インシデント管理と問題管理

結論：インシデント管理は「早く戻す」、問題管理は「原因を断つ」

インシデント管理の目的は、止まったり遅くなったりしたサービスをできるだけ早く元に戻すことです。問題管理の目的は、インシデントの根本原因を突き止めて取り除き、発生や再発を防ぐことです。試験では、この2つの役割をすり替えた選択肢がほぼ必ず出てきます。

たとえば台所の水漏れなら、バケツを置いて床を拭き、台所を使える状態に戻すのがインシデント管理です。配管のどこが傷んでいるかを調べて交換し、二度と漏れないようにするのが問題管理です。

インシデントとは何か：対象の見分け方

インシデントとは、サービスに対する計画外の中断、サービスの品質の低下、またはまだ顧客や利用者へのサービスに影響していない事象のことです。最後のものの例には、二重化したサーバの片方が故障したものの、もう片方が動いていてサービスは止まっていない状態があります。

見分けるコツは「サービスそのものに起きた異常か」です。原因・対応の行為・利用者からのお願いは、インシデントそのものではありません。

サービス要求とは、情報・助言・サービスへのアクセス・事前に承認されている変更などを求めるもので、異常ではありません。

インシデント管理の進め方：最初は必ず「記録」

インシデント管理は 記録 → 分類 → 優先度付け → 段階的取扱い（必要なとき）→ 解決 → 終了 の順に進めます。最初に記録するのは、記録がないと分類も優先度付けもできず、後で問題管理が傾向を分析する材料も残らないからです。優先度は、影響度（どれだけ広く業務に響くか）と緊急度（どれだけ急ぐか）を考えて付けます。

報告を受けたら、既知の誤り（原因や回避策がすでに分かっている問題）に当てはまるかを照合します。当てはまれば、用意された回避策ですぐに復旧できます。この照合はインシデント管理の活動です。

flowchart TD
  A["インシデント発生"] --> B["記録"]
  B --> C["分類"]
  C --> D["優先度付け（影響度・緊急度）"]
  D --> E{"既知の誤りに該当？"}
  E -->|"はい"| F["回避策で復旧"]
  E -->|"いいえ"| G["段階的取扱いで専門チームへ"]
  G --> H["復旧"]
  H --> I["問題管理：根本原因を分析"]
  I --> J["既知の誤りとして記録"]

段階的取扱い（エスカレーション）とは、自分たちで解決できないインシデントを、より専門的なグループや上位の権限者に引き継ぐことです。窓口となって初期の情報を集め、利用者と連絡を取り続けるのが一次サポートです。専門的な技能と経験を持つのが二次サポートで、一次から二次へ解決を依頼するのがエスカレーションです。

問題と既知の誤り：記録はつながっている

問題とは、1つ以上のインシデント（まだ起きていない潜在的なものも含む）の根本原因です。そのうち根本原因が特定されている、または回避策が存在する問題を既知の誤りと呼びます。

問題の記録には、その発端となったインシデントの記録を相互参照できる情報を含めます。1つの問題が複数のインシデントの原因になることもあるので、記録は1対1とは限りません。既知の誤りが特定されても、インシデントの記録は削除しません。

問題管理の活動：事後対応と事前予防

問題管理の活動は、インシデントが起きてから動く事後対応的なものと、起きる前に手を打つ事前予防的なものに分かれます。事前予防的な活動の代表は、インシデントの発生傾向を分析して、将来のインシデントを予防する方策を提案することです。

選択肢には、別のプロセスの活動も紛れ込みます。キーワードで見分けましょう。

障害の現場での初動：利用者とオペレータ

画面にエラーメッセージが出てアプリケーションが止まったら、利用者はまずエラーメッセージをマニュアルで確認し、自分で対応できる障害か、情報システム部門に頼むべき障害かを判断します。いきなり再起動したり同じ操作を繰り返したりすると、データを壊したり、原因の手がかりを消したりするおそれがあります。

オペレータが障害の発生を確実に知るには、システムコンソールへ出るアラームなどのメッセージに連動して、信号表示灯を点灯させたり報知器を鳴らしたりする仕組みが有効です。モニタカメラは人が見ていなければ気づけません。メモリダンプは原因を調べるための情報で、バックアップは復旧のための備えなので、どちらも「気づく」ための手段ではありません。