障害対応時の心構え

はじめに

初めまして、ポートのバックエンドを担当している @nakahara です。

エンジニアとしてサービス開発や運用に関わる上で、避けては通れないことがあります。
そう、障害対応です。

できればエンカウントしたくない事案ではありますが、長く開発に関わっていればいつかは直面する状況です。

弊社の開発チームでは "エラー当番" という制度を運用しており、フロントエンド、バックエンドそれぞれで一日毎に担当者を一名置いて、持ち回りでエラー監視をしています。

今回は自分がエラー当番の日に障害が発生し、その対応しなければならない、、といった際に自分なりに心がけていることをまとめようと思います。

まずは冷静になる

突然の障害報告がくると、人それぞれだと思いますが、私は結構テンパってしまいます笑。
焦っている状態では、正しい状況判断もできなくなるので、一旦冷静になりましょう。

とはいっても簡単に冷静になれるわけでもありません。

私の場合は、自分が緊張状態にあることは正しい反応だと自分に言い聞かせます。
二次障害を避けるためにも、障害対応時は慎重になりすぎるくらいの方が良いと思っているので、「ある程度緊張してるくらいが良いよね」と開き直ります。

障害対応の緊急度を確認

私が所属する開発チームでは、下記のような基準を設けて障害対応への緊急度を判断しています。
状況を確認し緊急度に応じて、対応方針をサイト管理者に伝えます。

サイトへアクセスができない

緊急度高、すぐ対応

サイトへアクセスできないことがある、なかなか反応が返ってこない

緊急度高、すぐ対応

サイトへアクセスできるがいつもより遅い

緊急度そこそこ高、早めに対応

サイトへのアクセスは問題ないが、何らかの通知がきている

緊急度中、その日中に確認、対応

障害範囲を確認

次に障害の範囲を調査します。
運営側にのみ影響があるケースなどは、社内周知だけで済む場合もありますが、例えば一般ユーザーに誤ったメールが一斉送信されているといったケースでは、障害対応よりもユーザーへの謝罪連絡の方が優先になる場合も考えられます。
なので本格的な原因調査の前に、障害の影響範囲をサイト管理者に伝えるようにしています。

障害原因の仮説立て

影響範囲が判明したら、障害原因の調査に入ります。
自分は下記の様に切り分けをして調査をしています。

直近で変更が加えられた箇所の確認

一番障害が発生することが多いのは、リリースの直後だと思います。
リリース直後に障害が起きた際には、まずその日の変更箇所を確認します。

整合性の取れないデータが保存されている

ソースコードに問題がなさそうな場合は、このパターンを疑います。
イレギュラーな操作によって、関連付けされるはずのデータが存在していない場合や、
別タブでの操作、連続クリックなどによる二重送信が起きているケースなどを調査します。

不正なアクセス、悪意ある攻撃

明らかに異常なパラメータがリクエストされている、ユーザーエージェントが不審な場合などは
外部的な要因でエラーが発生していることを疑います。
必要に応じて、ipをブロックするなどの対応を考えます。

暫定対応、恒久対応を考える

原因が特定できたら、修正に取り掛かります。
恒久的な修正がすぐに行える場合はそれに越したことはないのですが、修正に時間がかかってしまう場合もあります。

ページが閲覧できなくなっているケースなどでは、問題がある箇所の修正よりも障害状態からの復旧の方が優先度が高くなるので、変更箇所のrevertなどの暫定的な対応を先に行い、その後に恒久的な対処を行うようにしています。

復旧目処を伝える

修正の方針を決めたら、サイト管理者に障害の復旧目処を伝えます。
なるべく早めの復旧目処を伝えたいところではありますが、これに関しては少し余裕を持って伝えるように心がけています。
先述した通り、焦って作業すると二次的な障害を引き起こす可能性も高まる上、あらかじめ伝えた時間になっても復旧できなかった場合に、サイト管理者に不安を与えてしまうからです。

再発防止案をまとめ、振り返る

無事、障害を解消できたら、対応完了報告を済ませ、自分の対応に問題が無かったかを振り返ります。
急いで行なった修正が後々別の障害に繋がらないかなどを中心に確認します。

根本的な原因を振り返り、再発防止策をまとめたら、作業完了です。

まとめ

普段、心がけていることをまとめてみましたが、言うは易く行うは難しです。
また障害にぶつかったときにはこの記事を自分で見返しながら、対応にあたろうと思います。

そしてこの記事が、同様の状況に直面したどなたかの参考に少しでもなれば幸いです。