こんにちは。Topotal の 宮里 miya_wata1017 です。
前回の記事では、インシデント対応における属人化の原因と、Waroom の Runbook・専用チャンネル自動作成機能がどのように属人化を解消するかをご紹介しました。
前回の記事はこちら👇
今回、Waroom を使ったインシデント対応の一連のフローを解説します。起票からクローズまでの流れを把握することで、Waroom がどのようにインシデント対応の負担を減らしているかがより具体的にイメージしやすくなると思います。
ツールの切り替えが、対応の遅れを生む 😢
インシデント対応の現場では、スピードが重要です。障害が発生した瞬間から、誰に連絡する・どのチャンネルで話す・手順書はどこにある・誰がコマンダーになるという判断が次々と押し寄せてきます。
そこに別のツールを立ち上げて操作するというステップが加わると、その数秒・数分が積み重なり、復旧時間の遅延につながる可能性があります。
Waroom は Slack を起点に設計されており、ツールの切り替えを最小限に抑えながら一連の対応が完結します。次のセクションでは、その具体的なフローをご紹介します。
Waroom のインシデント対応フロー ✅
ステップ 1：インシデントを起票する
Waroom でのインシデント起票は、以下の方法がありますが、今回のブログでは、Slack 上からの起票についてご説明します。
- 外部監視ツールとの連携（Integration）による起票
- Web UI からの起票
- Slack 上からの起票
Slack 上でのインシデント起票は、 /waroom create コマンドを実行するだけでインシデントを起票できます。
/waroom create コマンド実行後は、以下のモーダルが表示されます。
ステップ 2：専用チャンネルが自動で作られ、関係者が集まる
インシデントが起票されると、対応専用の Slack チャンネルが自動で作成されます。さらに、サービスや重大度に応じてあらかじめ設定したメンバーを自動招待できます。
重大度 SEV-1 なら経営層も招待する、このサービスなら開発チームリーダーを含めるといったルールを事前に定義しておくことで、誰に連絡するかをその場で判断する手間を減らせます。
ステップ 3：コマンダーをアサインする
インシデント対応の指揮をとるコマンダー（指揮官）を決めます。Slack のスラッシュコマンドで完結します。
/waroom role assign commander @slack_username
コマンダーが明確になることで、各メンバーは判断を仰ぐ先がわかり、対応の指揮系統がチーム全体に伝わります。
インシデントコマンダーに関する記事も併せてご参照ください。
ステップ 4：対応しながら、AI が記録する
原因調査・復旧作業は、通常の Slack でのやり取りをそのまま続けるだけで構いません。Waroom は専用チャンネルでのやり取りを、Slack のコメント履歴を元に AI がリアルタイムで取り込み、インシデントの状況を自動で整理・集約します。
記録しながら対応するという二重の負担を減らせます。
また、/waroom update でステータスを「調査中」「修正中」と切り替えることで、各フェーズの所要時間（TTx：Time to Detect / Resolve など、対応の各段階にかかった時間の総称）も自動で計測されます。
ステップ 5：復旧を確認し、クローズする
復旧が確認できたら /waroom update でステータスを解決済みに変えます。TTR（Time to Resolve）が自動で記録され、チームに復旧が共有されます。
対応完了を宣言し、専用チャンネルをアーカイブします。アーカイブしたチャンネルはインシデント詳細画面からいつでも参照できるため、後からあのときどんな対応をしたかを確認しやすくなっています。
ステップ 6：振り返る
Waroom のブラウザ画面を開くと、AI が対応中の Slack のやり取りをもとに自動生成したドキュメントを確認できます。ポストモーテムが必要な場合は、ボタン1つで下書きを作成できます。タイムラインの再構成など、手間のかかる部分を AI が担ってくれるため、担当者は内容の確認と加筆・修正に集中しやすくなります。
ポストモーテムについては、別のブログで解説します。
フローが標準化されることで何が変わるか 📈
このフローが組織に定着すると、いくつかの変化が生まれやすくなります。
- 対応の心理的ハードルが下がる
- 次に何をすべきかが明確になることで、SRE 以外のメンバーでも起票・対応に参加しやすくなります。Waroom をご利用中のお客様からも、導入後に「インシデント対応への心理的ハードルが下がった」「自分以外のメンバーも起票するようになった」というお声をいただいています。
情報が一箇所に集まる
- 専用チャンネルに対応の情報が自動で集約されるため、複数のスレッドやドキュメントを横断する手間が減ります。後から合流したメンバーも、チャンネルを見るだけで状況を把握しやすくなります。
対応の質が蓄積される
- TTx の自動計測とインサイト画面の分析機能により、どのフェーズに時間がかかっているかをデータとして把握できるようになります。感覚ではなく、データをもとに改善の優先順位をつけやすくなります。
終わりに
Waroom を使ったインシデント対応のフローは、Slack を起点に以下のステップで対応を行うことで、別のツールへの切り替えを最小限に抑えられます。
起票 → 専用チャンネル作成・関係者招待 → コマンダーアサイン → 対応（AI が記録） → クローズ → 振り返り
前回の記事でご紹介した Runbook による標準化と、今回のフロー自動化が組み合わさることで、誰でも・いつでも・同じように動ける対応基盤を作りやすくなります。
インシデント対応のお悩みや、デモンストレーションをご希望の方は、こちらからお申し込みください👇
