はじめに
2023年の11月にスタートアップ企業に転職した。社内専用のWebアプリケーションのAPI開発を主にやっていたが、突然インシデント対応のルールを作りたいという話を受けた。せっかくスタートアップ企業に入社したんだからコードを書くこと以外のことも挑戦しよう、ということで引き受けた。
とはいえ、前職ではSREをやっていた訳でもなければ、ほとんどインシデントとは無縁のところにいたので知識がほぼない状態だった。とりあえず引き受けたからにはやらねば、という訳で情報を整理しつつ進めた。
やったこと
自分の中でどのようなルールにしていきたいかを整理
自社の社員にインシデント関連のインタビュー
他社の事例を調査
ルール作成
頭の中の整理
不幸中の幸いにも、直近でインシデントが発生したこともあり、各メンバがどのように対応しているのか、なぜ今になってルールを作りたいのか、現状の問題点は何か、どのようなことがあれば良さそうかを色々と整理した。整理した結果、自分の中では下記の事柄をルールに取り入れたいと感じた。
インシデント対応する人を固定したくない
どうやらインシデント対応する人が固定化しているように見えた。その人達が何かの理由で対応できないときが訪れたらヤバいと感じたのでやっていきたい。
インシデントの根本原因の除去を計画的にやりたい
その場だけの対応にしたくない。同様のインシデントが起こらないように、根本原因を放置しないように、計画を立てるところまでをやりたい。
ノウハウを社内ドキュメントに起こしておきたい
どんなインシデントがあって、どのように対応したのかが残されていないので、今いるメンバや将来会社に入ってくるメンバがインシデントを把握できないのは良くない。
ざっくりこれらはやりたいなーと整理したが、入社したばかりということもあり、「これが出来ていない理由があるかもしれない」、「他メンバがどのように感じているのか」などの知らないことがあると考えられるので、社内のメンバにこれらを聞いてみることにした。
もう少し補足すると、入って数カ月の人間が組織を知らずに組織のルールを自分勝手に作り、社内のメンバが混乱するのは流石に避けたいとも考えていた。（ルールをチェックする人はいるが、全員にチェックしてもらうわけではないので、あらかじめ全員の考えを知っておきたいとも思った)
インタビュー
上で触れた通りのことや、自分が自社開発のプロダクトを触ったことがかなり少なかったこと、自社に関するありとあらゆる知識がなかったこと、各メンバとそこまで話したことがなかった、等々からせっかくだし対面でインタビューをすることにした。インタビュー内容は主に下記の3点に絞った（他にも個人的に聞きたかったことなども聞いたが、ここでは関係がないので割愛）。
過去のインシデントはどういうものがあったか
社内でどういうことをインシデントと扱ったのかを知りたかった。
過去のインシデント対応で困ったこと
これを克服したルールにしたい。自分が想定していること以外の困りごとや組織上の不都合の関係で出来てないことがあるかもと思ったので聞いてみたかった。
自分の中でインシデントって何を指すのか
インシデントの基準が人によってばらけているとちょっと面倒なことになるので、各メンバがどう思っているのか聞いてみたかった。
このインタビューが自分の中ではかなり良くて、自分の考えていること以外にも考慮しなければいけないことも出てきたし、組織上ルール化出来ないことが出てきたりと収穫がかなりあった。ざっくりと総括をまとめると、
インシデント対応をする人を固定化せざるを得ない
社内の基盤となっているプロダクトとその周りのシステムを隅々まで知っているメンバが限られている。隅々まで知っていないとインシデント対応時に、どのようにあたりをつけ、どのように調査を進めていけばいいのかが出来ない。また、夜間に発生した場合に動けるメンバが限られること等々から固定化した方が利益が大きいことが分かった。色々と考えた結果、かなり心苦しいが現状は諦めざるを得ない。
インシデント対応の透明性がない
これはインタビューで得られたこと。社内では口頭で話したりTeamsのチャットでやり取りをすることが多く、インシデント対応もこの「閉じたコミュニケーション」で行われることが多い。何が起きてて、どのプロダクトに問題があるのかを当事者メンバにしか見れない。
この情報に透明性があると、外部のメンバから助言が得られることもあるし、どのように対応しているのかが見れるので固定化の解消につながるかもしれない。
※外部のメンバ: 社内のインシデント対応にあたっているメンバ以外のこと
インシデント対応の旗振りがいないので何も分からん
ほぼ上と同じ。誰が情報を握っているのかが分からないので、必要なメンバに情報が共有されない。営業は顧客にどのように伝えればいいのかが分からない、経営者はいつ解消見込みなのかが分からないなど、かなり良くない状態なので明確に決めておきたい。
これ以外にも色々と問題点が出てきたので出来る限り解決できるようにしたい。しかし前述の通り、知識がないので他社の事例を色々と調べてみることにした。
他社事例の調査
基本的には「他社ではどのようなフローで対応しているのか」を主に調査していた。あれば嬉しい部分として「他社では上の問題点をどのように解決しているのか」も調査していた。当たり前だが、「他社と自社は違うので参考程度にして自社でルール化するならどうするのか」を重点的に考えた。
まずはPagerDutyさんのインシデント対応プロセスの資料。これの素晴らしいところは、何を定めればいいのかが明確なので、どのようにルールを作ればいいのかがかなり掴めた。基本的にはこれを読んで自社のルールに役立てるかを考えていった。
次にレバレジーズさんのポストモーテム資料。これは「インシデントを根本原因の除去を計画的にやりたい」と「ドキュメント化」の2つを解消するのにピッタリだと考えていたのが「ポストモーテム」で、他の会社の事例がどのように対応しているのか知りたかったところで発見した資料。これの素晴らしいところは、「ポストモーテムとは？」から「どうすれば良くなるのか」等がえぐいぐらい詳しくまとまっている。自分も完全に理解はしていないので、実際に運用して振り返っていきたい。
他にも様々な資料を読ませていただいた。最近は各技術者がアウトプットとして資料をまとめていたりすることもあり調査には時間を要しなかった。本当に感謝しかない。
補足として、最近Googleの検索の精度がかなり良くないので普通に検索していると苦戦する。speakerdeckでの検索や、connpassでインシデント関連の勉強会を調べて紐づいた資料を参照することが多かった。
ルール作成
インシデント対応のルールが目的だったが、様々な資料を読ませていただき、社内にインシデント関連のことを明示した方が良いのでは？と思いガイドラインを作ることにした（ルール+αぐらいなのでそこまで大きく変わりはしない）。主に下記のページをNotionに作りルールとして定めた。
インシデントの定義
人によって定義が変わると報告しないことや重要度が各メンバに依存して温度感を保てないことが考えられたので、社内のインシデントの基準を明確に示した。
深刻度レベル表
今の会社はインシデントの知見が高くはないので、深刻度の分類で手間取ると嫌なので本当に一応作った程度。上のインシデント定義をSEVで分類分けしたぐらいなので、改善の余地はある。困ったらまた考えることにした。
インシデント対応の体制
誰が旗振り役なのかを明確にするために作った。役割は「インシデント対応社」と「顧客連絡者」と「インシデントコマンダー」の3役割。致し方がない部分だが、役割に該当するメンバは固定化されている。
インシデント対応フロー
今回の肝になる部分。報告 → 会議 → 対処 → 振り返りという一般的な対応フローになった。新しく会議を設けてインシデントコマンダーが情報の把握と旗振りを担うようにして、問題点の解消を試みている。実際に運用してみないと分からない部分もあるので、まずは理想論を並べた。
インシデントの振り返り
自分がやりたかった根本原因の除去計画とドキュメント化を担う部分。上述したポストモーテムに沿うように作成している。
過去のインシデント一覧
ポストモーテムでまとめた資料を置けるようにページを設けた。
やらなかったこと
情報の透明性の確保
当初はTeamsでやり取りを公開することを考えていたが、「夜間や休みの日にやり取りが発生することもあり、関係者以外がウォッチを続け次の仕事のパフォーマンスが落ちる」ということを考慮した結果やらないことにした。
個人的には自己責任としたかったが、気になっちゃう気持ちも分からなくはないので一旦はなしにした。透明性を上げてくれって声が相次いだらまた議論をしていきたいポイントではある。
役割の固定化の排除
上述している通りやらなかった（というより出来なかった）。これは出来る限り早急に解決したいポイントなので、運用しながら適宜振り返っていきたい。
インシデントを発生させないための取り組み
どこまでやるかを悩んだが、インシデントはどうしても起こってしまうものなので、今は一旦割り切って行わないことにした。今後運用していく部分で防げるところは組織として対策がとれるようにしていきたい。
これを今やってしまうと、組織の根幹部分を変える必要が出てきて少なからずメンバに影響を与えてしまうこと、インシデント発生時の心理的安全性を保てないことが想定されたのもある。出来る取り組みがメンバの匙加減になってしまうものが多かったのもある。
重大インシデントが発生できてしまう状況であれば強気に進言して変えていく意識を持っていたが、そこまで緩い組織体制じゃなかった。
おわりに
初めてこのようなルールを作る仕事をやってみたが、思った以上に考えることが多く大変だった。入社したばかりにも関わらず対等に色々と議論をしてくれた各メンバには感謝しきれない。
それと同時に組織上どうしても諦めざるを得ない部分があるのは心苦しい。一応自分がインシデントコマンダーとポストモーテムの資料を作るのをやることになったので、上手く情報をまとめてドキュメント化し各メンバに昇華させていきたい。
また今回の件を通じて、組織の問題点は少しずつ解消させていきたいなと感じた。前職の体制が割と理想に近かったのもあり、活用できるところは活用していきたい。それが今の組織にマッチするか否か、入ったばかりの自分がぐちゃぐちゃにして各メンバの生産性を下げることはしたくないので、また色々とメンバにはインタビューをして変えていけたら、と思っている。
長くなってしまったが終わり。だらだら書いてしまい読みづらい部分が多いと思うので適宜直していきます。もう少しここを詳しく書いてほしいみたいなのがあれば教えてください。