SLA（Service Level Agreement）は、サービスプロバイダーによく見られるサービスの信頼性を保証する形式です。 通常、SLAはオファーとして提供されます。満足してサービスを使用するか、別のサービスを探しています。 典型的な言い回しは「業界トップの99.95％の月間稼働率SLA」であり、ほとんどのユーザーに適しているようです。
通常、潜在的なユーザーは「99.95％の月間稼働率SLA」について読んだ後、非常に満足しています。30日間、月に21分以上ダウンタイムが発生しないという保証は非常に有望です。
クラウドサービスを自分のニーズに合わせて消費する限り、すべては比較的単純です。 私たちは99.95％を見て、1か月あたり21分を超えないことを考えました-感銘を受け満足しました。 自分で別のサービスに基づいてサービスを作成し、提供できるSLAを決定した場合はどうなりますか？
たとえば、画像処理サービス（疑わしいことにABBYY Cloud OCR SDKに似ています ）。 このようなサービスに提供できるSLAは何ですか？ 他のサービスへのすべての依存関係を取り、SLAを注意深く読み、9の数を見て、SLAに書き込むことができる小数点以下のナインの数を決定する必要があるように思われます。
イメージ処理サービスがWindows Azureで実行され、Azure Cloud ServicesのいわゆるWebロールとWorkerロールを使用してコードとAzure Storageを実行し、データを保存するとします。 素晴らしい。 クラウドサービスでSLAを開くと、TL; DR; ロールインスタンスの可用性は、1か月あたり99.95％保証されます（各ロールに少なくとも2つのインスタンスがある場合）。 Azure StorageでSLAを開くと、TL; DR; ストレージ要求の少なくとも99.9％のパフォーマンスが保証されます。 品質レベルが保証レベルに対応していない場合は、サポートに連絡する必要があります。その場合、サプライヤーはお金の一部を返却します。
これは、示された2つのサービスのSLAの非常に短い要約でした。 これらのサービスのいずれかを使用する場合は、すべての予約を注意深く読み、考慮する必要があります。
以下は基本的に重要です：最悪の場合でも、比較的少量のお金があなたに返されますが、それはカバーします...しかし、それは消費されたサービスのコストのほんの一部に結び付けられ、クラウドサービスを使用するコストは従業員の報酬などと比較して非常に低いため、何もカバーしませんサービスプロバイダーのサポートに連絡する担当者。 3ナインでのSLAの意味は非常に単純です：「親愛なるユーザー、これは非常に信頼できるサービスです。私たちは非常に一生懸命、注意して使用します。来月10日までに請求します。」 たとえば、時間の15％の間に可用性が保証される場合、サービスからの期待は根本的に異なります。
サービスが上記のSLAを備えた別のサービスに実質的に依存している場合、ユーザーにどのような保証を与えることができるかという問題に戻ります。 コードが実行されるマシンの可用性は、少なくとも99.95％の時間保証されているようです。 リポジトリへのアクセスの一部は失敗する可能性がありますが、10分の1パーセント以下について話すことは怖いことではありません。失敗したリポジトリ操作が一時停止を増やして数回繰り返されるようにサービスを設計する必要があります。ユーザー要求のリセット-これが頻繁に発生しない場合、ユーザーは完全に満足します。
したがって、いくつかの会議とコピー内の全員との2週間のやり取りの後、すべてを掛け合わせて提供できるものを決定できます。たとえば、サービスは月の99.9％の時間稼働しています。 このようなSLAを策定したら、ユーザーに「当社のサービスは信頼性があり、それを使用し、すべてがうまくいきます。そうでなければ、パニックなしで非常に迅速に修正します」と伝えます。
あなたはそのようなSLAを公開し、しばらくするとそれは非常に予想外です...
...非常に迷惑なエラーの修正を緊急に公開する必要があることに気づきました。 または、インフラストラクチャレベルで設定を変更する必要があります。 または、サービス自体が負荷が増加したことを認識し、スケーリングのためのコマンドを発行する必要があると判断しました。
これらすべてのアクションについて、クラウドインフラストラクチャで追加の管理サービスが使用されます（そのようなサービス上で実行されるポータル、またはそのようなサービスに呼び出しを送信するプログラムを使用している場合があります）。 これは非常に重要なサービスです。クラウドが非常に柔軟で使いやすいのは、その存在のおかげです。 そして、この非常に重要なサービスはまさにこの非常に重要な瞬間であり、あなたが何かをする必要があることが非常に非常に緊急であり、あなたのリクエストを処理することを拒否します。
多数のプレゼンテーション、スクリーンキャスト、および指示で、新しい仮想マシンの展開、サービススタッフィングを含むパッケージの公開、および他の多くの操作で、このサービスが左右にどのように使用されるかがわかります。 重要なことを誰もあなたに伝えません。このサービスはクラウドを管理する唯一の機会です。 管理サービスに何か問題があるとすぐに、非常に大きな問題が発生する可能性があります。
SLAの文言に戻ります。 明らかに、更新のスケーリングや公開などの操作の必要性を何らかの形で予測し、SLAで考慮する必要があります。 そして、はい、私たちのサービスは、ユーザーからの大量の（事前に不明な）画像を十分に迅速に処理する必要があるようです。そのためには、スケーリングできる必要があります。 そして、これらの必要な操作には、「補助」管理サービスの使用が必要です。
次に、この管理サービスのSLAを見て、それから何を期待するのかを理解することが論理的です。
Windows Azureでは、管理APIを使用してインフラストラクチャを管理します（管理ポータルとコマンドレットも機能します）。 そのため、Management APIサービスのSLAを開き、...
...しかし、いいえ、それは単に存在しないので、このドキュメントに精通することはできません。 また、Amazon EC2にはSLAインフラストラクチャ管理サービスもありません。
待って... OH SHI〜
はい、私たちはサービスにSLAが完全に欠けていることをほとんど無視しました。 コードの更新だけではありません（遅延しているように見えますが、実際には非常に緊急に公開する必要がある場合があります）-スケーリングする能力が常に必要です。
管理サービスにSLAがないのはなぜですか？ 推測することしかできません。
クラウド管理インフラストラクチャの信頼性を十分に高めるのはそれほど簡単ではないと想定できます。 特定の仮想マシンがネットワーク経由でアクセス可能であることを約束することの1つであり、さらにいくつかのノードへのスケーリングが確実に可能であることを約束することの1つです。
代わりに、ユーザーは管理サービスを重要なサービスとは見なさず、「メイン」サービスの現在のSLA方式に非常に満足していると想定できます。
あるいは、それを想定し、同時に別の想定を立てる
いずれにせよ、クラウドサービスプロバイダーにはまだサービスを開発する余地があり、ユーザーは自分のサービスの依存関係についてより注意する必要があります。 そうでなければ、小数点以下の印象的な数の9からは、使用できません。
ドミトリー・メッシェリャコフ、
開発者製品部門