shorihata/📝Note/💻Engineer Book/9章 せっかくのインシデントを無駄にする

9章 せっかくのインシデントを無駄にする

インシデントから学ぶべき

  • 学びの場として最適なのは、物事がうまくいったときではなく、うまくいかなかったとき。
  • 物事がうまくいっているときは、自分がシステムの中で実際に起こっていることと、システムの中で実際に起こっていることが、必ずしも矛盾しない。
  • インシデントは、システムに対するあなたの理解が現実と一致しているかどうかを確かめる決定的な機会
(たとえば) 15ガロンのガソリンタンクの車を、30ガロンのガソリンタンクの車だと思い込む。 10ガロンを使ったら、ガソリンを入れるという習慣があったため、理解と現実は対立しない。 いざ長距離ドライブで15ガロンを消費したときに問題が発生する。 → 自分の愚かさに気付き、新しい情報を得て適切な注意を払うようにできる。
いざ問題が発生したら、そのあとどうする？
  • 理由を深く追求する →インシデントから学ぶことができる
  • 念のため5ガロン使うごとにガソリンを入れた方がいいなと考える →インシデントから何も学ばずに暫定的な対応となり問題は解決しない(でも、こういうことも多くある)
教訓は、必ずしも自然に得られるものではない。多くの場合、体系的に構造化された方法で、システムやチームメンバーから教訓を引き出す必要がある。
そのため、ポストモーテムを実施しよう

良いポストモーテム

こんなポストモーテムは嫌だ

非難と懲罰のための、ポストモーテムは嫌だ。
(非難と懲罰の文化で)インシデントが発生すると、人々は責任のなすりつけ合いを始める。
  • 問題から距離を置こうとする
  • 情報に壁を作る
  • 自分が無実であると示すのに役に立つ点についてだけ手助けする
(非難と懲罰の文化では)インシデントの対応は「ミス」をした責任者を見つけ出し、彼らを適切に罰し、恥をかかせ、追いやること
その後、インシデントを起こした作業については誰かの承認を必須とするというような、余分なプロセスを追加されることになる。そして、問題が二度と起こらないことを確信して満足しながらその場を後にする。しかし、いつも問題は再発する。(ついでにプロセスが増えることで生産性も悪化する)
問題が人にあると攻撃してしまうのではなく、システム・プロセス・ドキュメント・システムの理解のすべてが、どのようにしてインシデントにつながったかを考えないといけない。
懲罰のための場になってしまうと、誰も参加しなくなり、継続的な学習と成長の機会を失う。

メンタルモデルを作ろう

(たとえば) 理解：Webサーバ→DBサーバ 現実：Webサーバ(クラスタ)→プロキシサーバ→DBサーバ(プライマリ/セカンダリ)
エンジニアのモデルとシステムの現実のギャップを埋めよう。

24時間ルールの遵守

  • 記憶が薄れ、詳細が失われていくから
    • インシデントは詳細が大きな違いを生む
  • 失敗の背景にある感情やエネルギーを確実に活用するため
    • インシデント直後は、極度の警戒心を抱く
    • 時間の経過とともに、危機感が薄れていく

ポストモーテムのルール設定

協力的でオープンな雰囲気を作るために。 非難と懲罰の文化ではなく、非難と懲罰の文化ではない文化で、コラボレーションと学習をより促進できる環境のために。
  • 人を直接批判してはならない。行動が振る舞いに焦点を当てる。
  • 誰もが、その時点で得られた情報の中で、最善の仕事をしたと考える。
  • 今となっては明白な事実であっても、その場ではあいまいだった可能性があることを認識する。
  • 人ではなくシステムを責める。
  • 最終的な目標は、インシデントに関与したすべての要素を理解することであることを忘れない。

ポストモーテムの招待者

  • インスデントから復旧プロセスに直接関与したすべての人
    • 復旧作業に少しでも関わった人でもよい
  • プロジェクトマネージャー
    • 既存のプロジェクトやリソースに与えた影響を伝えることができる
    • プロジェクトの計画が、問題を急ぎで解決するよう急かす状況を生み出していたりする
  • ビジネスステークホルダー
    • 技術的な詳細がビジネスにとってどのような影響があるか
  • 人事担当者
    • リソースや人員配置に要因があることがある

タイムラインの振り返り

イベントをタイムラインに記載する

(ポストモーテムの事前準備として) インシデント中に発生した一連のイベントをドキュメント化する
なにを？
  • どのようなアクションやイベントが行われたのか
  • 誰がそれを行ったのか
    • 主語が人ではなく、システムであることもある
    • 人の場合は役割で書く(エンジニアA、Bなど)
  • それが行われた時刻はいつか
どのように？
  • 純粋な事実のみを記載する
    • 何が起こったのか明確かつ簡潔に記述する
    • 解釈やコメント、動機などを一切排除する(この時点では)

イベントに文脈を与える

文脈とは、発生した各イベントの背景にある詳細や動機を示すもの
イベントの文脈は、その時の状況に対するその人のメンタルモデルを理解するためという動機で与えられるべき。 メンタルモデルを理解することで、なぜその決定がなされたのか、その決定に至るまでの前提条件を説明できます。
それぞれの出来事を見て、その決定の背景にある動機を探るような質問をしてみる
  • なぜそれが正しい行動だと感じたのか？
  • システムで何が起こっているのかについて、なぜそのように解釈したのか？
  • ほかの行動を検討したか？検討した場合、なぜそれらを排除したのか？
  • 誰かほかの人がそのアクションをとる場合、あなたがその時に持っていた知識をその人はどのように得るだろうか？
これらの質問はその人のアクションが正しいか間違っているかを仮定していない
ポストモーテムでは、誰かが正しい行動をしても、間違った行動をしても、同じように多くの学べることがある。 たとえば誰かがあるサービスを再起動し、それがインシデントを解決したアクションであった場合、エンジニアが何を知っていてそのアクションをとったのかを理解することは価値がある。
ポストモーテムでは、今後実行するべきアクションも決めるべき。 「誰がいつまでに何をするか」という形式で明確に定義されないといけない。 (時間が経つにつれてタスクの緊急性が薄れていく。)

アクション

アクションは、短期目標と長期目標に分けるべき。
  • 短期目標は、合理的な時間内に実行可能なタスク。チームで簡潔する。
  • 長期目標は、多大な労力を要するタスク。上層部による優先順位付けが必要になる。
ポストモーテムで決められたアクションは、日々の忙しさに追われ、優先順位は下がりがち。 アクションの進捗がなければ、重要でないと判断して、リスク保有とする選択もアリ。

ドキュメント化

ドキュメント化には非常に大きな価値がある。ドキュメント化したものは共有する。
  • ポストモーテムチーム以外の人に伝えるための記録として。
  • 将来同じような問題に遭遇したときの歴史的な記録として。
→ 他のエンジニアからも読まれることを想定する。
  • インシデントの詳細
    • インシデントが発生した日時
    • インシデントが解決した日時
    • インシデントが継続していた期間
    • 影響を受けたシステム
  • インシデントサマリー
    • インシデントについてはっきりとまとめた文章を書く節。2-3段で収める。
    • 全体的な影響、ユーザ体験への影響、どのように解決されたのか。
  • インシデントウォークスルー
    • 最も詳細な節
    • この節の対象読者はエンジニア
    • アクションの背景にある意思決定プロセス、グラフ・チャート・アラート・スクリーンショットなどの補足資料を提供する。
    • 網羅的である必要はないが、自分で調べる上で十分な背景を提供する
  • 認知とプロセスの問題
    • グループが改善すべき領域として特定した事柄を記載する。
    • 人々のメンタルモデルが正しくなかった部分をすべて検討する。
    • たとえば
      • 対応手順にステップが欠けている
      • 失敗シナリオが考慮されていなかった
    • 責任の所在ではなく、障害の原因となった重要な部分を特定する。
  • アクション
    • 箇条書き
    • 誰がいつまでに何をするか