ITIL3
第5章 サービストランジション（導入、変更処理）
全部で7つのプロセス
※ITILファンデーションでは3つのプロセス
概要
★サービスVモデル
顧客と合意した要件に達する為の5レベルの構築・テスト
1：事業、ビジネス要件定義 ⇒ サービス、ソリューション検証
2：サービス要件定義 ⇒ サービス受け入れテスト
3：サービス設計 ⇒ サービス運用（オペ）のテスト
4：サービス・リリース設計 ⇒ サービスリリースパッケージテスト
5：サービスソリューション開発 ⇒ コンポーネント、アセンブリテスト
・DIKW データ、情報、知識、知恵
データ：事実
情報：事実を集計
知識：傾向を知っている
知恵：傾向から施策を生み出せる
★サービスナレッジ管理システム（SKMS）
ナレッジ、情報の管理に使用される一連のツール
⇒構成管理システム（CMS）
インシデント、問題、既知のエラー情報含む
⇒構成管理データベース（CMDB）
CI管理のDB
⇒既知のエラーデータベース（KEDB）
⇒サプライヤ契約DB（SCD）
■①変更管理
標準化された手順を用いて、あらゆる変更を処理する。
事業にもたらされるリスクを最適化する。
・変更
サービス、サービス構成要素に対して追加、修正、削除
問題に対しての対応
使い勝手を改善する為の対応
・変更要求（RFC）
サービス変更の要求
・変更スケジュール
承認済みの変更の詳細と実施予定日をまとめたもの
・変更管理の7つのR
変更評価に使う質問
変更要請したのは誰？
変更理由は？
変更成果として要求されるものは？
変更に伴うリスクは？
変更に必要なリソースは？
変更の責任は誰に？
この変更と他の変更の関係は？
★変更モデル
変更のインパクトによる分類
通常の変更
標準的な変更
緊急の変更
★変更マネージャ
全てのRFCに対してクローズまでの責任者
RFCに対して優先度を割り当てる
CABの召集
・変更諮問委員会（CAB）
変更を管理、評価、許可を支援する機関
・変更諮問委員会（ECAB）
緊急の変更が必要になった場合に招集される機関
■②リリース管理及び展開管理
変更管理で計画された変更を受けて、その変更を実施する為の
計画、テスト、配布などを行う
※実際の変更処理を「正しく」行う為のプロセス
★リリース
ITサービスに対する許可された変更の集合帯
・リリースユニット
サービスやインフラをまとめてリリースする単位
・リリースパッケージ
複数のリリースユニットをまとめたもの
・ビッグバンアプローチ
新規サービスや、サービス変更を一斉に展開
・段階的アプローチ
新規サービスやサービス変更を一部のユーザーに限定して展開
・プッシュアプローチ
中央拠点から配信先へと配信
・プルアプローチ
ユーザーから中央拠点へアクセスし、持っていく展開方法
・自動
新規サービスやサービスの変更を自動で配信する
・手動
新規サービスやサービスの変更を手動で配信する
■③サービス資産管理および構成管理
サービス、インフラの構成情報を管理。
・構成アイテム（CI)
ハードウェア、ソフト、スタッフ、SLAなど
ITサービスの提供の為に管理する必要のあるコンポーネント
・構成識別
CI（マウス、モニタなど）を目に見える形で管理する。
※ラベルを張り付けるなど
・ステータスの説明と報告
構成アイテムの状態（インストール済み、回収済みなど）
を記録、報告する事。
・確定版メディアライブラリ（DML）
ソフトウェア、確定版文章など保管し、保護する場所。
・構成ベースライン
特定の時点におけるCIを記録したスナップショット
・構成管理データベース（CMDB）
構成アイテムを管理するDB
・構成管理システム（CMS）
構成データの管理に使用するツールデータベース
構成アイテムだけではなく、インシデント、問題なども
管理に含める。
第6章 サービスオペレーション（運用）
サービスオペレーション：5プロセス
サービスの運用活動：2機能
⇒サービスデスクとIT運用管理
・サービスオペレーションにおけるバランス
内部的なIT視点と外部的な事業観点
安定性と対応力
サービスの品質とサービスのコスト
リアクティブとプロアクティブ
■①イベント管理
全てのイベントを管理する
異常時は「インシデント管理」へエスカレーション
・イベント
構成アイテムやITサービスの管理にとって重要性のある状態の変更
情報 対処不要なイベント
警告 現状の状態に注意を払うイベント
例外 正常に運用ができていなイベント
・アラート
しきい値に達した時や障害時の警告
■②インシデント管理
インシデントの受付から解決まで。
⇒正常なサービス運用をできるだけ早く回復させる為。
⇒「問題」の根本原因の解決、調査などは行わない。
問題管理へエスカレーションする。
インシデント「識別」
記録
分類
優先度決定
初期診断
エスカレーション
調査と診断
解決と復旧
クローズ
・インシデント
ITサービスの計画外の停止や品質低下。
将来的な影響となる可能性のイベントもインシデントに含まれる。
★インシデントモデル
インシデント再発時に対して、事前に定義した処置方法の事
※すばやく対応できる
・重大なインシデント
事業に深刻な中断を与えるインシデント
・緊急度
どれだけ早く解決する必要があるか
・インパクト
ITシステムに対するインシデント、問題、変更の影響度
・優先度
インパクト＋緊急度で決まる
・エスカレーション
インシデント解決支援の為の仕組み
・1次、2次、3次サポート
1次：サービスデスク
2次、3次：より専門的なグループ
■③要求実現
ユーザー要求に対して、合意された手順で処理する。
・サービス要求
ITサービスに対して標準的な変更を求めるユーザー要求
※パスワードリセットなど
・要求モデル
サービス要求を処理する為、事前に定義した処理方法
・セルフヘルプ
ユーザー自らがサービスデスクを利用できるようにする仕組み
■④問題管理
サービスデスクで解決できなかったインシデントで
「問題」なのか「既知のエラー」なのか判別し、管理する。
回避策（ワークアラウンド）は「インシデント管理」へ提供
問題の「検出」
記録
カテゴリ化
優先度
調査、診断
既知のエラーレコード作成
問題解決
クローズ
レビュー
・問題
インシデントを引き起こす未知の原因
・問題モデル
問題が再発した時に実施する、事前に定義した処置方法
・ワークアラウンド（回避策）
問題に対する回避策
・既知のエラー
すでに原因が判明し、対応策が特定されているインシデント
・既知のエラーデータベース（KEDB）
既知のエラーの詳細保存DB
・リアクティブな問題管理
根本的な原因を解決し、再発を防止する活動
・プロアクティブな問題管理
将来発生する可能性のある問題を予防する活動
■⑤アクセス管理
許可されたユーザーにサービスを利用する権利を与える。
・アクセス
サービスの機能やデータに対してユーザが利用できる範囲
・ID
ユーザを個人として識別する情報
・権限
利用できるサービス、機能に対してどこまでの操作が可能か
定義するもの
・サービス群
複数のサービスをグループ化
群単位でまとめてアクセス権限をユーザーに与える事で
効率的に処理できる。
・ディレクトリサービス
アクセスや権限を管理する為のサービス。
ADなど
■⑥サービスデスク（機能）
プロバイダ〜ユーザー間の日常単一窓口
⇒インシデント管理、サービス要求、標準変更を実施
・単一窓口（SPOC）
ユーザーからの単一の連絡手段の事
・IT組織全体の調整
ユーザーの利益となるようにITサービスプロバイダの活動を調整する。
・ローカルサービスデスク
ユーザーの拠点内に設置されたサービスデスク
オンサイト対応が可能
・中央サービスデスク
複数の拠点の窓口を集約したサービスデスク
・バーチャルサービスデスク
実際の拠点は分散。擬似的に1つのサービスデスク機能を提供
・フォローザサン
24時間、365日で対応する事。
・インシデントのオーナーシップ
受け付けたインシデントに対して最後まで責任を持って、
追跡、管理する事。
・ユーザー及びITスタッフとのコミュニケーション
インシデントを円滑に解決へ導く為、ユーザーや必要な部門と接点を持つ
・進捗情報の提供
インシデントなどの途中経過をユーザーに報告する事
・管理情報の提供
インシデントを統計、解析しサポートデスクの運用向上に役立てる
■⑦技術管理（運用活動機能）
ITインフラの運用管理に必要な技術力、リソースを提供する。
ITインフラの設計
インフラの保守
障害発生時のサポート
■⑧アプリケーション管理
アプリの運用に必要な技術力、リソースを提供する。
・アプリケーションの設計
・機能の可変性の保証
・アプリケーションの保守
・障害発生時のサポート
■⑨IT運用管理
ジョブのスケジュール、バックアップ、リストアなど日常的な
運用活動の実施に責任を負う
運用コントロールと施設管理が含まれる
第7章 継続的サービス改善
・事業部門に提供しているITサービスもビジネスの変化に合わせて
変更していく必要がある。
・デミングサイクル
品質改善で用いられるPDCA
・継続的サービス改善モデル
継続的サービス改善で利用するデミングサイクルのモデル
・測定する理由
妥当性確認、方向付け、正当化、介入の4つ理由
・技術測定基準
CPU使用率、メモリ使用量などコンポーネント、アプリケーションの
測定基準
・プロセス測定基準
サービスマネジメントのプロセスの有効性や効率性を図る測定基準の事
・サービス測定基準
利用者に直接影響を与えるサービスをエンドツーエンドで
パフォーマンス、品質を測定する。
★7ステップの改善プロセス
測定対象の定義
測定できる内容の定義
データの収集
データの処理
データの分析
情報の提示、活用
是正措置の実施
