サービスレベルアグリーメントの適切な測定値を定義するにはどうすればよいですか？
私は、特定の構成に基づいて製品の正式なSLAをまとめることをますます求められている小さな開発会社で働いています。
開発の面ではこれに満足していますが、ハードウェア/プラットフォームの観点から現実的でない場合、ソフトウェアの観点から特定の目標を達成すると言っても意味がありません。クライアントは全体的なことだけを気にします。システムの可用性。
プラットフォームの観点から何を見るべきですか？どのような指標とレベルですか？
また、落とし穴は何ですか（たとえば、ソフトウェアの観点からは、修正時間を約束することは決してありません-何かを修正するために製品全体を書き直して、修正できると言う必要があるかどうかはわかりません5日は潜在的に不可能です-ハードウェア/ OS /プラットフォームの観点から何をコミットするのを避けるべきですか？
私はこの分野で豊富な経験を持っています。私は、ホスティングとサポートサービスを必要とするさまざまな企業部門に対して、ISPのようにデータセンターを運営している2つのフォーチュン5企業のために多くの仕事をしています。
通常、これらにはSLA（サービスレベルアグリーメント）とOLA（運用レベルアグリーメント））と呼ばれる2つのメトリックがあります。
SLAは、使用されているハードウェアのタイプによって満たされます。 SLAについて話すときは、レベルを使用してSLAを説明します。 SLA-1はゼロダウンタイム、SLA-2は最大1時間のダウンタイム、SLA-3は8時間などです。SLAは冗長機器を使用することで満たされます。ある会社では、高可用性を実現するために多くのCiscoを使用しています（Cisco CSMおよびGSSギア）。 SLAレベルについて話すとき、私たちは一般的にHA（高可用性）とDR（ディザスタリカバリ）について話します。企業に複数のデータセンターがある状況では、HAコンポーネントは通常データセンターごとの属性ですDRはデータセンター全体の属性ですが、RPO（リカバリポイント目標）とRTO（リカバリ時間目標）の両方で測定され、SLAレベルを意味します。
OLAは、実際の基本的な用語では、誰か（人間）が手動の介入/修正措置を必要とするイベントにどれだけ迅速に応答するかです。通常、OLAは応答時間の観点からも測定されます。それらは同じRTO/RPO目標を使用します。私が相談しているある会社は、OLAメトリックに6つのレベルを使用しています。ここでの最初の3つのレベルは、この例です。
OLA-1：RTO 0 <2時間OLA-2：RTO> = 2＆<= 4時間OLA-3：RTO> = 24時間＆<=データセンター障害でない場合は30日、DC障害> 30日。
OLAとSLAメトリックを駆動するものは、CIA評価と呼ばれるものです。CIA=機密性、整合性、および可用性。アプリケーションのデータは、そのアプリケーションに支払うビジネスユニットによって分類する必要があります。 CIAは、OLAとSLAのあるべき姿を推進するのに役立ちます。CIAレベルの各部分には、1から3までの番号が付けられます。たとえば、CIAの評価は1-1-1です。機密性が高く、整合性が最も高く、可用性が最も高いレベルになります。3-3-3のCIAレーティングは、可能な限り最低です。したがって、3-3-3のCIAレーティングは、通常、SLA＆OLAレベル6。SLA-6＆OLA-6は、保証されている最低（最長の応答時間）です。
CIAレーティングをどのように導き出すかは、通常、データが盗まれた場合（機密性）、侵害された場合（整合性）、またはシステムがダウンした場合（可用性）にビジネスが失う金額を把握することになります。したがって、機密データが盗まれた場合に1,000万ドルを失う可能性がある企業は、C評価が1であるか、データの損失が重大ではなく、企業にかかる費用が1,000ドルである場合、代わりにC評価が3になる可能性があります。 。
これは通常、私が相談した大企業がそのようなことを処理する方法です。
ソフトウェアの場合と同じように、ハードウェアの問題の修正時間を約束するのは遅いでしょう。ベンダーが何かの重大なバグを修正するのをいつ待つかはわかりません。 SLAレベルに関しては、「誰かがX時間以内に問題に取り組む」という形になる傾向があることがわかりました。もちろんXは、どれだけのレベルに依存するかによって異なります。支払いますが、私の経験では、1時間から8時間の間は正常に見えます。
ソフトウェアがインストールされているハードウェアの問題を復元するためにSLA）を提供するように求められた場合、答えは「いいえ」です。応答時間を約束することはできますが、制御する必要はありません。ハードウェア/ OS /ソフトウェアスタック全体を解決時間にコミットすることはできません。
たぶん、あなたの顧客は、あなたの製品にホストされた製品が本当に必要だと気まずい方法であなたに言っていますか？そうすれば、彼らは心配している内部の問題を回避し、あなたにチェックを切ることができます。
SLAを契約する際に考慮すべきことの1つは、SLA自体はまったく意味がなく、SLAは実行されません。
たとえば、ISPはネットワーク上で100％SLAを提供しますが、取り戻すことができる最大金額は毎月の請求額です。これは、帯域幅が安価で、金額にほど遠いためです。ネットワークがダウンしたときに失うお金の。
また、通常、契約書に記載されているのは、誰かが問題にどれだけ迅速に対応するかであり、実際に問題を修正するのにかかる時間ではありません。したがって、応答時間が短いことを約束する場合は、夜勤にインターンを配置して、目を覚ますまでチケットをシャッフルします。
私の経験では、このすべてのSLAビジネスは、実際には、あるとしてもごくわずかです。