この記事はBASE Advent Calendar 2023の2日目の記事です。
こんにちは！BASE株式会社でエンジニアをしている大津(@cocoeyes02)です。
今回は自分たちが運営しているプロダクトにおいて障害対応をする中で、インシデント発生が観測されてから暫定対応をするまでの初動にあたるフェーズの動きについて書いていきます。
インシデント対応全体に関わる話は別の記事にありますので、そちらも併せてご覧ください！
インシデント発生が観測されてからいかに早く対応に参加できるか
インシデント対応の初動フェーズにおいて、いかに早く対応に参加できるかというのは非常に重要なポイントとなります。その理由はいくつかあります。
今開発している機能を将来使うかもしれないユーザが減ってしまうリスクがあるから
インシデント発生時は、今現在困っているユーザ（BASEのサービスでいうとオーナーさん、購入者など）がいて、今すぐ対応をしないとどんどん体験を損なってしまう状況であることが多いです。
普段のユーザからのお問い合わせ対応も、インシデントほど切羽詰まっているわけではありませんが、やはりこちらも対応をしないとどんどん体験を損なってしまいます。
体験を損ない続けた先に待っていることは何でしょうか？そう、ユーザがプロダクトから離れてしまうということです。 その前提で考えると、原則業務の優先度としては、
インシデント対応 > お問い合わせ対応 > 普段の開発
の順であると考えています。ユーザが離れてしまうということは、今実装している機能を将来使う可能性があった人も減ってしまうということです。そうなるとせっかく新しい機能をリリースしても、価値を届けられるユーザの数が減ってしまいます。
インシデント対応には、ユーザがプロダクトから離れてしまうことで発生するリスクと戦う人々が集まっているのです。
そもそもインシデント対応において途中から対応に参加するのは、後になればなるほど難しい
インシデント対応は遅くなればなるほど、インシデント発生時間（ユーザ体験を損なっている時間）も伸びてしまいます。なので、スピードを求められる状況であることが多いです。
今どこまで対応したのか、今なんの対応をしているのか、どこまで情報を手に入れているのか、インシデント対応にまつわるログは時間が経つにつれて爆増していきます。参加するのが後になればなるほど、インシデント対応にまつわるログの量も多いため、キャッチアップだけでも大変です。
その点インシデント発生が観測されてからすぐ対応に参加することができれば、キャッチアップは難しくはありません。
ちなみにBASEではインシデントが起きた時にインシデント対応専用のチャンネルをSlackで作成しており、インシデント対応専用のチャンネルが作成された瞬間希望者を全員チャンネルへ自動的に参加させるツールがあります。
自動的に参加されたタイミングでSlackの通知がくるので、多くの人がインシデント発生に気づき、すぐ対応に参加することができます。
初動フェーズにおけるインシデント対応の具体例
ここにいくつか具体例を書きますが、これらの対応は実際にやってみないと上手くなりません。
現時点の状況やインシデントのまとめ
MTG等で途中から参加してきた人がインシデント対応へ参加しやすくするため、今起こっている事象をまとめるだけでも立派な対応になります。
インシデントのまとめはインシデント発生からの流れを一通り追っていないと書けないことが多いので、インシデント対応に慣れていない人はまずはここから取り組んでみると良いのではないかと思います。
必ず全部1人で書かなければいけないわけではありません。少しでも良いから書いてみるところから始めましょう。
インシデントの事象を再現しよう
インシデントの種類によっては、どのOS・ブラウザ・バージョンで起きたか重要になる可能性もあります。
その場合、どのOS・ブラウザ・バージョンで再現したのか少しでも多くの情報が必要になります。
実際に自分の環境で試してみて、再現した / しなかったかを書きましょう。
本番環境で再現するとエラーが出てしまう類のものであれば、ステージング環境等で確認するのも良いでしょう。
今回のインシデントの影響範囲をクエリやログなどで算出しよう
Xやメールなどでお知らせを出すため、今回のインシデント対象となったユーザ（のID）や購入者（のメールアドレス）などが必要になります。
ただしどのケースでも、テーブル構造の知識やクエリを書く力が必要です。
不安がある人は、社内のデータ抽出ログを一通り読んでみると良いでしょう。
事象に関連したエラーを社内で使用しているツールより確認しよう
インシデントの原因を見つける上で重要なのが、どんなエラーやログが吐かれていたのか確認することです。
そのために、社内で使用しているツール（BASEであればNew RelicやSentryなどを使用しています）の使い方について日頃から慣れておくと良いでしょう。
また、各ツールの通知を見れるチャンネルに入っているのも重要です。
すぐ検知できるように設定しておくと良いでしょう。
インシデント発生日にリリースしたものの中に怪しいものがないか確認しよう
インシデント発生日が分かれば、原因がインシデント発生日にリリースしたものの中にある可能性が高いです。
その日何が本番環境へリリースされたのか確認してみましょう。
関連してそうなリリースがあればPRのリンクを共有、さらにPRを読んで該当のソースコードを共有するなどできるとGOODです。
revert PRマージやロールバックの判断を促そう
何度も言いますが、インシデント発生時は、今現在困っているユーザがいて、今すぐ対応をしないとどんどん体験を損なってしまうという状況が多いです。
その今すぐ対応というのは必ずしも修正対応（≒根本対応）とは限りません。revert PRマージやロールバックすることで一時的にも復旧して体験が損なわれるのを止められるなら、その対応が優先です。
後から根本対応も必要になりますが、一番優先しなければいけない目的を見失わないようにしましょう。
revert PRや修正PRを作ろう、あるいはレビューしよう
暫定対応であればrevert PRを作る必要があります。原因がわかるのであれば、慌てずにかつ急いで修正のPRを作る必要があります。
また、自分がPRを作っていなくても、レビューすることも重要です。少しでも早くリリースできるよう、その辺りの感度も高めておくと良いでしょう。
インシデント対応はインシデント対応をやることでしか上手くならない
こんな記事を書いておいて身もふたもないですが、読むだけではやはりインシデント対応は上手くなりません。何故なら、実際にインシデント対応をしてみると上手くいかないことが多いからです。
- 思ったより時間が掛かっている間に、インシデント対応に慣れている他のメンバーがパパッと対応してしまった
- ツールの使い方に手間取ってしまった
- 知識不足でどうすれば良いかわからなくなってしまった
- 単純に慌てて頭が真っ白になったり（深呼吸しよう）
など…
こればかりは数をこなして徐々に上手くなっていくしかありません。設計も設計の数をこなさないと上手くならないと思いますが、インシデント対応も同じです。
また、自チームに関係するドメインのインシデント復旧対応だけ参加しても、なかなか上手くならないこともあると思います。なぜなら、都合よく自チームに関係するドメインのインシデントばかり起こるとは限らないからです。
自チームはもちろん、可能であれば自チームに関係しないドメインのインシデント復旧対応にも参加して数をこなしていきましょう。
また、インシデント対応は対象ドメインの中でも深い知識を要するケースが多く、対象ドメインを理解するきっかけになります。実はインシデント対応はドメイン知識獲得のチャンスなのです。悠長にしている暇はないのは確かですが、ピンチはチャンスだと思って取り組んでみましょう。
最後に
ここに書いてあることはあくまで入門が目的なので、インシデント対応に必要なことはもっとあります。例えば、あらかじめソースコードを広い範囲で読む、テーブル・インフラ（AWS）構成を把握するなど...
ただ、今回の記事に書いてあることが一通りできる人は、次何が必要なのか自ずと見えてくるものではないかと思います。なので、入門が目的であれば十分かと思っています。
また、今回は初動フェーズの話なので触れませんが、再発防止策を考えたりインシデント対応のふりかえりといったポストモーテムも必要な動きになります。
色々書きましたが私もできていない部分が多く、自戒の意を多分に含んでいます。
とはいえインシデント対応する人が1人でも増えると、会社・サービス・組織どの主語においても嬉しいことがたくさんあると思います。失敗を恐れずにインシデント対応をやっていきましょう。
明日のアドベントカレンダーは @takashi_matsuyuki さんの「HatenaBlog Workflows Boilerplateを試してみた」です！お楽しみに！
