This is the public roadmap for Waroom. We hope that by publishing the features we will add and their priorities, it will help you in your future planning. Customers can send feedback and inquiries through this repository.
License: Creative Commons Attribution Share Alike 4.0 International
インシデントにアクションアイテムを紐付ける際に、GitHubに対してシームレスに起票したい。
インシデントの情報をもとにGitHub上にチケットを起票できるようにする。
インシデントの起票が生じた際に Waroom の情報を外部サービスへ送信したい。
Webhook 機能を実装する。
https://api.beta.waroom.com/graphql が500エラーを返却しており、トップページが画像のようになっていました。
インシデントを作成する際、デフォルトでは「発生時の状況」という項目は空欄のフォームが表示される。
組織によってはインシデント発生時に決まった内容を入力するフローが存在しているケースがあり、そのような場合は入力フォームにテンプレートを挿入できるとよい。
インシデント起票時に利用するテンプレートを実装する。
インシデント対応のベストプラクティスの一つとして、役割のアサインがある。特にインシデントコマンダーのアサインはインシデント対応の開始時に行うべき重要なタスクだが、インシデントコマンダーを選出は人間が行う必要がある。
インシデントコマンダーとして任命された場合の負担はわりと大きいことから、アサイン時に心理的障壁が影響してアサインがされなかったり判断が遅れる場合がある。「誰か一人にアサインする必要があるが、誰がアサインされてもよい」状況においては迷う時間が単純なオーバーヘッドであるため、迅速にアサインがされることが望ましい。
インシデント対応チームの中から無作為にインシデントコマンダーをアサインする機能を実装する。
インシデントごとに専用チャンネル1を作成すると情報の分散が問題になる。この点については、以下のTweetでも議論が行われている。
refs: https://twitter.com/this_hits_home/status/1559328022854922241
情報の分散が起きると、メインチャンネル2に期待するインシデントに関する情報共有機能が失われたり、同一インシデントを複数のチームが対応して二次障害が起きたり、インシデントの状況を知るためにわざわざ別チャンネルに移動する手間が生じる。
この課題を解消するために、専用チャンネルの情報をメインチャンネルに同期的に共有したい。
各インシデントの詳細な情報は専用チャンネル、ざっくりした情報はメインチャンネルで読み取るという使い分けができるようにしたい。現在のWaroomの仕様では、起票時の情報はメインチャンネルで行われるため、起票以降のインシデント対応情報を共有すればよい。
対応詳細に関する情報は専用チャンネルで読み取ることを想定すると、メインチャンネルでは現在発生しているインシデントの状況を把握できればよい。インシデントの状況はWaroom上のインシデントステータス（Detected、Investigating、Fixing、Resolved、Close）から読み取れるため、その情報をメインチャンネルへ共有する。
インシデント対応中にWaroomのインシデント詳細画面を参照したい場合は、Slackの一番上のメッセージを辿ってWaroomにアクセスする必要がある。
インシデントが長期化してメッセージの数が増えた場合にスクロールバックするのは手間なので、素早く詳細画面へのリンクが踏めるような状況にしたい。
専用チャンネル内のSlackのブックマーク機能を用いることで、詳細画面へのアクセス経路を確保する。
現在のWaroomは、日付ベースのprefix( yyyymmddhhmmss- )が付与して専用チャンネルを作成する仕様となっており、ユーザーはprefixを変更できない。
日付ベースのprefixだけではチャンネル名から障害の状況が読み取りづらい。また、Slackのサイドバーの幅は限られているため、長いprefixを付与してしまうとインシデントを識別する文字列の部分が隠れてしまい、チャンネルの識別が困難になる。
また、特定の環境ではSlackワークスペース全体のチャンネル命名規則が厳密に定められており、チャンネル名を命名規則通りに設定できない場合は専用チャンネルを作成できない状況に陥るケースがある。
そのため、専用チャンネルに任意のprefix付与をできるようにすることで、一貫性のある統一されたチャンネル作成を実現し、上記の課題を解決したい。
専用チャンネルに対して任意のprefixを付与できるようにする。
また、設定の柔軟性を高めるために、prefixの設定は組織ごとではなくサービスごとに設定できるものとする。
Mackerelのアラート通知をトリガーにインシデントを起票したい。
Mackerelインテグレーションを実装する。
現状はユーザー登録時に決定したアイコンを変更することができないので、変更可能にしたい。
Slackのプロフィール画像を読み込んでWaroomに反映する。Waroomのプロフィール画像としてSlackの画像を反映する契機は、Slack上で /waroom signin を実行したときを想定する。
現状のWaroomは、インシデント対応後に行うべき改善タスク（アクションアイテム）を管理していない。インシデントステートドキュメントやポストモーテムにテキスト入力することはできるが、アクションアイテム専用のエリアではないので認識ししづらい。
そのため、インシデントごとにアクションアイテムを登録できるようにしたい。
インシデントごとにアクションアイテムを登録するための仕組みをつくる。
※ JIRAやGitHubなどのチケット管理ツールへのシームレスな登録は別のチケットで扱う。
機密情報を含むインシデント対応やセキュリティインシデントの対応時、専用チャンネルを作成する際にプライベートチャンネルを作成したい。
専用チャンネル作成時にプライベートチャンネルを作成できるようにする。
現状のWaroomでは、インシデントに対してCRITICAL、HIGH、LOW、INFOの4段階のSeverity設定できるが、組織によっては、すでにSeverityを運用しており、その内容に合わせて3段階にしたりラベルをP0〜P3にしたいという要望がある。
そのため、Severityをカスタマイズできるようにしたい。
Severityの数と名前をカスタマイズできるようにする。
New Relicのアラート通知をトリガーにインシデントを起票したい。
New Relicインテグレーションを実装する。
現状、インシデントに対してWaroomが予め用意したラベル（Severityや原因カテゴリなど）の付与はできるが、それ以外のラベルを付与することはできない。
インシデントのデータを顧客ごとの対応フローや分析の切り口に合わせて活用可能にするために、任意のラベルをインシデントに対して付与できるようにしたい。
インシデントに対して任意のラベルを付与できるようにする。また、インシデント一覧画面でラベルを指定してフィルタリングできるようにする。
インシデント状況をエンドユーザーに伝えるために、Waroom に集められた当該インシデントの情報とステータスページをリンクしたい。
Waroom の情報をもとにステータスページを自動的に更新する仕組みを構築する。
現在、期間を絞ってインシデントを表示する際に「未解決」「解決済み」に分かれてしまっている
「未解決」「解決済み」に限らず特定期間のインシデントの一覧を出したい
インシデントを振り返る際に一覧として出力されて、ステータスはラベル的に見えた方がスムーズに振り返りが実施できる
期間を絞ってインシデントを表示する際にステータスによらず一覧を表示する
現在はインシデントが解決済みかどうかの属性を選択することでしかインシデントのフィルタリングができない。
そのため、インシデントに紐づくサービス、期間、原因、重篤度（Severity）などのメタデータをもとにフィルタリングができるようにしたい。
フィルタリング機能を一覧画面上に実装する。
また、フィルターの内容はURL内のクエリとして設定できるようにする。
※↑定期的にインシデントを確認する場（SRE定例）などで毎回同一のフィルタリングが行われた一覧画面を表示できるようにすることが狙い。
ポストモーテムは、対応過程を振り返ったり再発防止を検討する際に有効であり、SRE の代表的なプラクティスの一つである。しかし、実際に書いてみると（自分はすでに理解している）タイムラインの作成は退屈だし、ポストモーテムのテンプレートに記載された項目を埋め終わるまでに多くの時間がかかる。結果として、ポストモーテムの作成の負荷が大きいと感じる人は珍しくない。
また、ポストモーテム作成の負担が大きいことが、組織的にポストモーテムを実践するシーンのブロッカーになっていると考えている。心理学 NLP の前提の一つに「いつでも現在可能な最善を尽くしている」という項目がある。ポストモーテムを書くケースに当てはめて考えると、得られる学びの量に対してポストモーテム作成の負荷が十分に大きいと感じる人はポストモーテムを書かないだろう。特に、ポストモーテムを書き慣れていない人であればあるほどこの傾向は強まるため、SREs が SRE を権限移譲するシーンでも重要なトピックである。
上記の理由から、SREs のみならず組織的にポストモーテムを実践する上でも重要であるポストモーテム作成時の負担軽減を行いたい。
インシデント対応中に得られた情報をもとにポストモーテムのたたき台を生成することで、ポストモーテム作成の負担を軽減する。
また、ポストモーテムの生成はWeb画面上のボタンや Slack コマンド1つで行えるものとする。
インシデント対応者は「起きていること、わかっていること、やったこと」などを複数人に対して同時にシェアしたいが、日々利用しているチャットツールでは情報が流れるので共有しづらいし、タスク管理ツールでは手軽に編集しづらい。SRE 本の「14.3.3 Live Incident State Document」にもある通り、インシデント中の情報を整理してドキュメントを常に最新の状態に保ち続けるためには、数人が同時に編集できる状態が理想系である。
インシデント対応に慣れている多くの企業では何らかの方法でインシデントの管理を行っているが、それらのツールはたいていライブドキュメント機能がない。そのため、現場では Google Docs や Scrapbox などのドキュメンテーションツールを利用することになり、ツールの分散が生じる。結果として、分散した情報を紐付ける手間がかかったり情報の一覧性が低下したりと様々な課題が生じる。
各インシデントの詳細画面に共同編集ができるスペースを設ける。暫定的なデザイン案は以下の通り。
現状では、Waroom上でポストモーテムを作成する際は、ベストプラクティスに基づいて定義されたポストモーテムテンプレートが利用される仕様となっており、テンプレートを変更することはできない。
組織内の運用に合わせてポストモーテムを実施するために、テンプレートをカスタマイズできるようにしたい。
ポストモーテムのテンプレートを変更できるようにするために。
GCPのCloud Monitoringのアラート通知をトリガーにインシデントを起票したい。
Cloud Monitoringインテグレーションを実装する。
セキュリティ上の観点から二要素認証、Passkey等に対応する
二要素認証、Passkeyを実装する
サービス運用を行う多くの企業は、インシデントが発生してから解決するまでの時間が必要以上に長引いてしまうことを望んでいない。可能な限り効率的に対応をするために、モニタリングツールやインシデントマネジメントツールなどを駆使して業務プロセスを構築している。
インシデント対応を行う仕組みが整った先でも改善の余地はある。他の業務改善と同様に、インシデント対応プロセスに対しても過去の傾向を把握し、改善につなげる試みをしたい。
しかし、インシデント対応プロセスを振り返るのはむずかしい。理由は、インシデント対応プロセスのどこに問題があったのかを定量的な判断するための環境が整っていないためである。本来的には、過去のインシデント対応を集計してどの工程でどのくらい時間がかかったのかを知る必要があるのだが、それらを手動で計測するのは現実的ではないし自動的に収集する仕組みをつくるのもむずかしい。
このような背景から、Waroom を利用してインシデント対応を普段通り行うだけで、振り返りや分析に利用できるメトリクスの収集と可視化を自動的に行いたい。
インシデント対応の改善を行うために必要なメトリクスの収集と可視化を行う。
なお、メトリクスの収集は Waroom が検知できるアクションに紐づいて自動的に取得されるものとする。
現在のWaroomは、メインチャンネル1で対応することが想定されており、特定のケース（severityがCRITICALに変更されたインシデント）のみ専用チャンネル2が作成される。この仕様の課題は以下の通り。
severityの値に関わらず、1つのインシデントに対して1つの専用チャンネルを作成できるようにする。なお、専用チャンネル作成の契機は起票と同時に行うのではなく、起票時に投稿される通知に設置されたボタンを押下したときとする。起票と同期的にチャンネル作成を行わない理由は主に以下の2点。
Web 画面や Slack App 以外からも柔軟にインシデントの追加や更新、削除などのオペレーションをできるようにしたい。
Waroom APIs を公開する。
ポストモーテムやアフターアクションレビュー（AAR）を通して根本原因とその対策方針が明らかになった場合は、改善に必要なアクションアイテムをタスク管理ツールに起票して進めるのが一般的である。このとき登録したタスクの優先順位が上がらずに完了しないケースが起きることは珍しくない。
上記の状態に問題があるかどうかは、当該インシデントの再発率や他のタスクの重要度によっても判断が分かれる部分なので言及しないが、さまざまなアクションアイテムが完了したか終わったかどうかがわからない状況は問題である。
特に、各個人が認識していてもチームが状況を把握していない場合は、個人のキャパシティを越えてアクションアイテムがアサインされたり、対策済み（または対策前）と勘違いしてオペレーションをすることで問題が生じるリスクがあるので、インシデントの対策状況はチーム全体で共通認識を持つべきである。
そのため、アクションアイテムの実施状況を確認できるようにしたい。
インシデントごとに紐づいたアクションアイテムの実施状況を俯瞰的に確認できるような可視化機能を実装する。アクションアイテムの完了ステータスは、チケット管理ツール上のステータスをソースとする。
インシデント対応を行う際、過去のインシデントを参考に対応することがある。特に、Waroomを活用することでインシデント対応の情報がストックされるようになった先では、類似インシデントを確認することで復旧対応を効率化することが出来る可能性がある。
そのため、類似インシデントを簡単に確認する仕組みがほしい。
インシデントが発生した場合に、過去に当該インシデントに類似したインシデントを検索して提示する機能を実装する。
インシデントの起点になるイベントは、モニタリングツールから発火されるアラート通知や顧客からの問い合わせなどがある。
現在のWaroomインテグレーションを活用することで、各種SaaSから送信される通知をトリガーにインシデントの作成ができるが、それ以外の情報をソースにインシデントの起票をすることはできない。
Slackメッセージをベースに起票ができるようになれば、インテグレーションが未実装だがSlackに通知している場合やSlack上で行われた問い合わせをインシデントの発火元として明確に指定することができる。
このような背景から、インシデントソースの指定をより広範囲に設定できるようにするために、Slackメッセージからインシデントを起票したい。
Slackメッセージからインシデントを起票できるようにする。
具体的には、メッセージの右上のオプションから"Create Incident"が実行する操作を想定している。
インシデントの代表的な原因の一つとしてアプリケーションコードの変更がある。日常的に新しいコードをリリースする環境の場合、インシデント発生時に真っ先に確認するのは直近で変更されたコードの内容である。
上記のような「障害発生 → デプロイ情報の確認」という典型的な対応プロセスを負荷を減らすために、インシデント情報とデプロイ情報を紐付けたい。
各インシデントの詳細画面に、直近のデプロイ情報を表示する。そのデプロイ情報にはリンクが含まれており、ワンクリックでコード管理ツールへ遷移するできるものとする。
組織的なインシデント対応を実現できるかどうかは、インシデントに慣れていないメンバーを巻き込むことができるかどうかが重要である。
教育やトレーニングの仕組みがない場合、インシデント対応スキルは復旧対応の経験量に比例して積み上がる。組織内の多くのメンバーが経験を積むことができれば問題ないが、実際の復旧対応の現場では迅速な復旧を最優先する影響で、対応慣れした特定のメンバーが何度も繰り返し復旧を行うことが多い。結果として、インシデント対応に慣れていないメンバーと対応慣れしたメンバーの対応力の差は広がり続ける構造に陥ってしまい、属人化が加速する。
インシデント対応ができるメンバーを一人でも多く増やす手段の一つとして、インシデント対応訓練の導入が挙げられる。実際、Datadog社では半年に一度インシデント対応を行う習慣がある。
refs: https://www.datadoghq.com/ja/blog/engineering/2023-03-08-deep-dive-into-incident-response/
Because we (like our customers) have high expectations for availability, we have a relatively low threshold for declaring incidents. A secondary effect of this is that we regularly undergo our incident management process, which helps keep our engineers up to date on tooling and incident response. We also require all engineers to complete comprehensive training before going on call and a refresher training session every six months.
しかし、インシデント対応訓練の仕組みを構築するには、専門性の習得と多くのエンジニアリングリソースの確保が必要であるため用意ではない。
そのため、手軽にインシデント対応プロセスを体験することができる訓練の仕組みがほしい。また、訓練を通してインシデント対応のベストプラクティスが学べることが理想である。
WHYに記載した背景や意図を加味し、以下を満たすような対応ゲームをWaroom上に実装する。
なお、このゲームは実際の障害対応時の状況に近づけるためにSlack上で遊べる仕様とする。
Waroom上でデプロイ情報を確認するためには、WaroomのAPIに対してデプロイ情報を送信する仕組みをユーザーが独自に構築する必要がある。この導入作業を楽にしたい。
Waroomに対してデプロイ情報を送信するためにGitHub Actionを作成する。
Waroom 上で @ メンション付きのコメントをしたとき、Slack への通知でもメンションしたい。
Waroom ユーザ ID と Slack ユーザ ID を紐付ける。
これにより、Slack 上に通知する際に Waroom ユーザ ID が Slack ユーザ ID へ変換され、メンションが行われるようになる。
コード起因のインシデントを対応する際、直近のコードの変更内容を知りたいケースがある。
上記のケースではたいていコード管理ツールを参照するが、よりシームレスに対応を行うためにSlackから離れることなくデプロイ情報を確認したい。
Waroomに収集されたデプロイ情報をSlackのSlashコマンドから確認できるようにする。
インシデント対応のために専用チャンネルを作成し、復旧対応を終えた後にチャンネルアーカイブをしないまま放置した場合、以下の例のようにSlackチャンネルが乱立してしまい、Slackのチャンネルリストビューが崩壊して生産性に影響が出る。
https://x.com/this_hits_home/status/1559328022854922241?s=20
そのため、復旧対応後に自動的にチャンネルをアーカイブしたい。
インシデントのステータスを復旧やクローズした場合に専用チャンネルを自動的にアーカイブする機能を実装する。
障害の状況をライブインシデントステートドキュメントに記述する際、ドキュメントのテンプレートを用いて入力をしたい。
現状の仕様はWaroomが提供するテンプレートが挿入されるしようなので、ユーザーがテンプレートを柔軟にカスタマイズできるようにしたい。
組織毎に Live Incident State Document のテンプレートを登録し、インシデント作成時に利用できるようにする。カスタムテンプレートがない場合はWaroomが用意したデフォルトテンプレートを表示する。
現在のWaroomはSlackに対する通知はできるが、各ユーザーごとに通知を管理していない。
インデント対応のロールアサイン、ポストモーテムのレビューのやりとりやフォローアップアクションのアサインなど、今後実装される予定の機能を活用した先で、自身に対する通知の管理を行う必要性が出てくる。
そこで、ユーザーごとに届いた通知をWeb上で確認できるようにしたい。
Web上で自身に対する通知の一覧を確認できるようにする。通知はメンションやアサインなど個人に紐づくアクションを行った際に送信されるものとする。
インシデントにアクションアイテムを紐付ける際に、JIRAに対してシームレスに起票したい。
インシデントの情報をもとにJIRA上にチケットを起票できるようにする。
インシデントの情報を関係者へ共有するシーンでは、インシデント対応中に得られた膨大な情報を要約する必要がある。要約作業は手間なので自動化したい。
インシデント概要の生成を自動化する。
インシデントのステータスの変更が遅れたりインシデントのクローズを忘れたりした場合、Waroomで認識する復旧時刻は実態に即したものにはならない。
上記のようにメトリクスが意図した結果になっていないケースが生じた際に、手動でメトリクスを修正できるようにしたい。
インシデントごとにメトリクスを修正するための機能を実装する。
現状はWeb UIのインシデント詳細画面でのみインシデント対応時のロール（インシデントコマンダーとインシデントレスポンダーのみ）をアサインすることができる。
ただ、Web上にアサイン機能は実際にインシデント対応を行うシーンでは使いづらいため、Slack上からロールのアサインができるようにしたい。
Slack上のインシデント開始時点でロールのアサインを簡単に行うことができるボタンを用意する。
また、現在はロールアサイン時にSlack通知が飛ばず、共有する上で不便なのでロール変更時にSlack通知が行われるようにする。
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
Django
The Web framework for perfectionists with deadlines.
Laravel
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
Microsoft
Open source projects and samples from Microsoft.
Google
Google ❤️ Open Source for everyone.
Alibaba
Alibaba Open Source for everyone
D3
Data-Driven Documents codes.
Tencent
China tencent open source team.
