勉強後記

千里の道も一歩から。学びから遊びまで継続活動の日記。

    ITIL

      このエントリーをはてなブックマークに追加 mixiチェック
    昨日受験してきました。。

    英語を直訳しているせいか、問題文の日本語が若干おかしかったけど・・・・。
    ITILv3Foundation2
    最低点だけど合格したwwwww 

      このエントリーをはてなブックマークに追加 mixiチェック
    7.1 継続的サービス改善の概要
    継続的サービス改善→ビジネスの変化に追随し、ITサービスやITサービスを支えるプロセスや機能の改善を実施する。プロセスの費用対効果や有効性、効率性を改善する活動。サービスオペレーションだけでなくサービスストラテジ、サービスデザイン、サービストラジションも対象となる。
    デミング・サイクル(PDCAサイクル)→品質改善の段階で用いられる4つの段階(計画、実施、点検、処置)をもつサイクル。
    継続的サービス改善モデル→継続的サービス改善で使用するデミングモデル。
    ビジョン、ミッション、最終目標、達成目標などの最上位のレベルの事業達成目標→効果的で効率的な改善を行うにはまず、事業とITの ビジョン、ミッション、最終目標、達成目標などの最上位のレベルの事業達成目標を正しく理解する必要がある。
    我々はどこにいるのか?→ 現在どのような状況になっているのかを現状分析し理解する事で、最終目標を達成するために必要な作業を明確にすることでわかる。
    ベースライン・アセスメント→最初に実施する現状分析。
    優れた目標値は単に測定可能なだけでなく、何を満たしているか→SMART。Specific:具体的、Measurable:測定可能、Achievable:達成可能、Relevant:適切、Timely:適時。
    サービス改善計画(SIP)
    → 目標改善を達成するために、どのようなプロセス、サービス改善をしていくかまとめたもの。
    重要業績評価指標(KPI)→測定基準を確立し、測定することで改善目標が達成できたか確認する。
    推進力の維持→改善が反映されたことを確認して、品質改善活動に対するモチベーションを保ち続けること。
    ベースライン→基準点として使用するベンチマークの事で、改善後の測定結果との比較作業で使用する。
    測定する理由→妥当性の確認、方向付け、正当化、介入のため。 
    妥当性確認
    → 以前行った意思決定が戦略とビジョン通りになっているか検証するために監視、測定すること。
    方向付け→設定した目標値を満たすために何をすべきかを監視、測定する。
    正当化→一連の措置が必要であることの正当性を証明するために監視・測定する。
    介入→変更や是正措置など介入が必要な箇所を特定するために監視する。 
    技術的測定基準→可用性やパフォーマンスなどといったITサービスを構成するコンポーネントやアプリケーションの測定基準のこと。 
    プロセス測定基準→サービスマネジメントのプロセスの有効性や効率性を図る測定基準。
    重要成功要因(CSF:Critical Success Factor)→プロセス測定基準で測定する。
    重要業績評価指標(KPI:Key Performance Indicator)→プロセス測定基準で測定する。
    サービスの測定基準→エンドツーエンドのサービス結果の事で、コンポーネントの測定基準のこと。
    ガバナンス→「方針と戦略が実際に遂行されること」「必要なプロセスに正しく従って処理されること」を確実にすることで、役割と責任の定義、測定と報告、特定された課題を解決するための処置が含まれる。
    コーポレートガバナンス→企業に公正性、透明性を求め、説明責任を負わせることを推進する。 
    ITガバナンス→サービス・ライフサイクル全体わたって機能し適切な方針、手順、プロセス、測定を整備しこれらが確実に実施、遵守されるようにすることをなんというか。

      このエントリーをはてなブックマークに追加 mixiチェック
    6.1 サービスオペレーションの概要
    サービスオペレーションの5つのプロセス→イベント管理、インシデント管理、問題管理、要求実現、アクセス管理
    イベント管理→サーバ、アプリケーションなどから通知されるすべてのイベントを監視し異常状態を通知するイベントが発生した場合、インシデント管理にエスカレーションする。
    インシデント管理→出来るだけ早くインシデントを取り除くことを目的に活動する。
    問題管理→問題の根本原因の特定、除去を目的とする活動を行うプロセス。
    要求実現→ユーザから要求される、リスクが少なく、低コストで発生頻度が多い作業をあらかじめ合意された手順に従って処理するプロセス。 
    アクセス管理→許可されたユーザにITサービスを使用する権限を付与し適切に使用されているかの確認などを行うプロセス。 
    サービスデスク→ITサービスプロバイダとユーザ間の接点となる組織。
    IT運用管理→ITインフラストラクチャを継続的に管理し、合意されたレベルでITサービスを提供するために日々の運用に責任を負う組織。
    技術管理→ITインフラストラクチャを継続的に運用・保守するために必要な技術やリソースを提供する組織。
    アプリケーション管理→運用中のアプリケーションの管理とサポートを担当する組織。 
    コミュニケーション→サービスオペレーションでの効果的なコミュニケーションによってすべてのチーム、部門がITサービスの提供やITインフラストラクチャの管理に関して標準的な活動が出来る。
    6.2 イベント管理
    イベント管理→ITインフラストラクチャ全体で発生するすべてのイベントをモニタリングするプロセス。
    イベント→構成アイテムやITサービス管理にとって重要性のある状態の変更のこと。通常、ITサービス、構成アイテム、イベント管理ツールなどによって生成される。
    情報のイベント→どのような対処も必要ないイベント。
    警告のイベント→サービスや装置がしきい値に近づいてきたとき生成されるイベント。
    例外のイベント→サービスや装置が正常に運用できていない状態で生成されるイベント。
    アラート→しきい値に達した時、変更があった時、または障害が発生した時の警告で、人に対して通知され、人の介入を必要とするもの。
    能動的モニタリングツール→デバイスやシステムなどの装置に問い合わせを行い、データを収集し、ステータスと可用性を判断するツール。
    受動的モニタリングツール→CI(構成アイテム)が一定の条件を満たすとイベントを生成して通知するツール。
    自動応答→発生したイベントの中で対処内容が明確で自動的に実行できるもののこと。
    アラート、人の介入→発生したイベントで人の介入が必要なアラートに対して人が対処を実施する対応のこと。
    エスカレーション→何らかの異常が発生していることを意味する例外はインシデント管理、問題管理、変更管理などいずれかのプロセスにエスカレーションする。
    6.3 インシデント管理
    インシデント管理→ITサービスに対する計画外の中断や品質の低下をインシデントとして管理するプロセスで発生時にはユーザに対する運用を可能な限り迅速に回復させる事に焦点をあてたプロセス。
    インシデント→ITサービスの計画外の停止や品質低下のことで将来的にITサービスに影響を及ぼす可能性がある生涯も含める。 
    サービスデスク経由でユーザから直接伝達された事象→「システムのレスポンスが悪くなった」「PCが故障した」といったユーザからの「問い合わせ」のことで、サービスデスクを経由してインシデントとして記録される事象のこと。
    イベント管理からのエスカレーション→イベント管理からインシデント管理にエスカレーションされてきた事象のこと。 
    技術スタッフによる記録→技術スタッフがハードウェア、ネットワークなどになんらかの不具合があることに気がついた時インシデントに記録しサービスデスクに問い合わせる。 
    インシデント・モデル→ 特定の種類の再発するインシデントを処理する手順を合意に基づいて事前に定義しておく方法のこと。項目として下記がある。
    ①インシデントを処理する手順
    ②処理手順に依存関係や共同処理がある場合、どのような順番で処理するかの時列の順序。
    ③責任(担当者、担当内容)。
    ④処理を完了するまでの期間、しきい値。
    ⑤エスカレーション手順(連絡先、連絡するタイミング)
    ⑥証拠保持の活動(エビデンスを残す活動)
    重大なインシデント→事業に深刻な影響を与える原因となるインシデントのこと。
    インパクト→インシデント、問題、変更におけるビジネスに与える影響の指標。サービスレベルが受ける影響の指標。サービスレベルが受ける影響の程度に基づくことが多い。下記5つの事を考慮して決定する。
    ①生命や健康に関わるリスク。
    ②影響を受けるサービスの数。
    ③財政上の損失。
    ④事業への評判への影響。
    ⑤規制上、法律上の違反。
    緊急度→インシデント、問題、変更が事業に顕著なインパクトを与えるまでに残された時間の指標。
    優先度→緊急度+インパクト。インシデント、問題、変更の相対的な重要度の識別に使用する。インパクトと緊急度をもとに決定し、解決し、解決時間目標の特定にも使用される。
    エスカレーション→インシデントをタイミングよく解決するための支援をする仕組み。
    機能的エスカレーション→サービスデスクのスタッフが単独でインシデントを解決できなかった場合か、初回解決の目標時間を超過した場合のいずれかが発生した時点で、インシデントをより専門的な知識を持つグループへ渡す事。
    階層的エスカレーション→重大なインシデントの場合はITマネージャに情報を提供する場合がある。
    1次サポートデスク→サービスデスク
    2次、3次サポートデスク→より多くの時間、あるいはリソースを所有しているサービスデスク以外の部門と専門家のサポートグループ。
    インシデント管理9つのプロセス→「識別」「記録」「分類」「優先度の決定」「初期診断」「エスカレーション」「調査と診断」「解決と復旧」「クローズ」
    インシデントの識別→インシデントはイベント管理プロセスからのエスカレーション、サービスデスクへの電話、webなどのセルフヘルプデスク、技術スタッフからのメールによって検出される。
    インシデントの記録→サービスデスクへ連絡されたもの、イベント管理ツールで自動検出されたイベントなどインシデントの受け取り方に関係なくすべてのインシデントの発生時刻、現象などを記録する事。
    インシデントの分類→発生したインシデントをハードウェアに関するもの、ソフトウェアに関するもの、捜査に関するもの等など様々な分類(カテゴリ化)する。そのごインシデントの優先度を決定する。
    初期診断→インシデントがサービスデスク経由で報告された場合、通常はユーザと電話している間にサービスオペレータが実行する。
    インシデントのエスカレーション→サービスデスクが単独で解決できなかった場合により高度な専門的知識を持つサポートグループに実施する行為。
    調査と診断→すでに明確になったワークアラウンドがない場合に必要となる。解決策が明確になった場合、解決策をテスト、適用、復旧させる。
    インシデントのクローズ→サービスデスクはインシデントが完全に解決されたことと、ユーザが満足しインシデントのクローズに合意していることを確認する。
    イベント管理のプロセス→イベント管理が管理するイベントがエスカレーションされてインシデントになる場合がある。
    問題管理のプロセス→問題管理のプロセスがインシデントの再発を防止するという意味でインシデント管理プロセスと関係がある。またインシデント管理プロセスから問題管理プロセス「問題」が報告される場合もある。
    サービス資産管理システムおよび構成管理システム(CMS)→インシデント管理プロセスが故障している装置を識別し、インシデントのインパクトを評価するために利用する。
    変更管理プロセス→変更が必要な場合、インシデント管理プロセスは変更要求を変更管理プロセスに提出して変更管理プロセスで処理を進める。
    キャパシティ管理→キャパシティ管理がパフォーマンスの問題を検知する場合がある。インシデント管理プロセスにワークアラウンドを提供する場合がある。
    可用性管理→可用性管理はインシデント管理プロセスで管理しているデータを利用してITサービスの可用性を判断し、インシデントライフサイクルで改善できる箇所がないか検討する。
    サービスレベル管理→サービスレベル管理はインシデント管理プロセスに対するサービスレベル(インシデントの応答時間、目標解決など)を合意する。
    6.4 要求実現
    要求実現→予期しないサービスの遅延や中断に起因するインシデントを取り除いた顧客やユーザからの要求を処理するプロセスをなんというか。
    サービス要求→情報や助言または標準的な変更やITサービスへのアクセスに対するユーザからの要求のことでサービスデスクで処理するもの。パスワードのリセット、新規のユーザ登録、アプリケーションのインストールなど。低リスク、発生頻度が高い、低コストという特徴がある。
    要求モデル→サービス要求を処理する、事前に定義した処理方法の事。
    セルフヘルプ→サービス要求、インシデントの登録やFAQの参照などユーザ自らサービスデスクを利用できる仕組みの事。
    セルフヘルプのITサービスプロバイダにとってのメリット→ITスタッフが不在でも24時間365日常時サービスを提供できるようになり、ITスタッフの削減、コストの削減、サービス時間の延長につながる。
    セルフヘルプデスクの事業部門にとってのメリット→Webインターフェイスであるため、ユーザはいつでもどこからでもサービスデスクを利用できるようになる。
    6.5 問題管理
    問題管理→イベント及びインシデントの根本原因を特定して解決するプロセス。将来発生する可能性があるインシデントおよび問題を防止し、インシデントが発生した場合迅速な診断し解決を可能にするための既知のエラー作成、ワークアラウンドの提供を実施する。
    問題→1つまたは複数のインシデントを引き起こす未知の原因。
    問題モデル→特定の種類の再発する問題を処理する手順を合意に基づいて事前に定義しておくこと。
    ワークアラウンド→完全な解決策がまだ存在しないインシデントや問題のインパクトを軽減排除すること、またはその方法の事。
    既知のエラー→診断に成功し、根本原因とワークアラウンドが識別、文書化された問題の事。
    既知のエラーデータベース(KEDB:Known Error Data Base)→すべての既知のエラーレコードを含むデータベース。下記2つを含む。
    ①サービスの回復や問題解決のために実施したワークアラウンド、解決策の詳細情報。
    ②障害内容、障害の兆候情報。
    リアクティブな問題管理→問題の根本原因を解決し、インシデントの再発を防止する問題管理。サービスオペレーションで実施される。下記10個の活動からなる。
    ①問題の検出。
    ②問題の記録。
    ③問題の分類(カテゴリ化)。
    ④問題の優先度の決定。
    ⑤問題の調査と診断。
    ⑥ワークアラウンドの特定。
    ⑦既知のエラーレコードの作成。
    ⑧問題の解決。
    ⑨問題のクローズ。
    ⑩重大な問題のレビュー。
    また下記4つの方法で検出される。
    ①サービスデスクからの報告。
    ②技術サポート・グループからの報告。
    ③イベント管理ツールからの通知。
    ④プロアクティブな問題管理の分析結果。
    プロアクティブな問題管理→将来発生しうるインシデントを事前に防止する問題管理。
    問題の記録→すべての問題において、問題に関連するあらゆる詳細情報を問題レコードに記録する事。
    問題の分類(カテゴリ化)→問題をハードウェアに関するもの、ソフトウェアに関するもの、操作に関するものなどに分類すること。
    問題の優先度の決定→インシデント管理と同じインパクトと緊急度から決定する。
    問題の調査と診断→既知のエラーデータベースを参照し過去に類似の問題がないか確認し、問題が過去にも発生している場合根本原因を特定する。 
    ワークアラウンド→問題によって引き起こされたインシデントに対して特定できるもの。
    既知のエラーレコード→診断が完了し、根本原因が特定できたら作成するもの。
    問題の解決→問題の根本原因取り除くために実施するもの。
    問題のクローズ→変更が完了し解決策が適用されたら実施する。
    重大な問題のレビュー→重大な問題に対してはレビューを実施、適切に実施された項目、されなかった項目、改善項目、再発防止法などを確認する。
    プロアクティブな問題管理→将来発生する可能性のある問題を予防すうる活動で通常は「サービスオペレーション」で開始されるが「継続的サービス改善」の一部として推進するものをなんというか。
    インシデント管理→問題によって引き起こされる場合が多くある問題管理のプロセスと関係のあるプロセス。
    サービス資産管理および構成管理→問題管理プロセスは、サービス資産管理および構成管理を使用して障害の発生している構成アイテムを識別し、問題解決のインパクトを判断する。
    変更管理→問題管理プロセスは問題を解決するために変更要求(RFC)を変更管理に提出する。
    リリース管理および展開管理→問題に起因してシステム変更が発生する場合、リリース管理および展開管理が変更を稼働環境に投入する責任を負う。
    可用性管理→停止時間を減少させ稼働時間を増加させる方法を特定する事に関与する。
    キャパシティ管理→パフォーマンスに関する問題の一部はキャパシティ管理による調査が必要となる。
    ITサービス継続性管理→重大な問題がいつまでも解決されないと、ビジネスが深刻なインパクトを受け始める。この場合ITサービス継続性管理がトリガーとなり、サービス継続性計画が発動される。
    サービスレベル管理→問題の発生が顧客と同意したサービスレベルに影響を与えるプロセス。
    6.6 アクセス管理
    アクセス管理→ユーザにサービスを使用できる権利を与える事が出来るプロセスでデータや知的所有権の気密性、可用性、完全性の確保につながるプロセス。
    アクセス→ユーザが利用する資格を持つサービスや機能やデータレベル/範囲のこと。
    ID→ユーザを個人として識別する情報で、ユーザごとに1意なものこと。
    権限→サービスや サービス群へのアクセスをユーザに提供する実際の設定のことで、一般的には読み取り、書き込み、実行、変更、削除などがある。
    サービス群→複数のサービスをグループ化したもので、利用可能な複数のサービスへのアクセスをユーザやユーザグループに付与する事で効率化を図ることができるもの。 
    ディレクトリ・サービス→アクセス権限を管理するためのツール。
    6.7 サービス・デスク
    サービスデスク→さまざまなインシデントやイベント処理に責任を負う専任のスタッフで構成される組織のことでITサービスプロバイダとユーザ間における日常の窓口の事。
    単一窓口(SPOC:Single Point of Contact)→事業部門から見たIT・サービスプロバイダへの単一の連絡手段。
    IT組織の全体の調整→円滑なコミュニケーションを維持しつつユーザの利益になるように、ITサービスプロバイダを調整する事。 
    フォローザサン→24時間365日サービスを提供するために世界中のサービスデスク、サポートグループを活用する事。 
    インシデントのオーナーシップ→受け付けたインシデントに対してクローズするまでインシデントを追跡し、必要に応じてフォローを行う事。
    ユーザおよびITスタッフとのコミュニケーション→インシデントを円滑に解決に導くためにユーザーや必要な部門と接点を持つこと。 
    進捗情報の提供→調査に時間を要するインシデントなどに対してユーザに途中経過などを報告すること。
    6.8 技術管理
    技術管理→技術的な専門能力とITインフラストラクチャの管理を提供する組織(グループ、部門、チーム)を目指す。
    ITインフラストラクチャ設計→対障害弾力性(障害に陥りにくい設計にする。障害が発生しても早く回復できる)や費用対効果の優れたITインフラストラクチャの設計の事。
    ITインフラストラクチャの保守→ITインフラストラクチャを最適な状態に維持するための技術力を提供する事。
    障害発生時のサポート→発生する技術的な障害を調査し解決する技術力を提供する事。 
    6.9 アプリケーション管理
    アプリケーション管理→アプリケーションのライフサイクル(要件の収集、設計、構築、展開、運用、最適化)を通して、アプリケーションの管理に責任を負い、運用中のアプリケーションの管理とサポートを担当する組織。
    ①アプリケーションの設計、機能
    ②機能の可用性の保証
    ③アプリケーションの保守
    ④障害発生時のサポート
    6.10 IT運用管理
    IT運用管理→ 事業部門に合意されたレベルでITサービスを確実に提供するために組織のITインフラストラクチャの継続的な管理と保守に責任を負う組織(グループ、部門、チーム)。運用コントロールと施設管理が含まれる。
    運用コントロール→ITインフラストラクチャの日常的な運用活動を実施したり、イベントを監視する。一般に運用統制室からITサービス、ITインフラストラクチャをネットワーク運用センターからネットワークを集中的に監視、管理すること。 
    施設管理→物理的なIT環境を管理し、電力や冷房設備を含めコンピュータ室、データセンター、復旧拠点を管理すること。

      このエントリーをはてなブックマークに追加 mixiチェック
    5.1 サービストラジションの概要
    サービス・トラジション→サービスデザインから、サービスデザインパッケージを受け取り、事業のニーズを満たすかどうかテストし、本番環境に展開し実際に運用で利用できる状態に移行する事。
    変更管理・サービス資産管理・ナレッジ管理→サービス・ライフサイクルのすべてのフェーズで実行されるプロセス。
    サービス・トラジションのみで実行されるプロセス→リソース管理および展開管理。移行の計画立案およびサポート、評価。サービスの妥当性確認およびテスト。 
    5.2 変更管理
    変更管理→標準化された手順を用いてあらゆる変更を効率的かつ迅速に処理する事。事業にもたらされるリスクを最適化するプロセス。
    サービス変更→許可、計画、サポートさえているサービスやサービスの構成要素(サービス・コンポーネント)とその関連文書を追加、修正、削除すること。 
    変更要求(RFC:Request for Change)→サービス変更の要求、提案のことで変更の詳細が記述されるもの。 変更理由、変更しない場合の影響、変更対象である構成アイテムのバージョンなどが含まれる。
    修復計画→変更またはリリースが失敗した場合に、変更前の既知の状態に回復させる切りもどし計画のこと。
    変更スケジュール→承認済みのすべての変更と詳細と変更の実施予定日をまとめた文書のことで「将来的な変更スケジュール」と呼ばれることもある。実施済みの変更情報を含む場合もある。
    変更管理の7つのR→変更を評価、アセスメントするときの重要な質問のこと。①変更を要請(RAISED)したのは誰か。②変更の理由(REASON)は何か。③変更の成果(RETURN)として要求されるものは何か。④変更に伴うリスク(RISK)は何か。⑤変更を実施するために必要なリソース(RESOURCE)は何か。構築、テスト、実装の責任(RESPONSIBLE)は誰にあるか。⑦この変更と他の変更の関係(RELATIONSHIP)は何か。
    変更要求の種類
    →変更のインパクト大きさなどによる分類のことで「通常の変更」「標準的な変更」「緊急の変更」がある。 
    通常の変更→変更管理の一般的な原則が適用される変更。変更の登録、フィルタリング、アセスメント、認可、スケジュール化、レビュー、クローズの段階を経て処理される。
    標準的な変更→ビジネスへの影響度、リスク、コストが少なく変更管理によって手順が確率された(手順が承認済み)の変更。決められた手順以外の変更を実施しない。そのためRFCを必要としない場合がある。
    緊急の変更→ビジネスに大きな影響を与えており、早急に変更しなければならない変更。時間が少ない状態、かつすぐにITサービスをを復旧しなければならないので別の障害をまねく可能性がある。緊急の変更は迅速に通常の変更を実施する事が大切。
    変更プロセスモデル→特定の種類の変更に対処するためにとるステップを事前に定義する手法。5つのステップがある。①課題や予想外のイベント処理を含む変更を処理するステップ。②あらゆる依存性または共同処理が定義された、これらのステップの実行順序。③責任。誰が何を行うべきか。④処理の完了に対する期間としきい値。⑤エスカレーション手順。誰にいつ連絡をとるべきか。
    変更マネージャ
    →すべてのRFCについて受領、登録を行い優先度を割り当て必要なメンバーを招集しRFCのクローズ(すべての処置終了)まで責任を負う人。
    変更諮問委員会(CAB:Change Advisory Board)→変更を許可し、変更の評価および優先度決定において変更管理を支援する機関。変更マネージャが議長を務め変更による利害関係者(顧客、ユーザ、サービスデスク、運用スタッフ、サプライヤーなど)で構成される。
    変更諮問委員会のメンバー→顧客、ユーザのマネージャ、ユーザのグループ代表者、アプリケーション開発者、保守担当者、専門家、技術コンサルタント、サービスデスク、ITサービス継続性管理・キャパシティ管理・セキュリティ管理などの運用スタッフ、設備・事務サービスのスタッフ、アウトソーシングしている場合契約業者またはサードパーティの代表者など。
    変更諮問委員会の検討すべき項目→提出されたRFC、変更に対する許可、変更スケジュール。
    緊急変更諮問委員会(ECAB:Emergency Change Advisory Board)→緊急の変更が必要となった場合(CAB全体を招集する余裕がない場合)に召集され、緊急の意思決定を下す権限をもつ、緊急諮問委員会より小規模なグループ。
    変更管理で行う9つのプロセス→①変更の計画立案とコントロール②変更のインパクトの理解③変更の意思決定と変更の許可④変更とリリーススケジュール⑤利害関係者とのコミュニケーション⑥修復計画があることの確認。⑦測定とコントロール⑧管理報告⑨継続的改善
    RFCの作成、記録→追加設備を供給する事業部門や問題管理プロセスなどRFCは変更を必要とする個人、
    グループである要求元から提出される。最初の変更管理の流れ。
    RFCレビュー→各変更要求を検討し、「あきらかに無理なもの」「既に受け入れ済みのRFC(重複しているもの)」
    「提出内容に不備があるもの」などを却下する変更管理の流れ。
    変更アセスメント、評価→変更アセスメントと許可は変更許可委員が行う。
    変更の許可→変更許可委員会によって変更を許可するか却下するかを決定する。
    変更の実施の調整→変更許可後実施する変更管理の流れ。
    変更のレビュー、クローズ→変更が完了した時点で変更管理の責任者に結果を報告し評価する。
    PIR(Post Implementation Review)→変更実施後のレビューの事。
    サービス資産管理および構成管理→変更の利害関係者やスタッフが構成管理システムを利用し、提案された
    変更のインパクトを評価し、変更のワークフローを追跡できるようにするため、正確な構成情報に確実、迅速
    容易にアクセスできるようにするプロセス。
    リリース管理および展開管理→変更管理プロセスによって許可された変更をリリース管理および展開管理に
    よって稼働環境にリリースされる。
    問題管理→ワークアラウンドを実施したり、既知のエラーを修正したりするために変更が必要となる場合がある。
    この時変更管理プロセスにRFCを提出するプロセス。
    ITサービス継続性管理→「ITサービス継続性計画」は変更管理プロセスを介して更新し、常に正確かつ最新の
    状態を維持し利害関係者に変更したことを認識させるおおもとのプロセス。
    情報セキュリティ管理→セキュリティを維持するために必要な変更を変更管理プロセスにRFCを提出する。
    キャパシティ管理→変更がキャパシティに及ぼすインパクトをアセスメントするプロセス。
    需要管理→変更で事業部門の需要を満たすことができなくなることがないように適切に管理するプロセス。

    5.3リソース管理および展開管理
    リリース管理および展開管理→リリースをパッケージ化、構築、テストして本番環境にサービスを導入し、
    サービスオペレーションへ引き継ぎ顧客に価値あを提供するプロセス。
    リリース→ITサービスに対して承認された変更を実施するために必要とされる、ハードウェア、ソフトウェア、文書
    プロセスなどの構成アイテムの集合。
    リリース方針→組織のリリース活動に対する方針のこと。リリース管理および展開管理の役割を明確に定義し
    自分の役割と権限レベルおよびプロセスに関わる他者の役割と権限レベルを理解できるようにすること。
    リリースユニット→通常同時にリリースされるサービス、ITインフラストラクチャの1部分で構成ユニットをまとめた
    リリースする単位のこと。
    リリースパッケージ→同時にリリースするためにパッケージ化されたリリースユニット全体のこと。複数のリリース
    ユニットで構成される場合もある。
    5.4サービス資産管理および構成管理
    サービス資産管理→サービスおよびITインフラストラクチャのコンポーネントの構成情報を正しい状態に維持し
    他のプロセス活動(インシデント調査)を支援するプロセス。
    構成アイテム(CI:Configuration Item)→ITサービスの提供のために管理する必要があるあらゆるコンポーネントの事で、一般にITサービス、ハードウェア、ソフトウェア、スタッフ、SLAなどの正式文書も含む。
    確定版メディアライブラリ(DML:Definitive Media Library)→承認済のバージョンのソフトウェア、文書のマスターコピーを保管し、保護する1つないしは複数の場所。このライブラリには社内で開発したソフトウェア、ベンダから購入したソフトウェアの両方が含まれる。
    構成モデル→確定版メディアライブラリ間の関係を含むサービス、資産およびインフラストラクチャのモデル。構成モデルを利用する事で、他のプロセスは価値ある情報を得る事ができる。①インシデントと問題のインパクト、原因のアセスメント②提案された変更のインパクトのアセスメント③新規または変更されるサービスの計画、設計④リリースおよび展開パッケージについて計画し別の場所やサービスセンターにサービスを移行⑤データセンタの統合、資産の再利用など資料の利用とコストの最適化。
    構成ベースライン→正式に合意済みで変更管理プロセスで管理され将来の構成、リリース、変更のベースとして使用されるもの。
    構成管理データベース(CMDB:Configuration Management Data Base)→構成アイテムを管理するデータベースのこと。他のCIとの関係も保存する。
    構成管理システム(CMS:Configuration Management System)→ITサービスプロバイダの構成データの管理に使用される一連のツール、データベースのこと。
    PICSV→サービス資産管理および構成管理での5つの主要活動の頭文字をとってこう記述する。
    管理と計画立案(management and Planning)→構成を管理する方針、適用範囲、目標、役割、責任などの導入計画を構成管理計画として策定する事。
    構成識別(configuration Identification)→マウス、HDD、キーボードなどどこまでをCIとして管理するかCIの選択基準、CIの命名規則、CIのラベル、CI同士の関係、CIのタイプなどを定義文書化すること。
    構成コントロール(configuration Control)→CIの変更を追跡し、管理する事。
    ステータスの説明と報告(Status accounting and reporting)→CIのステータスを追跡し、ステータスレポートを作成し報告する。
    検証と監査(Verification and audit)→構成管理データベースに格納されているCIが実際に存在していることを確認、監査すること。
    変更管理→構成管理システムを利用し提案された変更のインパクトを識別するプロセス。
    インシデント管理と問題管理→構成管理システムを利用し故障した機器を識別し、インシデントのインパクトをアセスメントしたり、潜在的な問題によって影響を受けるユーザを識別したりするプロセス。
    可用性管理→サービス資産管理および、構成管理プロセスは可用性管理の障害点の検出を支援する。
    ITサービス継続性管理→構成管理システムを利用し、事業が依存している資産を認識し、重要な予備資産とソフトウェアをコントロールするプロセス。
    財務管理プロセス→構成管理システムを利用し、コスト、減価償却手法、オーナ、ユーザ、保守コストと主要な財務情報を把握するプロセス。
    5.5ナレッジ管理
    ナレッジ管理→事業が必要とするサービスを提供およびサポートするために適切な人材が適切なブリッジをもっているようにするプロセス。①品質が改善したより効率的なサービス②サービスによってもたらされる価値についての共通の明確な理解③常に利用できる適切な情報
    DIKWData to Information to knowledge to Wisdom データ、知識、知恵の間の関連を理解する方法。
    サービスナレッジ管理システム(SKMS:Service knowledge Management System)→ナレッジ、情報の管理に使用される一連のツールのデータベース。知識に含まれる4つの点①スタッフの経験②気候、ユーザ数、組織の業績など③サプライヤ、パートナの要件能力④ユーザのスキルレベル 

     

      このエントリーをはてなブックマークに追加 mixiチェック
    4.1 サービスデザインの概要
    サービス・デザイン→サービスストラテジで明確にした事業部門の要件をもとにサービス設計する事。
    ITサービス設計をする際の考慮点→機能性(ITサービスの機能、品質)リソース(費用、スタッフ)スケジュール(期間)
    人材(People)→スタッフの能力やスキルの事。

    プロダクト(Products)→サービス、使用するツール(管理システム)技術の事。 
    パートナ(Partners)→サービスを提供する時に使用するメーカ、ベンダ、サプライヤの事。
    プロセス(Processes)→ サービス設計時の役割、活動の事。
    サービスデザインの5つの側面→サービスデザインでの設計 対象の事。サービスソリューション設計、支援的な仕組みの設計、技術アーキテクチャ設計、プロセス設計、測定方法と測定基準の設計。
    サービスデザイン7つの構成要素→サービスカタログ管理、サービスレベル管理、キャパシティ管理、可用性管理、ITサービス管理、情報セキュリティ管理、サプライヤ管理。
    サービスソリューション設計→事業部門と合意した要件(サービス要件、非機能要件、ユーザーインターフェイス)をもとに設計する設計対象。
    支援的な仕組みの設計(特にサービスポートフォリオ)→サービスポートフォリオ、システム管理ツール、ワークフローなどプロセスの活動を効率的に伝える仕組みやツールを設計対象とする。
    技術アーキテクチャの設計→安全で障害弾力性のあるITインフラストラクチャ、アプリケーションなどのアーキテクチャ設計を対象とする。
    プロセスの設計→プロセスの活動内容、インプット、アウトプット、役割、責任などを対象とする。
    測定方法と測定基準の設計→プロセスの活動やプロセスの成果物(アウトプット) 管理するため、プロセスを監視測定する基準の設計。
    サービスデザインパッケージ→ITサービスとその要件のすべての側面についてライフサイクルの各段階を通して定義する文書の事。
    サービスデザインパッケージの内容→要件(事業要件、サービスの活用場所、サービスの事業窓口)、設計(サービスの機能要件、サービスレベル要件、運用管理要件)、サービスライフサイクル計画(サービスの移行計画、運用の全体的な戦略など)
    サービスの自動化→サービスプロセスを自動化する事。有用性と保証を改善する。
    サービス自動化のメリット→サービス品質の改善のばらつきの減少による有用性、保証の改善、コスト削減など。
    サービス自動化のための4つ私信→①自動化する前にサービスプロセスを簡略化する。②活動の流れ、タスクの割り当て、情報の必要性、やりとりの明確化。③システムの技術の複雑性からユーザを保護する。④複雑な標準的でないまたは通常実施しないタスクは自動化を避ける。
    4.2 サービスカタログ管理
    サービスカタログ管理→ITサービスプロバイダが事業部門に提供しているサービスや、導入準備中のITサービスを作成管理する事。
    サービスカタログ→サービスオペレーションの段階で顧客やユーザーに提供されている、ITサービスと顧客やユーザに提供することが承認済みで導入準備中のITサービスについて詳細をまとめたもの。
    ビジネス・サービスカタログ→顧客に提供するITサービスの詳細をまとめたサービスカタログの事。
    技術・サービスカタログ→事業部門内にITサービスを提供するため必要となるすべてのサービス(支援)をまとめたものの事。 
    4.3 サービスレベル管理
    サービスレベル管理→ITサービスの目標について事業部門の代表者と協議し文書化する。合意されたレベルでITサービスが提供されているかITサービスプロバイダの能力を監視、レビューしサービスレベルを維持向上させる事。
    サービスプロバイダのタイプ→サービスプロバイダの典型的なビジネスモデルによる分類の事。
    内部サービスプロバイダ→ITサービスを提供する事業部門内に存在するサービスプロバイダの事。
    シェアド、サービス部門→内部サービスプロバイダの一部で、複数の事業部門で共有するITサービスを提供する部門の事。
    外部サービスプロバイダ→外部顧客にITサービスを提供する部門の事。
    SLR(Service Level Requirement)→ITサービスのあらゆる面に対する顧客の要件の事。
    SLA(Service Level Agreement)→ITサービスプロバイダと顧客との間で文書化された合意であり、重要なサービス目標と両当事者の責任を定義したもの。
    サービスレベルSLA→1つのSLAが1つのサービスを利用するすべての顧客を対象とする場合事。
    顧客ベースSLA→1つの独立した顧客グループとその顧客が使用するSLAの事。
    マルチレベルSLA→SLAの頻繁な更新を避けるため、企業レベル、顧客レベル、サービスレベルの3つ体系に分けることによって、SLAを使いやすいサイズに維持する。
    OLA(Operational Level Agreement)→SLAを実現するため、ITサービスプロバイダと組織内でサービスの提供を支援する他部署との合意の事。
    UC(Underpining Contract)外部委託契約→SLAを実現するため、ITサービスプロバイダと外部サプライヤとの間で交わされる契約の事。
    サービス・レビュー →先期のサービス達成度、翌期の課題をもって確認するため顧客またはその代表と定期的に開催するレビューの事。
    サービス改善計画(SIP(Service  Inprovement Plan))→プロセスまたはサービスに対する改善を実施するための正式な計画。
    サービスレベルモニタリングチャート(SLAM(Service Level Agreement Monitoring))→サービスレベルの目標値に対してどの程度達成できたかといった達成度をモニタし報告するための有益な情報の事。
    サービスレベルマネージャ→SLA、OLAを文書化する責任を持ち、SLAが満たされているかどうかのパフォーマンスを監視する。
    SLAフレームワーク設計→サービスレベル管理をサービスカタログを利用して、組織のニーズに最も適したSLA体系を設計する事。
    サービスレベル要件→サービスレベルが確定され、SLA体系について合意がされると策定される。
    SLAに照らしたサービスパフォーマンスの監視→SLAの目標値を満たしているかサービスのパフォーマンスを監視する事。
    可用性管理→可用性に関する要件をSLAのインプットとしてサービスレベル管理プロセスを提供し可用性が悪化することによって起きるSLA違反を削減する事。
    キャパシティ管理→パフォーマンスに関する要件をSLAのインプットとしてサービスレベル管理プロセスに提供する。
    サプライヤ管理→SLAと整合性が取れるようにサプライヤと契約する事。
    情報セキュリティ管理→SLAと整合性が取れるように情報セキュリティを管理する事。
    変更管理→SLAに関する変更を管理する。
    インシデント管理→SLAの目標値いないでインシデントを管理する事。
    4.4 キャパシティ管理
    キャパシティ管理→ITサービス/システムのキャパシティ・パフォーマンスが適切な時期に最も費用対効果に優れた方法で顧客、ユーザに現在および今後のニーズに対応できるようにする事。
    キャパシティ計画→ITサービスに必要となるリソースを管理するために使用し、事業の需要を予測したシナリオ及び合意済みのサービスレベルの目標を達成するための原価計算済み代案が含まれるもの。
    事業キャパシティ管理→ビジネスのニーズと将来の事業計画を把握し将来必要となるキャパシティを適切な時期に計画実装すること。
    サービスキャパシティ管理→ITサービスのパフォーマンスとキャパシティを把握することを責務としキャパシティ計画で使用するため各ITサービスで使用するリソースと使用状況を収集し記録し分析する事。
    コンポーネントキャパシティ管理→構成アイテムのキャパシティパフォーマンスを把握することを責務とする。サービスキャパシティ管理に使用するため、データ収集、記録、分析すること。
    4.5 ITサービスの継続性管理
    ITサービスの継続性管理→IT技術及びサービスに必要な設備を要求、合意された時間内に確実に再開できるようにすることで事業計測性管理プロセスを全体を支援する事。
    BCP(Business Continuity Plan)事業継続性計画→ビジネス・プロセス中断後にビジネス・プロセスを回復するために必要なステップを定義した計画でITサービス継続性計画、事業継続性計画の重要な部分を占める。
    BCM(Business Continuity Management)事業継続性管理→事業に深刻なインパクトを与える可能性があるリスクを管理し、組織がいつでも少なくとも事前に定義した最低限のレベルで事業を継続できることを確実にすること。
    BIA(Business Inpact Analysis)ビジネスインパクト分析→サービスが中断することによる事業へのインパクトを定量化すること。
    リスク・アセスメント→事業にとっての資産価値を分析し、資産に対する脅威を識別して脅威に対する各資産の脆弱性を評価する事。
    RA(Risk Analysis)リスク分析→継続性に対する潜在的な脅威とその脅威が現実になる可能性を識別するためのリスク識別のリスクアセスメントの事。
    リスク低減手段→リスクを評価し、事業及びあるいはITサービスの復旧に対する潜在的な要件を低減すること。
    復旧オプション→サービスの中断に対応するための戦略。
    手作業のワークアランド→ITサービスが再開するまでの2.3日間、1時的な措置としてITを使わず手作業でビジネスが回るようにする方法。
    相互協定→類似技術を使用する組織同士が合意し、非常時に助け合う方法。
    段階的復旧(コールドスタンバイ)→復旧時に「場所」だけを用意しておき、非常時に機器を持ち込んでシステムを再開する方法。
    中間的復旧(ウォームスタンバイ)→復旧用に「場所」と「機器」だけを用意しておき非常時にはデータへのバックアップから復旧することでシステムを再開する方法。
    高速復旧(ホットスタンバイ)→復旧用に「場所」と「機器」と「データ」だけを用意しておき非常時にデータの同期をとる事でシステムを再開する方法。
    即時的復旧(ホットスタンバイ)→復旧用に「場所」と「機器」と「データ」と「サービス」を用意しておき、常にデータとシステムの同期をとれているバックアップセンターを用意する事。非常時には即座にサービスが復旧できる方法。
    4.6 可用性管理
    可用性管理→事業と顧客に利益を提供できるように費用対効果の高い方法でITサービス、ITインフラストラクチャ、サポートする組織の可用性を最適化・改善するプロセス。サービス可用性、コンポーネント可用性の2つのレベルがある。
    コンポーネント可用性→サービスを構成するサーバやアプリケーションなどの可用性。
    サービス可用性→サービスそのもの可用性。
    可用性(Availability)→サービス、コンポーネント、構成アイテムが必要とされた時に合意された機能を実行する能力の事。
    可用性(%)=(合意済みサービス時間-停止時間)/合意済みサービス時間×100(%)→可用性の計算式。
    信頼性→サービス、コンポーネント、構成アイテムが中断せず長く合意された機能を実行できるかを示す指標。
    平均サービス・インシデント間隔(MTBSI:Meam Time Between Service Incident)→信頼性を測定・レポートする。
    平均故障間隔(MTBF:Meam Time Between Failures)→信頼性を測定・レポートする。
    平均サービス・インシデント間隔(時間)=使用可能な時間/サービス中断回数→MTBSIの計算式。
    平均故障間隔(時間)=(使用可能な時間-総停止時間)/サービス中断回数→MTBFの計算式。
    保守性→障害発生後、サービス、コンポーネント、構成アイテムが迅速かつ効果的に稼働状態に回復できるかを示す指標の事。
    平均サービス回復時間(MTRS:Meam Time to Restore Service)→保守性を計算する際に使用する。
    平均サービス回復時間(時間)=総停止時間/サービス中断回数→MTRSの計算式。
    サービス性→サードパーティ・サプライヤが持つ契約条件を満たす能力の事で、サードパーティ・サプライヤとの契約には構成アイテムに対して合意したレベルの信頼性、保守性、可用性が記載されている。
    重要ビジネス機能(VBF:Vital Business Function)→ITサービスによって支えられているビジネスプロセスの事業上重要な(欠かすことのできないもの)要素を表にしたもの。
    拡張版インシデントライフサイクル→インシデントのライフサイクルの詳細で検出、診断、修理、復旧、回復の段階がある。インシデントのインパクトを増大させたすべての要因を把握しインパクトをコントロール低減させる方法を計画するときに使用される。
    4.7 情報セキュリティ管理
    情報セキュリティ管理→ITセキュリティと事業セキュリティを整合させること、およびすべてのサービスとサービスマネジメントの活動において情報セキュリティが効率的に管理されている事。
    可用性・気密性・完全性(CIA)→情報セキュリティ管理のプロセスできちんと管理することに焦点をあてている3つのポイント。
    機密性(Confidentiality)→情報を知る権限を持つ人間だけに閲覧可能になっている。また情報を知る権限を持つ人だけに公開される情報セキュリティ管理の概念のひとつ。
    完全性(Intergrtiy)→情報が完全かつ正確で許可されていない修正から保護されていることの情報セキュリティ管理の概念のひとつ。
    可用性(Availability)→必要とするときに、情報を入手および利用可能な事。また情報を提供するシステムが攻撃に対して適切に対処し、障害から復旧、または障害を防ぐことことができる状態の情報セキュリティ管理の概念のひとつ。 
    情報セキュリティ方針→情報セキュリティ管理に対する組織のアプローチを統制する方針の事で情報セキュリティの全領域を網羅し事業とITのトップマネジメントにより認可される。 
    情報セキュリティ管理システム(ISMS:Informaetion Security Management System)→組織が情報セキュリティ管理の達成目標を確実に満たすことができるようにするための方針、プロセス、指針、ツールの枠組み。 
    ISO/IEC27001→情報セキュリティのフレームワークの国際規格。 
    情報セキュリティの管理システムの4つのP→People(人材)、Products(プロダクト)、Process(プロセス)、Partners(パートナー) 
    4.8 サプライヤ管理
    サプライヤ管理→良質のITサービスを事業部門に途切れることなく提供するサービスを管理し投資に見合う価値を得られるようにするプロセス。
    サプライヤ→ITサービスを提供するために必要となる商品またはサービスの供給を責務とするサードパーティのこと。戦略的サプライヤ、戦術的サプライヤ、運用上のサプライヤ、コモディティサプライヤの4つに分類される。
    戦略的サプライヤ→長期的な計画を推進するためにITサービス・プロバイダと戦略に関する機密情報をを共有するサプライヤ。戦略的な機密情報を共有できる上級マネージャーが関与し、定期的な打ち合わせやパフォーマンスのレビューを頻繁に行うサプライヤ。ネットワークのサービスサポートを供給する世界規模のネットワークサービスプロバイダなどが例にあげられる。
    戦術的サプライヤ→重要な商業活動や事業でITサービスプロバイダとやり取りがあるサプライヤ。通常中級マネージャによって管理され定期的な打ち合わせとパフォーマンスのレビューをするサプライヤ。ハードウェアの故障を解決するハードウェアの保守組織や基幹システムのアウトソーサーなど。
    運用上のサプライヤ→運用中の製品やサービスの供給でITサービスプロバイダとやり取りがあるサプライヤ。通常運用現場の責任者である運用マネージャによって管理され頻度は少ないが定期的な打ち合わせとパフォーマンスのレビューを実施する。社内イントラネット向けのウェブサイト運営などインパクトの低いサプライヤ。
    コモディティサプライヤ→ITサービスプロバイダに容易に入手できる製品とサービスを提供するサプライヤ。
    契約→複数の当事者間における法的拘束力のある合意のこと。SLA、OLAとの違いは法的拘束力の有無。
    契約の付則→セキュリティ要件、事業継続性要件、情報開示の合意など。
    サプライヤ契約データベース(SCD:Supplier Contracts Database)→サプライヤの契約のライフサイクル(契約の確立、契約の更新、終了、契約の評価など)を通じてサプライヤの管理に使用するデータベースまたは構造化された文書のこと。各サプライヤが提供するサービス、製品に関する情報、サプライヤとの契約情報など。
    サービスナレッジ管理システム(SKMS)→サプライヤ契約データベースはサービスナレッジ管理システムに含まれITサービスプロバイダに必要な情報を提供する。
    ITサービスの提供戦略の選択肢(ソーシング戦略)→ITサービスの提供形態の選択肢の全体。
    アウトソーシング→ITサービスの提供に必要なリソースを外部組織から調達する事。サービスの設計、開発、運用、保守などを外部組織に委託する。
    インソーシング→ITサービスの提供に必要なリソースをすべて社内でまかなうこと。ITサービスプロバイダ内のスタッフが設計、開発、運用、保守を行う。
    コンソーシング→アウトソーシングとインソーシングを組み合わせた形態。複数の外部組織と社内のリソースを両方使用し、ITサービスを提供する事。ITサービスプロバイダのスタッフが複数の外部組織の協力を得ながらサービスの設計、開発、運用、保守を行う。
    パートナーシップ(マルチソーシング)→専門能力や市場機会を相互に活用するため複数の組織が戦略的に連携し、ITサービスを提供する事。複数の企業の戦略的提携に基づいてサービスを提供する。
    アプリケーション・サービス供給→アプリケーション・サービスプロバイダ(ASP)が提供するアプリケーション(ネットワーク経由で利用可能)をASPと正式に協定を結んで提供される。ネットワーク経由で利用できる営業支援システムなど。
    ビジネスプロセスアウトソーシング(BPO:Business Process Outsourcing)→コストの安い地域にビジネス・プロセス機能をソーシングすること。総務、給与計算関係のデータ入出力を中心とした業務やコールセンタ運用など。
    ナレッジプロセスアウトソーシング(KPO:Knowledge Process Outsourcing)→ビジネス・プロセスや機能をソーシングする点はBPOと同じだが、さらに1歩進めて特殊で高い専門能力が必要なビジネスプロセスや機能をソーシングする。コンピュータのソフトウェアの研究開発部門など。



    このページのトップヘ