障害対応のフローをまとめてみました
こんにちは、でんでんです。
唐突ですが、みなさん、障害対応は好きですか？
僕は割と好きです。
問題を切り分けて探っていくことや、他チームと連携して動くの楽しくないですか？(もちろん障害は起こらないのが一番です。)
ただ、問題の切り分けなどは業務で鍛えられますが、
他チームとの連携は難しく、苦労した記憶があります。
そんなわけで、自分なりに障害対応フローをまとめてみました。
フロー
場合によって前後したり、飛ばすこともありますし、
細かいところは省略してますが大体は以下のフローです。
(青は特に他チームとの連携が必要になるところです。)
状況の確認
当たり前ですが、障害報告があったとき、最初にするのは状況の確認です。
- ユーザーが何をしたのか
- どんな画面になったのか
- 関連機能の変更が直近で行われていないか？
- もし行われていたら、誰が修正したか？
などです。
できるだけ詳細に、できればURLかスクリーンショット、エラー文言はもらいたいです。
影響範囲の仮調査
厳密でなくても良いので影響範囲を探りましょう。
全クライアントか、一部なのかぐらいで良いです。
この後報告したときに、相手がレベル感を把握できれば良いです。
上長に報告
ここが一番大事です！！
報告するのが大事です！！
取り敢えず言いましょう！！
この報告で、先輩がウルトラC決めてくれたり、実は別件で対応中と教えてくれたりします。
重要かの判断
絶対にこの判断は上長に報告した後にした方が良いです。
重要性の判断は、システムとしてだけではなく、
- クライアントとの関係値
- クライアント数や規模
などビジネス的側面が入ります。
現場だけでなく、上長/他チームの意見も踏まえて判断して(もらって)ください
緊急かの判断
緊急性の判断も、前述の重要性の判断と同じです。
緊急のとき
障害の根本対応が待てない場合もあります。
そんなときは、取り敢えずの一次対応をしましょう。
ここで大事なのは、要望を鵜呑みにしないことだと思います。
障害報告と同時に「◯◯にしてほしい。」と言われると思いますが、
その時クライアントのゴールも聞きましょう。
要望の◯◯を飛ばして、エンジニアならではのウルトラCを出来るときがあります(たまに腕の見せ所です。)
根本原因の調査 + 再現可能か？
一次対応後、または不要なとき、根本原因の調査に入ります。
調査する中で時々、
- お客さんのアカウントでは起こるのに、テストアカウントだと起こらない
- 本番では起こるのに、別環境だと起こらない
ということがあります
そういうときは、
- 関連レコードも含めて、同じデータを用意出来ているか
- 環境間の差異はないか
- インフラに問題はないか(1台だけサーバーが落ちてるなど)
- ユーザーの操作ログは、障害の報告と一致するか
あたりを調べると、大体は正解にたどり着くと思います。
影響範囲の確定/報告
根本原因の調査が終わってから、
再度、影響範囲を報告した方が良いことが多いです。
問題のあるクライアントに連絡or謝罪が必要な場合があります。
問い合わせが来る前に、こっちから連絡を入れたほうが、まだ印象がマシです。
時間勝負なところがあるので、早目にエンジニアから他チームに伝えてあげてください。
根本対応
連絡して、クライアントと調整してもらっている間、
頑張って直しましょう。
デグレしては意味ないので、複数人でレビューorモブプロするのが良さそうです。
終わったらお疲れ様です。ゆっくり休んでください。
フローには載せていないが大事なこと
証跡を残すこと
- 前提
- 調べたこと
- 考えたこと
- 試したこと + 結果
を残してください。助けやすさが全然違います。
TODOと予定を出しておくこと
- これからすること
- いつぐらいに終わるか
障害があるとクライアントの業務が止まるので、期限があったりします。
事前にこっちから伝えておくと、ちょっと交渉出来たりします笑
(交渉してくれるのは、エンジニアでなくCSですが...いつもありがとうございます)
仲間を集めよう
自分の得意領域でない障害のときもあります。
わからないときは、フロント/サーバーサイド/インフラなどの各方面の人を集めましょう。
最後に
色々書きましたが、とにかく大事なのは報告です。
調査のポイントなどはありますが、それは技術を身につけるとなんとかなり、
最後には連携の方が大事だったりします。
(その割に、教えてくれる人は少ない気がする)
プロダクトやチームによって変わるので、僕が書いたものも正解ではないですが、
誰かの参考になると良いな〜と思っています。
