【いでよ障害対応太郎】我々はインシデントにどう向き合っているのか 〜社内向け障害対応リスト付き〜
「なんかアプリでインシデント起きてエンジニアがどこかで対応してるらしいよ」
「インシデント時のお知らせって誰がどうやって出すんだっけ？」
「インシデントの復旧作業って今どれくらい終わってる？」
「あのインシデントって振り返りしたっけ？」
「似たようなインシデント、前も対応したような、していないような」
このような会話に覚えはありませんか？
FiNC Technologies社 (以下FiNC) では今まで
- インシデント対応をしていても自チーム内で対処しようとしてしまい、他の人が気づけない
- インシデント対応の仕方にフォーマットがなく、迅速な対応やお客様への報告ができない
- インシデントの振り返りが実施されず、インシデント時の知見が共有されない
という問題がありました。
それらの問題を
- 気が付きやすく、シェアしやすくする = 統一のチャンネルで情報を整理し、そこにシェアしやすい空気を作る
- 何をすべきかわかりやすくする = インシデント時対応のリストを作成し、それに従えば良いようにする
- 楽しく振り返る = ポストモーテム（インシデントの振り返り）の設定を促し、責めるのではなく楽しく明るく振り返る
という方法で改善していきました。
その際に気をつけたことなどについてシェアします！
ブログの内容は後日こちらのイベントで発表予定なのでプレゼンでも聞きたい方は是非ご参加ください〜！
目次
- 問題1：インシデント対応をしていても自チーム内で対処しようとしてしまい、他の人が気づけない
- 問題2 ：インシデント対応の際にすべきことが明文化されていない
- 問題3 ：インシデントの振り返りが実施されず、インシデント時の知見が共有されない
- インシデント対応KPTと今後の改善
- まとめ
- 付録 FiNCのインシデント対応リストの中身
問題1：インシデント対応をしていても自チーム内で対処しようとしてしまい、他の人が気づけない
インシデントが起きた際、他のチームと連携しないといけない場合でもチーム内で解決しようとしてしまうことはありませんか？
FiNCではサービスごとにチームが分かれているので、普段はそのチーム内でのチャンネルで会話しています。
そのため、インシデント時にもその中で作業をしてしまいがちで、全員がいるようなチャンネルでシェアせずに、自分のチーム内だけで処理してしまうことがよくありました。
その結果、他のチームの手助けを借りれば早くできたはずの対応に遅れが生じたり、お客様への連絡に遅れが出るようなことがありました。
そのような問題を防ぐために
- インシデント報告チャンネルの統一、周知
- 報告チャンネルは気軽にシェアできるように、報告した人を賞賛する雰囲気づくり
を行いました。
インシデント報告チャンネルの統一、周知
slackで #incidentチャンネルを作成し、インシデントの可能性のあることはそこで @channelをして(そこにいる全ての人に通知が行く) 報告するようにしました。
最初はプロダクトに関わる人しかいなかったチャンネルでしたが、徐々にと広報メンバー、CSメンバーも参加して、今では社員の大半が入っているチャンネルになっています。
報告チャンネルは気軽にシェアできるように、報告した人を賞賛する雰囲気づくり
社員の大半がいるチャンネルだと、特にプロダクトに関わらないメンバーの場合「アプリがなんか調子悪そうだけど自分が全体に通知していいのかな…」とためらってしまうことがよくありました。
そのようなためらいを防ぐために、誰かがインシデントを報告してくれた時に、実際にはインシデントではなかったとしても「これはインシデントじゃないので次回から報告しないでください」と咎めるのではなく、「些細なことでも報告していただきありがとうございます」と、報告してくれた人を賞賛するような雰囲気を積極的に作っていきました。
とはいえ、インシデント報告チャンネルでの報告は、エンジニアである自分や他のメンバーが繰り返し言っても最初はなかなか浸透しませんでした。
その中で鍵となったのが、このようなインシデントに対する取り組みに理解のあるプロダクトマネージャーの協力でした。
インシデント時にはすぐに駆けつけてくれて、積極的に広報/CS/マーケチームなど非エンジニアとの連携をしてくれたり、インシデント報告チャンネルでの報告を積極的に呼びかけてくれることで、「エンジニアの世界の話」と取られがちなインシデント対応への非エンジニアの心理的障壁を取り除いてくれたと思います。
少しでも不具合に感じることがあれば積極的にシェアする雰囲気ができ、実際に影響があるインシデントが起きた時に迅速な対応ができるようになりました。
ポイント
- インシデントが起きた時には全体のチャンネルでまずは周知する
- 連絡してくれた人が賞賛されるような雰囲気作りが大事
- 非エンジニアでインシデント対応に理解のある人がいると、より雰囲気を作りやすい
少し余談ですが、チャンネルの名前はもともとemergencyでした。しかし「緊急かどうかが判断できなくて報告をためらってしまう」ような事例や、「緊急かどうかは主観なのでincidentというチャンネルにすべきでは？」という声からincidentチャンネルに変更されました。
問題2：インシデント対応の際にすべきことが明文化されていない
いざインシデントが起きた時に、何から始めてどこに連絡をすればいいかわからないということはありませんか？
もともと FiNCでは、インシデントが起きた時にまず何をすべきかが明文化されていませんでした。そのため、ありがちだったのが
- エンジニアがいきなり調査を始めてしまって、調査がどこで行われていてどこまで進んでいるか状況が全くわからない
- お客様に（Twitterやアプリ内のお知らせ機能などで）どうやってお知らせするか整備されておらず、お知らせが出せなかったり、遅れてしまったりする
などの問題でした。
そのような問題を防ぐために
- インシデント対応リストの整備
- インシデント時にやることがコマンドで表示できるbotの作成
を行いました。
インシデント対応リストの整備
インシデント対応リストの詳細については付録にて詳しく説明しますが、インシデントが起きた時にはまず
- 全体の責任者、エンジニアの（作業はしない）コミュニケーション担当、エンジニア作業者の3つの役割を明確にする
- 調査用チャンネルの作成
- インシデント状況ドキュメントの作成
を行い
- 全体の責任者は各所への連絡、定期的な状況整理、お知らせの依頼
- エンジニアのコミュニケーション担当は作業はせず、インシデント状況ドキュメントのステータスやタイムラインなどの更新
- エンジニア作業者はインシデントからの復旧
を担当するようにしました。
それによって後から来た人でも、slackチャンネルや状況ドキュメントを見ることによってステータスやタイムラインがわかり、また連絡する人と作業者を分けることによってインシデントの復旧に力を注ぎつつ、お客様への告知も迅速に対応できるようになりました。
インシデント時にやることがコマンドで表示できるbotの作成
実際にインシデントが起きている時は、大抵みんな焦っています。
インシデント対応リストが長く読みにくいものだと、そのドキュメントを読んでいる余裕がなく、対応ルールが無視されてしまう問題がありました。
また、インシデント状況ドキュメントのテンプレートを見つけてきてコピペする作業が大変で、インシデント発生時にはないがしろにされがちでした。
そのため、最初は対応方法がわかるエンジニアがフォローしたりしていましたが、そのうちに「インシデントが起こった時に最初にやるべきことがbotで通知されれば、焦らなくて済むのでは？」ということでslackのコマンドを作り、botが最初にやるべきリストを出してくれるようにしました。
そのおかげでインシデント報告がされた時にみんながそのコマンドを実行し
- 対応時にやることリストがすぐわかって認知コストが下がる
- 対応時の手間が減る
ことで正しい対応が迅速にできるようになりました。
このbotはAWS Lambdaで作られていて、Terraformでコード管理されているので今後も少しずつ改善される予定です。
ポイント
- インシデントが起きた時に役割分担と、何をするかを事前に明文化して周知しておく
- インシデントが起きた時にやるべきことを思い出すコストを極力下げる
問題3：インシデントの振り返りが実施されず、インシデント時の知見が共有されない
インシデントの振り返りがされず似たようなインシデントが繰り返された経験はありませんか？
もともと FiNCではインシデントを振り返る会議があったのですが、インシデントの原因の究明と対策の場というより、責任の追求の場になってしまっていました。
そのため、会の雰囲気は暗く、徐々に参加する人が少なくなり、会も開催されなくなっていきました。
そこで、従来の責任追及の場としての振り返りではなく、原因を突き止めて再発防止の対策を行い、知見を共有する場としてのポストモーテム (注1) を開催するようにしました。
ポストモーテムはインシデントの後に設定され、誰でも参加できます。
またポストモーテムの最初には以下の条文が読まれます。
ポストモーテムの目的はインシデントの原因を解明し再発を防止すること、またインシデントが起きた時の初動を早めるための準備をすることです。
人の責任を追求することはせず、責任を追求するような発言があった場合にはお互いに注意をします。
言い訳をする必要はありません。よくなかったこともうまくいったことも他人事のように発言しても問題ありません。
良い振り返りは賞賛されるべきものです。楽しく振り返りましょう！
責任追及をするのではなく、楽しく振り返るということを意識的に心がけることで、実際に気持ちの良い雰囲気でポストモーテムが実施されるようになりました。
ポストモーテムも、インシデント対応のやり方と同様に、最初から浸透していたわけではありません。
最初はSREチームが主導してファシリテーションをしたり、話しやすい雰囲気作りをしていました。
そのうちにポストモーテムを設置するようお願いすることなく、各チームで主体的にポストモーテムを設置して振り返るような習慣がついてきました。
主体的にポストモーテムが開かれるために必要だった要素としては、繰り返しになりますが、責めない雰囲気、楽しく振り返るという雰囲気の浸透とポストモーテムのテンプレートを整備して、それを見れば振り返れるようにすることで、開催の障壁が低く保たれたことが良い要素だったかなと思います。
現在では、直接システム起因で発生したインシデントだけではなく、運用オペレーションのミスで起きたインシデントであっても運用オペレーションのチームでポストモーテムを主体的にするなど、エンジニアに限らずプロダクトに関わるメンバー全体に浸透してきています。
ポイント
- インシデントの振り返りは責めない雰囲気、楽しく振り返るという雰囲気を作る
- 振り返りの際にやることはテンプレートにしておく
インシデント対応KPTと今後の改善
インシデントへの対応方法も浸透してきて、ポストモーテムも数十回ほど実績ができてきたので、全体を通しての振り返りとしてKPTを実施しました。
Problem1
ポストモーテムで出たアクションのトラッキングが甘くて改善が実行されたりされていないことがある。
TRY1
ポストモーテムで出た改善タスクは、定常的な開発タスクと同じく当社ではAsanaで管理しているので開発スプリントのタスクに入れて、月に一回のインシデント対応KPTで進捗をトラックしていく。
Problem2
ポストモーテムで出た知見が全体にシェアされる仕組みがない。
TRY2
週次のエンジニア会議にて知見をシェアする場を設け、ポストモーテム後には全体のチャンネルにも知見をシェアする。
などの改善策が出てきました。
その他、前述の障害対応太郎をもっと便利にするために、TerraformでAWS Lambdaをコードで管理してアップデートしやすくする、などが出てインシデント対応方法全体としても改善されました。
今後も、インシデント対応やポストモーテムを月に一回ほどの頻度で振り返っていき、良いポストモーテムは週次のエンジニア会議で表彰するようにしていく予定です。
まとめ
FiNCにおけるインシデントの対応や振り返りについてまとめてみました。
- 気が付きやすく、シェアしやすくする
- 何をすべきかわかりやすくする
- 楽しく振り返る
という改善点が皆さんの会社でのインシデント対応の参考になれば幸いです！
ブログの内容はこちらのイベントでも発表しますので、もうちょっと突っ込んだ内容を聞きたい方は是非ご参加ください！
注1) ポストモーテムは検死という意味の単語で、インシデント後に原因究明、再発防止のために根本原因、トリガー、解決方法、タイムラインなどについて記録する文書です。FiNCでは振り返り会という意味で使うこともあります。FiNCにおけるポストモーテムのフォーマットはGoogleのSRE本 を参考にしています。
[付録] FiNCのインシデント対応リスト
付録としてFiNCのインシデント発生時の対応リストを公開します。
こちらもポストモーテムのフォーマット同様にGoogleのSRE本を参考にさせていただいています。
第一報を行う
#incident チャンネルで起きているインシデントについての第一報をする (@channelを必ずつける)
どんな状態が起きているのか今わかっている範囲での影響範囲について報告する
まずは今わかっていることを簡潔にまとめつつ、全体に知らせることが最優先です。必ずSlackのchannelメンションで全体に通知します
インシデント責任者を決める
インシデント責任者（主に企画部の誰か）
実際のインシデント解消業務は行わず、影響範囲を判断して作業責任者と連絡を取りながら関連部署に報告する
指示用のslack channelができたら、 #incident にも進捗報告するコミュニケーション担当者（エンジニア側責任者。主に技術開発部の誰か）を決める
実際のインシデント解消業務は行わない。incident状況ドキュメントを記入しタイムラインの更新をし続ける作業担当者（主に技術開発部の誰か）を決める
実際のインシデント解消業務を行う
次にインシデント責任者、コミュニケーション担当者、作業担当者を決めます。
作業をいきなり始めることで、インシデントのステータスがわからないような状況を防ぎます。
インシデント対応リストを作成したタイミングでは、エンジニア責任者とエンジニア作業者の二つの役割しかなかったのですが、エンジニア責任者が全てのコミュニケーション（対エンジニアに加え、広報、CS、マーケティングチームなど）を担当するとパンクすることがわかったので、改善され今のような形になりました。
指示用のslack channelを決める
作業担当者が今何を行なっているかなど、当該インシデントに対するあらゆる対応内容を流すためのchannelを作成する
全体の #incident チャンネルにはサマリーだけを流し、1つのインシデントの状況が1つのチャンネルで終えるように専用のチャンネルを作ります。
そうすることによって、エンジニアの作業ログによって重要なメッセージが埋もれたりすることや、同時にインシデントが起こってしまった時の混乱を防ぐ効果があります。
また、リモートでのインシデント対応が多いため、ビデオ会議を繋いで作業や連絡を取ることもあります。
インシデント責任者は責任をもって以下のリストを進める
1. インシデントの深刻度を判断しエスカレーションをする
インシデントレベルの分類をみてS_Serious / SS_ Critical の場合にはエスカレーションを行う2. お客様への告知の連絡をする
アプリ内でのお知らせの記載
お客様に影響があるケースでは、公式Twitterによる告知も行う
1時間以上のサービスの停止や、toBサイトの長時間停止などの場合、公式サイトでのお知らせ掲載
状況に応じて広報やCSチームと連携を取りお客様に対する告知文を用意します。
連絡網は事前に整備され、投稿文言のテンプレートは事前に用意されています。
3. タイムラインを終了ステータスまで随時更新する。
終了後も作業があればインシデントドキュメントのタイムラインに追記する
待機/解散の判断をする
完全に収束するまでタイムラインやステータスを更新します。
インシデント対応の終了を判断し宣言することは、特にリモートでのインシデント対応の場合に作業者や関係者の疲れを軽減させる意味でも重要です。
以上がFiNCのインシデント対応リストです。
こちらもぜひ参考にしていただければ嬉しいです。
