インシデント対応
障害発生時の検知・初動対応・エスカレーションなど、インシデント対応の基本的な流れを学ぶ
インシデント対応の流れ
インシデント対応は、思いつきで動くのではなく一定の流れに沿って進めることで、 混乱した状況でも冷静に対処できます。
1. 検知
アラートやユーザー報告により異常を把握する
2. トリアージ(重大度判定)
影響範囲とビジネスへの影響度から、対応の緊急度を判定する
3. 初動対応(影響の緩和)
ロールバックやフィーチャーフラグ無効化など、まず影響を止める
4. エスカレーション
必要な専門知識を持つ担当者やステークホルダーへ連絡する
5. 収束・復旧確認
指標が正常範囲に戻ったことを確認し、インシデントの終息を宣言する
6. 事後対応
ポストモーテムを実施し、再発防止策を計画する
まず影響を止める: 緩和優先の原則
障害対応で陥りやすい罠は、根本原因を完全に理解するまで対応を保留してしまうことです。 ユーザーへの影響が続いている間は、原因の完全な特定よりも影響を止めることを優先します。
# 即応できる緩和策の例
- 直前のデプロイが疑わしい → まずロールバックする
- 特定の新機能が原因と疑われる → フィーチャーフラグで無効化する
- 特定の外部依存先が不調 → サーキットブレーカーで切り離し、縮退運転に切り替える
- 特定エンドポイントへの過剰な負荷 → レート制限を一時的に強化する根本原因の追求はその後で
影響を止めてユーザーへの被害が収まった後、落ち着いてログやトレースを調査し、 根本原因を特定してから恒久対応を行います。急いで根本対応まで一気に行おうとすると、 さらなる不具合を生むリスクが高まります。
役割分担: インシデントコマンダー制
大規模な障害では、複数人が同時に調査・対応にあたることで混乱が生じがちです。インシデントコマンダーを1人立て、 全体の状況把握・意思決定・コミュニケーションの調整役に専念させることで、 他のメンバーは調査や修正作業に集中できます。
- インシデントコマンダー: 状況の統括、意思決定、対応の優先順位付け
- 調査担当: ログ・メトリクス・トレースを見て原因を切り分ける
- コミュニケーション担当: ステータスページの更新や社内外への状況共有を行う
エスカレーションとコミュニケーション
対応中は、社内の関係者やサポートチームに向けて定期的に状況を共有します。 「まだ調査中」であっても沈黙するのではなく、「何がわかっていて、何がわかっていないか」 「次にいつ更新するか」を明示することで、問い合わせの集中や不安の増大を防げます。 外部向けのステータスページがある場合は、そこにも同様の情報を反映します。
ポイント
- 検知→トリアージ→初動対応→エスカレーション→収束→事後対応の流れを意識する
- 根本原因の完全な特定より先に、影響を止める緩和策(ロールバック等)を優先する
- インシデントコマンダー制で役割を分担し、混乱を防ぐ
- 調査中でも定期的な状況共有を行い、関係者の不安や問い合わせ集中を防ぐ
確認クイズ
1 / 3直前のデプロイが原因と疑われる障害が発生した際、最初に取るべき対応はどれか？