5/31 ITILv3への道
[構成アイテム(CI)の状態の把握]
→構成のスタータスによって行う。
存在するか否かを管理し、管理コストを低減させることが可能
シリアル番号
→個々の構成アイテムを特定する要素
所有者
→構成アイテムの所有者を示す要素
設置場所
→構成アイテムが設置されている場所
構成管理システム
→
・構成アイテムの属性を保持
・複数のレイヤで構成
・構成アイテムは、すべて構成管理システムで保持
・他システムへ情報を提供
[サービスデスク-質の面で分類]
→
・非スキル型サービスデスク
・スキル型サービスデスク
・エキスパートサービスデスク
[サービスデスク-組織の場所の面から分類]
→
・ローカル・サービスデスク
・中央サービスデスク
・ヴァーチャル・サービスデスク
ローカルサービスデスク
→ユーザの拠点内あるいはユーザに比較的近いところで業務を行うサービスデスク
中央サービスデスク
→複数のユーザサイトからの連絡を受けるために、物理的に中心と位置づけられる場所に設置され業務を行うサービスデスク
ヴァーチャル・サービスデスク
→物理的に分散して配置されているサービスデスクを、統合された1つのサービスデスクとして機能を提供するサービスデスク
リスク低減手段
→リスクを評価、事業やITサービスの復旧を妨げる潜在的なリスクを低減すること
対応)リスクを把握し、評価されたリスクを低減するための計画を立てることが重要
具体的)HDDの損傷に備えるBackUpの所得、電源供給の中断に備える電源供給装置の設置など
リスク評価
→脅威のレベル、および組織がその脅威に対して脆弱である範囲を評価すること
復旧OP
→サービスの中断に対応するための戦略
事業継続性管理
→事業の深刻なインパクトを与える可能性があるリスクを管理
サービスVモデル
[左側]
→
・事業・ビジネス要件の定義
・サービス要件の定義
・サービスの設計
・サービス・リリースの設計 が位置づけられる。
[右側]
→左側の各作業に対するテストが位置づけられる。
[事業・ビジネス要件の定義]
→サービス提供、パッケージ、ソリューションの検証
[サービス要件の定義]
→サービス受け入れテスト
サービスオペレーション準備実況テスト
→サービスの設計に対応するテスト
サービス・リリース・パッケージのテスト
→サービス・リリースの設計に対応するテスト
ビルをまたがるサーバの移設
→変更管理の承認が必要
外部委託契約(UC)
→ITサービス・プロバイダと外部サプライヤとの間での取り決め
参考)社内の関連部門との間で契約する
OLAに相当。
OLA(オペレーショナルレベル・アグリーメント)
→SLAを実現するための内部のIT部門との契約
[新たなるアプリケーションのリリースを調整]
→変更管理
可用性管理の目的
→ビジネスニーズを満足させ、事業と顧客に利益を提供できるように、費用対効果の高い方法。
参考)ITサービス・ITインフラストラクチャなどの可用性を改善・最適化すること
ex)運用管理ツールの障害の検知時間を短くする
可用性管理の活動
→BackUPの所得やシステムの二重化など日常に障害に備える対策
[ユーザがサービスを利用できる能力を表す指標]
→可用性
[信頼性]
→ITサービス、ITサービスを提供しているITインフラストラクチャを構成する個々のコンポネート、構成アイテムがどの程度故障しにくいかを示す指標
[可用性]
→ITサービス、コンポーネント、構成アイテムが必要とされたときに、合意された機能を実行する能力
[保守性]
→ITインフラストラクチャやコンポーネントの運用状態の維持or運用状態への回復に対する能力
[サービス性]
→サードパーティやサプライヤが契約条件を満たす能力
7ステップの改善プロセス
→ITサービスの提供先の事業戦略やビジョンによって推進され、意思決定のフレームワークとして把握される必要あり
参考)
測定対象の定義→測定できる内容の定義→Dの収集→Dの処理→Dの分析→情報の提示活動→是正措置の実施
[最初の改善ステップ]
→理想的環境において、事業にとって重要となる測定対象を決定すること
[ITサービス・プロバイダとSLAを結ぶ際の利用者側の責任者]
→顧客
FSC:Forward Schedule of Change
→将来的な変更スケジュール
PSA:Projected Service Availabilty
→サービスの予想可用性
CAB:Changed Advisory Board
→変更諮問委員会
アクセス管理
→
・アクセスする権利を持つユーザだけがITサービスを利用できるように、IDや権限などを適切にコントロールプロセス。
・サービスデザインで定めた方針に従い、ITサービスを利用する権限をユーザに割り当てる
参考)ユーザがアクセスできる資産(D、ITインフラストラクチャ)を限定することが可。
メリット)
・資産の機密性、完全性、可用性を維持
・ユーザに対するアクセス制御を行うので、内部統制とも密接な関係
イベント管理
→ITサービスの提供に必要なサーバ、アプリケーションなどから通知されるすべてのイベントを監視
参考)ITサービスに悪影響を及ぼすイベントが発生した場合、イベント管理はインシデント管理プロセスへのエスカレーションなどの対応をとる。
問題管理
→インシデント管理からエスカレーションされたインシデントやサービスデスク解決できなかったインシデントの詳細を受け、状況を整理し、新規に発生した問題なのか、既知のエラーなのかを判別する
参考)調査する。既知のエラーの場合、既知であるのになぜインシデントが発生したのかという観点などから、再発防止の為に検討、情報提供する
要求実現
→PCの設置、OSのユーザ追加、プリントのトナー交換、パスワードのリセット依頼のような、手順書を作成すれば誰でも作業できるリスクの小さい作業をサービス要求として処理。
DSL:Definitive Software Library
→確定版ソフトウェアの保管庫。システムの損傷やシステムの変化に備え、リリースした構成アイテム(CI）のコピーを保管した安全な領域のこと
KEDB:(Known Error DataBase)
→既知のエラーDB
SCD:(Supplier Contracts DataBase)
→サプライヤ契約DB
[可用性管理の活動]
→計画立案と監視
参考)監視によって、サービスの合意の検証問題の解決、改善提案の重要な根拠が得られる
リスク評価
→脅威のレベルと脅威に対する脆弱性を評価
ビジネス・インパクト分析
→ITサービスが中断することによる事業へのインパクトを定量化する
事業継続性管理
→事業に深刻なインパクトを与える可能性があるリスクを管理
RACIモデル
→役割と責任を定義するために使用されるモデル
参考)役割を決める場合、場当たり的に役割を決めるのではなく、事前に明確にしておくことが重要
メリット)迅速に業務遂行可
RACI
Reaponsible(実行責任者)
→業務の遂行に責任をもつ人物
参考)1人or複数の人が担う
Accountable(説明責任者)
→個々の活動の説明責任者
参考)1人のみ
Consulted(協議対象)
→相談を受け、意見を求められる人物
参考)複数の人
Informed(通知対象)
→進捗状況についてnew情報を常に受け取る人物
参考)複数の人
課金
→投資したコストや運用に必要となるコストを、SLAに基づいて顧客に請求すること
参考)
[ITサービスを提供する側]
→SLAを意識したITサービスの維持に対する責任感が生じる。
[ITサービスを受ける側]
→参加意識が生まれるものと期待される
財務管理
→課金、会計業務、予算業務などが責任下に位置つけられる
コンポーネント・キャパシティ管理
→・コンポーネント稼動率を監視、分析、実行、報告し、コンポーネントの使用率の概要とベースラインの確立を行う
・構成アイテム(コンポーネント)のキャパシティ、パフォーマンスを把握することを責務とする
参考)・キャパシティ計画にしようするために、Dを収集、記録、分析する
コンポーネント
→構成アイテム(CI)
構成アイテム
→ITインフラストラクチャを構成する各コンポーネントを管理
ITインフラストラクチャ
→「CPU利用率」「メモリ使用量」
・多くの企業で管理ツールが利用
MoSCow分析
→SDツールの選定時、ツールが要件を満たすかどうかを検討するためにSDツールの要件をカテゴリ化する方法
M：持たなければならない要件(MUST)
→この要件が欠落するとツールの価値がなくなってしまうような、主要な要件
S：可能であれば持つことが推奨される要件(SHOULD)
→可能であれば持つことが推奨される重要な要件
参考)この要件を満たさなくてもツールには十分な価値がある
C：他に影響を与えなければ持つことが可能な要件(COULD)
→要件を提供するためのコストや時間がかからなければ持っていた方がよい要件
W：現在は不要であるが、将来的には持ちたい要件(WOULD)
→将来に必要になる可能性がある要件ですが、現在は必要とされていない要件
RFC(変更要求)
→さまざまなプロセスから提出可能
[3つのプロセスは変更要求を提出しません！]
→変更管理、構成管理、リリース管理
[リアクティブな問題管理]
→問題の根本的な原因を究明して問題を解決し、問題の再発を防止する活動
参考)問題のコントロールとエラーのコントロールを行う
[変更管理の7つR]
→変更を評価、アセスメントするときに考慮すべき内容を質問形式で並べたもの
参考)7つの質問に答えることによって、変更に失敗した時のビジネス(事業部門)へのインパクト(影響度)を確認可
[Raised]
→変更を要請したのは誰か？
[Reason]
→変更の理由は何か？
[Return]
→変更の成果として要求されるものは何か？
[Risk]
→変更に伴うリスクは何か？
[Resource]
→変更を実施するために必要なリソースは何か？
[Responsible]
→構築、テスト、実装の責任は誰にあるか？
[Relationship]
→この変更と他の変更の関係は何か？
→構成のスタータスによって行う。
存在するか否かを管理し、管理コストを低減させることが可能
シリアル番号
→個々の構成アイテムを特定する要素
所有者
→構成アイテムの所有者を示す要素
設置場所
→構成アイテムが設置されている場所
構成管理システム
→
・構成アイテムの属性を保持
・複数のレイヤで構成
・構成アイテムは、すべて構成管理システムで保持
・他システムへ情報を提供
[サービスデスク-質の面で分類]
→
・非スキル型サービスデスク
・スキル型サービスデスク
・エキスパートサービスデスク
[サービスデスク-組織の場所の面から分類]
→
・ローカル・サービスデスク
・中央サービスデスク
・ヴァーチャル・サービスデスク
ローカルサービスデスク
→ユーザの拠点内あるいはユーザに比較的近いところで業務を行うサービスデスク
中央サービスデスク
→複数のユーザサイトからの連絡を受けるために、物理的に中心と位置づけられる場所に設置され業務を行うサービスデスク
ヴァーチャル・サービスデスク
→物理的に分散して配置されているサービスデスクを、統合された1つのサービスデスクとして機能を提供するサービスデスク
リスク低減手段
→リスクを評価、事業やITサービスの復旧を妨げる潜在的なリスクを低減すること
対応)リスクを把握し、評価されたリスクを低減するための計画を立てることが重要
具体的)HDDの損傷に備えるBackUpの所得、電源供給の中断に備える電源供給装置の設置など
リスク評価
→脅威のレベル、および組織がその脅威に対して脆弱である範囲を評価すること
復旧OP
→サービスの中断に対応するための戦略
事業継続性管理
→事業の深刻なインパクトを与える可能性があるリスクを管理
サービスVモデル
[左側]
→
・事業・ビジネス要件の定義
・サービス要件の定義
・サービスの設計
・サービス・リリースの設計 が位置づけられる。
[右側]
→左側の各作業に対するテストが位置づけられる。
[事業・ビジネス要件の定義]
→サービス提供、パッケージ、ソリューションの検証
[サービス要件の定義]
→サービス受け入れテスト
サービスオペレーション準備実況テスト
→サービスの設計に対応するテスト
サービス・リリース・パッケージのテスト
→サービス・リリースの設計に対応するテスト
ビルをまたがるサーバの移設
→変更管理の承認が必要
外部委託契約(UC)
→ITサービス・プロバイダと外部サプライヤとの間での取り決め
参考)社内の関連部門との間で契約する
OLAに相当。
OLA(オペレーショナルレベル・アグリーメント)
→SLAを実現するための内部のIT部門との契約
[新たなるアプリケーションのリリースを調整]
→変更管理
可用性管理の目的
→ビジネスニーズを満足させ、事業と顧客に利益を提供できるように、費用対効果の高い方法。
参考)ITサービス・ITインフラストラクチャなどの可用性を改善・最適化すること
ex)運用管理ツールの障害の検知時間を短くする
可用性管理の活動
→BackUPの所得やシステムの二重化など日常に障害に備える対策
[ユーザがサービスを利用できる能力を表す指標]
→可用性
[信頼性]
→ITサービス、ITサービスを提供しているITインフラストラクチャを構成する個々のコンポネート、構成アイテムがどの程度故障しにくいかを示す指標
[可用性]
→ITサービス、コンポーネント、構成アイテムが必要とされたときに、合意された機能を実行する能力
[保守性]
→ITインフラストラクチャやコンポーネントの運用状態の維持or運用状態への回復に対する能力
[サービス性]
→サードパーティやサプライヤが契約条件を満たす能力
7ステップの改善プロセス
→ITサービスの提供先の事業戦略やビジョンによって推進され、意思決定のフレームワークとして把握される必要あり
参考)
測定対象の定義→測定できる内容の定義→Dの収集→Dの処理→Dの分析→情報の提示活動→是正措置の実施
[最初の改善ステップ]
→理想的環境において、事業にとって重要となる測定対象を決定すること
[ITサービス・プロバイダとSLAを結ぶ際の利用者側の責任者]
→顧客
FSC:Forward Schedule of Change
→将来的な変更スケジュール
PSA:Projected Service Availabilty
→サービスの予想可用性
CAB:Changed Advisory Board
→変更諮問委員会
アクセス管理
→
・アクセスする権利を持つユーザだけがITサービスを利用できるように、IDや権限などを適切にコントロールプロセス。
・サービスデザインで定めた方針に従い、ITサービスを利用する権限をユーザに割り当てる
参考)ユーザがアクセスできる資産(D、ITインフラストラクチャ)を限定することが可。
メリット)
・資産の機密性、完全性、可用性を維持
・ユーザに対するアクセス制御を行うので、内部統制とも密接な関係
イベント管理
→ITサービスの提供に必要なサーバ、アプリケーションなどから通知されるすべてのイベントを監視
参考)ITサービスに悪影響を及ぼすイベントが発生した場合、イベント管理はインシデント管理プロセスへのエスカレーションなどの対応をとる。
問題管理
→インシデント管理からエスカレーションされたインシデントやサービスデスク解決できなかったインシデントの詳細を受け、状況を整理し、新規に発生した問題なのか、既知のエラーなのかを判別する
参考)調査する。既知のエラーの場合、既知であるのになぜインシデントが発生したのかという観点などから、再発防止の為に検討、情報提供する
要求実現
→PCの設置、OSのユーザ追加、プリントのトナー交換、パスワードのリセット依頼のような、手順書を作成すれば誰でも作業できるリスクの小さい作業をサービス要求として処理。
DSL:Definitive Software Library
→確定版ソフトウェアの保管庫。システムの損傷やシステムの変化に備え、リリースした構成アイテム(CI）のコピーを保管した安全な領域のこと
KEDB:(Known Error DataBase)
→既知のエラーDB
SCD:(Supplier Contracts DataBase)
→サプライヤ契約DB
[可用性管理の活動]
→計画立案と監視
参考)監視によって、サービスの合意の検証問題の解決、改善提案の重要な根拠が得られる
リスク評価
→脅威のレベルと脅威に対する脆弱性を評価
ビジネス・インパクト分析
→ITサービスが中断することによる事業へのインパクトを定量化する
事業継続性管理
→事業に深刻なインパクトを与える可能性があるリスクを管理
RACIモデル
→役割と責任を定義するために使用されるモデル
参考)役割を決める場合、場当たり的に役割を決めるのではなく、事前に明確にしておくことが重要
メリット)迅速に業務遂行可
RACI
Reaponsible(実行責任者)
→業務の遂行に責任をもつ人物
参考)1人or複数の人が担う
Accountable(説明責任者)
→個々の活動の説明責任者
参考)1人のみ
Consulted(協議対象)
→相談を受け、意見を求められる人物
参考)複数の人
Informed(通知対象)
→進捗状況についてnew情報を常に受け取る人物
参考)複数の人
課金
→投資したコストや運用に必要となるコストを、SLAに基づいて顧客に請求すること
参考)
[ITサービスを提供する側]
→SLAを意識したITサービスの維持に対する責任感が生じる。
[ITサービスを受ける側]
→参加意識が生まれるものと期待される
財務管理
→課金、会計業務、予算業務などが責任下に位置つけられる
コンポーネント・キャパシティ管理
→・コンポーネント稼動率を監視、分析、実行、報告し、コンポーネントの使用率の概要とベースラインの確立を行う
・構成アイテム(コンポーネント)のキャパシティ、パフォーマンスを把握することを責務とする
参考)・キャパシティ計画にしようするために、Dを収集、記録、分析する
コンポーネント
→構成アイテム(CI)
構成アイテム
→ITインフラストラクチャを構成する各コンポーネントを管理
ITインフラストラクチャ
→「CPU利用率」「メモリ使用量」
・多くの企業で管理ツールが利用
MoSCow分析
→SDツールの選定時、ツールが要件を満たすかどうかを検討するためにSDツールの要件をカテゴリ化する方法
M：持たなければならない要件(MUST)
→この要件が欠落するとツールの価値がなくなってしまうような、主要な要件
S：可能であれば持つことが推奨される要件(SHOULD)
→可能であれば持つことが推奨される重要な要件
参考)この要件を満たさなくてもツールには十分な価値がある
C：他に影響を与えなければ持つことが可能な要件(COULD)
→要件を提供するためのコストや時間がかからなければ持っていた方がよい要件
W：現在は不要であるが、将来的には持ちたい要件(WOULD)
→将来に必要になる可能性がある要件ですが、現在は必要とされていない要件
RFC(変更要求)
→さまざまなプロセスから提出可能
[3つのプロセスは変更要求を提出しません！]
→変更管理、構成管理、リリース管理
[リアクティブな問題管理]
→問題の根本的な原因を究明して問題を解決し、問題の再発を防止する活動
参考)問題のコントロールとエラーのコントロールを行う
[変更管理の7つR]
→変更を評価、アセスメントするときに考慮すべき内容を質問形式で並べたもの
参考)7つの質問に答えることによって、変更に失敗した時のビジネス(事業部門)へのインパクト(影響度)を確認可
[Raised]
→変更を要請したのは誰か？
[Reason]
→変更の理由は何か？
[Return]
→変更の成果として要求されるものは何か？
[Risk]
→変更に伴うリスクは何か？
[Resource]
→変更を実施するために必要なリソースは何か？
[Responsible]
→構築、テスト、実装の責任は誰にあるか？
[Relationship]
→この変更と他の変更の関係は何か？