私は小規模な開発会社で働いていますが、特定の構成に基づいて製品の正式な SLA をまとめるよう求められることが増えています。
開発の面から言えば、私はこれに満足していますが、ハードウェア/プラットフォームの観点から現実的でない特定の目標をソフトウェアの観点から達成できると言っても意味がありません。クライアントが気にするのは、システム全体の可用性だけです。
プラットフォームの観点から何に注目すべきでしょうか? どのような指標やレベルでしょうか?
また、注意すべき点は何でしょうか (たとえば、ソフトウェアの観点からは、修正時間を約束することはありません。何かを修正するために製品全体を書き直す必要があるかどうかはわかりません。そのため、5 日以内に修正できると言うことは不可能である可能性があります。ハードウェア/OS/プラットフォームの観点から、どのような約束を避けるべきでしょうか)。
答え1
私はこの分野で豊富な経験があり、ホスティングとサポート サービスを必要とするさまざまな企業部門向けに ISP のようにデータ センターを運営しているフォーチュン 5 企業数社のために多くの仕事をしています。
通常、SLA (サービス レベル契約) と OLA (運用レベル契約) と呼ばれる 2 つのメトリックがあります。
SLA は、使用するハードウェアの種類によって満たされます。SLA について説明するときは、レベルを使用して説明します。SLA-1 はダウンタイムなし、SLA-2 は最大 1 時間のダウンタイム、SLA-3 は 8 時間などです。SLA は、冗長機器の使用によって満たされます。ある会社では、高可用性を実現するために Cisco を多用しています (Cisco CSM および GSS 機器)。SLA レベルについて説明するときは、通常、HA (高可用性) と DR (災害復旧) について説明します。会社に複数のデータ センターがある場合、HA コンポーネントは通常、データ センターごとの属性ですが、DR はデータ センター全体の属性です。どちらも、SLA レベルを意味する RPO (復旧ポイント目標) と RTO (復旧時間目標) で測定されます。
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 は、機密性が非常に高く、整合性レベルが最も高く、可用性レベルが最も高いことを意味します。CIA 評価 3-3-3 は、最低の CIA 評価です。したがって、CIA 評価 3-3-3 は通常、SLA と OLA レベル 6 にマッピングされ、SLA-6 と OLA-6 は最低 (応答時間が最も長い) であることが保証されます。
CIA 評価を導き出す方法は、通常、データが盗まれた場合 (機密性)、データが侵害された場合 (整合性)、またはシステムがダウンした場合 (可用性) に企業がどれだけの金額を失うかを計算することです。したがって、機密データが盗まれた場合に 1,000 万ドルの損失が発生する可能性がある企業は C 評価 1 になる可能性があります。また、そのデータの損失が重大ではなく、企業に 1,000 ドル程度の損害しか与えない場合は、C 評価 3 になる可能性があります。
私がコンサルティングを行った大企業は、典型的にはこのような方法でこのようなことを処理しています。
答え2
ソフトウェアの場合と同様、ハードウェアの問題の修正時間については、約束するのが遅いでしょう。ベンダーが何かの重大なバグを修正するのをいつ待つことになるかはわかりません。SLA レベルに関しては、「誰かが X 時間以内に問題に取り組みます」という形式になる傾向があることがわかりました。X はもちろん、支払われる金額によって異なりますが、私の経験では、1 時間から 8 時間の間が普通だと思います。
答え3
ソフトウェアがインストールされているハードウェアの問題の修復について SLA を提供するよう求められた場合、答えは「いいえ」です。応答時間を約束することはできますが、ハードウェア/OS/ソフトウェア スタック全体を制御せずに解決時間を約束することはできません。
おそらく、顧客は、あなたの製品にホスト型サービスが本当に必要だと、気まずい言い方で伝えているのではないでしょうか。そうすれば、顧客は心配している内部の問題を回避し、あなたに小切手を切るだけで済みます。
答え4
SLA を契約する際に考慮すべきことの 1 つは、SLA 自体にはまったく意味がなく、SLA が満たされなかった場合の罰則とともに遵守する必要があるということです。
たとえば、当社の ISP はネットワーク上で 100% の SLA を提供していますが、返金される最大額は月額料金のみです。これは、最近の帯域幅は安価であるため非常に低く、ネットワークがダウンしたときに失う金額に比べればはるかに少ない金額です。
また、契約書に書かれているのは、問題にどれだけ早く対応するかであって、実際に問題を解決するのにどれだけ時間がかかるかではありません。ですから、短い対応時間を約束させられたら、インターンを夜勤に配属して、あなたが起きるまでチケットをシャッフルしてもらいましょう。
私の経験では、この SLA ビジネスは、実質的にはほとんど意味がありません。