【読書メモ】システム障害対応の教科書 その1
経緯
『システム障害対応の教科書』を買ったので、心に残ったことと、ToDo（行動に移すこと）をメモしていいきます。
今回はとりあえず第4章まで。
第1章 システム障害対応を学ぶ意義
心に残ったこと
- 同じ障害は何度も起きないので、反復による教育が難しい
- 障害対応はぶっつけ本番で鍛えないとダメという誤解があるが、体制や報告の仕方などの改善で対応能力を上げることができる
- 仮想化技術クラウドの普及に伴い、システム障害対応の難易度は上昇している
- 障害対応の「漏れ」に注意
- 連絡漏れ
- 影響調査漏れ
- 作業漏れ
- 確認漏れ
ToDo
- 障害対応能力が上がることを目的とした障害対応訓練の策定
- インフラ構成の理解度を調査
- 漏れがないようなフローを作成
第2章 システム障害の定義
心に残ったこと
- システム障害の定義はプロセス開始のトリガー
- ユーザ業務に影響が出ていなくてもシステム障害と定義し、プロセスを開始する
- システム障害定義をサーバ停止などの具体的な事象にしない
- 障害対応の振り返り項目の一つに「障害対応のタイミングや方法が適切であったか」を加え、ドキュメントの陳腐化を防ぐ
- システム障害対応の目的、範囲を定義し共有する
- 共有するときはそのプロセスの用語や内容に齟齬がないようにする
ToDo
- システム障害の定義をし共有する
- 障害対応フロー図や連絡先管理表を作成し共有する
- 振り返り項目に「障害対応のタイミングや方法が適切であったか」を加える
第3章 システム障害対応の登場人物と役割
心に残ったこと
- 障害対応の際は役割を分けて
- インシデントコマンダーには技術力よりも自体を掌握するマネジメント、コミュニケーションスキルが重要
- 必ず根拠・事実に基づいた報告を受ける
- 他部所などから作業担当に直接支持が行かないようにする
- インシデントコマンダーは組織の上長である必要はない（部下の成長が止まるため）
- 最後まで真摯さを失わずに対応する
ToDo
- 障害対応時の役割を分ける（しかし、小さい会社の場合はどうしたら良いんだろう）
- インシデントコマンダーは人員の育成も視野に入れる * スキルレベルに応じて分けていいかも
- 真摯に対応するよう心がける
第4章 各プロセスの基本動作 発生から終息まで
心に残ったこと
- 検知・事象確認で必要なもの
- コミュニケーションツール
- システムの今の状態がわかるもの（監視ツールとか）
- 本来の機能・仕様が分かるもの（仕様書とか）
- 初報は不明な点があってもいいので、とにかくスピード重視
- 影響調査で大事なこと
- 影響あり/影響なし/調査中、を漏れなく伝える。断片的な情報はミスリードにつながる
- 原因調査プロセスで大事なこと
- システム構成図などで意志の疎通を図る
- アプリとインフラで調査方法が異なる
- アプリはインプット・アウトプット・業務仕様を押さえて調査検証
- インフラはシステム障害事象の共通性などから想定箇所の仮説を立てて調査検証を行う
- 早急に業務を復旧させるのが優先なので、What（どこが壊れたのか）までで良く、Why（なせそうなったのか）までは必要ない
- 事実と仮説を混同しない。そのために原因調査ステータスを共有したり、有識者を集める
- 過去に起きた障害の構成やエラーログを保存し検索できるようにしておくと良い
- 復旧対応で大事なこと
- インフラ障害の復旧確認は、システム全体に対して行う
- イベントの確認・事後対応で大事なこと
- 通知されるイベントをできるだけ減らす
- 自動復旧を推進する
ToDo
今回は以上です 最後までお読み頂き有難うございました。
