インシデントマネジメントのこれまでとこれから

これは Luup Advent Calendar 2023 の２２日目の記事です。

はじめに

株式会社Luup SREチームに所属しています、ぐりもお（@gr1m0h）です。

今年はLuupに転職し、主にSREとしてSLOの推進に携わり、２回の登壇を経て、完全にSLOの領域に身を置くようになりました。（Luupの外からもそのように見えていたと思います）しかし、実はSRE NEXT 2023以降は、インシデントマネジメントの整備に力を入れていました。

今回は、インシデントマネジメントの整備にあたりWaroomを採用した経緯について書きたいと思います。

インシデントマネジメントサービスの採用

インシデントマネジメントサービスの導入に至った経緯について説明します。

まず、Luupがインシデントマネジメントの分野でどのような活動をしていたのか、Luupの状態について共有します。

これまでは、SREチームが主導して次の活動を行っていました。

• インシデントマネジメントガイドの作成
• インシデントマネジメントテーブルの用意
• ポストモーテムチェックリストの用意

インシデントマネジメントガイドは、インシデント発生時に確認するSlackチャンネルやインシデントマネジメントのフロー（インシデント発生からポストモーテム会議の実施、事後の恒久対応（フォローアップアクション）の実施まで）、インシデントマネジメントテーブルへのリンクなどが詳細に記載されたドキュメントです。

インシデントマネジメントテーブルは、発生したインシデントを記録していくテーブルになっています。
ここには、各インシデントに関連する情報が詳細に記載されています。War roomチャンネル^[1] やポストモーテムチェックリストへのリンクなども含まれ、これを通じてインシデントの情報を確認できます。

記載するインシデント情報は、一般的なポストモーテムの項目と大きな違いはありませんが、Luup用に一部手を加えています。一般的なポストモーテムの項目については以下SREbookのポストモーテムのサンプルを参照ください。

https://sre.google/sre-book/example-postmortem/

ポストモーテムチェックリストは、ポストモーテム会議でインシデントを振り返る際に利用するチェックリストで、必要な情報が適切に入力されているかを確認する役割があります。

上記の手法により、一見するとインシデントマネジメントが十分に機能しているように見えますが、実際の運用においてはいくつかの課題が生じていました。以下にそのエピソードを述べます。

• SREチームが関与しない場合、そのインシデントはSREが主導しない限りインシデントマネジメントテーブルに記載されない
  • 発生した問題
    • インシデント履歴が記載されない
    • 対応が属人化する
• ポストモーテム会議の際に全員でインシデント情報を記載する
  • 発生した問題
    • 「事象の確認」「暫定対応の評価」および「恒久対応（フォローアップアクション）」等の本来ポストモーテムで行うはずの時間を失う
    • 会議時間が長時間化する

ポストモーテム会議の際に全員でインシデント情報を記載するということについては、本来はインシデント発生時にインシデントを記録、管理を開始するのが望ましいですが、それらが全て事後対応になってしまっており、アンチパターンになっています。

さらに、インシデントマネジメントが上手く運用されていないことから、重大なインシデントの対応は特定のメンバーに依存しているケースも発生していました。会社の事業をスケールさせていく過程で、さすがに特定メンバーへの依存に頼り続けるのは会社として無理があるフェーズになってきました。

オンコールを仕組み化するにおいても、従来の手法では以下のような課題が浮かび上がりました。

• War roomチャンネルを手動で作成する必要がある
  • Luupでは業務委託メンバーが多く、Slackのマルチチャンネルゲストの制約でSlackチャンネルを作成できない
• SREチーム以外のオンコール担当者がインシデント発生時に適切な対応がわからない
  • 各担当者のスキルに依存し、前提知識に偏りが生じている
• オンコール担当者の対応やインシデントの状態が、担当外のメンバーには見えない

これらの課題を解決するためにインシデントマネジメントサービスであるWaroomを選定しました。

なぜWaroomを選定したか

Waroomは株式会社Topotalが開発・提供するインシデントマネジメントサービスです。

https://waroom.com/

選定理由としては大きく以下の３点があります。

1. コスト
2. 機能の適合性
3. サポート

1.コスト

まず最初にコストについてです。
Waroomの料金体系は他の多くのインシデントマネジメントツールと異なり、ユーザー単位ではなく組織単位 になっています。

https://waroom.com/pricing

Luupという組織は、情報やデータが全社で共有され、Slackを通じて様々な情報が流れているため、必要であれば自ら情報を取得できるようなオープンな文化が根付いています。また、重篤度の高いインシデントを扱う場合など、オンコール担当者以外の他部署のメンバーもインシデントを参照することが想定されます。そのため、このシンプルなコスト料金体系は非常に大きな利点となりました。

2. 機能の適合性

次に機能の適合性についてです。

先述したそれぞれの課題についてWaroomでどのように解決できるか見ていきます。

ポストモーテム会議の際に全員でインシデント情報を記載する

Waroomはインシデントマネジメントサービスなので、Waroomを使用すればインシデントの発生からポストモーテム実施まで一気通貫でガイドを提供してくれます。これによって、インシデント情報を記載した上でインシデントのステータスを変更し、その後ポストモーテムを行うというフローが担保されるので、この問題が発生する余地がフローからは無くなります。また、ポストモーテム会議の前にインシデント情報を事前に記載しておかなければならないのですが、これもWaroomの「インシデントステートドキュメントの自動生成」の機能によって解決することができます。
インシデントステートドキュメントとは、インシデントの対応状況や調査結果をまとめたサマリーのようなドキュメントです。これは、SlackのメッセージをもとにAIが自動的に作成してくれるものです。

以下はテスト用にWaroom上で作成したインシデントのインシデントステートドキュメントです。

AIが作成したインシデントステートドキュメントは、精度が微妙な場合があるかもしれませんが、初版をAIが書いてくれるということは非常に重要なことです。これにより、人間がインシデント情報を更新する際の心理的障壁が低くなります。インシデント情報を詳細に書くということのとっかかりとして有効なものです。
また、インシデントステートドキュメントは複数人でリアルタイム編集できるので、チームでインシデント情報をまとめるということも容易です。

https://docs.waroom.com/realtime_incident_state_document

SREチームが関与しない場合、そのインシデントはSREが主導しない限りインシデントマネジメントテーブルに記載されない

この問題については、オンコール時のフローを整理し、啓蒙していくことで根付かせていくしかないかなと思っています。ただ、Waroomには記載したインシデントをもとに分析できる機能があるので、定期的にこの機能を使用して振り返りを行うことで、インシデント起票の効果を高められるのではないかと思います。これにより、小さなインシデントでもまず調査が必要な事象が起きたら、Waroomでインシデントを作成するという行動に結びつけられればと思います。

https://docs.waroom.com/insight

また、人間がインシデントを起票するから忘れてしまうという課題があるので、Waroomのインテグレーションを使用して、自動でWaroomのインシデントを起票するようにすれば、この課題を解決できます。Luupでは、Datadogのインテグレーションを活用することを検討しています。

https://docs.waroom.com/auto_trigger_integration

War roomチャンネルを手動で作成する必要がある

Slackの一般ユーザーは、WaroomにSlackアカウントを紐付けることでインシデント対応専用チャンネル^[2] を簡単に作成することができますし、簡単に招待を受けることができます。また、手動でインシデントを起票した場合は自動でインシデント対応専用チャンネルが作成されます。

https://docs.waroom.com/connect_slack_account

Slackのマルチチャンネルゲストは管理者ユーザーしかチャンネルに招待できません。なので、WaroomのSlackAppからの招待ができないという問題があります。こちらについては、Topotalさんの今後の機能開発に期待です！

SREチーム以外のオンコール担当者がインシデント発生時に適切な対応がわからない

インシデント発生時にまずどこを見て影響調査すれば良いか、既知のインシデントに対してどのような対応を行えば良いのかというのは事前にわかっていることです。WaroomのRunbookの機能を使えばこの問題を解決できます。

https://docs.waroom.com/create_runbook

このRunbookに事前にわかっている調査用のダッシュボードのリンクを貼ったり、対応を記載しておけば、それに則って対応を進められます。手順が「Next Action」として表示されるので、対応が完了したら「Done」のボタンを押下して次の手順に進む...というのを繰り返し対応を進めます。

以下は、Waroomのインシデント上の表示とSlackのインシデント対応専用チャンネルの表示です。

Waroomには、デフォルトRunbookがあり、何も設定していなければこのRunbookが適用されます。既知のインシデントに対してはそのインシデント専用のRunbook、未知のインシデントに対してはこのデフォルトRunbookが適用されるように設定しておけば良さそうです。

https://docs.waroom.com/create_runbook_rule

オンコール担当者の対応やインシデントの状態が、担当外のメンバーには見えない

Waroomでインシデントマネジメントを行うことができるので、Waroomがしっかり使われる状態になれば解決するでしょう。しばらくはWaroom警察？インシデント警察？のようにインシデントの現状を確認してステータスを更新してもらったり、重篤度的にポストモーテムしませんか？と声掛けが必要かなと思っています。ここは啓蒙活動、運用にのせるという活動の辛いところです。

その他、詳細な機能については以下のWaroomドキュメントを参照ください。

https://docs.waroom.com/

3. サポート

最後にサポートについてです。
Waroomについての説明を聞き、Luupの課題を解消できるか検討するため、1ヶ月のトライアルを実施しました。

トライアル期間中はWaroomの機能を一通り試してみたり、実際にインシデントが起きた際にWaroomを使用してインシデント対応を行うということをやっていました。幸いなことに、Waroomトライアル中に大きなインシデントが起きなかったので、避難訓練（インシデントが発生したとしてWaroomを使ってインシデント対応を実行してみる）を行い、Waroomを実際に使ってインシデント対応を実施できるか検証していました。

トライアル期間から今現在までSlack Connectを使用して、非常にやり取りしやすい状態でTopotalの担当者さんとコミュニケーションを取っています。Waroomを試してみると、正式リリース版がリリースされたばかりということもあり、不明点や疑問点が出てきました。これらについてTopotalの担当者さんに確認すると、非常に迅速かつ丁寧にサポートしていただけました。質問や要望に対する深い洞察だけでなく、Waroomというサービスの枠を超えて、Waroomでも設定できる重篤度（Severity）の定義についてやWaroomを用いたインシデントマネジメントのフローについても相談に乗っていただけました。

---

余談ですが、どうやらLuupがWaroomのファーストユーザー になったようです。
Waroomが製品版リリースされて１ヶ月での採用、そしてファーストユーザーに至った経緯には次のような背景があると思っています。

私がChairをやっていたSRE NEXT 2023というSREのカンファレンスで、Topotalの菱田さんが運営メンバーとして協力してくれていました。

菱田さんとオンラインミーティングでの雑談や、SRE NEXT 2023の進捗を出す＋懇親会であるBBQの際に、Waroomの説明を聞きたいという話をしていました。
Waroomは当時ベータの状態でした。私も先述した通りの状況であり、自分たちでWar roomチャンネルを作成する機能を作ったりして、インシデントマネジメントツールを自前運用するか、何か良いインシデントマネジメントサービスがないか調査を進めていました。

そんなある日、菱田さんからWaroom正式リリース版のフィードバックの依頼がありました。私は興味津々で即座に承諾し、Waroomの説明を聞き、いくつかフィードバックを提供しました。インシデントマネジメントツールの経験があまりなかったので大きな貢献はできなかったかもしれませんが。

ただ、その際にWaroomの詳細を聞き、Waroomの機能詳細や製品版のリリースタイミングを早い段階で社内に共有できたことが、このスピード感でのWaroomの採用につながった要因だと考えています。

さいごに

LuupでWaroomを使って、オンコール、インシデントマネジメントを改善しているお話を書きました。

まだ色々決めて運用を開始したところであり、避難訓練は行ったもののオペレーションの不具合などがありそうで不安ですが、避難訓練の録画をオンコール担当者に共有するなどサポートを継続的に行っています。

今後の改善や詳細などについては本ブログや登壇でお話しできればと思っています（登壇依頼とか憧れますね、お待ちしています）。Waroomの機能についても一通り触ったのである程度説明できる気がしています。Waroomについて気になった方は気軽にTopotalさんに声掛けていただいて製品説明をしていただいた方が良い気がしますが、この記事を読んでWaroomが気になった方は私に声かけていただいても良いです！一緒にインシデントマネジメントについて議論できれば嬉しいです。

最後に謝辞です。
Topotalの社員の皆さん。Waroomトライアル中から今現在ブログ執筆中もサポートいただきましてありがとうございます。
ユーザーが増えると難しい部分も出てくると思うので、Waroomを利用しているLuupもWaroomについてアウトプットしていき、微力ながら貢献できればと思っています。

最後に、弊社でのプロダクト開発、SREや使用技術に少しでも興味を持っていただけた方は、以下のリンクからお気軽にご連絡ください！私のX(Twitter)アカウントもDM解放しています。
直近副業や転職を考えている方でなくとも、ただ気軽に話を聞きたいという方でも大歓迎です！

https://recruit.luup.sc/

脚注

1. https://sre.google/sre-book/managing-incidents/#a-recognized-command-post

2. War roomチャンネルと同様のものを指しています。Waroomの機能説明なので、Waroomドキュメントの表現に合わせています。