この記事はリンクアンドモチベーションAdvent Calendar 2021 の18日目の記事です。
はじめに
障害って本当に寿命縮みますよね。
私は現在、障害が起こると一番に動くチームに所属しているので寿命が1ヶ月くらい縮んだ気分です。
新卒3年目のペーペーでもあり、様々な障害対応の場面で石につまづき落とし穴に落ちてきました。
しかも障害対応は日々命がけです。育成なんか悠長なことは言ってくれません。
そこで、これより障害対応の避難訓練を行います！！！
ある日…
slackの通知音、見たことのないエラー表示に気づいたあなた。
やばい、障害です。
この時あなたが取るべき行動は？
①エラーの原因を調べる
②slackの@ channelを投下する
正解は…
②です。
正直②をやった後で①をやっても30秒くらいしか変わりません。
障害かも？と思ったらまずいろんな人に知らせましょう。
※組織によってメンション先をカスタマイズしてくださいね！
また、あなたがエラーの調査ができそうなら、5分で調べた後に②をやるとその後の連携がスムーズです。
調査に３０分や1時間かかるようなら、最初にみんなにメンションしちゃいましょう。
（misohagiさん、ご指摘ありがとうございます！）
ちなみに…
障害対応は、障害指揮官（インシデントを解決に向けて動かす人）、調査・対応エンジニア、外部通信役（顧客との連絡を司る人）、書記官などの役割で対応していく人が必要です。1
少なくとも上記役割の人には連携しなければなりませんので、あらかじめメンションしておくといいでしょう。
事前に開発組織でインシデントが起きたときの上記役割の人を認識しておくと便利です。
あなたが実装した機能でエラーが発生
やっちまいました。
脳内をいろんなものが駆け巡り、冷や汗が流れます。
その時あなたが取るべき行動は？
①エラーの原因を調べる
②一呼吸入れる
正解は…
②です。
焦って対応しても何もいいことはありません。
二次災害がひたすらに増えるだけです。
障害が起こった！！！と思ったら、一度深呼吸して落ち着きましょう。
1人の落ち着きが全体の落ち着きにもつながります。
やっぱり障害だった
迅速な対応で、エラーの箇所と機能を特定したあなた。
優秀ですね。
何が起こってるかまとめて共有して欲しいと、外部通信役の人に言われました。
どちらを共有する？
①A画面でB機能が使用できなくなっている
②hogeでNoMethodErrorが起こり、fugaがnilだと怒られている
正解は…
①です。
外部通信役の人は障害に関する顧客との連携を担ってくれている人です。
この人は「顧客が何に困っているか」にしか興味がありません。
NoMethodErrorと言われた瞬間にあなたのもとを去っていくでしょう。
ちなみに…
障害調査の人に共有して欲しいと言われたら②が正解です。
この人は「どこで障害が起こっていて何をすべきなのか」に興味がある人です。
まあ①も伝えるべきですが。
情報を連携する相手の役割によって、①②両方を伝えることが正解な場面もあります。
なんのために情報が欲しいのかを認識しましょう。
タスクが振られた
障害対応メンバーに入ったあなた。
今日は外部通信役の人と連携するタスクをメインに障害対応をしていくようです。
影響顧客（障害に影響を受けた顧客のこと）を出してくれと言われました。
そんなもん出したことないわと心の中で突っ込みながら、あなたはどうする？
①一旦全顧客のidを羅列する
②顧客のなんの情報が欲しいか聞く
正解は…
②です。
そんなもん出したことないわと心の中で突っ込むなら、きっとあなたは外部通信役が何を求めているかわからないはず。
すぐにタスクに取り掛からずに、何が欲しいか聞いてみるといいでしょう。
その一手間がその後の10分間の巻き戻りをなくします。
ちなみに…
何が欲しいですか？と聞くだけでは抜け漏れが発生します。
目的、対象、納期、アウトプット形式の認識を合わせるとスムーズだと思ってます。
例
目的：お客様に現状共有をするため
対象：影響を今現在受けてるお客様
納期：12:00までに
アウトプット形式：スプレッドシートにidと顧客名とメールアドレスを記載
なんだか対応方針で揉めているみたい
障害の原因は突き止めてくれたみたいですが、対応方針が3つほど出ているようです。
実装者ということで「どれがいいと思う？」と聞かれたあなた。
なんか2個目っぽいなあ〜と思うなあ…
さてどう答える？
①2個目っぽいですね〜…でも正確にはわかんないのでマネージャーに聞いてください
②2個目っぽいですね〜…
正解は…
①です。
対応方針は確実に、簡単に、早く行えるものを選びます。QCDです。
実装者だからといって、顧客影響が出ている障害の方針決定の役割は担えません。
大体こういったものはマネージャーに責任を持ってもらったほうがいいので、マネージャーを呼びましょう。
暫定対応完了が見えてきた！
対応方針は対象のデータ削除というもの。
スクリプトを書いて欲しいと依頼されたあなた。
もうあなたが障害対応のメインになってますね。
さてどう書く？
①削除対象か確認、想定しているものか確認、削除、ちゃんと消えてるか確認…というスクリプト10行
②シンプルなほうがええやろ！対象データ削除というスクリプト3行
正解は…
①です。
正直消すだけなら3行だったりもしますが、二次災害防止のため確認できるものや対応記録が残るようなスクリプトを書きましょう。
本当に対象あってる？メモった？テストした？本当に消えてる？他に消えてない？とめっちゃ確認しましょう。
この30分が後々の5時間を救います。
これってこの機能だけ？
障害指揮官からこのバグって他の機能では起こらないの？と聞かれたあなた。
そういえば実装するときにC画面のD機能のメソッドを使ったんだよなあ…
でもC画面のD機能は今回の問題とは関係なかったよなあ。
さてどう答える？
①ちょっとわかんないので調べます
②C画面のD機能を参考にしましたがそちらでは起こりません！
正解は…
①です。
障害は参考にした機能だけで起こりうるとは限りません。
他にも同じメソッドを使っている場所はないか、水平的に調査をする必要があります。
ちなみにこの障害指揮官の聞き方は意地悪ですね。
水平調査は時間がかかるのでちゃんとタスクとして振ってあげなきゃいけません。
止血完了！
いやーがんばった！
まだまだ恒久対応や振り返りはありますが、一旦お客さんが超困る場面は脱しました。
あなたは大活躍でしたね！
お疲れ様でした！
①がんばったし3時間くらい離席する
②あと少し！現状とやったことのまとめをslackに投下し、引き継げる状態にしてから離席する
正解は…
②です。止血直後は再出血してもおかしくありません。
長時間離席する場合は誰かに引き継ぎをしておくと良いでしょう。
お疲れ様でした！
後日談
実は障害対応はこの後恒久対応をしたり再発防止策を考えたりモニタリングをしたりと
まだまだやることはあります。
一旦落ち着いたようでよかったよかった！
今後のためにしっかり要因を振り返りましょう！
まとめ
書いてみると、インシデント対応だけではなく日々の業務でも使えそうな観点がありました。
- フローを考えて情報発信をする
- タスクの目的を考えて実行する
- 急がば回れで確認を徹底する
めちゃくちゃ抽象度が高くなってしまいましたが、大事にしたいですね。
最後に
いっぱい書きましたが、正直深呼吸が一番大事です。
障害が起こったらみんなで1分くらい深呼吸して落ち着きましょう！
そのときに本記事をお供にぜひ。
それでは良い対応ライフを！