20180510-30.md

場所

TheCompany博多 1F

概要

30章 SREの投入による運用過負荷からのリカバリ @takumakume

資料

30. SREの投入による運用過負荷からのリカバリ

本章では運用過負荷のチームに対して、SREを投入し解決することに必要な過程や注意点について学習できた。

• 日々のチケット消費 > プロジェクト の状態に陥る事がある。(Googleでは均等が標準ポリシー)
  • SREが燃え尽きる
  • プロジェクトが遅延する
  • サービスのスケーラビリティ・信頼性が低下する
• 別のチームのSREを移籍させる
  • (補足) 読み進めるとここでいうSREは SRE哲学を理解し実践・導ける人 である必要があると理解した
  • チケットの消費をすることが目的ではない
  • チームのプラクティス改善に注力 (日々のルーチンワークの観察 → やり方の改善提案)
  • 複数人移籍する必要はない、チームが移籍に対して身構えないようにすること

30.1 フェーズ1: サービスの学習と状況の把握

• チームの仕事のプロセスや習慣がサービスのスケーラビリティの良し悪しに与える影響と理由を明確にすること
• チケットが多くなった → 人員を増やす ではないことをチームに思い出させる

運用モード

• サービスの成長によって増える作業をひたすら頑張るようなこと
  • サービスが成長したので、VMを構築する必要がある。構築部隊を結成しよう！
  • SREではソフトウェアを書いて解決する
• 運用モードに陥ったエンジニアはサービスのスケールによる問題を問題と認識しない
• あなたの仕事はアラート対応ではなくサービスの信頼性向上である

30.1.1 最大のストレス発生源の特定

• 運用モードに陥るのは過度なプレッシャーが要因になることが多い
• 作業を観察する間に発生した障害のストレスレベルの大きさを確認し、高い順に優先順位をつける
  • ストレスレベルは必ずしも "ストレスレベルの大きさ = 障害の大きさ" ではない
    • チームの視点や歴史によってストレスを生むことがある

30.1.2 発火点の特定

チームの最大の問題が特定できたらこの先予想される問題に備える

• 知識レベルのギャップ
  • 一部のチームメンバーの特化が進むと
    • オンコールサポートを行うための幅広い知識を持とうとしない
    • 自分たちが所有する重要な部分を他のメンバーに無視させるリスクを冒す
    • (補足) 特化したメンバーが作った、メンバーとしては謎技術の機能を共有しないと理解した
• SREが開発したサービスが静かに重要性を増している
  • 一人のSREによって暗黙的に支えられているサービス
• 「次の大きなアップデート」への強い依存
  • なんか問題が起きちゃったけど、来年OSのバージョンアップで解決するだろうから放置しよう！的なやつ
• 開発チームにもSREにも診断されないありふれたアラート
  • ワークアラウンド止まり
  • アラート対応ルールを作ってきっちり調査できるようにする
• 障害ドリブン以外でキャパシティ計画を持たないサービス
  • 生まれる
• サービス障害を招いた特定の変更のロールバックだけがアクションアイテムとなっているポストモーテム

30.2 フェーズ 2:状況の共有

フェーズ1でチームの力学と泣き所を見極めた、その後

• ポストモーテムのようなベストプラクテクスの適用
• トイルの発生源への最善の対処法を特定

30.2.1 チームのために良いポストモーテムを書く

• 不健全なチームのポストモーテムは効果がない
  • ポストモーテムを処罰であったり無駄と思っている
  • 「どうして自分が？」と報復に感じる
• 運用モードに入ったエンジニアは 腐ったリンゴ理論 を展開する
  • サービスの腐った部分を改善するのではなく、単に取り除く

30.2.2 火事を種類別に並べる

• トイルとそうでないものに分類する
• 更に自動化するものと、サービスのオーバーヘッドとして容認できるものに分類する

30.3 フェーズ 3:変化の推進

• チームの健全性はプロセス
• 英雄がバーーーンと解決するとかではだめ

30.3.1 基本からのスタート

• SLO(サービスレベル目標)がない場合は定義する
• 定量的にサービスへのインパクトを測定する
• 対処的な運用作業を健全で長期的なSREの焦点に移行させるための重要な手段

30.3.2 発火点の掃除の手助けを求める

• 移籍したSREは見つけた問題を単に修正してしまいたいと思うかもしれないが、それではだめ

  • 誰かやってくれるだろう... という考え方が根付いてしまう

    1. チームメンバーの 1 人がこなせる有益な作業を見つけてください。
    2. その作業により、ポストモーテムに書かれている問題が恒久的に対処される理由を明確に 説明してください。そうしなければ、健全なチームでさえも短絡的なアクションアイテムを作り出してしまうことがあります。
    3. コードの変更とドキュメントのリビジョンに対するレビューアの役割を果たしてください。
    4. 2つないし3つの問題に対して同じことを繰り返してください。

30.3.3 根拠を説明すること

• 移籍したSREがチームを離れても、設計や変更リストに対して「SREさんならどうコメントするか」をチームが予想できるようになっていなければなえらない

30.3.4 導く質問を投げかけること

• SRE基本原則について考えるように投げかける
• 運用モードに入っているエンジニアは拒絶する
• 移籍したSRE自身が体現する必要がある

30.4 まとめ

● 自分たちが変化すべき理由に関する技術的かつ場合によっては定量的な視点。 ● 変化がどのようなものかを示す強力な例。 ● SRE が利用する「民衆の知恵」の多くに対する論理的な説明。 ● スケーラビリティのあるやり方で新しい状況に対応するために必要な中核的原則。

• 最後のタスクは、事後報告書を書くこと
  • あなたの視点、事例、説明を反復するもの
  • 実践するためのアクションアイテムを入れておくとよい
  • 成功に至る各段階での重要な判断について説明された、ポストバイタム