dackdive's blog

新米webエンジニアによる技術ブログ。JavaScript(React), Salesforce, Python など

「システム障害対応の教科書」を読んだ

書籍

【改訂新版】システム障害対応の教科書

【改訂新版】システム障害対応の教科書

Amazon

読んだ。

本書の目次

第1章◆システム障害対応を学ぶ意義
第2章◆システム障害の定義
第3章◆システム障害対応の登場人物と役割
第4章◆各プロセスの基本動作～発生から終息まで
第5章◆障害対応に必要なドキュメント
第6章◆システム障害対応力を高めるツールと環境
第7章◆組織の障害対応レベル向上と体制作り
第8章◆システム障害対応力の改善と教育
第9章◆教育と育成の手引き
第10章◆障害対応訓練の実施
第11章◆事故を防ぐ手順書の作り方
第12章◆エンドユーザ向けの情報発信
Appendix◆難易度の高いシステム障害ケース

感想

システム障害対応に必要となる知識について、プロセスだけでなく体制作りや育成まで網羅的にカバーされており、まさに「教科書」といった感じだった。
私がそうだったが、通読しなくてもまずは興味があるところだけ読み、残りは必要になったときに参照するでもいいと思う。

とりあえず障害対応って何したらいいの？という人は第2章〜第4章とあとは第5章の「5.1　障害対応フロー図」「5.3　障害レベル管理表」あたりを読むのがオススメ。そこから発展して組織の障害対応の練度を上げる、みたいなことを考える必要が生じたときには第7章〜第9章あたりが参考になりそう。

個人的には第11章（手順書の作り方）、第12章（ユーザ向けの情報発信）が気になるトピックだった。が、これらは文量としてはそこまで多くなく、さらっとした内容だった。残念。

個人的に一番良かったのはこの図。

（p.35 より引用）

システム障害対応に関連するプロセスを上の図のように整理しており、かつシステム障害対応は「検知・事象の確認」〜「復旧対応」までとしている。
「本格（恒久）対策」以降を含まないのは、本書ではシステム障害対応の目的を「ユーザの業務影響を極小化し、早期に業務を復旧させること（p. 34）」と定義しているため。

この図の各ステップでやるべきことを理解した上で、実際の対応時は今この図のどのステップにいるのかを意識しながら作業を進めるのが良さそう。

気に入った一節

（参考：技術書は気に入った一節を見つけるだけでいい）

システム障害対応の目的は、システムを直すことではありません。ユーザの業務影響を極小化し、早期に業務を復旧させること。これがシステム障害対応の目的です。システムを直すことは、業務回復の手段の1つであり、目的ではないのです。(p.34)

「2.2.1・システムを直す≠障害対応」より。 エンジニア脳だと、どうしても障害が発生すると原因を突き止めて解決しようというマインドになりがちだが、障害対応における目的はそうじゃないよ、と。

内容メモ

第2章　システム障害の定義

  • なぜシステム障害の定義が必要か？→それがシステム障害対応プロセスを開始するトリガーの定義にもなるから

  • 本書におけるシステム障害の定義

    リリース後のシステムにおいて、システムの不具合やユーザ側の操作ミスで、ユーザ業務に影響が出ている。もしくは出るおそれがあるもの

  • Point：ユーザ業務に影響がなくてもシステム障害と定義する
    • 影響が出る可能性がある時点で、すべてシステム障害として扱いプロセスを開始すべき
  • Point：システム提供者側に責任がない場合もシステム障害と定義する
    • 例えば、認証基盤にSaaSを使っていてそこの障害が発生した場合とか
  • 2.2.1・システムを直す≠障害対応
    • 「気に入った一節」に書いたやつ。だいじ
  • 2.2.4 主要なマネジメントフレームワークの概要
    • ITILでもインシデント管理と問題管理を分けてるのね

第3章　システム障害対応の登場人物と役割

  • インシデントコマンダーの役割
    • 作業担当者への指示
    • 必要な人員を集め体制を構築する
    • 顧客や関連チームとのコミュニケーション窓口になる
    • 障害の発生と終息の宣言
    • 情報の整理・記録と更新
      • 事象、発生日時、影響範囲、etc.
    • ...
  • Point：インシデントコマンダー担当を固定化させない
    • 組織上の上長が常に担うのはアンチパターン
      • 上長は不在なことが多い
      • 部下の成長が止まる
      • 上長が能力を持っているとは限らない
    • インシデントコマンダーは組織上の上下関係によらず誰でもなって良い。育成方法は9章

第4章　各プロセスの基本動作〜発生から終息まで

  • 4.1 検知・事象の確認
  • 4.2 業務影響調査

    業務影響の確認は、ユーザ視点・業務視点で行う必要があります

    • 影響調査を疎かにしがちな場合は、影響調査担当（チーム）を作る
      • エンジニアは原因追及や復旧に注力してしまいがち
    • 影響あり／影響なし／調査中、を漏れなく伝える

第5章　障害対応に必要なドキュメント

  • 5.1 障害対応フロー図
    • ぱっと流れを掴むためにフロー図欲しくなるのはわかる
  • 5.3 障害レベル管理表
    • 今あるものとそこまで変わらないシンプルさ。逆にこれぐらいシンプルじゃないといけないんだな
    • 影響度と緊急度（影響がどれくらい出てるか） それぞれで基準を定義し、最終的な障害レベルはマトリックスで両者掛け合わせて考える
  • 5.4 障害状況ボード
    • 障害発生時に使う。ストック情報で、同じ場所で最新の状況が更新され続ける

第7章　組織の障害対応レベル向上と体制作り

さまざまな観点から、自組織が3段階のどのレベルに位置してるのかを評価する、という話。

第12章　エンドユーザ向けの情報発信

  • 情報発信する内容
    • 掲載日時、影響範囲、原因、代替手段など

  • Point：障害発生中は原因について詳細にアナウンスする必要はない

    ユーザにとっては、システムの利用可否・自分がとるべき対応について知ることが大切だからです。

  • 12.2 情報発信の方法

    • Point：初報は詳細な内容よりもスピード重視。また定期的な情報発信を行う

あわせて読みたい

参考になりそうな他社事例とかの資料を貼っておく。

週末の SRE Kaigi 2025 でも障害対応関連での発表がいくつかあったみたい。