はじめに
皆さんこんにちは。
春の陽気に誘われて、思わず家族もいないのにファミリーカーを買った挙げ句、車中泊仕様に改造してしまった、クラウド経費本部 プロダクト開発部 ガーディアングループの@tosite（てっしー）と申します。
最近は福岡開発拠点でも徐々に英語化が進んできており、意識的に英語を話すようになりました。
私が所属しているガーディアングループのエンジニアは、一般的にはCRE（Customer Reliability Engineering）と呼ばれる領域の業務を担当しています。
お問い合わせや技術的負債の解消だけでなく、機能改修や機能追加、パフォーマンス改善など「攻めの運用」も含め、お客さまにご満足いただけるよう、信頼性を保つことに日々腐心しています。
ところで皆さん、インシデントはお好きですか？
一口にインシデントと言っても、revertで解消するものからデータパッチを伴うもの、果てはサービスを一時的にメンテナンス状態にしなくてはならないような大規模なものまで、多岐に渡ります。
ですが、そのどれもに対して「はい」と答える方はおそらくいらっしゃらないのではないでしょうか。
私もインシデントは好きではありません。
しかしながら、エンジニアリングを生業とする以上、いつかは直面するものだと思います。
そこで今日は、インシデントが起こってしまったその時に、私はどういうことを考え、どういう立ち回りをしているのかについてご紹介させていただければと思います。
想定読者
インシデント対応を行うエンジニアの皆さま
インシデント対応の基本
一口にインシデントと言っても、そのフローは多岐に渡ります。
監視ツールによるアラートによって気づくものもあれば、お客さまからの問い合わせで初めて発覚するものもあります。
発生したインシデントは、緊急度や影響範囲などによってトリアージされ（場合によってはインシデント対応中に緊急度や影響範囲が変動することもあります）、エンジニアや各職種の社内ステークホルダーが招集され、インシデント対応が始まることでしょう。
ここで社内ステークホルダーとはエンジニア・カスタマーサポート・プロジェクトマネージャー・プロダクトオーナーなどを指します。
ここで余談ですが、優先度についてはよくまとまっている弊社ブログの記事がありますので、ご紹介させてください。
ガーディアングループでの1年を振り返って〜問い合わせ対応で大事な5つの考え方と、エンジニアとしての3つの成長〜#1. 優先度は「問題の重大度 × 影響範囲」で決める
ガーディアングループでは日々、お問い合わせの調査・対応を行っておりますが、その際に必ず優先度を把握しております。
優先度を判断した結果、インシデント扱いとするケースも稀にありますが、これが素早く行えているのはチームメンバー全員が上記の「優先度」に対する共通認識を持っているからです。
以下にインシデント対応の主な流れと主な内容について記載します。
- 検知: 発生したインシデントを検知するフェーズ
- アラートや問い合わせによる検知
- 初動対応: 復旧に向けて情報を集め、調査・連絡するフェーズ
- 対応メンバー招集
- 社内ステークホルダーへ連絡
- 影響範囲調査
- お客さま連絡
- 復旧: 障害発生前の状態に復元するフェーズ
- 原状復帰
- データパッチ
- お客さま連絡
- 事後対応: 障害発生後の報告と再発防止対応を行うフェーズ
- 恒久対応
- ポストモーテム作成
- 再発防止対応
※インシデントの規模によってはフェーズが混在する場合もあります。
インシデント対応に必要なこと
発生したインシデントの被害をいかに抑えるかについては、早く状況を把握し、復旧作業を行えるかどうかにかかっていると言っても過言ではありません。
とは言え、復旧作業を急ぐあまり、二次被害・三次被害を引き起こしてしまっては身も蓋もありません。
我々は丁寧に、正確に、かつ素早く、インシデントと向き合う必要があります。
そして刻一刻と変化していく状況や調査結果を整理して、適切にお客さまや社内ステークホルダーに状況を共有する義務があると考えています。
理想と現実
と、聞こえのいいことを言ってみましたが、そううまくはいかないのがインシデント対応です。
皆さんも次のような経験はありませんか？
初動対応編
- 関係者に連絡をしたいけど・・・
- 😱 やり取りしている社内ステークホルダーが多くて連絡が取りづらい
- 😱 今どういう状況なのかが一見してわからない
- エンジニア全員で影響調査！だけど・・・
- 😱 誰が何の作業をしているかが見えない
- 😱 各自の調査結果が散らばってしまう
- お客さまに連絡をしたいけど・・・
- 😱 サマリがまとまっていなくてよくわからない
- 😱 色んな場所で同じような報告を何度もしてしまう
事後対応編
- ポストモーテムをまとめたいけど・・・
- 😱 サマリがまとまっていなくて何をやったか思い出せない
- 😱 タイムラインがまとまっていなくて当時の状況がわからない
- 😱 誰が何の対応をしたかがわからない
- 😱 スレッドが分かれていて経緯が追えない
- いざ再発防止対応を行おうとしたら・・・
- 😱 誰がどのような対応をするのかがわからない
- 😱 どのような対応が必要かがわからない
- 😱 現時点でどこまで対応しているかがわからない
特にインシデント対応中は一秒でも早くサービスを復旧させたいという思いから、おのおのが全力で影響範囲の特定や原状復帰に向けて調査していることと思います（本当にいつもありがとうございます）。
なのになぜ、このようなことが起きてしまうのでしょうか？
インシデント対応に必要なのは「ハンドラー」の存在？
その原因の一つとして、私は「エンジニア全員がオペレーターになってしまう」という理由があると考えています。
上述の通り、我々は一秒でも早くサービスを復旧させたいと思っています。
それゆえ、全員が何かしら手を動かしている状況に陥ってしまうことがあります。
確かに復旧までのことを考えると、そちらのほうがより速く作業を進めることができるかもしれません。
ですが、社内ステークホルダーへの連絡やお客さま連絡、そして事後対応のことを考えると、「何も手を動かさずに状況整理に徹する人」が一人はいたほうがいいと思うのです。
私はその役回りを「ハンドラー」と呼んでおり、有事の際はハンドラーを意識的に務めるようにしています。
ハンドラーは具体的に何をする？
私がハンドラーを務める際、以下のことに気をつけています。
- 初動対応
- インシデントチャンネルの作成
- インシデントチャンネルへの誘導
- 報告レポートの雛形作成
- 状況整理
- 対応中
- 各エンジニアの作業状況確認
- 調査結果整理（主にエンジニア以外の社内ステークホルダー向け）
- 社内ステークホルダーへの連絡
- 対応方針策定
- 事後対応
- ポストモーテム作成
【初動対応】インシデントチャンネルへの誘導
こちらは社内のコミュニケーションにSlackなどのチャットツールを使っているプロダクト向けの説明になります。
インシデントかそうでないかに関わらず、調査の必要性がありそうなものに関してはなるべく早い段階で専用のチャンネルを作成する（あるいは作成するよう促す）ようにしています。
これはインシデント対応でよくありがちな「調査を進めるうちに緊急度・影響範囲が拡大していく」パターンに備えるためです。
このパターンの場合、初期の段階ではあまり緊急度が上がらず、スレッドなどで調査を進めることが往々にしてあります。
そして影響範囲が特定でき、インシデントであると気がついたときにはすでに調査ログなどの情報がいろんなところに点在しており、状況の把握に時間がかかってしまいます。
そうならないために、極力早い段階から情報を一本化できるようにするための取り組みが「インシデントチャンネルの作成」であり、社内ステークホルダーの「インシデントチャンネルへの誘導」なのです。
【初動対応】報告レポートの雛形作成
私は主に、以下のフォーマットに従って状況を整理していきます。
ドキュメンテーションツールについては特にこだわりはないのですが、最低限共同で編集できるものを選択しています（NotionやSlack canvasなど）。
なお、フォーマットの一部についてはGoogle社が公開している、「Google - Site Reliability Engineering」を参考にしています。
# 状況まとめ - サマリ: どんなインシデントなのかを一行で記入 - インパクト: 影響範囲について記入(例: 50ユーザーが管理画面にアクセスできなかった) - 根本原因: インシデントの根本原因について記入（例: コードに不具合があった） - 発生原因: インシデントの発生原因について記入（例: リリースによって発生した） - 再発防止案: - 【検出】次回同様のことが起きた場合にどう検知するかなどを記入 - 【緩和】今回発生したインシデントをどのように緩和させたかを記入 - 【修正】インシデントの修正プランについて記入 - 【予防】障害の再発を防止するプランについて記入 # 担当アサイン - 影響範囲調査: A - 原状復帰対応: B # メモ・議事録 <!-- 障害対応中のメモや議事録などを残しておく --> # タイムライン - **YYYY年MM月DD日** - **hh:mm** 原因となるプルリクエストのリリースが実施される - **hh:mm** 本番にデプロイが完了する - **YYYY年MM月DD日** - **hh:mm** お客さまからの問い合わせによって発覚 - **hh:mm** Aが管理機能の修正リリースによるものであることを特定 - **hh:mm** Revertを実施 - **hh:mm** Bが影響のあったユーザーを50ユーザーと特定 - **hh:mm** 影響のあったお客さまに個別に連絡 - **YYYY年MM月DD日** - **hh:mm** 不具合を修正して再度リリース
【初動対応】状況整理
報告レポートの雛形は完成しても、作成した段階ではほとんど情報が集まっていない状態であることもしばしばです。
このフェーズでは、関係者や先行して調査を進めてくれているエンジニアと連携して、現在の状況を洗い出します。
そしてどうすれば復旧まで持っていけそうか、また復旧までに必要なタスクは何かを整理しながら、各エンジニアへ担当をアサインしていきます。
すでに割り当てが決まっている場合、担当アサインリストを更新しましょう。
この際、非常にスピーディーにコミュニケーションが行えるので、ZoomやGoogle Meet、Slack huddleといったWeb会議サービスなどをつなぎながら作業することをおすすめします。
ただし、ハンドラーは会話を傾聴しておき、状況が変化したり新しい情報が出たりした場合はメモを取ることを忘れないようにしてください。
【対応中】各エンジニアの作業状況確認
実際に各エンジニアが手を動かす状況になったら、タイムキーパーとしての役回りに転じましょう。
10分、30分、1時間など、ある程度の区切りごとに現在の状況がどうなっているかを確認しつつ、報告レポートを更新していきましょう。
この際に、状況が変化した節目などは必ずタイムラインに記載するようにしましょう。
タイムラインに記載する際に気をつけるべきこととして、「事実のみを端的に記載する」点が挙げられます。
推測や憶測、仮説はメモ欄に、そうでない事実のみをタイムラインに記載するようにすることで、自然と一貫性のある報告レポートになります。
調査結果整理（主にエンジニア以外の社内ステークホルダー向け）
調査結果がある程度集まってきたら、次は社内ステークホルダー向けに報告するために調査結果をまとめましょう。
ですが、ここで一点気をつけるべきことをご紹介します。
エンジニア以外のメンバーにも状況が正確に伝わるよう、「コミュニケーションは相手の立場に立って行う」ことを意識しましょう。
そして、次のステップに進む前に、必ずインシデント対応メンバーのレビューを受けるようにしましょう。
もし内容や伝え方に不備がある場合、修正する手間が発生するだけでなく、情報が錯綜し、かえって混乱する可能性があります。
たとえどんなに急ぎであったとしても、報告する内容は誰かにレビューをしてもらうとよいでしょう。
【対応中】社内ステークホルダーへの連絡
ある程度状況が整理できたら、社内ステークホルダーへの連絡を必ず行いましょう。
インシデントの規模によっては社内ステークホルダーへの連絡を優先する場合もあります。
（例えば、全ユーザーがアプリケーションにアクセスできないなどの影響範囲が大きいインシデントの場合、問い合わせが殺到することが予想されます。その場合はカスタマーサポートやプロダクトマネージャー、プロダクトオーナーへ即時連絡するなどの対応が必要になる場合もあります）
この際に、報告レポートがあるとお互いに認識の齟齬もなく、また現在どこまで調査が進んでいるかが一目瞭然となることでしょう。
対応方針策定
そして集めた情報を元に、インシデント対応チームで対応方針を検討します。
この際に重要なこととして、「暫定対応と恒久対応を必ず分けて考える」というものがあります。
暫定対応とは、「フィーチャーフラグを利用して切り戻す」であったり、「一度revertする」であったり、「メンテナンス状態にする」であったりと、何らかの形でインシデント発生前の状態に戻すことを指します。
対して恒久対応とは、原因となるコードの修正などを指します。
（余談ですが、このタイミングで状況保全も行えると恒久対応がスムーズに進むので、余裕があればぜひ意識してください）
インシデントが発生した際、「お客さまの業務が止まらないよう一刻も早く正常な状態に戻す」ことを最優先に考えるべきです。
そして、ここの切り分けと判断に時間がかかると、インシデントの内容よってはより被害が拡大してしまうおそれがあります。
ハンドラーやインシデント対応チームは、現状を正確に把握し、どうすれば最短経路で暫定対応できるかを議論しましょう。
【事後対応】ポストモーテム作成
最後に、復旧まで終わったらポストモーテムを作成します。
とは言え、ここまでの一連のハンドリングがうまく機能していれば、タイムラインや状況についてはほぼまとまっている状況かと思います。
主に社内ステークホルダーを交えたタイムラインの整合性の検証や、再発防止策について議論しましょう。
なるべくポストモーテム作成には時間をかけないことがポイントです。
ここで重要なのが、ハンドラーは一人でポストモーテムを完成させようとしないよう意識することです。
各タスクごとに担当者を決めて作業しているはずなので、そちらと連携を取りながら担当部分の記入と、タイムラインの確認をお願いしてください。
そしてインシデントに関わったメンバーは、一緒にポストモーテムを完成させるよう意識していただけるとハンドラーになった人が助かります。
どんなに優れたエンジニアであっても、一人でインシデント対応をこなすことはとても心細く、負担が大きいものだと思います。
私は「対応メンバー全員でポストモーテムまで書き切る」ということをインシデント対応の大切な心得の一つとして、いつも心に留め置いています。
改めて理想と現実
ここで、先ほど挙げた課題に対して、ハンドラーが入った場合どうなるのかを見てみましょう。
初動対応編
- 関係者に連絡をしたいけど・・・
- 😱 やり取りしている社内ステークホルダーが多くて連絡が取りづらい
- 😄 各担当者はハンドラーに状況を報告するだけでよい
- 😱 今どういう状況なのかが一見してわからない
- 😄 ハンドラーが逐一タイムラインをアップデートしてくれるので一目瞭然
- 😱 やり取りしている社内ステークホルダーが多くて連絡が取りづらい
- エンジニア全員で影響調査！だけど・・・
- 😱 誰が何の作業をしているかが見えない
- 😄 ハンドラーが主体的に担当者の割り振りを可視化してくれる
- 😱 各自の調査結果が散らばってしまう
- 😄 各担当者の調査結果をハンドラーが吸い上げてまとめてくれる
- 😱 誰が何の作業をしているかが見えない
- お客さまに連絡をしたいけど・・・
- 😱 サマリがまとまっていなくてよくわからない
- 😄 ハンドラーがサマリをまとめて連絡してくれるのでわかりやすい
- 😱 色んな場所で同じような報告を何度もしてしまう
- 😄 単一の障害対応チャンネルがあるので追いやすい
- 😱 サマリがまとまっていなくてよくわからない
事後対応編
- ポストモーテムをまとめたいけど・・・
- 😱 サマリがまとまっていなくて何をやったか思い出せない
- 😱 タイムラインがまとまっていなくて当時の状況がわからない
- 😱 誰が何の対応をしたかがわからない
- 😱 スレッドが分かれていて経緯が追えない
- 😄 初動対応中にほとんどまとまっているのであとは転記するだけ
- いざ再発防止対応を行おうとしたら・・・
- 😱 誰がどのような対応をするのかがわからない
- 😱 どのような対応が必要かがわからない
- 😱 現時点でどこまで対応しているかがわからない
- 😄 ポストモーテムにまとまっている状態なのですぐわかる
インシデント対応対応でありがちな課題は、ハンドラーという役割を導入することでそのほとんどがカバーできたのではないでしょうか？
終わりに
なるべくならインシデントは起きないに越したことはないのですが、起きてしまった際に備えて、日頃から準備をしておくことが肝要だと思います。
確かに、ただでさえ不確実性・緊急性の高いインシデント対応というものに対して、ハンドラーを務めるというのはとても勇気がいることかもしれません。
しかし、チームメンバーは勇気を出してハンドラーに名乗り出たあなたを支えてくれるはずです。
ぜひ、臆せずやってみましょう。そして、その知見をみんなに広めていきましょう。
強いプロダクト・強い組織を作っていくうえで、インシデント対応の属人化を解消することが必要不可欠だと思っています。
インシデント対応を行ううえで、本記事が皆さまにとっての一助となれば幸いです。
最後に、マネーフォワード福岡開発拠点ではエンジニアを募集しています！
福岡開発拠点のサイトもあるのでぜひご覧ください！
