6/6 ITILv3への道
アウトソーサ
→あるプロセス及びその管理を外部委託すること
参考)アウトソースしたプロセスを確実にするとは
→外部委託したプロセスが正しく管理されていることを確実にすること
コーポレート(:corporate)
→企業の。組織の。
アプリケーション・サイジング
→アプリケーションが合意したサービス・レベルを確実に満たすために必要なリソースを見積もること
参考)キャパシティ管理プロセスの1つの活動として位置づけられる。
アプリケーションの性能要件を満たし、サービスの品質を維持するためには必要不可欠な活動
可用性管理
→事業と顧客に利益を提供できるように、費用対効果の高い方法。
ITサービス、ITインフラストラクチャ、サポートする組織の可用性を最適化、改善する
目標)通常のITサービスを維持する
手段)対障害弾力性のあるシステム、Back-upなどによるリスク低減手段と復旧戦略
期間)定められた瞬間 or 期間
目的)ITサービスを実行
注意)ITサービス継続性管理と区別すること
可用性(Availablilty)
→ユーザがITサービスを利用可能能力を表す
参考)システムダウンなど、利用不能時間が少ないこと＝可用性が高いと表現
計算式) 可用性(%)=合意済みサービス時間-停止時間/合意済みサービス時間*100(%)
段階的アプローチ
→新規サービスやサービス変更を一部のユーザに限定して展開する方法。ユーザ限定する
参考)その後、他のユーザにも同じ変更を繰り返し展開
プッシュ・アプローチ
→新規サービスやサービス変更を中央拠点から配信先に配信する方法
参考)配信されるタイミングをユーザは選択不可
ex)Windows-セキュリティパッチの自動更新
プル・アプローチ
→ユーザが選択した時点 or ユーザのPCやサーバの起動時に、中央拠点から持ってくる(プルする)展開方法。
【手作業のワークアラウンド】
→ITサービスが再開するまでの2-3日間、一時的な措置としてITを使わずに手作業でビジネスが回るようにする
参考)まれにガキ的な解決方法になることもある
【相互協定】
→類似の技術力を使用する組織同士が合意し、非常時に助け合う方法。
参考)現在では、適用できるケースは少ない
サービスデリバリ
→5つのプロセスで構成され、プロセスごとに異なる役割と責任を持たせる。
5つのプロセス一覧)
・サービスレベル管理
・ITサービス財務管理
・可用性管理
・ITサービス継続性管理
・キャパシティ管理
インシデント管理
→サービス品質に満足しない、もしくわ満足できなくなる原因となる事象(イベント)それ以外に、イベント管理からエスカレーションされてきたイベントも、インシデント管理で取り扱う。
参考)問題の根本原因の解決、調査はしない。主に、サービスデスクが行う
重大なインシデント
→事業に深刻な中断を与える原因となるインシデントのこと
【インシデント管理プロセスの活動】
1、インシデントの識別
→障害や障害の予兆を早期に検出し、インシデント管理プロセスを開始できるように、主要なコンポーネントを可能な限り監視する
2、インシデントの記録
→すべてのインシデントを記録することが重要
参考)
・発生時刻、現象などの詳細を記録
・もれなく管理するには、なんらかのインシデント管理システムが必要
３、インシデントの分類(カテゴリ化)
→適切に分類すること
ex)ハードウェア、ソフトウェア、操作など
４、インシデントの優先度の決定
→分類→優先度。
参考)「緊急度」と「ビジネスへのインパクト」をもとに決定
5、初期診断
→既知のアラーDBを参照、ワークアラウンド(回避策)が明確になっているインシデントか調査。
サービスデスクで対応可か、サポート・グループにエスカレーションすべきか判断
6、インシデントのエスカレーション
→原因究明が困難なインシデントの場合
「1次サポート」から「2次、3次サポート」へとサポート・グループに「エスカレーション」する
7、調査と診断
→インシデントの詳細を調査、対応策を検討。
サービスを早期に復旧することなので、「対応策」は対処療法的な回避策
8、解決と復旧
→原因が判明したら、取り除くため復旧作業をする。
参考)専門家が必要なこともある。復旧までのスケジュールを吟味し、ユーザに伝えること必要。
9、インシデントのクローズ
→インシデントが解決・復旧しユーザが満足したら、クローズする
サービス・カタログ管理
→ITサービス・プロバイダが事業部門に提供しているITサービス(ビジネス部門が導入、利用可能なITサービス)の一覧を作成
ex)常に最新の状態になるよう維持
サービス・カタログ
→提供中のITサービスや、稼働環境への導入に向けて準備中のITサービスの詳細、ITサービスの特徴のようやく、顧客、保守担当者の詳細をサービス・カタログにリスト化しまとめる。
参考)顧客、ユーザが利用可能ITサービスだけをまとめたもの
ビジネス・サービス・カタログ
→顧客に提供されるITサービスの詳細をまとめたサービス・カタログ
参考)ITサービス・プロバイダと事業部門との間のコミュニケーションツールとして使用。
事業部門の担当者が理解できる用語を使用し記述する
技術サービス・カタログ
→事業部門にITサービスを提供するために必要となる、すべてのサービス(支援サービス)をまとめたサービス・カタログ
参考)顧客に公開しないため、技術用語使用
FSC(:Forward Schedule of Change)
→将来的な変更スケジュールという形で、顧客やユーザ、ITスタッフなどに配布し、情報を共有しておくべき
→あるプロセス及びその管理を外部委託すること
参考)アウトソースしたプロセスを確実にするとは
→外部委託したプロセスが正しく管理されていることを確実にすること
コーポレート(:corporate)
→企業の。組織の。
アプリケーション・サイジング
→アプリケーションが合意したサービス・レベルを確実に満たすために必要なリソースを見積もること
参考)キャパシティ管理プロセスの1つの活動として位置づけられる。
アプリケーションの性能要件を満たし、サービスの品質を維持するためには必要不可欠な活動
可用性管理
→事業と顧客に利益を提供できるように、費用対効果の高い方法。
ITサービス、ITインフラストラクチャ、サポートする組織の可用性を最適化、改善する
目標)通常のITサービスを維持する
手段)対障害弾力性のあるシステム、Back-upなどによるリスク低減手段と復旧戦略
期間)定められた瞬間 or 期間
目的)ITサービスを実行
注意)ITサービス継続性管理と区別すること
可用性(Availablilty)
→ユーザがITサービスを利用可能能力を表す
参考)システムダウンなど、利用不能時間が少ないこと＝可用性が高いと表現
計算式) 可用性(%)=合意済みサービス時間-停止時間/合意済みサービス時間*100(%)
段階的アプローチ
→新規サービスやサービス変更を一部のユーザに限定して展開する方法。ユーザ限定する
参考)その後、他のユーザにも同じ変更を繰り返し展開
プッシュ・アプローチ
→新規サービスやサービス変更を中央拠点から配信先に配信する方法
参考)配信されるタイミングをユーザは選択不可
ex)Windows-セキュリティパッチの自動更新
プル・アプローチ
→ユーザが選択した時点 or ユーザのPCやサーバの起動時に、中央拠点から持ってくる(プルする)展開方法。
【手作業のワークアラウンド】
→ITサービスが再開するまでの2-3日間、一時的な措置としてITを使わずに手作業でビジネスが回るようにする
参考)まれにガキ的な解決方法になることもある
【相互協定】
→類似の技術力を使用する組織同士が合意し、非常時に助け合う方法。
参考)現在では、適用できるケースは少ない
サービスデリバリ
→5つのプロセスで構成され、プロセスごとに異なる役割と責任を持たせる。
5つのプロセス一覧)
・サービスレベル管理
・ITサービス財務管理
・可用性管理
・ITサービス継続性管理
・キャパシティ管理
インシデント管理
→サービス品質に満足しない、もしくわ満足できなくなる原因となる事象(イベント)それ以外に、イベント管理からエスカレーションされてきたイベントも、インシデント管理で取り扱う。
参考)問題の根本原因の解決、調査はしない。主に、サービスデスクが行う
重大なインシデント
→事業に深刻な中断を与える原因となるインシデントのこと
【インシデント管理プロセスの活動】
1、インシデントの識別
→障害や障害の予兆を早期に検出し、インシデント管理プロセスを開始できるように、主要なコンポーネントを可能な限り監視する
2、インシデントの記録
→すべてのインシデントを記録することが重要
参考)
・発生時刻、現象などの詳細を記録
・もれなく管理するには、なんらかのインシデント管理システムが必要
３、インシデントの分類(カテゴリ化)
→適切に分類すること
ex)ハードウェア、ソフトウェア、操作など
４、インシデントの優先度の決定
→分類→優先度。
参考)「緊急度」と「ビジネスへのインパクト」をもとに決定
5、初期診断
→既知のアラーDBを参照、ワークアラウンド(回避策)が明確になっているインシデントか調査。
サービスデスクで対応可か、サポート・グループにエスカレーションすべきか判断
6、インシデントのエスカレーション
→原因究明が困難なインシデントの場合
「1次サポート」から「2次、3次サポート」へとサポート・グループに「エスカレーション」する
7、調査と診断
→インシデントの詳細を調査、対応策を検討。
サービスを早期に復旧することなので、「対応策」は対処療法的な回避策
8、解決と復旧
→原因が判明したら、取り除くため復旧作業をする。
参考)専門家が必要なこともある。復旧までのスケジュールを吟味し、ユーザに伝えること必要。
9、インシデントのクローズ
→インシデントが解決・復旧しユーザが満足したら、クローズする
サービス・カタログ管理
→ITサービス・プロバイダが事業部門に提供しているITサービス(ビジネス部門が導入、利用可能なITサービス)の一覧を作成
ex)常に最新の状態になるよう維持
サービス・カタログ
→提供中のITサービスや、稼働環境への導入に向けて準備中のITサービスの詳細、ITサービスの特徴のようやく、顧客、保守担当者の詳細をサービス・カタログにリスト化しまとめる。
参考)顧客、ユーザが利用可能ITサービスだけをまとめたもの
ビジネス・サービス・カタログ
→顧客に提供されるITサービスの詳細をまとめたサービス・カタログ
参考)ITサービス・プロバイダと事業部門との間のコミュニケーションツールとして使用。
事業部門の担当者が理解できる用語を使用し記述する
技術サービス・カタログ
→事業部門にITサービスを提供するために必要となる、すべてのサービス(支援サービス)をまとめたサービス・カタログ
参考)顧客に公開しないため、技術用語使用
FSC(:Forward Schedule of Change)
→将来的な変更スケジュールという形で、顧客やユーザ、ITスタッフなどに配布し、情報を共有しておくべき