この記事は Timee Advent Calendar 2023 シリーズ 2 の10日目の記事です。
こんにちは！ @lucky_pool です。 タイミーでプロダクトマネージャーをしています。
はじめに
何らかのシステム障害が起こったとき、サービスを利用するあらゆる人に影響が出て、普段通りにサービスを利用できなくなってしまいます。そんな状況になった際、 “なんとかする” しかありません。
私はプロダクトマネージャーという役割で働いていますが、サービスのコード修正をすることや、データ変更のオペレーションをすることはありません。また、過去や新規に開発された機能や仕様をすべて熟知しているわけでもありません。ですが、障害対応においてインシデントコマンダーを担うことが何度かありました。
そこで、私がタイミーでインシデントコマンダーをやった経験から、一般的に役立ちそうな内容ををここでは紹介したいと思います。
インシデントコマンダーは誰でもなれる
ここでは、障害対応をなんとかする人を「インシデントコマンダー」と呼びます。
PagerDuty Incident Response *1 *2を参照すれば、インシデントコマンダーの説明は以下のとおりです。※ この記事はとても良い内容でして、なんと邦訳版としても公開されております。*3 *4 ありがたい！
Keep the incident moving towards resolution.
(意訳) インシデントを解決に向かわせ続ける人
そして次のようにも説明があります。
You don't need to be a senior team member to become an IC, anyone can do it providing you have the requisite knowledge (yes, even an intern!)
(意訳) インシデントコマンダーになるには、シニアメンバーになる必要はなく、必要な知識があれば誰でもなれる（もちろん、インターンでも）
そうです、やり方さえ分かれば誰でもなれるとのことです。私も、タイミーでのインシデントコマンダーの経験上、これは一定「確かにそう」と思っています。
PagerDuty のドキュメントには Requisite knowledge (必要な知識, 予備知識) と説明がありますが、実際は所属するチームや会社によって、対応できる権限や関係者、関係するツールが異なります。方法論を知ることは必要ですが、それらの知識をベースにした “経験” が必須だと考えています。故に実行することができます。
実際に私がどんな経験をしたかをかいつまんで説明します。
事前に経験したこと
私が入社したのは2022年10月です。約1年ちょと前です。入社後から(今もですが)、システム障害等、何らか問題が起きたとき、その事象を “なんとかしたい” という気持ちだけは持っていました。
そんな気持ちからか、いつのまにか以下のことを経験していました。
①障害対応に何度もオブザーブする
タイミーでは、何らかのシステム障害が観測されたとき、Slackの WF にて報告されることになっています。そして @障害報_通知グループ なるグループに通知が飛ぶようになっています。
- この通知グループは、障害報告を知りたい人が多く入っており、例えば、プロダクト開発の関係者だけではなく、カスタマーサポート、広報、管掌役員なども入っています
- また、メンション対象にいなくとも、投稿先のチャンネルは、全社への情報発信をする場所であり 数100人以上が見ているチャンネルだったりします
私はこの通知を受け取る一人となりました。WFによって自動的に Google Meet のURLを提示してくれるため、作業担当者が会話しはじめます。このGoogle Meet に入ることで状況を知るようにしました。
その過程で大まかな障害対応の手順がわかるようになっていきました。
例えば以下の通り。
- 影響範囲の調査
- 誰に影響があるのか、何に影響があるのかを調べます
- システム的な影響（xxx のエラーが xxx 件ある等）だけでなく、問合せ状況（xxxに関する問合せが、通常よりxxx件多い)、また手元での確認状況（xxxxの操作をするとxxxxになる）を把握するのに努めます
- 暫定対応方針の検討と実行
- 顧客説明方針
- 広範囲な障害であれば、なんらか顧客周知をすることを検討しなければなりませんが、そうではなく、社内一部業務フローのみの影響であれば、関係者に対し周知する方針にします
- システム対応方針
- できる限り早く、影響範囲を小さくできる方針を検討します
- revert するほうが手っ取り早ければそうしますが、そうはいかない場合は、なんらかコード差分を作りデプロイが必要になるかもしれません
- 顧客説明方針
- 定期的な情報共有
- 1および2の対応ステータスをリアルタイムに更新していきます、そうすることで、解消見込み時間などが分かり、安心する人たちもでてきます
- オンコール対応の収束
- 暫定対応を講じ、影響範囲を少なくすることに成功した場合、チームは解散します
- もし土日や深夜であれば、何らかの残対応があっても、翌営業日にすることがあるでしょう
- ポストモーテムの実施及び恒久対応の計画
- 恒久的な再発防止策だけでなく、プロセスの改善の検討と実施を計画します
②障害対応時のインシデントコマンダーの補佐をする
障害対応状況をオブザーブしていると、インシデントコマンダーを補佐できるようなことがいくつかあります。例えば以下の対応ができます。
対応状況の記録を取る
- タイミーの場合はドキュメントは Notion にまとめており、障害対応時においてもNotion ページに情報を集めていきます
- インシデントコマンダーは話をすること、情報を整理することに集中するため、文字列に整理することは難しいことがあり、故にこの補佐をすることはとても頼りになります
- また以下にも関連しますが、関係者にライブで状況を伝える役割にも一助になります
関係者にライブで状況を伝える
- WF で生成されたスレッドに、今の対応状況を箇条書きで投下しました
- 例えば
- 影響範囲がわからず、その調査を開始した、解消は未定
- 影響範囲は未確定だが規模として xxx が見込まれることがわかった
- 対応方針を検討しているが、大きく xxxx と xxxx の方針がでている
- xxx の方針を取ったため、 xxxx に解消が見込まれる
- 例えば
- これらのただの書き殴りだとしても、関係者にとっては有用な情報になります
- 障害対応時のタイムラインとして後で役に立ちます
関係者にメンションし呼び出してくる
- 対応に必要な人が Meet に来ていない場合は、容赦なくメンションします
- インシデントコマンダーや作業者が「xxxさん、xxxxチームに来て欲しい」という発言があれば、すぐに「じゃ、私が呼びますね」と対応します。
- インシデントコマンダーや作業者が解決に向かうことに集中してもらうことに役立てます
- また、作業者が複数チームに分かれる場合もあるため、両チームのハブとなるような動きをしてインシデントコマンダーの補佐ができます
- 例：
- A: 障害原因の調査および対処方針を検討するチーム
- B: 顧客周知方針を検討するチーム
- 例：
③ポストモーテムにオブザーブする
タイミーにおいて、障害対応をしたあとは関係者でポストモーテムを実施しています。もし、障害対応をオブザーブしていなかったり何らかの補佐をしていなくても、どのような障害があり、対応がされていたのかが理解できるため、ポストモーテムの参加からでも良い経験になると思います。
ポストモーテムにおいては、再発防止だけでなく、障害対応のプロセスの改善についても会話がされます。例えば、私が参加したポストモーテムでは以下のような会話がありました。
- xxx さん(xxxチーム) にて早期に報告があったのはいい動きだった！
- 以前に対応した xxx によって、今回の対応が早期に解決できてよかった！
- 今回 xxx の対応ができたことによって、顧客問い合せが 0件 で影響範囲を少なくできた！
もちろん、このような良い会話だけではなく、 xxx をすることによって、もっと効果的にできるというような具体的なアクションにつながるものもあります。
システム障害、それは突然やってくる
誰もが対応できる時間帯にやってくるとは限りません。なんとかする間には、サービスのあらゆる利用者に対して真摯に説明する必要がありますし、可能な限りはやく解消するしかありません。故に、事前にこういった経験をしておくと焦らずにすむと思います。また、事前にある程度経験した上で、書籍*5も読むと体系だった知識としても理解しやすくなるかもしれません。
本稿が転ばぬ先の杖として、参考になれば幸いです。
