誰が何をすればいいか即わかる！「迷わない」インシデント対応フローの作り方
こんにちは！PIVOTプロダクトチームのエンジニアをしている、楠瀬（@indiamelaaa）です。
リリースしたサービスに不具合が発生したとき、どのように対処していますか？
「うわ、やばい…！」と焦ってバタバタしてしまい、対応が後手に回ってしまうことはありませんか？
私たちも以前は、インシデントが起こるたびに「どうやって情報共有をすればいいの？」「誰がいつまでに対応すればいいの？」と混乱しがちでした。せっかくなら同じ失敗は繰り返したくないですよね。
そこで私たちは、インシデント対応のフローを仕組み化して、いつ起こっても冷静に対処できるように整備しました。
この記事では、私たちが実際に行なっているインシデント対応フローについてご紹介します。インシデント対応を円滑に進めるためのヒントやポイントを、ぜひ参考にしてみてください。
仕組み化の背景
フローを決めるまでは、インシデントが起こった際に、次のような課題に直面していました。
対応が属人化してしまう
「誰が何をするべきか」が曖昧で、ひとりのメンバーに対応が集中してしまう
初動対応が遅れがち
問題を検知してから共有や優先順位付けを行うまでに時間がかかり、被害が拡大してしまう
こうした課題を解消するため、インシデント対応のフローを明確化し、誰でも迷わず動ける仕組みを作ることにしました。
インシデントとは
そもそも「インシデント」とは何を指すのでしょうか？
「システムが落ちてユーザーが使えなくなった」「セキュリティ侵害が起こった」などが代表的な例ですが、ここでは一般的なインシデントの考え方と、私たちのチームが定義しているインシデントの基準をそれぞれご紹介します。
一般的なインシデント
定義や言い回しは規格やガイドラインによって異なりますが、共通して以下の状態を指しています。
「サービス運用が正常に行えない、あるいは行えなくなる恐れがある状態」
障害だけではなく、運用に影響を与える可能性があればインシデントに含まれるのが大きなポイントです。
私たちが定めたインシデントの定義
私たちのチームでは、もう少し具体的に以下のように定義しています。
「1人以上のユーザーが通常運用できない、または企業の収益に影響を及ぼす問題・障害」
具体例としては以下のようなケースです。
ユーザーがサービスにアクセスできない（ログイン不可、画面が真っ白で操作不能など）
セキュリティ上のリスクがあり、ユーザーや企業の信用を損ねる可能性がある
動画の視聴データが欠損し、収益に関わる分析ができない
「一般的なインシデントの考え方」をベースにしつつ、自社サービスにとって重要な要素を明確化することで、「これはインシデントだ」と誰でもすぐに判断できるようにしています。
インシデント対応フローの概要
私たちが作成したインシデント対応フローは、次のようなステップに分かれています。
```mermaid
graph TD;
A[検知] --> B[ざっくり調査];
B --> |影響あり| C[トリアージ];
B --> |影響なし| D[改善系対応としてチケット化];
C --> E[チャンネル作成・発報];
E --> |Webのみ可能な場合、可能であれば| F[切り戻し対応];
E --> G[インシデント対応];
F --> H[リリース];
G --> H[リリース];
H --> I[収束確認];
I --> J[ポストモーテム];
J --> K[再発防止策の実施];
K --> L[Slackチャンネルのアーカイブ];
```それぞれ詳しく解説します。
1. 検知
システムモニタリング
ユーザーからの問い合わせ
社内メンバーの気づき
などから、不具合の可能性がある事象を検知します。大きい・小さいにかかわらず、問題を見つけたら即座に次のステップに進むのがポイントです。
2. ざっくり調査
検知した問題が実際に「インシデント」なのかどうかを簡易的に状況把握します。再現確認や影響範囲のざっくり調査をして、
「1人以上のユーザーが通常運用できない、または企業の収益に影響を及ぼしている状態かどうか」
を判断します。
ここでは詳細原因の究明ではなく、インシデントとして扱うべきかどうかのファーストジャッジだけを行うのが重要なポイントです。
もしインシデントに該当しなければ、今後の改善ポイントとして通常開発のタスクへ回します。
3. トリアージ
「インシデントだ」と判断したら、問題の重大度（Severity）を素早く判断して対応の優先順位を決めます。
PIVOTでは、各インシデントに対して重大度をSEV1〜SEV3までのレベルに分けて設定しています。
PIVOTにおける重大度の定義（例）
SEV1: 全ユーザーに影響する・企業の収益に関わる重大なインシデント
全ユーザーが動画を視聴できない
全ユーザーの個人情報が漏洩するリスクが発覚
サブスクリプションの決済処理が全停止
サービス全体が法的に利用停止を命じられる
SEV2: 多くのユーザーに影響する重大なインシデント
Androidアプリ全体でログインができなくなる
iOS 16以降の端末でのみ動画が視聴できない
非会員ユーザーが会員登録できない
SEV3: 一部のユーザーに影響するインシデント
低速回線を利用している場合に動画再生が停止する
新規登録フォームで一部のユーザーが次のステップに進めない
プロフィール登録で1990年以下が選択できない
重大度をあらかじめ定義しておくことで、チームが迷わず、的確な初動対応を取れるようになります。
4. チャンネル作成・発報
トリアージを終えたら、Slack上にインシデント対応専用のチャンネルを作成します。専用チャンネルを作ることで、情報を一箇所に集約し、混乱を防ぎます。
チャンネル作成は誰でも簡単に行えるよう、Slackのワークフローを活用しています。
フォームに「起こっていること」「重大度」「影響範囲」を入力して送信すると、専用チャンネルが自動作成され、関係者が召集されます。
Slack上でのやり取りを集約することで、見落としや重複報告を防ぎ、インシデント対応がスムーズになります。
5. （Webのみ可能な場合）切り戻し対応
もしリリース後に発生したインシデントですぐ切り戻しできる場合は、素早く切り戻しを行います。
「とりあえず被害を食い止めよう」という考え方ですね。
ただし、iOS/Androidアプリの場合は切り戻しても審査を経る必要があり、すぐに反映されないため、6に進みます。
6. 詳細調査・インシデント対応
まず調査担当者とは別に、インシデントコマンダーと呼ばれる、現場をリードする人を決めます。
インシデント発生時は、インシデントのきっかけを作ってしまったメンバーが慌ててしまうケースが想定されます。そこで、現在起きている事象の整理や、関係者とのコミュニケーションをリードする人がいるとスムーズな対応が行えます。
尚、企業によっては、他にもテクニカルリード等の別の役割を決めているところもあると思いますが、私たちのチームはまだ少数なので、現状は役割を2つに限定しています。
ここからは、重大度ごとに、対応内容が変わります。
SEV1: 全ユーザーに影響する重大インシデント
インシデントコマンダーは速やかに社内全体へ状況を報告
調査担当者が原因を深掘りし、最速で止血するための方針を検討
インシデントコマンダーが方針を決定し、最優先で対応に着手
SEV2: 多くのユーザーに影響する重大なインシデント
基本的な流れはSEV1と同様
エスカレーション（報告・承認先）はインシデント内容に応じて判断
SEV3: 一部のユーザーに影響するインシデント
調査担当者が原因を調査し、詳細な影響範囲と対応時間を見積もる
インシデントコマンダーが対応方針を決定
必要に応じてエスカレーション
7. リリース
応急処置や修正対応が完了したら、テストを実施しリリースします。
アプリの場合は、リリース後に強制アップデートを設定することで、ユーザーが早期に最新バージョンを利用できるようにします。
8. 収束確認
リリースして完了ではなく、しっかりモニタリングして問題が解決したかどうかを確認します。
エラーログや問い合わせが再び発生していないか
障害状況が改善されているか
収束を確認できたら、専用チャンネルでチームへ周知します。
9. ポストモーテム
インシデント対応で最も大事と言っても過言ではないのがこの振り返りです。
「なぜ問題が起きたのか？」 「対応は適切だったか？」などを以下の観点で深掘りします。
影響範囲
インシデント発生から収束までのタイムライン
根本原因の深掘り
再発防止策
インシデント対応時の振り返り（うまくいった点・問題があった点）
Googleのポストモーテム事例を参考にすると理解が深まりますので、興味があればぜひご覧ください。
10. 再発防止策の実施
ポストモーテムで検討した再発防止策は、そのままにせず必ず具体的な行動に落とし込んで実行します。
私たちは毎朝のミーティングで進捗や実施状況をチェックし、「やったつもり」を防ぐようにしています。
11. Slackチャンネルのアーカイブ
最後に、対応専用に作ったチャンネルをアーカイブし、今回のインシデント対応は完了です。
インシデント対応のポイント
ここまで紹介したフローを考えるうえで、特に重要視していたポイントをまとめます。
1. 初動を素早く
インシデント対応では、初動の早さがその後の影響を大きく左右します。
フローを定義して迷わないようにする
Slackのワークフローなどを使い情報共有を自動化する
これらを通じて、いかに早くチーム全体が動き出せるかにフォーカスしています。
2. 属人化を防ぐ
誰か特定のメンバーだけが対応を抱え込むと、疲弊やリスクが高まります。
フローを整備し、役割（インシデントコマンダー・調査担当者など）を決めることで、誰がいつ何をするかが明確になり、チーム全体で対応できます。
3. 振り返りを通じた継続的な改善
インシデント対応は振り返りが欠かせません。
収束後、ポストモーテムで原因や対応を振り返る
改善点を具体的なアクションへ落とし込む
これにより、同じ問題の再発を防ぎ、チームとプロダクトの成長に繋げられます。
おわりに
インシデント対応は、どんなプロダクトチームにとっても避けては通れない課題です。私たちは今回ご紹介したようなフローを整備し、チーム全体が落ち着いて行動できる環境を作るようにしています。
もし皆さんのチームでも、「インシデント対応が属人化している」「なかなか初動が遅れる」という悩みがあれば、本記事で紹介したフローを参考にしてみてください。
また、「こんな対応フローを使っているよ」「ここをもう少しこう改善したらよくなるかも」といったフィードバックがあれば、ぜひ教えてください！
最後まで読んでいただき、ありがとうございました！