SRE サイトリライアビリティエンジニアリング ――Googleの信頼性を支えるエンジニアリングチームの特に気になっている第5章をまとめる。

まとめる際の視点

本章全体で、トイルとは何であり、何でないのかが書かれているため、これを明確にするようにまとめる。

トイルの定義

プロダクションサービスを動作させることに関係するタスクで、次の説明に1つでも該当する仕事はトイルの度合いが高い。

  • 手作業であること これには何らかの自動化スクリプトを手作業で実行するものも含まれる。つまりスクリプトを走らせるための実作業時間もトイルに分類される。

  • 繰り返されること 繰り返し何度も何度も行われるタスク。
    新たな問題を解決したり、新たな解決策を生み出しているならトイルではない。

  • 自動化できること マシンで行えるタスクや、タスク自体の必要性がなくなる仕組みが作れるものはトイルである。
    そのタスクに人間の判断が欠かせないものはトイルではない。
    ただし、「人間の判断が欠かせない」か判断するときには注意が必要(後述)。

  • 戦術的であること 割り込みで始まり、生じた問題への対応として行われるもの。ページャーのアラート対応なども含まれる。
    戦略的であったり将来予測に基づくものはトイルではない。

  • 長期的な価値を持たないこと タスクを終えてもサービスが同じ状態であるもの。
    ただし、古いコードや設定を整理するといったつまらないタスクでも、サービスに恒久的な改善が加えられるならトイルではない。

  • サービスの成長に対してO(n)であること サービスサイズ、トラフィック量、ユーザ数などに比例してスケールするもの。
    理想的な管理と設計がなされたサービスは追加のタスク無しに1桁は成長できるはずである。

そのタスクには本当に人間の判断が欠かせないか？

脚注だが重要なポイントのためピックアップする。

あるタスクを「人間の判断を必要とするのでトイルではない」と判断するときには、注意しなければなりません。タスクが本質的に人間の判断を必要とするのか、そしてもっと優れた設計で対応することはできないのか、といったことを慎重に考えなければならないのです。

人間による“多くの判断”と“複雑なレスポンス”を求めるようなタスクが“何度も”発生するサービスの場合、不必要な複雑さを抱えた設計に問題がある。そういったサービスは、単純化すると共に、下位層の障害の影響を排除したり、それに自動的に対応できるよう再構築する必要がある。
再構築が完了しリリースされるまで、この種の「人間の判断を必要とする」タスクはトイルである。

トイルは少ないほうが良い理由

放置すれば拡大し、急速に全員の時間の100%を埋め尽くすため。
この理由のため、GoogleのSRE組織では、トイルを各人の作業時間の50%以下に抑えるという目標を掲げている。それにより、各SREは最低でも作業時間の50%は「将来のトイルの削減」「サービス機能開発」に費やされることが目標となる。 「サービス機能開発」のフォーカスは信頼性・パフォーマンス・利用率改善で、これは二次効果としてトイルを削減する。

  • 管理面 SREにおける「エンジニアリング」(後述)の作業により、サービス規模に比例しないSRE組織でサービスを管理できるようになる。
  • 人事面 GoogleではSREの採用時に50%ルールを引用し、SREが典型的な運用チームではないことを約束している。
    この約束を守るため、SREが単なる運用チームに退化しないようにする必要がある。

エンジニアリングであるための条件

本質的に人間の判断を必要とする。
サービスに恒久的な改善を加え、戦略によって導かれる。

  • ソフトウェアエンジニアリング(トイルではない) コード作成・修正、関連する設計・ドキュメント作業。
    例) 自動化スクリプト・ツール・フレームワーク作成、スケーラビリティ・信頼性・頑健性のためのコード修正
  • システムエンジニアリング(トイルではない) システム設定・設定変更・システム関係のドキュメント作業。
  • トイル サービス稼働に直結する作業で、繰り返したり手作業のもの。
  • オーバーヘッド(トイルではない) サービス稼働に直結しない管理的な作業。 例) 採用・人事・MTG・BTSの整理・作業報告・レビュー・自己評価・研修

トイルは常に悪なのか？

多少のトイルは避けられないが、エンジニアが少量の作業を楽しめるなら問題ない。
大量に処理する必要がある場合には次の理由で悪となる。

  • キャリアの停滞
    プロジェクトに使う時間が少なくなることで、キャリアアップの遅滞や停滞が発生する。
  • モラルの低下
    耐えられるトイルが限界に達して燃え尽き・倦怠・不満につながる。
  • 混乱の発生
    「エンジニアリングの組織である」というSREについての理解がチームの内外で混乱する。
  • 進捗速度の低下
    SREが手作業や消火活動に忙しすぎると、プロダクトの機能開発の速度が低下する。
  • 習慣づけ
    SREがトイルに熱心すぎると、SRE外のチームがSREにもっとトイルを回したくなる。
  • 摩擦の発生
    人により耐えられるトイルの量には差があり、耐えられないエンジニアの脱出を促してしまう。
  • 信義違反
    採用・異動の際に提示した「SREが典型的な運用チームではない」という約束に反する。