はじめに
LuupのSREチームに所属している、ぐりもお（@gr1m0h）です。
6月に「Waroom Meetup #1」にスピーカーとして招待いただきました。また、この勉強会はオンライン配信がなくオフラインのみの開催だったため、7月に広島で行われた「Road to SRE NEXT@広島」でも内容を少しアップデートして登壇しました。
資料はこちらです。
どちらのイベントもオフライン開催だったため、資料だけでは口頭での説明が抜けてしまい、意図が十分に伝わらない可能性があります。そのため、登壇内容をブログとしてまとめます。
インシデントマネジメントの変遷
まず、Luupの開発組織でのインシデントマネジメントの変遷について軽く共有し、その後詳細について触れていきます。
Luupの開発組織では以下の様にまず、Notionを使ってインシデントマネジメントを行っていき、次にWaroomを使ってインシデントマネジメントを行うという風に変わっていきました。
また、Slackでのコミュニケーション、エスカレーションフローなどのプロセスの部分も変わっていきています。
Notionでのインシデントマネジメント
2023年11月にWaroomを導入し始めるまでは、社内で使用しているNotion上にインシデント情報をまとめるための環境を整えていました。
具体的には、インシデントマネジメントテーブルの作成や、インシデント発生後に使用するポストモーテムチェックリストの準備を行っていました。
このあたりの詳細については、以前書いた以下のブログに記載しています。
課題についても上記のブログに記載していますが、改めて整理すると以下のようになります。
インシデント対応時にインシデントマネジメントテーブルへの記録が漏れたり、インシデント対応自体が特定メンバーに依存しているというケースが発生していました。
また、昨年7月の法改正により、電動キックボードの利用が増えたことで事業が拡大するフェーズに突入し、オンコール体制をしっかり整備する必要が出てきました。オンコール対応を始めたものの、対応専用チャンネルを手動で作成する必要があったり、インシデント発生時に担当者が適切な対応を把握できていなかったりと、オンコール対応においても課題が見つかりました。
加えて、ポストモーテム会議においても課題が発生しました。
インシデント対応時にインシデントマネジメントテーブルへの記録が漏れることで、会議前に必要な情報が十分に揃っておらず、インシデントマネジメントテーブルの評価を行うはずが、会議中に情報を記入する時間になってしまっていました。
Waroomでのインシデントマネジメント
Waroomは正式リリースされてから、すぐトライアルを開始し、現在も使い続けています
インシデントマネジメントのサービスはいくつかありますが、コスト、サポート、機能の適合性の観点からWaroomを選択しました。
今回の登壇内容では、機能の適合性、課題を解決できるかというところについてフォーカスしてお話しました。
先述した課題に対して、WaroomのUserToken版Slack App、ランブック、ポストモーテムという機能を使って解決していきました。
ランブック、ポストモーテムについては、以前書いた以下のブログに記載しているので、割愛します。
ここでは、対応専用チャンネルを手動で作成する手間があるという課題に対する対応について説明します。
前提として、Luupでは、正社員はSlackの「Full member」として登録され、一般的な権限を持っています。一方、業務委託の方は「Multi-channel guest」として登録されています。Full memberはSlackチャンネルを作成し、他のメンバーを招待できますが、Multi-channel guestはこれができず、Workspace owner/adminがチャンネルに招待する必要があります。
現状、SREチームやサーバーチームなど、一部の業務委託メンバーはオンコール対応を行なっており、Multi-channel guestがFull member同様にチャンネル操作できないと、インシデント対応に大きな影響を及ぼす状況になっていました。
この課題を「UserToken版SlackApp」で解決しました。
WaroomのSlackAppは通常、SlackのBotTokenで動作し、Full member以上の権限のユーザーに対して対応専用チャンネルの作成や招待を自動的に行います。しかし、Multi-channel guestに対しては権限不足のため、これを行うことが出来ません。
Workspace owner/adminがWaroomのSlack連携を行う必要がありますが、UserToken版SlackAppを使うことで、Multi-channel guestに対してもFull member同様、対応専用チャンネルの作成や招待を自動化することが可能になります。
UserToken版SlackAppを運用する際の注意点は以下の通りです。
-
Full member権限（Workspace owner/admin以外）のユーザーでSlackAppをインストールしないこと
これを実施すると、利用するSlackAppがFull member権限のUserTokenに切り替わってしまうためです。事故を防ぐために、Waroom側で権限管理できるようになると良いと考えています。 -
SlackApp用のSlackユーザー（Workspace admin）を作成すること
必須ではありませんが、既存のWorkspace owner/adminがSlack連携を行うことも可能です。Luupでは、Waroom用にWorkspace adminユーザーを新たに作成し、このユーザーでSlackAppをインストールしています。これにより、Waroom SlackAppの操作が特定のユーザーの動作として表示されることを防ぎ、健全な運用を行っています。 -
Slackコマンドを実行するチャンネルを固定すること
実際にはWaroom用のユーザーが招待されているSlackチャンネルでしかコマンドを実行できませんが、忘れがちになるため、コマンド実行可能なチャンネルを周知することが必要です。
Waroomの運用状況
現在のインシデントマネジメントの運用状況について説明します。
Waroomの利用範囲
Waroomの利用範囲は、SREチームのみの状態から開発組織全体へと拡大しました。
ここで疑問に思うのは、「なぜNotionで管理していたときはうまくいかず、Waroomでは成功したのか」ということです。
SREチームとしては、以下の３つの要因があると考えています。
-
SREチームが普及活動を積極的に行えたこと
Waroom自体の影響もありますが、時間が経つことで体制が強化され、推進する正社員が増えたことが大きいです。オンコール体制の構築など、インシデント対応が活発化してきたことも一因だと思います。 -
SRE以外のチームでも潜在的なニーズがあったこと
リリース時のインシデント対応はできていたものの、インシデント情報を蓄積して分析・管理する部分は不十分でした。 -
Waroomの利便性
Notionでは最初からすべての入力項目が見えてしまいますが、Waroomのランブックは対話形式で入力していくため、心理的な負担が少なく、利用が進んだのだと思います。
コミュニケーション
他部署のメンバーとも対応専用チャンネルを通じてやりとりができるようになりました。
ここで疑問に思うのは、「なぜ他部署のメンバーがWaroomを使った対応専用チャンネルでやりとりできるのか？」ということです。
これは、Waroomを意識せずに自然に利用できているためだと考えています。Slack自体がLuup社内の標準的なコミュニケーションツールとして定着しており、これまでもインシデント発生時には緊急チャンネルが作成され、そこで対応していたため、Waroomを意識せずに従来通りの対応ができているのだと思います。
共有・振り返り
開発組織全体とSREチームで、それぞれ振り返りを行っています。
開発組織全体では、週1回の部会でSREチームから報告を行い、SLOの状況報告と合わせてインシデントの報告を行います。インシデントによるErrorBudgetの消費も含めて共有することで、SLOとインシデントの関連を理解してもらうことができます。
SREチーム内での共有・振り返りは、週1回のSRE SyncMTGで実施しています。パフォーマンス確認や定点観測の際にDatadogのダッシュボードを確認しますが、その前に1週間で発生したインシデントを確認することで、インシデントがどのような影響を与えたのかを把握できるようにしています。
プロセス
SEV（重大インシデント）の定義について、Luupでは以下の観点で定義を行う必要があります。
- SLOアラートの状態
- CSからの問い合わせ件数
- 法律遵守（個人情報保護、道路交通法、道路運送車両法など）
- 車両数、ユーザー数
個人情報保護はどの事業でも重要ですが、LUUPでは道路交通法なども考慮する必要があります。例えば、管理画面から自賠責画像が参照できなくなった場合、法律違反になる可能性があり、ソフトウェアのインシデントが直接的に法的な問題を引き起こすことも考えられます。このように、SEVの定義には多くの変数が絡むため、現在検討中です。
また、インシデント発生時のコミュニケーションについては、サービス運用においてCSやサービスオペレーションの役割が大きいため、エンジニアではないメンバーとも連携を取る必要があり、プロセス整理が難しい部分があります。
さらに、CSがインシデントをエスカレーションする際、当番のオンコールメンバーを把握してメンションするのが難しいという課題がありました。これを解決するために、SlackAppを作成しました。
@oncallコマンドを使うことで、当日のオンコール担当のみをメンションできるようにしました。この機能はCloud RunでGoogleスプレッドシートで管理されているオンコール当番表を読み込み、メンションをリダイレクトする仕組みです。
さいごに
Luupの開発組織でのインシデントマネジメントの変遷について紹介しました。
LuupのSREチームでは、Waroomの導入により、インシデント対応やオンコール体制の改善が進んでいます。これまでNotionを使っていた時はうまく機能していなかった管理が、Waroomの利便性やSREチームの推進活動を通じて、開発組織全体に広がり、効率的に運用できるようになりました。
開発組織全体およびSREチーム内でのインシデントの共有・振り返りも定期的に行われ、SLOやErrorBudgetの消費状況も合わせて報告することで、インシデント対応に関する理解が深まりました。
また、SEV定義に関しては、SLOアラート、CSの問い合わせ件数、法令遵守など、複数の観点から定義を進める必要があります。加えて、CSがオンコール担当者を簡単に把握できるようにするためのSlackAppの開発も進められ、インシデント対応の効率化が図られています。
今後は、さらにプロセス改善を進めつつ、インシデント対応やオンコール体制の強化を続け、開発組織全体での信頼性向上を目指しています。
↓は、Road to SRE NEXT Hirosimaで登壇したときの様子です。
最後に、弊社のプロダクト開発やSRE、使用技術に興味を持っていただけた方は、以下のリンクからお気軽にご連絡ください！私のX(Twitter)アカウントでもDMを受け付けています。
副業や転職をお考えの方だけでなく、気軽に話を聞きたいという方も大歓迎です！
Discussion