SLAアップタイム計算機
SLA稼働率から許容ダウンタイムを計算します。
- Per year
- 8.8 h
- Per month (30d)
- 43.2 min
- Per week
- 10.1 min
- Per day
- 1.4 min
概要
可用性の目標はパーセンテージで語られますが、パーセンテージは規模を伝えるのが 苦手です。99% と 99.9% は表記上は隣同士に見えて、年間では 3 日以上違います。 この計算機はパーセンテージを時間に変換します。この数字が実際に役に立つ形は、 時間の方です。
可用性の値を入れると、年・月・週・日それぞれで許されるダウンタイムが出ます。
使い方
- Availability (%) に可用性を入力するか、プリセットのボタンを押します。
- Per year・Per month (30d)・Per week・Per day の 4 つの窓で 許容ダウンタイムを読みます。
プリセットは実際の契約に現れる水準を並べています。90・95・99・99.9・99.95・ 99.99・99.999 の 7 つです。
早見表
| 可用性 | 年あたり | 月あたり (30日) | 週あたり | 日あたり |
|---|---|---|---|---|
| 90% | 36.50 days | 3.00 days | 16.8 h | 2.4 h |
| 95% | 18.25 days | 1.50 days | 8.4 h | 1.2 h |
| 99% | 3.65 days | 7.2 h | 1.7 h | 14.4 min |
| 99.9% | 8.8 h | 43.2 min | 10.1 min | 1.4 min |
| 99.95% | 4.4 h | 21.6 min | 5.0 min | 43.2 s |
| 99.99% | 52.6 min | 4.3 min | 1.0 min | 8.6 s |
| 99.999% | 5.3 min | 25.9 s | 6.0 s | 864 ms |
注目すべき点が 2 つあります。まず日あたりの列は、1 回の不良デプロイがその中に 収まらなければならない量です。そして 99.99% あたりを下回ると、日あたりの許容 ダウンタイムは、人がアラートに気づき、ダッシュボードを開き、何をするか判断する までにかかる時間より短くなります。ここが、信頼性が運用の問題であることをやめて アーキテクチャの問題になる実務上の境界線です。
目標をどう決めるか
野心から前へ進めるのではなく、結果から逆算してください。
まず、停止中に何が起きるかを問います。バッチ処理が遅れて後で追いつくだけなら、 目標は低くてかまいません。顧客が購入を完了できないなら、目標は売上に従います。 緊急のサービスがそれに依存しているなら、そもそも問うべきはこの数字ではありません。
次に、目標を依存先と突き合わせます。直列に並ぶものについて、可用性は乗算的に 劣化します。99.9% の部品 3 つを必要とするサービスは、自分自身が何も間違えて いない段階で上限が約 99.7% です。クリティカルパスが許す以上を約束することは できず、リトライを足しても、失敗が独立でない限り算術は変わりません。
最後に、復旧のプロセスと突き合わせます。フェイルオーバーが手動で、オンコールの 呼び出しがメールで届くのに 99.99% を掲げるなら、それは目標ではなく願望です。 数字が機構を規定します。
SLO と SLA は別の数字
社内の SLO は契約上の SLA より厳しく保ってください。その差が運用余裕、つまり 自分の目標は割って対応を始めたが、まだ違約が発生していない領域になります。
契約 SLA が 99.5% で社内 SLO が 99.9% なら、最初のシグナル（43 分）から最初の 利用料返還（3.6 時間）までに月あたり約 2.9 時間の余裕が生まれます。2 つの数字が 等しければ、気づいた瞬間が支払いの発生した瞬間でもあり、問題を静かに処理する 余地は残りません。
除外条項も読んでください。多くの SLA は、告知済みのメンテナンス、顧客自身の設定 に起因する障害、不可抗力を数えません。この控除があるために、利用者が現実に 不可用を体験した月でもサービスは SLA を達成し得ます。これは法的な帰結であって、 エンジニアリング上の帰結ではありません。
何を「ダウン」と数えるか
パーセンテージは算術で、難しいのはそれを当てる定義の方です。2 つのチームが同じ 1 か月について違う可用性を報告し、どちらも嘘をついていない、ということが起こります。
どこから測るか。 自社ネットワークの内側からのチェックは、CDN・DNS・ インターネット経路を飛ばします。利用者に見える失敗の大きな割合はそこで起きます。 外から測れば、利用者の体験に近く、ダッシュボードが示すものより悪い数字が出ます。
どの頻度で測るか。 5 分間隔のプローブは 5 分より短い停止を検出できず、 30 秒の停止をタイミング次第で 0 分または 5 分のダウンタイムとして計上します。 粗いプローブは信頼性を上げません。測定の見える範囲を狭めるだけです。
どのエンドポイントか。 プロセスが生きていれば 200 を返すヘルスチェックは、 実際のリクエストが全滅している停止中も満点の可用性を報告します。チェックは 問題になる依存先を実際に叩かなければなりません。
部分障害をどう扱うか。 20 あるエンドポイントのうち 1 つが壊れているとき、 サービスは動いているのか。時間ベースの定義はたいてい「動いている」と答え、その エンドポイントの利用者は「動いていない」と答えます。可用性を稼働区間ではなく 成功リクエストの比として定義する主な理由がこれで、その枠組みは エラーバジェット計算機 を参照してください。
数字を約束する前に定義を書き下してください。後で意見が食い違うのは、定義の ところです。
使用例
- 冗長化の費用を正当化する — 99.9% が許すのは月 43 分です。手動フェイル オーバーの単一リージョン構成は、1 回のインシデントで日常的にそれを超えます。
- メンテナンス窓の長さを決める — 4 時間の窓は、ダウンタイムに数えるなら 99.9% 以上のすべてで予算超過です。契約上数えないか、無停止の移行手順が必要か、 どちらかになります。
- 事業者の宣伝文句を検算する — 自動フェイルオーバーがどのドキュメントにも 書かれていない 99.99% は、技術仕様ではなく販促の数字です。
- アラート閾値を決める — 99.95% では、週 1 分のダウンタイムが週次バジェット の 5 分の 1 です。それが監視に要求される解像度です。
注意事項
ここでは年を 365 日、月を 30 日としています。閏年と暦月の長さでわずかに数字が 動くため、契約がその差で成否を分ける場合は契約に書かれた定義を使ってください。
表示は読みやすい単位に自動で切り替わります。1 秒未満はミリ秒の整数、1 分未満は 秒、1 時間未満は分、1 日未満は時間、それ以上は日で、いずれも小数第 1 位（日は 第 2 位）までです。丸めた表示なので、細かい比較をするときは元のパーセンテージ で計算してください。
このツールが答えるのは「このパーセンテージは何分のダウンタイムを許すか」です。 バジェットに個別の失敗リクエストが何件収まるかも知りたい場合は エラーバジェット計算機 を使ってください。同じ算術を時間で はなくリクエスト量に当てたものです。