『トラブル』満たされなかった利用者のシステムへの期待
　そのシステムへ、利用者がどのような期待をしていたか

原因特定のため、仮説を立て検証する
　利用者の報告内容と矛盾しないか、症状をすべて説明できるか を確認
　仮説は徐々に範囲を拡げていく

トラブルシューティングプロセス（p.12 図 1.1-2）
　問題認識
　　何をトラブルとするのか → そのシステムにおいて、利用者の期待は適切か
　仮説設定
　　システムのあるべき状態との差異に着目
　情報収集
　　あなたのトラブルは誰かのトラブルであった可能性を、忘れない
　検証整理
　　仮説に基づき収集した情報から原因を特定
　　問題を充分に説明できなければ、仮説設定に戻る
　意志決定
　　解決策実行の承認
　　副作用に注意
　　原状復帰手順を確保
　解決策実行
　　既存利用者への影響把握
　　アナウンス要不要確認
　結果評価
　　解決策実行後状況と期待状況の差異

必ずしも、完全修正が利用者の希望ではない
　特定期間の可用性確保
　新システム導入のための現システム修復困難設定

*修正プログラムの種類（p.14 COLUMN）

※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※
　システムのあるべき状態を明確にする
　結果評価を忘れない
　結果評価後ワークアラウンド(回避策)を明文化し、「既知のエラー」を増やす
※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※

トラブルを区別する
　ITILでは、
　　インシデント
　　　標準運用に属さない状態
　　問題
　　　「インシデント」を発生させる可能性のある未知の原因
　　既知のエラー
　　　「ワークアラウンド(回避策)」が明文化されたもの

『問題」を物理障害と論理障害に分ける
　　システム要件を満たしているか(メモリ・CPU・ハードディスク・ネットワークアダプタ など)
　　基本情報の確認(OS、ソフトウェアのバージョン、修正プログラム適用の有無）
　　オペレーションミスはないか
　　ネットワークトラブルはないか

*メーカー別BIOS/診断メニュー起動方法（p.17 表 1.2-1）
*ハードウェア診断に特化したLive CDタイプOS（p.17 *6, *7）

初期確認により、「物理障害」「論理障害」「オペレーションミス」について確認する

*初期確認作業フロー（p.18 図 1.2-1）

トラブルの記録方法　SOAP(Subjective Objective Assessment Plan)方式
　S：主観的情報
　　利用者の訴えを可能な限りそのままの言葉で記載する
　　動作が重い・見た目の変化・設定変更(されている・されない)・動作不具合・その他

　O：客観的情報
　　調査により収集したデータ・ログ・メモリダンプ・ネットワークパケット など
　　対処療法的操作とその結果も記録

　A：評価
　　主観的情報・客観的情報から分析
　　現象再現性の確認
　　時間的変化の記録

　P：計画
　　評価に基づき解決策をどのように実施するかを計画する

※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※
　主観的情報なのか、客観的情報なのかを明確に記載する
　客観的情報収集方法について記録する
※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※