意味のある稼働率SLAとは

稼働率SLAは約束のように見えて、実際には返金規定のように振る舞います。提供側はそれを知っています。契約する側は知らないことが多く、可用性を買ったつもりでサービスレベル契約に署名しますが、実際に買っているのは、可用性が得られなかったときに受け取れるわずかな割引です。

それが必ずしも悪い取引だというわけではありません。ただ、多くの人が結んでいるつもりの取引とは別の取引であり、その違いはシステムが止まって、契約には何と書いてあるのかと誰かが尋ねた瞬間に効いてきます。

スリーナインは完璧に近く聞こえますが、月に43分の停止を許容します。 フォーナインが許容するのは4分です。平日の午後に43分の障害を吸収できる事業なら、99.9%で十分であり、それ以上に費用を払う必要はありません。吸収できないのであれば、ナインをいくつ並べても助けにはなりません。契約は障害を防ぐのではなく、クレジットを支払うだけだからです。

稼働率SLAが分単位で約束していること

パーセントの表記は、非常に広い幅をごく小さな差に見えるかたちへ押し込めます。時間に直して書き出すと、その差はすぐに明らかになります。

ここから二つのことが導かれます。99.9%から99.99%への一歩は、許容される停止時間を十分の一に縮めますが、費用の増え方はふつうそれよりはるかに大きくなります。デプロイの工程まで含めて、単一障害点をひとつ残らず取り除く冗長化が必要になるからです。ここでいう冗長化とは、サーバーをもう一台置くことではありません。データベース、ネットワーク経路、認証層のすべてを二重にし、リリースそのものがサービスを止めないよう無停止デプロイまで用意することを指します。そしてファイブナイン以上の水準は、人が異常に気づいて対応するまでの時間より短いため、人の手を介さず自動で切り替わるシステムでなければ維持できません。

数字は、印象がよいかどうかではなく、障害が実際に一時間あたりいくらの損失を生むかで決めてください。その一時間の損失額を実際に計算してみると、多くの企業では、ひとつ上の等級に払う追加費用のほうが大きくなります。ほとんどの業務システムは、99.9%で正直に十分です。

サービスクレジットは賠償ではありません

ほとんどすべての稼働率SLAで定められている救済手段は、将来の利用料から差し引かれるクレジットです。通常は月額料金の一定割合で、しかもその月の請求総額を上限とすることが多くなっています。Google Cloud のコンピューティング SLA がその代表例で、クレジットのみ、顧客からの申請制、上限付きです。

つまり取り戻せる最大額は、その期間に支払った金額とおおむね同じです。多くのサービスにおいて、それは障害が生む損失よりはるかに小さい額です。月に数百ポンドのプラットフォームが一日分の売上損失を埋め合わせることはできませんし、埋め合わせられるような条件に同意する提供者もいません。さらにクレジットは、障害が起きたそのサービスの料金だけを基準に計算されることが多く、そのサービスに依存していた他のシステムが巻き添えで止まった分の損失は計算に入りません。

クレジットはまた、自動で付与されるのではなく申請が前提であることも少なくありません。違反に自分で気づき、自分で計算し、ときには三十日という短い期限のなかで請求を出さなければなりません。提供者には、目標を下回ったことを自分から知らせる義務はなく、実際に知らせる提供者はごくわずかです。

実務上の結論は、クレジットを保護だと考えるのをやめることです。クレジットは、提供者が自分の掲げた数字をどれだけ本気で扱っているかを示す指標にすぎません。実際にあなたを守るのはアーキテクチャであり、災害復旧のガイドで扱った復旧計画です。

すべてを決めるのは条項です

何を停止として数えるのか。 完全に応答しない状態だけなのか、性能の劣化も含むのか。三十秒かけて応答するサービスは使い物になりませんが、多くの定義では利用可能に分類されます。応答時間が重要なら、遅延のしきい値を定義そのものに書き込ませてください。

どう測るのか、誰が測るのか。 ほぼ例外なく提供者が、自社の監視で、自社のネットワークから測ります。それは提供者のインフラの測定であって、あなたの体験の測定ではありません。測定地点を合意したうえで、それとは別に独立した監視を必ず動かしてください。自分で観測していない数字は、争うことができません。

除外事項。 計画メンテナンスは通常まるごと除外されます。つまり提供者は、何ひとつ違反することなく毎月数時間サービスを落とせます。必要な事前通知の期間と、上限の有無を確認してください。定期メンテナンスが全面的に除外されると、契約書に書かれたパーセントと、実際に使えた時間との差ははっきり開きます。さらに、あなたの設定に起因するもの、第三者に起因するもの、不可抗力に起因するものも除外され、これらの区分はかなりの量を吸収します。

測定期間。 月次が標準で、利用者に有利です。年次の測定では、提供者は長時間の障害を出しながら目標を達成できてしまいます。99.9%であれば、まる一日の停止でも年間の許容枠に収まるからです。

応答と解決の違い。 多くの契約は一定時間内に応答することだけを約束し、修復については何も述べていません。一時間以内の応答と、期限のない修復という組み合わせはよくある形ですが、読んだ印象よりはるかに弱い約束です。

数字より先に求めるべきもの

見出しの数字ではなく、実際の振る舞いを変える項目を押してください。

計画メンテナンスの上限、事前通知と、繁忙時間帯を避けた作業枠をあわせて求めます。実際の可用性には、パーセントよりもこちらのほうが効くことが少なくありません。

状態の透明性、つまり公開のステータスページと、障害を速やかに掲載するという約束です。自分の障害を自分で公表する提供者は、その運用のしかたについて何かを語っています。

定義されたエスカレーション経路、名前または役割と時間が明記されていること。そうでなければ、障害対応は誰に連絡するのかを探すところから始まってしまいます。

大きな障害のあとの報告書、何が起きたのか、その結果として何を変えたのかを記したものです。提供者が渡せる書類のなかで最も情報量が多く、出したがらないという事実そのものもまた情報です。

繰り返しの未達に対する解約権。 慢性的に水準を下回るなら、違約金なしで離れられるべきです。この権利はどのクレジットよりも価値があります。損害に見合う唯一の救済だからです。

自分がSLAを提供する側なら

平均的な月ではなく、いちばん悪い月にも守れる数字を出し、約束する前に自分で測ってください。検証したことのない数字を約束した提供者は、その差を公の場で知ることになります。

計画メンテナンスを正直に定義し、その枠を守ってください。ステータスページを公開してください。誰にも求められなくても障害報告書を書いてください。残ってくれる顧客は、あなたが何が起きたかを理解していると信じられる顧客だからです。

そして各等級の価格は、実際に提供するのにかかる費用に合わせてください。フォーナインはマーケティング上の判断ではなく、冗長化されたインフラであり、自動フェイルオーバーであり、システムを止められないデプロイ工程です。そのすべてに請求書がついてきます。その運用基盤の多くは、CI/CDパイプラインのガイドから始まります。

Mecanikはサーバーセキュリティ分析の一環として、可用性の約束のもとでシステムを構築し運用しています。結ぶ価値のある約束は、ほぼ常に、調子の悪い一週間でも守れる約束です。

よくある質問

99.9%の稼働率はどれだけの停止を許容しますか。 年間8.76時間、月間43.2分です。99.99%へ進めると年間52.6分、月間4.32分まで縮み、十分の一になります。デプロイ工程を含めて単一障害点をすべて取り除く必要があるため、実現にかかる費用は通常、十倍をはるかに超えます。

サービスクレジットは停止に対する本当の賠償ですか。 いいえ。クレジットは通常、月額料金の一定割合であり、その月の請求額を上限とします。したがって取り戻せる最大額は支払った金額とおおむね同じで、障害が生む損失よりはるかに小さい額です。短い期限内の申請が前提であることも多く、目標を下回ったと提供者から知らせてくることはめったにありません。

稼働率SLAでは何を確認すべきですか。 何を停止として数えるのか、性能の劣化が含まれるのか、誰がどこから測るのか、除外事項が何を覆うのか、計画メンテナンスに上限と事前通知があるのか、測定期間が月次か年次か、そして約束が応答なのか解決なのかです。

測定期間はなぜそれほど重要なのですか。 月次の測定は利用者に有利です。年次の測定では、提供者は一度の長時間障害を出しながら目標を達成できます。99.9%であれば、まる一日の停止でも年間の許容枠に収まるからです。同じ障害でも、月次の契約なら明確な違反になります。

より高い数字の代わりに交渉する価値があるのは何ですか。 繁忙時間帯を避けた通知つきの計画メンテナンス上限、障害を速やかに掲載する公開ステータスページ、担当と時間が明記されたエスカレーション経路、大きな障害のあとの書面報告、そして繰り返しの未達に対する解約権です。最後のものだけが、損害に見合う唯一の救済です。