この記事はOptimind Advent Calendar 2023の9日目の記事となります。
みなさんこんにちは。オプティマインドの柏原です。
年の瀬なので、この機に今年取り組んだインシデント体制改善について振り返っていきたいと思います。
背景
オプティマインドでは1〜2年ほど前に社内のインシデント体制を整理し、対応手順書などの各種ドキュメントやオンコール体制など、インシデント対応をするために必要なものは一通り揃っていました。ここまで作り上げてくれていた先達には本当に感謝していて、良い仕組みで回っていたと思います。
しかし、直近では当時と比較してプロダクトの構成や社内の人数構成など、取り巻く様々な環境が変化しており、それに伴っていくつか課題が見えてきていたため、これまでの仕組みをベースにしつつ改善に着手してきました。
これまでの体制
課題の説明をする前にこれまでの体制を簡単にご説明します。
従来のオプティマインドにおけるインシデント対応フローは主に以下のような形でした。
- インシデント発報
- インシデントを検知すると、気づいたメンバーによってslackのワークフローにてインシデント発報がなされる。
- 既定のメンバーへの電話通知とslackチャンネルへのメンション付メッセージが投稿される。
- 対応準備
- 社内で定義されたインシデント深刻度に乗っ取り、非常に軽微なもの以外は対応するための準備に移る。
- 該当のslackチャンネル内でhuddleを開き、そのタイミングで対応可能なメンバーで対応チームを組成する。
- 対応チーム内でインシデントコマンダー、調査対応、顧客対応などの役割を分担する。
- 対応チームに必要なメンバーが不足しているときはエスカレーションフローに従って連絡を行う。
- 対応開始
- 技術的な要因や、影響顧客範囲などの調査結果を発報時に投稿されたメッセージのスレッドとして残し、都度サマリーをインシデントコマンダーがメンテナンスする。
- インシデントコマンダーの判断で終息状態となるまで継続される。
- 対応後
- ポストモーテムの担当者決めと開催日を決定する。
- ポストモーテム開催後は結果をslackに投稿する。
見えてきた課題
この仕組みはそれなりに上手く回ってきていたのですが、以下の問題を抱えていました。
- インシデントの深刻度が発報時点では不明な場合が多く、確からしい情報をつけることが難しかった。
- 発報直後はインシデントが起きたということは分かるが、何が起きたかなどの情報がslackに手動で投稿されるまでは分からないため、概要や関連しそうなチームなどが分からない場合がある。
- インシデントが複数同時に発報された場合に、コミュニケーションをどこでとるべきか判断に迷う。
- ポストモーテムによる学びの仕組みは存在するが、顧客報告を行うための情報がslackのスレッド内にしか残らないため、後から遡りにくい。
- インシデント体制を改善するためのオーナシップを持ったチームがないため、継続的かつ俯瞰的な改善が難しい。
- 対応フローに対するナレッジが新しく加入してくれたメンバーに浸透できず、段々と形骸化しつつある。
- 終息したかどうかがslackの投稿をみただけでは分かりづらい場合が多く、その後の対応のフォローが見過ごされるケースがあった。
- 暫定対応後に時間をおいて、別の根本的なリリースが発生するような場合に、その情報は各チームのスレッドなどで行われるため情報が分散し、関係者がキャッチアップすることが難しかった。
改善方針の調査
ということでまずは他社がどのように対応しているのかを調査しました。
その中で、GMOペパボ1さんや10X2さんが取り組んでいるようなインシデントbotを組み、インシデント毎に専用のチャンネルを生成し必要な情報をそこに集約し、報告プロセスもその仕組みに載せる対応をとれば上記の課題の大部分は改善できそうでした。
ただしここで、自分があまり自身のタスクマネジメントが上手くないこともあり、他のタスクに圧迫されこの改善作業に継続的に工数を割くことが難しいという問題がありました。かといって専任のチームも現時点ではいないため、なるべく維持することが容易で、少ない工数で簡単にやれる方法からステップバイステップで着手していくことにしました。
改善v1
まずは、これまで同様のslackワークフローを用い、ステップを追加するだけで簡単に解決できそうなことに対処する方針で進めました。
やったこと
インシデント発報時の初期情報記載フォームの追加
インシデント発報時に投稿されるメッセージに対して、温度感や起きた現象などのその時点で分かっている情報をフォームで入力してもらうように変更しました。
このフォームを埋めてSubmitすると、以下のように発報時点での初期情報がわかるようなメッセージが投稿されます。
これにより、slack上のインシデント投稿を一見すれば関連しそうなチームや担当者が主体的に飛びつきやすい状況を作ることができました。
体制解除ボタンの追加
発報時に投稿されるメッセージにインシデント体制解除ボタンを追加し、明示的にインシデント体制が解除されたかどうかを認識できる状態を作りました。これにより、インシデント通知に気付くのが遅れた他メンバーが今からでも参加すべきかどうかを迷うリスクを低減できました。
報告フォームの追加
体制解除ボタンが押されたら、報告用のボタンを投稿するようにステップを追加し、そのボタンを押すことで報告フォームが開く仕組みを作りました。また、これによって報告された内容はNotionに連携されログとして貯まっていく仕組みも同時に追加しました。
インシデントワーキンググループの発足
専任のチームもいない、自分も常に工数を避けるわけではないという状況の中で、継続的に改善を進めていくためには他のメンバーの力を借りることが重要だと思い、社内で有志を募り継続的な改善のアイデア出しやアクションに着手をするワーキンググループを作りました。
ありがたいことに数名が手を挙げてくださり、中にはBizRegionのメンバーも参加してくれていて、DevRegionに閉じないインシデント体制そのものに対する改善点などを定期的に話し合っています。具体的にはこれまで、ぬるっと特定のメンバーが対応してきた休日のオンコール体制などについてもどこまで・どのようにするのかなど、とても良い話ができていると思っています。
残る課題
これらの対応でかなりの部分の課題は改善されたため、一旦v1の対応としてはここまでとしましたが、以下の課題が残ったままの状態となっていました。
- インシデントが複数同時に発報された場合に、コミュニケーションをどこでとるべきか判断に迷う。
- 対応フローに対するナレッジが新しく加入してくれたメンバーに浸透できず、段々と形骸化しつつある。
- 暫定対応後に時間をおいて、別の根本的なリリースが発生するような場合に、その情報は各チームのスレッドなどで行われるため情報が分散し、関係者がキャッチアップすることが難しかった。
改善v2
改善v1で残された課題はありつつも、しばらくは運用でカバーしつつ数か月を過ごしていました。ある時、別件でslackのワークフローを触るタイミングがあり、その時に新しいslackワークフロー3が追加されていることに気が付きました。この新しいワークフローではslackチャンネルの生成などの新しいステップが追加されており、botの実装を行わずともやりたいことがパパっとやれそうに見えたのでv2の改善に着手しました。
やったこと
専用のチャンネルを生成するステップの追加
単一のチャンネル単一のメッセージスレッドで情報を管理するスタイルをやめ、インシデント発報と同時に専用のチャンネルを生成する方式にしました。従来までと同様に、ワークフローを実行し必要な初期情報を入力すると、専用のチャンネルが生成されると同時に共通のインシデントチャンネルに以下のような投稿がなされます。
生成された専用のチャンネル側では、指定されたメンバーが自動で招集されて来ると共に、slackワークフローより対応ステップの文面がチャンネルに投稿され、対応方法が明示されます。その後は、専用チャンネルの中で対応チームを組み、従来同様に対応を行っていくことになります。
また、体制解除後には以下のような事後対応依頼のメッセージも投稿されます。
これらにより、同時に複数のインシデントが発報された場合でも対応可能となり(あまり考えたくはないですが...)、また経験が浅いメンバーでも対応ステップを容易に把握することができるようになりました。また、専用のチャンネルを生成することにしたため、該当するインシデントに関連する情報を単一のチャンネル内の複数スレッドで管理することが可能になり、その上でリリースの情報なども基本的にこのチャンネルの中で報告するルールを決めたことで、一定情報の分散が抑えられていると思います。
残る課題
このv2までの取り組みを行ったことで、最初に記述した課題は現時点だとほぼほぼ解決したのですが、新しい課題というの継続的に出てくるもので今は以下のような課題を感じています。
- ステップは明示されど、ぬるっとインシデントコマンダーなどの役割分担が行われずに各種調査対応に着手される場合がある。
- インシデント体制の運用に対する教育などがないため、結局は時間の経過とともに特定のメンバーに役割やナレッジが集中しそう。
- 人数がさらに増えてきたため特定の人が言い出さなければポストモーテムが忘れられる場合がある。
- プラットフォーム的なアプローチでプロダクト横断的なインシデントリスクを下げられる試みがあるかもしれないが、ポストモーテムでは個別のチームに関連する要因に終始していて、あまりこの要素をちゃんと深掘れていない。
これらに対してはこれから、インシデントワーキンググループとはまた別の、技術に特化した改善方法を議論する品質改善グループを発足させたり、インシデント避難訓練的なものを考えていたりしますが、どう転ぶかはまださっぱりなのでこれからもいろいろとトライしていこうとおもいます。
まとめ
いい機会だったので今年ちょこちょことやっていたインシデント体制の改善内容についてまとめてみました。改善してきた中で、どうしてもすぐにプロセスや仕組みを追加したくなりますが、一歩踏みとどまって過剰になっていないかを考えるのは大事だなと感じたりしました。文化で解決できる部分はしっかり組織にメッセージングすることで醸成していき、仕組みで抑える部分はしっかり作るということを意識して、今後も改善を続けていきたいと思います。
最後に
本記事を読んでオプティマインドの組織について興味を持っていただけた方は、弊社採用資料により詳しい内容が書かれていますのでぜひご覧ください。また、もっと詳しく知りたいと思っていただけた方はカジュアル面談も大歓迎ですので、気軽にお声がけください。