変更要約: 初版（第5章・s1-s5）
5.4サービスマネジメント
ITILの枠組みに基づくSLA（サービスレベル合意書）・SLM（サービスレベル管理）、インシデント管理・問題管理・変更管理・構成管理の各プロセス、サービスデスクの役割、キャパシティ管理・可用性管理、そしてデータセンターのファシリティ（UPS・免震構造）を学びます。
システムを作って終わりではなく、安定的に運用し続けるための体系がサービスマネジメントです。ITILが示すベストプラクティスをもとに、約束したサービス水準をどう管理するか（SLA/SLM）、障害への対応プロセスをどう区別するか（インシデント/問題/変更管理）を理解することが、実務でも試験でも問われる核心です。
5.4.1ITILとSLA/SLM
- ITIL（Information Technology Infrastructure Library）＝ITサービスマネジメントのベストプラクティス集。特定の製品や組織に依存しない、業界標準として広く参照される枠組みです。
- SLA（Service Level Agreement・サービスレベル合意書）＝サービス提供者と利用者の間で、提供するサービスの水準（稼働率・応答時間など）を数値目標として合意した文書。SLM（Service Level Management・サービスレベル管理）＝SLAで合意した水準を継続的に監視・報告し、達成に向けて管理する活動全体。SLAが「約束の中身」、SLMが「約束を守るための管理プロセス」という関係です。
5.4.2インシデント管理・問題管理・変更管理・構成管理
- インシデント管理＝サービスの中断や品質低下が発生した際、サービスを可能な限り迅速に復旧させることを目的とするプロセス（応急対応・暫定回避策が中心。根本原因の追究は目的としない）。問題管理＝インシデントの背後にある根本原因を特定し、恒久的な対策を講じて再発を防止するプロセス。
- 変更管理＝システムへの変更（設定変更・パッチ適用・機能追加等）を計画的に評価・承認し、統制されたプロセスで実施することで、変更に起因する新たな障害を防ぐプロセス。構成管理（サービスマネジメント文脈）＝IT資産・機器・ソフトウェアなどの構成情報（CI: Configuration Item）を正確に把握・記録し、変更管理やインシデント対応の判断材料にするプロセス。
- インシデント管理と問題管理の違いが最重要の区別です。「今すぐサービスを止めない・復旧させる」のがインシデント管理、「二度と同じ障害を起こさない」のが問題管理で、目的の時間軸（応急 vs 恒久）が異なります。
「インシデント管理＝迅速な復旧が目的・根本原因は追究しない」「問題管理＝根本原因の特定と恒久対策で再発防止」「変更管理＝変更を計画的に評価・承認し統制する」「SLA＝合意した水準の文書・SLM＝その水準を継続管理する活動」が最頻出です。インシデント管理と問題管理の目的の取り違え（「インシデント管理で根本原因まで解決する」等）が典型的な誤答です。
5.4.3サービスデスク・キャパシティ/可用性管理・ファシリティ
- サービスデスク＝利用者からの問い合わせ・障害報告を受け付ける単一の窓口（シングルポイントオブコンタクト）。一次対応で解決できないものは、適切な専門チームへエスカレーションします。キャパシティ管理＝将来の需要を見越して処理能力・リソースが不足しないよう計画するプロセス。可用性管理＝サービスが必要な時に利用可能な状態を維持できるよう、冗長構成や障害対応体制を計画するプロセス。
- ファシリティ管理＝データセンター等の物理的な設備を管理する領域。UPS（無停電電源装置）＝停電時に一定時間、電力を供給し続ける装置（長時間の発電継続ではなく、非常用発電機への切替や安全なシャットダウンまでの橋渡しが主な役割）。免震構造＝地震の揺れが建物に直接伝わらないよう建物と地盤の間で揺れを吸収する構造（耐震構造は建物自体を頑丈にして耐える方式で、揺れの伝わり方が異なる点に注意）。
あるECサイトで注文処理が突然遅くなった、という障害を例に、各プロセスの役割分担を追ってみます。利用者からの問い合わせは、まずサービスデスクという単一窓口で受け付けられます。サービスデスクは症状を一次切り分けした上で、担当チームへエスカレーションします。担当チームはここでインシデント管理のプロセスに入り、「なぜ遅いのか」を深く追究するよりも先に、まずサービスを正常な状態に戻すことを最優先します。たとえば負荷の高いバッチ処理を一時停止する、キャッシュを再起動するといった暫定的な回避策で応答時間を正常に戻し、インシデントをクローズします。しかし同じ現象が繰り返し発生するようであれば、問題管理のプロセスに移行し、「特定のクエリがインデックスを使わずフルスキャンしている」といった根本原因を時間をかけて調査し、恒久対策（インデックス追加やクエリの見直し）を計画します。この恒久対策を本番環境へ適用する際には、変更管理のプロセスに従い、影響範囲や実施タイミングを事前に評価・承認してから、統制された手順で変更を実施します。この変更が意図せぬ副作用を起こさないよう、変更管理の判断材料として構成管理で記録されたシステム構成情報（どのサーバーがどのミドルウェアに依存しているか等）が参照されます。並行して、今回の障害がアクセス急増によるものだったのであれば、キャパシティ管理の観点から将来の需要増を見越したリソース増強を計画し、可用性管理の観点からは冗長構成の強化を検討します。さらに、これらすべての前提として、データセンターのサーバーが停電時にもUPSによる一定時間の電力供給で安全にシャットダウンでき、地震の際には免震構造によって直接的な揺れの影響を受けにくい、という物理的な基盤があってはじめて、サービスマネジメントの各プロセスが機能する土台になります。
| プロセス | 目的 | 時間軸 |
|---|---|---|
| インシデント管理 | サービスの迅速な復旧 | 応急（今すぐ） |
| 問題管理 | 根本原因の特定・恒久対策 | 恒久（再発防止） |
| 変更管理 | 変更の計画的な評価・承認・統制 | 変更実施前後 |
ひっかけ： 「インシデント管理では根本原因を特定してから対応する」は誤りです。インシデント管理の目的は迅速な復旧であり、根本原因の追究・恒久対策は問題管理の役割です。また「UPSは停電時に長時間にわたり主電源の代わりを果たす発電設備である」も誤り＝UPSは短時間の橋渡しが主な役割で、長時間の電力供給は非常用発電機の役割です。さらに「免震構造は建物自体を頑丈にして地震の揺れに耐える構造である」も誤り＝それは耐震構造の説明で、免震構造は建物と地盤の間で揺れを吸収し伝わりにくくする構造です。
5.4.4この節のまとめ
- SLA＝合意した水準の文書・SLM＝水準を継続監視・管理する活動。ITIL＝ITサービスマネジメントのベストプラクティス集
- インシデント管理＝迅速な復旧が目的（根本原因は追究しない）／問題管理＝根本原因特定と恒久対策で再発防止。変更管理＝変更を計画的に評価・承認・統制
- UPS＝停電時の短時間の橋渡し（長時間の代替は非常用発電機）。免震構造＝建物と地盤の間で揺れを吸収（耐震構造は建物自体で耐える）
進捗の記録にはログインが必要です。
理解度チェック
（軽い確認用）Q1. サーバーの応答が急に遅くなったという障害が発生した。まず優先すべきなのは、根本原因の特定ではなく、暫定的な回避策でサービスを正常な状態に戻すことである。この対応が属するプロセスは？
Q2. 同じ障害が繰り返し発生しているため、根本原因を時間をかけて調査し、恒久的な対策を計画することになった。この活動が属するプロセスは？
Q3. データセンターが停電した際、非常用発電機が稼働を開始するまでの短時間、サーバーへの電力供給を維持し安全なシャットダウンを可能にする設備はどれか？