本番障害発生時のあれこれ

この記事は BABY JOB Advent Calendar 2022 の 24日目の記事です。

はじめに

今日はクリスマス・イブですね！
こんな楽しい日に本番障害をテーマに記事を書こうと思います(笑)

筆者のプロフィール

• 2022/11 にBABY JOBに入社したばかり
• 障害対応の経験は新卒から約6年いた保守開発のPJでいろいろやりました
• 直近数年はPoC開発など本番稼働前の開発ばかりしていた

なぜこのテーマなのか？

私自身久しぶりに本番稼働しているシステムを触るということで、
本番障害とも付き合っていくことになるんだなと覚悟(？)はしていました。

そんな矢先、入社初日のオリエンテーション中に本番障害が発生(※)しまして、
ちょっと懐かしさを感じながらも、改めて気が引き締まったということと、
リハビリも兼ねて纏めてみようと思ったわけです。

※決して頻発してるわけじゃないです(今回も1年ぶりとか？)

前提

アプリにバグがあって発生するような本番障害を想定して記載します。
サーバーが止まってるとかのインフラ系の障害は想定してません。
※インフラ系で何かあったときはただただ祈ってました。

全て筆者の経験による主観なのでご意見いただければ喜びます。

発生時になにをするべきなのか？

さっそくですが障害が発生したら何をすべきなのか？
どういう順番でやるべきなのか書いていきます。
対応の順番としてはざっくりとこんな感じかなと思います。

1. 情報収集
2. 原因の調査
3. 影響範囲の調査
4. 対策の検討と実施
5. リカバリー

以降でそれぞれについて書いていきたいと思います。

場合によっては当事者が明確な場合がありますが、
冷静な判断が出来そうにないなど、精神状態によっては対応メンバーから外すことも検討しましょう。

1. 情報収集

原因の特定につなげるための情報を集めます。
2.原因の調査 と並行して行うこともあるかと思います。

場合によってはここはほとんど不要な場合もあります。
(発生する箇所や内容が明確な場合とか)

なかなか再現パターンが掴めない場合や、
バグが入り込んでから発覚までに時間が経ってそうな場合は特にここが重要になってきます。

• いつ起きたのか？
• どんなことが起きたのか？
• 類似のデータで同じことが起きているデータはないか？
• 同じことが起きていないデータとの違いはなにか？

などなどいろんな観点で情報を集めます。
それぞれ複数あるとよりいいです。
できる限りたくさん情報を集めましょう。

2. 原因の調査

ここが最も重要な作業です。
ここで間違うと以降の作業が全て無駄になります。

本番で動いているアプリと同じコードの環境で実施します。
当たり前のことですが、焦ってると意外に忘れがちだったりするのであえて書きます。

1.情報収集 で集めた情報を元にまずは調査している環境で再現させます。
再現さえすればあとはデバッグなりしながら原因の特定ができます。

ここで重要になるのが

• その原因で本当に間違いないのか？
• 他に原因となるバグが潜んでいる可能性はないか？
  の検証です。

それっぽい原因を1つ見つけると安心してしまうものですが、
「現象は似てるけど違った」とか「他にも不具合が潜んでいた」なんてこともあり得るわけです。

じゃあどうやって見つけた原因が正しいと判断するのか？ですが、
1.情報収集 で集めた情報全てに対してその原因で説明ができるかどうか？だと思います。

全ての説明の辻褄があえばほぼ間違いないと判断できると思います。

3. 影響範囲の調査

次は影響範囲を調査します。
原因がわかると、すぐにコードをどう修正するか(対策)を考えてしまいがちですが、
この影響範囲によって対策が変わるためまず影響範囲を調べます。

具体的には応急処置が必要かどうかが変わってきます。
例えば、

• 毎分何百件も不具合データが新たに生み出される
• 画面が動かず業務が止まってしまう
  などのような場合はスピードを優先した対策を打つ必要があります。

逆に2月29日にしか発生しないなら、対策は4年後までにやればいいと判断できます。

4. 対策の検討と実施

影響範囲によっていつまでに何をやるべきかを検討します。
前述したようにスピードを優先する必要がある場合は、
段階的に対策を打っていく必要があります。

5. リカバリー

ここは特筆すべきことはないですが、
データが不整合な状態になってしてしまっている場合はあるべき状態に戻しましょう。

対応が終わったら

起きてしまったものは仕方がないので、
次に同じことが起こらないようにするために、
障害対応が一段落したら振り返りをしましょう。

• なぜ起こったのか
• 気付けるポイントはどこにあったのか
• どうすれば防げたのか

などいろんな観点で分析して次に繋げましょう。

絶対にやってはいけないのは個人にフォーカスすることだと思っています。
ましてや、個人を責めるなど論外です。
プロジェクトとして、チームとしての改善策を考えましょう。

最後に

本番障害というと精神的ダメージが大きいですが、
運用や開発プロセスなど改善点が見つかるタイミングでもあるため、
起こってしまっても悲観的にならず、
チームとして前進する策を改めて考える機会と捉えましょう。

個人を責めるなど論外です(重要なので2回言う)

最後までお読み頂きありがとうございました。