インシデントレビュー

インシデントレビューを書く主な目的は、インシデントを文書化し、寄与したすべての根本原因を十分に理解し、特に、再発の可能性や影響を減らすための効果的な予防措置を講じることです。¹

はじめに

インシデントレビューは、責任を追及しない文化の中で理解を深めるための極めて重要な機会です。その目的は、再発防止のアクションアイテムを集めることにとどまりません。インシデントの発生に寄与するシステムとエンジニアリング文化の両方について学ぶためのプロセスです。これらの要素がどのように機能し、相互に作用するかを話し合って分析することで、私たちが支える技術環境と、それが機能する組織全体の背景について、価値ある洞察を得られます。

GitLab では、責任を追及しないインシデントレビューの実践に取り組んでいます。つまり、責任を負わせたり、過失のある個人を特定しようとしたりするのではなく、インシデントの「なぜ」と「どのように」を理解することに意図的に焦点を当てます。インシデントレビューでは、直接の証言と価値ある背景情報を示すために、個人名やチーム名に言及する場合がありますが、こうした言及は責任を負わせることを決して意図していません。むしろ、一連の出来事、関連する意思決定プロセス、インシデント中に直面した課題をよりよく理解するための手段です。

私たちがこの責任を追及しないモデルを採用するのは、オープンなコミュニケーション、信頼、緊密なコラボレーションを促進するためです。これにより、誰もが報復を恐れずに自分の視点や所見を共有できます。

継続的な学習は、この責任を追及しないレビューで最も重要かつ最優先の焦点ですが、レビューには実務的な目的もあります。システムのレジリエンスと信頼性を高める、実行可能な改善策の特定と実施につながり、最終的にはエンジニアリング文化を強化し、ユーザーにサービスを提供する能力を向上させます。

テンプレート

• Review Initiator（ほとんどの場合は Incident Lead）は、インシデントの Slack チャンネルまたはインシデント Issue ダッシュボードで割り当てられたインシデント後タスクに従って、GitLab.com Production Tracker または Dedicated Issue トラッカーでインシデントレビュー Issue を作成します。
• インシデントレビューのテンプレートは、https://app.incident.io/gitlab/settings/post-mortem で編集できます。

ロール

すべてのインシデントレビューには、レビューを作成する Review Initiator、完了まで推進する DRI、完了を承認する Bar Raiser の 3 つのロールがあります。これらのロール以外にも、多くの参加者が RCA、是正措置、インシデントの詳細に貢献する場合があります。

Review Initiator

Review Initiator は、ほとんどの場合、Incident Lead です。すべての Severity::1 および Severity::2 のインシデントでは、Incident Lead がインシデント後タスクの一環としてレビュー Issue を作成する責任を負います。その他のすべてのインシデントでは、誰でもインシデント Issue に Review-Requested ラベルを適用し、自分でレビュー Issue を作成して、レビューを依頼できます。

Review Initiator は、適切なテンプレートを使用してレビュー Issue を作成し、初期メタデータを追加する責任を負います。これには以下が含まれます。

• 適切な Issue タイトルを設定する
• レビューをインシデントにリンクする
• レビューを担当する適切な DRI を見つけ、その人に Issue を割り当てる

DRI

サービスまたは機能を担当するチームがインシデントレビューの DRI です。例外はありません。Engineering Manager はレビューの推進をチームメンバーに委任できますが、最終的には EM がレビューを担当し、その完了に責任を負います。

DRI は、さらなる意見や詳細を得るために適切な人々を参加させ、話し合いに加わってもらうことで、レビューを推進する責任を負います。

サービスオーナーは、インシデントに直接関わっていなかった場合でも、そのサービスについて最も多くの背景情報を持ち、最終的にはサービスの信頼性を担当します。これにより、適切な人々が何が起きたのか、そしてなぜ起きたのかを理解できます。

DRI は次のことを行います。

• インシデントに関わった人々（EOC、IMOC、CMOC、その他のエンジニアやステークホルダー）を話し合いに参加させる
• 是正措置につながるさらなる洞察を得るため、掘り下げた質問をする
• 是正措置によって同様の問題の再発を防げるかを確認する。防げない場合は掘り下げを続け、レビューに関わる人の範囲を広げることを検討する。
• 是正措置、infradev Issue、またはインシデントから生じたその他のアクションや成果をリンクし、作成する。レビューを終了する前に、すべてのアクションをチームに割り当てる必要がある。
• 必要な場合は、公開 RCAを担当する
• レビューの初稿を作成した時点と、終了できる状態になった時点で、Bar Raiserのレビューを依頼する。誰に依頼するかについては、Bar Raiser の探し方を参照する。
• Bar Raiser の承認後、期限前にレビューを終了する。

Bar Raiser

Bar Raiser パネルは、すべてのインシデントレビューをレビューします。レビューを終了するには、Bar Raiser の承認が必要です。 レビューが Bar Raiser にどのように割り当てられるか、また Bar Raiser になる方法については、Bar Raiserページを参照してください。

Bar Raiser は、メンテナーがコードの基準を維持するのと同じように、インシデントレビューの高い基準を維持します。レビューの進め方を指示したり、何が間違っているかを伝えたりするためにいるのではありません。厳しい質問をし、他の人が考えなかった観点から掘り下げ、導き出された是正措置が理にかなっており、信頼性を向上させて再発を防ぐために本当に必要なものであることを確認する役割です。

Bar Raiser パネルは、インシデントレビューの DRI と同等の立場にあるメンバーのグループです。質の高いインシデントレビューがもたらす価値を熟知した Engineering Manager、Product Manager、Staff+ エンジニアで構成されます。

Bar Raiser は、参加しているインシデントレビューの推進や担当には責任を負わず、レビューが SLO を満たすようにする責任も負いません。それは DRI の責任です。

レビュー実施のガイダンス

以下は、すべての DRI が検討すべき質問であり、Bar Raiser が尋ねる可能性の高い質問です。該当する場合、インシデントレビューと、そこから生じる是正措置を通じて、答えが明確になっている必要があります。

1. 根本原因は明確に特定されているか？
2. 是正措置は根本原因の種類を反映しているか？
3. 適切なオブザーバビリティがあったか？
4. 適切なプロセスがあったか？
5. 変更について、適切なコントロールフローを通じてリリースしたか？
6. テストで見逃していたか？
7. どうすればより早く検知できたか？
8. どうすればより早く緩和できたか？
9. この具体的な影響の範囲外にも、同じように対処する必要がある領域はあるか？
10. 是正措置によって再発リスクを本当になくしたか？

すべての質問がすべてのインシデントに該当するわけではなく、レビューは記入するためのフォームではありません。質問が該当するにもかかわらず、レビューがそれに答えていない場合、その不足に最も価値のある是正措置が隠れていることがよくあります。

是正措置を根本原因の種類に合わせる

目の前の障害を修正するだけでは、ほとんどの場合十分ではありません。そもそも、その種類の問題が本番環境に到達することを許した要因にも、是正措置で対処する必要があります。それが何を意味するかは、特定した原因の種類によって異なります。

• コード変更: 何が欠陥の流出を許したのでしょうか？テストカバレッジ、コードレビュー、フィーチャーフラグの使用、段階的なロールアウト、カナリア、変更をどれだけ迅速に元に戻せたかを確認します。コード変更がインシデントを引き起こしたにもかかわらず、同様の欠陥が再び流出する可能性を減らす是正措置が 1 つもない場合、レビューは完了していません。
• インフラストラクチャまたは設定の変更: 変更は想定されたコントロールフローを通じて行われたか、レビューされたか、段階的に適用されたか、ロールバックできたか？
• 容量または飽和: 上限を把握していたか、監視していたか、障害発生時点ではなく発生前に余裕とアラートがあったか？
• 依存関係または外部サービス: グレースフルデグラデーションができたか、その依存関係に適したタイムアウト、リトライ、フォールバックがあったか？
• ユーザーが引き起こしたインシデント（悪意の有無を問わない）: 適切な上限があったか、ユーザーと原因を迅速に検知して特定できたか、問題を止めるためのツールがあったか？

同じ考え方が検知と緩和にも当てはまります。気付くまで、または復旧するまでに予想外の時間がかかった場合、それ自体が寄与原因であり、インシデントを引き起こした原因とは別の是正措置に値します。

インシデントレビューの完了

レビューは、次の条件を満たすと完了し、終了できます。

• DRI が経緯と RCA を完成させている
• 是正措置が作成され、適切なチームに割り当てられている
• Bar Raiser が承認している
• 必要な場合は、公開 RCAが公開されている

公開 RCA

Severity::1 のインシデントについては、お客様は公開 RCA ができる限り早く提供されることを期待しています。

公開 RCA は DRI が担当します。 これは別のチームへの独立した引き継ぎではありません。インシデントレビューを担当する同じ個人またはチームが、SLO内に公開版を提供する責任を負います。これには、Support や特定の Technical Account Manager との調整が含まれる場合があります。

社内のインシデントレビューをそのまま公開できる場合、DRI は直接公開するためにレビューを公開設定にします。RED データ、お客様を特定できる情報、セキュリティ上機微な詳細、または社内専用の背景情報が含まれるため公開できない場合、DRI は一般向けのレビューを作成し、同じ SLO内に公開する責任を負います。社内向けと公開向けのレビューを別々に用意する必要があることは、期限に間に合わない理由にはなりません。

公開版にも、何が起きたのか、どのような影響があったのか、何が原因だったのか、再発を防ぐために何を行うのかをお客様に伝える必要があります。公開版は短く、社内向けの内容が少ない文書であって、曖昧な文書ではありません。

GitLab Dedicated の場合、外部 RCA はさらに Dedicated の外部 RCA プロセスに従います。このプロセスでは、お客様へのリリース前に追加のコミュニケーション承認が必要になる場合があります。

一般的な根本原因分析のハンドブックページも参照してください。

週次インシデントレビュー会議

週次インシデントレビュー会議は、インシデントレビューが完了しているかどうかにかかわらず、前週に発生したすべての重大度の高いインシデントをレビューするワーキングセッションです。

• 頻度: 毎週
• 対象者: すべての Engineering Manager と個人貢献者が参加できます。議論の対象となるインシデントを担当する DRI チームの代表者には、参加が求められます。
• 対象範囲: 前週に発生したすべての Severity::1 および Severity::2 のインシデント

この会議は、Operational Excellenceのインシデント詳細分析を補完します。Operational Excellence では、完了した少数のインシデントレビューを Engineering のリーダー陣とレビューします。一方、週次インシデントレビューでは、レビューがまだ進行中の段階で、EM と IC が最近のインシデントについて学び、意見やフィードバックを提供する場を設けます。この会議で得られたフィードバックは、進行中のインシデントレビューに直接反映でき、反映すべきです。

会議での議論は、非同期レビューや Bar Raiser の承認に代わるものではありません。DRI は、関連する議論をインシデントレビュー Issue に要約して記載する責任を負います。

レビューを開始する基準

1. ユーザーに影響する重大度の高いすべてのインシデント（Severity::1 および Severity::2）では、レビューが必要です
2. インシデント Issue に Review-Requested ラベルが追加されたすべてのインシデント
3. インシデント自体の範囲を超える詳細情報が必要なすべてのインシデント

お客様との連携

インシデントレビューでは、Technical Account Manager（TAM）などの連絡窓口を通じて、お客様との連携が必要になる場合があります。 レビューで判明した事項についてお客様が同期ミーティングでの議論を求める場合、TAM は重要なステークホルダーとの話し合いを調整するため、Infrastructure の管理職と連携できます。

担当チームのないサービス

担当するチームが存在しないサービスもあります。担当が不明確な場合は、サービスに最も近い、または最も詳しいチームが名乗り出てレビューを担当することが求められます。

レビューの完了に期待されるタイムライン

インシデントレビューは、インシデント解決後 5 営業日以内に終了することが求められます。お客様は、Severity 1 のインシデントについて、インシデント解決後 7 日以内に公開 RCAが提供されることを期待できます。社内では、私たちはより厳しい SLO を自らに課しています。想定される完了日を把握してください。

ページのソースコードを見る - ページの編集 - please contribute.