Close

インシデント管理改善への道はここから始まります

インシデント管理ホーム

インシデントの事後分析

アトラシアンでは、重大度レベル 2 以上のすべてのインシデントの根本原因の理解と修正を確かなものとするために、誰も責めることのない事後分析を行っています。これは、アトラシアンの事後分析の方法を説明する内部資料の要約版です。

インシデント管理ハンドブック

ハンドブックの印刷版または PDF 版を入手する

インシデント管理ハンドブックの印刷版は、数量限定で無料配布しています。または、PDF 版をダウンロードしてください。


事後分析とは何か

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

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

アトラシアンでは、事後分析の完了と承認を確実にするために、すべての事後分析を 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. チームに「何がうまくいったか、もっとうまくできることは何だったか、どこが運が良かったか」を質問します。

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

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

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

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

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


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

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

フィールド

説明

インシデントの概要

インシデントを数行に要約する。重大度、原因、影響が続いた期間を含める。

<日付><インシデントの時間範囲。14:30 から 15:00 など><数> 名の顧客に <イベントの症状> が発生した。イベントは、<デプロイの時間またはインシデントの原因となった変更> 時にデプロイがきっかけで発生した。デプロイには、<変更の理由または説明> によるコードの変更が含まれた。このデプロイのバグが <問題の説明> の原因となった。

このイベントは <システム> によって検出された。このイベントは <解決のために取られた行動> によって緩和された。

この <重大度レベル> のインシデントは X% の顧客に影響した。

このインシデントに関して <サポート チケットとソーシャル メディアの投稿の数> 件が提出された。

きっかけ

このインシデントを引き起こした状況を説明する。例:以前の変更で潜在的なバグが発生した。

<日付><時刻> (<顧客に影響が出る前の期間>) に <製品またはサービス><インシデントを引き起こした変更の説明> の変更が行われた。この変更が、<変更の影響の説明> の原因となった。

不具合

何が期待どおりに動作しなかったのかを説明する。不具合に関係するグラフやデータを添付する。

<数> 件の応答が、<期間> の間に X% のリクエストに誤って送信された。

影響

インシデント中に内部および外部の顧客に何が起こったかを説明する。提出されたサポートケースの数を含める。

<日付><時間> から <時間> の間に <インシデントの概要> が発生した。

このインシデントは、<数> 名の顧客(すべての <システムまたはサービス> の顧客の X %)に <顧客に起こった状況を説明> の影響があった。

<サポートチケットとソーシャルメディアの投稿の数> 件が提出された。

検出

アトラシアンが、いつ、どのようにインシデントを検出したか?

検出までの時間を改善する方法は?思考の訓練として、この時間を半分にするには?

このインシデントは、<アラートのタイプ> がトリガーされ、<呼び出しを受けたチームまたは個人>が呼び出されたときに検出された。その後 <第二対応者またはチーム> を呼び出すことになった。これは、ディスク書き込みサービスの担当でなかったので、対応が <期間> 遅れたためである。

<改善点の説明> は、<改善の影響> が得られるように <改善を担当するチーム> によって設定される。

回答

誰が、いつ、どのように対応したか?対応に遅延や障壁はあったか?

14 時 34 分(UTC 時間)に呼び出しを受けた KITT エンジニアが 14 時 38 分にインシデントチャットルームに入室した。しかし、待機エンジニアに Escalator autoscaler に関して十分な背景知識がなかったため、14 時 50 分に再度アラートを送信し、14 時 58 分に上級 KITT エンジニアがチャットルームに入室した。

リカバリ

いつ、どのようにサービスが復旧されたかを説明する。影響を緩和する方法にどのようにたどり着いたか?

状況に応じて追加の質問をする。例:緩和までの時間を改善するにはどうすればいいか?思考の訓練として、この時間を半分にするには?

以下の 3 方面からの対応により復元を行った。

  • BuildEng EC2 A5G の容量を拡大し、ワークロードを処理できるノード数を増やす。また、定数を超えたノードのスケジューリングの可能性を減らす。

  • クラスタの積極的なスケールダウンを防ぐために、Escalator autoscaler を無効にする。

  • Build Engineering スケジューラーを前のバージョンに戻す。

タイムライン

インシデントのタイムラインの詳細を、時系列でタイムゾーンを含むタイムスタンプ付きで提供する。

インシデントのすべてのきっかけ、影響のはじまり、検出時間、エスカレーション、決定、変更、影響の終了を含める。

すべての時間は UTC で表示。

11:48 - K8S 1.9 制御プレーンの更新完了
12:46 - Goliath の V1.9 への更新完了(クラスターオートスケーラーと BuildEng スケジューラーインスタンスを含む
14:20 - Build Engineering が KITT Disturbed へ問題を報告
14:27 - KITT Disturbed が特定の EC2 インスタンス(ip-203-153-8-204)の不具合を調査開始
14:42 - KITT Disturbed が特定のノードを遮断
14:49 - BuildEng が問題が 1 つ以上のノードに影響を及ぼしていることを報告。問題の 86 のインスタンスが不具合はシステムに関することを示す
15:00 - KITT Disturbed がスタンダードスケジューラーへの切り替えを提案
15:34 - BuildEng が 300 ポッドの不具合を報告
16:00 - BuildEng がすべての不具合のあるビルトを除去し、OutOfCpu レポートを作成

16:13 - 新しいビルドでも不具合が再発するため、一時的な不具合ではないことを BuildEng が報告。
16:30 - KITT がこの不具合がインシデントだと認め、インシデントとして対応。
16:36 - KITT が Escalator autoscaler を無効にし、問題を軽減するために autoscaler が計算を削除しないようにする。
16:40 - KITT は ASG が安定し、クラスターの負荷は正常で、顧客の影響が解決したことを確認。

なぜなぜ分析

根本原因を特定するテクニックを使う。

影響を出発点として、なぜ起こったのか、なぜその影響があったのかを質問する。根本原因にたどり着くまで「なぜ」を質問し続ける。

「なぜ」をリストアップするか、作図して課題に添付する。

  1. サービスが停止した。なぜかというと、データベースがロックされたから。

  2. なぜかというと、データベースの書き込みが多すぎたから。

  3. なぜかというと、サービスに変更があり、増加を予想していなかったから。

  4. なぜかというと、テスト変更をいつロードするべきか、開発プロセスで設定していないから。

  5. なぜかというと、以前にロードテストをしたことがなく、規模が今までにないレベルに到達しているから。

根本原因

根本原因は何か?このクラスのインシデントの再発を防ぐために、変更する必要がある物事。

<バグの原因またはバグが起こったサービス> 接続プールの処理時のバグが、接続状態への不十分な視認性と組み合わさり、障害状態での接続リークを引き起こした。

バックログチェック

バックログの中に、このインシデントを防止できたものや影響を軽減するものはあったか?そうであるなら、なぜそれをしなかったのか?

正直な評価は、過去の優先順位とリスクに関する決定を明確にするのに役立つ。

特になし。フロータイピングへの改善は、決まったやり方がある既知の継続中のタスクであった(例:ファイルを変更または作成するときにフロータイプを追加する)。統合テストを修正するためのチケットは作成されたが、試行時に失敗した。

再発

同じ(根本原因の)インシデントは以前にも起きたことがあるか?その場合、なぜ、また再発したのか?

同じ根本原因のインシデントは、HOT-13432、 HOT-14932、HOT-19452。

教訓

何を学んだか?

何がうまくいったか、何をもっとうまくできたか、運がよかった点について話し合い、改善の機会を探る。

  1. 作業のレートリミッタが適切に維持されていることを確認するために、ユニットテストを実施する必要がある。

  2. 通常の操作とは異なる一括操作ワークロードを見直すべきである。

  3. 一括操作はゆっくり開始して監視する必要がある。サービス指標が正常であれば増やしていく。

是正措置

このクラスのインシデントが再発しないためには何をすればいいのか? 誰がいつ行動を起こすか?

「優先行動」課題を作成して、追跡している各行動にリンクする。

  1. 不具合を制限するため、一時的にオートスケールのレート制限を手動にする。

  2. ユニットテストとジョブのレート制限の再導入をする。

  3. スケーリング効果を導くために、クラスタ全体の分散率情報を収集する二次的メカニズムを導入する。

  4. AWS ES ではオートスケールが行われないため、大規模な移行は調整する必要がある。

  5. Stride 検索がまだ階層 2 に分類されているか検証する。

  6. xpsearch-chat-searcher が失敗したときに、完全ではなく部分的に失敗するように pf-directory-service にチケットを提出する。

  7. CloudWatch アラートを使用して ElasticSearch クラスタの高 IO 問題を特定する。


直接原因と根本原因

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

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

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

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

シナリオ 直接原因と行動 根本原因 根本原因の緩和

Stride の「Red Dawn」スクワッド サービスに Datadog モニターとオンコール アラートがなかった、またはそれらが適切に設定されていなかった。

チームメンバーが新サービスに監視とアラートを設定していなかった。

それらのサービスの設定を行う。

監視とアラートを含む、新サービスの立ち上げプロセスが設けられていない。

新サービスの立ち上げプロセスを作成し、それに従うようにチームに指示する。

このブラウザバージョンでは動作しないファブリックエディターにアップグレードされたため、Stride が IE11 では使用できない。

依存関係のアップグレード。

アップグレードを元に戻す。

ブラウザ間の互換性テストの欠如。

継続的なブラウザ間の互換性テストの自動化。

Micros EU のログがログサービスに届いていなかった。

Micros に提供されたログを送信する役割が正しくなかった。

役割を修正する。

ある環境からのログが機能しているかどうか判別できない。

すべての環境に対して、ログの欠落用の監視とアラートを追加する。

以前の AWS インシデントによって、Confluence Vertigo ノードがメディアへの接続プールを使い果たし、顧客に断続的な接続とメディアエラーが発生した。

AWS の不具合。

AWS の事後分析を取得する。

Confluence 接続プールの処理時のバグが、接続状態への不十分な視認性と組み合わさり、障害状態での接続リークを引き起こした。

バグを修正し、今後、影響が起きる前に同様の状況を検出するための監視機能を追加する。


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

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

カテゴリー

用語の定義

取るべき行動

根絶

アトラシアンによるコードの変更(具体的な変更の種類)

テストする。カナリアテストを行う。インクリメンタルロールアウトを実行し、ウォッチする。機能フラグを使う。品質エンジニアに相談する。

変更

アトラシアンによる変更(コード以外)

変更の方法を改善する。変更の見直し、管理プロセスを変更するなど。「バグ」関連のすべてがここに該当する。

拡張性

スケールの失敗(例:リソースの制約に対して盲目的、容量計画の欠如。

サービスのリソースの制約は何か?監視とアラートを実施していたか?容量計画がなければ、作成する。容量計画があれば、どのような新しい制約を考慮する必要があるか?

アーキテクチャ

運用条件による設計のズレ

設計の見直しをする。プラットフォームの変更は必要か?

依存関係

第三者(アトラシアン以外)のサービスの不具合

第三者の不具合のリスクを管理しているか?リスクを受け入れる経営判断をしたか?または、緩和策を構築する必要があるか?以下の「依存関係と根本原因」を参照。

不明

確認できない(診断能力を高めるための行動)。

ログ、監視、デバッグおよび同様の機能を追加して、システムの観測可能性を改善する。


依存関係のある根本原因

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

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

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

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

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

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


事後分析の行動

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

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

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

カテゴリー 確認事項

このインシデントの調査

「何がこのインシデントを引き起こす原因となったか?」根本原因を特定することが最終的な目標。

ログ分析、要求パスの図表、ヒープダンプの見直し

このインシデントの緩和

「この特定のイベントを解決して管理するため、まず実施した行動は何か?」

ロールバック、チェリーピッキング、設定のプッシュ、影響を受けたユーザーとのコミュニケーション

このインシデントのダメージを修復

「このインシデントの即時のまたは二次的なダメージをどのように解決したか?」

データの復元、機械の修理、トラフィックの再ルートの削除

将来のインシデントの検出

「同じような不具合を正確に検出するための時間を短縮するにはどうすればいいか?」

監視、アラート、入力と出力の妥当性チェック

将来のインシデントの緩和

「今後、このようなインシデントの重大度や継続時間をどのように減少させるか?」

「同じような不具合が次に発生したときに、影響するユーザーの割合をどうすれば減らすことができるか?」

グレースフルデグラデーション、重要ではない結果の取り下げ、フェールオープン、ダッシュボードまたはプレイブックで現在のプラクティスを拡大、インシデントプロセスの変更

将来のインシデントの防止

「このようなインシデントの再発をどのように防止するか?」

コードベースの安定性の改善、より完全なユニットテスト、入力検証とエラー状態のロバスト性、プロビジョニングの変更

事後分析行動を言葉で表現する方法についても、Lueder 氏と Beyer 氏のアドバイスを活用しています。

事後分析行動の表現方法:

事後分析行動を適切に表現できるかどうかで、事後分析行動を容易に完了できるか、あるいは実行不可能または先延ばしが原因で無制限に遅れるといった違いが生じる可能性があります。よく練られた事後分析行動には以下のような特性が必要です。

実現性:動詞で始まる文で各行動を説明します。行動`はプロセスではなく、有益な結果につながるべきです。例えば、「重要な依存関係を一覧表にする」は良い表現ですが、「依存関係の調査」は良い表現ではありません。

明確さ:各行動の範囲をできるだけ絞り込んで定義し、何がその作業に含まれているか、含まれていないかを明確にします。

制限:行動に終わりを設けない、または継続中にするのではなく、各行動がいつ終了となるかをはっきりと表現します。

...から ...まで

このシナリオの監視を調査する。

(実現性)すべてのケースでサービスからのエラーの戻り率が 1% 以下になるようにアラートを追加する。

機能停止の原因になった課題を修復する。

(明確さ)ユーザー住所入力フォームの無効な郵便番号を安全に処理する。

エンジニアが更新前にデータベーススキーマを解析できるか確実にチェックできるようにする。

(制限)スキーマの変更に対する提出前の自動チェック機能を追加する。


事後分析の承認

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

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

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

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


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

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

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

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

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

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

落ち着いて続けましょう

これでインシデントハンドブックは終わりです。お読みいただきありがとうございました。

フィードバックや提案がありましたら、incident-handbook@atlassian.com 宛にメールにてご連絡ください。