間違いだらけの ポストモーテム 〜ホントに役立つレビューはこうだ !〜

Kazuto Kusama @jacopen Product Evangelist @PagerDuty Japan Organizer @Platform Engineering Meetup Founder @Cloud Native Innovators Association Organizer @CloudNative Days

インシデント、大変ですよね

Proprietary & Confidential July 19, 2024 世界に衝撃を与えた 大規模システム障害

ポストモーテム してますか？ Q

いきなりですが 本セッションでは今後ポストモーテムという呼び方はしません。 ポストインシデントレビュー (インシデント後レビュー) と呼びます ポストモーテムはやや後ろ向きの意味を持つ言葉です • 検死、死後解剖という意味 インシデント後には、多くのネガティブな感情が残ります 「あー、きつかった･･･」 なので、ポストインシデントレビューという言葉を使って、 前向きに考えるように促したいため です。

ただし、ポストモーテムという表現が間違いだ　というつもりはありません ※ その表現が組織に定着しているのであれば、無理に変える必要はありません。 • ポストインシデントレビュー • ポストモーテム • レトロスペクティブ • 振り返り どの用語を使っても問題はありません ※なんなら、 PagerDutyにもPostmortemsという機能があります

インシデントレビュー してますか？ Q

ポストインシデントレビュー ● やっていない、という方 ○ しましょう！ ● やっているという方 ○ とても良いと思います！ ○ ただ、レビューが「義務的」になっていませんか？ ○ レビューが組織の成長に繋がっていますか？ ○ より効果を高めるために、本セッションを参考にしてください

何故ポストインシデントレビューを 行うのか

インシデントは 最高に学べる

ポストインシデントレビューの目的 ● 大小問わずインシデントから学ぶ ● より良い方法について共有し、学び、協力するため ● 継続的な学習の文化を醸成

インシデントは システムの回復力の源を見る ための理想的な機会

インシデントから学習することで、何を得られる？ • 問題に素早く気づける • 適切な人材のチョイス • 問題の原因を素早く分析 • インシデント発生時の円滑な調整 • トレードオフの適切な処理 • ヒーローエンジニア依存の低減 • 若手エンジニアのスキル開発 • より適切な組織編成

ポストインシデントレビューの 進め方

どういうときにレビューすべき？ ● 本当に酷いインシデントだった場合 ● 二つ以上のチームが関与している場合。 それまで一緒に仕事したことない場合はなおさら ● 些細なことに思えるミスが関わっていた場合 (証明書の更新漏れなど) ● 大きなイベントの最中(株主総会とか)に起きた場合 ● 新しいサービス、またはサービス間の新たな連携方法によって起きた場合 ● いつもより多くの人がインシデント対応チャンネルに入っていた場合 インシデントの解消後、なるべく早く着手するのが望ましいが、大規模インシデントの場合疲労 の問題もあるので、ベストエフォートで対応しましょう

人間的な要素に注目する

人間的な要素に注目する 現代のシステムは、人間が人間の目的のために構築したもの。 なので、人間的な要素を理解しなければ、技術的な要素を理解することは できない 有意義なポストインシデントレビューを行うには、 直面した技術的な課題とそれを処理した社会的背景の両方を考慮する

How we got here process 割り当て 特定 インタビュー 分析 ミーティング 共有 こ こ に 至 る ま で の 経 緯

割り当て

ファシリテーターのアサイン • プロセスを進めるファシリテーターをアサインする • ファシリテーターに求められるもの • 献身的 • 本質的な物語を引き出す • インシデントのあらゆる視点が十分に表現され、かつ事後的な推測を排除することに注力

誰が調査すべき か？ • 関連するコンポーネントに対する基本的な知識を有している • 調査手法、インタビュー、およびポストインシデントレビューの実施について 訓練を受けている（または、訓練を受けた者とパートナーを組んでいる） • 責任追及の傾向を意識(Blame-aware)し、説明責任を重視したポストインシデントレビュープロ セスの確立または強化に尽力している • 調査の完了まで注力できる

調査すべきでない 人は？ • そのインシデントに直接関与していた • インタビュー対象者に対して権限を持つ立場にある • 組織的な知識を欠く新入社員である • レビューに慎重に対応する時間がない。

Blame-awareに進める Blameless(責任追及無し)からさらに踏み込んだ考え方 • 人間の本性として「責任の所在を明確にしたい」という傾向は自然な反応 • この傾向を完全に排除するのではなく、理解した上で乗り越えることで学習文化を促進 • 誰が関与したかについて話すことは許容される。しかし、その議論は制裁無しで行われ る。善意で行った行動ついて、誰も罰せられることはない • 個々の過ちでは無く、システム全体の問題点を特定することに重点が置かれる • 心理的安全性の促進。チームメンバーがインシデントについてオープンに議論できる安 全な環境を作る

特定

調査のためのデータソース • 人 • 対応者 • 管理者 • サポート • 開発ツールとレポーティングシステム • Runbook • ダッシュボード • ログ • メトリクス • テキスト • Slack • Teams • E-mail • 映像 • Zoom • Teams • Google Meet これらを時系列順に再構築する。事後の視点ではなく リアルタイムでの状況を再現

関係者のフォローアップを確認する

データを統合する データの統合に使えるもの • コラボレーションドキュメント • チケット • Jeli 作業をこなすのに役立つものであれば何でも使う。 ただし、データの収集に時間を費やし過ぎないように留意

インタビュー

誰と話すべきか • イベントの主要関係者 • 専門家(Subject Matter Experts) • 関与していないはずの人々 • 非難されていると感じている人 • 組織に新しく加わった人 • 関与していた、または状況を監視していたリーダー • 影響を受けたユーザー

質問のコツ • 信頼関係を築く • 人々に話をさせる – 専門家のような気分になってもらう • 一般的なことから具体的なことへ • ヒントを使う • 耳を傾け、調整する • 認知的な質問をする Cook (1999)

より充実した、より読まれるレポートのための 「正しい」質問方法 ● どのようにしてインシデントに巻き込まれましたか？ ● あなたが「なにかおかしい」と言ったとき、何を考えていましたか？ ● このような種類のインシデントに遭遇したとき、通常何を確認しますか？ ● なぜ○○さんを呼んだのですか？

「何故起きたのか？」 ではなく 「何故これが理にかなっていたのか ?」

「なぜこれが理にかなっていたのか」 • 「なぜこれが起きたのか 」「なぜ悪いことが起こったのか 」と聞かない • 「なぜこの方法で行うことが 理にかなっていた のか」と聞くべき • 誰も意図的に失敗しようとは思っていない。 みんな良かれとおもってやっている • 一歩下がって「なぜそれが理にかなっていたのか」 「なぜシステムがそれを許容するようになっていたのか」を考える • この「理にかなっていた」点を本当に理解しない限り、 同じ問題を繰り返してしまう

分析

分析の流れ • 収集したデータ（トランスクリプト、人物データ、アラートログ、オンコールスケジュール、 ダッシュボードなど）をタグ付けして整理し、分析の方向性を定める • イベントの経緯とタイムラインを作成する • 浮かび上がるテーマと残された主要な疑問点をメモする • 疑問に答えるために必要な追加データを特定する • （オプション）インタビュー対象者を特定し、準備を行う • 収集したデータとテーマをまとめる • 分析結果、裏付けデータ、テーマをレポートにまとめ、レビューや会議の指針とする

避けるべき落とし穴

避けるべき落とし穴 • 根本原因への過度な注目 • 「人的ミス」を原因とすること • 反事実的推論 (Counterfactuals)

ミーティング

アジェンダのサンプル プロセスの概要 物語(Narrative)の概要（検出、診断、修復、重要な局面 ) 技術に関する背景 主なテーマと質問 次のステップ

準備 • 事前に資料を配布する • 質問や回答を期待する場合は、その旨を事前に伝える。また、どのト ピックについて質問や回答を期待するかも伝える • 会議の各部分の議論を時間制限する。

議論のファシリテーション • 参加者に自分よりも多く発言させる。自分が専門家である必要はない • 準備を活かす • おとなしいグループには、基本に立ち返ってみる • おしゃべりなグループには、時間制限を設けてみる • 感情的になりやすいグループには、状況を和らげるようにする

アクションアイテムのまとめかた • 会議中にトラッキング • 会議後のフォローアップ • レポートで詳細に展開

共有

レポートに入れる情報 https://howie-guide.pagerduty.com/assets/HowWeGotHereReportGuide.pdf 物語的な説明: このセクションは何が起こったかの要約として機能するべきです。この文書を ざっと見る人でも、ここでこの情報の要約 を得られるようにすべきです。 イベント: 異常な（通常または予想されるものから逸脱した）イベントの 2-3文の説明。 顧客/従業員への影響: どこで？どのくらい？誰が影響を受けたか？どのように？どの KPIが影響を受けたか？ （UIの相互作用が関 与している場合、スクリーンショットが役立ちます！） トリガー: トリガーは通常無害（それ自体では害がない）であり、（貢献要因 /可能要因からの） 脆弱性を組み合わせてイベントにつなが ります。例：「ロールバックボタンが 押され、複数のユーザーが自分のワークスペースにアクセスできなくなった」。 この例では、ロール バックボタンを押すことがトリガーですが、ロールバックボタンを 押すこと自体は、通常脆弱性とは考えられません。 主要な学び/テーマ/質問: 誰かが1年後や2年後にこの文書を見たとき、何を持ち帰ってほしいですか？ 議論すべき重要な点として何 が目立ちましたか？ 貢献要因/可能要因: これらをインシデントが発生するために真実でなければならなかったこととして 考えてください。これらを「原因」や 関与した人々として考えないでください。 貢献要因と可能要因は、システムに潜在的に残っていた脆弱性を作り出します （時には長期 間にわたって！）。

レポートに入れる情報

書かれてファイリングされるだけのレポート • 多くの組織で見られるのは、「単なるチェックボックス作業」になってしまうこと • 「大変なインシデント対応の後に、また退屈なテンプレートを埋める作業があ るのか･･･。誰も見ないだろうけど、監査のためにやらなきゃ」

誰が知る必要があるか そのインシデントに関わっている人やチームだけでなく、以下のような人も考慮す る • 一次サポート • 依存関係にあるチーム • 将来のチームメンバー • プロジェクトマネージャー • 経営陣/意思決定者 調査結果を共有できる範囲が広ければ広いほど、学習の機会も増える。

ポストインシデントレビュー やっていきましょう

PagerDutyは、よりよいポストインシデントレビューを支 援します

Thank you