システム障害が起きた時の心構えと取るべき行動
こんにちは、いっせいです。
先日、Carelyが一時利用できなくなる障害を発生させてしまいました。
誠に申し訳ございませんでした。
このエントリでは障害が起きた時にどのように考え、どのような行動を取るべきかということを、
諸先輩方から教わってきたこと、自分が考えていることをお伝えしたいと思います。
心構えと行動
まずは冷静になる
障害は突然発生することがあります。
そうなると慌てる気持ちもわかります。
しかし慌てたところでサービスは復旧しませんし、
慌てながら作業をすることでさらなる障害を引き起こしていまう..なんてこともあります。
まずはひとつ深呼吸をして冷静になりましょう。
事実を集める
ある程度経験を積んだエンジニアだと「これが原因だろう」と思い込みで話を進めてしまうことがあります。
もちろん障害の箇所のあたりを付けることは大事ですが、
自分の経験や憶測を先に信じて話を進めていくと本当の原因から遠ざかってしまうことがあります。
代表的な「事実」としては以下のようなものがあります。
- Datadog, Mackerel, Sentry などの監視ツール/サービスからの通知
- 上記監視ツールのメトリクス
- デプロイしたソースコード
- サーバのログ
- データベースのログ
- AWS などの PaaS のステータス
まずは監視ツールからの通知があるでしょうからそこから事実を集めていくのがよいかと思います。
事実を記録する
また事実を時系列順に記録していくことも大事だと考えています。
「Aという作業をしたあとにBという障害が起こり、Cという状態になった」のか
「Bという障害が起こり、Aという作業をしたあとにCという状態になった」だと、原因や影響が異なってくることがあります。
何がいつ起こったのかという情報はとても大切です。
障害対応中はバタバタすることが多く、振り返ってみて「あとの時何したんだっけ？」となりがちです。
次回同じ障害が起きた時などのための手順書を作ることがあるかと思いますが、そのときにも役立つと思います。
声をかける
チームで障害対応を行う場合にはSlack上などで「私はサーバのログをみます」「では私はメトリクスを確認します」などの声掛けをしましょう。
限られた時間で効率的に障害対応を行うためにチーム内で情報共有を行っていきましょう。
リスクの分析と対応方針を決める
事実が集まってきたら影響範囲が見えてくると思います。
すぐにコードを修正して緊急リリースする必要があるのか、
それとも一旦はそのままにしておいてよいのか。
上長を含めてチーム内で検討しましょう。
対応方針を決めたら粛々と対応していきましょう！
障害対応アンチパターン
障害対応中にしてはいけないこともあるかと思います。
最初から根本解決をしようとする
例えばソースコードのロールバックで応急処置が可能な障害なのに、
時間をかけてソースコードを正しい修正してリリースしようとしてしまうことがあります。
これが正しいこともありますが、まずはサービスを復旧させることが大事かと思います。
責任の所在を明確にしようとする
障害が起きている真っ只中にするべきことではありません。
誰が悪いかなどユーザーにとっては関係ありません。
サービスを復旧させることが一番です。
おわりに
自分が障害が起きたときにどのように考えて行動しているかを書いてみました。
みなさんそれぞれ障害や障害対応に対しての考え方があるかと思います。
iCARE Dev チームは毎月 meetup を行っていますので、ぜひお話しましょう！
それではまた！
