サービスマネジメントシステムの計画及び運用
サービスカタログ・構成管理・変更管理・リリース展開、インシデント管理と問題管理の違い、可用性や容量・能力の管理という運用の中核を理解できるようになります。
ねらい
サービスマネジメントシステムの運用の全体像を学びます。このレッスンを終えると、サービスの計画から提供までの管理プロセス群、変更管理とリリースの流れ、インシデント管理と問題管理の役割分担を説明できるようになります。
ストーリー
朝9時、ヘルプデスクに「販売システムにつながらない」という電話。まず一刻も早く使える状態に戻す。落ち着いたら、なぜ起きたのかを掘り下げて再発を防ぐ。この「早く戻す」と「根本から断つ」の分業が、運用管理の心臓部です。
サービスの計画と土台の管理
サービスマネジメントシステムの計画はPDCAで回し(JIS Q 9001と同じ発想)、資源、力量、認識、コミュニケーション、文書化した情報、知識という支援の要素を整えます。サービスは、変更要求や新規サービスの提案をサービスポートフォリオ(計画中・開発中・稼働中・廃止などのサービスの状態を含む)で管理し、顧客向けにはサービスの内容と依存関係を説明するサービスカタログを維持します。
土台となる管理も欠かせません。サービスに使う資産を管理する資産管理(ITアセットマネジメント、ソフトウェアアセットマネジメント、ライセンスマネジメント)、構成品目(CI)と版を識別・記録・検証する構成管理、顧客満足や苦情に向き合う事業関係管理、SLAの達成を監視するサービスレベル管理、外部供給者やクラウドサービスの利用を監視する供給者管理、TCOを踏まえた予算業務及び会計業務です。
需要・容量とサービスの変更
サービスへの需要を予測する需要管理と、それに基づいてCPU使用率・メモリ使用率などの管理指標をしきい値で監視しながら資源を計画する容量・能力管理が、パフォーマンスの土台を支えます。
サービスを変えるときの流れは次のとおりです。
- 変更管理で、変更要求(RFC)を記録・分類し、優先度を決め、リスクや事業利益を考慮して承認します。変更には標準変更、通常の変更、緊急変更などのカテゴリーがあり、承認は変更諮問委員会(CAB)が行います。失敗に備えたロールバック(切り戻し)の計画と、変更実施後のレビュー(PIR)も変更管理の活動です。
- 大きな変更は、サービスの設計及び移行として計画・設計(サービス受入れ基準・非機能要件の定義)・構築を行い、移行リハーサルや運用テストを経て運用引継ぎまで進めます。
- リリース及び展開管理で、試験済みの変更を稼働環境へ展開します。緊急リリースを含むリリースの種類と受入れ基準を定めておきます。
インシデント管理と問題管理:早く戻す、根本から断つ
インシデントとは、サービスに対する計画外の中断やサービスの品質の低下のことです。
- インシデント管理の目的は、サービスをできるだけ早く回復することです。影響と優先順位を決め、解決目標時間の中で対応します。完全な修理を待たずに回避策で回復させることもあります。手に負えないときは、より専門的な担当へ引き継ぐ機能的エスカレーションや、管理者層へ引き継ぐ階層的エスカレーションを行い、重大なインシデントはトップマネジメントに通知します。
- 問題管理の目的は、インシデントの根本原因を突き止めて再発を防止することです。インシデントのデータと傾向を分析して問題を特定し、根本原因の分析と予防処置を行います。原因は分かったがまだ解決していないものは既知の誤りとして記録し、回避策とともに共有します。
「早く戻す」インシデント管理と「根本から断つ」問題管理は、同じインシデントの発生を起点にしながら、目的が分かれる2つの活動です。
利用者からの「パスワードを初期化してほしい」のような定型の依頼は、インシデントとは区別してサービス要求管理で扱います。
可用性と継続の管理
サービス可用性管理では、サービス可用性を監視して目標と比較し、計画外の喪失を調査して処置をとります。評価には、信頼性、回復力、保守性の観点と、MTBFやMTTRという指標を使います。
災害などの重大な事態に備えるのがサービス継続管理です。事業継続計画(BCP)と整合するサービス継続計画を作成・維持し、定めた間隔で試験します。復旧の目標は3つの指標で定めます。いつまでに復旧させるかのRTO(目標復旧時間)、どの時点のデータまで戻すかのRPO(目標復旧時点)、どの水準まで戻すかのRLO(目標復旧レベル)です。RPOは障害発生より前のどの時点のデータまで戻すかを、RTOは障害発生からいつまでに復旧させるかを表し、同じ障害発生の時点を挟んで時間軸の前後を指します。
待機系の備え方には、すぐ切り替えられるホットスタンバイ、準備に多少の時間を要するウォームスタンバイ、機材の手配から始めるコールドスタンバイがあります。情報セキュリティ管理(ISO/IEC 27000シリーズに基づく方針・管理策・インシデント対応)も、サービスマネジメントシステムの一部として実施します。
例題
次の問いに答えてください。
問1 インシデント管理と問題管理の目的の違いを説明してください。
問2 変更要求を評価し、承認の判断を行う組織を何といいますか。
解答と解説
問1について、インシデント管理の目的はサービスをできるだけ早く回復することで、回避策の適用も認められます。問題管理の目的は根本原因を突き止めて再発を防止することです。「早く戻す」と「根本から断つ」の分業です。
問2の答えは変更諮問委員会(CAB)です。リスクや事業利益を考慮して変更要求の承認を判断します。
応用
本試験を意識した問題を解いてみましょう。
問 インシデントのデータや傾向を分析して根本原因を特定し、インシデントの発生や再発を防止する処置を決定する活動はどれでしょうか。次の中から選んでください。
- 問題管理
- インシデント管理
- 変更管理
- リリース及び展開管理
解答と解説
答えは1の問題管理です。根本原因の分析と予防処置によって、再発を防ぐことが目的です。2のインシデント管理は、根本原因の解明よりもサービスの早期回復を優先する活動であり、回避策による復旧も認められます。3の変更管理は、変更要求を記録・評価・承認する活動で、原因分析そのものではありません。4のリリース及び展開管理は、試験済みの変更を稼働環境へ展開する活動であり、再発防止の分析を行う活動ではありません。
分からなかった点・気になった点
読み込み中です。