SLAマス数学 — 99.9%の可用性が実際にどれだけダウンタイム時間にコストをかけているか

こう考えましょう：クライアントとの会議中に、「99.99%の稼働率」という要求が出てきたら、「もちろん」と答えて、話は進みます。しかし6ヶ月後、あなたはSLAの信用額に関する条項に目を向け、どうしてここまで来たのかと驚きます。その保証は、1年間にちょうど52分のダウンタイムを許容しています——そしてそのほとんどは、1つの悪いデプロイによって消えてしまいます。

すべての開発者がSLAに署名する前に頭に持つべき数学です。

フォーマル

可用性パーセンテージは、次のシンプルなフォーマルを使ってダウンタイムに変換されます。

ダウンタイム = (1 – 可用性) × 周期

99.9%の稼働率の場合：1 – 0.999 = 0.001。1年間の分の分（525,960分）を掛け算して、525.96分——つまり1年間で8.77時間の許容ダウンタイムになります。これは災害的なダウンタイムではありません。これは、ある日曜日の午後、デプロイが長引くこと、データベースのフェイルオーバーが予想以上に長引くこと、そして夜間の依存関係のアップデートが認証サービスを破壊することです。8時間はとても短いです。

参照表

これをブックマークしてください。ここに記載されたすべての数字は同じ方法で計算されています——可用性から1を引いて、期間の分（分）を掛け算し、最も読みやすい単位に変換します。

可用性	1日あたりのダウンタイム	1週間あたりのダウンタイム	1ヶ月あたりのダウンタイム	1年あたりのダウンタイム
99%	14.4分	1.68時間	7.3時間	87.6時間
99.5%	7.2分	50.4分	3.65時間	43.8時間
99.9%	1.44分	10.08分	43.83分	8.77時間
99.95%	43.2秒	5.04分	21.92分	4.38時間
99.99%	8.64秒	1.01分	4.38分	52.6分
99.999%（五つの9）	0.864秒	6.05秒	26.3秒	5.26分

99.999%の行をもう一度読みましょう。1年間に5分26秒の許容ダウンタイム。総計を含みます。計画されたメンテナンス、ヘルスチェックの失敗、そしてロードバランサーが死んだノードを認識するのに必要な30秒を含みます。ほとんどのチームにとって、この数字がどれほど現実的かを計算できます。

五つの9が実際に必要とするもの

五つの9（99.999%）は「良いインフラストラクチャー」だけではありません。それは別のエンジニアリング分野です。その達成には次のものが求められます。

• すべての層における完全な冗長性 — スタックのどこにも単一のポイントの故障がない、DNS、CDN、データベース、アプリケーション層を含む
• サブ秒での検出を備えた自動フェイルオーバー — 人間が反応できないため、監視とフェイルオーバーは介入なしで動作する必要があります
• ゼロダウンタイムデプロイ — ブルー/グリーンまたはカナリー、自動ロールバック。どのデプロイがリスタートを必要とする場合、5分の予算を消費します
• 複数地域のアクティブアクティブ構成 — 1つの地域がダウンしても、あなたを連れて行かないようにする
• SLA外の計画されたメンテナンス — 多くの99.9% SLAは計画されたメンテナンスを明確に除外していますが、99.999% SLAはそのスペースをしばしば持たない

実際に99.999%を達成している企業——AWS S3、Google Cloud Storage——は、専門のリリビリティエンジニアチーム、長年のチャオスエンジニアリングデータ、そしてSaaS創業者を倒すほどのインフラ投資をしています。達成は可能ですが、偶然ではなく、高価ではありません。

あなたは 稼働時間／SLA カルキュレーター を使用して、どの可用性パーセンテージでも、どの期間でもこれらの変換を実行できます。

SLA信用問題

ここが人々を驚かせる部分です：クラウドプロバイダーのSLA信用は、あなたの実際の損失を補償しません。彼らはあなたの月額サービス料金の10～30%を信用として提供します。もしEC2を$500/月で支払い、2時間のダウンタイムがSLAを違反した場合、$50～150の信用を得る可能性があります。しかし、あなたは潜在的に数千ドルの収益を失い、インシデント対応にエンジニアの時間を使い、クライアントの信頼を損なっています。

あなたのクライアントとのSLAを書くとき、これは標準的なモデルであることを理解してください——信用はサービス料金に結びついた善意の贈り物であり、完全な補償ではありません。注意深く「補償条項」を読む必要があります。多くの企業クライアントは、実際の損害に関する言語を交渉しようとします。それは法律家とSREの間の別の話であり、SREの範囲外です。

月間と年間の窓は重要です

SLAは特定の期間で測定され、その期間が多くの人々が認識していないほど重要です。年間の99.9% SLAは、12ヶ月にわたって8.77時間の合計ダウンタイムを提供します。月間の99.9% SLAは、月ごとに43.83分しか提供されません——しかし、毎月リセットされます。

クライアントはほとんど月間測定を求めます——それは厳格に聞こえ、あなたが1ヶ月で悪い結果を出した場合に彼らに利点を与えます。しかし、彼らが常に認識していないのは、月間測定が実際にはあなたに少ない緩和を提供することです：43.83分 × 12ヶ月 = 525.96分/年、これは年間計算とまったく同じです。違いは、月間SLAでは、1ヶ月の悪い結果が、他の11ヶ月が完璧であった場合でも、違反を引き起こす可能性があるということです。

交渉の際に、可能な限り年間測定期間を推奨してください。クライアントが月間を強調する場合、その月に99.9%を達成できるよう、インフラが実際に達成できるようにする必要があります——平均ではなく、月ごとに達成できるように。

実際に約束すべきこと

ここに実際に役立つガイドラインがあります。

個人プロジェクトおよび初期段階の製品

99%は誠実で十分です。月に9時間のダウンタイムは、専門的なオペレーションチームを持たない小さなチームにとって現実的です。達成できる範囲を超えて約束しないでください——SLAの欠落による信頼性の損失は、初期段階での期待値を下げるよりも深刻です。

B2B SaaSおよび標準クラウドインフラストラクチャー

99.9%が適切な目標です。適切な監視、自動スケーリング、管理されたデータベース、およびデプロイにダウンタイムを必要としないCI/CDパイプラインがあれば、AWS、GCP、またはAzure上で、英雄的な努力を要せず、実際に達成可能です。43分の月間予算は厳しいですが、デプロイ自動化が整っている場合、実現可能です。

99.99%およびそれ以上の目標

これは本物の投資を必要とします：複数可用性ゾーンのロードバランサー、複数地域のフェイルオーバー、自動プロモーションを備えたデータベースのレプリケーション、そしてリリビリティを主な職務としている人物が必要です。もしクライアントが99.99%を要求し、そのインフラがまだ整っていない場合、誠実に99.9%に交渉し、99.99%を達成するための計画を提示する必要があります——それに伴うインフラコストの増加を価格に反映します。

99.999%はアマゾンやグーグルの領域です。金融インフラ、医療システム、またはテレコムグレードサービスを運営している場合、または専門のSREチームを備えている場合を除き、これは現実的なコミットメントではありません。

あなたの状況に合った数字を計算してください

ここでの数学は、どの時間帯でも、どの可用性目標でもスケーリングされます。非標準のSLA期間——90日間のローリングウィンドウ、財務四半期、カスタム測定期間——の場合、フォーマルは同じです：ダウンタイムパーセンテージを期間内の分の数に掛けます。

IO Tools上の稼働率/SLA計算機

の すべてのこの計算を処理します——どの可用性パーセンテージでも、どの期間でも、正確なダウンタイム許容量を入力し、SLA文書の作成やクライアントの稼働率要件に対して現実的な提案を提供するために役立ちます。 まとめ：99.9%は、専門的なリリビリティ投資をしない大多数のチームにとって現実的な上限です。それ以上のものは現実的なコストと本物のプロセス変更を必要とします。契約署名前に、あなたが約束する内容を理解してください。

SLA数学——99.9%稼働率が実際にあなたにどれだけのダウンタイムをもたらすか 2

あなたも好きかもしれません