トイルの定義と管理
通常運用中に人間のオペレーターがシステムに触れる必要があるなら、それはバグです。システムが成長するにつれて「通常」の定義は変わっていきます。
— Carla Geisser, Google SRE
SREは運用作業よりも長期間にわたるエンジニアリングプロジェクトの作業に時間を使おうとします。しかし「運用作業」という言葉は誤解を招くため、私たちはトイル (Toil) という言葉を使います。
トイルの定義
トイルとは単なる「やりたくない仕事」ではありません。管理上の雑務や汚れ仕事と単純に言い換えられるものでもありません。手作業の繰り返し業務を好む人さえいます。行わなければならない管理上の雑務もありますが、それはトイルではなくオーバーヘッドです。つまらない仕事には長期的な価値があることもあり、そうであればそれはトイルではありません。
それではトイルとは何でしょうか?
トイルとは、プロダクションサービスを動作させることに関係する作業で、以下のような特徴を持つものです:
- 手作業で繰り返し行われる
- 自動化することが可能
- 戦術的である
- 長期的な価値を持たない
- 作業量がサービスの成長に比例する
以下の説明の一つ以上に当てはまるような仕事であれば、その仕事のトイルの度合いは高いと言えます。
トイルの特徴
| 特徴 | 説明 |
|---|---|
| 手作業であること | 何らかのタスクを自動化するためのスクリプトを手作業で実行するような作業が含まれます。スクリプトを実行するのは、そのスクリプト中の各ステップを手作業で実行するのに比べれば手早いですが、スクリプトを走らせるための実作業に人間が使う時間は、やはりトイルの時間です。 |
| 繰り返されること | ある作業をするのが初めて、もしくは二回目程度なのであれば、その作業はトイルではありません。トイルとは繰り返し何度も何度も行われるものです。 |
| 自動化できること | マシンが人間同様に行えるタスクや、そのタスクの必要性がなくなる仕組みが作れるのであれば、その仕事はトイルです。そのタスクに人間の判断が欠かせないのであれば、トイルとは言い難いですが、本質的に人間の判断を必要とするのか、そしてもっと優れた設計で対応することはできないのか、といったことを慎重に考える必要があります。 |
| 戦術的・反応的であること (Tactical) | トイルは長期的な戦略に基づく能動的な作業ではなく、突発的な割り込みや問題発生に対して受動的に行う作業です。アラートへの対応はトイルです。この種の仕事を完全になくしてしまうことはできませんが、最小限になるよう、継続的に努める必要があります。 |
| 長期的な価値を持たないこと | あるタスクを終えた後でも、サービスが同じ状態のままなのであれば、そのタスクはおそらくトイルです。例えば、古いコードや設定に踏み込んで整理するといった、つまらない作業が含まれていたとしても、そのタスクによってサービスに恒久的な改善が加えられるのであれば、それはトイルではありません。 |
| サービスの成長に対してO(n)であること | その作業に、サービスのサイズ、トラフィックの量、ユーザー数などに比例してスケールするようなタスクが含まれているなら、そのタスクはおそらくトイルです。理想的な管理と設計がなされたサービスは、リソースを追加する一度限りの作業はともかくとして、その他の追加の作業なしに、少なくとも一桁は成長できるものです。 |
トイルは少ないほうが良い理由
GoogleのSRE組織では、トイルを各人の作業時間の50%以下に抑えるという目標が掲げられています。各SREの作業時間のうち最低でも50%は、将来のトイルを削減するか、サービスに機能を追加するエンジニアリングプロジェクトの作業に費やされるべきです。
50%ルールの重要性
この50%というゴールを共有する理由は、トイルというものは、確認しないままにしておけば拡大し、急速に全員の時間の100%を埋め尽くしてしまう傾向があるためです。
トイルを減らし、サービスをスケールさせる作業が、SREにおける「エンジニアリング」です。エンジニアリングの作業によって、SRE組織の規模はサービスのサイズに比例しなくなり、純粋な開発チームや運用チームに比べて、より効率的なサービスを管理できるようになります。
エンジニアリングであるための条件
エンジニアリングの作業とは、新しいことをするものであり、本質的に人間の判断を必要とします。エンジニアリング作業は、サービスに恒久的な改善を加え、戦略によって導かれるものです。この作業はクリエイティブかつイノベーティブであることが多く、問題を解決するために設計主導のアプローチをとります。つまり汎用性があるほど優れています。エンジニアリングの作業は、チームやSREの組織が同レベルのスタッフ数でより規模の大きいサービスや多くのサービスを扱えるように支援します。
典型的なSREの活動分類
| 分類 | 説明 |
|---|---|
| ソフトウェアエンジニアリング | コードの作成・修正を含む作業であり、関連する設計やドキュメンテーションの作業も含まれます。 例: 自動化スクリプトの作成、ツールやフレームワークの作成、サービスへのスケーラビリティや信頼性のための機能の追加、インフラストラクチャのコード修正による頑健性の改善など |
| システムエンジニアリング | プロダクションシステムの設定、設定の変更、システムに関するドキュメント作成が含まれ、一回の作業で改善効果が持続するような方法で行われます。 例: モニタリングのセットアップと更新、ロードバランシングの設定、サーバーの設定、パラメーターチューニングなど。システムエンジニアリングには開発チームに対するアーキテクチャ、設計、プロダクション環境への適合のコンサルテーションも含まれます |
| トイル | サービスを稼働させることに直結している作業で、繰り返されたり、手作業だったりするもの |
| オーバーヘッド | サービスを稼働させることに直結していない管理的な作業。 例: 採用、人事の労務作業、ミーティング、バグのキューの整理、スニペット（コード片）の作成や共有、ピアレビュー、自己評価、トレーニングコースなど |
トイルは急増しがちなので、安定してエンジニアリングに50%の時間をあてるのは、SREチームによっては現実的ではないこともあります。しかし、プロジェクトに使われた時間の比率の平均が長期的に見て大きく50%を下回っているなら、チームは一歩引いて、何が問題なのかを確認しなければなりません。
トイルの計算
SREがトイルに費やす時間を50%に抑えようとする場合、その時間はどのように使われるのでしょうか？
オンコール対応をしているSREには、処理しなければならないトイルの下限があります。典型的なSREは、各サイクルでプライマリオンコールを1週間、セカンダリオンコールを1週間担当します。したがって、6人のローテーションでは、6週間のうち少なくとも2週間がオンコールシフトと割り込み処理に充てられることになり、潜在的なトイルの下限は 2/6 = 33% となります。8人のローテーションでは、下限は 2/8 = 25% です。
Google SREの実データ
このデータと一致して、SREはトイルの最大の原因は割り込み（緊急ではないサービス関連のメッセージやメール）であると報告しています。次に多いのはオンコール対応（緊急）で、その次がリリースとプッシュです。リリースとプッシュのプロセスは通常、かなりの自動化で処理されていますが、この領域にはまだ改善の余地があります。
GoogleのSREに対する四半期ごとの調査によると、**トイルに費やされる平均時間は約33%**であり、全体目標の50%を大きく下回っています。しかし、平均は外れ値を捉えきれません。一部のSREは0%のトイル（オンコール作業のない純粋な開発プロジェクト）を報告し、他のSREは80%のトイルを報告しています。個々のSREが過度のトイルを報告する場合、それはしばしば、マネージャーがチーム全体にトイルの負荷をより均等に分散し、それらのSREがやりがいのあるエンジニアリングプロジェクトを見つけることを奨励する必要があることを示しています。
トイルの計測と報告の実践例
各SREエンジニアがトイルにかけた時間をどのように計測し、報告するかについては、チームの文化やツールに合わせていくつかの方法があります。
1. チケットシステムによるラベリングと時間記録
JiraやGitHub Issuesなどのチケット管理システムを使用している場合、タスクに「Toil」や「Engineering」といったラベルやカテゴリを付与します。
- 方法: 作業完了時に所要時間を記録し、適切なラベル（例:
type:toil）を付ける。 - メリット: 定量的なデータが自動的に集計でき、可視化しやすい。
- デメリット: すべての作業（特に細かい割り込み）をチケット化するオーバーヘッドが発生する。
2. スニペット（週報）による自己申告
Googleで行われている「スニペット」のような、週ごとの作業要約を活用します。
- 方法: 毎週の終わりに、その週に行った主な活動を箇条書きにし、トイルとエンジニアリングの割合を概算（例: トイル 40%, エンジニアリング 60%）で記載して共有する。
- メリット: 記録の負担が少なく、定性的な情報（何が辛かったかなど）も共有できる。
- デメリット: 主観的な見積もりになりがちで、正確性に欠ける場合がある。
3. 四半期ごとのアンケート調査
定期的にチームメンバーに対してアンケートを実施し、トイルの状況を把握します。
- 方法: 「過去3ヶ月間で、トイルに費やした時間は何%くらいでしたか？」「トイルの主な原因は何でしたか？」といった質問を行う。
- メリット: 長期的な傾向や、メンバーの感情（燃え尽き感など）を把握しやすい。
- デメリット: リアルタイムなデータではないため、即座の対策が遅れる可能性がある。
4. オンコールシフトの分析
オンコール担当中の活動ログを分析します。
- 方法: PagerDutyなどのツールからアラート数や対応時間を集計し、オンコールレポートとしてまとめる。
- メリット: 最も負荷の高い「割り込み」トイルを正確に把握できる。
- デメリット: オンコール以外のトイル（手作業のスクリプト実行や申請業務など）が漏れる可能性がある。
これらの方法を単独で、あるいは組み合わせて使用し、チーム全体でトイルの傾向を把握することが重要です。
トイルは常に悪なのか?
トイルは必ずしも全員を不幸にしてしまうわけではありません。これは量が少ない場合は特にそうです。予測可能な繰り返しのタスクは、ごく穏やかなものです。中にはこの種の作業を楽しめる人もいます。
トイルは常に同じように悪いものというわけではなく、SREにとって多少のトイルは避けられないものだということをはっきり認識しておかなければなりません。少量であれば気にする必要はありません。トイルが有害になるのは、大量に処理しなければならなくなったときです。
多すぎるトイルが悪である理由
個人への影響
-
キャリアの停滞: プロジェクトに使う時間があまりに少なくなると、キャリアアップが遅くなったり、急停止することになります。つまらない仕事からキャリアを生み出すことはできません。
-
モラルの低下: あまりに多すぎるトイルは燃え尽きや倦怠、不満につながります。
組織への影響
エンジニアリングに使うべき時間までトイルに時間を使いすぎると、SREの組織には以下のようなダメージが生じます:
| 影響 | 説明 |
|---|---|
| 混乱の発生 | SREの組織の中で、あるいはSREの組織とともに働く誰もが、SREはエンジニアリングの組織であることを理解してもらうようにしています。SRE内の個人やチームがトイルにばかり従事しすぎていると、SREという職務について他の人々が勘違いしてしまう可能性があります。 |
| 進捗速度の低下 | 過剰なトイルは、チームの生産性を下げます。SREチームが手作業や新しい機能を早急にロールアウトするための消火活動に忙しすぎると、プロダクトの機能開発の速度は下がってしまいます。 |
| 習慣づけ | トイルに取り組むのに熱心すぎると、開発側のカウンターパートはもっと多くのトイルを回したくなりはじめ、場合によっては本来開発側で行うべき運用のタスクまでSREに回そうとします。 |
| 摩擦の発生 | あなたが個人的にはトイルに不満を抱いていなくても、現在の、あるいは将来のチームメイトはトイルが好きではないかもしれません。チームの仕事の流れにあまりに多くのトイルを組み込んでしまうと、それはチーム内の最高のエンジニアに対し、もっと報われる仕事を他のところで探すように勧めているようなものです。 |
| 信義違反 | プロジェクトの作業を約束された上で新規採用された人や異動でSREに加わった人は、欺かれたと思うでしょう。これはモラルに悪影響を及ぼします。 |
継続的な改善の重要性
もし私たち全員が毎週少しずつトイルを削減することに取り組めば、着実にサービスをクリーンアップできます。そして、スケールのためのエンジニアリング、次世代サービスのアーキテクチャ設計、SRE横断的なツールチェーンの構築に私たちの集合的な努力をシフトできるようになります。
より多くを発明し、より少なくトイルしましょう。
まとめ
- トイルは手作業で繰り返される、自動化可能な作業であり、長期的な価値を持ちません
- SREは作業時間の50%以上をエンジニアリングプロジェクトに費やすべきです
- Google SREの実データでは、平均トイル時間は約33%（目標50%以下を達成）
- オンコール体制を考慮すると、トイルの理論的下限は25-33%程度
- 少量のトイルは避けられないものですが、過剰なトイルは個人と組織の両方に悪影響を及ぼします
- トイルを削減し、エンジニアリング作業に注力することで、SREチームはよりスケーラブルなサービス運用を実現できます
- 毎週少しずつトイルを削減する継続的な取り組みが重要です