1-1 トラブルシューティングのプロセス・何をトラブルとするのか

estis2016/05/18 (水) 12:31 に投稿

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

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

トラブルシューティングプロセス(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:計画
  評価に基づき解決策をどのように実施するかを計画する

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