2.4サービスマネジメント

システムは「作って終わり」ではなく、日々安定して動かし続けることが求められます。障害が起きたときにどう対応し、どう二度と起こさないようにするか、利用者との約束をどう管理するか——これらを扱うのがサービスマネジメントです。

2.4.1ITILとSLA・SLM

• ITIL＝ITサービスマネジメントのベストプラクティス（成功事例）をまとめたガイドライン。世界的に広く参照され、サービスデスクやインシデント管理など各プロセスの考え方の土台になっています。
• SLA（サービスレベル合意書）＝提供するサービスの品質（稼働率・応答時間など）について、提供者と利用者があらかじめ合意し文書化したもの。SLM（サービスレベル管理）＝SLAで定めた水準を実際に維持・改善できているかを継続的に管理する活動です。

2.4.2インシデント・問題・変更管理とサービスデスク

• インシデント管理＝サービスの中断や障害が発生した際、まず正常なサービスを早く復旧させることを目的とする活動（原因の根本解明は目的としない）。問題管理＝インシデントの根本原因を調査し、再発を防止することを目的とする活動。
• 変更管理＝システムへの変更（設定変更・機能追加等）を、影響範囲を事前に評価し、承認を得たうえで計画的に実施する活動。無秩序な変更が新たな障害を招くのを防ぎます。
• サービスデスク＝利用者からの問い合わせ・障害報告を受け付ける単一の窓口。利用者はここに連絡すればよく、内部でどの担当チームに割り振るかはサービスデスク側が調整します。

2.4.3ファシリティマネジメント

• ファシリティマネジメント＝サーバー室・電源・空調など、ITサービスを支える設備面を維持管理する活動。UPS（無停電電源装置）＝停電時に一定時間電源を供給し続け、安全にシステムを停止させる（または非常用電源に切り替える）ための装置。
• 冗長化＝サーバーやネットワーク機器などを予備を含めて複数用意しておき、一部が故障しても全体としてサービスを継続できるようにする設計の考え方です。

社内で使う基幹システムにログインできないという障害が起きた場面を追ってみましょう。利用者はまずサービスデスクへ連絡します。サービスデスクは症状を聞き取り、担当チームへつなぎます。ここでの最優先事項は原因の完全解明ではなく、とにかく早くサービスを元通りに使えるようにすることなので、暫定的な対処として認証サーバーを再起動する、といった応急処置がまずインシデント管理の一環として実施されます。無事にログインできるようになれば、このインシデント自体は解決とみなされます。しかし、同じ障害が翌週も再発したとなると、根本原因を突き止める必要が出てきます。ここで動くのが問題管理で、ログを詳しく調べた結果「特定の条件で認証サーバーのメモリが枯渇する」という根本原因が判明したとします。この根本原因に対処するには、認証サーバーの設定変更やソフトウェアの更新が必要になりますが、これをいきなり本番環境に適用すると新たな不具合を招くおそれがあるため、変更内容の影響範囲を事前に評価し、承認を得たうえで計画的に適用する変更管理のプロセスを経ます。こうした一連の運用の質を継続的に測るために、あらかじめ利用者側とSLA（例：「営業時間中の稼働率99.9%以上」）を合意しておき、実際の稼働実績がこの水準を満たしているかを継続的に確認・改善するSLMが行われます。さらに、そもそも停電で認証サーバーが落ちてしまわないよう、UPSで一時的に電源を確保しつつ安全に停止させる、あるいはサーバー自体を冗長化しておき1台が故障してももう1台が処理を引き継げるようにしておく、といったファシリティマネジメントの備えが、こうした障害の発生頻度そのものを下げる土台になります。

2.4.4この節のまとめ

• ITILはITサービスマネジメントのベストプラクティス集。SLAは品質の合意文書・SLMはその水準を継続管理する活動
• インシデント管理＝早期復旧が目的・問題管理＝根本原因と再発防止が目的・変更管理＝事前の影響評価と承認
• サービスデスクは利用者の単一窓口。ファシリティマネジメント（UPS・冗長化）が障害の発生自体を減らす土台