インシデントの事後分析

事後分析とは何か

事後分析は、インシデントの説明を書面で記録したものです。

• インシデントの影響
• インシデントを緩和または解決するための行動
• インシデントの根本原因
• インシデントの再発を防止するためのフォローアップ行動

アトラシアンでは、事後分析の完了と承認を確実にするために、すべての事後分析を Jira 課題を使って追跡しています。ニーズが複雑ではない場合は、各事後分析に Confluence ページのような単純なシステムを使うこともできます。

なぜ事後分析をするのか？

事後分析の目的は、すべての根本原因の理解、今後の参考とパターンを見つけるための記録作成、再発の可能性または影響を軽減するのに有効な予防措置を設定することです。

事後分析で効果的にインシデントの再発を防ぐには、レビュー プロセスによってチームが根本原因の特定と修正を行う動機を示さなければなりません。正しい方法はチームの文化によって異なりますが、Atlassian のインシデント対応チームで有効性が判明している方法の組み合わせをご紹介します。

• 対面ミーティングは、適切な分析を促し、どのような修正が必要か、チームが同じ認識を持つのに役立ちます。
• デリバリーチームと運用チームのマネージャーによる事後分析の承認は、チームが事後分析を徹底的に行う動機を与えます。
• 指定の「優先行動」には合意済みの Service Level Objective（SLO）があり、サービスによって 4 週間または 8 週間の期間で、完了したことを確認するリマインダーとレポートを提出します。

このプロセスに加わり、その効果を確実なものとするには、組織のあらゆるレベルでのコミットメントが必要です。当社のエンジニアリングディレクターとマネージャーは、それぞれの分野で解決行動を担当する承認者と SLO を決定しました。このシステムは、彼らの決定をコード化して実行を試みるものにすぎません。

いつ事後分析が必要なのか？

重大度 1 と 2 のインシデントで事後分析を実施します。それ以外の場合、事後分析は省略可能です。

課題の解決中または解決直後に、事後分析の担当者が新しい事後分析課題を作成します。

誰が事後分析を完了するのか？

不具合のあるサービスのデリバリーチーム（インシデント課題上の「不具合のあるサービス」を担当しているチーム）が、事後分析を完了する責任を持ちます。チームは事後分析担当者を選んで、彼らに事後分析課題を割り当てます。

• 事後分析担当者は、起案や承認から事後分析が公開されるまでのすべての指揮をとり、事後分析の完了に対する説明責任を負います。
• 事後分析承認者（1 名以上）は、事後分析をレビューして承認します。バックログ内でフォローアップ行動の優先順位を設定することが期待されます。

Confluence ページには、サービスグループごとに（必須および任意の）事後分析承認者が一覧表示されます。サービスグループは一般的にアトラシアン製品に対応しています（例：Bitbucket Cloud）。

どのように事後分析行動を追跡するのか？

事後分析で実施される行動は以下のとおりです。

• チームが所有しているバックログに Jira 課題を提起します。すべての事後分析行動は、Jira で追跡しなければなりません。
• 事後分析課題から「優先行動」（根本原因の修正のため）または「改善行動」（根本原因以外の原因の改善のため）として事後分析行動をリンクします。

重大度ごとに、事後分析の優先行動で修正されていない根本原因の数を追跡するカスタムレポート機能が、Jira REST API を使用して構築されています。各部署のエンジニアリングマネージャーは、定期的にこのリストを見直します。

事後分析プロセス

事後分析プロセスには、事後分析課題の作成、事後分析ミーティングの実施、行動の記録、承認の取得、結果の報告（任意）が含まれます。

事後分析担当者は、以下のタスクの実行に責任を持ちます。

1. 事後分析を作成してインシデントにリンクします。
2. 事後分析課題を編集し、フィールドの説明を読み、フィールドを完成させます。
3. インシデントの根本原因を特定するため、「5 つの Why」テクニックを使用して、真の根本原因にたどり着くまで因果関係を遡ります。
4. 事後分析ミーティングをスケジュールします。ミーティング招待テンプレートを使用して、デリバリーチーム、影響を受けたチームおよび関係者をミーティングに招待します。
5. チームと面会し、下に記載するミーティングスケジュールを実施します。
6. 担当の開発マネージャーとフォローアップを行い、このクラスのインシデントを予防するための具体的な行動に対するコミットメントを得ます。
7. チームが担当するバックログに記載の各行動に対して Jira 課題を提起します。事後分析課題から「優先行動」（根本原因の修正）または「改善行動」（その他の改善事項）として事後分析行動をリンクします。
8. Confluence で適切な承認者を調べて、事後分析の [承認者] フィールドに追加します。
9. 「承認リクエスト」へのトランジションを選択して、指名した承認者からの承認をリクエストします。承認者への指示とともに、コメントが自動で課題に加えられます。
10. 事後分析が承認されるまで必要に応じてフォローアップします。
11. 事後分析が承認されると、Confluence に事後分析ブログの下書きが自動的に作成されるので、それを編集をして公開することができます。事後分析をブログで公開し、苦労して学んだことを共有することで、その価値が何倍にも高まります。

事後分析プロセスが完了すると、チームの SLO に従って、通常のバックログの一環として開発チームが各行動に優先順位を付けます。

事後分析ミーティング

アトラシアンでは、チームで集まって学んだことを話し合うことで、根本原因をより深く分析できることを発見しました。チームが分散型であるため、このようなミーティングの多くはビデオチャットで行われます。また、インシデントに多数のスタッフが関与している場合は、複数のグループで行います。

推奨されるアジェンダ

1. チームに、事後分析では誰も責めないこと、およびその理由を伝えます。
2. イベントのタイムラインを確認します。
3. 根本原因を確認します。
4. 「開かれた考え方」を使って行動を考えます。例えば、「今後、このクラスのインシデントを防ぐために何ができるでしょうか？」ということを話し合います。
5. チームに「何がうまくいったか、もっとうまくできることは何だったか、どこが運が良かったか」を質問します。

カレンダーの予約に使える推奨テンプレート：

<インシデントへのリンク> について、誰かのせいにしない事後分析を行いますのでぜひ参加してください。<インシデントの概要>

事後分析の目的は、すべての根本原因の理解、今後の参考とパターンを見つけるための記録作成、再発の可能性または影響を軽減するのに有効な予防措置を設定することです。

この会議では、インシデントの根本原因を特定して緩和するための行動を決定します。

開発担当マネージャーが在席していない場合は、優先順位の決定には適さない状況なので、ミーティングで具体的なアクションにコミットすることは避けてください。人々は完全な情報がない中でコミットすることにプレッシャーを感じてしまいます。その代わりに、ミーティング後に担当マネージャーとフォローアップを行い、特定された優先行動を確定することに対してコミットメントを得ます。

事後分析の課題フィールド

事後分析課題には広範囲にわたる入力フィールドがありますので、事後分析ミーティングを行う前に、インシデントに関するすべての重要情報を収集することが推奨されます。以下に、フィールドの入力方法の例を示します。

直接原因と根本原因

事後分析の作成や確認を行うときは、直接原因と根本原因を区別する必要があります。

• 直接原因は、このインシデントを引き起こした直接の原因です。
• 根本原因は、変更することでこのようなインシデントを完全に防ぐことができる、一連のイベントの中で最も効果的な場所にある原因です。

事後分析では、根本原因を発見して、それらを緩和するための最適な方法を決定することを目指します。一連のイベントの最適な場所を見つけるのが、本当の事後分析の技術です。5 つの Why のようなテクニックを使って「原因を遡る」ことで、根本原因を見つけます。

以下に、直接原因と根本原因の例を示します。

根本原因のカテゴリーとその行動

これらのカテゴリを使用して根本原因をグループ化し、それぞれに対する適切な行動について説明します。

依存関係のある根本原因

依存関係の不具合でサービスにインシデントが発生した場合、どこに不具合があるか、どのような根本原因があるかは、依存関係がアトラシアン内部であるか第三者であるかによって異なります。また、依存関係のパフォーマンスの妥当な期待値も関係します。

内部の依存関係の場合は、「依存関係の Service Level Objective（SLO）は何か？」を質問します。

• 依存関係は SLO を侵害していますか?
  • 不具合は依存関係によるものなので、信頼性を高める必要があります。
• 依存関係は SLO の範囲内なのにサービスが停止しましたか?
  • サービスは復元力を高める必要があります。
• 依存関係に SLO が設定されていませんか？
  • SLO が必要です！

第三者との依存関係の場合は、「第三者との依存関係の可用性や待ち時間などに対する妥当な期待値 * はどのぐらいか？」を質問します。

• 第三者との依存関係は（悪い意味で）期待値を上回りましたか？
  • 期待値が間違っていました。
    • 再発しない自信はありますか？例：RCA を見直し、同意します。この場合、アクションは RCA です。
    • または、期待値を調整する必要がありますか？この場合、回復力を高め、期待値を調整する必要があります。
    • 調整した期待値が受け入れられなかった場合、要求と解決策の食い違いをなんとかして解決する必要があります。例えば、他の供給元を見つけるなどです。
• 第三者との依存関係は期待値の範囲内なのにサービスが停止しましたか?
  • この場合、サービスは復元力を高める必要があります。
• 期待値を設定していませんでしたか？
  • 第三者との依存関係の担当者は、期待値を確立してチームと共有する必要があります。それによって、彼らの依存するサービスに、どれぐらいのレベルの復元力をビルドする必要があるかを知ることができます。

*なぜ「期待値」なのでしょう? 第三者と SLA に合意しているはずです。現実には、第三者と契約した SLA は不具合や緩和策を特定するには役立ちません。たとえば、AWS は EC2 向けの SLA をほとんど公開していません。そのため、第三者のサービスを利用する必要がある場合は、提供される信頼性、可用性、パフォーマンスのレベルやその他の主要な指標について、どの程度期待することが妥当であるかを意思決定する必要があります。

事後分析の行動

Google の Sue Lueder 氏と Betsy Beyer 氏が、事後分析のアクション アイテムについて素晴らしいプレゼンテーションと記事を作成しています。アトラシアンでもこれを使用してチームに指示を行っています。

PIR が短期的および長期的な修正の両方を確実にカバーできるように、以下の質問に取り組んでください。

「将来のインシデントの緩和」と「将来のインシデントの防止」が根本原因に対処する可能性が最も高い行動です。確実にどちらか一つは行えるようにしましょう。

事後分析の承認

アトラシアンでは、事後分析が確実に承認されるために、Jira ワークフローと承認ステップを使用します。承認者は、一般的にサービス所有者またはサービス運用に責任を持つマネージャーです。事後分析の承認は、以下のことを示しています。

• 根本原因を含めて、インシデント後のレビューで明らかになったことに同意する
• リンクされた「優先行動」が根本原因への対応として容認できることに同意する

承認者が追加の行動を要求したり、提案された行動によって対処されない因果関係の特定を依頼することが多くあります。このように、承認はアトラシアンの事後分析プロセスに多くの価値を追加します。

インシデントがほとんど発生しない、またはインフラストラクチャが複雑ではないチームの場合、事後分析の承認は必要ない場合もあります。

誰も責めることのない事後分析

うまくいかなかったときに、誰かのせいにしたいと思うのは人間にとって自然なことです。それを回避するのが、アトラシアンの最大の関心事です。事後分析を実行する際は、これを意識的に克服する必要があります。私たちは、スタッフの善意を前提とし、スタッフの失敗を決して非難しません。事後分析は、正直かつ客観的に障害を引き起こした状況を調べる必要があります。それによって、正しい根本原因を見つけ、緩和することができます。スタッフを非難することは、以下の理由によって根本原因を見つける妨げになります。

• スタッフが同僚の視線の中で自分の立場や将来的なキャリアにリスクを感じた場合、これらの感情は通常「自分の雇用主である企業の最大の利益」よりも個人的な順位の中で上回り、自分の基本的なニーズを守るために、必然的に真実を偽ったり、隠したりします。
• もし、一人のスタッフがインシデントに直接つながる行動をしたとしても、「なぜ x（個人名）さんはこれをしたのですか？」と聞くべきではありません。「なぜそれができるようなシステムだったのか、または、なぜこれが正しいことだと信じてしまったのか？」というような質問の仕方をします。
• 個人を非難するのは不親切であり、執拗に繰り返された場合は恐怖と不信感の文化が形成されます。

この事後分析のテクニックは、すべての参加者の個人の安全を確保するために使用されます。

• 事後分析会議を始めるときに、この事後分析は誰かを糾弾するものではないこと、またその理由を宣言します。
• 個人を指し示す場合は、名前ではなく役割（例：待機ウィジェットエンジニア）を使います（事実については明確かつ明瞭なまま）。
• 事後分析タイムライン、因果連鎖、緩和策が、個人ではなく、システム、プロセス、役割の文脈で枠付けされていることを確認します。

誰も糾弾しない事後分析のインスピレーションと、有益な「セカンドストーリー」のコンセプトは、John Allspaw 氏の独創的な記事から来ています。