本を読む会 SRE サイトリライアビリティエンジニアリング #5 ~トイルの撲滅

読み会5章「トイルの撲滅」予習ログです。

#5 トイルの撲滅

Eliminating Toil

  • "If a human operator needs to touch your system during normal operations, you have a bug. The definition of normal changes as your systems grow."

読み解きたいこと

  • トイルとはなにを指すのか
  • Google はどうしてこの内容をあえて章として取り上げるのか
  • トイルとは具体的にどういった作業を指すのか
    • SREに聞いてみたい

読書メモ

5.1 トイルの定義

  • トイル
    • プロダクションサービスを動作させるエンジニアリングに関係する作業
    • 自動化が可能で、戦術的で長期的な価値がなく、作業量がサービス成長に比例
  • オーバーヘッド
    • エンジニアリング以外の作業。プロダクションサービスの稼働に直接関係しない管理上のお仕事
      • e.g. 定例チームMTG, 人事評価作業、目標設定や選考課題考案や事前MTGなど
手作業である
  • e.g. 何らかのタスクを自動化するためのスクリプトを手動で実行するようなこと。確認や実作業にひとの時間を使うようなこと
繰り返される
  • e.g. 3回以上同じ作業を繰り返し繰り返し行うようなこと。もたらされる成果やアウトプットは同じもの
    • 1~2回程度であればトイルと言わない。また新しい気づきや問題解決や解決策に至る作業はトイルと言わない
自動化できる
  • マシンが人と同じように行えるタスク、またそのタスクの必要性をなくすことができる仕組みが作れるようなら、その作業はトイル
    • ひとの判断を要する作業はトイルではない 。ならば選考対応はトイルじゃない。オーバーヘッド
戦術的である
  • 戦略や予測の基づくものではなく、解決にいたるフローの中の作業でもなく、割り込みでスタートして問題発生時の対応作業としておこなわれるもの
    • ゼロにはできないが最小限にはしたい
    • 別のサービスで同じ障害がなんども発生してしまうようなこと？
長期的な価値を持たない
  • タスクを終えた後も、サービスが成長・前進しない
    • 古いコードや設定に踏み込んで整理改善し、サービスにとって恒久的な改善が加えられればトイルではない
サービスの成長に対して O(n) である
  • サービスの成長（トラフィック量、ユーザ数）とともに作業量も増加してしまうようなタスクはトイル
  • 理想的な管理と設計がされたサービスは、そのリソースを追加する作業のみで、他の追加作業なしに1桁程度は成長ができる

5.2 トイルは少ない方がよい理由

この節は Googleの信念を感じる。

  • トイルの作業性質は、SREの戦略・存在意義に反するから
  • SREにとってエンジニアリングとは、サービスをスケールさせる作業であるから

そのためにやっていること

  • SREの目標に、トイルに使う作業は作業時間全体の50%以内に抑えることを掲げる
    • 各SREの作業時間の最低50%は、将来的なトイルの削減またはプロダクト成長に寄与するシステム開発に充てる
    • そういった機能開発は、信頼性、パフォーマンス、利用率の改善目的でおこなうことが普通で、この作業はしばしばトイルを削減してくれる副次効果がある
  • SREの採用時に、いわゆる運用作業チームではないことを明言し約束する
    • そして運用作業チームにならないよう組織チーム全体で取り組んでいく
Googleでのトイルの計算
  • トイルのなかで最も多い作業は割り込み。緊急ではないサービスに関するメッセージやメール、notify
  • その次にオンコール（障害対応）、次にリリースやプッシュ
  • SREのトイルが多すぎる場合
    • 特定のSREのトイルが多すぎる場合は、マネージャがそれぞれに負荷分散できていないことを示す

5.3 エンジニアリングである条件

エンジニアリングとはなにか

  • 人間の判断を必要として新しいものを作ること
  • サービスに恒久的な改善を加え、戦略により導かれるもの
    • クリエイティブでイノベーティブであり、問題や課題を解決するために設計主導のアプローチを取る
  • 汎用的である/横展開が可能である

以下はSREの活動。SREがトイルに割く時間が50%を大きく上回る場合は、何が問題なのかをしっかりと確認しないといけない。

ソフトウェアエンジニアリング
  • SREがコードを書き、新しいツールやフレームワーク、自動化スクリプトを作り出すこと
  • サービスの信頼性やスケーラビリティにダイレクトに働きかけ、サービスに恒久的な改善をもたらすエンジニアリング
システムエンジニアリング
  • プロダクトのシステム設定、設定変更、システムのドキュメンテーションの作成
  • 一度の作業で改善効果が持続できるような作業
    • e.g. モニタリングのセットアップと更新、ロードバランシングの設定、サーバ設定、OSのパラメータチューニング、開発チームへのアーキテクチャ、設計、プロダクト環境に対するコンサルティング
トイル

上述の通り

オーバーヘッド

上述の通り

5.4 トイルは常に悪なのか?

  • 少量であれば悪ではない、中にはトイルを楽しめるSREもいる
    • いち早く達成感をもたらしてくれる類のタスクでもある
  • SREのみならずエンジニアにとってゼロにはできないものであることを認識しておきたい
  • トイルが実業務の半分以上あるいは大量に発生する場合は、問題視したい

トイルが悪になる理由は以下。

キャリアの停滞 (個人)
  • トイルを積み重ねても、サービス・個人どちらの成長にも繋がらない
モラルの低下 (個人)
  • あまりにトイルが多いとSREとして業務をすることが嫌になってしまう ><
    • 切ない
混乱の発生 (SREチーム)
  • SREが発揮する本来の成果/Site Reliabilityやサービスをスケールさせることに時間を割けない。SREの存在意義が自他ともにわからなくなってしまう
    • 切ない
進歩速度の低下 (SREチーム)
  • トイルが多すぎると SREチームの生産性が下がる。火消し作業ばかりに注力し本来のプロダクト機能開発速度の低下=サービス成長の機会損失
    • 切ない
習慣づけ (SREチーム)
  • SREが頑張ってトイルをやっつけすぎるとトイルに対してSREの活躍を期待するように
    • トイル対応はSREの主たるミッションではないのに切ない
摩擦の発生 (SREチーム)
  • トイルが多すぎることによるチーム全体のモラル低下、SRE個々の摩擦
  • 切ない
信義違反 (SREチーム)
  • 大量のトイルは、新規作用されたSRE、あるいは異動者に対する信義に関わる

5.5 まとめ

  • 優れたエンジニアリングで、毎日少しずつトイルを無くしていこうという気概を持とう
  • そのことでサービスをクリーンアップし、SREの労力をスケーラビリティの向上と次世代サービスのアーキテクチャ設計、ツールの構築にシフトしていこう
  • そしてイノベーションを増やし、トイルを減らしたいね

参考

www.youtube.com

わかったこと

  • SREにとってトイルの存在
  • トイルがもたらす影響
  • トイルを減らすために
    • SREの技術力、DevOpsの対立を生まない体制と仕組みづくり、どれが欠けてもいけない。トイルを削減するという目標を掲げ、削減に必要な材料は同時に進化させるという意思が重要そうだ
      • 自分の職種やチームにもトイルはある。判断を必要としない手作業や繰り返しを「仕方なし」で済ませている。気に留めないといけない

感想

「私たちSREにとってこれはトイルです」と決めて「トイルによりこんな悪影響が及びます」なので「撲滅したい」と発信することで、自分たちのミッションをブラさないとするGoogle SREの信念を感じた。一貫している。
と同時に、"5.4 トイルは本当に悪なのか" の節では SRE の悩みを垣間見せてもらった気がした。

トイルを撲滅するための案として「SREのクリエイティブやイノベーティブマインドを広報し、周辺理解の醸成を進める」を挙げてみたい。SREがパフォーマンスを発揮する対象が浸透すれば、エンジニア全体でトイルを撲滅するあるいは分担できる環境が整いやすくなるかもしれない。
他に、トイルから話が逸れるが、SREのクリエイティブは組織や担当サービスにより異なるイメージがある。一人ひとりのSite Reliability Engineer が、まだ新しい職種であるSREのありようをそれぞれの環境で育てていく、というおもしろさがありそうにも感じた。

SRE本を興味深いな読み返したいなと思える点として、別職種である自分にもあれこれと置き換えて思考できるというのがある。

参加者 : missasanさん, yuukiさん