Incident Response Practices: Waroom's Features and Future Challenges @rrreeeyyy 1 1 Waroom Meetup #2 | Ryota Yoshikawa ( @rrreeeyyy ) Waroom Meetup #2 | Ryota Yoshikawa ( @rrreeeyyy )

Me 株式会社 Topotal CTO/SRE (2021/06 〜) SRE as a Service® いろいろな会社さんの SRE 導入・改善のお手伝いをさせ てもらっています https://topotal.com/servi ces/sre-as-a-service Waroom® インシデント対応を楽にする ためのインシデントマネジメ ント SaaS を作っています https://waroom.com/ 2 2

Waroom and Me Topotal 創業時に「インシデントマネジメント SaaS をやろう」と言いました 「Waroom」というサービス名を決めました ご明察の通り War room から来ているのがメインの理由です waroom-backend を rails new しました (Waroom は Rails で開発しています) Rails, GraphQL (graphql-ruby), EKS (Fargate), Aurora MySQL, ... アーキテクチャや Waroom 自体の裏側はどこかの機会でまた発表したい Waroom のバックエンド領域の技術選定や（初期の）機能開発をほぼやっていました 初期にインシデントレスポンスのペインの洗い出しと解決策の検討をしました Google Docsで30ページ以上掛けた (w/ @nari-ex, @yuuk1, @sawa-zen) 今でも技術選定はもちろん難しめの機能開発や色々な意思決定に関わっています 最近は少なめですがバックエンドの最多 commits / additions / deletions です 3 3 Waroom Meetup #2 | Ryota Yoshikawa ( @rrreeeyyy ) Waroom Meetup #2 | Ryota Yoshikawa ( @rrreeeyyy )

Waroom Meetup #2 | Ryota Yoshikawa ( @rrreeeyyy ) Waroom Meetup #2 | Ryota Yoshikawa ( @rrreeeyyy ) 4 4

Waroom Meetup #2 | Ryota Yoshikawa ( @rrreeeyyy ) Waroom Meetup #2 | Ryota Yoshikawa ( @rrreeeyyy ) 5 5

Waroom Meetup From Waroom Meetup #1 ( https://topotal.connpass.com/event/317285/ ) この文章の元を書いたのは自分です この発表でも一般に参考になるインシデントレスポンスのプラクティスを紹介します もちろん自分も参考にしているので対応する Waroom の機能も紹介します まだまだ実装できていないところもあるので私見でこうなるといいなも書きます Waroom を使う・使わないに関わらずインシデント対応の改善に繋がると嬉しいです イベントタイトルがWaroom Meetupになっておりますが、Waroomに限ら ずさまざまなインシデントSaaSのプラクティスを共有いただきたいと、私た ちは考えています。これは、国内のインシデントレスポンスの事例を幅広く増 やし、国内のインシデントレスポンスがよりよくなることをWaroom Meetup が目指しているためです。また、その事例を参考にWaroomの開発を進めてい き、よりよいインシデントマネジメント SaaS になることも目指しています。 6 6 Waroom Meetup #2 | Ryota Yoshikawa ( @rrreeeyyy ) Waroom Meetup #2 | Ryota Yoshikawa ( @rrreeeyyy )

Incident Response Practices Resources Waroom の開発においては様々なインシデント対応関連の情報を参考にしています 開発初期に参考にした（今も参考にしている）情報は特に次の通りです Incident Management for Operations 界隈では有名(?)な消防士が表紙の本です 米国で災害時等に利用される Incident Command System (ICS) を参照 この本では ICS の説明や IT システムでの適用について主に論じている Site Reliability Engineering | Chapter 14 - Managing Incidents 同様にICSを参照するGoogle内の実務的なプロセス (IMAG) が書かれる Site Reliability Workbook | Chapter 9 - Incident Response PagerDuty のインシデント対応プロセス と前述の IMAG を参照 インシデント対応のケーススタディを行いつつフレームワークの説明 7 7 Waroom Meetup #2 | Ryota Yoshikawa ( @rrreeeyyy ) Waroom Meetup #2 | Ryota Yoshikawa ( @rrreeeyyy )

Incident Management Guide インシデント対応をフェーズごとに分けて考える どこがボトルネックになっているか・何をすればよいかが比較的考えやすい Incident Management Guide では以下のように分類される Prepare Detect Triage Mitigate Resolve Learn Remediate 今回はこれを参考にそれぞれのプロセスにおいて以下を紹介していきます 世の中に書かれているプラクティス / 参考になるリソース / 自分の考え Waroom の機能 / 機能に対する(なるべく公正なつもりの)現状の自分の評価 8 8 Waroom Meetup #2 | Ryota Yoshikawa ( @rrreeeyyy ) Waroom Meetup #2 | Ryota Yoshikawa ( @rrreeeyyy )

Prepare phase - 1 インシデント発生前の計画と準備を行う段階 Practice: インシデント対応計画 (Incident Management Plan) を策定する e.g. インシデントを検知・宣言するまでの流れを決定する 特定の Slack チャンネルで宣言する などを事前に決めておく インシデントの分類・優先度付け 重大度・影響範囲・緊急性などとそれらの決定方法などを整理しておく ロールの割り当て・エスカレーション方法の決定 どのようなルールで各人にロールを割り当てるか？ インシデント対応時のコミュニケーション方法の決定 どのチャンネルでコミュニケーションを取るか？ 参考: Creating an Efficient IT Incident Management Plan: A Guide to Templates and Best Practices by Squadcast 9 9 Waroom Meetup #2 | Ryota Yoshikawa ( @rrreeeyyy ) Waroom Meetup #2 | Ryota Yoshikawa ( @rrreeeyyy )

Waroom Meetup #2 | Ryota Yoshikawa ( @rrreeeyyy ) Waroom Meetup #2 | Ryota Yoshikawa ( @rrreeeyyy ) 10 10

Prepare phase - 2 Practice: インシデント対応の手法を示したランブックを用意する サービスの正常性確認方法・重大度の決定方法など対応時にやることを整理する 特定のアラートに紐づくインシデントならばより具体的なランブックを用意できる Practice: インシデント対応中の作業を可能な限り自動化する 影響範囲の自動分析, 根本原因調査のための情報整理, 軽減策の提案 参考: Google Site Reliability Engineering- Incident Management Guide 11 11 Waroom Meetup #2 | Ryota Yoshikawa ( @rrreeeyyy ) Waroom Meetup #2 | Ryota Yoshikawa ( @rrreeeyyy )

Prepare phase w/ Waroom インシデント対応では事前の準備がどれくらいできているかが非常に重要 動き方が決まっていないインシデント対応は遅くなる上に負荷も高いと感じる Waroom の評価 導入により宣言方法・分類やコミュニケーション手法はある程度決定されそう インシデント対応中の情報のサマライズが自動で行われる インシデントに紐づく Runbook 機能がある Runbook を頑張って書かなければならない ポストモーテムなどからある程度生成できるようにしたい 組織にあったインシデント対応計画は割と頑張って作らなければならない Waroom によるアシストがもっとあっても良いと思っている 重大度や影響範囲の決定も人間が頑張って行う必要がある インシデントの経過時間と影響範囲から重大度は算出できそうと考えている 12 12 Waroom Meetup #2 | Ryota Yoshikawa ( @rrreeeyyy ) Waroom Meetup #2 | Ryota Yoshikawa ( @rrreeeyyy )

Waroom Tips: インシデントステートドキュメントテンプレート Waroom のインシデントステートドキュメント機能について 対応チャンネルでの Slack での会話を AI が自動でサマライズする機能 もしくはチーム間でドキュメントを共同編集することができる インシデントステートドキュメントはテンプレートを書くことができる テンプレートが AI に対する指示そのものになっている 例えば「原因の候補を列挙してください」などが書ける Slack の会話から原因の候補を列挙してもらえる 他にも例えば「今日の天気を記載してください」みたいなこともできる 別に現状は正しい天気が記載されるわけではない...... 上手く使えばインシデント対応の自動化に寄与することができそう 上手い使い方があればぜひ教えて下さい 13 13 Waroom Meetup #2 | Ryota Yoshikawa ( @rrreeeyyy ) Waroom Meetup #2 | Ryota Yoshikawa ( @rrreeeyyy )

Waroom Tips: インシデントステートドキュメントテンプレート 14 14 Waroom Meetup #2 | Ryota Yoshikawa ( @rrreeeyyy ) Waroom Meetup #2 | Ryota Yoshikawa ( @rrreeeyyy )

Waroom Meetup #2 | Ryota Yoshikawa ( @rrreeeyyy ) Waroom Meetup #2 | Ryota Yoshikawa ( @rrreeeyyy ) 15 15

Detect phase インシデントの兆候を早期に発見する段階 Practice: 信頼性の高いアラートメカニズムを利用する 優れたアラートメカニズム アラートがタイムリーに発生する ユーザが利用する主要な機能をカバーできている 原因ではなく症状に基づくアラートである 対処が可能なアラートである SLO (w/ burn-rate) によるアラートはこれらを満たすことが可能な手法の一つ Practice: 人間によるインシデント起票 システムによる監視はインシデントを検知するためのパーツの 1 つ サポートチームが問い合わせを受けたときにインシデントを宣言できると良い 参考: PagerDuty - What is an Incident? | Human Escalation 参考: Incident Management Guide 16 16 Waroom Meetup #2 | Ryota Yoshikawa ( @rrreeeyyy ) Waroom Meetup #2 | Ryota Yoshikawa ( @rrreeeyyy )

Detect phase w/ Waroom 優れたアラートメカニズムを利用することで良いインシデント対応を継続できる 無闇にアラートを仕掛けていくと Alert Fatigue を引き起こす可能性もある 数が多いとインシデントは起票されるが対応されず放置...のような懸念もある プロダクトに関わるすべての人間がインシデントの宣言を行える状態であってほしい Waroom の評価 アラートに対して Runbook を紐づけることができる 「対処が可能なアラート」の余地を広げることができる ユーザ数による課金がないので組織内のすべてのユーザが Waroom を使える どのユーザも Waroom を利用して同じフローでインシデントの宣言が可能 アラートシステムとの深い連携などは今のところ無い 例えば SLI/SLO アラートの場合は特別扱いする事ができるかもと思っている 他のシステムアラートと bundle してしまうとか アラート・モニタリングシステム側ともっと連携できないか考えている 17 17 Waroom Meetup #2 | Ryota Yoshikawa ( @rrreeeyyy ) Waroom Meetup #2 | Ryota Yoshikawa ( @rrreeeyyy )

Triage phase インシデントの影響度を評価し、対応の優先順位を決定する段階 Practice: 重大度に応じたインシデントの分類 インシデント対応計画の項とも重複するが重大度にまつわる事項を事前に決める 重大度の決定方法 多くの顧客が機能を利用できない時間が n 分続いた場合は High、など 重大度に応じたインシデント対応方法 Severity: High では即時エスカレーションを行い対応を開始する、など 判定に迷ったケースでの対応方法 迷っているうちの高い方のレベルを設定して対応を開始する、など Practice: インシデントのグルーピング 重大度の高いインシデントと関連するインシデントをグルーピングする インシデントの認知負荷の軽減や対応状況の管理を簡潔にすることができる 参考: PagerDuty - Severity Levels 18 18 Waroom Meetup #2 | Ryota Yoshikawa ( @rrreeeyyy ) Waroom Meetup #2 | Ryota Yoshikawa ( @rrreeeyyy )

Triage phase w/ Waroom 複数のインシデントが発生した際に優先順位をつける事でユーザ影響が少なくなる 対応者にとっても対応方針や温度感が明確になり対応しやすくなる Waroom の評価 （当然）インシデントに対して重大度を定義することができる 一方重大度の定義はユーザごとに異なるので頑張って作る必要がある 作ったものを Waroom 上で参照できるような状態にしたいと思っている 重大度に応じた Waroom の振る舞いの変化が乏しい 現状単に分類するだけのラベルになっているのでもっと活用したい 重大度の自動判定（提案）や重大度に応じたアクションの変更など？ 重大度に応じて表示する Runbook を変えたいケースもある？ インシデントのマージやグルーピングは現状だとできない 手動でマージ・グルーピングできるだけだと有り難みが少ないと思う AI などでマージ・グルーピングを提案するのが良さそう？ 19 19 Waroom Meetup #2 | Ryota Yoshikawa ( @rrreeeyyy ) Waroom Meetup #2 | Ryota Yoshikawa ( @rrreeeyyy )

Mitigate & Resolve phase (Fixing phase) 影響を最小限に抑える一時的な対策 / 根本原因の特定と恒久的な対策を行う段階 Practice: 3C (coordinate, communicate, control) 明確な役割・タスク・コミュニケーションチャネルを持つ対応組織を構成する インシデントコマンダー,コミュニケーションリード,オペレーションリード... Practice: ユーザ中心のインシデント対応 時間の掛かる恒久対応ではなくすぐにできる緩和策を適切に選択する 影響の受けているユーザに対して対応状況の共有を随時行う 適切なユーザコミュニケーションは技術的な緩和策と同じぐらい大事である 参考: Google Site Reliability Engineering: Incident Management Guide 参考: Site Reliability Engineering | Chapter 14 - Managing Incidents 20 20 Waroom Meetup #2 | Ryota Yoshikawa ( @rrreeeyyy ) Waroom Meetup #2 | Ryota Yoshikawa ( @rrreeeyyy )

Mitigate & Resolve phase (Fixing phase) w/ Waroom 適切なインシデント対応組織の構成と優先順位付けがプロダクトの信頼性を守る 単に対応するのもそうだがユーザに対するコミュニケーションも同様に大事 Waroom の評価 Runbook を step-by-step で表示し実施の管理をすることができる インシデントステートドキュメントが自動で生成され最新の状態に保たれる インシデントコマンダーやコミュニケーションリードの負荷を下げられる それぞれのロールのアクションや意思決定のアシストが十分でないと感じる コマンダー用の Runbook やリマインダ機能などを過去検討していた 対ユーザやステークホルダーに対するコミュニケーションも楽にしたい 緩和策・原因・復旧策の提案などにも取り組んで行きたい 21 21 Waroom Meetup #2 | Ryota Yoshikawa ( @rrreeeyyy ) Waroom Meetup #2 | Ryota Yoshikawa ( @rrreeeyyy )

Learn & Remediate phase (Post-incident reviews: PIR) 得られた教訓の組織全体での共有 / システムやプロセスを改善し再発防止を行う段階 Practice: 非難なきポストモーテムの文化 インシデントを対応だけで終わらせずに対応改善の機会と捉える 当該のインシデントに関わる事象だけではなく Practice: インシデント対応訓練を行う 実際の環境を模した環境などで対応訓練を行う 参考: ACM Queue - Weathering the Unexpected Google の DiRT (Disaster Recovery Testing event) の例 Wheel of Misfortune 形式の訓練 インシデントのシナリオを用意しておきゲームマスターと対話式で対応を行う 参考: Google Site Reliability Engineering: Incident Management Guide 22 22 Waroom Meetup #2 | Ryota Yoshikawa ( @rrreeeyyy ) Waroom Meetup #2 | Ryota Yoshikawa ( @rrreeeyyy )

Learn & Remediate phase (PIR) w/ Waroom 単にインシデントの対応だけでなくそこから学び改善を得るのが大事 多くの学びを得ることでインシデント対応の速度・プロダクトの信頼性に繋がる Waroom の評価 ポストモーテムの自動生成機能があり書く敷居がかなり低い Tips で紹介したテンプレートと同様のものがポストモーテムにもある 任意のプロンプトを AI に対して投げることができる 対応訓練機能があり実際に演習しながら改善が行える 現状のクオリティは大分低い (頑張ります) 将来的にはポストモーテムなどから自動でシナリオを生成したい インシデントのメトリクスを用いた可視化によって振り返りがしやすい ポストモーテムのアクションアイテムのトラッキングがしたい Waroom にポストモーテムを書いた後のステータスを追いづらい インシデント対応計画の定期的な見直しなども取り組みたい 23 23 Waroom Meetup #2 | Ryota Yoshikawa ( @rrreeeyyy ) Waroom Meetup #2 | Ryota Yoshikawa ( @rrreeeyyy )

Waroom Meetup #2 | Ryota Yoshikawa ( @rrreeeyyy ) Waroom Meetup #2 | Ryota Yoshikawa ( @rrreeeyyy ) 24 24

Waroom Meetup #2 | Ryota Yoshikawa ( @rrreeeyyy ) Waroom Meetup #2 | Ryota Yoshikawa ( @rrreeeyyy ) 25 25

Conclusion インシデント対応のフェーズごとにプラクティスと参考リソースを紹介しました 実際に Waroom の開発を行うにあたり様々な資料を参考にさせて頂いています 各フェーズ・プラクティスに対しての考えと現状の Waroom の評価を行いました まだまだ改善が必要な箇所は多いという認識はもちろんあります ようやく何とか使えるレベルまでこぎ着けた...という感覚 一方 rails new した頃から考えると遠いところまで来たなという感覚もある 自分で挙げた以外にもいろいろなフィードバックを求めています サービス公開以降自分たちの想像を遥かに超えたフィードバックを頂けて幸福です Waroom のトライアルは 1 ヶ月無料なのでぜひ試してみて下さい!! 26 26 Waroom Meetup #2 | Ryota Yoshikawa ( @rrreeeyyy ) Waroom Meetup #2 | Ryota Yoshikawa ( @rrreeeyyy )

!!We are Hiring!! https://jobs.topotal.com/ に今すぐアクセス!! Waroom のトライアルも募集中 https://waroom.com/ に今すぐアクセス !! 27 27 Waroom Meetup #2 | Ryota Yoshikawa ( @rrreeeyyy ) Waroom Meetup #2 | Ryota Yoshikawa ( @rrreeeyyy )