サービスマネジメント

目次

応用情報技術者試験（レベル３）シラバス－情報処理技術者試験における知識・技能の細目－ Ver.6.1 に基づき，「サービスマネジメント」の対策ノートを作成した。

本稿は，プロジェクトマネージャ試験 午後Ⅱ の対策としても活用できるようにしている。

• サービスマネジメント
• サービスマネジメントシステムの計画及び運用
• パフォーマンス評価及び改善
• サービスの運用
• ファシリティマネジメント
• 本稿の参考文献

サービスマネジメント

(1) サービスマネジメントの目的と考え方

サービス

サービルとは「顧客が特定のコストやリスクを負わずに達成することを望む成果を促進することによって，顧客に価値を提供する手段」（出典「ITIL 用語および頭字語集」）

サービスコンポーネント

サービス品質

サービスマネジメント

情報システムの運用や保守は，ハードウェアやソフトウェアなどの技術的な側面と顧客の要求を満たすためのサービスとしての側面から対応する必要がある。サービスマネジメントとは，高品質なサービスを顧客に提供するためのものである。ITIL では，この目的を実現するための指針を成功事例に基づいてまとめている。

サービスライフサイクルの段階（計画立案，設計，移行，提供，改善）

サービルライフサイクルの段階を次表に示す。

(2) サービスマネジメントシステムの確立，実施，維持及び継続的改善

サービスマネジメントシステム

ITIL では，サービスマネジメントを「顧客に対し，サービスの形で価値を提供する組織の専門能力の集まり」として定義している。

システムの運用や保守などを IT サービスとしてとらえて体系化し，適切なサービス品質で，サービス価値を提供する。また，顧客満足度を考え，サービス提供者だけでなく，ユーザの順守事項も決定する。

IT サービスマネジメントを導入する際の手順は以下のとおり。

1. ビジョンの明確化
2. 現状の把握
3. 目標の設定
4. 目標達成方法の検討
5. 目標達成状況の把握方法の検討
6. 継続的改善方法の検討

サービスの要求事項

顧客

サービス提供者

サービスオーナは，特定の IT サービスの提供に対する責任をもつとともに，顧客も含めた関係者に対する説明責任をもつ。

JIS Q 20000 の規格群（ISO/IEC 20000 シリーズ）

(3) ITIL

ITIL (Information Technology Infrastructure Library)

ITIL は，1989 年に英国が発行した IT サービスマネジメント（ITSM）のガイドラインである。IT サービスに関する国際的な教本として各国で利用されており，最新版は 2019 年に ITIL4 が発行されている。

サービスマネジメントの成功事例（ベストプラクティス^[1]）を英国政府機関の OGC（Office of Government Commerce）が体系化したもので，世界的な標準企画として扱われている。サービスマネジメントは，情報システムの運用や保守などを行う IT サービスの事業者が顧客の要求を満たすために自社のサービスを管理するための取組み（フレームワーク）のことである。

ITIL 2011 edition いよれば，サービス・パッケージは，コアサービス，実現サービス及び強化サービスの組合せで構成された，特定の種類の顧客ニーズへのソリューションを提供する複数のサービスの集まりである，と説明されている。

ITIL が定義する機能の名称には，サービスデスク，技術管理，アプリケーション管理，IT 運用管理の 4 つがある。

ITIL で定義されるサービスのライフサイクルにおける，サービストランジション段階では，規定された要件と制約に沿って，サービスを運用に移行し，確実に稼働させる。

7 ステップの改善プロセス

ITIL 2011 edition に記載されている 7 ステップの改善プロセスとは、改善を ① 特定、② 定義、③ 収集、④ 処理、⑤ 分析、⑥ 提示、⑦ 実装するために必要な手順を定義および管理するプロセスのことである。

1. 改善の戦略を識別する
2. 測定するものを定義する
3. データを収集する
4. データを処理する
5. 情報とデータを分析する
6. 情報を提示して利用する
7. 改善を実施する

ITIL の IT サービス継続性管理の達成目標として，災害が起こった後，一定期間内にシステムを復旧し事業を継続させることが挙げられる。

ITIL は，サービスマネジメントを実現するためのガイドラインである。これを日本工業規格（JIS）が日本における IT サービスマネジメントの実践的な規格・ルールとして定めたものが JIS Q 20000（JIS Q 20000-1 : 第1部 : サービスマネジメントシステム要求事項，JIS Q 20000-2 : 第2部 : 実践のための規範）である。

JIS Q 2000-1 : 2012 0.2 サービスマネジメントシステム要求事項

この規格の要求事項は，サービスの要求事項を満たし，かつ，顧客及びサービス提供者の双方に価値を提供する，サービスの設計，移行，提供及び改善を含む。この規格は，サービス提供者がサービスマネジメントシステム（以下，SMS という。）を計画，確立，導入，運用，監視，レビュー，維持及び改善する場合の統合されたプロセスアプローチを要求する。

JIS Q 20000-1:2012（サービスマネジメントシステム要求事項）の "サービスマネジメントシステムの監視及びレビュー" の要求事項の一つに「監査員は，自らの仕事を監査してはならない」がある。

(4) SLA

SLA

SLA (Service Level Agreement) は、発注者とサービス提供者との間で、サービスの品質の内容について合意した文書のこと。

内容は、サービスの品目と水準，水準が達成できなかった場合のペナルティなどが盛り込まれ、サービスレベルは客観的な方法で測定できる数値で記載される。

IT サービスの可用性と信頼性の管理に関わる KPI として，サービスの中断回数及びそのインパクトの削減率が用いられる。

例として，ある会社の基幹サービスの SLA の抜粋を次表に示す。

SLA の目標値は，目標保証型と努力目標型に分類される場合がある。

目標保証型

取り決めたサービスレベルを保証する。

努力目標型

取り決めたサービスレベルは努力目標にとどまり，サービスレベルの達成，維持に向けて継続的な改善努力を行う。

サービス可用性

信頼性

サービス時間

応答時間

サービス及びサービスマネジメントシステムのパフォーマンス

サービスマネジメントシステムの計画及び運用

(1) サービスマネジメントシステムの計画と支援

PDCA

サービスマネジメントシステム要求事項は，SMS 及びサービスのあらゆる場面で， 計画（Plan）−実行（Do）−点検（Check）−処置（Act）（PDCA）として知られる方法論の適用を要求する。この規格で適用する PDCA 方法論を簡潔に説明すると，次のようになる。

計画（Plan）

SMS を確立し，文書化し，合意する。SMS には，サービスの要求事項を満たすための方針，目的，計画及びプロセスが含まれる。

実行（Do）

サービスの設計，移行，提供及び改善のために SMS を導入し，運用する。

点検（Check）

方針，目的，計画及びサービスの要求事項について，SMS 及びサービスを監視，測定及びレビューし，それらの結果を報告する。

処置（Act）

サービスマネジメントシステム及びサービスのパフォーマンスを継続的に改善するための処置を実施する。

JIS Q 9001

マネジメントシステム

資源

力量

認識

コミュニケーション

文書化した情報

知識

(2) サービスの計画

サービスの要求事項

変更要求

サービスポートフォリオ

サービス・ポートフォリオとは，サービス・プロバイダによって管理されている全てのサービスをリスト化し，そのサービスごとに詳細情報をまとめたものである。

サービス・プロバイダの約束事項と投資を表すものであって，サービス・プロバイダによって管理されている "検討中か開発中"，"稼働中か展開可能" 及び "廃止済み" の全てのサービスが含まれる。

サービス・パイプライン

サービスの状態（計画中，開発中，稼働中，廃止など）

(3) サービスカタログ管理

サービスカタログ

サービスの販売と提供の支援に使用され，顧客に公開されるものであって，"検討中か開発中" と "廃止済み" のサービスは含まれず，"稼働中か展開可能" のサービスだけが含まれる。

サービスカタログとは，サービスプロバイダ（情報システム部門／外部サービス事業者）がエンドユーザー（従業員／顧客）に向けて提供中の IT サービスをまとめたリストのこと。現状において稼動中で利用可能な IT サービスを一覧できるようにした文書やデータベースなどをいう。サービスカタログの認可は，サービスオーナが責任をもつ事項である。

サービスカタログは、IT サービスを受けるエンドユーザーに「いま利用できる IT サービスには何があるか」「すでに利用している IT サービスはどれか」などの情報を明確に提示するものである。従って、IT サービスを利用するうえでは不要な技術的説明などは省き、IT に詳しくない利用者にも理解できるような言葉遣いで表現すべきである。

サービス・カタログとは「稼働中の全ての IT サービス（展開可能な IT サービスを含む）に関する情報を格納するデータベースまたは構造化された文書」（出典「ITIL 用語および頭字語集」）

(4) 資産管理

資産管理（IT アセットマネジメント（ITAM：IT asset management））

ソフトウェアアセットマネジメント（SAM）

ライセンスマネジメント

(5) 構成管理

構成管理

構成管理プロセスは、すべてのサービス資産と構成およびその関係を特定して構成管理データベース（CMDB）を構築し、それらサービス構成要素の維持管理や制御を活動の中心とするプロセスである。構成管理データベースには、構成品目、版、関係、ベースライン及びリリースなどの構成情報が記録され、他のプロセスからの求めに応じて情報の提供を行う。既知のエラーレコードを作成してデータベースに登録するのも，構成管理プロセスで行う活動である。

構成管理を導入することで，構成品目の情報を正確に把握することによって，他のプロセスの確実な実施を支援できる，というメリットが得られる。

構成品目（CI : Configuration Item）

サービスの提供のために管理する必要がある要素。

構成情報

文書化された構成情報（例：構成管理データベース（CMDB : Configuration Management Database））

構成品目のライフサイクルを通じて，構成品目の属性及び構成品目間の関係を記録するために使用するデータベース。

版（バージョン）

構成ベースライン

構成識別

構成監査

(6) 事務関係管理

事業関係管理

サービス提供者と顧客との間の良好な関係を確立するための活動を行う。苦情の処理や顧客満足度の測定・分析・レビューなどを行う。

事業関係マネージャは，事業関係管理について責任をもつ役職で，顧客との関係維持を責務とする役割である。

顧客関係

顧客満足

サービス満足度

苦情

(7) サービスレベル管理

サービスレベル管理（SLM : Service Level Management）

サービスレベル管理（SLM : Service Level Management）の最終目標は，現在のすべての IT サービスに対して合意されたレベルを達成すること，そして将来のサービスが，合意された達成可能なサービスレベル目標を満たすように提供されることである。

サービスレベル管理プロセスの活動として，提供するITサービス及びサービス目標を特定し，サービス提供者が顧客との間で SLA（Service Level Agreement）を交わす。

SLA の締結後は、PDCA マネジメントサイクルによってサービスの維持、及び向上を図る活動を行う。

サービスレベル目標

パフォーマンス

(8) 供給者管理

供給者管理

サービス提供者が委託などにおいて，さらにサービスマネジメントプロセスの導入や移行のために供給者（サプライヤ）を用いる場合には，その供給者の管理が必要である。運用を委託する場合には，運用レベルを保証するために OLA（Operation Level Agreement : 運用レベル合意書）を作成し，契約を行う。

外部供給者

内部供給者

供給者として行動する顧客

契約

アウトソーシングの利用

SaaS，PaaS，IaaS などのクラウドサービスの利用

クラウドサービス上にデータを保存している場合、急なサービス提供停止により重要なデータが消失してしまうというリスクがある。そのためクラウドサービスを選定する際には、導入・運用コストなどの検討とあわせて、サービス提供事業者が「そのサービスを長期に渡り提供し続けてくれるどうか」や「利用終了時のデータの取扱い」という点を考慮する必要がある。

SaaS 選定の観点を次表に示す。

(9) サービスの予算業務及び会計業務

サービスの予算業務及び会計業務

財務管理

予算業務

会計業務

課金

配賦

直接費

間接費

減価償却

総所有コスト（TCO : Total Cost of Ownership）

TCO (Total Cost of Ownership) は、ある設備・システムなどにかかわる、購入から廃棄までに必要な時間と支出の総計金額のことである。

(10) 需要管理

需要

需要管理

各種サービスに対するニーズの量（つまり「需要」）を総合的に把握して管理することで，より効率的に良いサービスをお客様に提供することができるようになる。これを需要管理と呼ぶ。

需要管理とは「サービスに対する顧客の需要を把握，予測し，それに影響を及ぼすことを責務とするプロセス」（出典「ITIL 用語および頭字語集」）

需要予測

(11) 容量・能力管理

容量・能力（キャパシティ）

システムが備えるべき能力（キャパシティ）を管理する。キャパシティは，現在および将来の需要を考慮して計画・設計を行う。また，サービスのパフォーマンス（CPU 使用率，メモリ使用率，ディスク使用率，ネットワーク使用率ほか）のしきい値を設定・監視し，キャパシティ拡張の判断を行う。

キャパシティ管理に関わる必要な活動として，リソースの増強を適切に（過不足なく）行う必要がある。

容量・能力計画

容量・能力管理

オンラインシステムの容量・能力の利用の監視についての注意事項は，応答時間や CPU 使用率などの複数の測定項目を定常的に監視する。

キャパシティ管理では，サービスにどの程度のリソースやパフォーマンス（機能）が必要となるかを将来を見据えて管理する。リソースには，CPU やメモリといったシステム的なものだけでなく，人的リソースや工数管理も含まれる。

スケールアップ

サーバを構成する各処理装置をより性能の高いものに交換したり，プロセッサの数などを増やすことでサーバ当たりの処理能力を向上させる

スケールアウト

接続されるサーバの台数を増やすことでサーバ群全体としての処理能力や可用性を向上させる

監視

しきい（閾）値

管理指標（CPU 使用率，メモリ使用率，ディスク使用率，ネットワーク使用率ほか）

(12) 変更管理

① 変更管理方針

変更管理

変更管理は，サービスのコンポーネント，文書の変更を安全かつ効率的に行うための管理である。事業部や IT 部門などからの RFC（変更要求）を受け取り，対応する。

ITIL v3 における変更管理プロセスの考え方として，変更諮問委員会（CAB）だけではなく，緊急時の決定を下す権限を有する小規模な組織を特定しておくことも必要である。

変更管理方針

② 変更管理の開始

変更要求（RFC）

RFC (Request For Change) は、インシデント管理プロセスや問題管理プロセスから発行される変更要求である。RFC を受けて実際にシステム構成を変更するのは変更管理プロセスでの活動である。

③ 変更管理の活動

変更管理方針で定義された構成品目に対する変更要求の管理を実施する。

優先度

変更のカテゴリ（標準変更，通常変更，緊急変更など）

ロールバック（切り戻し）

変更諮問委員会（CAB）

IT サービスに変更を加える要因には，単純なオペレーションだけでなく事業戦略やビジネスプロセスの変更など，様々なものがある。そのため，顧客やユーザ，開発者，システム管理者，サービスデスクなどの様々な立場の利害関係者が定期的に集まり，変更をアセスメントする変更諮問委員会（CAB : Change Advisory Board）が開かれる。

変更実施後のレビュー（PIR）

(13) サービスの設計及び移行

① 新規サービス又はサービス変更の計画

サービスの設計及び移行

新規サービス又はサービス変更の計画

サービスまたは顧客に重大な影響を及ぼす可能性のある「新規サービス」や「サービス変更」が起きた場合に，サービス提供者が実施すべき適切な手順や活動，考慮すべき内容等を定めている。

新規または変更したサービスを本格的な稼働状態へ移行する場合は，以下に示すような手順を踏まえる必要がある。

1. 試験環境を用意し，事前に試験（受入れテストや運用テスト）を実施する。また，稼働環境へ移行する際の切替え手順や問題点を確認するために移行テストを実施する。
2. 1. で問題がなければ稼働環境へ移行（一斉移行方式，段階的移行方式，並行移行方式など）させる。

開発から運用への移行を円滑かつ効率的に進めるには，システムの開発部と顧客（または運用部）が連携し，顧客もシステムの運用に関わる要件の抽出に積極的に参加することが重要になる。

② 設計

サービスの設計は，経営戦略で定められた事業のニーズを満たすために行われる。SLA などで定められた，具体的な数値を満たすために必要なサービスの設計を行う。

サービス受入れ基準

設計・開発

サービス設計書

非機能要件

性能，信頼性，拡張性，セキュリティなどのように，システム自体に求められる業務要件や入出力など以外のもの全般を指す。

③ 構築及び移行

構築

継続的インテグレーション

移行

運用サービス基準

業務及びシステムの移行

現行システムの登録データと新システムへの移行内容を次表に示す。

移行計画

移行リハーサル

切換計画に不備がないことを確認するために，システム切替作業の実施日より前に実施するもの。

移行判断

移行の通知

移行評価

運用テスト

受入れテスト

運用引継ぎ

(14) リリース及び展開管理

リリース及び展開管理

変更管理プロセスで承認された変更内容を，IT サービスの本番環境に正しく反映させる作業（リリース作業）を行うのが，リリース及び展開管理である。

リリース管理では，本番環境にリリースした確定版のすべてのソフトウェアのソースコードや手順書，マニュアルなどの CI（構成品目）を 1 か所にまとめて管理する。まとめておく書庫のことを DML（Definitive Media Library : 確定版メディアライブラリ）という。

リリース

緊急リリースを含むリリースの種類

展開

リリースの受入れ基準

受入れ試験環境

稼働環境

リリースの配付

継続的デリバリ

継続的デプロイ

(15) インシデント管理

インデント管理は，"計画外の障害"や "顧客からのサービス障害報告" からのサービスの迅速な復旧を行う管理を行う。

① インシデントの対応

インシデント管理

インシデント管理は、サービスに対する計画外の中断、サービスの品質の低下、あるいは顧客へのサービスにまだ影響していない事象が報告された時に、サービスの中断時間を最小限に抑えて速やかに回復することを目指すプロセスである。インシデント管理プロセスには，例として，ITサービスを迅速に復旧させるために回復策を実施する活動，インシデントの発生を記録し，関係する部署に状況を連絡する活動がある。

インシデント管理の手順は，以下の通り。

通常，インシデント管理では，次のような KPI（Key Performance Indicator）が設定される。

• サービスデスクで解決された割合（初回解決の割合）
• 解決までの平均時間
• 重大なインシデントの数・割合
• 目標時間内に解決できた割合

インシデント

記録

分類

影響

緊急度

優先順位

解決目標時間

エスカレーション（機能的エスカレーション，階層的エスカレーション）

インシデントの早期解決のために，インシデントを受け付けた 1 次グループが，より対処能力に優れた専門的な部門や権限を持つ上位組織（2 次グループ）などにインシデントの解決を依頼すること。

階層的エスカレーション

エスカレーションを支援するために，より上級レベルのマネジメントに情報を提供したり，彼らを関与させたりすること。

機能的エスカレーション

エスカレーションを支援するために，より高度な専門知識を持つ技術チームにインシデント，問題，または変更を転送すること。

回避策（ワークアラウンド）

インシデント発生時の回復策のことで、完全な解決策がまだ存在しないインシデントや問題の悪影響を低減または排除するために策定される。問題やエラーコードごとのワークアラウンドを用意することで、業務の停止時間を最小限に抑えることができる。

終了

インシデントモデル

② 重大なインシデントの対応

重大なインシデント

ミッションクリティカルシステム

ミッションクリティカルシステムは、障害発生などによってシステムが中断・停止すると巨額の損失や信用の失墜などの致命的な問題を招く可能性が高いため、24 時間 365 日止まることを許されないシステムをいう。

交通機関や金融機関の基幹システム、および EC サイトの基幹システムなどがミッションクリティカルシステムの例で、これらのシステムでは停止をさせないために極めて高い信頼性や耐障害性、保守性などが要求される。

(16) サービス要求管理

サービス要求管理

サービス要求

記録

分類

緊急度

優先順位

実現

終了

サービス要求の実現に関する指示書

(17) 問題管理

問題管理

問題管理プロセスは、インシデントの根本原因を特定し、インシデント及び問題の影響を最小化又は回避することを目的とするプロセスである。主な活動は以下の通り。

• インシデントの根本原因と潜在的な予防処置を特定する
• 問題解決のための変更要求を提起する
• サービスへの影響を低減又は除去するための処置を特定する
• 既知の誤りを記録する

したがって，IT サービスマネジメントにおける問題管理プロセスにおいて，インシデントの発生後に未知の根本原因を特定し，恒久的な解決策を策定する。

問題（problem）

一つ以上のインシデントの根本原因。（出典）JIS Q 20000-1:2011

傾向分析（trend analysis）

インシデントの発生を未然に防ぐためには，今後どのようなインシデントが発生するのかを予測し，予防措置を講じることで影響を最小限にとどめることが必要である。そのためには，インシデント及び問題の傾向を分析し，根本原因及び潜在的な予防措置を特定することが前提となる。サービスマネジメントにおけるこの作業を傾向分析という。

根本原因

インシデントまたは問題の，根本的な，あるいは元の原因を意味する。

予防処置

記録（record, noun）

達成した結果を記述した，又は実施した活動の証拠を提供する文書。

分類

優先順位付け

エスカレーション

解決

終了

既知の誤り（known error）

根本原因が特定されているか，若しくは回避策によってサービスへの影響を低減又は除去する方法がある問題。（出典）JIS Q 20000-1:2011

(18) サービス可用性管理

サービス可用性管理

サービス継続及び可用性管理は、SLA で合意したサービス継続及び可用性を達成することを目的とし、サービス障害や災害の予防及びそこからの復旧、並びに目標達成のための十分なサービスの可用性の提供を確実にするプロセスである。

サービス継続及び可用性管理の主要な活動は、リスクアセスメントとリスクマネジメントであり、リスクアセスメントでは重大なサービスの停止から事業が受けるインパクトを調査する事業影響度分析を実施することが望まれる。リスクアセスメント及び事業影響度分析に基づいてサービス継続計画が策定される。

サービス可用性

サービス可用性管理の 4 つの視点は次表のとおり。

信頼性

ソフトウェアの信頼性の評価指標を次に示す。

回復力

保守性

ソフトウェアの保守性の評価指標を次に示す。

MTBF

MTBF（mean operating time between failures : 平均故障間動作時間）は，故障間動作時間の期待値。平均故障隙間動作時間は，修理アイテムに対してだけ用いられる。ある特定期間中の MTBF は，その期間中の総動作時間を総故障数で除した値である。

故障動作時間が指数分布（exponential distribution）に従う場合には，どの期間をとっても故障率は一定であり，MTBF は故障率の逆数になる。

指数関数型を含む連続分布の MTBF は，信頼度関数 $R = e^{-\lambda t}$ を用いて，次式で計算できる。

MTTR

MTTR（mean time to restoration : 平均修復時間）は，修復時間の期待値。修理を完了するための平均時間を表し，アベイラビリティ $A$，保全度 $M$，修復率 $\mu$に関係する。

連続分布関数では，修復率 $\mu$ と逆数の関係になる。

また，固有アベイラビリティ $A$ との関係では，次式がよく用いられる。

(19) サービス継続管理

サービス継続管理では，インシデントの発生に備えて，復旧のための設計をする。

障害時には，待機系への切替え，データの回復などを行うが，その手法はあらかじめ設定しておく必要がある。BCP を策定し，RTO，RPO を決めておく。

事業継続計画（BCP）

サービス継続計画

復旧

RTO (Recovery Time Objective : 目標復旧時間)

業務中断後いつまでに復旧させるかを示す。例として，以下のようなものがある。

• 業務アプリケーションをリリースするための中断時間は，24 時間以内とする。
• 業務データの復旧は，障害発生時点から 24 時間以内に完了させる。
• 中断した IT サービスを 24 時間以内に復旧させる。

RPO (Recovery Point Objective : 目標復旧時点)

障害の発生などの理由により業務が中断した場合に、過去の何時の時点までの状態に戻すのかを示す目標値である。例として，以下のようなものがある。

• 障害発生時点の 24 時間前の業務データの復旧を保証する。

コールドスタンバイ

コンピュータシステムを設置できる施設だけを確保しておき、障害発生時にはそこに機材などを搬入してバックアップサイトとして機能させる方式。障害発生後には、システムの導入とデータの復旧を行って業務を引き継ぐ。

ホットスタンバイ（高速復旧）

バックアップサイトに本システムと同じ機器及びバックアップデータを用意しておく方式。非常時にはデータの復旧を行ってから処理を引き継ぐ。本システムを同じものを稼働させておき、定期的に同期をとる方式もこれに含まれる。

ホットスタンバイ（即時的復旧）

日常からバックアップサイトで本システムと同じものを稼働させておき、非常事態が起きたときに切れ目なく業務を引き継ぐ方式。常に本システムのデータとの同期が行われており、障害発生時に直ぐにその施設でシステムを運用できる体制になっている。

ウォームスタンバイ

バックアップサイトに本システムと同じ機器を全部(あるいは部分的に)設置しておく方式。障害発生後には、追加の機器やデータおよびプログラム媒体を搬入してから予備系システムを立ち上げて処理を引き継ぐ。

縮退運用

縮退運用は、システムの一部に障害が発生したときに、その障害部分を切り離し、処理速度や一部機能の制限をしてもシステム全体としては停止することなく稼働させ続ける方式である。フォールバック（fall back）ともいう。

例えば 2 台のサーバで構成される負荷分散システムにおいて、片方のサーバが故障したときに、処理能力の低下を許容して残った片方のサーバのみで処理を続けることが縮退運用に該当する。

ディザスタリカバリ（DR）

予期せぬ災害によって被害が発生した場合，迅速にサービスを回復，あるいは被害を最小限にとどめる必要がある。その回復措置をディザスタリカバリ（災害復旧），通称 DR と呼ぶ。事業継続計画（BCP）は DR を包含している。

(20) 情報セキュリティ管理

情報資産の機密性，完全性，可用性を保つように，情報セキュリティを管理する。ISMS を構築し，情報セキュリティマネジメントの規格に基づき，情報を適切に管理する。

パフォーマンス評価及び改善

(1) パフォーマンス評価

① 監視，測定，分析及び評価

② サービスの報告

サービスの報告

パフォーマンス

有効性

傾向情報

(2) 改善

① 不適合及び是正処置

不適合

是正処置

② 継続的改善

継続的改善

プロセス能力水準（プロセス成熟度水準）

プロセスアセスメント

ギャップ分析

CSF（Critical Success Factors：重要成功要因）

KPI（Key Performance Indicator : 重要業績評価指標）

業務状況を測定し，評価するために設定される指標。

サービスの運用

(1) システム運用管理

システム運用管理

システムが運用要件を満たしているかどうかを定期的に評価することは重要である。様々な視点から，管理項目が設定され，例として次表のようなものがある。

その他，安全性とセキュリティ，運用者の作業負担，利用者のシステム使用性なども評価項目として考えられる。

運用の資源管理（要員などの人的資源及びハードウェア，ソフトウェア，データ，ネットワークなどインフラストラクチャの技術的資源）

仮想環境の運用管理

ジョブの管理

データ管理

データ管理者（DA）とデータベース管理者（DBA）は，データベースの管理を専門的に扱う職種である。

データ管理者（DA : Data Administrator）

業務の実世界から概念設計，システム化の範囲で論理設計などデータそのものの管理を行う。

データベース管理者（DBA : DataBase Administrator）

DA が設計した論理データモデルから物理設計を行い，データベースを構築したり，構築後のデータベースの運用設計および運用保守などのデータベースの管理を行う。

利用者の管理

コールドスタート

ウォームスタート

(2) 運用オペレーション

運用オペレーション

日々の運用をルール化，手順化して実施することである。ルール化，手順化する内容としては，次表のようなものがある。

スケジュール設計

ジョブスケジューリング

バックアップ

フルバックアップ方式

毎回データ全体のバックアップを行う方式。復旧時間は短くなるが，バックアップに要する時間は長い。

差分バックアップ方式

定期的にフルバックアップを行い，次のフルバックアップまでの期間は，フルバックアップ以降に変更のあったファイル（差分）だけを記録していく方式。バックアップ時間は短くて済むが，復旧は ① フルバックアップの適用 → ② 差分バックアップを適用という流れになるのでフルバックアップ方式と比較して作業時間がかかる。

システムの監視と操作

アウトプットの管理

ジョブの復旧と再実行

運用支援ツール（監視ツール，診断ツール）

業務運用マニュアル

(3) サービスデスク

サービスデスク

サービスデスクは，ITIL が定義する機能の一つであり，インシデントの連絡の受付，対応及び解決に向けた活動を行う。

SPOC (Single Point Of Contact)

SPOC とは、利用者からの問い合わせに対応する単一窓口のことで「Single Point of Contact」の略である。利用者からの問い合わせを一元管理することで、対応業務の効率化及び品質向上を目的として設置される。

コールセンタ

CTI（Computer Telephony Integration）

コンピュータと電話システムを連携・統合したもの。

FAQ (Frequently Asked Questions)

「よくある質問とその答え」をまとめたドキュメントを指す。FAQ を作成し公開することで、利用者が既知の問題を自分で解決できるようになるため、利用者満足度の向上や利用者対応業務の効率化などの効果が望める。

応対マニュアル

知識ベース

一次サポート

二次サポート及び三次サポート

サービスデスク組織の構造（ローカルサービスデスク，バーチャルサービスデスク，中央サービスデスク，フォロー・ザ・サン）

サービスデスクとは顧客からの問合せの窓口のことで，「ヘルプデスク」とも呼ばれている。サービスデスク組織の構造には，次表のような種類がある。

AI の活用（チャットボットなど）

利用者が質問のキーワードを入力すると，想定される質問とその回答を返す。利用者が期待する回答が得られない場合には，キーワードを追加させるなど対話的な対応をする。

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

(1) ファシリティマネジメント

「ファシリティ」とは，"設備" や "施設" を意味する。情報システムを構成するサーバやネットワークは，決められた施設内に設置して運用が行われている。ファシリティマネジメントは，設備や施設をはじめとして，情報システムの維持保全を行う一連の活動のことである。

① ファシリティマネジメントの目的と考え方

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

IT サービスを提供するためには，その前提として，その IT サービスを運用するための施設・設備が，健全な状態で維持管理されていることが必要になる。

② 施設管理・設備管理

施設管理

システムを保有する施設や設備への障害となる内容とその対策の例として，次表のようなことが挙げられる。

建物管理（免震装置，アレスタなどのサージ防護デバイス，防災防犯設備，安全管理関連知識ほか）

電気設備（UPS，自家発電設備ほか）

UPS (Uninterruptible Power Supply) は、落雷などによる突発的な停電発生したときに自家発電装置が電源を供給し始めるまでの間、サーバに電源を供給する役目をもつ機器である。機器内部に電気を蓄えていて、電源の瞬断時にシステムを安全に終了する時間を与えてくれたり、自家発電装置による電源供給までの間、つなぎの役目を果たしたりする。

電力会社からの電力供給が長時間停止する場合を想定し，自家発電設備を設置する場合がある。

空調設備（空調機器，コールドアイル，ホットアイルほか）

冷房負荷は、室内の温度・湿度を一定に保つために、空気から取り除くべき熱量をいう。太陽熱、室外から侵入する空気内の熱、機器・照明の熱、室内外の温度差による窓や壁からの伝熱などがある。

通信設備（MDF，IDF ほか）

③ 施設・設備の維持保全

施設・設備の維持保全

④ 環境側面

環境側面

グリーン IT

環境側面では，地球環境に配慮した IT 製品や IT 基盤，環境保護や資源の有効活用につながる IT 利用を推進することが大切である。この思想のことをグリーン IT という。

データセンタ総合エネルギー効率指標（GEC，PUE，ITEE，ITEU ほか）

本稿の参考文献

• JIS Q 20000-1 : 2020「情報技術−サービスマネジメント− 第1部：サービスマネジメントシステム要求事項」"Information technology-Service management-Part 1: Service management system requirements"
• JIS Q 20000-2 : 2013「情報技術－サービスマネジメント－第2部：サービスマネジメントシステムの適用の手引」"Information technology -Service management- Part 2 : Guidance on the application of service management systems"
• 最上 千佳子 著，「ITIL はじめの一歩　スッキリわかる ITIL の基本と業務改善の仕組み」，株式会社 翔泳社，2019年3月11日

ITIL はじめの一歩 スッキリわかるITILの基本と業務改善のしくみ （EXAMPRESS　IT Service Management教科書） [ 最上 千佳子 ] 価格：1980円（税込、送料無料) (2022/1/10時点) 楽天で購入