はじめに
先日担当システムで大規模障害が起こり、障害の振り返りを実施していました。ここまで大規模な障害は初めてだったので、何をしたらよいかわからず、周囲の人に聞いたり過去資料を参考にしました。
必要なことは、「時系列整理と問題点洗い出し、真因と対策」です。
本記事では、障害振り返りで何をしたらよいかを、今回の経験をもとに記載しました。
※今後、場数を踏んでいけばこの記事も更新されるかも。
報告資料に書くこと
速報
復旧完了後、その日のうちに1枚のパワポで役員にあげるイメージ。
- 発生事象
- 発生日時
- 業務影響（〇〇システムの〇〇業務に対し、〇件のこんな影響が出た）
- 業務影響のリカバリ状況
- 直接原因
- 直接原因に対する対策（復旧方法）
- 復旧時刻
- 段階的復旧であればその内容
- 暫定対処のみで恒久対処は時間をかけてやる場合はその内容
- 簡単なシステム構成図と、どの部分で障害が起きたかなどわかる図
振り返り後の報告
- 障害内容サマリ
- 速報で書いたような内容のサマリ
- 障害の真因・対策を一言で
- 直接原因の詳細説明
- 直接原因の暫定対処／恒久対処のスケジュール
- 混入、流出、復旧長時間化について、振り返りをした内容。問題点・真因・対策を詳細説明
- 業務影響の詳細説明
障害振り返りでやること
再発防止に向けた振り返りを実施する。
ポイントは以下 3 つ。
- 混入原因：不具合を混入させてしまった原因
- 流出原因：不具合をリリース前に検出できなかった原因
- 復旧長時間化：（今回のように、影響を食い止められなかった場合）サービスの復旧までに時間がかかった原因。
① 問題点の洗い出し
混入原因・流出原因の洗い出し
不具合が混入した原因を明らかにする。
- なぜ不具合が起きてしまったのか、直接原因を特定。
- どの工程で発生してしまったのか、時系列と合わせて特定する。
- 直接原因の対処＝復旧方法について
（混入原因の例）
マスタの設定を間違えた、要件の調整でコミュニケーションの齟齬があった、製品バグを引いてしまった等。
（流出原因の例）
試験観点から漏れていた、試験環境と本番環境の環境差異により検出できなかった等。
（直接原因の対処の例）
商品マスタの設定が間違っていたので、商品マスタにパッチをあてる。
復旧長時間化における問題点の洗い出し
直接原因への対処に時間がかかった場合は、当日の対処についても問題点を洗い出す。
- 時系列を振り返り、できなかったことを洗い出す。
（例）15:00（障害発生から 180 分）：〇〇の作業に 2 時間かかった - できなかったこと（事象）に対して、「あるべき姿」を洗い出す。
（例）〇〇の作業は障害発生から 30 分以内に終わるべき - 「事象」と「あるべき姿」の差分が「問題点」となる。
（例）〇〇の作業の長時間化
以下の形の表を作り、チーム内で集まって振り返りを実施した。
※以下内容は適当な例なので参考にしないでください
| 時刻 | 障害発生から〇分 | 自システムの動き（自社） | 自システムの動き（開発パートナー） | 他システム | イベント | できたこと | できなかったこと | どうあるべきだったか |
|---|---|---|---|---|---|---|---|---|
| 13:00 | 00:00 | 営業から問い合わせ | ||||||
| 13:05 | 00:05 | 調査開始 | ||||||
| 13:20 | 00:20 | 被疑箇所特定（〇〇マスタ） | マスタ変更作業準備開始 | 被疑箇所特定に20分かかった | 被疑箇所特定は5分以内にすべき | |||
| 13:40 | 00:40 | 他システムの影響確認 | 障害体制構築 | |||||
| 13:50 | 00:50 | マスタ設定指示 | 作業開始 | |||||
| 14:20 | 01:20 | 作業完了 | 一部システム復旧 | 作業ミスで二次災害を起こさなかった | ||||
| ・・・ | ・・・ | ・・・ | ・・・ | ・・・ | ・・・ | ・・・ | ・・・ | ・・・ |
当日の時系列の整理は振り返りの中心となるので、障害が起きたら情報班の人がホワイトボードに時系列を書きだすことが大事。後で思い出すのはつらい。
書く人がいなければ率先してやる。
②真因の特定・対策の設定
問題点について、なぜなぜ分析を実施し、真因を特定する。
人のミスで終わらず、仕組み的・組織的な問題をあぶりだすことがポイント。今回は、チームメンバーで集まって問題点を洗い出し、各自なぜなぜ分析案を持ち寄り、いくつかの真因にまとめた。
真因に対し、対策を打つ。
結果は以下のようにまとめることができる。
| 問題点 | なぜ１ | なぜ２ | なぜ３ | 真因 | 対策 | 実施完了予定時期 | |
|---|---|---|---|---|---|---|---|
| 混入原因 | 商品マスタの設定作業で違う値を設定した | 設定作業の手順書が間違っていた | ～～ | ～～～ | 真因①：レビュープロセスが〇〇 | 対策①：マスタ設定作業の承認プロセスでレビューの〇〇を確認 | 12/26 |
| 〇〇〇が～～ | ～～ | ～～ | ～～ | ||||
| 流出原因 | 試験していなかった | マスタ設定だったから | ～～ | ～～ | 真因②：～～ | 対策②：〇〇 | 12/16（済） |
| 復旧長時間化 | マスタ設定作業が長時間化した | ～～ | ～～ | ～～ | 真因③：～～ | 対策③：〇〇 | 12/16（済） |
| 〇〇〇が～～ | ～～ | ～～ | ～～ | 真因④：～～ | 対策④：〇〇 | 12/26 | |
| 〇〇〇が～～ | ～～ | ～～ |
運用設計
システム障害は、起こるものだという前提でシステムを作るのが大事で、障害のパターンは事前に列挙しておくのが望ましい。
- 障害箇所（例：データベースとアプリの間のコネクション）
- 起こりえること（例：コネクションが枯渇する）
- 検知するメトリクス（例：コネクションプール）
- 復旧方針（例：データベース再起動）
- 復旧方針に対する手順書整備
さらに、手順書はすぐ使えるように更新しておく必要がある。構成変更などがある場合は注意が必要。
事業会社のシステム担当は、システムを作った後もずっと維持していく必要がある。運用設計のスキルが求められると実感した。。
個人的な感想
- 正常性バイアスという言葉を肌で感じた。障害が起きてすぐに「このあと会議キャンセルして体制取って…！」とできない。避難訓練ならぬ障害訓練大事。
- マズそうならすぐに偉い人を呼びに行こうと思った。
- 開発パートナーの会社との連絡はすぐに取ろう。とりあえずテレビ会議はすぐにつなげる練習をしよう。そして誰かパートナー拠点（離れている場合）に走ろう。
- アプリチームとインフラチームが分かれている場合、連携が希薄になりがち。すぐに情報共有を。
- クラウド時代だし、アプリ担当だからといってシステム構成知識が乏しいと障害の際に露呈して社内の立場が危うくなる（笑）ただ、普段の仕事で求められないから、机上で見てるくらいになってしまうんだよなあ…（その時間も限られていて…）
- 普段ビジネスとか未来とかの話が多い部長だが、開発技術の知識も凄まじく持っていることがわかった。うーん。すごい。
まとめ
本記事では、障害が起きた後の振り返りに必要な、時系列整理と問題点洗い出し、真因と対策の考え方をまとめました。
今回特に残したいと思ったのは②真因の特定・対策の設定の表です。
障害は普段学べないことが学べたり、緊張感たっぷりの雰囲気だったりで、普段より生き生きしてる人も多いです。
