インシデント対応

Google SRE Book の第14章(インシデント管理)と第15章(ポストモーテムの文化)を取得して読み、 理解した内容を自分の言葉で書いたもの。本文の引用はしていない。

管理されていないインシデントで起きること

技術力の問題ではなく、進行の管理を誰もしていないことが事態を悪化させる。 典型的な3つの失敗。

技術的な問題に視野が狭まる

対応者が原因究明に没入して、より広い緩和策が見えなくなる。 そして忙しすぎて、状況を明確に伝える余裕がなくなる。

コミュニケーションが崩れる

情報共有の型がないと、各自がサイロで動く。 経営層は状況を把握できず、手伝える人も何をすればいいか分からない。 「同僚が今どんな操作をしているのか誰も知らない」状態になる。

勝手に動く(フリーランシング)

善意の人が調整せずに変更を入れる。 テストしていないコードを本番に入れて、事態をさらに悪くする。

インシデント管理の4要素

責任の再帰的な分離

役割を明確に割り当てる。分離されているからこそ、各自の裁量が大きくなる。 同僚の判断を疑う必要がなくなるため。

手が足りなければ、その役割の中でさらに分割して委譲する(だから「再帰的」)。

認識された司令所

調整する場所を1つに決める。 物理でも仮想でもよい。 分散したチームならチャットが向いていて、記録がそのまま残るという利点がある。

インシデント状態のライブドキュメント

常に更新される、権威ある現状の記録。 指揮者がこれを最新に保つ。リアルタイムの調整に使い、後のポストモーテムの材料にもなる。

明示的な引き継ぎ

指揮の移譲を明示的に行う。特にタイムゾーンをまたぐとき、 「誰が指揮しているのか分からない」空白を作らない。

役割

役割やること
インシデント指揮者(Incident Commander)全体の状態を把握し、責任を委譲する
オペレーション責任者指揮者の指示のもと、実際に手を動かして技術的な対処をする
コミュニケーション責任者関係者へ定期的に状況を伝え、記録を保つ
計画責任者バグ登録や復旧計画など、より長い時間軸を扱う

変更を入れるのはオペレーション責任者だけ。 これがフリーランシングを止める仕組み。

進め方

まず止血する。原因究明より先に被害を止める
手順は事前に用意しておく
割り当てた人を信頼する。細部に口を出さない
自分と周囲の消耗を見る
定期的に別の手を検討し直す
平時に練習しておく
役割を持ち回りにして、組織として対応できるようにする

ポストモーテム

目的

ポストモーテムは罰ではなく、組織全体にとっての学習の機会。

やることは、インシデントを記録し、根本原因を理解し、再発を防ぐ手を打つこと。

非難しない(blameless)とは何か

個人の落ち度ではなく、システムの問題として扱う。 前提は「関わった全員が善意で動いていた」こと。

医療と航空という、安全が最優先される分野から来た考え方。

書き方が具体的に変わる。

非難する書き方非難しない書き方
「あの複雑なバックエンドを全部書き直す必要がある。毎週壊れている」「バックエンドを書き直すというアクションアイテムは、この繰り返されるページを止められるかもしれない」

指を差すのをやめて、「なぜその人はより良い判断をするための情報を持てなかったのか」を調べる方向に切り替える。

書く条件を決めておく

書くかどうかを都度議論しない。基準を先に決める。

利用者から見えるダウンタイムが閾値を超えた
データが失われた(量に関わらず)
オンコールが手で介入した(ロールバック、経路の切り替えなど)
解決までの時間が閾値を超えた
モニタリングが検知できず、人が手で見つけた

加えて、関係者は誰でもポストモーテムを要求できるようにしておく。

レビュー

レビューされていないポストモーテムを残さない。

シニアなエンジニアが草稿を見て、次を確認する。

書ききれているか
根本原因の分析が十分か
アクションアイテムの優先度が適切か

定期的なレビューの場を設けて、確実に完了させてから記録として保管する

文化として根付かせる

書けと言うだけでは根付かない。挙げられている仕掛け。

仕掛け内容
今月のポストモーテムよく書けたものを組織全体に紹介する
読書会過去のインシデントについて、軽食を出して率直に話す場を持つ
不幸のルーレット新メンバーが過去のインシデントを、当時の指揮者と一緒に再演する
見える形での評価良い対応をリーダーが公に称える
フィードバック調査プロセス自体への意見を定期的に集める

成功にはシニアなリーダーの参加が要る。 時間がかかるという懸念には、実際に価値が出ていることを示して応える。

関連