3 カ月で改善! システム障害対応 実践ガイド インシデントの洗い出しから障害訓練まで、開発チームとユーザー企業の「協同」で現場を変える(サンカゲツデカイゼンシステムショウガイタイオウジッセンガイド インシデントノアライダシカラショウガイクンレンマデカイハツチームトユーザーキギョウノキョウドウデゲンバヲカエル)

本来、システム障害をゼロにできるのが理想ですが、現実はそうはいきません。いざ障害が起きると対処に追われ、「ちゃんと体制を整えておかないと」という話になるものの、結局、目の前のことが優先され、障害対応の改善は後回しにー。本書では、起きてしまったシステム障害でエンドユーザーを困らせないために、対応プロセスを最短で改善するための方法をお伝えします。「アラートが多すぎる」「対応できる人が限られている」「障害時のコミュニケーション方針があいまい」といった課題をつぶしていき、障害訓練を行うところまで徹底解説します。

障害が起きるたびに対処に追われ、体制を整える話が後回しになる現場を、3 か月で立て直すための手順をまとめた実務書です。『3 カ月で改善! システム障害対応 実践ガイド インシデントの洗い出しから障害訓練まで、開発チームとユーザー企業の「協同」で現場を変える』 (野村浩司、松浦修治 著、翔泳社、2023 年 9 月刊) は、アラートの多さ、対応できる人の偏り、障害時のコミュニケーション方針のあいまいさといった課題を順につぶし、障害訓練を行うところまでを扱います。版元の紹介によると、著者は NTT データで金融システムの開発保守運用と改善を 12 年、リクルートで人材事業のプロジェクトマネジメントと IT サービスマネジメントを 14 年担当してきた 2 人で、7 年にわたって事例を分析して見つけた方法だと説明されています。

3 部 10 章の構成と、第 1 週から第 12 週までの改善ステップ

PART 1 で障害対応の意義と改善の始め方、改善する理由を確認し、PART 2 で改善の難所と、改善の肝となるサービス視点での運用設計を説明したうえで、PART 3 で実践に入ります。PART 3 は課題の特定に続いて、週ごとの手順が組まれているのが特徴です。CHAPTER 7 の第 1 週から第 4 週でアラートと問い合わせを洗い出して分類し、対処が要らないものと定型的なものを見分けて処置します。CHAPTER 8 の第 5 週から第 8 週では障害発生時のアクションと、判断の情報や基準、実行の役割と権限を定義し、CHAPTER 9 の第 9 週から第 12 週で大規模障害の定義とエスカレーション、体制の構築、コミュニケーションのルールを決め、最後に障害対応の訓練と振り返りを行います。CHAPTER 10 は継続的な改善のための役割の最適化で、付録として実践事例、便利な雛形、タスクとチェックポイントが付きます。版元の紹介では、各プロセスで使える雛形がダウンロード特典として用意されています。

アラートの洗い出しから始める障害対応改善の考え方

障害対応の改善というと、監視ツールの導入や手順書の整備から手を付けがちですが、日々の負担になりやすいのは、鳴っても誰も対処しないアラートや、同じ確認を毎回手作業で繰り返す問い合わせです。本書が最初の 4 週をアラートと問い合わせの洗い出しと分類に充てているのは、こうしたノイズと 繰り返しの手作業 を減らすと効果がすぐに見え、本当に判断が要る事象に人の注意を集められるからだと読めます。そのうえで、障害が起きたときに何を見て、誰が、どこまでの権限で動くかを事前に決めておくことが、障害対応のプロセス を安定させる要になります。判断の基準が決まっていないと、経験のある特定の人に対応が集中し、その人が不在のときに復旧が遅れるという属人化が起きます。版元が属人化と人的ミスの回避を掲げているのは、この構造を手順と役割の定義で崩すためです。

開発チームとユーザー企業の協同、SRE の本との違い

副題にある開発チームとユーザー企業の「協同」は、本書の立ち位置をよく表しています。障害対応では、システムを作る側と業務で使う側のどちらか一方だけでは、どの障害が利用者にとって重大かを決められません。サービス視点での運用設計を改善の肝に据えるのも、エンドユーザーへの影響を基準に優先度を決めるためと考えられます。Google が提唱した Site Reliability Engineering を扱う本が、信頼性の目標値やエラーバジェット、自動化を軸に組織とシステムの設計を語るのに対し、本書は大規模なエンジニアリング組織を前提にせず、既存の体制のまま運用の手順と役割を整える道筋に絞っています。SRE を本格的に導入する前の段階として、あるいは開発を担う会社と発注側の会社が分かれた体制の現場で、まず障害対応が回る状態を作りたい場合に合う構成です。

一方で、監視基盤の構築方法やクラウドの冗長構成、障害の根本原因を技術的に突き止める手法を求める人には、本書の範囲は合いません。扱うのはプロセスと体制の改善で、特定のツールの操作手順の本ではありません。運用の自動化や CI/CD まで視野を広げたい場合は DevOps 本の選び方 も参考になります。

障害のたびに同じ人が呼ばれ、振り返りをしても次の障害で同じ混乱が起きる現場のリーダーや運用担当者、発注側でシステムの運用に責任を持つ担当者にとって、週ごとに何をすればよいかまで落とし込まれた本書は、改善を後回しの課題から今週取り組む仕事に変えるための手引きになります。