ITIL No.3 -サービストランジションの概要-

こんにちは豊かな大島です。

前回、ITILのサービスデザインについて書かせて頂きましたが、今回は第3回としてご紹介致します。

前回の記事：ITIL No.2 -サービスデザインの概要-

ITILには「サービスライフサイクル」と言う、５つのプロセスから成り立つ重要な考え方が御座います。

１.サービスストラテジ(サービス戦略)

２.サービスデザイン(サービス設計)

３.サービストランジション(サービス移行)

４.サービスオペレーション(サービス運用)

５.継続的なサービスの改善（コンティニュアルサービスインプルーブメント）

今回は、３.サービストランジション(サービス移行)について説明します。

サービストランジションはサービスデザインで設計されたサービスを本番環境へ移行・導入することをゴールとしたプロセスです。

または既存のサービス変更を確実に本番環境へ導入・移行するためのプロセスです。

サービストランジションでは以下の大きな項目をおさえておきたい。

• 移行計画立案とサポート
• 変更管理
• サービス資産および構成管理
• リリースおよび展開管理
• ナレッジ管理

 移行計画立案とサポート

サービスデザインの要件を網羅し、移行作業が確実に実施できるように計画を立案する事かゴールのプロセスです。

サービスデザインからの引き継ぎ、サービス移行段階におけるプロセス間の関係の定義や調整は、移行計画立案とサポートの役割です。

• リリース方針の定義
• リソース(人員含む)の割当て、期間、コストに関する移行計画
• 各プロセスからのインプット情報分析、RFC※評価、ベースライン設定、課題、リスク管理などの事前レビュー
• リリーステストと手順の立案

※RFC (Request For Change)変更要求書、変更を行う際に管理者や作業者に申請する要求書。

変更管理

変更のライフサイクルを管理し効率的な変更を定義するのが目的です。変更プロセスは記録され、目的やリスクが評価されて、テストをレビューし実行に移し、手順書などを評価します。組織のルールを確立し、周知徹底されなければなりません。

変更管理においては、その変更は妥当か類似している変更要求はないか、変更日時や変更方法や内容を決める際にCAB※を招集することがもっとも重要だと考えています。また、緊急度が高い変更に関してはECAB※を開き話し合いを設けます。

※ CAB(Change Advisory Board)変更諮問委員会。変更要求を話し合い、変更の可否を評価するために組織される委員会 。

※ ECAB(Emergency Change Advisory Board)緊急変更諮問委員会。緊急変更が必要な場合に召集され、緊急の変更意思決定を下す委員会 。CABを招集できない場合に緊急招集できる小規模な委員会です。

変更リスクの管理はリスクの大きさに応じて変更の承認権限を設定しなければなりません。

組織全体に影響をあたえる変更と個人、つまりわずかな影響がある変更は同様に扱うことは適切ではありません。

手順が周知済みの変更は現場の判断で変更することにより、迅速に変更が可能です。

日常に発生する変更に対して決められた変更を標準的な変更と言います。

 サービス資産および構成管理

ITサービスに必要なITインフラストラクチャのコンポーネントの構成情報の把握、正常稼働中の状態を維持し、他のプロセス活動の最適化を支援するプロセスです。構成管理ではCI※(構成アイテム)で管理され、IT機器だけではなくITサービスに関わる全ての情報が管理対象となります。

※CI(Configuration Item)構成アイテム。ITサービスを提供するうえで管理が必要とされる全てのコンポーネント。

構成管理の主な構成アイテム

• ハードウェア
• ソフトウェア
• 文書（仕様書・設計書、SLA、 契約書、運用マニュアルなど）

Ⅰ 管理と計画立案：構成管理方針、適用範囲、目標、役割、責任などの導入計画立案
Ⅱ 構成の識別：CIの選択基準、名前、ラベル付、他のCIとの関連、タイプなどを定義
Ⅲ 構成コントロール：CIの変更を追跡、管理
Ⅳ ステータスの説明と報告：CIのステータスを追跡、ステータスレコード、レポートの作成
Ⅴ 検証と監査：CMDB※に格納されているCIは正しいか、実際に存在しているかを確認

※ CMDB(Configuration Management Database)構成管理データベース、サービスやシステムを構成する全ての要素（設備、ハード、ソフト、ネットワーク、機器類、マニュアル、SLA、組織など）の詳細及び相互関係に関する情報を管理する仕組み。

リリースおよび展開管理

ITサービスの品質を安定させることを目的として、リリース・パッケージの構築と導入、テストを実施し本番環境での影響を抑えるためのプロセスです。

リリースパッケージの構築プロセスは以下の通りです。

1. リリースと展開の計画立案
2. リリースの構築・テスト
3. 展開
4. レビューとクローズ

・リリースと展開の計画立案

変更管理プロセスにて承認されたリリース展開のテスト計画や、受け入れ基準を作成し、リリースのパッケージ化、構築、展開など、サービスオペレーションに引き継ぐ活動の計画立案をします。

・リリースの構築・テスト

切り戻し計画やテストリハーサルの実施・確認などの項目があります。システム障害の半数はリリースのタイミングで発生すると言われていますので慎重・正確に進めます。予め種別ごとにまとめ準備を進める必要があります。複数の組織が分散してる場合でもこのプロセスをしっかり構築しテストすることにより効率的に受け渡しを行う事が化の王になります。

・展開

リリース計画に従い稼働環境に展開を実施、サービスオペレーションや初期サポートへ引き継ぎます。展開によっては廃止した資産管理も求められます。特に個人情報の除去などは確実に実施し、文章として残しておくことは必要です。

・レビューとクローズ

展開が実施されてから定めた期間の後、レビューを実施します。利用者の満足度、品質基準、達成度を確認してクローズします。関連するプロセスや構成アイテム(CI)を関連付けしてモレヌケがないよう管理します。

ナレッジ管理

ナレッジ管理ではDIKWと言う用語が使われます。ナレッジを効率的に管理するために収集すべきデータと情報の要件を定義し、そのデータを"SKMS"に蓄積していきます。SKMSは、CMDBやCMS及びその他のツールとデータベースが含まれITサービスのライフサイクル全体を管理するためにITサービスプロバイダが必要とする全ての情報を格納、管理、更新、提示します。

Data(データ), Information(情報), Knowledge(ナレッジ), Wise(知恵)

データは事象についての様々な形でインフラストラクチャ上に存在 します。
情報は、データに前後関係をもたらすことで生まれ、通常、文書、電子メール、マルチメディアのようにやや構造化された状態で保管されています。
ナレッジは、個々が持っている暗黙の経験、考え、見識、価値および判断で形成されます。 意思決定がしやすいように、情報を「使える形」に変えたものです。
知恵は、全体の流れを踏まえた上で、確固たる常識的な判断を行うための本質を 捕らえた具体的な洞察です。

さて、次回は「４.サービスオペレーション(サービス運用)」をご紹介致します。

ごきげんよう！