7/4 ITILｖ３への道
サービス資産管理および構成管理
→ITサービスの継続的な運用のためには欠かせないプロセス
DSLの格納先
→リポジトリ、共有ファイルサーバ、物理的なロッカーなど
CMDB
→CIの属性、他のCIとの関係が保存
ポイント)CMDBに加え、Dの精度を維持する仕組みを導入
CMS
→ITサービス・プロバイダが保持する構成Dの管理に使用、
一連のツール、DBなどの総称。
構成Dの管理に使用するツール、DBのこと
参考)CMDBはCMSに含まれる
参考2)情報だけでなく、インシデント、問題、既知のエラー、変更、リリースの情報も含む
サービスオペレーション
→ITサービスに関する問い合わせを受け付けたり、障害に対処するなどの活動を行い、
合意済みのレベルで顧客やユーザにITサービスを提供可にする
IT運用管理
→合意レベルのITサービスを供給しサポートするために
ITインフラストラクチャを継続して維持、管理するそしき
技術管理
→ITインフラストラクチャを管理するのに十分な知識とスキルを持った組織
アプリケーション管理
→アプリケーションを管理するのに十分な知識とスキルを持った組織
内部的なIT視点
→ITサービスを提供するためにITコンポーネントやITシステムが
どのように管理されているか焦点をあてること。
参考)重視すると、ITサービスが事業部門に与える成果(最終結果)を考慮しなくなり、
事業部門の要件を満たせなくなる
外部的な事業観点
→ITサービスを事業部門がどのように使用するかに焦点をあてること
参考)どのようなITコンポーネントやシステムを使用してITサービスを
提供できるのかについて考えなくなり、実際には実現できない機能の提供を顧客と約束することになる。
イベント
→CIやITサービスの管理にとって重要性のある状態の変更のこと。
参考)ITサービス、CI、モニタリング・ツールなどにより生成。
→情報、警告、例外の3種類に分類される属性をもつころが推奨される。
参考)情報はどのような対処も不要なイベント、
警告は何らかの理由により現在の状態に注意を払う必要があるイベント。
例外は、正常に運用できていないことを意味するイベント
アラート
→人に対して通知され、人の介入を必要とする
インシデント管理
→ユーザから、伝達されたイベント以外に、
運用管理を行うシステムからの報告や、イベント管理からエスカレーションされてきた
イベントについて取り扱う。
→インシデントの受付から解決までの流れを管理することが主たるタスクになる。
参考)問題の根本原因の解決、調査はしない。
インシデント
→サービスデスク経由でユーザから直接伝達されたイベント、イベント管理ツールからのエスカレーション、技術スタッフによる記録から登録
参考)ユーザが気づかないような障害もインシデントとして登録。
インシデント・モデル
→インシデントが再発したときに実施する事前に定義した処置の方法のこと
参考)マニュアル
参考2)重大なインシデントに対しても用意する。
インシデント管理プロセスの解決
→ファースト
→インシデントの識別
参考)主要なコンポーネントは可能なかぎりすべて監視する
参考2)インシデントが解決し、サービスが復旧したあと、問い合わせしてきた人が満足したらインシデントをクローズ可
優先度
→インシデントの緊急度と、インシデントのインパクトの両方を考慮して決定される指標。
優先度が高いインシデント
→インパクトが大きく、かつ緊急度が高いインシデントであっても、インシデント解決のための工数が、非現実的な大きなものであれば場合より優先度を低くすることになる
サービス要求
→発生頻度が高いものの、低リスク低コストであるような小さな変更。
参考)サービスデスクorインシデント管理で処理
要求モデル
→サービス要求を処理するために事前に定義した処理の方法。
参考)サービス要求は頻繁に繰り返される作業のため事前に定義
問題管理
→インシデントの根本原因の検知と、解決および予防を目的とするプロセス
既知のエラー
→すでに原因が判明しており、対応策が特定されているインシデントのこと
参考)ワークアラウンドが識別された問題と考えること可
リアクティブな問題管理
→サービスオペレーションで開始されるが、CSIの一部として推進
問題管理のフロー
→ファースト：問題を検出
セカンド：問題の記録
参考)インシデント管理と同様に、問題に関連する、すべての詳細情報を記録
→問題がクローズしたあとに重大な問題についてレビューを実施し、適切に実施された項目、実施されなかった項目、改善項目、再発防止方法などを確認。
参考)重大な問題のレビューが終了した時点で、問題管理のフローは終了。
問題管理
→エスカレーションした変更要求が実施されるまで、進捗状態を監視
→問題をハードウェアに関するもの、ソフトウェアに関するもの、操作に関するものなどに分類。
参考)問題はインシデント管理と同じ基準に従い分類
アクセス
→ITサービスの機能やDをユーザが利用できる範囲のことを指す。
アクセス管理
→誰がどのITサービスにアクセスできるかを決定するのではない
参考)誰がどのITサービスにアクセス可 決定するのは、Sdの情報セキュリティ管理、可用性管理。
参考2)情報セキュリティ管理、可用性管理で決定した方針、規制をもとに、ITサービスを利用する権限をユーザに割り当てる
ディレクトリ・サービス
→アクセスや権限を管理するためのツール
単一窓口
→必ずしも物理的な拠点を1ヶ所におく必要はない
IT組織全体の調整
→サービスデスクが、円滑なコミュニケーションを維持しつつ、ユーザの利益になるよう、ITサービス・プロバイダが持つ組織およびプロセスの活動を調整すること。
参考)サービスデスクは、各部門の活動を調整する
中央サービスデスク
→メリット)情報を集約しやすい
デメリット)ユーザから物理的に話離されているため、ユーザの意見を肌で感じられない
ex)火災など
インシデントのオーナシップ
→インシデントを受け付けたサービスデスクが保有
ex)インシデントをエスカレーションするべき場合も、最終的にインシデントがクローズするまでサービスデスクが責任を持って追跡・管理することになる
ユーザおよびITスタッフとコミュニケーション
→インシデントを円滑に解決に導くために、ユーザや必要な部門と接点を持つこと。
参考)ユーザとの直接的な接点、あるいはエスカレーション先との連携などにおいて、効果的なコミュニケーションをとる必要あり
技術管理
→ITインフラストラクチャの運用を行うのに必要な技術力やリリースを提供する組織
参考)ITインフラストラクチャの設計、ITインフラストラクチャの保守、障害発生時のサポートなどの活動を行う
参考2）システムの大規模化に伴い、単一の部門やグループとするのではなく、必要となる基準に応じた複数のチームで分業する
→ITサービスの継続的な運用のためには欠かせないプロセス
DSLの格納先
→リポジトリ、共有ファイルサーバ、物理的なロッカーなど
CMDB
→CIの属性、他のCIとの関係が保存
ポイント)CMDBに加え、Dの精度を維持する仕組みを導入
CMS
→ITサービス・プロバイダが保持する構成Dの管理に使用、
一連のツール、DBなどの総称。
構成Dの管理に使用するツール、DBのこと
参考)CMDBはCMSに含まれる
参考2)情報だけでなく、インシデント、問題、既知のエラー、変更、リリースの情報も含む
サービスオペレーション
→ITサービスに関する問い合わせを受け付けたり、障害に対処するなどの活動を行い、
合意済みのレベルで顧客やユーザにITサービスを提供可にする
IT運用管理
→合意レベルのITサービスを供給しサポートするために
ITインフラストラクチャを継続して維持、管理するそしき
技術管理
→ITインフラストラクチャを管理するのに十分な知識とスキルを持った組織
アプリケーション管理
→アプリケーションを管理するのに十分な知識とスキルを持った組織
内部的なIT視点
→ITサービスを提供するためにITコンポーネントやITシステムが
どのように管理されているか焦点をあてること。
参考)重視すると、ITサービスが事業部門に与える成果(最終結果)を考慮しなくなり、
事業部門の要件を満たせなくなる
外部的な事業観点
→ITサービスを事業部門がどのように使用するかに焦点をあてること
参考)どのようなITコンポーネントやシステムを使用してITサービスを
提供できるのかについて考えなくなり、実際には実現できない機能の提供を顧客と約束することになる。
イベント
→CIやITサービスの管理にとって重要性のある状態の変更のこと。
参考)ITサービス、CI、モニタリング・ツールなどにより生成。
→情報、警告、例外の3種類に分類される属性をもつころが推奨される。
参考)情報はどのような対処も不要なイベント、
警告は何らかの理由により現在の状態に注意を払う必要があるイベント。
例外は、正常に運用できていないことを意味するイベント
アラート
→人に対して通知され、人の介入を必要とする
インシデント管理
→ユーザから、伝達されたイベント以外に、
運用管理を行うシステムからの報告や、イベント管理からエスカレーションされてきた
イベントについて取り扱う。
→インシデントの受付から解決までの流れを管理することが主たるタスクになる。
参考)問題の根本原因の解決、調査はしない。
インシデント
→サービスデスク経由でユーザから直接伝達されたイベント、イベント管理ツールからのエスカレーション、技術スタッフによる記録から登録
参考)ユーザが気づかないような障害もインシデントとして登録。
インシデント・モデル
→インシデントが再発したときに実施する事前に定義した処置の方法のこと
参考)マニュアル
参考2)重大なインシデントに対しても用意する。
インシデント管理プロセスの解決
→ファースト
→インシデントの識別
参考)主要なコンポーネントは可能なかぎりすべて監視する
参考2)インシデントが解決し、サービスが復旧したあと、問い合わせしてきた人が満足したらインシデントをクローズ可
優先度
→インシデントの緊急度と、インシデントのインパクトの両方を考慮して決定される指標。
優先度が高いインシデント
→インパクトが大きく、かつ緊急度が高いインシデントであっても、インシデント解決のための工数が、非現実的な大きなものであれば場合より優先度を低くすることになる
サービス要求
→発生頻度が高いものの、低リスク低コストであるような小さな変更。
参考)サービスデスクorインシデント管理で処理
要求モデル
→サービス要求を処理するために事前に定義した処理の方法。
参考)サービス要求は頻繁に繰り返される作業のため事前に定義
問題管理
→インシデントの根本原因の検知と、解決および予防を目的とするプロセス
既知のエラー
→すでに原因が判明しており、対応策が特定されているインシデントのこと
参考)ワークアラウンドが識別された問題と考えること可
リアクティブな問題管理
→サービスオペレーションで開始されるが、CSIの一部として推進
問題管理のフロー
→ファースト：問題を検出
セカンド：問題の記録
参考)インシデント管理と同様に、問題に関連する、すべての詳細情報を記録
→問題がクローズしたあとに重大な問題についてレビューを実施し、適切に実施された項目、実施されなかった項目、改善項目、再発防止方法などを確認。
参考)重大な問題のレビューが終了した時点で、問題管理のフローは終了。
問題管理
→エスカレーションした変更要求が実施されるまで、進捗状態を監視
→問題をハードウェアに関するもの、ソフトウェアに関するもの、操作に関するものなどに分類。
参考)問題はインシデント管理と同じ基準に従い分類
アクセス
→ITサービスの機能やDをユーザが利用できる範囲のことを指す。
アクセス管理
→誰がどのITサービスにアクセスできるかを決定するのではない
参考)誰がどのITサービスにアクセス可 決定するのは、Sdの情報セキュリティ管理、可用性管理。
参考2)情報セキュリティ管理、可用性管理で決定した方針、規制をもとに、ITサービスを利用する権限をユーザに割り当てる
ディレクトリ・サービス
→アクセスや権限を管理するためのツール
単一窓口
→必ずしも物理的な拠点を1ヶ所におく必要はない
IT組織全体の調整
→サービスデスクが、円滑なコミュニケーションを維持しつつ、ユーザの利益になるよう、ITサービス・プロバイダが持つ組織およびプロセスの活動を調整すること。
参考)サービスデスクは、各部門の活動を調整する
中央サービスデスク
→メリット)情報を集約しやすい
デメリット)ユーザから物理的に話離されているため、ユーザの意見を肌で感じられない
ex)火災など
インシデントのオーナシップ
→インシデントを受け付けたサービスデスクが保有
ex)インシデントをエスカレーションするべき場合も、最終的にインシデントがクローズするまでサービスデスクが責任を持って追跡・管理することになる
ユーザおよびITスタッフとコミュニケーション
→インシデントを円滑に解決に導くために、ユーザや必要な部門と接点を持つこと。
参考)ユーザとの直接的な接点、あるいはエスカレーション先との連携などにおいて、効果的なコミュニケーションをとる必要あり
技術管理
→ITインフラストラクチャの運用を行うのに必要な技術力やリリースを提供する組織
参考)ITインフラストラクチャの設計、ITインフラストラクチャの保守、障害発生時のサポートなどの活動を行う
参考2）システムの大規模化に伴い、単一の部門やグループとするのではなく、必要となる基準に応じた複数のチームで分業する