障害対応のフローをまとめてみました | Dev Driven 開発・デザインチーム 障害対応のフローをまとめてみました | 働くひとと組織の健康を創る iCARE

BLOG

障害対応のフローをまとめてみました

shogofukuden
2021/02/05

こんにちは、でんでんです。
唐突ですが、みなさん、障害対応は好きですか?
僕は割と好きです。
問題を切り分けて探っていくことや、他チームと連携して動くの楽しくないですか?(もちろん障害は起こらないのが一番です。)

ただ、問題の切り分けなどは業務で鍛えられますが、
他チームとの連携は難しく、苦労した記憶があります。
そんなわけで、自分なりに障害対応フローをまとめてみました。

フロー

場合によって前後したり、飛ばすこともありますし、
細かいところは省略してますが大体は以下のフローです。
(青は特に他チームとの連携が必要になるところです。)

状況の確認

当たり前ですが、障害報告があったとき、最初にするのは状況の確認です。

  1. ユーザーが何をしたのか
  2. どんな画面になったのか
  3. 関連機能の変更が直近で行われていないか?
    • もし行われていたら、誰が修正したか?

などです。
できるだけ詳細に、できればURLかスクリーンショット、エラー文言はもらいたいです。

影響範囲の仮調査

厳密でなくても良いので影響範囲を探りましょう。
全クライアントか、一部なのかぐらいで良いです。
この後報告したときに、相手がレベル感を把握できれば良いです。

上長に報告

ここが一番大事です!!
報告するのが大事です!!
取り敢えず言いましょう!!
この報告で、先輩がウルトラC決めてくれたり、実は別件で対応中と教えてくれたりします。

重要かの判断

絶対にこの判断は上長に報告した後にした方が良いです。
重要性の判断は、システムとしてだけではなく、

  1. クライアントとの関係値
  2. クライアント数や規模

などビジネス的側面が入ります。
現場だけでなく、上長/他チームの意見も踏まえて判断して(もらって)ください

緊急かの判断

緊急性の判断も、前述の重要性の判断と同じです。

緊急のとき

障害の根本対応が待てない場合もあります。
そんなときは、取り敢えずの一次対応をしましょう。

ここで大事なのは、要望を鵜呑みにしないことだと思います。
障害報告と同時に「◯◯にしてほしい。」と言われると思いますが、
その時クライアントのゴールも聞きましょう。
要望の◯◯を飛ばして、エンジニアならではのウルトラCを出来るときがあります(たまに腕の見せ所です。)

根本原因の調査 + 再現可能か?

一次対応後、または不要なとき、根本原因の調査に入ります。

調査する中で時々、

  • お客さんのアカウントでは起こるのに、テストアカウントだと起こらない
  • 本番では起こるのに、別環境だと起こらない
    ということがあります

そういうときは、

  1. 関連レコードも含めて、同じデータを用意出来ているか
  2. 環境間の差異はないか
  3. インフラに問題はないか(1台だけサーバーが落ちてるなど)
  4. ユーザーの操作ログは、障害の報告と一致するか

あたりを調べると、大体は正解にたどり着くと思います。

影響範囲の確定/報告

根本原因の調査が終わってから、
再度、影響範囲を報告した方が良いことが多いです。

問題のあるクライアントに連絡or謝罪が必要な場合があります。
問い合わせが来る前に、こっちから連絡を入れたほうが、まだ印象がマシです。
時間勝負なところがあるので、早目にエンジニアから他チームに伝えてあげてください。

根本対応

連絡して、クライアントと調整してもらっている間、
頑張って直しましょう。
デグレしては意味ないので、複数人でレビューorモブプロするのが良さそうです。
終わったらお疲れ様です。ゆっくり休んでください。

フローには載せていないが大事なこと

証跡を残すこと

  1. 前提
  2. 調べたこと
  3. 考えたこと
  4. 試したこと + 結果

を残してください。助けやすさが全然違います。

TODOと予定を出しておくこと

  1. これからすること
  2. いつぐらいに終わるか

障害があるとクライアントの業務が止まるので、期限があったりします。
事前にこっちから伝えておくと、ちょっと交渉出来たりします笑
(交渉してくれるのは、エンジニアでなくCSですが...いつもありがとうございます)

仲間を集めよう

自分の得意領域でない障害のときもあります。
わからないときは、フロント/サーバーサイド/インフラなどの各方面の人を集めましょう。

最後に

色々書きましたが、とにかく大事なのは報告です。
調査のポイントなどはありますが、それは技術を身につけるとなんとかなり、
最後には連携の方が大事だったりします。
(その割に、教えてくれる人は少ない気がする)

プロダクトやチームによって変わるので、僕が書いたものも正解ではないですが、
誰かの参考になると良いな〜と思っています。