本番障害が発生したときにやるべきこと

結論

　１．顧客影響、業務影響を極小化する
　２．直接原因を踏まえて横展開する
　３．システムを復旧する
　４．直接原因のみならず根本原因を明らかにする
　５．再発防止する

詳細

１．顧客影響、業務影響を最小限にする

まずは業務影響、顧客影響はどのくらいあるのか、代替策があるのか、を把握する。

システム復旧には時間がかかることも多い。システム復旧できなくとも影響を極小化することを最優先する。

原因は後でよい。システム復旧も（代替策がない場合を除き）後でよい。

２．直接原因を踏まえて横展開する

影響を極小化するには、他に類似障害がないかを確認することも重要。
このときの横展開の目的は（潜在的な障害が顕在化することによる）影響が
出ないようにすることなので、直接原因レベルでよい。

原因となった資源をリリース（本番環境へ移行）する際に、システム停止が必要となる場合、何度も停止することを避けるという意図もある。

３．システムを復旧する

直接原因、修正範囲が明らかになったら修正する。

このときデグレード（プログラムの変更または修正により、他のプログラムに意図しない影響が生まれ、変更・修正前よりもソフトウェアの品質が劣化してしまうこと）を発生させないことも重要。

最初に業務影響、顧客影響を把握し、代替策を実行して影響を極小化できているなら、システム復旧を焦る必要はない。

４．直接原因のみならず根本原因を明らかにする

システム復旧が完了したら、根本原因を分析する。
少なくとも以下３つの観点が必要だろう。

　（１）なぜ作りこんだのか
　（２）なぜテストで検知できなかったのか
　（３）なぜレビューで検知できなかったのか

また、以下の点に気を付ける必要がある。

　（１）深堀がただの繰り返しになっていないか。（小泉構文）
　　（悪い例）項目の型が一致していなかった。なぜなら、型が不一致になってたからだ。
　　（良い例）型の考慮が漏れていた。なぜなら、型の一致という観点がレビュー観点として資料化されておらず、属人的になっていたからだ。

　（２）逆からたどったとき因果関係が成立しているか
　　「A（結果）なのはB（原因）だったから」
　　であれば、「B（原因）だったのでA（結果）だった」と逆にしても日本語として成立する。

　（３）ルール、体制まで踏み込んでいるか
　　担当者レベルだと、ルール、体制まで踏み込んで原因を考えることができないことは多い。
　　よって、影響度によってはマネジメント層も巻き込んで原因分析する必要がある。
　　また、直接原因から始まり、「なぜ」と５回繰り返して分析することも有効。

５．再発防止する

再発防止策は上記で分析した根本原因に紐づく必要がある。
また、再発防止策を徹底させる仕組み、運用も含めなければ意味がない。

・（悪い例）型の一致を確認することを徹底する（ただの決意）
・（良い例）型の一致を確認するという観点をレビューチェックシートに盛り込み、二次検証者の氏名、検証日の記載欄を設けて検証したことを証跡として残す。
当レビューチェックシートを成果物として提出することを開発標準に明記する。
（※）開発標準に沿って開発するというルールが徹底されていることが前提ではある。開発時に必ず目に付く箇所に記載しておくことが重要。

また、防止策の粒度も適正か確認する必要がある。（難しいが）
　・粒度が粗いと（抽象的だと）対策ががぼやけて重要な点が確認不足となる
　・粒度が細かいと（具体的だと）類似事象は防ぐことができても他の障害を防ぐことができない。

背景

トラブル発生時に「なんでそんなことになってんの！？」と原因を知りたい気持ちもわかる。

が、最優先は顧客、業務への影響を極小化することである。

そのためにシステム復旧が不要であれば（代替策があるのであれば）後回しでもよい。

新規参入メンバーにその意識を浸透させる必要があるという課題認識から改めて整理した。