この記事は、CyberAgent Developers Advent Calendar 2024とCyberAgent Group SRE Advent Calendar 2024の16日目の記事です。
はじめまして、メディア統括本部サービスリライアビリティグループ（以下、SRG）の柘植（@shotaTsuge）です。
#SRG（Service Reliability Group）は、主に弊社メディアサービスのインフラ周りを横断的にサポートしており、既存サービスの改善や新規立ち上げ、OSS貢献などを行っているグループです。
本記事では、WINTICKETを支えるインシデントマネジメントの取り組みについて紹介したいと思います。
WINTICKETとは
WINTICKETは、2019年4月にリリースした公営競技のインターネット投票サービスです。サービスとしては、投票だけではなくレース映像のライブ配信やAI予想、オッズ、レース情報など、レースの予想に役立つ様々な情報も提供しており、リリースから約2年で、競輪投票サービスNo.1へと急成長しました。そして、サービスの特性的にPayPayなどの豊富な決済手段を提供している為、高い信頼性が求められています。そういった背景から、WINTICKETでもSRE領域に注力をしており、利用者が安心安全にサービスを利用できるように、信頼性の向上に取り組んでいます。
※ 上記画像は、2023年3Q決算説明会資料のデータを引用しています
SRGとしての関わり
WINTICKETの信頼性を向上する為に、これまでにSRGとして様々な支援を行ってきました。その中で、先ずは現状の課題を整理する為に、当時WINTICKETの技術責任者であったわだまる（@wadackel）さんとSRE成熟度評価を実施し、「サービスレベル目標」「監視」「インシデント対応」「ポストモーテム」「トイルの撲滅」の5つの項目についての評価を行い、それぞれの項目に対しての改善計画を立てて実施してきました。本記事では、その中のインシデント対応の改善について紹介していきます。その他の項目について、実施してきた取り組みについては、別の機会があれば紹介したいと思います。
インシデントマネジメントの取り組み
取り組みについて紹介する前に、そもそもインシデントマネジメントがなぜ重要なのかについて少し触れておきたいと思います。整備されていないことによって、私は下記のようなことが起こり得ると考えています。
- 対応の温度感や質にむらが出やすい
- 計画的に恒久対応が行われない為に、同じようなインシデントの再発リスクが高い
- そもそもインシデントが起きていることに気づけていない
そういったリスクを減らしたいというモチベーションの元、インシデント対応フローを評価した中で、より成熟度を向上させるための取り組みとして、下記が出てきました。
- インシデント重要度レベルの策定
- インシデント発生時の役割と活動を定義
- インシデント対応フローの見直し
インシデント重要度レベルの策定
WINTICKETでは、インシデント発生時に迅速かつ適切な対応を行うための基準として、過去の事象を元に、インシデント重要度レベル（Severity Level）を5段階で定義することにしました。インシデント重要度レベルを定義するにあたり、下記のような点を考慮しました。
- 影響ありの判断は、ユーザーの行動をベースに行う
- レベル判断に迷った際は、一つ上のレベル判定をする
レベル判断に迷った際は、一つ上のレベル判定をする様にしている理由としては、重要度を低く見積もることによって、必要な対応が後手に回るリスクや不確定要素が多い状況では、低く見積もるよりは高い温度感で対応を進めた方が良いと考えたからです。そして、インシデントが収束しているという理由でレベルを下げない様にもしており、これはインシデントの収束具合とレベルは関係ないからです。
これらの点を考慮した上で、下記画像のようなレベル決定ツリーを作成し、インシデント重要度を決めていきました。
| 対象 | |
|---|---|
| SEV-1 | 〇〇に関わるインシデント |
| SEV-2 | 〇〇機能に影響のあるインシデント |
| SEV-3 | SEV-2に該当せず、〇〇に影響のあるインシデント |
| SEV-4 | SEV-2に該当せず、〇〇に影響が出る可能性のあるインシデント |
| SEV-5 | 対応すべき〇〇なインシデント |
現在では、インシデント重要度レベルの定義は、事業責任者との合意を得た事業部全体でのインシデントを適切な温度感で扱うための指針となっています。また、半期に一回、過去のインシデントとインシデントレベルが適切であったかの見直しを行いを行いインシデント重要度が事業優先度と一致している状態を作っています。
インシデント発生時の役割と活動を定義
インシデント発生時に、迅速かつ適切なインシデント対応を実施するには、即席のインシデント対応チームが それぞれの役割を自覚し、効率的に目の前の作業に取り組めている必要があります。もしも、役割が明確になっていない状態の場合、対応者が重複した作業を行なってしまったり、誰かが考えてくれる、やってくれるだろうと思い込んでしまうなどにより、対応が遅くなってしまう可能性があります。その為にWINTICKETでは、IC（Incident Commander）とOL（Operations Lead）が、二人三脚でインシデント対応の中核を担えるように、役割と活動を定義しています。また、PE（Product Expert）、PD（Product Director）、開発責任者、テックマネージャーをIM（Incident Manager）と総称しており、インシデント発生時の一時対応を主に担当し、定期的な棚卸しも行っています。
| 役割 | 活動 | |
|---|---|---|
| IC / Incident Commander | インシデントを収束させるための意思決定を担う また、インシデント対応中に全体的な責任と権限を持つ |
作業はなるべく避け、インシデント全体の把握・指示に務める また、情報展開をファシリテートやOL の指揮する現場が、インシデント収束・緩和の作業に集中できるように環境を整備する インシデント対応に必要な体制指示、ユーザー告知有無、上位のエスカレーション先への共有・報告・確認も適切に行う 必要に応じて、後任者へ権限を明示的に委任する |
| OL / Operations Lead | インシデント対応の現場責任を担う IC との協業によってインシデントの収束あるいは緩和を迅速に行う 主にテックリード、テックマネージャー、あるいは担当領域の運用対応者が担当する |
インシデントの解決、あるいは緩和をするために指揮・対応を行う(指揮が主務となり、対応作業は最低限とする) また、IC やチームメンバーへ更新情報の伝達や技術・運用的課題から必要な人選を実施する |
インシデント発生時の役割
インシデント発生時の役割分担は、下記の様に定義しました。WINTICKETでは、プロダクトの各領域に対するエキスパートメンバーをPE（Product Expert）、プロダクトの各領域に対して意思決定が行えるメンバーをPD（Product Director）と定義しており、マネージャーは、テク・ビジのマネージャーが主な担当者となっています。
| 報告・確認先 | IC（指揮官） | 概要 | |
|---|---|---|---|
| SEV-1 | 事業責任者 | 事業責任者 | 事業責任者の指揮が必須 |
| SEV-2 | 事業責任者 | PE | 事業責任者の共有は必須、指揮は PE |
| SEV-3 | PE | PD | PEの共有は必須、指揮は PD |
| SEV-4 | PE | マネージャー | 担当領域マネージャーが指揮 |
| SEV-5 | マネージャー | メンバー | 現場メンバーのみで解決 |
インシデント重要度レベル別のアクション
インシデント重要度レベル別に、下記についてのアクションを定義しています。
- 共有・連絡時のSlackメンション
- Warroomの作成
- 業務時間外対応の有無
- ユーザー告知の有無
- ポストモーテムの作成
インシデント対応フローの見直し
WINTICKETでは、インシデント重要度レベル別の対応手順を用意しています。しかし、対応手順はあくまでガイドラインであり、実際は、IC/OLの判断のもと状況に応じて適切な対応を行う必要があります。また、インシデントの対応を進めるにあたり、Warroomと呼ばれる専用のインシデント対応Slackチャンネルを作成し運用しています。インシデント対応中に発生する情報伝達や作業ログを一箇所に集中させ、円滑な情報展開を行うことを目的としており、副次的な効果として振り返り（ポストモーテム）の際のタイムライン整理にも役立てています。通話が必要な際は、基本的には、作成したWarroomでハドルミーティングを実施します。対応内容によって技術や運用面などの別軸での通話が必要なケースでは、適切なSlackチャンネルで行うようにしています。ただし、その際もハドルミーティング中のメモや議事録はWarroomに集約する様にしています。
全てのインシデント重要度レベル別の対応手順の説明は割愛しますが、WINTICKETでは、SEV-1とSEV-5の場合、特定の対応手順はないものとしています。これは、SEV-1であれば、主に事業責任者、及び開発責任者レイヤー判断によって体制を整え対応する必要があるからです。またSEV-5であれば、軽微なインシデントである為、適宜状況を指定したSlackチャンネルへ共有し、対応を進めるで事足りると判断しているからです。
Slackbotの活用
インシデント対応フローを見直したことにより、以前と比べるとインシデントレスポンスは改善されました。しかし、個人のインシデント対応能力への依存やはじめてインシデント対応する人に対してのトレーニングコストがかかってしまうといった課題がありました。そういった課題を解決する為に、インシデントレスポンスを支援してくれるSlackbot（incbot）を開発し、導入することにしました。WINTICKETでは、事業特性に柔軟に対応でき、欲しい機能の開発や修正ができるという点で、内製化を選択しました。
incbotは、Bolt for JavaScriptというSlack公式のフレームワークを使って、TypeScriptで開発しています。
インフラとしては、Google Cloudを採用しており、Cloud Runへホストしたサーバがベースとなっています。また、インシデントの情報（概要やステータスなど）はCloud Firestoreに保存する様にしています。インシデントの情報を保存することによって、一定期間のMTTR計測などのインシデントレスポンス自体の評価や振り返り、改善にも活用しています。
ここからは、incbotを活用したインシデント対応の流れについて説明していきます。
※ Slackチャンネル名やメンションなどは適当な名前にしています
1.初動
インシデントが発生したら、まず初めに発見・検知した人がインシデント報告用のSlackチャンネルで、incbotのスラッシュコマンドを実行し、第一報を行います。
スラッシュコマンドを実行すると下記画像のようなモーダル画面が表示されるので、インシデント重要度レベル（推定）、事象、事象の概要、検知日時、影響範囲（推定）を入力し、「報告する」ボタンを押下します。
「報告する」ボタンを押下すると、下記の画像のようなメッセージが通知されます。
通知されたメッセージのスレッドに、インシデントに対しての対応手順も投稿されるので、その手順に従って先ずは、発見・検知した人にインシデントマネージャーも加えてインシデント報告用のSlackチャンネルでハドルミーティングを開始し、下記を決めていきます。
- インシデント重要度レベルの一次決め
- 役割（IC/OL）を任命
- 暫定的な対応方針の決定
暫定的な対応方針の決定については、IC/OLの指揮のもと、調査方針も含めて決めます。また、調査方針が決まった際は、OLの指揮のもと対応メンバーでの影響調査を並行して進めていきます。
インシデントの対応方針が決まったら、先程のスレッドに投稿されたメッセージ内の「対応を開始」ボタンを押下し、インシデント対応を開始します。
「対応を開始」ボタンを押下すると、下記画像のようなモーダル画面が表示されるので、インシデント重要度レベル、障害起因、事象、事象の概要、IC担当者、OL担当者、影響範囲、検知日時、発覚経路を入力し、「開始する」ボタンを押下します。
「開始する」ボタンを押下すると、自動で下記画像のようにWarroom（Slackチャンネル）が作成されます。作成されたWarroomには、選択した障害起因に合わせて必要なメンバーが自動で招待されるようになっています。
2.レベル別のインシデント対応
Warroomが作成されたら、インシデント重要度レベル別の対応手順に沿って対応を進めていきます。Warroomには、IC/OLが対応の進行をする際の手引きとして下記画像のようなメッセージが投稿されます。
インシデントが復旧したら、ICはWarroomで incbotへメンションします。メンションをすると下記の画像の様なメッセージが表示されるので、メッセージ内の「復旧」ボタンを押下します。
また、インシデント重要度レベルなどのインシデント情報を変更したい場合も、同じ様にincbotへメンションし、変更したい情報のボタンを押下します。
「復旧」ボタンを押下すると、下記画像のようなメッセージが投稿されます。
ポストモーテムの予定を設定したら、必要に応じて解散します。「復旧」ボタンを押下したタイミングで、ポストモーテムの記事は自動で作成されます。
3.事後対応
事後対応として、自動で作成されたポストモーテムの記事を元に、インシデント情報の追記や修正をした上で、ポストモーテムを実施します。ポストモーテムが完了したら、Warroomで、 incbotへメンションをします。
メンションをすると上記の画像の様なメッセージが表示されるので、「クローズ」ボタンを押下し、対応を完了します。incbotを活用したインシデント対応の流れは以上になります。
最後に
今回は、WINTICKETを支えるインシデントマネジメントの取り組みについて紹介させていただきました。incbotへの機能追加や過去のインシデントデータの活用など、まだまだやりたいことは沢山ありますが、インシデントマネジメントを改善したことによって、単純にインシデントレスポンスが早くなっただけでなく、組織全体としてインシデントレスポンス自体に対しての改善へも向き合うことができるようになったと思います。引き続き、利用者が安心安全にサービスを利用できるように、信頼性の向上に取り組んでいきたいと思います。