MOF 実行概要

[アーティクル]
07/12/2010

Microsoft Operations Framework

ホワイトペーパー

発行 : 2002 年 10 月

概要

「実行概要」ホワイトペーパーでは、Microsoft Operations Framework (MOF) の起源とその設計目標について説明し、MOF のプロセスモデル、チームモデル、およびリスクモデルの概要を示します。このホワイトペーパーは、他の MOF ホワイトペーパーが提供している詳細な情報を理解するための基礎となるものです。発行されているその他のホワイトペーパーについては、MOF Web サイト (https://www.microsoft.com/japan/technet/itsolutions/techguide/mof/default.mspx) を参照してください。

トピック

はじめに
MOF プロセスモデル
MOF チームモデル
MOF リスクモデル
MOF と Microsoft Solutions Framework
開始にあたって
関連情報
寄稿者

はじめに

フレームワークの概要

情報技術 (IT) プロジェクトにより最大限の成果が得られるように、Microsoft では、Microsoft テクノロジを基盤として構築されるソリューションを効果的に設計、開発、展開、運用、およびサポートする方法に関する包括的なガイド機能を提供しています。この知識は、大規模なソフトウェア開発とサービス運用プロジェクト、プロジェクト導入における企業顧客へのコンサルティング経験、世界中の IT 業界からもたらされる最良の知識などに基づく Microsoft の豊富な経験を背景としています。

このガイド機能は、相互補完的な 2 つの統合知識体系 (フレームワーク) に組織化されています。つまり、Microsoft Operations Framework (MOF) と Microsoft Solutions Framework (MSF) です。

MOF は、Microsoft の製品とテクノロジを基に構築された IT ソリューションにおける基幹システムの信頼性、可用性、保守性、および管理容易性を各組織で実現するための技術ガイド機能です。MOF のガイド機能では、複雑な分散異種 IT 環境の運用に関連する要員、プロセス、テクノロジ、および管理の問題を取り扱います。MOF の詳細については、https://www.microsoft.com/japan/technet/itsolutions/techguide/mof/default.mspx を参照してください。

もう 1 つのフレームワークである MSF では、さまざまな規模の組織またはプロジェクトチームのニーズを満たす柔軟性に富みスケーラブルな方法が提供されます。MSF ガイド機能は、要員、プロセス、およびテクノロジの各要素と、大部分のプロジェクトで問題となるこれらの要素の取捨選択を管理するための原則、モデル、および運用規則で構成されます。このガイド機能により、効果的な IT ソリューションを計画、設計、開発、および展開する際に役立つ実証済みの実践方法が示されます。MSF の詳細については、https://www.microsoft.com/msf/ (英語) を参照してください。

IT のライフサイクル

IT テクノロジに基づくサービスを提供するためには、次の 2 つの重要な作業を IT 要員が実行する必要があります。

サービスに対するニーズの把握とソリューションの開発
サービスを提供するソリューションの運用

Microsoft の 2 つのフレームワーク (MSF と MOF) では、MSF が最初の項目 (ニーズの分析と付加価値の高いソリューションの開発) に対応し、MOF が次の項目 (IT サービスの現状に基づくソリューションの運用) に対応します。

2 つのフレームワークは相互に補完し合うことで、価値実現までの時間、つまり、ニーズの把握からサービスの提供までに要する時間を最小化します。これらのフレームワーク間の用語と概念に一貫性があることも、高品質なサービスを提供する際に役立ちます。

MSF と MOF では、新しいソリューションを開発および運用する際に、次の 4 つの基本的手順に従います。

新しいビジネス要件を定義します。
MSF と MOF を使用してソリューションを開発および展開します。
MOF を使用してソリューションを運用します。
繰り返し改善作業を行います。

現在導入中のソリューションに変更を加える場合は、運用要件、新しいビジネス要件、または規制的要件がその起点となりえます。

Microsoft の IT ライフサイクルにより、IT サービスの費用効率の高い円滑な提供を目的として、IT 組織で発生する各種の活動がそれぞれ位置付けられ、相互に関連付けられます。MOF と MSF は、IT ライフサイクルにおいて、別個でありながら相互に不可分であるフェーズにそれぞれ対応します。各フレームワークでは、それぞれの領域内で成果を得るために必要な要員、プロセス、およびテクノロジに関する有益で詳細な情報が提供されます。MSF と MOF には、有効な IT ソリューションを効果的かつ効率的に実現および運用するための、測定と繰り返し実行が可能な一貫性のあるプロセスが含まれます。

図 1: ビジネスニーズを満たすために連携する MSF と MOF

図 1: ビジネス ニーズを満たすために連携する MSF と MOF

MOF と ITIL

IT サービス管理における現時点での業界のベストプラクティスは、英国の政府調達庁 (OGC : Office of Government Commerce) により IT インフラストラクチャライブラリ (ITIL : IT Infrastructure Library) としてドキュメント化されています。

OGC は、サービス管理と運用における情報技術の使用に関して、ベストプラクティスとなるアドバイスと推奨事項の策定を担当する英国政府機関です。

この目的を実現するために、OGC は、世界中の主導的な IT 企業と共にさまざまなプロジェクトを認定し、IT サービス管理の運用規則に関するベストプラクティスをドキュメント化および検証しています。ITIL には、現在 40 を超えるドキュメントがあります。各ドキュメントは、IT サービス管理における 1 つの機能に対応しており、他のドキュメントとの相互参照も含まれます。

MOF は、共同作業によって作成されたこれらの業界標準を、Microsoft の製品やテクノロジを利用する際の具体的なガイドラインに結び付けるものです。また MOF では、アプリケーションホスティングや Web ベースのトランザクションシステム、Web ベースの電子商取引システムなど、分散 IT 環境や業界のトレンドに対応できるように、ITIL の作業標準が拡張されています。

設計上の検討事項

MOF は次の目標を達成するように設計されました。

実証済みの概念を使用します。
業界のベストプラクティスを活用します。
運用知識に対して拡張可能な基盤を提供します。
要員、プロセス、およびテクノロジの問題に対処します。
顧客、パートナー、Microsoft Global Operations & Technology グループ (以前の ITG)、および Microsoft 製品とサービスの各組織からの情報を統合します。
ビジネスが変化する環境に迅速に適合できるように、IT の機敏性を向上します。
Microsoft Solutions Framework と一体化し、IT ライフサイクルの他の部分を管理します。
サーバーやテクノロジの単なる管理ではなく、プロセスと手順を視野に入れながら、エンドツーエンドサービスの管理をサポートします。

MOF のモデル

MOF は、次の 3 つのモデルにより構成されます。

プロセスモデル
チームモデル
リスクモデル

この 3 つのモデルにより、IT サービス管理での要員、プロセス、およびリスク管理に関するガイド機能が提供されます。各モデルでは、Microsoft プラットフォームを基盤とするシステムにおいて、高度な可用性、信頼性、保守性、および管理容易性を実現するためのテクノロジとベストプラクティスの確立に重点が置かれます。また、他のテクノロジプラットフォームとの相互運用性に関するガイド機能も提供されます。

MOF プロセスモデル

概要

運用のためのプロセスモデルは、運用チームが IT サービスの管理と保守を行うために実施するプロセスの機能モデルです。その意味で、複雑な IT 環境について検討するための、簡素化された汎用的な手段を提供します。

起源

プロセスモデルは、OGC の ITIL (IT Infrastructure Library) を通じてドキュメント化されているベストプラクティスに基づいています。

プロセスモデルでは、運用グループの主な責任を、IT 環境の変更の管理であると仮定しています。サービスのライフスパン全体を通じて変更を取り扱う最も効果的な方法は、関連する変更を "リリース" と呼ばれるパッケージにまとめてグループ化し、変更を 1 単位として計画、管理できるようにすることです。MOF プロセスモデルは、あらゆるリリースに適用可能なライフサイクルを示し、そのライフサイクルの各部分を構成するプロセスや活動を明確にします。

ガイド原則

MOF プロセスモデルは 4 つのガイド原則に基づいています。

構造化アーキテクチャ MOF プロセスモデルは、ミッションクリティカルなコンピューティングに必要とされるあらゆる運用活動を構造化し、ますます複雑化する環境に対してそれらの活動がよりよく対処できるようにするアーキテクチャです。
迅速なライフ サイクル、反復的な改善 IT 運用に対する変更のスピードは加速し続けています。変更に対するこのような要求に直接応えるものとして、競争力維持のための改良や刷新などのビジネスニーズがあります。その結果、MOF には、変更を迅速に取り込むことのできる能力と、全般的な運用環境を継続的に査定し改善することのできる能力の両方をサポートする、反復的なライフサイクルの概念が取り入れられています。
レビュー主導の管理 プロセスモデルには、ライフサイクルにおいて鍵となるポイントごとにレビューが設けられています。レビューでは、チームがリリースベースの活動や定常的または日常的な運用活動について、その成果を評価します。このような主要なレビューによって、上位の管理部門からの意見が重要視される場合にそれらを取り込むことができるようになります。
組み込み型のリスク管理 今日の IT 運用は従来よりも重要で複雑なものになっており、運用上の障害や失敗は世界中の顧客や IT ユーザーに対してますます隠し難いものになっています。このことは、運用によってビジネスが失敗することのないように、運用におけるリスク管理がきわめて重要になっていることを意味します。

用語

プロセスモデルをより具体的に議論するのに役立てるため、いくつかの特別な用語をここで定義します。これらの多くは既存の ITIL 用語に基づいています。

サービス ソリューション IT が組織に提供する能力。例として、メッセージング、業務用アプリケーション、データストレージ、印刷などがあります。
リリース 運用チームが 1 単位として本稼動環境に導入する、変更のグループ。各リリースは独自のライフサイクルを持ち、通常 1 つのリリースの終わりは次のリリースの始まりとなります。
IT サービス管理 ミッションクリティカルな IT サービスの品質を確保して顧客に即したサービスレベルを満足するための、プロセスの構造化セットに対して適用される概念。
サービス管理機能 (SMF) ほとんどのサービスソリューションに共通していて、各リリース中に発生する、20 個のプロセス。例として、変更管理、リリース管理、サービスデスク、キャパシティ管理、セキュリティ管理などがあります。各 SMF は、今日の IT 環境に見られるサービスソリューションのスイート全体にわたって適用される、一貫したポリシー、手続き、標準、およびベストプラクティスを提供します。
サービスの役割 SMF は 4 つのカテゴリに分類され、それぞれサービスの役割により定義されます。たとえば、変更管理、構成管理、およびリリース管理について、SMF は変更を特定、承認、制御し、IT 環境にリリースするためのサービスの役割をサポートしています。
作業領域 サービスの役割を共有する SMF の略称。変更、運用、サポート、および最適化。作業領域にはそれぞれ複数の SMF があります。
運用管理レビュー 重要な管理レビューは 4 つの作業領域それぞれに対して特定されます。レビューは、各作業領域に対する重要な運用チェックポイントを表します。

MOF プロセスモデルは、あらゆるサービスソリューションに関連するあらゆる規模のリリースに適用できるライフサイクルを示しています。次の図はこのライフサイクルを示したもので、4 つの作業領域と 4 つのレビューがあります。

図 2: MOF プロセスモデル

図 2: MOF プロセス モデル

各作業領域に対するサービスの役割とレビューを、次の表に示します。

作業領域	サービスの役割	レビュー
変更	新しいサービスソリューション、テクノロジ、システム、アプリケーション、ハードウェア、およびプロセスの導入	リリース準備
運用	日常作業の効果的かつ効率的な実行	運用
サポート	障害、問題、および照会に対する迅速な解決	サービスレベル契約 (SLA)
最適化	IT サービス提供におけるコスト、パフォーマンス、キャパシティ、および可用性を最適化するための変更の推進	リリース承認

レビューのうち 2 つはリリーススケジュールによって推進されます。リリース承認レビューは、変更の開発とリリースに関する正式な作業が始まる前に行われ、リリース準備のレビューは変更を本稼動環境にリリースする前に行われます。運用レビューとサービスレベル契約 (SLA) レビューは、社内の運用作業と顧客サービスレベルに対する実績を査定するために、リリースの導入後定期的に行われます。

MOF の SMF の多くは OGC の ITIL (IT Infrastructure Library) に基づいています。ただし、運用作業領域における要員管理 (最適化作業領域内) とそのすべての SMF は、特筆すべき例外です。ITIL はプラットフォームに依存しないため、これらの項目については網羅していません。

結果として、運用作業領域については、Microsoft の製品やテクノロジに固有の運用作業のガイダンスについて、MOF がそれらの大部分を提供しています。また、Microsoft の IT 運用に対する取り組みのために、現在多くの製品において、それらの製品の保守性、信頼性、そして管理容易性を高めることを直接の目的としたさまざまな機能が取り入れられています。適用可能であれば、SMF の提供の自動化または改善のどちらかを行う Microsoft の製品や機能を具体的に参照できるように、MOF において ITIL の基礎的な IT SMF が拡張されています。

これらの IT SMF はベストプラクティスであり、ある特定の運用環境についてその独自の要件や具体的な要件に対応するように、カスタマイズを行う必要があります。

作業領域の詳細

ここでは、MOF プロセスモデルの 4 つの作業領域がスパイラル状のリリースライフサイクルの中でどのように連結しているのかについて説明します。この説明では、リリースが既に承認、開発され、本稼動環境に導入するための準備が整っていると仮定しています。説明を始める概念的な出発点として、IT ライフサイクルの中の多数の点が考えられますが、ここでは次の点から始めるのが最も直感的といえます。

変更

この作業領域に続いてリリース承認レビューが行われ、提案された変更が開発され導入されます。次に示す SMF は、変更の開始、開発、および導入の各プロセスを管理する役割を担います。

変更管理 悪影響を緩和または解消するため、変更を導入する前に、影響を受けるすべてのシステムとプロセスを特定します。
構成管理 主な IT コンポーネントまたは資産について、それらの記録、追跡、および報告を特定します。
リリース管理 ソフトウェアおよびハードウェアの各リリースの導入を促進し、それらが確実に計画、試験、および実装されるようにします。変更および構成の管理プロセスと密接に連携し、共有構成管理データベース (CMDB) が最新になることを保証します。

リリースを本稼動環境に導入する際は、その前にリリース準備のレビューで "ゴーサイン" の決定を取得する必要があります。リリースが完了すると、"実装後のレビュー" によって、リリースの成否と変更作業領域プロセスの実効性が評価されます。

運用

導入が成功すると、ここでリリースが稼動状態になります。そして、次に示す SMF によって、システムを稼動するための日常活動が開始されます。

セキュリティ管理 セキュリティ制御を開発、実装、および管理することにより、安全なコンピューティング環境を維持する役割を担います。
システム管理 企業システムの稼動を維持する日常業務を遂行し、計画リリースの影響を査定する役割を担います。
ネットワーク管理 組織のネットワークを構成する物理コンポーネント (サーバー、ルーター、スイッチ、ファイアウォールなど) を設計、保守する役割を担います。
サービスの監視および制御 IT サービスの健全性を監視し、必要ならば基準の維持のために措置を講じます。
ディレクトリ サービス管理 企業ディレクトリを日常的に運用、保守、およびサポートする役割を担います。
記憶域管理 データの復元と履歴アーカイブを目的としてオンサイトおよびオフサイトのデータストレージを取り扱い、バックアップやアーカイブの物理的なセキュリティを確保します。
ジョブのスケジュール設定 バッチ処理作業をさまざまな回数で割り当て、システムリソースの使用率を最大限高めると同時に、ビジネス機能やシステム機能が汚染されないようにします。
印刷および出力管理 ビジネス出力に関連するコストやリソースを管理し、機密性のある出力のセキュリティを確保します。

運用のレビューは定期的に行われます。内部的には、IT スタッフが対象となるサービスを保守できているか、サービスレベル要件を満たしているか、および、スタッフの経験をナレッジベースにドキュメント化できているかについて、主にレビューが行われます。

サポート

日常の運用作業が始まった後は、必ずといっていいほど問題が発生します。次に示す SMF の目的は、エンドユーザーの障害、問題、および照会について、それらをタイムリに解決することです。

サービス デスク IT サービスの利用に関連する問題について、最前線のサポートをユーザーコミュニティに提供します。
障害管理 検出から記録、調査、診断、そして解決に至るまでの、障害のライフサイクルを管理します。
問題管理 IT サービスレベルに影響を及ぼす障害や中断について、それらの根本原因を調査し解決します。

SLA レビューは定期的に行われ、スタッフがサービスレベル契約で定義されているサービスレベル要件を満たしているかどうかが評価されます。スタッフは、レビューに失敗した分野に対応するために修正的な措置を実施したり、サービスレベル契約内の変更について交渉したりします。また、障害管理や問題解決のプロセスによって、変更が特定の運用プロセス、ツール、および手続きに反映されます。

最適化

前の 2 つの作業領域の SMF は、本稼動環境の維持、障害や問題の解決など、日常の運用作業を中心としています。最適化作業領域では、SMF の観点がより事前対応的になり、現在の実績を評価し、将来のニーズを予測します。したがって ITIL では、他の作業領域の SMF は運用的なものとして分類され、最適化作業領域は戦略的なものとして分類されています。これらの SMF を次に示します。

サービス レベル管理 IT サービスプロバイダとその顧客間でサービスレベル契約の交渉、監視、および維持を行うことにより、IT サービスの品質を管理します。
キャパシティ管理 IT サービスおよびインフラストラクチャの計画、サイジング、および制御を行い、サービスレベル契約に規定された実績レベルの範囲内でユーザーの要求を満たすようにします。
可用性管理 情報とサービスの可用性を、合理的なコストで、同意済みの品質レベルに従って、明確化、管理、および指示し、事前対応的に維持します。
予算経費管理 財源を管理し、組織上の目標を支援します。予算経費管理には、原価計算、予算編成、プロジェクト投資査定などが含まれることがあり、組織によっては原価回収が含まれる場合もあります。
要員管理 IT 要員の採用、雇用、維持、および動機付けを行うためのベストプラクティスを勧告します。
サービス継続性管理 ミッションクリティカルなシステムのサービス中断を最小限に抑えるのに必要な手続きとコンポーネントに着目します。また、IT 災害への対処とその復旧のための計画についても把握しておきます。

これらの SMF によって、コストを低減しつつ、サービスレベルの維持または改善をもたらす変更 (新しいリリース) が定義、生成されます。リリース承認レビューは、提案されたこれらの変更に対する最終的なレビューになります。このレビューの後、変更作業領域の SMF を始点とする新しいサイクルが開始します。

要約

次の図はリリースのライフサイクルを示したもので、4 つの作業領域と 4 つのレビュー、そして 20 の SMF があります。

図 3: MOF プロセスモデルと SMF

図 3: MOF プロセス モデルと SMF

MOF チームモデル

概要

ミッションクリティカルなシステムは複雑です。そのため、プロセスモデルの SMF に示したように、それらのシステムの稼動を維持するのに必要な活動もまた複雑になります。これらの活動やプロセスを実行するためには、運用チームに携わる人員が適切に組織化され配置されている必要がありますが、作業の複雑さがこのような目標の達成を困難にしています。MOF チームモデルは、チームの役割の全体像を簡素化し、管理部門が人員の効率的な組織化に専念できるように支援する、有益な手段です。

MOF チームモデルでは、このような作業を遂行するために IT サービス管理のためのガイドラインを使用します。このガイドラインは、これまで成功を収めたあらゆる規模の IT 運用組織に見られる数々の品質目標を基に作成されています。

MOF チームモデルは次の事柄を明確にします。

運用チームを構造化するためのベストプラクティスの役割クラスタ。
各役割クラスタの主な活動と能力。
チームをさまざまな規模や種類の組織にスケーリングする方法。
どの役割どうしを効果的に組み合わせることができるのか。
Microsoft プラットフォームの分散コンピューティング環境を稼動し運用するのに役立つガイド原則。
MOF チームモデルと MSF チームモデルとの関係。

起源

Microsoft では MOF チームモデルを作成するにあたり、MSF の進化を通じて学習された教訓を利用し、組織構造とプロセス所有権に対応した ITIL のベストプラクティスを基礎として、パートナー、顧客、および Microsoft の社内 IT グループで使用されている重要な成功要因をモデリングしました。

MOF チームモデルの重要な側面として、分散システムを管理している分散チームの適用性があります。コンピューティング環境自体が集中化されていたころは、チームのメンバは一般に同じ会社に所属し、同じ施設内で作業をしていたため、プロセス管理の集中化は容易でした。しかし、今日分散コンピューティングを管理しているチームは、しばしば地理的に離れた地域やタイムゾーン、または企業にわたって分散しています。このためプロセスの所有権の集中化が従来よりも難しく、運用チームを構造化するためにしばしば新しい手段が必要になります。MOF および ITIL のベストプラクティスを活用すると、IT グループは責任の共有に向けた移行作業に取り組むことができます。

ガイド原則

効率的な運用チームを首尾よく編成するためには、役割と責任を単に明確化するだけでは不十分です。また、文化的な価値感覚を植え付ける共有の原則や、チームがどのように機能すべきかを規定するガイドラインを設けることが必要になります。MOF チームモデルのための 5 つの基本的な原則とガイドラインを次に示します。

優れた顧客サービスを提供
ビジネスの優先順位を理解し、IT によってビジネスの付加価値を実現
相乗効果をもたらす、強固な仮想チームを編成
IT オートメーションと知識管理ツールを活用
優秀な IT 運用スタッフを採用、教育、および維持

チームの役割クラスタ

MOF チームモデルは、運用チームがいくつかの重要な品質目標を首尾よく達成する必要があるという経験に基づいて作成されています。チームモデルの役割クラスタは、活動とプロセスについて 6 つの一般的なカテゴリを定義するものです。役割クラスタの中のプロセスはすべて同じ品質目標を支援します。役割クラスタとは共通の目標を共有する活動のグループである、という認識を持つことが重要です。役割クラスタはジョブの説明ではなく、何らかの組織図を暗示するものではありません。

役割を実行する人員の数は役割によって大きく異なります。大規模な組織では、1 つの役割の中にある 1 つのプロセスの実行が、機能遂行チーム全体に割り当てられる場合があります。たとえば、運用の役割の中にあるいくつかのプロセスのうちの 1 つであるデータベースの管理に、十数人の人員が専念することが考えられます。これら十数人の人員は、プロセス所有者が率いる仮想のプロセスチームの一部になることもあり、複数の国や地域、タイムゾーンに及ぶこともあります。

小規模の組織では、複数の役割を組み合わせることが必要になる場合があります。たとえば、小さな支店に所属する 1 人の人員が、セキュリティの役割とインフラストラクチャの役割の両方にあるすべてのプロセスについて責任を担うことが考えられます。

次の図では、典型的な運用組織において、6 つの役割クラスタを数十余りの機能役割または機能遂行チームに対応付けています。以降、これら 6 つの役割クラスタについて詳しく説明します。

Dd283231.mofeo04s(ja-jp,TechNet.10).gif

図 4: MOF チームモデルと、機能役割または機能遂行チームの例
拡大表示する

リリース

運用チームは、既存のリソースを特定し、それらを詳細なレベルで追跡して、プロセスを明確にドキュメント化し、変更の履歴を管理する必要があります。この目標を達成するため、リリースの役割クラスタは通常、企業のナレッジベースで学習される変更と教訓を追跡し、構成管理データベースのインベントリと変更を追跡します。また、この役割クラスタは変更開発チームと運用グループとの主要な連絡役となり、構成管理に関する ITIL 規則、およびソフトウェアの管理と配布に関する ITIL 規則が含まれます。

インフラストラクチャ

効果的な IT 運用を行うには、物理的な環境標準の明確な定義、物的資産の管理、IT インフラストラクチャの保守、そしてアーキテクチャの進化の予測が必要です。インフラストラクチャの役割クラスタは主にこれらの作業を担います。インフラストラクチャの役割クラスタは、エンドツーエンドサービスの土台となるビルディングブロックを選択、管理し、共通または共有のデータを管理することによって、これらの目標を達成します。また、施設や事務所の移転、拡張、および買収を支援し、配線、ラボスペース、ユーザー接続手段などの物理環境の変更を支援します。

サポート

IT 運用グループにとって真の "サービス精神" を持つことが、これまでにも増して重要になっています。これは、テクノロジシステムのユーザー自身が、従来よりも技術的に経験豊かになり、システムやそれらをサポートする人員に対して従来よりも大きな期待を持っているからです。チームの成功によって、社内外の顧客に対して高い水準のサポートを設定し、満足することが可能になります。これがサポートの役割クラスタが行うことです。

運用

運用チームは、日常の定期的な作業が高い信頼性で実行されることを保証する必要があります。運用の役割クラスタは、熟練した専門担当者の手によってこの目標を達成します。専門担当者は、メッセージング、システム管理、テレコミュニケーション、ネットワーキング、データベース管理などテクノロジ分野や本稼動システムを主に取り扱います。その他の役割として、データのバックアップ/アーカイブ/格納、出力の管理、システムの監視、イベントログの管理、ファイルおよび印刷サーバーの管理など、スケジューリングされた反復可能なプロセスがあります。

パートナー

IT サービスを提供するためには、他の企業との提携がますます必要になります。相互に利益をもたらす低コストな手段でこれらの提携関係を定義し管理していくことは、関与するすべての企業の成功にとってたいへん重要なことであり、これがパートナー役割が行うことです。パートナーの役割クラスタには、社外の当事者との関係と、当事者どうしの関係の両方について担当する、社内管理者が設けられます。

セキュリティ

この役割クラスタの主な目標は、データの機密性、整合性、および可用性を確保することです。セキュリティの役割クラスタの専門担当者はこれらの目標を達成するため、テクノロジを利用するだけでなく、ビジネスポリシーの周知も行います。このようなビジネスポリシーには、たとえば従業員が退社するときに従うべき退出手続きの定義などがあります。

プロセスモデルとチームモデルとの関係

チームの役割クラスタは、次の図に示すように、通常 MOF プロセスモデルの 4 つのプロセス作業領域に対応します。複数の役割が 1 つの作業領域に関与したり、1 つの役割 (仕入業者やセキュリティなど) が複数の作業領域に関与したりする場合があることに注意してください。

図 5: MOF チームの役割クラスタとそれらの MOF プロセスモデルへの対応

図 5: MOF チームの役割クラスタとそれらの MOF プロセス モデルへの対応

MOF リスクモデル

概要

運用のためのリスクモデルは、運用スタッフが日常的に直面する問題に対して、実証済みのリスク管理技術を適用するものです。リスクの管理については数多くのモデルやフレームワーク、そしてプロセスがあります。これらはすべて不確定な将来に対する計画に関するものであり、運用のためのリスクモデルもまた例外ではありません。しかし、このモデルは、その主要な原則、カスタマイズされた用語、構造化された反復型の 5 段階のプロセス、より大きな運用フレームワークへの統合によって、他の多くのモデルよりも優れた価値を提供します。

起源

運用のためのリスクモデルは、組織が自身の業務を Microsoft プラットフォーム上で遂行しながら、リスク管理のためにフレームワークを活用できないかという顧客からの要望に応えるために開発されました。Microsoft Solutions Framework では広範囲に適用可能なリスクモデルが定義されました。これらは、特にソフトウェアの開発および導入のプロジェクトなど、プロジェクトの遂行中に必要となるリスク管理に対応するように、その説明がカスタマイズされます。運用のためのリスクモデルは、MSF リスクモデルをその基礎とし、運用グループのニーズに対応できるように拡張とカスタマイズがなされています。

ガイド原則

運用のためのリスクモデルでは、運用におけるリスク管理を首尾よく実現するために、次に示す原則が提唱されています。

リスク **を継続的に査定します。**つまり、チームは新しいリスクがないか常に調査究明に努め、既存のリスクを定期的に再評価する、ということを意味します。
**リスク管理をすべての役割およびすべての機能に統合します。**つまり、高いレベルにおいて、すべての IT の役割がリスク管理の責任の一部を共有し、すべての IT プロセスをリスク管理を念頭に設計することを意味します。
**リスクの特定を積極的に進めます。**リスク管理が成功するためには、チームメンバは報復や批判を恐れることなく、リスクの特定に積極的に取り組む必要があります。
リスク **ベースのスケジューリングを採用します。**環境を維持するために、しばしばいくつかの変更を順番に加えることがあります。チームは、リリースのできない変更については可能な限り危険の最も大きい変更を先に加えて、時間やリソースの無駄を避けます。
**受け入れ可能なレベルの形式的手続きを確立します。**成功のためには、チームが理解し採用できるプロセスが必要です。

これらの原則は "事前対応" という言葉にまとめられます。事前対応的なリスク管理を実践しているチームでは、リスクは運用の中の正常な一部分であると認識され、リスクを恐れるのではなく、将来へ備えるための機会として捉えられます。チームメンバは、計測と反復が可能な、目に見えるかたちの継続的なプロセスを採用することによって、事前対応的な思考態度で作業に臨みます。そしてこれらのプロセスを通じてリスクや機会を客観的に評価し、リスクの原因や兆候に対処するための措置を講じます。

リスク管理プロセス

次の図は、識別、分析、計画、追跡、および制御という、リスク管理プロセスの各手順を示しています。ここで重要なことは、個々のリスクがこれらすべての手順を少なくとも一度は通過し、場合によっては何回も循環することがある、ということを理解することです。また、リスクにはそれぞれ独自のタイムラインがあるため、複数のリスクが任意の地点で同時に個々の手順に留まることもあります。

図 6: リスク管理のプロセス

図 6: リスク管理のプロセス

リスクプロセスには次のようなリスクリストが含まれます。

リスク査定ドキュメント 最初の 3 つの手順では、特定のリスクに関する情報を収集し、それをリスク査定ドキュメントに追加します。残りの 2 つの手順では、このドキュメントを意思決定支援に利用します。
上位リスク リスト このリストは、チームの限られた時間とリソースを投入するのに十分値するような、少数の重要なリスクを特定します。
無効リスク リスト リスクは、無害になった時点で必ずマスタリスクリストから無効リスクリストに移します。このリストは、チームが将来利用できるように履歴参照としての役割を果たします。

プロセス内の 5 つの手順を次に示します。

手順 1. 識別リスクの発生源、障害モード、条件、運用上の結果、および業務上の結果を調べます。
手順 2. 分析リスクの発生可能性と影響を調べ、それらの情報を利用してリンク相互間の格付けに役立つ指数を計算します。
手順 3. 計画リスクを完全に回避する軽減策を定義する。または、リスクを別の当事者に転嫁します。あるいは、影響や発生の可能性、またはそれら両方を軽減します。リスクが発生した場合に実行すべき緊急策を定義します。リスクがまさに発生しようとしていることを示すトリガを定義します。
手順 4. 追跡リスクのどのような要素が時間と共に変化しているのかを示す情報を収集します。
手順 5. 制御特定の変化に対して、計画された対応策を実行します。たとえば、トリガの値が真になった場合に、緊急時の計画を実行します。リスクが有害でなくなったら、それを無効にします。影響が変化した場合には、"分析" 手順を繰り返して影響を再評価します。

例

企業のメッセージングサービスにおいて、運用の役割を担当し、可用性管理を実行している人物が、合併に伴う人員削減によってグループの要件を満たすことができなくなる、と判断したとします。

リスクコンポーネント	説明
リスクの発生源 :	テクノロジ (その他の選択肢としては、人員、プロセス、外部) など。
障害モード :	パフォーマンス (その他の選択肢としては、コスト、機敏性、セキュリティなど)。
条件 : この条件で将来を予測した場合。	電子商取引 Web サーバーの単体電源が障害を起こします。
運用上の結果 : 次のような事態となって運用に支障を来たします。	新しい電源を購入。技術者は新しい電源の設置に専念し、他の作業を保留します。
業務上の結果 : 次のような事態となって業務全体に支障を来たします。	顧客がサイトを利用できなくなり、自社に対する顧客の印象が悪くなります。競合他社のサイトに切り替え、そのまま戻ってこなくなる顧客も発生します。
発生可能性 : 条件が発生する可能性は。	最初の 3 年のサービス提供年間で月あたり .001 (1,000 分の 1)。
影響 : 業務上の結果に伴う影響。	1 から 10 までのスケール (1 を最小) で考えた場合、この企業における業務上の結果は 8 と推定されます。
指数 : 発生可能性に影響を乗算した結果。	.008
軽減策 : 条件が発生する前に、次のような手段によって影響や発生可能性の軽減を試みます。	診断を実施し、古い電源を故障前に交換することで、発生可能性を軽減します。冗長電源を備えたサーバーに切り替えることによって、また、予備をすぐに利用できるように準備しておくことでダウンタイムを最小限に抑えることによって、電源に関する単一障害発生地点の影響を軽減します。
トリガ : 条件がまさに発生しようとしている場合 (しかしまだ発生はしていない場合)、次の理由によってその兆候を認識します。	定期的な診断により、信頼性の低下傾向が見られ、ある特定のしきい値に達した場合に、条件がまさに発生しようとしていると見なします。実際にいつ障害が発生したのかは自動監視ユーティリティにより示されます。
緊急策 : この条件を回避できない場合は、次のようにしてトリガに対応します。	電源をすぐに予備と交換します。使用できる電源がない場合は、優先順位の低いサービスをサポートしているサーバーをダウンし、その電源を電子商取引 Web サーバーに設置します。

MOF と Microsoft Solutions Framework

MSF と MOF はどのように連携するのか

IT ソリューションの開発と導入には、通常 2 つの IT チームが関与します。その 1 つであるプロジェクトチームは、限られた時間内でソリューションを計画、開発し、導入するために召集されます。MSF はこのようなプロジェクトチームのガイドとなるように設計されています。一方、運用チームは永続的であり、ソリューションの日常の運用作業と将来の進化について担当します。MOF はこのような運用チームのガイドとなるように設計されています。

2 つのフレームワークは、プロジェクトチームのソリューションをその導入後に効果的かつ効率的に運用できることを保証するように、変更の開始から相互に関係する必要があります。

MSF チームモデルにはリリースの役割が含まれており、開発された変更をリリースパッケージに統合し、円滑に導入して、効果的に運用できることを保証します。通常、リリース管理では変更開発チームに関するリリースの役割が履行されます。この作業は、新しいアプリケーションであれ、またはインフラストラクチャの変更であれ、その種類に関係なく発生します。

開発チームがリリース管理に参加することで、変更が運用性および保守性を目的として作成されることが保証され、リリース要件を満たすことが保証されるのに役立ちます。この役割には運用作業領域およびサポート作業領域からの意見が取り入れられることもあります。

開始にあたって

どこからでも始められ、どこにでも進める

IT 組織では、MOF の適用を自環境内のどこからでも始めることができ、それから他の分野に広げることができます。しかし、MOF のベストプラクティスガイダンスが適用される利点の最も大きい分野を判断するうえで、組織は MOF の運用評価を作業の開始点として利用できます。組織ではしばしば、ヘルプデスクやサービスデスク、可用性などの分野を上位の問題分野として対応することがありますが、これらは一般に兆候的な現象であり、実際には変更管理やリリース管理が根本的な問題となります。運用評価を実施することは、IT サービスレベルに影響を与えている潜在的な問題分野を具体的に特定するのに役立ちます。

寄稿者

主な著者

Bret Clark、Microsoft Corporation

Neil Fairhead、Microsoft Corporation

Kathryn Rupchock Pizzo、Microsoft Corporation

編集者

Laurie Dunham、Microsoft Corporation

その他の寄稿者

Bill Bagley、Microsoft Corporation

Anthony Baron、Microsoft Corporation

Mary Anne Blake、Microsoft Corporation

Jeff Yuhas、Microsoft Corporation

このドキュメントに記載されている情報は、このドキュメントの発行時点におけるマイクロソフト側の見解を反映したものです。変化する市場状況に対応する必要があるため、このドキュメントは、記載された内容の実現に関するマイクロソフトの確約とはみなされないものとします。また、発行以降に発表される情報の正確性に関して、マイクロソフトはいかなる保証もいたしません。

このホワイトペーパーに記載された内容は情報提供のみを目的としており、明示または黙示に関わらず、これらの情報についてマイクロソフトはいかなる責任も負わないものとします。

お客様は著作権に関する法律を遵守する必要があります。このドキュメントのいかなる部分も、米国 Microsoft Corporation の書面による許諾を受けることなく、その目的を問わず、どのような形態であっても、複製または譲渡することは禁じられています。ここでいう形態とは、複写や記録など、電子的な、または物理的なすべての手段を含みます。ただしこれは、著作権法上のお客様の権利を制限するものではありません。

マイクロソフトは、このドキュメントに記載されている内容に関し、特許、特許申請、商標、著作権、またはその他の無体財産権を有する場合があります。別途マイクロソフトのライセンス契約上に明示の規定のない限り、このドキュメントはこれらの特許、商標、著作権、またはその他の無体財産権に関する権利をお客様に許諾するものではありません。

Microsoft は、米国 Microsoft Corporation の米国その他の国における登録商標です。

記載されている会社名、製品名には、各社の商標のものもあります。

MOF 実行概要

トピック