トイルについて改めて考える

はじめまして、@mshibuyaです。2019年7月よりメルカリにて働いており、メルカリシステムを支えるインフラを運用しサービスの信頼性を担保するSREチームにおいてエンジニアリングマネージャーをしています。

ここではトイルについて考えます。トイルは、SREに関わる皆様には大変おなじみの概念と思いますが、改めて紹介すると

トイルとは、プロダクションサービスを動作させることに関係する作業で、手作業で繰り返し行われ、自動化することが可能であり、戦術的で長期的な価値を持たず、作業量がサービスの成長に比例するといった傾向を持つものです。
（Betsy Beyer他編「SRE サイトリライアビリティエンジニアリング」 オライリー社）

といったものです。「トイルは悪であり、できるだけ減らすべきもの」という点においては議論の余地はあまりないものと考えますが、その一方「何が減らされるべきトイルであるのか」については人によって・チームによって解釈の幅が大きいように感じられるので、そこについて改めて考え直してみたいというのがこの記事の動機です。

なおこの記事はSRE Advent Calendar 2019の17日目のエントリです。

トイルの分類学

SRE Workbook Chapter 6 - Eliminating Toilのセクション「Toil Taxonomy」において6つの類型が取り上げられています。

ビジネスプロセス

サービスを動かすコンピューティングリソースの管理のために必要とされる様々なオペレーションによるもので、

• 新規ユーザの追加
• 設定変更やセキュリティ対策
• ソフトウェア更新
• 負荷に追従するためのリソース追加や削除
• コスト最適化

といった一連の作業がもたらす負荷です。典型的にはチケットベースの依頼の形を取り、作業負荷がチームに分散され気づかないうちに静かに積もっていく可能性があります。

本番環境による割り込み

本番システムを動かし続けるために必要となる時間的制約の高いタスクのことで、

• 枯渇したディスクの空き容量の確保
• 応答しなくなったアプリケーションの再起動
• 負荷に応じたキャパシティの調整

のようなものが該当します。オンコール対応の時に行うようなことはここに入るイメージですかね。

リリースの見守り

多くの場合は自動化されたデプロイシステムが整備されているはずですが、それでもデプロイはレビューや自動テストといった様々なプロセスから成り立っておりいつもうまくいくとは限りません。リリースリクエストを作り、ダメならロールバックしたり、緊急パッチを作ったり、設定変更をしたり…といった作業を行うことは負荷であり、トイルとなり得ます。

移行

なんらかのテクノロジーから別のテクノロジーへの移行（データストア・クラウドベンダー…といった）については、それを一度限りのものと考え、手作業で行ってしまいがちですがそれ自体トイルたり得ます。例えばデータベースの移行のためにバックアップツールを書き換えることはソフトウェア開発のタスクですが、そのこと自体がバックアップツールのビジネス上の価値向上をもたらすわけではなく、長い目で見れば繰り返され得る作業です。

コストエンジニアリングとキャパシティプランニング

• リソースを省コストで利用するための取り組み（リザーブドインスタンスの購入のような）
• 上流・下流にあるサービスのサービスレベルレビュー
• ワークロードの大きさに合わせた最適化
• クラウドベンダーが提供するサービスに合わせたアプリケーションの最適化（DynamoDBに最適化する、のような）
• スポットインスタンスを利用可能にするためのツールの変更
• 余剰リソースへの対応

といったものもトイルになり得ます。

見えにくいアーキテクチャのトラブルシューティング

マイクロサービスのような分散アーキテクチャを採用していて、かつ十分洗練されたトレーシングやモニタリングが整っていない場合、トラブルシューティングにかかる労力は大きくなります。似たような問題に繰り返し悩まされていて、都度原因究明に労力を要しているならトイルに該当するでしょう。

気付き

こうして見ると、普段SREチームがやっているようなタスクってほとんどトイルに見えてきませんか？うーん、我々のやっていることの大半は実は価値がないんですかね…

多分そんなことはなくて、そこは上記分類にも断り書きのある通り

トイルであるかどうかというのは0/1で分類できるものではなくて、スペクトル状に幅のあるものと考える方がよい。

なのです。「このタスクはトイル度80%くらいだ」「このタスクは効果が期待できるのでトイル度20%ほどでは」という風に考える方が実態に沿っているのでしょう。

そして大事なポイントがあると思っていて…

タスクが（合理的な労力の範囲内での）自動化可能性を持たないのだとすれば、それをトイルと見なす選択肢を多分失う

のではないかなと思い至りました。「これは自動化しようがないし、一回きりだからトイルじゃなくてソフトウェアエンジニアリングだよね」みたいなことになってしまい得ると。人間誰も、自身がトイルのような相対的に意味の薄いことをやっているとは思いたくないですからね。

自動化可能性の低さは、いろんなところから生まれうると思います。アーキテクチャもそうですし、ツール・慣習・プロセス…などなど。

トイルとの戦いは、こういった多くの要素も考慮しながら、戦略的・長期的なビジョンを持って臨むことになるのでしょう。長い戦いになりますね。

まとめ

このエントリでは、SRE Workbookで取り上げられているトイルの分類について紹介し、そこから得た着想について紹介しました。

現在メルカリSREチームでは自分と一緒にこんなことを考え、SREチームの成果を最大化するために力をお貸しくださるエンジニアリングマネージャーを絶賛募集中です。

Engineering Manager, Site Reliability - Mercari, Inc.

少しでも興味をもって頂けた方がいましたら、こんなbosyuもありますのでまずはカジュアルに食事でもどうでしょう。
上記bosyuないしTwitterアカウント宛でも大丈夫ですので、どうぞお気軽にお声がけください！現場の生の課題感などあれこれ語らいましょうー