体系学習
ITサービスを安定して届け、改善する仕組み
SLA、サービスデスク、インシデント管理、問題管理、変更管理などを『サービスを止めない・再発させない・安全に変える』流れで整理する。
対象資格:ITパスポート / 基本情報技術者試験
目安時間:30分
このページで理解できること
- サービスマネジメントの目的を価値・品質・継続的改善の観点から説明できる
- SLA・SLO・SLIを区別できる
- サービスデスクとサービス要求管理の役割を説明できる
- インシデント管理と問題管理の目的を区別できる
- 変更管理・構成管理・リリース及び展開管理の違いを説明できる
- FEでは可用性・継続性・容量能力と継続的改善までつなげて判断できる
ITパスポート:サービスマネジメント、ITIL、SLA/SLO/SLI、サービスデスク、インシデント・問題・変更などの基本的な役割を目的から見分けられる状態を目標にする。
基本情報技術者試験:ITパスポート範囲に加え、サービス要求、構成管理、リリース及び展開、可用性、継続性、容量・能力、継続的改善を関連付け、運用プロセス間の役割分担まで理解する。
ITサービスは、システムを作って公開した時点で完成ではありません。利用者が必要なときに使え、障害時には早く復旧し、同じ問題を繰り返さず、安全に変更し続ける必要があります。このページでは、サービスマネジメントを『合意する→受け付ける→復旧する→原因をなくす→変更する→改善する』という流れで整理します。
まずはサービス運用の流れ
障害対応だけでなく、合意・変更・改善までを一つの循環として見ます。
サービス水準を合意する
SLAなどで、どのようなサービスと性能を提供するかを顧客と合意します。
問い合わせを受け付ける
サービスデスクが単一窓口となり、問い合わせやサービス要求、インシデントを記録・分類します。
サービスを早く復旧する
インシデント管理では影響を抑え、正常なサービスをできるだけ早く回復させます。
根本原因を調べる
問題管理ではインシデントの傾向や原因を分析し、再発防止へつなげます。
変更を管理して展開する
変更のリスクと影響を評価し、承認・試験した上でリリースや展開を行います。
測定し、継続的に改善する
サービスの実績を目標と比較し、改善活動を回し続けます。
1. サービスマネジメントは「価値を安定して提供し続ける」ための管理
SLA・SLO・SLIは、約束・目標・測定値という関係で整理します。
サービスマネジメントは、サービスの計画、設計、移行、提供、改善に必要な活動や資源を管理し、利用者や顧客へ価値を提供し続けるための考え方です。
ITILは、サービスマネジメントで広く利用されるフレームワークです。ITILそのものが個別のSLAや運用手順ではなく、サービスを管理・改善するための体系的な考え方を提供します。
SLAは、サービスと合意されたパフォーマンスを特定する、サービス提供側の組織と顧客との合意です。可用性、サービス時間、応答時間などが対象になり得ます。
SLOは達成を目指すサービスレベルの目標、SLIはサービスレベルを評価するために実際に測る指標と考えると整理しやすくなります。
| 用語 | 役割 | 例 |
|---|---|---|
| SLA | 顧客とのサービス水準に関する合意 | 月間可用性などの合意条件 |
| SLO | 達成を目指すサービスレベル目標 | 月間可用性99.9%以上 |
| SLI | サービスレベルを観測・評価する指標 | 実測した月間可用性 |
2. サービスデスクは利用者との単一窓口になる
問い合わせを受ける場所と、問題を根本解決する活動は同じではありません。
サービスデスクは、利用者からの問い合わせに対する単一の窓口、SPOC(Single Point of Contact)として機能します。
問い合わせを記録・分類し、優先度を付け、必要に応じて担当へエスカレーションします。FAQやチャットボットなどを活用して自己解決を支援することもあります。
パスワード再設定や利用申請のように、標準化された依頼を処理する活動はサービス要求管理として整理されます。一方、計画外の中断や品質低下はインシデントとして扱います。
3. インシデント管理は早期復旧、問題管理は根本原因と再発防止
同じ障害を扱っていても、目標が異なります。
インシデントは、サービスの計画外の中断や品質低下など、正常なサービス提供へ影響する事象です。インシデント管理では、利用者への影響を抑え、通常のサービスをできるだけ早く回復させることを重視します。
応急的な回避策でサービスを復旧できても、原因が未解決なら同じ障害が再発する可能性があります。そこで問題管理では、インシデントのデータや傾向を分析し、根本原因を特定して再発防止策を検討します。
問題の根本原因が判明しているが恒久対策がまだ完了していない状態は、既知の誤りとして管理されることがあります。
| 管理 | 主な目的 | 代表的な視点 |
|---|---|---|
| インシデント管理 | サービスを早く正常状態へ戻す | 影響・優先度・解決目標時間・エスカレーション・回避策 |
| 問題管理 | 根本原因を特定し再発を防ぐ | 傾向分析・根本原因・予防処置・既知の誤り |
4. 変更管理・構成管理・リリース管理を混同しない
「変えてよいか」「何がどう構成されているか」「どう本番へ出すか」は別の役割です。
変更管理は、サービスや構成要素への変更要求を記録し、優先度、リスク、事業上の利益、実現可能性、財務影響などを考慮して承認・計画・試験する活動です。
構成管理は、サービスを構成するハードウェア、ソフトウェア、文書などの構成品目と、その属性や関係、状態を把握できるようにします。変更の影響範囲を判断する土台にもなります。
リリース及び展開管理は、承認された新規サービスや変更を稼働環境へ計画的に展開する活動です。変更を承認することと、本番環境へ展開することは同じではありません。
| 管理 | 中心となる問い |
|---|---|
| 変更管理 | この変更を承認し、どのように安全に実施するか |
| 構成管理 | サービスは何で構成され、それらはどう関連しているか |
| リリース及び展開管理 | 承認された変更をいつ・どう稼働環境へ出すか |
ITパスポートではここまでを確実に
- サービスマネジメントとITILの関係を説明できる
- SLA・SLO・SLIを区別できる
- サービスデスクがSPOCとして機能することを理解している
- サービス要求とインシデントを区別できる
- インシデント管理と問題管理の目的を区別できる
- 変更管理・構成管理・リリース及び展開管理の役割を区別できる
FE深掘り
5. FEでは可用性・継続性・容量能力を分けて管理する
『止まりにくさ』『災害後にどこまで戻すか』『性能不足を起こさないか』は別の管理対象です。
可用性管理では、サービスが必要な時間に利用できる状態を目標と照らして監視・改善します。信頼性や保守性と関連し、MTBFが長いほど故障間隔が長く、MTTRが短いほど平均修復時間が短い方向です。
サービス継続管理では、大規模障害や災害などを想定し、サービス継続計画を作成・維持・試験します。RTOは復旧までに許容する目標時間、RPOはどの時点までのデータ復旧を目標とするかを表します。
容量・能力管理では、現在と将来の需要を踏まえ、CPU、メモリ、ディスク、ネットワークなどの資源が必要な性能を満たすよう監視・計画します。単に障害が起きた後で増強するのではなく、需要予測も重要です。
| 管理 | 主な問い |
|---|---|
| サービス可用性管理 | 必要なときに利用できる状態をどのように維持するか |
| サービス継続管理 | 重大障害時に、いつまでに・どの時点まで復旧するか |
| 容量・能力管理 | 現在・将来の需要に対して資源や性能が足りるか |
FE深掘り
6. FEでは測定・報告・是正・継続的改善までつなげる
サービスは一度設計した水準を守るだけでなく、実績から改善します。
サービスのパフォーマンスは、要求事項やサービスレベル目標と比較して監視・測定・分析・評価します。結果はサービス報告として関係者へ共有します。
目標未達や不適合があれば、単にその場で修正するだけでなく、再発防止につながる是正処置が必要かを判断します。
継続的改善では、サービスとサービスマネジメントシステムの適切性・有効性を継続的に高めます。PDCAのように、計画・実行・評価・改善を繰り返す考え方と結び付けると理解しやすくなります。
基本情報ではここまでつなげる
- サービス要求・インシデント・問題を目的から区別できる
- 変更管理・構成管理・リリース及び展開管理を区別できる
- MTBFとMTTRが可用性へ与える方向を説明できる
- RTOとRPOを区別できる
- 容量・能力管理が需要予測と資源監視を扱う理由を説明できる
- 測定・報告・是正処置・継続的改善の流れを説明できる
最後に一つの運用サイクルへ戻す
- SLAなどでサービス水準を合意する
- サービスデスクで問い合わせを受け付ける
- インシデント管理で早期復旧する
- 問題管理で根本原因と再発防止を扱う
- 構成を把握し、変更を評価して安全に展開する
- 可用性・継続性・容量能力を管理する
- 実績を測定し、継続的に改善する
サービスマネジメントは用語数が多い分野ですが、『早く戻す』『原因をなくす』『安全に変える』のように各管理活動の目的を一言で対応付けると、似た選択肢を見分けやすくなります。