アベイラビリティ : ハイ アベイラビリティ

サービス レベル管理:ベスト プラクティス White Paper

2005 年 10 月 4 日 - ライター翻訳版
その他のバージョン: PDFpdf | 機械翻訳版 (2013 年 8 月 21 日) | 英語版 (2005 年 10 月 4 日) | フィードバック

目次

概要
サービスレベル管理の概要
      重要な成功要因
      パフォーマンス指標
      サービスレベル管理のプロセス フロー
サービスレベル管理の実装
      ネットワーク サービス レベルの定義
      SLA の作成と維持
サービスレベル管理のパフォーマンス指標
      サービス レベル契約またはサービス レベル定義の文書化
      パフォーマンス指標の規準
      サービス レベル管理のレビュー
サービス レベル管理の要約
関連するシスコ サポート コミュニティ ディスカッション
関連情報

概要

この文書は、ハイアベイラビリティ ネットワークのサービス レベル管理と Service-Level Agreement(SLA; サービス レベル契約)について説明しています。 また、サービス レベル管理の重要な成功要因と、成果を評価するためのパフォーマンス指標について示しています。 さらに、ハイアベイラビリティ サービス チームによって明らかにされた最適な方法のガイドラインに基づき、SLA について詳細に説明します。

サービスレベル管理の概要

ネットワーキング組織ではこれまで、堅固なネットワーク インフラストラクチャを構築し、個々のサービス問題を事後対処的に処理することによって、拡張を続けるネットワーク要件に対応してきました。 ネットワークが停止すると、同じ原因による停止が二度と発生しないように、新しいプロセス、管理能力、またはインフラストラクチャを構築します。 しかし現在では、変化の速度が速くなり、アベイラビリティの要件がしだいに厳しくなっているため、予定外のダウンタイムを未然に防ぎ、ネットワークを迅速に復旧するための改良されたモデルが必要とされています。 多くのサービス プロバイダーや企業組織が、ビジネス目標の達成に必要なサービス レベルの定義を改善するように努めてきました。

重要な成功要因

SLA の重要な成功要因は、実現可能なサービス レベルを首尾よく確立し、維持するための主要要素を定義する際に使用します。 重要な成功要因として認められるには、プロセスまたはプロセスのステップが SLA の品質を向上させ、ネットワーク アベイラビリティ全般に対してプラスの効果を与えることが必要条件となります。 また、重要な成功要因は測定できる必要があり、これによって組織では、その成功要因が、定義された手順に対してどの程度成果をあげているかを判断できます。

詳細については、「サービスレベル管理の実装」を参照してください。

パフォーマンス指標

パフォーマンス指標は、重要な成功要因を測定するための仕組みを提供します。 通常はパフォーマンス指標を月に 1 回検討することで、サービス レベル定義または SLA がうまく機能しているかどうかを確認します。 ネットワーク運用グループおよび必須ツール グループでは次の規準を実行できます。

注: SLA を活用していない場合は、次の規準の他に、サービス レベル定義やサービス レベルのレビューを行うことを推奨します。

パフォーマンス指標には、次のようなものがあります。

  • 文書化されたサービス レベル定義または SLA。アベイラビリティ、パフォーマンス、事後対処的なサービス応答時間、問題解決の目標、問題の報告などが定められています。

  • 月 1 回のネットワーキング サービス レベル検討ミーティング。サービス レベルの適合状況を検討し、改善を実施します。

  • パフォーマンス指標の規準。アベイラビリティ、パフォーマンス、優先順位別のサービス応答時間、優先順位別の解決時間、その他の測定可能な SLA パラメータなどが含まれます。

詳細については、「サービスレベル管理の実装」を参照してください。

サービスレベル管理のプロセス フロー

サービス レベル管理の高レベル プロセス フローには 2 つの主要なグループがあります。

  1. ネットワーク サービス レベルの定義

  2. SLA の作成と維持

次の図のオブジェクトをクリックすると、そのステップの詳細情報にジャンプします。

highlevel.gif

サービスレベル管理の実装

サービス レベル管理の実装には 16 のステップがあり、各ステップは次の 2 つの主要カテゴリに分けられます。

ネットワーク サービス レベルの定義

ネットワーク管理者はネットワークをサポート、管理、および測定するための主要規則を定義する必要があります。 サービス レベルはすべてのネットワーク利用者のための目標を定めるもので、サービス全体の品質の規準として使用できます。 サービス レベル定義は、ネットワーク リソース計画を作成するためのツールや、より高度な QoS への資金投入を要求するための証拠としても使用できます。 また、ベンダーおよび通信事業者のパフォーマンスを評価するための手段にもなります。

サービス レベルの定義と測定を行わなければ、組織は明確な目標を設定できません。 サービスの満足度を決めるのはユーザであり、この満足度はアプリケーション、サーバ/クライアント処理、またはネットワーク サポートの間で多少違いがあります。 最終的な結果が組織にとって明確でないため、概算が困難になり、結果的に、ネットワークおよびサポート モデルの改善プロセスにおいて、作成されたモデルが予防的ではなく事後対処的になります。

サービス レベルのモデルを構築し、それをサポートするためには、次のステップに従うことを推奨します。

  1. 技術面での目標と制約を分析する。

  2. アベイラビリティの概算を決定する。

  3. アプリケーションのプロファイルを作成し、重要なアプリケーションのネットワーク特性を詳述する。

  4. アベイラビリティとパフォーマンスの標準を定義し、一般的な用語を定義する。

  5. アベイラビリティ、パフォーマンス、サービスの応答時間、問題解決の平均時間、障害検出、アップグレードのしきい値、報告経路を含めたサービス レベル定義を作成する。

  6. 規準を収集し、サービス レベルの定義を監視する。

ステップ 1: 技術面での目標と制約の分析

技術的な目標と制約の分析に取りかかる際の最もよい方法は、技術的な目標と要件に関するブレーンストーミングまたは調査を行うことです。 この討論には、他の IT 技術担当者を招くのがよい場合があります。これは、各担当者がそれぞれ自身の担当するサービスについて個別の目標を定めているためです。 技術的な目標には、アベイラビリティ レベル、スループット、ジッタ、遅延、応答時間、スケーラビリティに関する要件、新機能の導入、新規アプリケーションの導入、セキュリティ、管理性、コストの安定化などが含まれます。 続いて、使用可能なリソースが与えられたという仮定のもとに、これらの目標を達成するための制約を調査します。 それぞれの目標と、それに対する制約の説明を記述したワークシートを作成します。 最初は、ほとんどの目標が達成不可能であるように思われるかもしれません。 この場合は目標に優先順位を設定するか、ビジネス要件から外れない範囲で期待を下方修正します。

たとえば、アベイラビリティ レベルを 99.999 %(1 年当たりのダウンタイムが 5 分)に設定したと仮定します。 この目標を達成するには数多くの制約があります。たとえば、ハードウェアのシングル ポイント障害、リモート ロケーションで故障したハードウェアの Mean Time To Repair(MTTR; 平均修理時間)、通信事業者の信頼性、予防的な障害検出機能、変更率の高さ、現在のネットワーク キャパシティの制限などが制約として挙げられます。 結果的に、目標を達成可能なレベルに調整しても構いません。 次のセクションで説明するアベイラビリティ モデルは、現実的な目標の設定に役立ちます。

また、ネットワーク内の制約の少ない領域に高いアベイラビリティを提供する案も検討する余地があります。 ネットワーキング組織がアベイラビリティのサービス標準を公開したときに、同じ組織内のビジネス グループの中から、そのレベルは許容できないという声があがる場合があります。 この場合、ここから、SLA に関する議論や、ビジネス要件を満たす引き当てモデルや概算モデルの作成を始めることができます。

技術的な目標の達成に関係する制約またはリスクをすべて明らかにします。 制約には、所期の目標に対する最も大きなリスクまたは影響という観点から優先順位を設定します。 これは、ネットワーク改善イニシアチブに優先順位を設定するときや、制約に対処する際の難易度を判断するときに役立ちます。 制約には次の 3 つの種類があります。

  • ネットワーク テクノロジー、復元力、および設定

  • ライフサイクル規約(計画、設計、実装、運用)

  • 現在のトラフィックの負荷またはアプリケーションの動作

ネットワーク テクノロジー、復元力、および設定に関する制約とは、現在のテクノロジー、ハードウェア、リンク、設計、設定に関係するすべての制限またはリスクのことです。 テクノロジーの制限には、テクノロジー自体によって課される制約も含まれます。 たとえば、冗長なネットワーク環境においてコンバージェンス時間を 1 秒以下にするテクノロジーは今のところ存在しません。これは、ネットワークを通じて音声接続を維持する場合に重要になる可能性があります。 別の例として、地上のリンクをデータが通過できる生の速度が挙げられます。これはおよそ 100 マイル/ミリ秒です。

ネットワーク ハードウェアの復元力に関するリスク調査は、ハードウェア トポロジ、階層、モジュール性、冗長性、および MTBF に的を絞り、ネットワーク内の定義されたパスに従って行います。 ネットワーク リンク制約は企業組織のネットワーク リンクと通信事業者への接続性を中心に取り扱います。 リンク制約には、リンクの冗長性と多様性、メディアの制限、配線のインフラストラクチャ、ローカルループの接続性、長距離の接続性などがあります。 設計についての制約はネットワークの物理設計または論理設計に関係し、機器を設置するためのスペースからルーティング プロトコル実装のスケーラビリティにいたるまで、すべてのものが対象となります。 プロトコル設計とメディア設計は常に、設定、アベイラビリティ、スケーラビリティ、パフォーマンス、およびキャパシティとの関連を含めて検討する必要があります。 また、Dynamic Host Configuration Protocol(DHCP; ダイナミック ホスト コンフィギュレーション プロトコル)、Domain Name System(DNS; ドメイン ネーム システム)、ファイアウォール、プロトコル トランスレータ、ネットワークアドレス変換などのネットワーク サービスに関する制約も検討する必要があります。

ライフサイクル規約は、ソリューションの一貫した展開、問題の検出と修復、キャパシティまたはパフォーマンスに関する問題の予防、およびネットワークの一貫性とモジュール性に関する設定を行う際に使用される、ネットワークのプロセスと管理を定義します。 この領域の検討が必要となるのは、非アベイラビリティの最大の要因が一般に専門知識とプロセスであるためです。 ネットワーク ライフ サイクルとは、計画、設計、実装、運用のサイクルを指します。 これらの各領域内で、パフォーマンス管理、構成管理、障害管理、セキュリティなどのネットワーク管理機能について理解する必要があります。 ネットワークのライフサイクル アセスメントは Cisco NSA High-Availability Service(HAS)サービスから入手できます。これは、ネットワークのライフサイクル規約に関連した現在のネットワーク アベイラビリティの制約を示します。

現在のトラフィックの負荷またはアプリケーションに関する制約とは、単に現在のトラフィックとアプリケーションの影響を意味します。

困ったことに、多くのアプリケーションには注意深い管理を必要とする重要な制約があります。 現在のアプリケーションにおけるジッタ、遅延、スループット、および帯域幅の要件には一般に数多くの制約があります。 また、アプリケーションの記述方法によって制約が生じることもあります。 これらの問題をより深く理解するには、アプリケーション プロファイリングが役立ちます。次のセクションでは、この機能について説明しています。 現在のアベイラビリティ、トラフィック、キャパシティ、およびパフォーマンス全般の調査も、ネットワーク管理者が現在のサービス レベルへの期待とリスクを把握するうえで役立ちます。 この調査を行うには通常、ネットワーク ベースラインと呼ばれるプロセスを使用します。このプロセスを利用すれば、一定の期間(通常はおよそ 1 か月)におけるネットワークのパフォーマンス、アベイラビリティ、またはキャパシティの平均を明確にすることができます。 この情報は一般にキャパシティの計画やトレンド分析に使用されますが、サービス レベルの問題を把握するために使用することもできます。

次のワークシートでは、セキュリティ攻撃または Denial-of-Service(DoS; サービス拒否)攻撃を防ぐという目標例に対して、上記の目標/制約手法を使用しています。 このワークシートは、セキュリティ攻撃を最小限に抑えるためのサービス範囲を決定する際にも利用できます。

リスクまたは制約

制約のタイプ

予想される影響

使用可能な DoS 検出ツールによって必ずしもすべてのタイプの DoS 攻撃を検出できるわけではない。

テクノロジー/復元力

アラートに対処するために必要なスタッフがおらず、プロセスも定められていない。

ライフサイクル規約

現在のネットワーク アクセス ポリシーが適切でない。

ライフサイクル規約

帯域幅の輻輳による攻撃を受けた場合、現在の帯域幅の狭いインターネット接続が要因になる可能性がある。

ネットワーク キャパシティ

攻撃を防ぐために有効な現在のセキュリティ設定が徹底されない可能性がある。

テクノロジー/復元力

ステップ 2: アベイラビリティの概算を決定する

アベイラビリティの概算とは、特定の 2 地点間のネットワークにおいて期待される理論的なアベイラビリティです。 この正確な理論的情報は、次のようないくつかの点で役立ちます。

  • 組織における内部アベイラビリティの目標としてアベイラビリティの概算を使用し、ずれを迅速に定義、修正できる。

  • ネットワーク設計担当者がビジネス要件に合わせてシステムのアベイラビリティを決定する際に、この情報を使用できる。

非アベイラビリティまたは停止時間を引き起こす要因には、ハードウェア障害、ソフトウェア障害、電源および環境の問題、リンクまたは通信事業者の障害、ネットワーク設計、人為ミス、プロセスの欠如などがあります。 ネットワークの全体的なアベイラビリティの概算を評価する際は、これらのパラメータをそれぞれ詳細に評価する必要があります。

現在アベイラビリティを測定している組織では、アベイラビリティの概算を必要としないことがあります。 この場合は、ベースラインとしてアベイラビリティの測定値を使用して、サービス レベル定義で使用する現在のサービス レベルを推定します。 ただし、実際の測定結果と理論的なアベイラビリティを比較して理解するために、両者を比較しても構いません。

アベイラビリティとは、製品またはサービスが必要なときに正しく機能する確率を意味します。 次の定義を参照してください。

  1. アベイラビリティ

    • 1 - (接続障害の総時間数)/(接続の総供用時間数)

    • 1 - ((障害 i によって影響を受けた接続の数 X 障害 i の継続時間)の総計)/(供用した接続の数 X 稼働時間)

  2. アンアベイラビリティ

    1 - アベイラビリティ。つまり、ハードウェア障害、ソフトウェア障害、環境および電源の問題、リンクまたは通信事業者の障害、ネットワーク設計、ユーザ エラーとプロセス障害を原因とする接続停止時間の合計。

  3. ハードウェア アベイラビリティ

    調査すべき最初の領域はハードウェア障害の可能性とアンアベイラビリティへの影響です。 これを判断するには、全ネットワーク コンポーネントの MTBF と、2 地点間のパス上にある全デバイスのハードウェア問題の MTTR を把握する必要があります。 ネットワークがモジュール方式で階層的な場合、ハードウェア アベイラビリティはほとんどどの 2 地点間でも同じになります。 MTBF 情報はすべての Cisco コンポーネントについて提供されており、各所のアカウント マネージャに依頼すれば入手できます。 Cisco NSA HAS プログラムでも、ツールを使用してネットワーク パスに基づくハードウェア アベイラビリティを計算します。これは、システムにモジュールの冗長性、シャーシの冗長性、およびパスの冗長性が存在する場合でも可能です。 MTTR はハードウェアの信頼性を構成する主な要素の 1 つです。 組織では、故障したハードウェアをどれだけ迅速に修理できるかを評価する必要があります。 組織にスペアの準備がなく、標準の Cisco SMARTnetTM の契約に依存している場合は、予想される平均的な交換時間は約 24 時間です。 コア部分は冗長化しているもののアクセスは冗長化していない標準的な LAN 環境では、おおよそのアベイラビリティは 99.99 %、MTTR は 4 時間になります。

  4. ソフトウェア アベイラビリティ

    次に調査する領域はソフトウェア障害です。 シスコでは測定のために、ソフトウェア障害を「ソフトウェア エラーを原因とするデバイスのコールドスタート」と定義しています。 シスコはソフトウェア アベイラビリティの把握に向けて大きく前進しています。しかし、新規リリースは測定に時間がかかり、General Deployment ソフトウェアよりもアベイラビリティが低いと見なされます。 IOS バージョン 11.2(18)などの General Deployment ソフトウェアでは、アベイラビリティの測定結果は 99.9999 % を超えています。 これは、修復時間を 6 分(ルータがリロードに要する時間)とし、Cisco ルータでの実際のコールドスタートに基づいて計算されたものです。 複数のバージョンを使用している組織では、アベイラビリティは若干低くなると予想されます。これは、複雑度が増し、相互運用性を考慮する必要があるほか、トラブルシューティング時間が増えるためです。 最新のソフトウェア バージョンを使用している組織では、非アベイラビリティが高くなると予想されます。 また、非アベイラビリティはかなり広範に分散されます。このため、カスタマーのサイトにおいて、非アベイラビリティが著しく増加するか、アベイラビリティが General Deployment リリースのレベルに近づきます。

  5. 環境および電源のアベイラビリティ

    アベイラビリティにおける環境と電源の問題についても考慮する必要があります。 環境の問題は、機器の温度を規定された動作温度に保つために必要な冷却システムの故障に関連します。 Cisco デバイスの多くは、仕様から著しく逸脱した場合、単純にシャットダウンします。すべてのハードウェアに損傷をきたすような危険を冒すことはありません。 アベイラビリティを概算するために、電源が使用されます。これは、この領域での非アベイラビリティの主な原因が電源であるためです。

    電源障害はネットワークのアベイラビリティを決定するための重要な側面ですが、理論的な電源分析を正確に行うことはできないため、この議論には限界があります。 したがって、地域での過去の事例、電源バックアップ機能、およびすべてのデバイスに一定品質の電源を確実に供給するためのプロセスに基づいておおまかに測定された、各デバイスの電源のアベイラビリティを評価する必要があります。

    補助発電機、Uninterruptible-Power-Supply(UPS; 無停電電源装置)システム、および高品質電源の実装プロセスを備えた組織では、控えめな評価でも 9 が 6 個、つまり 99.9999 % のアベイラビリティを確保できます。これらのシステムがなければ、アベイラビリティは 99.99 %(年間のダウンタイムがおよそ 36 分)に下がります。 当然これらの値は、組織での見解や実際のデータに基づいてより現実的な値に調整できます。

  6. リンクまたは通信事業者の障害

    リンクおよび通信事業者の障害は WAN 環境でのアベイラビリティに関する主な要因です。 WAN 環境は単に、組織のネットワークと同じアベイラビリティの問題、たとえば、ハードウェア障害、ソフトウェア障害、ユーザ エラー、電源障害といった問題の影響を受ける別のネットワークである点に留意してください。

    通信事業者のネットワークの多くは、自社のシステムですでにアベイラビリティを概算していますが、この情報を得ることは困難な場合があります。 通信事業者の保証するアベイラビリティのレベルは、多くの場合、実際のアベイラビリティの概算にほとんど、またはまったく基づいていません。 これらの保証レベルは、単に通信事業者のマーケティングおよび販売の戦略に過ぎないことがあります。 場合によっては、通信事業者の提供するネットワークのアベイラビリティがきわめて良好であることを示す統計情報が公開されていることもあります。 これらの統計情報は完全に冗長化されたコア ネットワークにのみ当てはまるもので、WAN ネットワークでの非アベイラビリティの主な要因である、ローカルループ アクセスによる非アベイラビリティは考慮されていません。

    WAN 環境でのアベイラビリティの見積もりは、実際の通信事業者の情報と WAN 接続の冗長性のレベルに基づいて作成することが必要です。 組織が複数のビルディング エントランス設備を備え、冗長なローカルループ プロバイダー、Synchronous Optical Network(SONET; 同期光ファイバ ネットワーク)へのローカル アクセス、および地理的に分散した冗長な長距離事業者を使用している場合、WAN アベイラビリティはかなり高くなります。

    電話サービスは WAN 環境での非冗長ネットワーク接続に関するかなり正確なアベイラビリティの概算です。 電話のエンドツーエンドの接続性に関するアベイラビリティの概算はおよそ 99.94 % です(この項で説明したものと同じアベイラビリティの概算方法を使用した場合)。 この方法論はこれまでわずかな変動しかないデータ環境で使用されていましたが、現在はサービス プロバイダー ケーブル ネットワークのパケット ケーブル仕様における対象として使用されています。 完全な冗長システムにこの値を適用する場合は、WAN アベイラビリティが 99.9999 % に近づくものと想定できます。 当然のことながら、費用とアベイラビリティの観点から、完全に冗長化され、地理的に分散された WAN システムを持つ組織はほとんど存在しないため、この能力については適切な判断を下す必要があります。

    LAN 環境では、リンク障害が起こる可能性は低くなります。 ただし、計画担当者はコネクタの故障やゆるみによる短時間のダウンタイムを想定しても構いません。 LAN ネットワークのアベイラビリティは控えめな見積もりでおよそ 99.9999 %(年間のダウンタイムがおよそ 30 秒)です。

  7. ネットワーク設計

    ネットワーク設計はアベイラビリティに対するもう 1 つの主要要因です。 スケーラビリティに乏しい設計、設計ミス、およびネットワークのコンバージェンス時間はすべてアベイラビリティにマイナスの影響を及ぼします。

    注: この文書の目的により、スケーラビリティに乏しい設計または設計ミスについては、次のセクションで説明します。

    ネットワーク設計は、ネットワーク内でのトラフィックの再ルーティングを引き起こすソフトウェア障害およびハードウェア障害に基づいて測定可能な値に限定されます。 この値は一般に「システム切り替え時間」と呼ばれ、システム内部でのプロトコルのセルフヒーリング機能の要因です。

    アベイラビリティの計算には単純にシステム計算と同じ方法を使用します。 ただし、ネットワーク切り替え時間がネットワーク アプリケーションの要件を満たしていない場合には、これは無効です。 切り替え時間が許容される場合は、それを計算から除外します。 切り替え時間が許容されない場合は、それを計算に加えます。 具体的な例としては、推定または実際の切り替え時間が 30 秒である環境で Voice over IP(VoIP)を使用するケースが挙げられます。 この例では、ユーザはいったん電話を切り、おそらくかけなおすでしょう。 ユーザはこの時間を間違いなく非アベイラビリティと認識しますが、アベイラビリティの概算ではこれは評価されません。

    システム切り替え時間を原因とする非アベイラビリティを計算するには、冗長パスに基づく理論的なソフトウェア アベイラビリティとハードウェア アベイラビリティを調べます。これは、切り替えがこの領域で起こるためです。 故障によって冗長パス内での切り替えを引き起こす可能性があるデバイスの数、それらのデバイスの MTBF、および切り替え時間を調べる必要があります。 単純な例として、冗長化された 2 台のまったく同じデバイスがあり、それぞれの MTBF が 35,433 時間、切り替え時間が 30 秒 である場合について考えてみます。 35,433 を 8766(うるう年を含む平均の年間時間数)で割ると、このデバイスは 4 年に 1 回故障することがわかります。 切り替え時間として 30 秒を使用する場合は、各デバイスにおいて 1 年当たり平均 7.5 秒の、切り替えによる非アベイラビリティが生じると想定できます。 ユーザはどちらのパスも通過できるため、7.5 秒を 2 倍すると、1 年当たりの非アベイラビリティは 15 秒になります。 1 年当たりの秒数の観点で計算すると、この単純なシステムでの切り替えによるアベイラビリティは 99.99999785 % になります。 切り替えを引き起こす可能性があるネットワーク内の冗長デバイスの数によっては、この値は他の環境よりも大きくなることがあります。

  8. ユーザ エラーとプロセス

    ユーザ エラーとプロセスに関するアベイラビリティの問題は、企業ネットワークと通信事業者ネットワークにおける非アベイラビリティの主な要因です。 非アベイラビリティのおよそ 80 % が、エラーの未検出、変更障害、パフォーマンスの問題などが原因で発生します。

    アベイラビリティの概算を決定する際に、その他すべての理論的な非アベイラビリティを 4 倍する必要は決してありませんが、これが多くの環境に当てはまることは事実です。 次のセクションでは、非アベイラビリティのこの側面について、詳しく説明します。

    ユーザ エラーとプロセスを原因とする非アベイラビリティの量を理論的に計算することはできないため、これはアベイラビリティの概算から除外し、組織が完璧を目指して努力することを推奨します。 注意すべき点は、組織が持つ固有のプロセスと専門知識のレベルが現在アベイラビリティにどの程度のリスクをもたらしているのかを理解する必要があることです。 これらのリスクや阻害要因を十分に理解していれば、ネットワーク計画担当者はこれらの問題を原因とする非アベイラビリティをある程度考慮に入れても構いません。 Cisco NSA HAS プログラムはこれらの問題について調査を行うため、プロセス、ユーザ エラー、または専門知識の問題によって起こりうる非アベイラビリティについて理解する際に役立つ場合があります。

  9. 最終的なアベイラビリティの概算の決定

    全体的なアベイラビリティの概算は、これまでに定義された領域の各アベイラビリティを掛け合わせて計算します。 これは一般に、任意の 2 地点間の接続性がほぼ同じである均質な環境(階層的なモジュール方式の LAN 環境や階層的な標準の WAN 環境)の場合に行います。

    この例では、階層的なモジュール方式の LAN 環境に対してアベイラビリティの概算を計算します。 この環境では補助発電機を使用し、すべてのネットワーク コンポーネントに対して UPS システムを備えており、電源を適切に管理しています。 VoIP は使用しておらず、ソフトウェア切り替え時間を考慮する必要はありません。 個々の見積もりは次のとおりです。

    • 2 つのエンドポイント間のハードウェア パス アベイラビリティ = 99.99 %

    • GD ソフトウェアの信頼性を基準として使用したソフトウェア アベイラビリティ = 99.9999 %

    • バックアップ システムを備えた環境および電源のアベイラビリティ = 99.999 %

    • LAN 環境のリンク障害に関するアベイラビリティ = 99.9999 %

    • システム切り替え時間は考慮しない = 100 %

    • ユーザ エラーとプロセスのアベイラビリティ(完璧と想定)= 100 %

    組織が確保すべき最終的なアベイラビリティの概算は 0.9999 x 0.999999 x 0.999999 x 0.999999 = 0.999896、つまり 99.9896 % になります。 ユーザ エラーまたはプロセス エラーによって起こりうる非アベイラビリティを考慮し、その非アベイラビリティが技術的要因によるアベイラビリティの 4 倍であると仮定すると、アベイラビリティの概算は 99.95 % になります。

    この分析例は、LAN アベイラビリティが 99.95 % と 99.989 % の平均になることを示しています。 これらの数値はネットワーキング組織のサービス レベルの目標として使用できます。 システムのアベイラビリティを測定し、非アベイラビリティの何パーセントが上記の 6 つの領域に起因するかを決定することによって、別の値を計算することも可能です。 この方法を使用すれば、ベンダー、通信事業者、プロセス、およびスタッフを適切に評価できます。 計算された数値は、そのビジネスにおける期待の設定にも使用できます。 数値が許容できない場合は、目的のレベルに達するように他のリソースを割り当てます。

    ネットワーク管理者は、特定のアベイラビリティ レベルでのダウンタイムの長さを知っていると役に立つ場合があります。 任意のアベイラビリティ レベルにおける 1 年間のダウンタイムの長さ(分)は次のようにして計算できます。

    1 年間のダウンタイムの長さ(単位は分) = 525600 - (アベイラビリティ レベル X 5256)

    アベイラビリティ レベルとして 99.95 % を当てはめてみると、ダウンタイムは 525600 - (99.95 x 5256) = 222.8 分になります。 上記のアベイラビリティの定義では、これはネットワーク内のインサービス状態にあるすべての接続についての平均ダウンタイムに相当します。

ステップ 3: アプリケーション プロファイルの作成

アプリケーション プロファイルは、ネットワーキング組織が個々のアプリケーションのネットワーク サービス レベルの要件を理解し、定義する際に役立ちます。 これを利用すれば、ネットワークに対する個々のアプリケーションの要件とネットワーク サービス全体を確実にサポートできます。 アプリケーション プロファイルは、アプリケーションまたはサーバ グループによってネットワークが問題として指摘されたときに、ネットワーク サービス サポートの文書化されたベースラインとしての役割も果たします。 最終的にアプリケーション プロファイルは、パフォーマンスやアベイラビリティなどのアプリケーションの要件を実際のネットワーク サービスの目標または現在の制限と比較することによって、ネットワーク サービスの目標をアプリケーションまたはビジネスの要件に合わせます。 これはサービス レベル管理のためだけでなく、全体的なトップダウン ネットワーク設計のためにも重要です。

アプリケーション プロファイルはネットワークに新規アプリケーションを導入するときに必ず作成します。 新規サービスまたは既存サービスに対するアプリケーション プロファイルの作成を徹底させるために、場合によっては、IT アプリケーション グループ、サーバ管理グループ、およびネットワーキング グループの間で取り決めを行う必要があります。 ビジネス アプリケーションとシステム アプリケーションについて詳細なアプリケーション プロファイルを作成します。 ビジネス アプリケーションには、電子メール、ファイル転送、Web ブラウジング、メディカル イメージング、製造アプリケーションなどが含まれます。 システム アプリケーションには、ソフトウェア配布、ユーザ認証、ネットワークのバックアップ、ネットワーク管理などが含まれます。

アプリケーション プロファイルはネットワーク アナリストが作成するか、またはアプリケーションまたはサーバ サポート アプリケーションによって作成します。 新規アプリケーションの要件を正しく記述するために、プロトコル アナライザと、遅延エミュレーション機能付きの WAN エミュレータが必要となることがあります。 これは、必要な帯域幅、アプリケーションの操作性を損なわない最大の遅延、およびジッタ要件を決定する際に役立ちます。 必要なサーバがありさえすれば、ラボ環境でこれを実行しても構いません。 その他のケース、たとえば VoIP を使用するケースなどでは、ジッタ、遅延、帯域幅などのネットワーク要件は十分に公開されているため、ラボでのテストは必要ありません。 アプリケーション プロファイルに含めるべき項目を次に示します。

  • アプリケーション名

  • アプリケーションのタイプ

  • 新規アプリケーションかどうか

  • ビジネス上の重要性

  • アベイラビリティの要件

  • 使用するプロトコルとポート

  • ユーザ帯域幅の推定値(kbps)

  • ユーザの数と場所

  • ファイル転送の要件(時間、量、エンドポイントなど)

  • ネットワーク停止時の影響

  • 遅延、ジッタ、およびアベイラビリティの要件

アプリケーション プロファイルの目標は、アプリケーションのビジネス要件、ビジネス上の重要性、およびネットワークの要件(帯域幅、遅延、ジッタなど)を把握することです。 また、ネットワーキング組織では、ネットワーク ダウンタイムの影響についても把握する必要があります。 場合によってはアプリケーションまたはサーバの再起動が必要になりますが、これはアプリケーション ダウンタイムの総時間を大幅に増やすことになります。 詳細なアプリケーション プロファイルを作成すれば、ネットワーク能力全般を比較し、ネットワーク サービス レベルをビジネスおよびアプリケーションの要件に合わせることができます。

ステップ 4: アベイラビリティおよびパフォーマンス標準の定義

アベイラビリティおよびパフォーマンス標準は、サービスに対する組織の期待を設定します。 これらはネットワークまたは個別アプリケーションの各種領域別に定義できます。 パフォーマンスは、往復の遅延、ジッタ、最大スループット、帯域幅保証、および全体的なスケーラビリティの観点から定義することもできます。 組織がなすべきことはサービスへの期待を設定することだけではありません。その他にも、どのようなサービス標準があり、その標準がアプリケーション要件またはサーバ管理要件にどのように関係するのかを、ネットワーキング グループに協力しているユーザ グループおよび IT グループに十分理解してもらえるように、個々のサービス標準を注意深く定義する必要があります。 また、ユーザ グループと IT グループにも、サービス標準の測定方法を理解してもらうことが望まれます。

標準の作成には、前のサービス レベル定義ステップの結果が役立ちます。 この時点でネットワーキング組織は、ネットワークにおける現在のリスクと制約、およびアプリケーションの動作について明確に理解し、理論的なアベイラビリティ分析またはアベイラビリティ ベースラインの結果を手にしているはずです。

  1. サービス標準が適用される地理的領域またはアプリケーション領域を定義します。

    これには、キャンパス LAN、国内 WAN、エクストラネット、パートナーとの接続などの領域が含まれることがあります。 場合によっては、1 つの領域内でいくつかの異なるサービス レベルの目標を設定しても構いません。 これは企業やサービス プロバイダー組織では珍しいことではありません。 これらのケースでは、個々のサービス要件に基づいて異なるサービス レベル標準を作成することがよくあります。 それらの標準が、1 つの地理的領域またはサービス領域で、ゴールド、シルバー、およびブロンズ サービス標準として分類されるケースもあります。

  2. サービス標準パラメータを定義します。

    最も一般的なネットワーク サービス標準はアベイラビリティと往復の遅延です。 最大スループット、最小帯域幅保証、ジッタ、許容されるエラー率、およびスケーラビリティ能力も、必要に応じて使用できます。 サービス パラメータの測定方法を検討する際には注意が必要です。 パラメータが SLA に含まれるかどうかにかかわらず、どのようにしてサービス パラメータを測定し、問題またはサービスの不適合が生じたときにどのようにしてその正当性を示すかについて検討しておくことが望まれます。

サービス領域とサービス パラメータを定義した後、前のステップの情報を使用してサービス標準のマトリックスを作成します。 ユーザや IT グループに混乱を招くおそれのある領域を定義することも必要です。 たとえば、ping の往復での最大応答時間は、特定のアプリケーションに対して遠隔地から Enter キーを押す場合の最大応答時間とは非常に異るものになります。 次の表は、米国内でのパフォーマンス ターゲットをまとめたものです。

ネットワーク領域

アベイラビリティのターゲット

測定方法

平均ネットワーク応答時間のターゲット

許容される最大応答時間

応答時間の測定方法

LAN

99.99%

Impacted user minutes

5 ミリ秒以下

10 ミリ秒

ラウンドトリップ ping の応答

WAN

99.99%

Impacted user minutes

100 ミリ秒以下(ラウンドトリップ ping)

150 ミリ秒

ラウンドトリップ ping の応答

クリティカルな WAN およびエクストラネット

99.99%

Impacted user minutes

100 ミリ秒以下(ラウンドトリップ ping)

150 ミリ秒

ラウンドトリップ ping の応答

ステップ 5: ネットワーク サービスの定義

これは基本的なサービス レベル管理へ向けての最後のステップです。ここでは、サービス レベルの目標を達成するために実装する事後対処的および予防的プロセスとネットワーク管理能力について定義します。 最終的な文書は一般に「運用サポート プラン」と呼ばれます。 ほとんどのアプリケーション サポート プランには、事後対処的なサポート要件のみが記載されます。 ハイアベイラビリティ環境では、予防的な管理プロセスについても検討する必要があります。予防的な管理プロセスは、ユーザからのサービス コールを受ける前にネットワークの問題を切り分けて解決するために使用します。 最終的な文書には概して次のことを記載します。

  • サービス レベルの目標を達成するために使用する事後対処的プロセスと予防的プロセス

  • サービス プロセスの管理方法

  • サービス目標とサービス プロセスの測定方法

この項では、多くのサービス プロバイダーおよび企業組織で検討すべき事後対処的サービス定義と予防的サービス定義の例を示しています。 サービス レベル定義を作成する際の目標は、アベイラビリティとパフォーマンスの目標を満たすサービスを作成することです。 これを実現するには、現在の技術的な制約、アベイラビリティの概算、およびアプリケーション プロファイルを念頭に置きながらサービスを構築する必要があります。 具体的に言えば、常に迅速に問題を特定し、アベイラビリティ モデルによって割り当てられた時間内に問題を解決できるサービスを定義、構築することが望まれます。 また、無視すればアベイラビリティとパフォーマンスに影響を及ぼす可能性のあるサービス問題を迅速に特定し、解決できるサービスを定義することも必要です。

所期のサービス レベルは一朝一夕で達成されるものではありません。 すでにサービス分析ステップを完了していたとしても、専門知識の不足、プロセスに関する現在の制限、スタッフのレベルが十分でないなどの欠点によって、所期の標準または目標の達成が妨げられることがあります。 必要なサービス レベルを所期の目標に正確に一致させる方法はありません。 これに対処するには、サービス標準を測定し、さらにサービス標準のサポートに使用するサービス パラメータを測定します。 サービス目標が満たされていない場合は、問題を把握するためにサービス規準に目を向けます。 サポート サービスを改善するためには、多くの場合、概算の増加が有効であり、これによって所期のサービス目標の達成に必要な改善を実施できます。 時間が経つにつれてネットワーク サービスとビジネス要件の間に齟齬が生じ、それらを合わせるために、サービス目標またはサービス定義に修正を加えることもあります。

たとえば、99.9 % のアベイラビリティを目標として設定していた組織で、99% のアベイラビリティしか達成されなかったとします。 サービスおよびサポートの規準を見ていた組織の担当者は、ハードウェア交換におよそ 24 時間かかっていることに気付きました。当初の見積もりでは、ハードウェア交換の時間配分は 4 時間であり、実際の作業時間はこの見積もりを大幅に超えています。 また、予防的な管理能力がなおざりにされていて、ダウンした冗長ネットワーク デバイスが修理されていることにも気付きました。 さらに、責任を持って改善を行う担当者も定められていませんでした。 結果的に、この組織では、現在のサービス目標を下げることを検討した後、所期のサービス レベルを達成するために必要な追加のリソース計画を作成しました。

サービス定義には、事後対処的なサポート定義と予防的なサポート定義をどちらも含める必要があります。 事後対処的定義では、ユーザからの苦情またはネットワーク管理能力を起点として問題を特定し、その問題に対処する方法を定義します。 予防的定義では、故障した「スタンバイ」ネットワーク コンポーネントの修理、エラーの検出、キャパシティのしきい値とアップグレードなど、発生する可能性のあるネットワークの問題を特定し、解決する方法について記述します。 次の項に、事後対処的サービス レベル定義と予防的サービス レベル定義の例を示します。

事後対処的サービス レベル定義

次のサービス レベル領域は一般に、ヘルプデスク データベースの統計情報と定期的な監査を使用して測定します。 この表は組織にとっての問題の重大度を具体的に示しています。 この表には、新規サービスに対する要求の対処方法は記載されていません。これは、SLA または追加のアプリケーション プロファイリングとパフォーマンスの what-if 分析によって取り扱うことがあります。 同じサポート プロセスによって対処する場合は、一般に重大度 5 が新規サービスの要求になります。

重大度 1

重大度 2

重大度 3

重大度 4

重大なビジネス上の影響

LAN ユーザまたはサーバ セグメントの停止

クリティカルな WAN サイトの停止

損失または品質低下による大きなビジネス上の影響、適切な回避策あり

キャンパス LAN の停止(5〜99 ユーザに影響)

国内 WAN サイトの停止

国外 WAN サイトの停止

パフォーマンスに対するクリティカルな影響

一部のネットワーク機能の喪失または品質低下(冗長性の喪失など)

キャンパス LAN のパフォーマンスへの影響

LAN 冗長性の喪失

機能に関する問い合せまたは障害、組織にとってのビジネス上の影響なし

問題の重大度を定義したら、サービス応答定義を作成するためのサポート プロセスを定義または調査します。 一般にサービス応答定義には、階層化されたサポート構造と、トラブル チケットによって問題を追跡するヘルプデスク ソフトウェア サポート システムが必要です。 また、優先順位別の応答時間と解決時間、優先順位別のコール回数、および応答/解決品質についての規準も使用できる必要があります。 サポート プロセスを定義するには、組織内での各サポート層の目標を設定し、それぞれの役割と責任を明確化すると便利です。 組織ではこの作業を通じて、各サポート レベルのリソース要件と専門知識のレベルを把握できます。 次の表は、階層化されたサポート構造と問題解決のガイドラインの例を示しています。

サポート層

責任

目標

第 1 層サポート

フルタイムのヘルプデスク サポート

サポート コールへの回答、トラブル チケットの発行、最大 15 分までの問題の処理、チケットの文書化、第 2 層サポートへの報告

着信コールの解決率:40 %

第 2 層サポート

キューの監視、ネットワーク管理、端末の監視

問題が特定されたソフトウェアのトラブル チケットの発行

実装

第 1 層およびベンダーからのコールへの対応、第 3 層への報告

解決までのコールの所有権の保有

第 2 層レベルでのコールの解決率:100 %

第 3 層サポート

優先順位 1 の問題すべてについて、第 2 層への即時のサポートの提供

SLA 解決時間内に第 2 層で解決されなかった問題すべてについて、合意の上で解決を支援

問題の直接の所有権は持たない

次に、サービス応答とサービス解決に関するサービス定義のマトリックスを作成します。 ここでは、問題をどれだけ迅速に解決するかについての目標を設定します(ハードウェア交換を含む)。 サービス応答時間と復旧時間はネットワークのアベイラビリティに直接影響を及ぼすため、この領域で目標を設定することが重要です。 問題解決時間も、アベイラビリティの概算に基づいて設定します。 アベイラビリティの概算で、重大度の高い問題が多数発生するケースが考慮されていない場合は、これらの問題の根源と実行可能な対策の特定に尽力します。 次の表を参照してください。

問題の重大度

ヘルプデスクの応答

第 2 層の応答

オンサイトの第 2 層

ハードウェア交換

問題解決

1

第 2 層、ネットワーク運用管理者への速やかな報告

5 分

2 時間

2 時間

4 時間

2

第 2 層、ネットワーク運用管理者への速やかな報告

5 分

4 時間

4 時間

8 時間

3

15 分

2 時間

12 時間

24 時間

36 時間

4

15 分

4 時間

3 日

3 日

6 日

サービス応答とサービス解決の他に、報告マトリックスも作成します。 報告マトリックスは、使用可能なリソースを、サービスに重大な影響を及ぼす問題に確実に集中させるために役立ちます。 一般に、問題の解決に集中していると、その問題にリソースを追加することまではアナリストが考慮できない場合があります。 その他のリソースにいつ報告すべきかを定義しておけば、経営陣の問題に対する認識が高まり、多くの場合、今後の予防的対策につながります。 次の表を参照してください。

経過時間

重大度 1

重大度 2

重大度 3

重大度 4

5 分

ネットワーク運用管理者、第 3 層サポート、ネットワーキング担当役員

     

1 時間

ネットワーク運用管理者、第 3 層サポート、ネットワーキング担当役員への情報の更新

ネットワーク運用管理者、第 3 層サポート、ネットワーキング担当役員への情報の更新

   

2 時間

VP への報告、役員、運用管理者への情報の更新

     

4 時間

VP、役員、運用管理者、第 3 層サポートへの根本原因分析の報告、未解決時は CEO への報告が必要

VP への報告、役員、運用管理者への情報の更新

   

24 時間

   

ネットワーク運用管理者

 

5 日

     

ネットワーク運用管理者

これまでに説明したサービス レベル定義では、運用サポート組織が問題を特定した後、その問題にどのようにして対処するかという点を中心としていました。 運用組織では、上記とほぼ同じ情報を含む運用サポート プランを何年も前から作成しています。 しかし、これらのケースで欠けているのは、事前に問題を特定するにはどうすればよいかということと、その方法で特定できる問題にはどのようなものがあるかということです。 先進的なネットワーク組織では、ユーザの問題報告または苦情によって事後対処的に特定された問題ではなく、予防的に特定された問題のパーセンテージを目標として設定することにより、この問題の解決を試みています。

次の表は、予防的サポート能力と予防的サポート全般をどの程度見積もってよいかを示しています。

ネットワーク領域

予防的な問題検出の比率

予防的な問題検出の比率

LAN

80 %

20 %

WAN

80 %

20 %

より予防的なサポート定義を作成する際に、この方法から始めることをお勧めします。特に予防的ツールによって自動的にトラブル チケットが生成される場合は測定が単純で、非常に簡単だからです。 これはまた、ネットワーク管理ツール/情報を、根本的な原因を特定するための支援ではなく、予防的な問題の解決に集中させる点でも役立ちます。 ただし、この方法の大きな問題点は、これが予防的サポート要件を定義するものではないことです。 これは一般に、予防的サポート管理能力における格差を生み出し、結果的に新たなアベイラビリティ リスクをもたらします。

予防的サービス レベル定義

サービス レベル定義を作成するための、より包括的な方法論では、ネットワークをどのようにして監視し、運用組織が定義済みの Network Management Station(NMS; ネットワーク管理ステーション)のしきい値に対して 24 時間 365 日体制でどのように対処すればよいかについて、詳細に述べられています。 これは、Management Information Base(MIB; 管理情報ベース)変数の数の多さや、ネットワークの健全性に関係するネットワーク管理情報の量を見れば、まったく不可能な作業のように思われるかもしれません。 また、この業務は非常にコストがかかり、大量のリソースを必要とする可能性があります。 残念なことに、このような理由から多くの組織が予防的サービス定義の実装を避けていますが、予防的サービス定義は、本質的に単純で、非常に簡単に従うことができ、ネットワーク内の最大のアベイラビリティ リスクまたはパフォーマンス リスクのみに適用できます。 基本的な予防的サービス定義の価値を認識している組織では、段階的アプローチをとりさえすれば、大きな影響を与えることなく徐々に変数を増やしていくことができます。

予防的サービス定義の最初の領域はすべての運用サポート プランに組み込んでください。 サービス定義では単に、運用グループがネットワークのさまざまな領域で、どのようにしてネットワークまたはリンクのダウン状態を事前に検出し、それに対処するのかを規定するだけです。 この定義(または管理サポート)がなければ、一定していない多様なサポート、非現実的なユーザの期待、および最終的なネットワーク アベイラビリティの低下を余儀なくされるおそれがあります。

次の表は、リンク/デバイスダウン状態に対するサービス定義の作成方法を示しています。 この例では、企業組織が時間帯やネットワークの領域に基づいて異なる通知要件と応答要件を持つ場合を示しています。

ネットワーク デバイスまたはリンクのダウン

検出方法

5 x 8 通知

7 x 24 通知

5 x 8 解決

7 x 24 解決

コア LAN

SNMP デバイスとリンクのポーリング、トラップ

NOC がトラブル チケットを発行、LAN 担当ページャーに連絡

LAN 担当ページャーに自動的に連絡、LAN 担当者がコア LAN キュー用のトラブル チケットを発行

NOC によって 15 分以内に割り当てられた LAN アナリストがサービス応答定義に従って修復

優先順位 1 および 2 は速やかな調査と解決

優先順位 3 および 4 は早期解決のためにキューイング

国内 WAN

SNMP デバイスとリンクのポーリング、トラップ

NOC がトラブル チケットを発行、WAN 担当ページャーに連絡

WAN 担当ページャーに自動的に連絡、WAN 担当者が WAN キュー用のトラブル チケットを発行

NOC によって 15 分以内に割り当てられた WAN アナリストがサービス応答定義に従って修復

優先順位 1 および 2 は速やかな調査と解決

優先順位 3 および 4 は早期解決のためにキューイング

エクストラネット

SNMP デバイスとリンクのポーリング、トラップ

NOC がトラブル チケットを発行、パートナー担当ページャーに連絡

パートナー担当ページャーに自動的に連絡、パートナー担当者がパートナー キュー用のトラブル チケットを発行

NOC によって 15 分以内に割り当てられたパートナー アナリストがサービス応答定義に従って修復

優先順位 1 および 2 の場合は即時に調査および解決

優先順位 3 および 4 は早期解決のためにキューイング

他の予防的なサービス レベル定義は、ネットワーク エラーと、キャパシティ/パフォーマンスの問題の 2 つのカテゴリに分けられます。 これらの領域のサービス レベル定義を作成しているネットワーク組織はほんの数パーセントに過ぎません。 結果的に、これらの問題は無視されるか、散発的に処理されています。 それでも構わないネットワーク環境もありますが、ハイアベイラビリティ環境では一般に、一貫した予防的サービス管理が必要です。

ネットワーキング組織は、いくつかの理由から予防的サービス定義の作成に苦労する傾向があります。 これは主に、アベイラビリティ リスク、アベイラビリティの概算、およびアプリケーションの問題に基づいて予防的サービス定義の要件分析を行ったことがないためです。 そのため、特に状況に応じて追加のリソースが必要になるという点で、予防的サービス定義の要件を明確にすることができず、利点もあいまいになります。

2 つめの理由は、既存のリソースまたは新しく定義されたリソースと、処理可能な予防的管理の量とのバランスに関係します。 これについては、アベイラビリティまたはパフォーマンスに重大な影響を及ぼす可能性のあるアラートのみを生成するようにします。 また、同じ問題に対して複数の予防的トラブル チケットが生成されないようにするため、イベント相関管理またはプロセスについても検討が必要です。 組織が苦労する最後の理由は、新しい予防的アラートのセットを作成すると、多くの場合、それまで検出されなかったメッセージの初期フラッドが生成されることです。 運用グループでは、この初期フラッドの問題に対応できるよう準備するとともに、それまで検出されなかったこれらの条件を修正または解決するために短期的に追加のリソースを割り当てる必要があります。

予防的サービス レベル定義の最初のカテゴリはネットワーク エラーです。 ネットワーク エラーはさらにシステム エラーに細分化できます。システム エラーには、ソフトウェア エラーまたはハードウェア エラー、プロトコル エラー、メディア制御エラー、精度エラー、環境に関する警告などがあります。 サービス レベル定義を作成するときは、これらの問題となる条件をどのようにして検出し、だれがそれを調べ、その条件が発生したときに何が起こるかについて大まかに理解することから始めます。 必要に応じて、サービス レベル定義に特定のメッセージまたは問題を追加します。 正しい対処を行うために、次の分野でさらに作業を行う必要がある場合があります。

  • 第 1 層、第 2 層、第 3 層サポートの責務

  • ネットワーク管理情報の優先順位と、運用グループが実際に処理可能な予防作業の量とのバランス

  • サポート スタッフが定義済みのアラートに効果的に対処できるようにするためのトレーニング要件

  • 根本原因が同じ問題に対して複数のトラブル チケットが生成されないようにするためのイベント相関方法

  • 第 1 層サポート レベルでのイベント識別に役立つ特定のメッセージまたはアラートの文書化

次の表は、ネットワーク エラーに関するサービス レベル定義の例を示したものです。これを見れば、予防的ネットワーク エラー アラートの担当者はだれで、問題をどのようにして特定し、問題が発生したときに何が起こるかを明確に理解できます。 また、組織では、正しい対処を行うために、上記で定義した努力を行う必要がある場合があります。

エラー カテゴリ

検出方法

しきい値

実行するアクション

ソフトウェア エラー(ソフトウェアによる強制クラッシュ)

syslog ビューアを使用して syslog メッセージを毎日レビュー

第 2 層サポートで実施

優先順位 0、1、および 2 のすべての発生事項

レベル 3 以上の発生事項 100 以上

新しい事項が発生したか、注意を要する問題の場合は、問題のレビュー、トラブル チケットの作成とディスパッチ

ハードウェア エラー(ハードウェアによる強制クラッシュ)

syslog ビューアを使用して syslog メッセージを毎日レビュー

第 2 層サポートで実施

優先順位 0、1、および 2 のすべての発生事項

レベル 3 以上の発生事項 100 以上

新しい事項が発生したか、注意を要する問題の場合は、問題のレビュー、トラブル チケットの作成とディスパッチ

プロトコル エラー(IP ルーティング プロトコルだけ)

syslog ビューアを使用して syslog メッセージを毎日レビュー

第 2 層サポートで実施

1 日当たり優先順位 0、1、および 2 のメッセージ 10 個

レベル 3 以上の発生事項 100 以上

新しい事項が発生したか、注意を要する問題の場合は、問題のレビュー、トラブル チケットの作成とディスパッチ

メディア制御エラー(FDDI、POS、ファースト イーサネットだけ)

syslog ビューアを使用して syslog メッセージを毎日レビュー

第 2 層サポートで実施

1 日当たり優先順位 0、1、および 2 のメッセージ 10 個

レベル 3 以上の発生事項 100 以上

新しい事項が発生したか、注意を要する問題の場合は、問題のレビュー、トラブル チケットの作成とディスパッチ

環境に関するメッセージ(電源や温度)

syslog ビューアを使用して syslog メッセージを毎日レビュー

第 2 層サポートで実施

すべてのメッセージ

新規の問題の場合はトラブル チケットの発行とディスパッチ

精度エラー(リンク入力エラー)

5 分間隔での SNMP ポーリング

NOC で受信されたしきい値イベント

入力または出力エラー

任意のリンクでの任意の 5 分間隔内で 1 つのエラー

新規の問題の場合はトラブル チケットの発行、第 2 層サポートへのディスパッチ

予防的サービス レベル定義のもう 1 つのカテゴリはパフォーマンスとキャパシティに適用されます。 真のパフォーマンスおよびキャパシティ管理には、例外管理、ベースラインとトレンディング、および what-if 分析が含まれます。 サービス レベル定義では単に、調査またはアップグレードのきっかけとなるパフォーマンスおよびキャパシティの例外しきい値と平均しきい値を規定するだけです。 これらのしきい値は 3 つのパフォーマンスおよびキャパシティ管理プロセスすべてになんらかの方法で適用されます。

キャパシティとパフォーマンスに関するサービス レベルの定義は、ネットワーク リンク、ネットワーク デバイス、エンドツーエンドのパフォーマンス、そしてアプリケーションのパフォーマンスと言った、複数のカテゴリに細分できます。 これらの領域のサービス レベル定義を作成するには、デバイス キャパシティ、メディア キャパシティ、QoS の特性、およびアプリケーション要件の固有の側面に関する詳細な技術的知識が必要です。 そのため、パフォーマンスとキャパシティに関連したサービス レベル定義はネットワーク設計者がベンダーの入力をもとに作成することを推奨します。

ネットワーク エラーの場合と同様に、キャパシティおよびパフォーマンスに関するサービス レベル定義を作成するときは、これらの問題となる条件をどのようにして検出し、だれがそれを調べ、その条件が発生したときに何が起こるかについて大まかに理解することから始めます。 必要に応じて、サービス レベル定義に特定のイベント定義を追加できます。 正しい対処を行うために、次の分野でさらに作業を行う必要がある場合があります。

  • アプリケーションのパフォーマンス要件についての明確な理解

  • しきい値が組織のビジネス要件と全体的なコストの観点から意味があるかどうかについての、詳細な技術的調査

  • 概算サイクルおよびサイクル外のアップグレード要件

  • 第 1 層、第 2 層、第 3 層サポートの責務

  • ネットワーク管理情報の優先順位および重要性と、運用グループが実際に処理可能な予防作業の量とのバランス

  • サポート スタッフがメッセージまたはアラートを理解し、定義済みの条件に効果的に対処できるようにするためのトレーニング要件

  • 根本原因が同じ問題に対して複数のトラブル チケットが生成されないようにするためのイベント相関方法またはプロセス

  • 第 1 層サポート レベルでのイベント識別に役立つ特定のメッセージまたはアラートの文書化

次の表は、リンクの使用率に関するサービス レベル定義の例を示したものです。これを見れば、予防的ネットワーク エラー アラートの担当者はだれで、問題をどのようにして特定し、問題が発生したときに何が起こるかを明確に理解できます。 また、組織では、正しい対処を行うために、上記で定義した努力を行う必要がある場合があります。

ネットワーク領域/メディア

検出方法

しきい値

実行するアクション

キャンパス LAN バックボーンとディストリビューション リンク

5 分間隔での SNMP ポーリング

コア リンクおよびディストリビューション リンクでの RMON 例外トラップ

5 分間隔での使用率が 50 %

例外トラップの場合は使用率が 90 %

パフォーマンスに関する電子メール エイリアス宛てに電子メールで通知

QoS 要件の評価や、繰り返し発生する問題に対するアップグレードを計画するグループ

ドメスティック WAN リンク

5 分間隔での SNMP ポーリング

5 分間隔での使用率が 75 %

パフォーマンスに関する電子メール エイリアス宛てに電子メールで通知

QoS 要件の評価や、繰り返し発生する問題に対するアップグレードを計画するグループ

エクストラネット WAN リンク

5 分間隔での SNMP ポーリング

5 分間隔での使用率が 60 %

パフォーマンスに関する電子メール エイリアス宛てに電子メールで通知

QoS 要件の評価や、繰り返し発生する問題に対するアップグレードを計画するグループ

次の表は、デバイス キャパシティおよびパフォーマンスのしきい値に関するサービス レベル定義を示しています。 しきい値には必ず、ネットワークまたはアベイラビリティの問題を防止するために有効で意味のある値を指定してください。 チェックされていないデバイス コントロール プレーン リソースの問題によってネットワークへの重大な影響が生じるおそれがあるため、この領域は非常に重要です。

         

Cisco 7500

CPU、メモリ、バッファ

5 分間隔の SNMP ポーリング

RMON 通知(CPU の場合)

5 分間隔での CPU 使用率が 75 %、RMON 通知の場合は 99 %

5 分間隔でのメモリ使用率が 50 %

バッファの使用率が 99 %

問題の解決とアップグレードの計画を行うパフォーマンスとキャパシティに関する電子メール エイリアス宛てに電子メールで通知

RMON によって CPU 使用率が 99 % と報告された場合は、トラブル チケットを発行し、第 2 層サポートのページャーに連絡

Cisco 2600

CPU、メモリ

5 分間隔での SNMP ポーリング

5 分間隔での CPU 使用率が 75 %

5 分間隔でのメモリ使用率が 50 %

問題の解決とアップグレードの計画を行うパフォーマンスとキャパシティに関する電子メール エイリアス宛てに電子メールで通知

Catalyst 5000

バックプレーンの使用率、メモリ

5 分間隔での SNMP ポーリング

バックプレーンの使用率が 50 %

メモリの使用率が 75 %

問題の解決とアップグレードの計画を行うパフォーマンスとキャパシティに関する電子メール エイリアス宛てに電子メールで通知

LightStream<SUP>(R) </SUP>1010 ATM スイッチ

CPU、メモリ

5 分間隔での SNMP ポーリング

CPU の使用率が 65 %

メモリの使用率が 50 %

問題の解決とアップグレードの計画を行うパフォーマンスとキャパシティに関する電子メール エイリアス宛てに電子メールで通知

次の表は、エンドツーエンド パフォーマンスおよびキャパシティに関するサービス レベル定義を示しています。 これらのしきい値は一般にアプリケーションの要件に基づきますが、なんらかのタイプのネットワーク パフォーマンスまたはキャパシティの問題を示すために使用することもできます。 組織でパフォーマンスに関するサービス レベル定義が規定されていても、ほとんどの場合、ほんの一握りのパフォーマンス定義しか作成されていません。これは、ネットワーク内のすべてのポイントから他のすべてのポイントへのパフォーマンスを測定するには膨大なリソースが必要であり、そのうえ相当な量のネットワーク オーバーヘッドが発生するためです。 これらのエンドツーエンド パフォーマンスの問題はリンクまたはデバイス キャパシティのしきい値によって捕捉されることもあります。 地理的領域別に全般的な定義を作成することを推奨します。 必要であれば、いくつかの重要なサイトまたはリンクを追加しても構いません。

ネットワーク領域/メディア

測定方法

しきい値

実行するアクション

キャンパス LAN

なし

発生が予測される問題がない

LAN インフラストラクチャ全体を測定するのは困難

往復応答時間が常に 10 ミリ秒以下

問題の解決とアップグレードの計画を行うパフォーマンスとキャパシティに関する電子メール エイリアス宛てに電子メールで通知

ドメスティック WAN リンク

Internet Performance Monitor(IPM)ICMP エコーのみを使用した、SF から NY および SF からシカゴへの現在の測定

往復応答時間の 5 分間の平均が 75 ミリ秒

パフォーマンスに関する電子メール エイリアス グループ宛てに電子メールで通知し、QOS 要件を評価および繰り返し発生する問題に対するアップグレードを計画

サンフランシスコから東京

IPM と ICMP エコーを使用したサンフランシスコからブリュッセルへの現状の測定

往復応答時間の 5 分間の平均が 250 ミリ秒

パフォーマンスに関する電子メール エイリアス グループ宛てに電子メールで通知し、QOS 要件を評価および繰り返し発生する問題に対するアップグレードを計画

サンフランシスコからブリュッセル

IPM と ICMP エコーを使用したサンフランシスコからブリュッセルへの現状の測定

往復応答時間の 5 分間の平均が 175 ミリ秒

パフォーマンスに関する電子メール エイリアス グループ宛てに電子メールで通知し、QOS 要件を評価および繰り返し発生する問題に対するアップグレードを計画

サービス レベル定義の最後の領域はアプリケーションのパフォーマンスに関するものです。 アプリケーション パフォーマンス サービス レベル定義は通常、アプリケーションまたはサーバ管理グループが作成します。これは、アプリケーションのパフォーマンスにおける最大の要因がおそらくサーバ自体のパフォーマンスとキャパシティであるためです。 ネットワーキング組織では、ネットワーク アプリケーション パフォーマンスに関するサービス レベル定義を作成すれば、次のような理由から大きな利益を得ることができます。

  • サービス レベルの定義および測定によってグループ間の競合が解消される可能性がある。

  • キー アプリケーションに対して QoS が設定されていて、その他のトラフィックがオプションと見なされている場合は、個々のアプリケーションのサービス レベル定義が重要になる。

アプリケーションのパフォーマンスを作成し測定することを決めた場合は、おそらくサーバ自体へ向かう方向のパフォーマンスを測定しない方が効果的です。 そうすると、ネットワークの問題とアプリケーションまたはサーバの問題を区別する際に役立ちます。 Cisco ルータで動作するプローブまたはシステム アベイラビリティ エージェント ソフトウェアと、パケットのタイプおよび測定頻度を制御する Cisco IPM を使用してください。

次の表は、アプリケーションのパフォーマンスに関する単純なサービス レベル定義を示しています。

アプリケーション

測定方法

しきい値

実行するアクション

Enterprise Resource Planning(ERP)アプリケーション

TCP ポート 1529、ブリュッセルから SF

IPM ポート 1529 を使用して、ブリュッセルからサンフランシスコへの往復のパフォーマンスを測定

ブリュッセルのゲートウェイから SFO のゲートウェイ 2 へ

往復応答時間の 5 分間の平均が 175 ミリ秒

パフォーマンスに関する電子メール エイリアス グループ宛てに電子メールで通知し、問題を評価および繰り返し発生する問題に対するアップグレードを計画

ERP アプリケーション

TCP ポート 1529、東京から SF

IPM ポート 1529 を使用して、ブリュッセルからサンフランシスコへの往復のパフォーマンスを測定

ブリュッセルのゲートウェイから SFO のゲートウェイ 2 へ

往復応答時間の 5 分間の平均が 200 ミリ秒

パフォーマンスに関する電子メール エイリアス グループ宛てに電子メールで通知し、問題を評価および繰り返し発生する問題に対するアップグレードを計画

カスタマー サポート アプリケーション

TCP ポート 1702、シドニーから SF

IPM、ポート 1702 を使用して、シドニーからサンフランシスコへの往復のパフォーマンスを測定

シドニーのゲートウェイから SFO のゲートウェイ 1 へ

往復応答時間の 5 分間の平均が 250 ミリ秒

パフォーマンスに関する電子メール エイリアス グループ宛てに電子メールで通知し、問題を評価および繰り返し発生する問題に対するアップグレードを計画

ステップ 6: 規準の収集と監視

規準を収集して成果を監視しなければ、サービス レベル定義だけがあっても役に立ちません。 重要なサービス レベル定義を作成する際は、サービス レベルをどのようにして測定し、報告するかを規定します。 サービス レベルを測定することによって、組織の目標が達成されているかどうか、およびアベイラビリティ問題またはパフォーマンス問題の根本原因が特定されているかどうかがわかります。 サービス レベル定義の測定方法を決める際には、目標についても検討してください。 詳細については、「SLA の作成と維持」を参照してください。

サービス レベルを監視している場合は、定期的に検討ミーティング(通常は月に 1 回)を開催し、定期サービスについて議論する必要があります。 すべての規準を取り上げ、それらが目標に適合しているかどうかについて話し合います。 適合していない規準があれば、問題の根本原因を特定し、改善を実施します。 個々の状況について改善を実施しているときは、現在のイニシアチブと進捗状況も議題に取り上げます。

SLA の作成と維持

サービス レベル定義は、組織全体にわたる一貫した QoS の作成とアベイラビリティの改善に寄与するという点で優れたビルディング ブロックです。 次のステップでは SLA を取り扱います。SLA によってビジネス目標とコスト要件が直接サービス品質に反映されるため、SLA は一種の改善手段といえます。 適切に構成された SLA は、ネットワークの問題に関する明確なプロセスまたは手順を維持することにより、効率、品質、およびユーザ コミュニティとサポート グループ間の相乗効果のモデルとして機能します。

SLA には次のような利点があります。

  • SLA はサービスに関する双方向の責任を確立します。つまり、ユーザやアプリケーション グループにもネットワーク サービスについての責任が生じます。 ユーザやアプリケーション グループが、特定のサービスに関する SLA の作成や、ビジネス上の影響についてのネットワーク グループとの意見交換に協力しない場合、実際には問題についての責任がユーザやアプリケーション グループにある可能性があります。

  • SLA は、ビジネス要件を満たすために必要な標準ツールとリソースを決定する際に役立ちます。 要員の数と使用するツールを SLA なしで決定する場合は、通常、概算からの推測になります。 サービスの設計が過剰であれば支出超過につながり、逆に条件に満たない場合はビジネス目標が達成されません。 SLA を調整することでバランスのとれた最適なレベルを実現できます。

  • 文書化された SLA はサービス レベルの期待を設定するための明確な手段となります。

サービス レベルの定義を行った後、次の手順に従って SLA を構築することを推奨します。

7. SLA の前提条件を満たす

8. SLA に関与するグループの決定

9. サービスの要素の決定

10. カスタマーのビジネス ニーズと目的の理解

11. 各グループに必要な SLA を定義

12. SLA の形式を選択

13. SLA ワークグループの立ち上げ

14. ワークグループの会議を開き、SLA の草案を作成

15. SLA について協議

16. SLA の適合性について測定および監視

ステップ 7: SLA の前提条件を満たす

IT SLA 開発の専門家は SLA を成功させるための前提条件として 3 つの項目を挙げています。 残念ながら、これらの目標に達していない組織は SLA プロセスに関して問題が生じるおそれがあるため、SLA プロセスに関連して起こりうる問題について検討する必要があります。 ネットワーキング組織が全般的なビジネス要件を満たすサービス レベル定義を作成できる場合は、SLA を実装しなくても大きな問題ではありません。 SLA プロセスの前提条件を次に示します。

  • 会社全体にサービス重視の体制が形成されていなければならない。

    組織では、カスタマーのニーズを何よりも優先させる必要があります。 サービスに対してはトップダウンによる最優先事項としての取り組みが必要であり、これがカスタマーのニーズと意識の全面的な理解につながります。 顧客満足度調査とカスタマー主導のサービス イニシアチブを実施することも必要です。

    組織がサービスまたはサポートの満足度を企業目標として宣言することも、別のサービス指標になりえます。 IT 組織は今や組織全体の成果にクリティカルにリンクしているため、このようなことは珍しくありません。

    サービス体制が重要なのは、SLA プロセスが本質的にカスタマーのニーズとビジネス要件に基づいて改善されるためです。 これまでサービス文化を重視してこなかった組織では、SLA プロセスが困難なものであると感じるでしょう。

  • カスタマー/ビジネス イニシアチブによってすべての IT 活動が推進されていなければならない。

    企業のビジョンまたはミッションの声明は、SLA などの IT 活動すべてを推進するカスタマーおよびビジネス イニシアチブと整合がとれている必要があります。 ネットワークを活用して特定の目標を達成しようとすることが多くありますが、目標とそれに続くビジネス要件をネットワーキング グループが認識していない場合があります。 この場合、ネットワークに一定の予算を割り当てても、このグループは現在のニーズに過剰に対処したり、要件を著しく過小評価する可能性があるため、結果的に失敗に終ります。

    カスタマー/ビジネス イニチアチブが IT 活動と整合がとれていると、ネットワーキング組織は新規アプリケーションの水平展開、新規サービス、またはその他のビジネス要件に容易に同調することができます。 このつながりによって、企業目標の達成へと向かう共通した全体意識が生まれるため、すべてのグループが 1 つのチームとして機能します。

  • SLA プロセスと契約に従う必要がある。

    第 1 に、効果的な契約を作成するために SLA プロセスを学習する責任があります。 第 2 に、契約のサービス要件を遵守する必要があります。 個々の関係者すべてからの重要な意見も取り組みもないまま、強力な SLA を作成しようとしないでください。 これは、管理者層および SLA プロセスに関係のあるすべての個人が取り組む必要があります。

ステップ 8: SLA に関与するグループの決定

エンタープライズ レベルのネットワークの SLA は、ネットワーク要素、サーバ管理要素、ヘルプデスク サポート、アプリケーション要素、およびビジネス要件またはユーザ要件によって大幅に異なります。 一般に各領域の管理者層は SLA プロセスに関与します。 このシナリオは組織が基本的な事後対処的サポート SLA を構築しているときに有効です。 ハイアベイラビリティ要件を持つ企業組織では、SLA プロセス中にアベイラビリティの概算、パフォーマンスの制限、アプリケーション プロファイリング、予防的管理能力などの問題について支援を受けるために、技術サポートが必要となる場合があります。 予防管理的側面の強い SLA を作成する場合は、ネットワーク設計者とアプリケーション設計者による技術チームを結成することを推奨します。 技術サポート員であれば、ネットワークのアベイラビリティとパフォーマンス能力、および特定の目標を達成するために必要な事柄をかなり厳密に見積もることができます。

サービス プロバイダーの SLA には通常、ユーザの意見は取り込まれません。これは、サービス プロバイダーが SLA を作成する目的が「他のサービス プロバイダーに対する競争上の優位性を獲得すること」に尽きるからです。 場合によっては上層部の経営陣が、自社サービスの普及を促進し、社内従業員に内部目標を与えるために、非常に高いアベイラビリティまたはパフォーマンスのレベルでこれらの SLA を作成することがあります。 その他に、内部的に測定および管理された強力なサービス レベル定義を作成することでアベイラビリティを改善するという技術的側面に専心しているサービス プロバイダーもあります。 他のケースでは、両方の取り組みを同時に行いますが、必ずしもそれらを 1 つにまとめたり、同じ目標を目指したりするとは限りません。

SLA に関与する関係者は SLA の目標に基づいて選択します。 目標には次のようなものが考えられます。

  • 事後対処的サポートのビジネス目標の達成

  • 予防的 SLA の定義による、最高レベルのアベイラビリティの提供

  • サービスの普及促進または販売

ステップ 9: サービスの要素の決定

主要なサービス/サポート SLA は通常、サポートのレベル、測定方法、SLA 調整のための報告経路、概算に関する全体的な考慮事項など、多くの要素から構成されます。 ハイアベイラビリティ環境のサービス要素には、事後対処的な目標だけでなく、予防的なサービス定義も含めるようにしてください。 その他にも、次のような項目が含まれます。

  • オンサイト サポート時間と時間外サポート用の手順

  • 優先順位の定義(問題のタイプ、問題についての作業を開始するまでの最大時間、問題解決までの最大時間、報告手順など)

  • ビジネス上の重要性の順にランク付けされた、サポート対象製品またはサービス

  • 専門知識への期待、パフォーマンス レベルの期待、ステータス レポート、および問題解決に対するユーザ責任のサポート

  • 地理的単位またはビジネス単位でのサポート レベルの問題と要件

  • 問題管理方法と手順(コール追跡システム)

  • ヘルプデスクの目標

  • ネットワーク エラーの検出とサービス応答

  • ネットワーク アベイラビリティの測定とレポート作成

  • ネットワーク キャパシティおよびパフォーマンスの測定とレポート作成

  • 競合解決手順

  • 実装された SLA の引き当て

ネットワーク対応アプリケーションまたはサービスの SLA には、ユーザ グループの要件とビジネス上の重要性に基づく追加のニーズが含まれる場合があります。 ネットワーク組織はこれらのビジネス要件に真摯に耳を傾け、サポート構造全体に合わせた特別なソリューションを展開する必要があります。 一部の人々またはグループにしか適用できないプレミア サービスを作成せずに、サポート体制全体に合わせる点が非常に重要です。 多くの場合、これらの追加要件は「ソリューション」カテゴリに分類できます。 具体例としては、ビジネス ニーズに基づいたプラチナ、ゴールド、シルバー ソリューションなどがあります。 個別のビジネス ニーズについては、次の SLA 要件の例を参照してください。

注:サポート構造、報告経路、ヘルプデスクの手続き、測定方法、優先順位の定義については、大部分は同じまま維持して、一貫性のあるサービス体制を維持し、向上させます。 

  • バースト時の帯域幅要件と能力

  • パフォーマンス要件

  • QoS の要件と定義

  • ソリューション マトリックスを作成するための、アベイラビリティの要件と冗長性

  • 監視とレポート作成の要件、方法論、および手順

  • アプリケーション/サービス要素のアップグレード基準

  • 予算外要件への資金投入、またはクロスチャージ方法

たとえば、WAN サイト接続用のソリューション カテゴリを作成できます。 プラチナ ソリューションの場合は、サイトに 1 対の T1 サービスが提供されます。 それぞれの T1 回線は異なる通信事業者が提供します。 サイトには 2 台のルータがあり、いずれかの T1 またはルータで障害が発生したときにサイトが停止しないように設定されます。 ゴールド サービスでも 2 台のルータがありますが、バックアップ フレームリレーが使用されます。 このソリューションでは、停止が起こると帯域幅が制限される可能性があります。 シルバー ソリューションではルータは 1 台のみで、通信事業者も 1 つです。 これらのソリューションはいずれも、問題チケットの異なる優先順位レベルに対応するよう考慮されています。 停止に対して優先順位 1 または 2 のチケットが必要な組織では、プラチナまたはゴールド ソリューションが必要になります。 これにより、カスタマーの組織が必要なサービスのレベルに資金を投入できます。 次の表は、エクストラネット接続のビジネス ニーズに応じて 3 つのレベルのサービスを提供する組織の例を示しています。

ソリューション

プラチナ

ゴールド

シルバー

デバイス

WAN 接続用の冗長ルータ

コア サイトでのバックアップ用の冗長ルータ

デバイスの冗長性なし

WAN

冗長化された T1 接続、複数の通信事業者

フレームリレー バックアップ付きの T1 接続

WAN の冗長性なし

帯域幅要件とバースト

バースト時のロード シェアリング機能を持つ冗長化された T1

ロード シェアリング機能なし、クリティカル アプリケーション専用のフレームリレー バックアップ、フレームリレー 64K CIR のみ

最大で T1 まで

パフォーマンス

往復応答時間:常に 100 ミリ秒以下

応答時間:99.9% の期待値で 100 ミリ秒以下

応答時間:99 % の期待値で 100 ミリ秒以下

アベイラビリティの要件

99.99%

99.95%

99.9%

ダウン時のヘルプデスクの優先順位

優先順位 1: ビジネスに不可欠なサービスのダウン

優先順位 2: ビジネスに影響を及ぼすサービスのダウン

優先順位 3: ビジネスに関する接続のダウン

ステップ 10: カスタマーのビジネス ニーズと目的の理解

このステップは SLA 作成者に大きな信頼感を与えます。 さまざまなビジネス グループのニーズを理解することにより、最初の SLA 文書はビジネス要件と所期の結果にかなり近いものになります。 カスタマーのサービスがダウンしたときに失われるコストの把握に努めてください。 見積もりは生産性の損失、収益の損失、およびカスタマーの信用の喪失という観点から行います。 少数の人々との取るに足りない結び付きでさえ、収益に重大な影響を及ぼす可能性があることを常に念頭に置く必要があります。 この場合は、起こりうるアベイラビリティ リスクおよびパフォーマンス リスクをカスタマーに確実に理解してもらうことが重要です。これによって、組織の側でもカスタマーが必要としているサービスのレベルをいっそう深く理解できるようになります。 このステップを省略すると、ただ単に 100 % のアベイラビリティだけを要求するカスタマーばかりが多数集まる可能性があります。

SLA 作成者は、ネットワークのアップグレード、ワークロード、および概算を考慮するために、組織のビジネス目標と発展についても理解することが求められます。 また、使用されるアプリケーションについて知ることも有益です。 組織が各アプリケーションについてのプロファイルを理解していることが望ましいものの、理解していない場合は、アプリケーションに対する技術的な評価を行って、ネットワークに関連する問題を確認するようにします。

ステップ 11: 各グループに必要な SLA を定義

主要なサポート SLA には、ネットワーク運用グループ、サーバ運用グループ、アプリケーション サポート グループなどの重要なビジネス単位や機能グループの代表を含める必要があります。 これらのグループは、サポート プロセスにおける役割だけでなく、ビジネス ニーズにも基づいて選出するようにします。 多くのグループから代表を選出することで、個々のグループのニーズに偏らない、公平な総合的サポート ソリューションを作成できます。 こうしなければ、サポート組織が個々のグループにプレミア サービスを提供するという、組織のサービス体制全体が埋もれるシナリオにつながる可能性があります。 たとえば、あるカスタマーは、実際には自身のアプリケーションのダウンタイム コストが収益の損失、生産性の損失、およびカスタマーの信用の喪失という観点から見て他のアプリケーションよりも相当低いにもかかわらず、自身のアプリケーションがこの会社の中で最もクリティカルであると主張するケースがあります。

同じ組織内でも、ビジネス単位が違えば要件も異なります。 ネットワーク SLA の目標の中に、異なるサービス レベルに対応するただ 1 つの総合的なフォーマットについて合意を得ることがあります。 ここでの要件とは通常、アベイラビリティ、QoS、パフォーマンス、および MTTR です。 ネットワーク SLA でこれらの変数を取り扱うには、QoS の可能な調整に対してビジネス アプリケーションの優先順位を設定し、ネットワークに影響するさまざまな問題の MTTR に対してヘルプデスクの優先順位を定義し、各種のアベイラビリティ要件とパフォーマンス要件に対応するソリューション マトリックスを作成します。 エンタープライズ規模の製造企業での単純なソリューション マトリックスの例を次の表に示します。 この表に、アベイラビリティ、QoS、およびパフォーマンスの情報を追加しても構いません。

ビジネス単位

アプリケーション

ダウンタイム コスト

ダウン時の問題の優先順位

サーバ/ネットワーク要件

製造

ERP

1

最高の冗長性

カスタマー サポート

カスタマー ケア

1

最高の冗長性

技術

ファイル サーバ、ASIC 設計

2

LAN のコア部分の冗長性

マーケティング

ファイル サーバ

2

LAN のコア部分の冗長性

ステップ 12: SLA の形式を選択

SLA のフォーマットはグループの要望や組織の要件によって異なります。 ネットワーク SLA のアウトラインの推奨される例を次に示します。

  1. 契約の目的

    • 契約に関与する関係者

    • 契約の目的と目標

  2. 提供されるサービスとサポート対象製品

    • ヘルプデスク サービスとコール追跡

    • MTTR 定義に対するビジネス上の影響を基準とした問題重要度定義

    • QoS 定義に対するビジネス クリティカルなサービスの優先順位

    • アベイラビリティ要件とパフォーマンス要件に基づいて定義されたソリューション カテゴリ

    • トレーニング要件

    • キャパシティ計画要件

    • 報告要件

    • レポート作成

    • 提供されるネットワーク ソリューション

    • 新規ソリューションの要求

    • サポート対象外の製品またはアプリケーション

  3. ビジネス ポリシー

    • 業務時間内のサポート

    • 業務時間後サポートの定義

    • 休日の適用範囲

    • 連絡先の電話番号

    • ワークロードの予測

    • 苦情処理

    • サービス適格基準

    • ユーザおよびグループのセキュリティ責任

  4. 問題管理手順

    • コールの起点(ユーザまたは自動)

    • 第 1 レベルの応答とコール修復率

    • コール追跡とレコードの保持

    • 発信側の責任

    • 問題の診断とコール クローズ要件

    • ネットワーク管理に関する問題の検出とサービス応答

    • 問題解決カテゴリまたは定義

    • 慢性的な問題の取り扱い

    • 重大な問題/例外コールの取り扱い

  5. サービス品質の目標

    • 品質の定義

    • 測定の定義

    • 品質の目標

    • 問題解決に取りかかるまでの優先順位別平均時間

    • 問題解決までの優先順位別平均時間

    • ハードウェア交換までの優先順位別平均時間

    • ネットワークのアベイラビリティとパフォーマンス

    • キャパシティの管理

    • 発展の管理

    • 品質レポート

  6. 要員計画と概算

    • 要員計画モデル

    • 運用の概算

  7. 契約の保守

    • 適合状況の検討スケジュール

    • パフォーマンス レポートの作成と検討

    • レポート規準の調整

    • 定期的な SLA の更新

  8. 承認

  9. 添付資料と提出物

    • コール フロー図

    • 報告マトリックス

    • ネットワーク ソリューション マトリックス

    • レポートの例

ステップ 13: SLA ワークグループの策定

次のステップは SLA ワーキング グループの参加者(グループ リーダーなど)を決めることです。 ワークグループには、ビジネス単位または機能グループからのユーザや管理者、または地域的拠点からの代表者が参加しても構いません。 参加者はそれぞれのワークグループで SLA の問題について意見を交換します。 主要な SLA 要素に合意する権限を持つ管理者や意思決定者も参加すべきです。 このような参加者には、SLA に関連する技術的な問題を定義する能力があり、なおかつ IT レベルの意思決定の権限を持つ、管理者であり技術者でもある人々(つまり、ヘルプデスク管理者、サービス運用管理者、アプリケーション管理者、ネットワーク運用管理者など)が含まれていても構いません。

ネットワーク SLA ワークグループは、多くのアプリケーションとサービスに対応するただ 1 つのネットワーク SLA について合意を得るために、幅広いアプリケーションおよびビジネスの代表から構成される必要があります。 ワークグループには、ネットワーク対応のビジネス クリティカルなプロセスとサービス、および個々のサービスのアベイラビリティ要件とパフォーマンス要件をランク付けする権限が必要です。 この情報は、ビジネスに影響する問題のタイプ別の優先順位付けに使用されるほか、ネットワーク上のビジネス クリティカルなトラフィックへの優先順位付けや、ビジネス要件に基づく将来的な標準ネットワーキング ソリューションの作成時にも使用されます。

ステップ 14: ワークグループの会議を開き、SLA の草案を作成

ワークグループでは最初にワークグループ憲章を作成します。 この憲章では、SLA の目標、イニシアチブ、およびタイム フレームについて明示します。 次に具体的な作業計画を策定し、SLA を作成、実装するためのスケジュールと日程表を作成します。 また、サポート基準に照らし合わせてサポート レベルを測定するためのレポート作成プロセスも開発します。 最後に SLA 契約のドラフトを作成します。

ネットワーク SLA ワークグループは、最初のうちは SLA を作成するために週に 1 回会合を開きます。 SLA の作成が完了し、承認を受けた後は、月に 1 回または四半期に 1 回会合を開き、SLA の更新について話し合います。

ステップ 15: SLA について協議

SLA 作成の最後のステップは最終的な交渉と承認です。 このステップには次のような作業があります。

  • ドラフトの検討

  • 内容の交渉

  • 文書の編集と改訂

  • 最終承認の取得

ドラフトの検討、内容の交渉、改訂というサイクルは、承認を得るために最終版を経営陣に提出するまで何度も繰り返される場合があります。

ネットワーク管理者の観点から見ると、達成可能で測定も可能な結果についての交渉が重要です。 パフォーマンスとアベイラビリティの契約を他の関連組織の契約と比較して詳しく説明してください。 これは、品質の定義、測定の定義、および品質の目標を対象とします。 追加サービスは費用の追加に相当する点に注意してください。 ユーザ グループに、サービスのレベルを追加するとそれだけコストが増える点を理解してもらい、それがクリティカルなビジネス要件であるかどうかを判断してもらうようにします。 コスト分析は SLA のさまざまな角度(ハードウェア交換時間など)から容易に実行できます。

ステップ 16: SLA の適合性について測定および監視

SLA の適合状況を測定し、結果を報告することは、SLA プロセスにとって長期にわたる一貫性と結果を確保するために重要な側面です。 通常は、SLA の主要コンポーネントをすべて測定可能なものとし、SLA の実装に先立って測定方法を導入することを推奨します。 さらに、ユーザ グループとサポート グループの間で月次ミーティングを開催し、測定結果の検討、問題の根本原因の特定、サービス レベル要件を満たす、またはそれを越えるようなソリューションの提案などを行います。 これにより、SLA プロセスが最新の品質改善プログラムとほぼ同じようなものとなります。

次の項では、組織の管理者層が自組織の SLA と全体的なサービス レベル管理をどのようにして評価できるかについて、さらに詳しく説明します。

サービスレベル管理のパフォーマンス指標

サービス レベル管理のパフォーマンス指標は、成果の尺度としてサービス レベルを監視し、改善するための仕組みを提供します。 これにより、組織はサービスの問題に迅速に対処し、その環境内のサービスまたはダウンタイム コストに影響を与える問題を容易に把握できます。 また、サービス レベル定義を測定しなければ、組織は事後対処的な立場をとらざるを得ないため、積極的になされた予防的措置がすべて無効になります。 サービスが十二分に機能していると賞賛する人はいなくなり、代わりに多くのユーザが要件を満たしていないサービスについて不満を口にするようになります。

サービス レベル管理のパフォーマンス指標は既存のサービス レベルを十分に把握し、現在の問題に基づいて調整を行うための手段を提供するため、サービス レベル管理の最も重要な要件になります。 これは予防的サポートを提供し、品質改善を行うための基盤です。 組織が問題について根本原因を分析し、品質改善を行う場合、サービス レベル管理のパフォーマンス指標は、アベイラビリティ、パフォーマンス、およびサービス品質を改善するための最良の方法論になりえます。

たとえば、次のような現実的なシナリオについて考えてみます。 X 社は長時間にわたってネットワークが頻繁にダウンするというユーザからの苦情を数多く受けていました。 X 社はアベイラビリティを測定し、少数の WAN サイトに主要な問題があることを突き止めました。 これらの結果をさらに詳しく調査すると、問題のほとんどが少数の WAN サイトで起こっていることが判明しました。 根本原因がわかり、X 社は問題を解決しました。 X 社では次にアベイラビリティのサービス レベル目標を設定し、ユーザ グループとの間で契約を作成しました。 その後の測定では、SLA に適合しないという理由から迅速に問題が検出されました。 そのため、ネットワーキング グループはプロ意識と専門知識を備えた、組織にとって貴重な存在と見なされるようになりました。 ネットワーク グループは本質的に事後対処的サポートから予防的サポートに移行し、会社の収益に貢献しました。

残念ながら、今日の大部分のネットワーキング組織は限られたサービス レベル定義しか持たず、パフォーマンス指標はまったく使用していません。 その結果、ネットワーキング組織では、根本原因を事前に特定し、ビジネス要件を満たすネットワーク サービスを構築する代わりに、ユーザからの苦情や問題への対応にほとんどの時間を費やしています。

サービス レベル管理プロセスの成果を確認するには、次の SLA パフォーマンス指標を使用します。

  • 文書化されたサービス レベル定義または SLA。アベイラビリティ、パフォーマンス、事後対処的なサービス応答時間、問題解決の目標、問題の報告などが定められています。

  • パフォーマンス指標の規準。アベイラビリティ、パフォーマンス、優先順位別のサービス応答時間、優先順位別の解決時間、その他の測定可能な SLA パラメータなどが含まれます。

  • 月 1 回のネットワーキング サービス レベル管理ミーティング。サービス レベルの適合状況を検討し、改善を実施します。

サービス レベル契約またはサービス レベル定義の文書化

最初のパフォーマンス指標は、SLA またはサービス レベル定義について詳述した文書です。 サービス レベル定義の第 1 の目標はアベイラビリティとパフォーマンスにするのが普通です。これは、アベイラビリティとパフォーマンスが最も重要なユーザ要件であるためです。

第 2 の目標の重要性は、アベイラビリティまたはパフォーマンス レベルの達成方法を定義する際に利用できる点にあります。 たとえば、アベイラビリティおよびパフォーマンスのターゲットとして思い切った値を設定している組織では、問題が起こらないようにすることと、問題が起こったときに早急に解決することが重要です。 第 2 の目標は所期のアベイラビリティとパフォーマンスのレベルの達成に必要なプロセスを定義する際に役立ちます。

事後対処的な第 2 の目標には次のようなものがあります。

  • コール優先順位による事後対処的なサービス応答時間

  • 問題解決の目標または MTTR

  • 問題の報告手順

予防的な第 2 の目標には次のようなものがあります。

  • デバイスダウンまたはリンクダウンの検出

  • ネットワーク エラーの検出

  • キャパシティまたはパフォーマンスに関する問題の検出

第 1 の目標であるアベイラビリティとパフォーマンスのサービス レベル定義には次のものを含める必要があります。

目標

  • 目標の測定方法

  • アベイラビリティとパフォーマンスの測定を担当する関係者

  • アベイラビリティとパフォーマンスのターゲットを担当する関係者

  • 非適合プロセス

利害の衝突を避けるため、可能であれば、同じ関係者が測定と結果を両方とも担当しないようにします。 ときどき、追加/移動/変更エラー、未検出エラー、またはアベイラビリティ測定に関する問題のために、アベイラビリティの数値を調整しなければならないことがあります。 サービス レベル定義には、精度を改善するため、および誤った調整を避けるために結果を変更するプロセスを含めても構いません。 アベイラビリティとパフォーマンスを測定する方法については、次のセクションを参照してください。

事後対処的な第 2 の目標のサービス レベル定義では、ネットワークまたは IT 全般にわたる問題を検出した後、組織がどのようにしてその問題に対処するかを規定します。次に例を示します。

  • 問題の優先順位の定義

  • コール優先順位による事後対処的なサービス応答時間

  • 問題解決の目標、または MTTR

  • 問題の報告手順

一般にこれらの目標は、そのときどきでだれが問題の責任を持つかということと、定義された問題に対処するために責任者は現在の作業をどの程度まで減らしてよいかを規定します。 他のサービス レベル定義と同様、サービス レベル 文書にも、目標の測定方法、測定を担当する関係者、および非適合プロセスについて詳しく記載する必要があります。

予防的な第 2 の目標のサービス定義では、組織がどのようにして予防的サポートを提供するか(たとえば、ネットワーク ダウン、リンクダウン、またはデバイスダウン状態の検出、ネットワーク エラー状態、ネットワーク キャパシティのしきい値など)を規定します。 品質の予防的管理は問題の解消と迅速な解決に効果があるため、予防的管理を推進するような目標を設定します。 これを実現するには通常、ユーザから連絡を受ける前に検出および解決した予防的なケースの数を目標として設定します。 多くの組織が、この目的のためにヘルプデスク ソフトウェアにフラグを設定し、予防的ケースと事後対処的ケースを識別しています。 サービス レベル 文書にも、目標の測定方法、測定を担当する関係者、および非適合プロセスについて詳しく記載する必要があります。

パフォーマンス指標の規準

定義されたサービス レベルの目標はすべて測定可能であることが常に推奨されます。これにより、組織でサービス レベルを測定し、アベイラビリティとパフォーマンスという第 1 の目標の達成を阻害するサービス問題の根本原因を特定できるほか、特定のターゲットに向けた改善を実施できます。 全体的に見ると、規準とは単に、ネットワーク管理者がサービス レベルの一貫性を管理し、ビジネス要件に従って改善を実施するためのツールに過ぎません。

残念ながら、アベイラビリティ、パフォーマンス、およびその他の規準を収集している組織はそれほど多くありません。 組織ではその理由として、完璧な精度、コスト、ネットワークのオーバーヘッド、および使用可能なリソースを提供できないことを挙げています。 これらの要素はサービス レベルの測定能力に影響を与える可能性がありますが、サービス レベルは全体的な目標に照準を合わせて管理し、改善すべきです。 完璧な精度は提供できなくても、これらの最も重要な目標を満たす低コスト、低オーバーヘッドの規準を作成することは多くの組織で今までにも可能だったはずです。

アベイラビリティとパフォーマンスの測定はサービス レベル規準において軽視されることが多い領域の 1 つです。 これらの規準をうまく利用している組織では、非常に単純な 2 通りの方法を使用しています。 1 つめの方法は、ネットワークのコア部分からエッジに対して Internet Control Message Protocol(ICMP; インターネット制御メッセージ プロトコル)ping パケットを送信することです。 この方法によってパフォーマンスに関する情報を取得することもできます。 また、この方法を活用している組織では、同類のデバイスを LAN デバイスや国内のフィールド オフィスなどの「アベイラビリティ グループ」に分類しています。 通常はネットワークの地理的領域やビジネス クリティカルな領域が違えばサービス レベルの目標も異なるため、この方法も魅力的です。 この方法を使用すれば、規準グループ別に特定のアベイラビリティ グループに属するすべてのデバイスの平均をとることができるため、適正な結果が得られます。

アベイラビリティを計算するためのもう 1 つの有用な方法は、トラブル チケットと、Impacted User Minutes(IUM)と呼ばれる測定値を使用することです。 この方法では停止によって影響を受けたユーザの数を表にまとめ、ユーザの数と停止時間(分)を掛け合わせます。 その時間帯における合計時間(分)のパーセンテージとして表すと、これはアベイラビリティに容易に換算できます。 どちらの方法も、ダウンタイムの根本原因を突き止めて測定する際に役立ち、その結果改善のターゲットが定めやすくなります。 根本原因カテゴリには、ハードウェアの問題、ソフトウェアの問題、リンクまたは通信事業者の問題、電源または環境の問題、変更障害、ユーザ エラーなどが含まれます。

測定可能な事後対処的サポートの目標には次のようなものがあります。

  • コール優先順位による事後対処的なサービス応答時間

  • 問題解決の目標、または MTTR

  • 問題の報告時間

事後対処的サポートの目標を測定するには、ヘルプデスク データベースを基に、次のフィールドを含むレポートを生成します。

  • コールが最初に報告された(またはデータベースに入力された)時間

  • 問題に対処する担当者によってコールが受け入れられた時間

  • 問題が報告された時間

  • 問題がクローズされた時間

これらの規準には、データベースに一貫して問題を入力し、リアルタイムで問題を更新するために管理者のインフルエンス(影響力)が必要となる場合があります。 場合によっては、ネットワーク イベントのトラブル チケットや電子メールによるリクエストを自動的に生成できます。 この方法を使用すれば、問題の開始時間を正確に特定できます。 この種の規準から生成されたレポートでは通常、問題はプライオリティ別、ワークグループ別、および担当者別にソートされており、起こりうる問題の特定に役立ちます。

予防的サポート プロセスを測定するには、予防的作業を監視し、その有効性の測定値を計算する必要があるため、事後対処的サポート プロセスよりは測定が困難です。 この領域では、今までほとんど何も行われてきませんでした。 ただし、実際にヘルプデスクにネットワークの問題を報告する人の割合がほんの数パーセントに過ぎないことは明らかであり、それらの人々が問題を報告すると、問題を説明したり、ネットワーク関連の問題として切り分けたりするのに時間がかかるのも明らかです。 冗長デバイスや冗長リンクの障害はエンド ユーザにほとんど影響を与えないため、必ずしもすべての予防的ケースがアベイラビリティとパフォーマンスに即時の効果をもたらすわけではありません。

予防的サービス レベル定義または契約を実装している組織がそれを行っているのは、ビジネス要件とアベイラビリティ リスクの可能性のためです。 事前対処的サポートではケースがユーザによって生成されるのに対し、予防的サポートではケースの品質またはパーセンテージの観点で測定が行われます。 どの領域でも同様に予防的ケースの量を測定することをお勧めします。 そのカテゴリとして、ダウン デバイス、ダウン リンク、ネットワーク エラー、キャパシティ違反などがあります。 アベイラビリティ モデリングと予防的ケースを使用してさらに作業を進めると、予防的サービス定義を実装することで達成されるアベイラビリティの効果を判断できる場合もあります。

サービス レベル管理のレビュー

サービス レベル管理の成果を測定するもう 1 つの尺度はサービス レベル管理の検討です。 これは SLA を作成しているかどうかにかかわらず実施することが望まれます。 サービス レベル管理の検討は、定義されたサービス レベルの測定担当者やサービス レベルの定義に関与した関係者との月次ミーティング時に実施します。 SLA が関係しているときには、ユーザ グループが出席しても構いません。 ミーティングの目的は、測定されたサービス レベル定義のパフォーマンスを検討し、改善を実施することです。

ミーティングの際は定められた議題を用意する必要があります。議題には次のような項目を含めるようにします。

  • ある一定期間にわたって測定されたサービス レベルの検討

  • 個々の領域で定義された改善イニチアチブの検討

  • 現在のサービス レベル規準

  • 現在の規準のセットに基づいてどのような改善が必要であるかについての議論

ある程度の期間が経過すると、組織ではグループの有効性を判断するために、サービス レベルの適合状況のトレンド分析を実施できます。 このプロセスは品質管理サークルまたは品質改善プロセスと同じです。 ミーティングは個々の問題をターゲットとして設定したり、根本原因に基づいてソリューションを決定したりする際に役立ちます。

サービス レベル管理の要約

要約すると、サービス レベル管理を実施することで、組織はサポート方法を事後対処的サポート モデルから予防的サポート モデルに移行できます。予防的サポート モデルでは、ネットワークのアベイラビリティとパフォーマンスのレベルが、最近発生した一連の問題によってではなく、ビジネス要件によって決定されます。 このプロセスを利用すれば、サービス レベルの継続的な改善を可能にする環境が構築され、ビジネス上の競争力が向上します。 サービス レベル管理は予防的ネットワーク管理の最も重要な管理要素でもあります。 そのため、すべてのネットワーク計画フェーズおよび設計フェーズで、できるだけサービス レベル管理を導入することを推奨します。また、ネットワーク アーキテクチャを新たに定義する場合は、最初からサービス レベル管理を実施してください。 これによって組織では最初からソリューションを適切に実装できるようになり、ダウンタイムや手直しの量を最小限に抑えることができます。


関連するシスコ サポート コミュニティ ディスカッション

シスコ サポート コミュニティは、どなたでも投稿や回答ができる情報交換スペースです。


Document ID: 15117