UITシステムを「作る」だけでなく「安定して動かし続ける」ことの大変さは、実際に使う側になると痛感します。ITILはその「運用」の知恵をまとめたフレームワークで、特にインシデント管理・問題管理・変更管理の3つが試験でよく問われます。サービスデスクとSLAの考え方と合わせて整理してみました。
この記事でわかること
- ITIL（ITサービスマネジメントのベストプラクティス集）の概要
- インシデント管理・問題管理・変更管理の違いと目的
- サービスデスク（ヘルプデスク）の機能と種類
- SLA（サービスレベル合意書）の内容と指標
- ITサービスの継続性管理（ITSCM）の考え方
目次
ITILとは——IT運用の「業界共通ルール集」
ITIL（IT Infrastructure Library）
ITILとは、ITサービスマネジメント（ITSM）のベストプラクティスをまとめた英国政府発のフレームワーク。「システムを安定して運用し続けるための共通の知恵」。なぜ重要か：システムは作ったら終わりではなく、障害対応・変更管理・ユーザーサポートなど「運用フェーズ」が事業の継続性を左右する。ITILはその運用を体系化し、担当者が変わっても品質を維持するための枠組み。
主要プロセスの整理
| プロセス | 目的 | 具体的な活動 |
|---|---|---|
| インシデント管理 | 障害・不具合をできるだけ早くサービス正常状態に戻す | 障害の受付→分類→エスカレーション→復旧→クローズ |
| 問題管理 | インシデントの根本原因を特定・排除して再発を防ぐ | 既知エラーDBの管理・根本原因分析（RCA）・恒久対策の実施 |
| 変更管理 | システム変更をリスクを最小化して安全に実施する | 変更要求（RFC）の審査→CABによる承認→変更実施→レビュー |
| リリース管理 | 新バージョン・パッチを計画的に本番環境へ展開する | リリース計画→テスト→段階的展開→ロールバック手順の準備 |
| 構成管理 | ITインフラの構成情報（CI）を正確に把握・管理する | CMDBの整備・資産情報の更新・依存関係の可視化 |
インシデント管理 vs 問題管理——混同しやすいポイント
具体例で区別する
- インシデント管理の例：「メールサーバーが落ちた→サービスを再起動して復旧させる」。スピードが最優先。根本原因の特定は二の次。
- 問題管理の例：「なぜメールサーバーが落ちたのか？メモリリークが原因と判明→パッチ適用で恒久対策」。再発防止が目的。
- 既知エラー（Known Error）：根本原因は特定されているが、まだ恒久対策が完了していない状態。回避策（ワークアラウンド）で対応中。
サービスデスクとSLA
| 概念 | 内容 |
|---|---|
| サービスデスク（ヘルプデスク） | ユーザーからの問い合わせ・障害報告の窓口。「シングルポイントオブコンタクト（SPOC）」としてあらゆる問い合わせを受け付ける |
| SLA（サービスレベル合意書） | ITサービスの提供者と利用者間で結ぶ合意書。可用性・応答時間・障害回復時間などの目標値を明文化する |
| SLM（サービスレベル管理） | SLAで定めた目標を継続的にモニタリングし、未達の場合に改善アクションを取るプロセス |
| OLA（運用レベル合意） | IT部門内部の各チーム間で結ぶ合意。SLAを達成するための内部目標 |
Uのメモ
学習メモ
- ITIL：IT運用のベストプラクティス集。英国政府発・業界標準フレームワーク
- インシデント管理（早期復旧が目的）≠ 問題管理（根本原因排除・再発防止が目的）
- 変更管理：CAB（変更諮問委員会）が変更要求（RFC）を審査・承認
- SLA：サービス提供者とユーザー間の合意書。可用性・RTO・RPO等の目標値を規定
- CMDB（構成管理データベース）：CIの情報と依存関係を管理するデータベース
