問題管理とは、インシデントの根本原因を特定し、それを排除または軽減するためのプロセスです。
問題管理により、重大なインシデントの発生を予防することができます。
問題管理の目的
問題管理の目的は、インシデントや障害の根本原因を特定し、再発防止策や未然防止策を提案することです。
- インシデントの根本原因を技術的に分析し特定
- 恒久的な解決策の提供（根本解決）
一時的な回避策（ワークアラウンド）ではなく、再発しないように根本的な対応を行います。 - インシデントの再発防止
同様の障害が再び発生しないように、システムや運用の改善を行います。
問題管理の活動内容
問題管理はインシデント発生後に実施するリアクティブの対応と、インシデントが発生する前に実施するプロアクティブの対応があります。
リアクティブな問題管理
リアクティブな問題管理は、既に発生したインシデントの根本原因を調査し、教訓を得て再発防止策を提案して対応します。
■活動の流れ
インシデント（障害）が発生した後にその根本原因を特定するプロセスを問題コントロールと言い、フローだと①～③が該当します。
問題の修正、予防、変更管理との連携はエラーコントロールと言います。
①問題の識別
インシデント管理から対象のインシデントを確認します。
②分類
分類の項目に決まりはないですが、問題の種類や重要度、影響範囲に基づいて分類を行い、優先度を決定します。
分類のフェーズで設定できない項目は次の原因調査で埋めても良いです。
③原因調査
問題の根本的な原因を特定します。
具体的な活動内容は次の通りです。
- ログを確認
- 監視ツールの確認(障害発生時のCPU、メモリ、ストレージ領域の使用率や、サービスの稼働状況など)
- プログラムのソースコードを確認
- パッケージソフトの場合はサポートへ問合せ
インシデント管理で得られた情報を基に問題管理の調査が行われることが多いですが、根本原因を特定するためには追加の調査が必要な場合もあります。
システム的な原因を確認できたら、なぜそれが起きたのかを分析します。
この分析手法としては、なぜなぜ分析や、フィッシュボーンダイアグラム（特性要因図）がよく使用されます
■なぜなぜ分析の例
問題：WEBアプリケーションは使用できなかった
１ なぜ → アプリケーションがデータベースに接続できなくなり、データの読み書きができなかった
２ なぜ → データベースのデータ領域の空きが無くなり、WEBアプリが動かなくなった
３(1)なぜ → 容量監視ができていなかった
４(1)なぜ → 監視体制が不十分
５(1)なぜ → 運用手順が不明確で、監視ツールのアラート設定がされていなかった。
３(2)予想以上にデータ領域が増加
４(2)なぜ → 先週にリリースした自動登録バッチ機能によりデータが増加していた
５(2)なぜ → 自動登録バッチ機能追加に伴うデータ増加を考慮できていなかった
④エラー評価(恒久対策立案)
エラー評価(恒久対策立案)では、問題を根本的に解決するための恒久対策（長期的な対策）を考えます。
例えば次のような例があります。
- ソフトウェアの修正やパッチ適用
- インフラのアップグレードや交換
- プロセスの改善（手順の再設計、トレーニングの実施）
- 監視体制の強化
先ほどのWEBアプリケーションの問題の例の場合は次のような対策が考えられます。
・データベース容量の定期的な監視とアラート設定。
・自動的なデータ圧縮やアーカイブ機能の導入。
・運用ポリシーの整備と、容量管理担当者の明確化。
提案された恒久対策がどの程度効果的で、どのようなリスクがあるかを評価します。
新しい対策が他の問題を引き起こさないか、実施後の影響を予測することが重要です。
⑤解決策（恒久対策）の実施
解決策（恒久対策）の実施 は、問題の根本原因を解決するために立案した恒久的な対策を実際に実行します。
先ほど説明した「④エラー評価(恒久対策立案)」を実施します。
恒久対策がソフトウェアの修正や、ハードウェアの交換、運用プロセスの変更を含む場合、それらの実施は変更管理プロセスに従って行われます。
問題管理は、これらの対策が実行されることを確認する役割を担います。
ただし、次のような例は変更管理の対象外です。
■変更管理対象外
- オペレーター改善に向けたトレーニングの実施
- 管轄外（構成管理対象外）の運用マニュアル修正
⑥解決策（恒久対策）の進捗監視
対策が計画通り進んでいるか、スケジュール通りに作業が実施されているかを報告します。
問題が複数存在する場合は、問題管理の記録データベース(またはExcel)や、課題管理表を使って定期的印報告をします。
ソフトウエアの修正などの変更管理で実施する活動は、変更管理で進捗を管理しますが、問題管理側でも進捗を管理する場合は問題管理で上がっている問題のリストを作成して報告すると良いです。
報告書のサンプル
問題管理で対応する問題は、顧客へ報告が必要ですが、報告書に記載すべき内容のサンプルを記載します。
（企業によってはテンプレートが決まっていると思いますので、その場合はテンプレートを使ってください。）
（■、□の箇所は選択肢を表しており、■が本サンプルの該当項目です。）
| 問題発生日 | ｘｘｘｘ年ｘｘ月ｘｘ日 |
| 影響度 | ■高 □中 □低 |
| 緊急度 | 高：最優先で対応 |
| 内容 | WEBシステムにアクセスするとエラーメッセージが表示されて利用できない。 ○○業務、□□業務を行う全ユーザが業務できない状態となった。 確認したところ、データベース領域の使用率が100%となっていた。 |
| 発生フェーズ | □リリース前 ■リリース後(瑕疵担保期間内) □リリース後(瑕疵担保期間外) |
| 暫定復旧内容 | データベース領域に過去のリリース作業前に出力したデータベースバックアップ(ダンプファイル)が残っていたので、開発担当者に確認して削除した。 |
| 関連システムへの影響 | 本システムと連携しているXXシステムへのデータ送信が停止した。 |
| 障害発生原因の工程箇所 | □要件定義 ■プログラム設計(基本設計や詳細設計) □プログラミング □リリース作業 ■運用設計 |
| インシデント発生～回復 (ワークアラウンド)に至るまでの経緯 | 8:00 x様からシステムへログインできないとの問合せがあった 8:00 運用保守担当のy氏からシステム全利用者と関連システム担当者へ障害が発生している旨をアナウンスした。 8:15 運用保守担当のy氏がアプリケーションサーバを再起動したが解消しなかった。 8:30 監視ツールでシステムの状況を確認したところ、データベース領域の使用率が100%となっていた。 9:00 データベース領域に過去のリリース作業前に出力したデータベースバックアップ(ダンプファイル)が残っていたので、開発担当者に確認して削除した。 9:15 システムの動作確認をして、システム全利用者へ障害が回復した旨をアナウンスした。 |
| 問題発生の経緯 | データベースへ登録するデータおよびログ領域の使用量が増えた。 |
| 原因 | １ なぜ → アプリケーションがデータベースに接続できなくなり、データの読み書きができなかった ２ なぜ → データベースのデータ領域の空きが無くなり、WEBアプリが動かなくなった ３(1)なぜ → 容量監視ができていなかった ４(1)なぜ → 監視体制が不十分 ５(1)なぜ → 運用手順が不明確で、監視ツールのアラート設定がされていなかった。 ３(2)予想以上にデータ領域が増加 ４(2)なぜ → 先週にリリースした自動登録バッチ機能によりデータが増加していた ５(2)なぜ → 自動登録バッチ機能追加に伴うデータ増加を考慮できていなかった |
| 恒久対応 | ・データベース容量の定期的な監視とアラート設定。 ・自動的なデータ圧縮やアーカイブ機能の導入。 ・運用ポリシーの整備と、容量管理担当者の明確化。 |
まとめ
- 問題管理はインシデントの根本原因を特定し、再発防止策を講じるプロセス。
- インシデントの再発を防ぐために、システムや運用の改善を行う。
- 問題管理にはリアクティブ（事後対応）とプロアクティブ（事前対応）の2つのアプローチがある。
- リアクティブな問題管理では、インシデント後に根本原因を特定し、再発防止策を提案する。
- 問題識別、分類、原因調査、エラー評価（恒久対策立案）が主なステップ。
- 「なぜなぜ分析」や「フィッシュボーンダイアグラム」を使い、根本原因を特定する。
- 恒久対策の例として、ソフトウェア修正、インフラのアップグレード、監視体制の強化がある。
- 解決策（恒久対策）の実施は、変更管理プロセスに基づいて行われる。
- 進捗監視を通じて、恒久対策が計画通りに実施されているかを確認する。
- 問題管理報告書では、インシデントの詳細、原因、対応策、恒久対策が含まれる。
コメント