5/27,5/29 ITILv3への道
システム監査規定
→システム監査の決まりを定めたもので、組織体の長(経営者など)が承認
ゴーイングコンサーン
→企業が永続的に事業を継続する(廃業しない)ことを前提とした会計上の考え方
顧客
→ITサービスのコストについて責任を持つ人
ユーザ
→ITサービスを使用する人
ITサービス・プロバイダ
→ITサービスを提供
ベンダ(製品を販売する会社)
→製品のメーカーや、販売代理店のこと
標準的な変更
→手順が決まっており、リスクの少ない変更
ex) 新人用にPC1台を追加するなど
緊急の変更
→ビジネスに大きな影響を与えており、早急に変更しなければならない変更
参)ITサービスの障害を復旧する場合のみ使用。
通常の変更
→通常の変更手順に従って行う変更(RFCを出して行う変更)
RFC(変更要求)：Request For Change
→サービス変更の要求、提案のこと
RFCには、変更の詳細が記述される。
参考)
・既知のエラーを取り除くために問題管理が提案するもの
・システムの変更に関わるさまざまなプロセスから作成される
主な項目)
・変更理由
・変更しない場合の影響
・変更対象である構成アイテムのver
*保守による変更という変更モデルなし
RFCという用語
→「インシデント管理」「サービス資産管理および構成管理」「問題管理」にも関係
説明)問題管理で識別された既知エラーを解決するための変更要求を意味する
CMDB：Configuration Management DataBase
→構成管理DB、構成アイテムを管理するDBのこと、CIの属性、他のCIとの関係を保存
参考)CIを中心よした構成情報を格納するが、それ以外に、そのCIとシステムとの関係も格納する。
検討)多種多様な要素が格納されるので、管理すべき対象の設置やD鮮度を保つ為の仕組みを検討する必要あり
デメリット)ツールだけに頼るとD鮮度に疑問がわくことがあるので、少なくとも、棚卸などのタイミングでCMDBをリフレッシュする仕組みを導入すべき
インシデント管理
→インシデントの受付から解決までの流れを管理。
参考)CMDBのupはしない
構成管理
→CMDBのupに責任を負う
問題管理
→インシデントの根本原因の検知、解決および予防を目標とする
リリース・ユニット(=リリースの単位)
→
・同時にリリースされるITサービス、ITインフラストラクチャの一部分
・構成ユニットをまとめたリリースする単位
ex)ソフトウェアのリリース・ユニットの場合。
大きい順に、システムレベル、アプリケーションレベル、モジュールレベルなどがあげられる
参考)リリースに必要な時間などを始め、様々な要素を十分に考慮することが大切
リリース
→ITサービスに対する許可された変更の集合体
リリース・パッケージ
→同時に複数の変更をリリースするために、複数の変更をまとめたもの
関連文書のコピー
→確定版ソフトウェアの保管庫(DSL)内に保管される
既知のエラー
→過去に発生したインシデント
参考)根本原因が判明し、対応策が特定されているインシデント
未知のインシデント
→問題としてインシデントを管理
イベント
→構成アイテムやITサービスが生成する状態の変更
段階的復旧(コールドスタンバイ)
→復旧用に場所だけを用意しておき、非常時には機器を持ち込んでシステムを再開する方法
中間的復旧(ウォームスタンバイ)
→復旧用に場所と機器を用意しておき、非常時にはDのBackupから復旧することでシステムを再開する方法
高速復旧(ホットスタンバイ)
→復旧用に場所、機器およびDを用意しておき、非常時にはDの同期をとることでシステムを再開する方法
即時的復旧(ホットスタンバイ)
→常にDの同期がとれたBackup-Cを用意し、非常時には即座にサービスの回復を実現する方法
ITサービス継続性管理
→ITシステムの中断に対する
復旧の為の戦略を復旧OPとして整理
参考)想定外のリスクに備え、リスク低減手段と復旧戦略により、迅速にITサービスを復旧する
需要管理
→サービスに対する顧客の需要を判断し、顧客の需要に見合うキャパシティを提供可にする
[オンライン処理と帳票出力処理を同じ時間帯に実行すると]
→リリース不足の発生が予想される
対策)同じ時間帯に実行するのではなく、異なる時間帯に実行することでリソース不足の解消や負荷を分散させることが期待
[変更管理の役割]
→
・RFCを受けて、変更を効率的かつ迅速に適用するための手順や手法を確立させる
・変更に関するさまざな計画をして、リソースの調整やコントロールを行う。
[リリース管理]
→変更にて承認された手順や手法に基づいて、変更が正しく行われることを保証
[変更に対して]
→変更管理が計画を立案
リリース管理が実施
サービスレベル管理
→合意されたサービスレベルが正しく保たれていることを管理するプロセス
ワークアラウンド
→未知のインシデントである問題に対する解決策
[大規模なワークアラウンド]
ex)P仕様の変更、パッケージソフトウェアのカスタマイズ
[シンプルなワークアラウンド]
ex)PCがフリーズした場合の再起動
サービス・カタログ
→ITサービスを明確にする
参考)顧客が理解できる表現でITサービスの説明を詳しく記述することが大切。
SLA(サービスレベル・アグリーメント)
→ITサービス・プロバイダと顧客との間での文書化されたITサービスレベルに関する合意。
SIP(サービス改善P)
→サービスレベルの改善を行うための各種活動のこと
BIA(ビジネス・インパクト分析)
→災害などによってITサービスが中断することによる事業へのインパクトを評価すること
問題管理
→インシデントの根本原因を究明して解決策を策定
可用性管理
→ITサービスの可用性を最適化、改善
サービスレベル管理
→ITサービス・プロバイダの能力を監視し、サービスレベルを維持、向上
機能的エスカレーション
→より専門的な知識を持つグループにインシデントを渡す
階層的エスカレーション
→一定時間が経過してもインシデントが解決できない場合などに、より上位のグループにインシデントを渡す。
FSC:(Forward Schedule of Change)
→将来的な変更スケジュール
PSA:(Projected Service Availability)
→サービスの予想可用性
CAB:(Change Advisory Board)
→変化・諮問委員会
サービス・ポートフォリオ
→ITサービス・プロバイダが管理しているすべてのサービス
詳細)計画中のサービス、稼働中のサービス、既に廃止されたサービス
[稼働中のサービス]
→サービス・カタログ
[既に廃止されたサービス]
→廃止済みサービス
サービス・パイプライン
→サービス・ポートフォリオで管理される計画中のサービス
サービストランジション
→サービスデザインで設定した
ITサービスを開発環境や本番環境へ導入。
＊サービス・ポートフォリオの構成要素ではない
SLAに直接関係する当事者
→
・スループット
・課金
・合意
通信サービスに関する専門的技術の記述
→SLAに関係なし
サービス・オーナ―
→ITサービスの提供について、ITサービス・プロバイダ内のサービスマネジメント役員に対する説明責任を負う者。
サービスレベル・マネージャ
→ITサービスの提供について、ITサービスを利用している顧客に対する説明責任を負う者。
インシデント管理
→
・受け付けたイベントの解決までの流れを管理
・発生したインシデントの根本原因を解明したり、調査したりすることはない。
・再発防止を検討することもない
顧客と直接交渉の場をもつのは
→サービスレベル管理
＊キャパシティ管理、情報セキュリティ管理、可用性管理は顧客と直接かかわりをもたない
サービス時間と延長に関する取り決め、サービスレベルに関する合意
→ITサービス・プロバイダと顧客との間で結ばれる
参考)結ばれた合意は、SLAの内容として記録。
キャパシティ管理
→必要なリソースとコストのバランス、需要と供給のバランスをとれる作業を行う
参考)最も高い費用対効果かつタイムリーな方法。
ITインフラストラクチャのキャパシティを、進化する事業要件に確実に適合させる
情報セキュリティ管理
→情報セキュリティがすべてのサービスとサービスマネジメントの活動において、確実に効率的に管理される
可用性管理
→費用対効果の高い方法で、ITサービス、ITインフラストラクチャ、サポートする組織の可用性を最適化、改善。
キャパシティ管理のサブプロセス
→事業キャパシティ管理、サービスキャパシティ管理、コンポーネント・キャパシティ管理の3つ
事業キャパシティ管理
→ビジネスのニーズと将来の事業計画を把握し、将来必要になるキャパシティの計画を立てる。
サービス・キャパシティ管理
→サービスのパフォーマンスを監視、分析、調整、報告し、サービス利用の概要とベースラインを確立、サービスに対する需要の管理を行う
コンポーネント・キャパシティ管理
→コンポーネント稼働率を監視、分析、実行、報告し、コンポーネントの仕様の概要とベースラインの確立を行う
インシデント管理のサブプロセス-分類と初期サポート
→原因・理由が明らかになっているインシデント
→分類と初期サポートで解決方法を提供
→空欄
→新しく発生したインシデント
問題管理
→リアクティブな側面
→プロアクティブな側面をもつ
リアクティブな問題管理
→発生した問題への対処を行うことから、事後の対応に重きが置かれる
プロアクティブな問題管理
→空欄
→システム監査の決まりを定めたもので、組織体の長(経営者など)が承認
ゴーイングコンサーン
→企業が永続的に事業を継続する(廃業しない)ことを前提とした会計上の考え方
顧客
→ITサービスのコストについて責任を持つ人
ユーザ
→ITサービスを使用する人
ITサービス・プロバイダ
→ITサービスを提供
ベンダ(製品を販売する会社)
→製品のメーカーや、販売代理店のこと
標準的な変更
→手順が決まっており、リスクの少ない変更
ex) 新人用にPC1台を追加するなど
緊急の変更
→ビジネスに大きな影響を与えており、早急に変更しなければならない変更
参)ITサービスの障害を復旧する場合のみ使用。
通常の変更
→通常の変更手順に従って行う変更(RFCを出して行う変更)
RFC(変更要求)：Request For Change
→サービス変更の要求、提案のこと
RFCには、変更の詳細が記述される。
参考)
・既知のエラーを取り除くために問題管理が提案するもの
・システムの変更に関わるさまざまなプロセスから作成される
主な項目)
・変更理由
・変更しない場合の影響
・変更対象である構成アイテムのver
*保守による変更という変更モデルなし
RFCという用語
→「インシデント管理」「サービス資産管理および構成管理」「問題管理」にも関係
説明)問題管理で識別された既知エラーを解決するための変更要求を意味する
CMDB：Configuration Management DataBase
→構成管理DB、構成アイテムを管理するDBのこと、CIの属性、他のCIとの関係を保存
参考)CIを中心よした構成情報を格納するが、それ以外に、そのCIとシステムとの関係も格納する。
検討)多種多様な要素が格納されるので、管理すべき対象の設置やD鮮度を保つ為の仕組みを検討する必要あり
デメリット)ツールだけに頼るとD鮮度に疑問がわくことがあるので、少なくとも、棚卸などのタイミングでCMDBをリフレッシュする仕組みを導入すべき
インシデント管理
→インシデントの受付から解決までの流れを管理。
参考)CMDBのupはしない
構成管理
→CMDBのupに責任を負う
問題管理
→インシデントの根本原因の検知、解決および予防を目標とする
リリース・ユニット(=リリースの単位)
→
・同時にリリースされるITサービス、ITインフラストラクチャの一部分
・構成ユニットをまとめたリリースする単位
ex)ソフトウェアのリリース・ユニットの場合。
大きい順に、システムレベル、アプリケーションレベル、モジュールレベルなどがあげられる
参考)リリースに必要な時間などを始め、様々な要素を十分に考慮することが大切
リリース
→ITサービスに対する許可された変更の集合体
リリース・パッケージ
→同時に複数の変更をリリースするために、複数の変更をまとめたもの
関連文書のコピー
→確定版ソフトウェアの保管庫(DSL)内に保管される
既知のエラー
→過去に発生したインシデント
参考)根本原因が判明し、対応策が特定されているインシデント
未知のインシデント
→問題としてインシデントを管理
イベント
→構成アイテムやITサービスが生成する状態の変更
段階的復旧(コールドスタンバイ)
→復旧用に場所だけを用意しておき、非常時には機器を持ち込んでシステムを再開する方法
中間的復旧(ウォームスタンバイ)
→復旧用に場所と機器を用意しておき、非常時にはDのBackupから復旧することでシステムを再開する方法
高速復旧(ホットスタンバイ)
→復旧用に場所、機器およびDを用意しておき、非常時にはDの同期をとることでシステムを再開する方法
即時的復旧(ホットスタンバイ)
→常にDの同期がとれたBackup-Cを用意し、非常時には即座にサービスの回復を実現する方法
ITサービス継続性管理
→ITシステムの中断に対する
復旧の為の戦略を復旧OPとして整理
参考)想定外のリスクに備え、リスク低減手段と復旧戦略により、迅速にITサービスを復旧する
需要管理
→サービスに対する顧客の需要を判断し、顧客の需要に見合うキャパシティを提供可にする
[オンライン処理と帳票出力処理を同じ時間帯に実行すると]
→リリース不足の発生が予想される
対策)同じ時間帯に実行するのではなく、異なる時間帯に実行することでリソース不足の解消や負荷を分散させることが期待
[変更管理の役割]
→
・RFCを受けて、変更を効率的かつ迅速に適用するための手順や手法を確立させる
・変更に関するさまざな計画をして、リソースの調整やコントロールを行う。
[リリース管理]
→変更にて承認された手順や手法に基づいて、変更が正しく行われることを保証
[変更に対して]
→変更管理が計画を立案
リリース管理が実施
サービスレベル管理
→合意されたサービスレベルが正しく保たれていることを管理するプロセス
ワークアラウンド
→未知のインシデントである問題に対する解決策
[大規模なワークアラウンド]
ex)P仕様の変更、パッケージソフトウェアのカスタマイズ
[シンプルなワークアラウンド]
ex)PCがフリーズした場合の再起動
サービス・カタログ
→ITサービスを明確にする
参考)顧客が理解できる表現でITサービスの説明を詳しく記述することが大切。
SLA(サービスレベル・アグリーメント)
→ITサービス・プロバイダと顧客との間での文書化されたITサービスレベルに関する合意。
SIP(サービス改善P)
→サービスレベルの改善を行うための各種活動のこと
BIA(ビジネス・インパクト分析)
→災害などによってITサービスが中断することによる事業へのインパクトを評価すること
問題管理
→インシデントの根本原因を究明して解決策を策定
可用性管理
→ITサービスの可用性を最適化、改善
サービスレベル管理
→ITサービス・プロバイダの能力を監視し、サービスレベルを維持、向上
機能的エスカレーション
→より専門的な知識を持つグループにインシデントを渡す
階層的エスカレーション
→一定時間が経過してもインシデントが解決できない場合などに、より上位のグループにインシデントを渡す。
FSC:(Forward Schedule of Change)
→将来的な変更スケジュール
PSA:(Projected Service Availability)
→サービスの予想可用性
CAB:(Change Advisory Board)
→変化・諮問委員会
サービス・ポートフォリオ
→ITサービス・プロバイダが管理しているすべてのサービス
詳細)計画中のサービス、稼働中のサービス、既に廃止されたサービス
[稼働中のサービス]
→サービス・カタログ
[既に廃止されたサービス]
→廃止済みサービス
サービス・パイプライン
→サービス・ポートフォリオで管理される計画中のサービス
サービストランジション
→サービスデザインで設定した
ITサービスを開発環境や本番環境へ導入。
＊サービス・ポートフォリオの構成要素ではない
SLAに直接関係する当事者
→
・スループット
・課金
・合意
通信サービスに関する専門的技術の記述
→SLAに関係なし
サービス・オーナ―
→ITサービスの提供について、ITサービス・プロバイダ内のサービスマネジメント役員に対する説明責任を負う者。
サービスレベル・マネージャ
→ITサービスの提供について、ITサービスを利用している顧客に対する説明責任を負う者。
インシデント管理
→
・受け付けたイベントの解決までの流れを管理
・発生したインシデントの根本原因を解明したり、調査したりすることはない。
・再発防止を検討することもない
顧客と直接交渉の場をもつのは
→サービスレベル管理
＊キャパシティ管理、情報セキュリティ管理、可用性管理は顧客と直接かかわりをもたない
サービス時間と延長に関する取り決め、サービスレベルに関する合意
→ITサービス・プロバイダと顧客との間で結ばれる
参考)結ばれた合意は、SLAの内容として記録。
キャパシティ管理
→必要なリソースとコストのバランス、需要と供給のバランスをとれる作業を行う
参考)最も高い費用対効果かつタイムリーな方法。
ITインフラストラクチャのキャパシティを、進化する事業要件に確実に適合させる
情報セキュリティ管理
→情報セキュリティがすべてのサービスとサービスマネジメントの活動において、確実に効率的に管理される
可用性管理
→費用対効果の高い方法で、ITサービス、ITインフラストラクチャ、サポートする組織の可用性を最適化、改善。
キャパシティ管理のサブプロセス
→事業キャパシティ管理、サービスキャパシティ管理、コンポーネント・キャパシティ管理の3つ
事業キャパシティ管理
→ビジネスのニーズと将来の事業計画を把握し、将来必要になるキャパシティの計画を立てる。
サービス・キャパシティ管理
→サービスのパフォーマンスを監視、分析、調整、報告し、サービス利用の概要とベースラインを確立、サービスに対する需要の管理を行う
コンポーネント・キャパシティ管理
→コンポーネント稼働率を監視、分析、実行、報告し、コンポーネントの仕様の概要とベースラインの確立を行う
インシデント管理のサブプロセス-分類と初期サポート
→原因・理由が明らかになっているインシデント
→分類と初期サポートで解決方法を提供
→空欄
→新しく発生したインシデント
問題管理
→リアクティブな側面
→プロアクティブな側面をもつ
リアクティブな問題管理
→発生した問題への対処を行うことから、事後の対応に重きが置かれる
プロアクティブな問題管理
→空欄