インシデント管理

インシデント管理

インシデントとは、サービスの低下やアウテージを引き起こす—または引き起こす可能性のある—異常な状態です。これらのイベントは、サービスの中断を防いだり、運用状態にサービスを復旧させたりするために、人的介入を必要とします。 インシデントには_常に_即座の対応が行われます。

インシデント管理の目標は、混乱した状態を素早いインシデント解決へと整理することです。そのために、インシデント管理は以下を提供します。

1. 対応チームが確実にインシデントを解決できるメンバーを常駐させるためのオンコール体制
2. インシデントチームメンバーのための明確に定義された役割と責任およびワークフロー
3. 情報の流れと解決経路を管理するためのコントロールポイント
4. 教訓とテクニックを抽出・共有するためのインシデントレビュー

インシデントが開始すると、インシデント自動化ツールが対応するインシデントアナウンスチャンネルにテキストベースのコミュニケーション用インシデント専用 Slack チャンネルへのリンクを含むメッセージを送信します。 インシデントチャンネル内に、インシデント専用の Zoom リンクが作成されます。 さらに、Production トラッカーに GitLab Issue がオープンされます。

インシデント管理ライフサイクル

GitLab では、インシデント管理を以下のステップからなるフィードバックループとして取り組んでいます。

1. 準備 — インシデントに関わる可能性があるすべての人へのプロセスのドキュメント化と適切なトレーニング。適切なモニタリングとアラートが整備されており、適切な人がオンコールローテーションに含まれていることを確認することが含まれます。
2. 識別 — インストゥルメンテーション/アラート/モニタリング、顧客報告、チームメンバー報告、またはセキュリティ報告を通じて問題を特定します。特定されたらインシデントが宣言されます。
3. 調査 — アウテージ/サービス中断の原因を調査し、影響の初期評価を行い、重大度レベルを決定します。
4. 封じ込め — 影響を封じ込め、できる限り迅速にサービスを安定させます。封じ込めが達成されたら、インシデントは「軽減済み」とみなされます。
5. 修復 — サービスの安定化に向けたより堅固な対応。すべての異常な状態が解消されたとき、インシデントは修復済み、つまり「解決済み」とみなされます。
6. 回復 — テストとドキュメントの改善。インシデントの再発防止や将来の対応時間を改善するために特定された是正措置は、このフェーズで開始される場合があります。
7. 学習 — 根本原因分析、インシデントレビュー/レトロスペクティブ、および追加の是正措置の特定。これらはすべてステップ1のドキュメントとトレーニングの更新にフィードバックされ、フィードバックループを閉じます。

モニタリングとアラートの概要については、モニタリングハンドブックページをご覧ください。必要に応じて開発チームの専門知識を得るための開発エスカレーションプロセスも活用しています。

メトリクス

インシデントのパフォーマンスは、ターゲットメトリクスのセット（MTTR、30分以内に軽減された割合、内部検知率など）に対して追跡されます。定義、スコープ、ダッシュボードへのリンクはインシデントメトリクスページに記載されています。

スケジュールされたメンテナンス

C1 のスケジュールされたメンテナンスは、未宣言のインシデントとして扱う必要があります。

メンテナンスウィンドウ開始の30分前に、変更を担当するエンジニアリングマネージャーは、SRE オンコール、リリースマネージャー、CMOC に対してメンテナンスが間もなく開始することを通知する必要があります。

調整とコミュニケーションは Situation Room Zoom で行い、メンテナンスに問題が発生した場合に他のエンジニアを迅速かつ簡単に参加させられるようにします。

メンテナンス手順中に関連するインシデントが発生した場合、EM はインシデントの期間中インシデントマネージャーとして行動する必要があります。

メンテナンス手順中に無関係の別のインシデントが発生した場合、スケジュールされたメンテナンスに関与しているエンジニアはアクティブなインシデントのために Situation Room Zoom を退出する必要があります。

スケジュールされたメンテナンス中に短時間のエラーが予想される場合は、関連するステータスページへの更新を通じてユーザーに通知する必要があります。メンテナンスの期間をサービスレベル契約へのダウンタイムとしてカウントしないようにするため、メンテナンスウィンドウを設定する必要もあります。

オーナーシップ

インシデントリードの役割はすべてのインシデントに対して意図的に設定する必要があります。インシデントのオーナーを決定する際に助けが必要な場合は、EOC が支援できます。 インシデントリードは、いつでも別のエンジニアにオーナーシップを委任したり、IM にオーナーシップをエスカレートしたりできます。 インシデントのオーナーは常に1人のみであり、インシデントのオーナーのみがインシデントを解決済みと宣言できます。 インシデントリードはいつでも階層の次の役割にサポートを求めることができます。インシデントリードの役割は常に現在のオーナーにアサインされている必要があります。

インシデント管理の構造

GitLab では、インシデント管理フレームワークが2つの重要な概念を区別しています。

1. インシデント対応の役割（Incident Response Roles）：これらはインシデント対応中に必要な機能的な役職であり、誰が担うかに関わらず特定の責任と行動によって定義されます。現在、3つの定義された役割があります：インシデントリード、インシデントレスポンダー、コミュニケーションマネージャー。

2. 対応チーム（Response Teams）：これらはこれらの役割を担当する特定のチームとローテーションです。異なる対応チームは異なる環境（例：GitLab.com 対 Dedicated）または専門機能をカバーする場合があります。

この区別を理解することで、インシデント中に誰が何をするかが明確になり、インシデント管理プロセス全体での適切な調整が確保されます。

インシデント対応の役割 対 チームについて詳しく見る

インシデント対応の役割

インシデント中は責任の明確な区分が重要です。迅速な解決には、タスクの委任に関する集中力と明確な階層が必要です。重複を防ぎ、適切な操作順序を確保することが軽減に不可欠です。

対応チーム

オンコールスケジュールを維持することで、インシデントを解決できるチームメンバーが常に確保されています。

オンコールのチームメンバーがページングされると、インシデントに参加し、上記のインシデント対応の役割のいずれかを担当します。

オンコールのプロセスとポリシーの詳細はオンコールハンドブックページをご覧ください。

以下はインシデント解決をサポートするオンコールローテーションの概要です。

Tier 1

自動化システムによって通知されるオンコールローテーション：

低重大度のインシデントでは、ページングされた個人が複数の役割を担う場合があります。例えば、S4 インシデントでは EOC がインシデントリードとインシデントレスポンダーの両方の職務を担当することがあります。重大度が上がるにつれて、単一の個人がこれらの役割を担うことがより重要になります。Tier 2 の個人をページングする必要が出てきます。

Tier 2

人間によって通知されるオンコールローテーション：

役割とチームのマッピング

このテーブルは、インシデント対応中にどのチームが通常どの役割を担うかを示しています。

詳細な役割責任

インシデントリードの責任

インシデントリードは、インシデントが進行し更新され続けることを確保する責任があります。この役割は自動的に設定されるものではなく、インシデントの種類に基づいてアサインされるべきです。インシデントリードのアサインに関する詳細はワークフローセクションをご覧ください。インシデントリードは必要に応じて EOC や IMOC などの他の関係者を積極的に招集することが求められます。

インシデントリードの責任のより詳細な内訳をご覧ください。

インシデントレスポンダーの責任

インシデントレスポンダーとは、インシデントの技術的な調査と解決に貢献するすべての人を指します。EOC チームは通常主要なレスポンダーとして機能しますが、関連する専門知識を持つ GitLab チームメンバーであれば誰でも支援のために呼び出される可能性があります。

インシデントレスポンダーの責任のより詳細な内訳をご覧ください。

コミュニケーションリードの責任

コミュニケーションリードは、ステータスページの更新管理、ステークホルダー通知の調整、そして外部顧客への影響が確認された重大インシデントに関するタイムリーな公開コミュニケーションの確保を通じて、重大インシデント中の GitLab の公式な声として機能します。

複数のチャンネルにわたる調整されたコミュニケーションを必要とする重大インシデントでは、IMOC はインシデントの期間中コミュニケーションリードを頼ります。

コミュニケーションリードの責任のより詳細な内訳をご覧ください。

詳細なチーム責任

Engineer On Call (EOC) の責任

Engineer On Call は通常、主要なインシデントレスポンダーとして機能し、宣言されたインシデントの影響軽減と解決を担当します。EOC はサポートが必要な場合や他の人がインシデント調査の支援に必要な場合は IMOC に連絡する必要があります。

EOC はインシデントレスポンダーの責任を確認してください。

Incident Manager On Call (IMOC) の責任

Incident Manager On Call は通常、インシデントリードとして機能し、インシデント中の戦術的なリーダーシップと調整を担当します。

IMOC はインシデントリードの責任とコミュニケーションリードの責任の両方を確認してください。インシデントリードは多くの低重大度インシデントでコミュニケーションリードとしても機能する場合があるためです。

シフトのスケジュール方法や PTO や補償が必要な場合の一般的なシナリオについての一般的な情報は、インシデントマネージャーオンボーディングドキュメントをご覧ください。

Infrastructure Leadership の責任

Infrastructure Leadership は、Engineer On Call (EOC) と Incident Manager On Call (IMOC) の両方のエスカレーションパスに含まれています。 これはアクティブな IMOC の代替や置き換えではありません（現在の IMOC が利用不可の場合を除く）。

Infrastructure Leadership に直接ページングするには、/inc escalate を実行し、Oncall Teams ドロップダウンメニューから dotcom leadership escalation を選択します。

以下の状況でページングされます。

1. #cto Slack への更新提供を目的とした、すべての S1 インシデント。
2. IMOC が 15 分以内にページに応答できない場合。
3. 複数の進行中インシデントが EOC を圧迫している場合、または複数の SRE 間での調整が必要な場合、Infrastructure Leadership をページングして回復の調整と追加支援の招集を支援してもらえます。

ページングされた際、Infrastructure Leadership は以下を実施します。

1. インシデントコールに参加します。
2. インシデントレスポンダーに追加の SRE からの支援が必要かどうか確認します。
3. IMOC が職務を果たせることを確認します。
4. インシデントレスポンダーが完全に修復に集中できるよう、IMOC/CMOC の主要な技術的接点となります。
5. 進行中のすべての S1 インシデントについて #cto Slack チャンネルへの更新を提供します。

CTO へのアップデート

Infrastructure Leadership は、GitLab.com および GitLab Dedicated インシデントの両方について、インシデント開始時、重要なステータス変更時（「調査中」から「修正中」など）、およびインシデント解決時に #cto Slack チャンネルへのアップデートを行う必要があります。 アップデートは GitLab.com 用に使用されている標準の incident.io Summary フォーマットに従い、通常はインシデントサマリーからコピー＆ペーストできます。 既存のサマリーが不十分な場合は、@incident Slack bot にインシデントの executive summary のドラフト作成を依頼できます。

:s1: **GitLab.com でのインシデント**

**問題**:
（高レベルのサマリーを含む）
**影響**:
（どのサービス/アクセス方法と何割のユーザーに影響しているかを含む、ユーザーへの影響を説明）
**原因**:
（判明している場合は原因のリスト）
**対応戦略**:
（問題を修復するために何をしているか）
**— Production Issue —**
主なインシデント: （インシデントへのリンク）
Slack チャンネル: （インシデント Slack チャンネルへのリンク）

チームコーディネーター

インシデントマネージャーコーディネーター

1. 毎月第1火曜日頃：
   • コーディネーターは IM オンボーディング/オフボーディングボードの ~IM-Onboarding::Ready と ~IM-Offboarding のオープンな Issue をレビューし、これらのチームメンバーをスケジュールに追加します。
   • スケジュールは incident.io の Incident Manager - GitLab SaaS スケジュールを編集して更新されます。
   • スケジュールを編集する際は、各ローテーションの変更が有効になる時間を設定することを確認してください（通常は最初の月曜日の UTC 00:00）。
2. MR へのリンクと追加または削除された人の簡単な概要とともにスケジュールが変更されたことを示すアナウンスが #im-general に投稿されます。
3. IM オンボーディング/オフボーディングボードのすべての Issue は、期限超過の確認のために月に1回レビューする必要があります。 期限を過ぎた Issue がある場合、コーディネーターはオンボーディングを完了するためにより多くの時間やサポートが必要かどうかを確認するために作成者にチェックインする必要があります。

Engineer On-Call コーディネーター

EOC コーディネーターは、SRE オンコールの生活の質を向上させ、会社全体のオンコールエンジニアが高い自信のレベルで運用できるようにプロセスを設定することに焦点を当てています。

この役割の責任：

1. EOC の生活の質向上に役立つプロセスとツールのギャップを特定し、PI を通じて把握する。
2. 定期的なトレーニングとワークショップを調整する。
3. インシデントレビューと注目すべきインシデントのフォローアップとして、SRE 間の知識移転を可能にする。
4. SaaS Platforms 内の他のチームとの調整と優先度設定を通じて、インシデント管理に関するより大きな変更を推進する。

EOC コーディネーターはコアなオンコールとインシデント管理の懸念事項について Ops チームと密接に連携し、必要に応じて組織全体の他のチームと関わります。

参考資料

その他のエスカレーション

必要に応じて Infrastructure Platforms チームからさらなるサポートが利用できます。 Infrastructure Platforms リーダーシップは PagerDuty Infrastructure Platforms Escalation で連絡できます（詳細はチームページをご覧ください）。 Delivery リーダーシップは PagerDuty で連絡できます。Delivery グループページのリリース管理エスカレーション手順をご覧ください。

インシデント軽減方法 - EOC/インシデントマネージャー

1. S1 または S2 インシデント中に広範なユーザーへの影響が確認された場合、EOC としてインシデントを軽減するために必要に応じて—さらなる許可なしに—ユーザーをブロックする権限があります。インシデントへのリンクと、ユーザーがブロックされた理由をさらに説明するメモを含むサポートガイドラインの Admin Notes に関して必ず従ってください。
   1. ユーザーがブロックされた場合、さらなるフォローアップが必要になります。これはインシデント中に、または時間的制約に応じて軽減後に実施できます。
      1. アカウントのアクティビティが不正使用と見なされる場合、アカウントを永久にブロックして後処理するためにTrust and Safety にユーザーを報告してください。イベントの性質によっては、EOC は SIRT チームへの連絡も検討する場合があります。
      2. そうでない場合は、関連する機密インシデント Issue を作成して CMOC にアサインし、ユーザーに一時的にアカウントをブロックしなければならなかった理由を説明してもらいます。
      3. EOC がユーザーのトラフィックが悪意のあるものかどうかを判断できない場合は、SIRT チームに調査を依頼してください。

インシデントマネージャーを招集するタイミング

以下のいずれかが当てはまる場合は、インシデントマネージャーを招集することをお勧めします。

1. S1/P1 レポートまたはセキュリティインシデントがある。
2. GitLab.com アプリケーションのパス全体または機能の一部をブロックする必要がある。
3. GitLab.com プロダクションシステムへの不正アクセスがある。
4. 他の SRE への委任を支援するために 2 件以上の S3 以上のインシデントがある。

注意: インシデントの重大度が上がった場合（例：S3 から S1 に）、incident.io は自動的に EOC、IMOC、CMOC にページングします。

複数のインシデントが同時発生した場合の対処

時折、同時に複数のインシデントが発生することがあります。場合によっては、1人のインシデントマネージャーが複数のインシデントをカバーできます。これは特に、重要なアクティビティを伴う2件の同時高重大度インシデントがある場合は不可能なことがあります。

複数のインシデントがあり、追加のインシデントマネージャー支援が必要と判断した場合は、以下のアクションを取ってください。

1. #im-general と適切なインシデントアナウンスチャンネルに追加のインシデントマネージャー支援を求める Slack メッセージを投稿します。
2. Slack 経由でリクエストに対応がない場合は、/inc escalate を使用して Infrastructure Leadership にエスカレートします。

週末のエスカレーション

EOC は週末でもアラートへの対応が期待されています。インシデントが ~severity::1 または ~severity::2 でない限り、軽減に時間を費やすべきではありません。~severity::3 と ~severity::4 インシデントの軽減は月曜日から金曜日の通常業務時間中に実施できます。ご質問がある場合はインフラストラクチャエンジニアリングマネージャーにお問い合わせください。

~severity::3 と ~severity::4 が複数回発生し週末作業が必要な場合、複数のインシデントを単一の severity::2 インシデントにまとめるべきです。 重大度の判断に支援が必要な場合は、EOC とインシデントマネージャーは /inc escalate を通じて Infrastructure Leadership に連絡することをお勧めします。

インシデントマネージャーエスカレーション

EOC（Engineer On Call）がページに応答しない場合、ページはインシデントマネージャー（IM）にエスカレートされます。 このエスカレーションは incident.io を経由するすべてのアラートで発生し、低重大度のアラートも含まれます。 大量のページがあり EOC がページの確認に集中できない場合にこれが発生する可能性があります。 この場合、IM は対応するインシデントアナウンスチャンネルで EOC が支援を必要としているかどうかを確認するために Slack で連絡を取る必要があります。

例：

@sre-oncall、エスカレーションを受け取りました。LINK_TO_INCIDENT_ESCALATION を調査できますか、それとも何か支援が必要ですか？

EOC が利用不可のために応答しない場合は、incident.io アプリケーションを使用してインシデントをエスカレートし、インフラストラクチャエンジニアリングリーダーシップにアラートを送信する必要があります。

対応チームを招集する方法

インシデント中にインシデントレスポンダー（EOC）、IMOC、またはコミュニケーションマネージャー（CMOC）を招集する必要がある場合は、以下のいずれかの方法でオンコール担当者にページングします。これにより PagerDuty インシデントまたは incident.io エスカレーションがトリガーされ、選択したImpacted Service に基づいて適切な担当者にページングされます。

• Slack で /inc escalate コマンドを使用し、以下のチームに基づいて Oncall team ドロップダウンメニューから正しいチームを選択します。

顧客との直接対話が必要なインシデント

S1 または S2 インシデント中に、1人または複数の顧客と同期的な会話を持つことが有益と判断された場合、その会話には新しい Zoom ミーティングを使用すべきです。通常、このアクションにつながる2つの状況があります。

1. 顧客が GitLab.com をどのように使用しているかについての洞察が解決策の発見に価値のある、単一または少数の顧客に特有に影響するインシデント。
2. 主要な顧客と同期的な会話を持ちたい、追加の更新を提供したり追加の質問に回答するような、マルチ時間の完全停止や地域的な DR イベントなどの大規模なインシデント。

関係するオーバーヘッドと影響軽減の取り組みから注意を逸らすリスクから、このコミュニケーションオプションは慎重に使用し、非常に明確かつ明白なニーズがある場合にのみ使用すべきです。

インシデントの直接顧客対話コールの実施は、現在のインシデントマネージャーが以下の手順を取ることで開始されます。

1. 顧客コールに専念する2人目のインシデントマネージャーを特定します。インシデントにまだいない場合は、/here A second incident manager is required for a customer interaction call for XXX のようなメッセージで #im-general でニーズをアナウンスします。
2. 追加の支援と認識のためにInfrastructure Leadership ローテーションにページングします。
3. 顧客コールに専念するカスタマーサクセスマネージャー（CSM）を特定します。この役割が明確でない場合は、Infrastructure Leadership にも確認します。
4. これらの追加の役割をメインのインシデントに参加させてインシデントの履歴と現状を把握するよう依頼します。軽減への集中を維持するために必要な場合は、この情報共有を別の Zoom ミーティングで行うことができます（その後、顧客との会話にも使用できます）。

インシデントの履歴と現状を把握した後、エンジニアリングコミュニケーションリードは以下のアクションで顧客対話を開始・管理します。

1. 新しい Zoom ミーティングを開始し—すでに進行中のものがない限り—プライマリ CSM を招待します。
2. エンジニアリングコミュニケーションリードと CSM は、GitLab と自分の役割（CSM、Engineering Communications Lead）を示すように Zoom 名を適切に設定します。
3. CSM を通じて、ディスカッションに必要な顧客を招待します。
4. エンジニアリングコミュニケーションリードとインシデントマネージャーは、会話間で正確な情報が流れるよう非同期更新を優先する必要があります。このためにインシデント Slack チャンネルの使用を検討しますが、顧客コールが始まる前に合意してください。
5. エンジニアリングコミュニケーションリードと CSM の両方は、インシデントに必要な全時間、顧客との Zoom に留まる必要があります。コンテキストの損失を避けるため、どちらも内部インシデント Zoom と顧客対話 Zoom を行き来すべきではありません。

シナリオによっては、インシデントのほぼすべての参加者（EOC、他の開発者など）が顧客と直接作業する必要がある場合があります。この場合、インシデント Zoom ではなく顧客対話 Zoom を使用します。これにより、会話（およびテキストチャット）が可能になりながら、一次対応者がインシデント Zoom で内部コミュニケーションを素早く再開する機能も維持されます。

是正措置

是正措置（CA）はインシデントの結果として作成する作業アイテムです。 インシデントから生じた Issue のみが ~"corrective action" ラベルを受け取るべきです。 これらは同種のインシデントを防止したり軽減までの時間を改善するために設計されており、インシデント管理サイクルの一部です。 是正措置はダウンストリームの分析を支援するためにインシデント Issue に関連付ける必要があります。

Production Engineering プロジェクトの是正措置 Issue は、フォーマット、ラベル、完了のためのサービスレベル目標の適用/モニタリングの一貫性を確保するために是正措置 Issue テンプレートを使用して作成する必要があります。

~"corrective action" ラベルを持つ Issue には自動的に ~"infradev" ラベルが適用されます。 これは、これらの Issue が特定の期間内に解決するための開発と同じプロセスに従うためです。 詳細についてはinfradev プロセスをご覧ください。

是正措置 Issue を作成する際のベストプラクティスと例

• SMART 基準を使用してください：具体的（Specific）、測定可能（Measurable）、達成可能（Achievable）、関連性のある（Relevant）、期限付き（Time-bounded）。
• 発生したインシデントへのリンクを貼ってください。
• 関連するインシデントの最高重大度を示す重大度ラベルをアサインしてください。
• 作業の緊急性を示す優先度ラベルをアサインしてください。デフォルトでは、インシデントの重大度と一致させてください。
• 該当する場合は、関連する影響を受けたサービスのラベルをアサインしてください。
• 是正措置 Issue のプロジェクト内のどのエンジニアでも Issue を引き継いで次のステップを知ることができるよう、十分なコンテキストを提供してください。
• 以下のような是正措置の作成は避けてください：
  • 過度に一般的（「具体的」に反する、最も典型的な間違い）
  • インシデントの症状のみを修正する。
  • 人的エラーをさらに増加させる。
  • インシデントの再発防止に役立たない。
  • 迅速に実装できない（期限付きに反する）。
• 例：（いくつかのベストプラクティス Postmortem ページから引用）

ランブック

ランブックはオンコールのエンジニアが利用できます。プロジェクトの README には上記の各役割のチェックリストへのリンクが含まれています。

GitLab.com のアウテージが発生した場合、ランブックリポジトリのミラーが https://ops.gitlab.net/gitlab-com/runbooks の Ops インスタンスで利用できます。

現在の EOC は誰ですか？

@sre-oncall ハンドルを使用して現在の EOC を確認してください。

現在の EOC に連絡するタイミング

現在の EOC は Slack の @sre-oncall ハンドルで連絡できますが、このハンドルは以下のシナリオでのみ使用してください。

1. デプロイメントパイプラインを停止する支援が必要な場合。注：これはインシデントを報告することで、カスタムフィールド「Blocks Deployments」を「Yes」に設定することでも達成できます。
2. 変更管理プロセスを通じてプロダクション変更を実施しており、必要なステップとして EOC の承認を求める必要がある場合。
3. その他の懸念事項については、サポート依頼セクションをご覧ください。

EOC は Slack での @sre-oncall ハンドルの使用にできるだけ早く応答しますが、状況によっては直ちに対応できない場合があります。緊急の場合や即時の応答が必要な場合は、インシデントの報告セクションをご覧ください。

インシデントの報告

GitLab チームメンバーで GitLab.com に関連する可能性のあるインシデントを報告したい場合は、以下の手順に従ってインシデントを宣言してください。EOC がオンラインになりインシデントについてあなたと関与するまでオンラインのままでいてください。ご協力ありがとうございます！

Slack でインシデントを報告する

GitLab の Slack で /incident または /inc と入力し、プロンプトに従ってインシデント Issue をオープンしてください。 確信が持てない場合でも、より高い重大度を選択してプロダクション問題のインシデントを宣言することをお勧めします。 高重大度のバグをこのプロセスで報告することが推奨されており、必要に応じて適切なエンジニアリングチームを確保できます。

インシデント宣言 Slack ウィンドウ

インシデント宣言結果

GitLab インシデント Issue のオープンに加えて、専用のインシデント Slack チャンネルがオープンされます。incident.io は対応するインシデントアナウンスチャンネルにこれらすべてのリソースへのリンクを投稿します。インシデント宣言の結果として作成・リンクされたインシデント Slack チャンネルに参加し、オンコールエンジニアとインシデントについてディスカッションしてください。S3 または S4 を宣言して EOC の支援が必要な場合は、Slack チャンネルで /inc escalate と入力してエスカレートしてください。

アウテージ 対 低下 対 中断の定義とコミュニケーションのタイミング

これは Status.io の用語によるサービス中断（アウテージ）、部分的なサービス中断、パフォーマンス低下の定義の初版です。 データはKey Service Metrics Dashboardのグラフに基づいています。

アウテージとパフォーマンス低下インシデントは次の場合に発生します。

1. 低下：サービスが文書化された Apdex SLO を下回るか、文書化されたエラー率 SLO を上回る5分間継続する状態。
2. アウテージ（ステータス = 中断）：エラー率グラフのアウテージラインを超える5分間継続するエラー率。

低下またはアウテージのどちらの場合も、イベントが5分を経過したら、EOC とインシデントマネージャーは外部コミュニケーションのために CMOC を招集する必要があります。5分以上継続するすべてのインシデント（「一瞬」のインシデントを含む）は、インシデント発生から1時間以内にできるだけ早く公開で通知する必要があります。

SLO は runbooks/rules に記載されています。

GitLab.com の低下または中断を確認するには、以下のグラフを確認します。

1. Web サービス
   • エラー率
   • Apdex
2. API サービス
   • エラー率
   • Apdex
3. Git サービス（公開向けの git インタラクション）
   • エラー率
   • Apdex
4. GitLab Pages サービス
   • エラー率
   • Apdex
5. Registry サービス
   • エラー率
   • Apdex
6. Sidekiq
   • エラー率
   • Apdex

部分的なサービス中断とは、GitLab.com のサービスまたはインフラストラクチャの一部のみがインシデントを経験している状態です。部分的なサービス中断の例としては、GitLab.com が通常通り運用されているが以下のような場合があります。

1. CI/CD ペンディングジョブの遅延
2. リポジトリミラーリングの遅延
3. マージリクエストなど特定の機能に影響する高重大度バグ
4. git リポジトリのサブセットに影響する1つの gitaly ノードでの不正使用または低下。これは Gitaly サービスメトリクスで確認できます。

高重大度バグ

高重大度バグの場合でも、インシデントを報告する経由でインシデントを作成することをお勧めします。これにより、イベントと対応を追跡するインシデント Issue が作成されます。

進行中または予定されているデプロイメントに高重大度バグがある場合は、デプロイメントをブロックする手順に従ってください。

セキュリティインシデント

インシデントがセキュリティに関連する可能性がある場合は、Slack で /security を使用してセキュリティエンジニアオンコールを招集してください。詳細はセキュリティエンジニアオンコールの招集をご覧ください。

コミュニケーション

情報はインシデントの影響を受けるすべての人にとっての資産です。情報の流れを適切に管理することは、驚きを最小限に抑え、期待値を設定するために不可欠です。適切に計画できるよう、関心のあるステークホルダーにタイムリーに進展を通知することを目指しています。

この流れは以下によって決まります。

1. 情報の種類
2. 対象となる読者
3. タイミングの重要性

さらに、すべてのステークホルダーの焦点を維持するために情報過多を避けることが必要です。

そのために、以下を設けています。

1. すべてのインシデント用の専用 Zoom コール。Zoom コールへのリンクは、対応するインシデントアナウンスチャンネルに投稿されたインシデント Slack チャンネルで確認できます。
2. 複数ユーザーの入力が必要な場合に共有テンプレートに基づく Google Doc。
3. 内部更新のためのインシデントアナウンスチャンネル。
4. 様々なメディア（例：Twitter）に配信される status.io 経由での status.gitlab.com への定期的な更新。
5. Infrastructure のワークロードを保持するキューとは別に、インシデントや変更に関する Issue 専用のProduction リポジトリ。

インシデントアナウンスチャンネル

インシデントがアナウンスされる専用のインシデント Slack チャンネルが3つあります。

• #incidents：すべてのインシデントがここでアナウンスされます。
• #incidents-dotcom：すべての .com インシデントがここでアナウンスされます。
• #incidents-dedicated：すべての Dedicated インシデントがここでアナウンスされます。

ステータス

status.gitlab.com を更新する status.io を使用してインシデントのコミュニケーションを管理しています。status.io のインシデントには state と status があり、CMOC によって更新されます。

status.io でインシデントを作成するには、Slack で /woodhouse incident post-statuspage を使用できます。

セキュリティインシデント中のステータス

場合によっては status.io への投稿を行わないことを選択する場合があり、投稿/ツイートをスキップする例を以下に示します。場合によっては、セキュリティ更新をリリースするまでセルフマネージドインスタンスのセキュリティを保護するのに役立ちます。

• パスのURLの部分ブロックが可能な場合、例えばパスの問題のある文字列を除外する場合。
• 過去1週間のログ検索で GitLab.com での URL の使用がない場合。

ステートとステータス

ステートとステータスを遷移するための定義とルールは次のとおりです。

ステータスはステートとは独立して設定できます。これらが一致しなければならない唯一の場面は Issue が

重大度

インシデントの重大度

インシデントの重大度は、組織全体での適切な対応を確保するためにインシデントの開始時にアサインする必要があります。インシデントの重大度はその時点で利用可能な情報に基づいて決定すべきです。重大度はより多くの情報が入手可能になるにつれて調整できる、また調整する必要があります。重大度レベルはインシデントが持った最大影響を反映し、インシデントが軽減または解決された後もそのレベルを維持する必要があります。顧客への影響または GitLab への影響の基準のいずれかが満たされた場合、その行の重大度をアサインすべきです。

インシデントマネージャーと EOC は、インシデントの重大度をアサインするためのガイドとして次のテーブルを使用できます。

アラートの重大度

1. アラートの重大度は必ずしもインシデントの重大度を決定するわけではありません。単一のインシデントは様々な重大度のいくつかのアラートをトリガーする場合がありますが、インシデントの重大度の決定は上記の定義によって駆動されます。
2. 時間をかけて、特定の SLO に対する個々のアラートを集約できるサービスレベルのモニタリングを通じて、インシデントの重大度の決定を自動化することを目指しています。

インシデントデータ分類

GitLab のデータ分類標準には4つのデータ分類レベルが定義されています。

• RED データはインシデントに含めるべきではありません（Issue が機密であっても）。
• ORANGE および YELLOW データは含めることができ、インシデントを管理するインシデントマネージャーはインシデント Issue が機密としてマークされているか内部メモにあることを確認する必要があります。

インシデントマネージャーは注意を払い最善の判断を行う必要があります。可能な限り Issue 全体を機密としてマークするのではなく、内部メモを使用することを好みます。 数行の無味な log データはデータセキュリティの懸念を表すものではないかもしれませんが、より大きなセット（ログ、クエリ、その他のデータ）にはより制限的なアクセスが必要です。

インシデントワークフロー

サマリー

インシデントのライフサイクル全体は incident.io を通じて管理されます。すべての S1 と S2 インシデントはレビューを必要とし、他のインシデントもこちらで説明されている基準に従ってレビューできます。

インシデントは報告され、低下が終了して再発しないと判断されたときに解決されます。

インシデントリード

インシデントリードは、インシデントが進行し更新され続けることを確保する責任があります。この役割はインシデント開始後に意図的にアサインされます。 リードはインシデントの種類に基づいて選択すべきです。例えば：

• 低複雑度インシデント：影響を受けるシステムに最も精通したチームメンバーがリードすべきです（多くの場合、報告者）。
• 高複雑度インシデント：調整要件から IMOC（Sev1/2）または EOC（Sev3/4）が通常リードすべきですが、プロダクトエンジニアとエンジニアリングマネージャーもこの役割を担うことができます。
• Delivery 関連インシデント：リリースマネージャーがリードに適していることが多い。
• セキュリティインシデント：セキュリティチームメンバーが通常リードすべき。

タイムライン

インシデントのタイムラインは、ページ下部のアクティビティセクションで「Highlights」を「All Activity」に変更することで incident.io ウェブインターフェースのインシデントで確認できます。 インシデントチャンネル内の Slack 投稿に :pushpin:（📌）または :star（⭐）の絵文字リアクションをすることで、アイテムをタイムラインに追加できます。:pushpin: でリアクションすると、GitLab インシデント Issue に公開コメントが残ります。:star: でリアクションすると、GitLab インシデント Issue に内部コメントが追加されます。Slack メッセージに添付された画像は incident.io タイムラインに追加されますが、GitLab Issue には投稿されません。

ラベリング

インシデントのステータスを説明するために GitLab ラベルのみを使用することはなくなりました。インシデントの信頼できる唯一の情報源は incident.io です。 ただし、incident.io はインシデントのステートに基づいていくつかのラベルを設定します。

ワークフローラベリング

その他のインシデントラベル

これらのラベルは、メトリクスと追跡のためのメタデータを追加するメカニズムとしてインシデント Issue に追加されます。

重複

既存のインシデントと重複するインシデントが作成された場合、それを適切な主要インシデントにマージするのは EOC 次第です。 インシデントはオープンなインシデントにのみマージできるため、必要に応じてインシデントを一時的に再オープンする必要がある場合があります。

フォローアップ Issue

GitLab Issue は incident.io で「Follow-up」が作成されたときに自動的に作成されます。任意の GitLab Issue は、リンクをインシデント Slack チャンネルに貼り付けることでフォローアップアイテムとして追加できます。 フォローアップアイテムはデフォルトでincident-follow-ups プロジェクトに作成され、インシデント終了後に適切なプロジェクトに移動する必要があります。

ワークフロー図

  graph TD
    A(インシデントが宣言される) --> |初期重大度がアサインされる| B(Active->Investigating)
    A -.-> |重複の場合| Z(Merged)
    B --> |"修正が特定された"| C(Active->Fixing)
    C --> |"修正がデプロイされた"| D(Active->Monitoring)
    D --> |"インシデントが解決された"| E(Resolved)
    E --> |"S1 または S2"| F(Post-Incident Review)
    E --> |"S3 または S4"| G(Incident Closed)

ニアミス

ニアミス（「near hit」または「close call」）とは、インシデントを引き起こす可能性があるが、実際にはインシデントに至らない予期しないイベントです。

背景

米国では、Aviation Safety Reporting System が 1976 年から near call の報告を収集しています。ニアミスの観察とその他の技術的改善により、致死事故率は約 65% 低下しました。 出典

John Allspaw が述べているように：

ニアミスはワクチンのようなものです。それらはプロセス中に誰かや何かを傷つけることなく、会社が将来のより深刻なエラーに対してより良い防御を構築するのに役立ちます。

ニアミスの処理

ニアミスが発生した場合は、通常のインシデントと同様の方法で処理する必要があります。

1. まだオープンされていない場合は、インシデント Issue をオープンします。実際にインシデントが発生していた場合に適切な重大度ラベルでラベル付けします。インシデント Issue に ~Near Miss ラベルを付けます。
2. 是正措置は実際のインシデントと同じように扱う必要があります。
3. インシデントレビューのオーナーシップはニアミスに気づいたチームメンバーにアサインするか、適切な場合は、ニアミスがどのように発生したかについて最も知識のあるチームメンバーにアサインします。

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