タイムラインで目に付いたこの記事を読んで考えたこと。
そういえば障害発生時の対応フローは、割と標準的なものが無いような気がする(不勉強で知らないだけかもしれないけれど)。共通フレーム2013でも細かい定義は無かったし、他の書籍で読んだ記憶も無い。というわけでいったん経験的な知恵をアウトプットしてみようかと。
基本的な流れ
割と自分のイメージと似た障害対応フローが公共系システムのドキュメントとして公開されてたので流用する。ここから拝借したもの。
図にもあるように、基本的な流れは
- リカバリー対応（初期対応、一次対応）
- トラブル復旧作業（本格対応）
- 再発防止
が一般的だと思っている。
初期対応のフレーム
初期対応で考えることはだいたいこんな感じ。あわててプログラムを修正する前にやることがある。
- 問題調査のために保全すべきデータやログを確保する。時間経過や調査のための作業で情報が抹消されないようにする。
- 問題原因を絞り込む。特定するのがベストだが、特定できない場合は後述の止血対応のために問題原因を類推する。
- 原因（場合によれば仮説）に基づき影響範囲を特定する。
- 問題の拡大を防ぐ止血対応を行う。最悪サービスを止める場合もあれば、機能制限するという場合もある。例えば他システム連携機能だけ停止するとか。ケースバイケース。
- 正しくないデータが存在することで二次被害が出る可能性があるのであれば、データを修正する。なお今後の調査や検証のために、修正前のデータはきちんと保全しておく。
上の図で言うと「原因解析、リカバリ方法の検討、検証、設定・実施」あたりがこれに該当する。
冒頭で紹介した記事にも書いてあるが、原因を深追いしてしまい出血死しないようにすることが重要である。
原因特定に執着して時間をかけてしまっては、傷口が開いてしまいます。
システム障害と僕達はいかにして戦えば良いのか、障害対応について考えた - Qiita
本格対応のフレーム
とりあえず血が止まったら、本格対応である。実際の対応内容は障害内容や原因にもよるのだけれども、考えることはだいたいこんな感じ。
- ソフトウェアの不備や考慮不足であれば、問題原因そのものについて修正を行う（直接原因の是正）。
- 扱うデータ内容にもよるけれども、必要に応じて誤データについて回復処置（データの復元、復旧）を行う。また関連システムに誤データが流出している場合は、この対策について相手先と調整する。
- 同じ不備や考慮不足が、ソフトウェアの他の部分にも無いか確認しあれば修正する（直接原因の横展開調査）。
- バグが埋め込まれた原因を振り返り、その原因に基づき見直すべき範囲があれば確認し、問題があれば見直す（バグ埋込原因に基づく横展開調査）。
- バグがリリース前のテストで検知されなかった理由を振り返り、不十分なテスト範囲があれば確認し、問題があれば見直す（バグ不摘出原因に基づく横展開）。
もちろん原因がまったく特定でいないという場合もある。元記事で紹介されているWikipediaの「特異なバグ」というページは知らなかったのだけれども興味深い。
いつまでたっても原因特定できない場合は、問題再発検知の仕組みを仕込んで経過観察扱いにするということもある。永遠に経過観察するわけにもいかないので、半年や1年待って再発しなければ原因不明で対応完了としてしまうのが良い。
再発防止のフレーム
本格対応が終わったら、最後に再発防止を検討する。本格対応段階でバグ埋込原因やバグ不摘出原因が明確になっていれば、それに対しての恒久的な打ち手を考えるといったところ。
- 「気をつける、注意する」といった方向性はナシ。
- 安易に作業プロセスを追加・変更しないようにする。生産性が落ちやすいため。
- 勉強会をする、といった教育系の打ち手は効果が見えにくいのと、不勉強であることの宣伝になるので避ける。
- もちろん勉強会は否定しないけど、「再発防止策です」と言って外部に発信するのは避けたい
- 一番良いのは自動化やツール導入など。人が介在せずにチェックできるのがベストではある。
- 問題内容のレアケース具合によっては、再発防止しないという選択肢も常に考える。費用対効果の問題があるからだ。
と、ここまで書いてみたのだけれども経験的な知識のアウトプットであるため、なんともまとまりが悪い。それと、何か書き忘れていることもあったような気がしている。というわけで上記はあくまで参考程度でご参照下さい。
