R5 SM PM2-1 サービスレベル管理におけるサービスレベルの合意について

設問ア：ITサービスの概要と討議の対象となったサービスレベル項目と討議を要することになった背景

　1.　概要
　Z社は、自社開発のネットワーク機器を販売している通信事業者である。Z社の開発した簡易サーバーである「A」(以下、Aという)は、ファイルサーバとして機能し、バックアップを内蔵ストレージの他、クラウドストレージにも分散してバックアップをする。
　Z社技術部ではAに関するサービスデスク対応やインシデント対応も実施している。Aのインシデント対応、例えばマルウェア感染時などにファイル復元が必要な場合、技術部にて実施する。
　Z社はAのサービスレベルを各顧客ごとではなく、営業部と結んでいる。技術部と営業部でのAに関わるSLAのサービスレベル項目の一つは、インシデント発生後24時間以内でサービスを復旧させることである。これは、顧客のインシデント対応の要求から、技術部による対応により24時間以内で顧客の操業を可能にする、ことを意味する。
　私は、Z社の技術部の課長であり、AのSLAを含むサービスを管理するITサービスマネジャである。
　2.　討議の対象となったサービスレベル項目
　昨今、情報セキュリティにおける脅威（以下、脅威という）の高度化により、現状のSLAを見直すこととなった。これは、脅威による攻撃を完全に防ぐことは困難であるという前提のもと、組織に求められる回復力を示すサイバーレジリエンスを取り入れる必要がある、という営業部の強い要望からであった。
　私はこの要望に対し、インシデント発生後の12時間で目標復旧レベル（RLO）を当日操業が可能なレベルにし、その後24時間以内にサービスを復旧させることとした。このサービスレベルは営業部と合意が取れ、SLAとして定義された。
692-1492

設問イ：サービスレベル合意に向けた取り組み及びサービスレベル管理の仕組み

1.サービスレベルの合意に向けた取り組み
　私は、Aにおけるサービスレベル目標の変更は、サービス提供に関わるZ社技術部の各関連部署の協議・調整が必要と考えた。
　Aにおける各関連部署は、以下の通りである。
　・Z社情報システム部：情報システム部はAの開発や機能改善を実施する部署である。Aに関わる高度なインシデント対応の機能的エスカレーション先としても機能する。また、メモリや記憶媒体といった部品も扱う。
　・Z社技術部管理課：技術部管理課は、サービスデスク対応やAに設定されたEメールを利用したエラー通知、例えばCPU使用率が長期的に100％を推移したイベントなどが発生した際に通知する（以下、エラー通知という）を管理している。
　・Z社技術部サポート課：技術部サポート課は、技術部管理課によるサポートデスク対応では復旧できなかったインシデント対応を、設置現場に訪問して対応を行う。
　以上の各関連部署が、Aのサービスレベル項目の変更に関わる。
2.サービスレベル管理の仕組み
　まず、私はインシデント対応の要求から、早期に詳細なインシデントの内容を把握する必要があると考えた。これについては、技術部管理課の受付において、エラー通知を確認することで申告症状の情報と併せて手順を追加するよう指示した。
　次に、技術部サポート課の対応において、従来のSLAでは問題解決に重点が置かれていたが、改定されたSLAでは、RLOも達成しないとならない。これは、問題解決と同時にフォールバック（縮退運転）も開始できるよう対応しなければならないことを意味する。具体的には、内蔵ストレージや場合によってはクラウドストレージのバックアップから当日操業が可能なよう一部を復元する手順の採用である。
　これは、従来の対応手順に加えて採用できるよう、技術部サポート課に周知する必要がある。私は、この内容について、Z社情報システム部の協力を要請し、Eラーニングとしてまとめた。
　最後に、Z社情報システム部に情報発信と部品故障時のパーツを技術部サポート課に配備するよう要請した。
　情報発信は、Z社情報システム部が持つ、Aに関わる高度なインシデント対応の知見をZ社管理課及びZ社技術部サポート課に広めることを目的とした。上記のEラーニングにこの情報発信も含めるよう依頼した。
　パーツの配備は、技術部サポート課が訪問作業を実施した際に、パーツが必要となりその手配で24時間以内に復旧させるSLAを違反が発生することを防ぐためである。
1705-2305

設問ウ：取組の評価と改善点

1.評価
　SLAを変更してから半年が過ぎ、私はこの変更のレビューを営業部と実施した。
　変更にSLA違反となるような事案はなく、問題なく稼働していると考えられる。また、サービスレベルにSLAを加えることによって、副次的な効果ではあるが、顧客へのサービス停止時間が減少し、顧客満足度の向上にもつながったことが確認された。
2.今後の課題
　私は、今回のSLAの変更の発端が情報セキュリティの脅威からであったことから、今後とも継続的かつ自動化されたSLAの変更について検討の必要があると考えた。
　これについては、エラー通知が利用できると考えた。サービスレベル目標を満たせない事態の発生又は兆候の認識について、顧客のサービス要求を待つプロアクティブな対応だけではなく、早期に検知が可能なプロアクティブな対応が可能となると考えられる。
　エラー通知に関する運用についても、設問イで述べた関連部署との協議・調整が必要となる。具体的には、エラー通知を受けるZ社技術部管理課の取り扱いの変更、エラー通知が通知可能な内容といった仕様に関するZ社情報システム部との情報提供、新たなエラー通知運用に関するZ社サポート課の対応の変更などである。
　私は、この変更の協議するため、各関連部署の要員を招集し、会議を開催した。