あらすじ
【障害対応時の基本動作と現場マネジメントがわかる！】
本書は、ITシステム障害対応の現場で必要なさまざまな知識とノウハウ（基本動作、ツール、必要ドキュメントなど）を体系化し、個人・組織のシステム障害対応力を向上させることを目的とした解説書です。障害対応を指揮する「インシデントコマンダー」や、実際に作業にあたる作業担当者が知っておくべき知識を解説するとともに、高い障害対応力を備えた組織作りについても紹介します。改訂新版では、チームメンバーの教育と育成、障害対応訓練実施のポイント、事故を防ぐ手順書の作り方、エンドユーザ向け情報発信についての章を新設しました。また、生成AI技術のシステム運用への応用についても紹介しています。
■こんな方におすすめ
・ITサービスに関わるすべての人
・ITシステムの障害対応に携わる人
・システム障害時の対応について体系的な知識を知りたい人
■目次
●第1章 システム障害対応を学ぶ意義
1.1 なぜシステム障害対応は暗黙知だったのか
1.2 上昇し続けるシステム障害対応の難易度
1.3 システム障害対応時に起こり得るさまざまな問題
●第2章 システム障害の定義
2.1 システム障害とは何か
2.2 システム障害対応の目的と定義
●第3章 システム障害対応の登場人物と役割
3.1 システム障害対応の登場人物の概要と体制
3.2 インシデントコマンダーの役割と基本動作
3.3 作業担当
3.4 ユーザ担当
3.5 CIO
●第4章 各プロセスの基本動作～発生から終息まで
4.1 検知・事象の確認
4.2 業務影響調査
4.3 原因調査
4.4 復旧対応
4.5 イベントの確認／事後対応
●第5章 障害対応に必要なドキュメント
5.1 障害対応フロー図
5.2 オンコールシフト表と連絡先管理表
5.3 障害レベル管理表
5.4 障害状況ボード
5.5 作業タイムチャートシフト表
●第6章 システム障害対応力を高めるツールと環境
6.1 大規模システム障害のコントロール
6.2 システム監視ダッシュボード
6.3 War Roomダッシュボード
6.4 War Room
6.5 構成管理データベース（CMDB）
6.6 システム運用におけるAIの活用
●第7章 組織の障害対応レベル向上と体制作り
7.1 障害対応レベルの維持・向上
7.2 障害対応を担う組織や体制
●第8章 システム障害対応力の改善と教育
8.1 組織の障害対応力の継続的な改善
8.2 教育と訓練
●第9章 教育と育成の手引き
9.1 作業担当とインシデントコマンダーに必要な能力
9.2 障害対応チームの育成の流れ
9.3 障害対応力スキルチェックシート
●第10章 障害対応訓練の実施
10.1 訓練手法の種類と適切な選択
10.2 訓練の実施要領
●第11章 事故を防ぐ手順書の作り方
11.1 ヒューマンエラーとは
11.2 ヒューマンエラーを防ぐ手順書の作成
●第12章 エンドユーザ向けの情報発信
12.1 エンドユーザ向けの情報発信の目的と内容
12.2 エンドユーザ向けの情報発信の方法
●Appendix 難易度の高いシステム障害ケース
ケース1 ビジネスロジックアプリケーション障害と「誤データの波及」
ケース2 インフラ障害における機器の「半死」
ケース3 大規模インフラ障害と「伝言ゲーム」
ケース4 キャパシティ障害
ケース5 災害時のコントロール～3.11のふりかえり
■著者プロフィール
木村誠明：株式会社野村総合研究所 システムコンサルタント。金融系業務システムの開発・保守運用に携わり多くの障害対応を経験。その後、システム運用高度化のための技術開発・サービス開発を実施。現在はITサービスマネジメントの専門家として、社内外のシステム運用の改善に携わるとともに、障害対応力向上のための研修講師も手掛ける。NRI認定ITサービスマネージャー。
感情タグBEST3
Posted by ブクログ
【改訂新版】システム障害対応の教科書
著：木村 誠明
出版社：技術評論社
コンピュータの障害に関する書。めったに発生しないが、発生すれば、大規模の業務の停止を伴う事故になる。
・インフラとアプリケーションの境界がどんどん曖昧になっている
・障害を認知、確認をして、対応、復旧をする、システムの複雑度が上がるにつれ、障害復旧の難易度が上がっている
・単なるインフラの故障がきっかけで障害が発生し、リカバリー用のジョブの不具合でシステムが停止し、バックアップシステムに切り替わることなく、全体系が停止する
・重大インシデントに対して、複数のチームが同時並行の対応をしながら、雑音を含めてクリティカルなコミュニケーションを続けていく
・リモートでの対応、ＣＥの手配と現地へのオンサイト指示、パーツのセンターへの緊急郵送手配
起きてしまった障害を以下に速く業務復旧するかという、事後保全（リアクティブ）と、障害をおこなさないための予備保全（プロアクテイブ）について、人や組織の育成を含めた洞察を加えています。
障害対応については、プロセスに分けて解説しています
・イベントの確認
・検知・事象の確認
・事業影響の確認
・原因調査
・復旧対応
・恒久対策
・障害分析・再発防止策
ＩＴＩＬベースの管理
・イベント管理
・インシデント管理
・問題管理
どこからもたらされた情報か
・ユーザ
・監視系（アプリ、インフラ）
・オペレータコール 等
何を初動確認すべきか
・どの画面、帳票、処理か
・異常な状態とは 参照負荷、出力不正、遅延 処理できない
・いつ起きたか
・再現するのか
・エンドユーザにどう発信するか
障害に備える
・障害対応フロー
・障害対応手順書
・オンコールシフト表
・障害管理レベル 障害度 高・中・低 障害レベル 高・中・低
組織レイヤ 経営層、インシデント担当チーム、担当者
・階層別対応 Ｔｉｅｒ１：ヘルプデスク Ｔｉｅｒ２：保守チーム Ｔｉｅｒ３：業者、開発元
・監視（ビジネス監視、フロントエンド監視、ＡＰ監視、サーバ監視、ネットワーク監視、セキュリティ監視）
・構成管理データベース（ＣＭＤＢ）
・教育と訓練 ＢＣＰ訓練、シャドウイング（同行対応）、実機訓練
・チーム育成 スキル分類、教育計画
障害を振り返る ポストモーテム
・システム障害の内容 概要、現状、経過、発生原因、影響範囲、復旧対応、本格対策
・システム障害の分析 根本原因、内容検証
・教訓 うまくいったこと、うまくいかなかったこと、幸運だったこと
・改善策 再発防止策、課題解決策
難易度が高いシステム障害
・誤ったデータが他の処理に波及する データのすり抜け
・機器の半死半生
・大規模障害と伝言ゲームによる誤った初動、手順書の誤り等
・キャパシティ障害 性能劣化、非機能障害
・大規模自然災害
目次
はじめに
改訂版の執筆にあたって
第1章◆システム障害対応を学ぶ意義
1.1 なぜシステム障害対応は暗黙知だったのか
1.2 上昇し続けるシステム障害対応の難易度
1.3 システム障害対応時に起こり得るさまざまな問題
第2章◆システム障害の定義
2.1 システム障害とは何か
2.2 システム障害対応の目的と定義
第3章◆システム障害対応の登場人物と役割
3.1 システム障害対応の登場人物の概要と体制
3.2 インシデントコマンダーの役割と基本動作
3.3 作業担当
3.4 ユーザ担当
3.5 CIO
第4章◆各プロセスの基本動作～発生から終息まで
4.1 検知・事象の確認
4.2 業務影響調査
4.3 原因調査
4.4 復旧対応
4.5 イベントの確認／事後対応
第5章◆障害対応に必要なドキュメント
5.1 障害対応フロー図
5.2 オンコールシフト表と連絡先管理表
5.3 障害レベル管理表
5.4 障害状況ボード
5.5 作業タイムチャートシフト表
第6章◆システム障害対応力を高めるツールと環境
6.1 大規模システム障害のコントロール
6.2 システム監視ダッシュボード
6.3 War Roomダッシュボード
6.4 War Room
6.5 構成管理データベース（CMDB）
6.6 システム運用におけるAIの活用
第7章◆組織の障害対応レベル向上と体制作り
7.1 障害対応レベルの維持・向上
7.2 障害対応を担う組織や体制
第8章◆システム障害対応力の改善と教育
8.1 組織の障害対応力の継続的な改善
8.2 教育と訓練
第9章◆教育と育成の手引き
9.1 作業担当とインシデントコマンダーに必要な能力
9.2 障害対応チームの育成の流れ
9.3 障害対応力スキルチェックシート
第10章◆障害対応訓練の実施
10.1 訓練手法の種類と適切な選択
10.2 訓練の実施要領
第11章◆事故を防ぐ手順書の作り方
11.1 ヒューマンエラーとは
11.2 ヒューマンエラーを防ぐ手順書の作成
第12章◆エンドユーザ向けの情報発信
12.1 エンドユーザ向けの情報発信の目的と内容
12.2 エンドユーザ向けの情報発信の方法
Appendix◆難易度の高いシステム障害ケース
ケース1 ビジネスロジックアプリケーション障害と「誤データの波及」
ケース2 インフラ障害における機器の「半死」
ケース3 大規模インフラ障害と「伝言ゲーム」
ケース4 キャパシティ障害
ケース5 災害時のコントロール～3.11のふりかえり
参考文献
索引
ISBN：9784297140120
出版社：技術評論社
判型：A5
ページ数：336ページ
定価：2800円（本体）
2020年04月03日初版第１刷発行
2024年04月15日第２版第１刷発行
Posted by ブクログ
難しいことが書いてあるわけではなく，やるべきこと，考えるべきことなどが淡々と言語化されている．
ITの現場で暗黙知としてあるいは属人的なスキルとして確立していた障害対応を汎用的な内容で形式知とする取り組みはもっと評価されてもいいんじゃなかろうか．
システム障害対応の経験がないけど，その分野の知識が求められる自分のような人には良いだろう．
-----------------------------------
・仮想化
→エラーポイントが疎結合
→システム構成の複雑化
・原因調査
→仮説立案から．
→事象からあたりどころをつける．
（ネットワーク，物理サーバ）
・ビジネスロジックの障害とインフラの障害では打ち手，観点が異なる．
・指差呼称
・障害対応フロー図
→バイネームではなくロール名で表を作る
・障害はマイナスからのスタート．悪い報告も喜んでいけいれ心理的安全性を高めるべき
・”システム障害の定義”から始めるべし．それが障害対応のトリガーとなるから．
・ユーザ影響がなくても「障害」とみなす．
・障害のレベル感を影響度，緊急度のマトリクスで定義
・システムを治すことが障害対応ではない．業務を必要なレベルに復旧することが目的．クライアントが気にするのは根本原因ではなく，影響
・ユーザ＝システム利用者，顧客＝契約相手
・システム復旧よりもSorry画面の表示を優先する選択もあり得る
・障害状況ボード p64
・調査作業
→影響範囲確認，原因究明，復旧方法確認，
類似調査（同様の問題が他に発生していないか）
・復旧対応はシステムに変更が加わるという点で，調査とは異なる．
・CIO：何を守り，何を諦めるのかをきめる
