SLA計算機

コンテンツの表

1 完全なSLAガイド

2 SLAレベルの説明

3 ダウンタイムの参照のテーブル

完全なガイド

包括的なSLAガイド

SLAとは?

サービスレベル契約(SLA)は、サービスプロバイダとサービスの期待レベルを定義する顧客との間の契約で、通常、稼働時間の割合として表現されます。 SLAは、特定の期間(日、月、または年)に許されるダウンタイムの最大量を指し、プロバイダが保証を満たしていない場合、多くの場合、金融罰またはサービスクレジットを含みます。 SLAはクラウドホスティング、通信、SaaS、マネージドサービスに共通しています。

ダウンタイムの計算方法は?

式は次のとおりです。ダウンタイム = (1 − SLA)%) × 期間。例えば、99.9で% 1年以上のSLA (525,600分): ダウンタイム = 0.1% × 525,600 = 526 分(約 8.76 時間)/年この計算機は、同じロジックを毎日、月々、年々の期間に適用しますので、各ウィンドウで最大の許可された停電を見ることができます。

SLA対SLO対SLI

SLA(サービスレベル契約)は契約保証です。 SLO (Service Level Objective) は、SLA よりも大きく設定し、バッファを作成します。 SLI(サービスレベルインジケータ)は、測定する実際のメトリック(例えば、監視による可用性の割合)です。よい練習:あなたのSLO 0.5–1を置く% 通常の変動が合意に違反しないため、SLAの上で。

主なコンセプト:

アップタイム %: SLAのパーセンテージ(99.9など)%) は保証された可用性です。残りは許可されたダウンタイムです。
The "nines": 99% = 2つのニン; 99.9% = 3本; 99.99% = 4つのニン;99.999% = 5 ニン。より多くのnines =許可されたダウンタイムおよび通常より高いコスト。
サービスクレジット: 侵害のための典型的な救済(例えば10〜25% 月額料金 0.1% SLA以下、現金での払い戻しはできません。
除外: メンテナンス、不可抗力、顧客使用の停止は通常、ダウンタイムから除外されます。

顧客対プロバイダーの視点

顧客として

プロバイダーが失敗した場合、明確な稼働時間保証とクレジットを取得します。
この計算機を使用して、SLAが許可する(日、月、年)どのくらいのダウンタイムを確認します。
契約中の免責、測定方法、およびクレジットキャップの交渉
ハイアール SLA (99.99 など)%) 通常、コストが高まり、ビジネスへの影響に対するバランス。

プロバイダーとして

最大ダウンタイムにコミットし、クレジットやペナルティをトリガーします。
SLAの上の内部SLOを設定し、侵害を回避します。
ダウンタイムとしてカウントを正確に定義し、スケジュールされたメンテナンスを除外します。
契約で使用される同じ方法論の可用性を監視します。

SLAのメリット

クラリティ: 両当事者は、予想される可用性と故障の結果に同意します。
責任: プロバイダーは、ターゲットを満たすためのインセンティブを持っています。顧客は定義された治療法を持っています。
計画: 最大許容ダウンタイム(例43分/月99.9%) 能力とインシデントの対応計画を支援します。
信頼: SLA(クラウドプロバイダーなど)の公開は、透明性と比較をサポートしています。

制限と検討

SLAは、ダウンタイムをゼロにしない可用性の保証です。許可された停電は、ユーザーに影響を与える可能性があります。
サービスのクレジットは、まれに結果的な損傷を覆います(失われた収益、評判);責任のキャップが適用されます。
ダウンタイムの定義は異なります。部分的なアウトタイム、最小限の期間、および除外は明確に述べなければなりません。
5つのナインを達成する(99.999)%) 重要な冗長性および費用を必要として下さい;すべてのシステムがそれを必要としません。

重要:

SLAは、停電を防止しません。それは、プロバイダがそれを超えると、どのくらいのダウンタイムが許され、何が起こるかを定義します。常に、ダウンタイム、測定方法、および除外されるもの(メンテナンス、力majeure)を定義します。サービスのクレジットは、通常、キャップされ、ショートウィンドウ内で主張されなければなりません。彼らはビジネスの継続計画を置き換えません。

正しいSLAレベルを選ぶ

適切なSLAを選択すると、ビジネスへの影響、コスト、および実現可能性に依存します。検討:

重要性: ダウンタイムの1時間分の費用は何ですか? 顧客向け収益システムは、多くの場合、99.9を必要としています% またはより高い。
費用: ハイアールSLA (99.99)%, 99.999%) 冗長性および工学を要求して下さい;保証は重要である場合もあります。
業界規範: クラウドプロバイダは、多くの場合、99.9-99.99を提供%; 電気通信および財政は5つのninesを要求するかもしれません。
測定: 契約がポーリング間隔、場所、およびスケジュールされたメンテナンスが除外される方法を指定することを確認します。

クイックリファレンス:SLAによるダウンタイム

スラ	月日	1 年間
99%	7.3 h	3.65 days
99.9%	43.8 min	8.76 h
99.99%	4.4 min	52.6 min
99.999%	26 sec	5.26 min

結論:

SLAsは、提供者が不足したときに、可用性の明確な期待を設定し、治療を提供しました。この計算機を使用して、SLAのパーセンテージを具体的なダウンタイム制限(日、月、年)に変換し、測定、除外、およびサービスのクレジットに関する明確な契約条件と組み合わせます。重要なサービスについては、実際にSLAに会うことができる監視およびアーキテクチャに投資するか、または要求します。

レベル

SLAレベルの説明

典型的なSLAの層およびその影響。 AWS、Azure、およびGCPは通常99.9を提供します。% へ 99.99% サービスによっては5つのニン(99.999)%) N+2冗長性を要求し、電気通信および中心の銀行で共通です。

99% – 99.5%

~7.3 h /月 (99)%) または~3.6 h/month (99.5)%). 非批判的な内部ツール、dev/staging に適しています。安価、より少ない保証。

99.9% (three nines)

~43.8分/月ビジネスアプリ、電子商取引、SaaS の共通。多くのクラウドプロバイダのための業界標準。

99.99% (four nines)

~4.4 日/月重要なシステム、金融サービス、決済ゲートウェイ。冗長アーキテクチャが必要です。

99.999% (five nines)

~26秒/月テレコム級、ミッションクリティカル(911、コアバンキングなど)。達成し、作動する非常に高価。

参考文献

ダウンタイムの参照のテーブル

この表を使用して、一般的なSLAレベルの1日、月、および年の最大許容ダウンタイムを表示できます。値が1 − SLAから派生する%) × 数分

スラ	一日あたり	月日	1 年間
99%	14.4 min	7.3 h	3.65 days
99.9%	1.44 min	43.8 min	8.76 h
99.99%	8.6 sec	4.4 min	52.6 min
99.999%	0.86 sec	26 sec	5.26 min

ベストプラクティス

SLAの選択と交渉

SLAを定義または交渉するときは、明確さと測定性に焦点を当てます。以下の点は、紛争を回避し、合意が執行可能であることを確認します。

キーポイント:

ダウンタイム(予定メンテナンスを除く)のカウントを定義しますか? 最小限の期間?)
測定を指定する: ポーリング間隔、場所、および可用性 % 計算される
サービスのクレジットまたはペナルティを含む。典型的な10〜25% クレジット 0.1% 以下のSLA
30日以内にインシデントレポートと根本原因分析が必要

ダウンタイム(予定メンテナンスを除く)のカウントを定義しますか? 計画された出金は事前に発表しましたか?)
SLAのコストが高まり、ビジネスへの影響に対する残高が高くなります。 1時間の停電は、99.99のプレミアムよりも費用がかかる場合があります%.
契約中のサービスクレジットまたは罰を含みます。典型的な: 10-25% クレジット 0.1% SLA以下
透明インシデントレポートと根本原因分析(RCA)を30日以内に要求します。
異なるサービス層(例、プレミアム対標準サポート)のための別のSLAを検討してください。
測定方法論: ポーリング間隔(1分?5分?)、監視ポイント数、地理的カバレッジを指定します。
Avoid ambiguity: define "available" precisely (e.g., HTTP 200 within 5 seconds from at least 2 of 3 regions).

重要事項

ダウンタイムのカウントは?

SLAの定義は契約により異なります。紛争を避けるため、以下の記述を明らかにします。

メンテナンス予定:通常は除外されます。事前に5～14日前までにご連絡下さい。
力属性:自然災害、戦争 - 典型的に除外される。
顧客使用停止: 不正設定 - 除外されます。
一部発生:一部のプロバイダは、非可用性のみをカウントします。劣化した性能はカウントされません。
Minimum outage duration: Outages under 5 minutes may be excluded ("consumption" clauses).
サードパーティの依存関係:上流プロバイダー(クラウド、CDN、DNS)による損害は、契約で明確にカウントされない場合があります。

法律相談

サービスのクレジットと罰

SLAが侵害されると、サービスクレジットは典型的な救済(現金払い戻しなし)です。例構造:

99.9% 壊れたが、≥99.0%: 10% クレジット
99.0% 壊れたが、≥95.0%: 25% クレジット
&95.0%: 50～100% クレジット

クレジットは通常、キャップされます(例えば100% その月の料金)。 30〜60日以内に請求しなければなりません。クレジットは、重要なサービスに対する別々の責任規定(売上、評判の損失)を補償しません。

業界トップ

業界別SLA

典型的なSLAの期待はセクターによって変わります。独自のSLAを定義または交渉する際に参照として使用します。

Eコマース/小売: 99.9-99.95%. ピーク(ブラックフライデー、クリスマス)の間のダウンタイムの毎分は、失われた収益で数千を意味することができます。
ヘルスケア/HIPAA: 99.99% 忍耐強いシステムのためのかより高い。規制圧力および忍耐強い安全ドライブ厳密な条件。
銀行/フィンテック: 99.99-99.999%. 支払い処理とコアバンキングは、多くの場合、5つのninesを必要とします。取引システムは非常に利用可能である必要があります。
SaaS/B2B: 99.9% 共通のベースラインです。企業のお客様は、多くの場合99.95を交渉します% または 99.99% プレミアムサポート
内部IT / devツール: 99% ステージング、CI/CD、内部ダッシュボードの不足顧客向けシステムよりもビジネスへの影響が低い。

オペレーション

モニタリングとSLAのコンプライアンス

SLAのコンプライアンスを追跡するには、一貫性のある測定と明確な定義が必要です。以下の慣行は、紛争を回避し、正確な報告をサポートするのに役立ちます。

ベストプラクティス:

複数の地理的ポイントからの稼働時間監視(単一の場所から偽陽性がない場合)
SLAの定義(例1分チェック)に一致する一貫性のあるポーリング間隔
可用性計算のための開始/終了タイムスタンプで正確なインシデントロギング
定期メンテナンスの除外; 監視がメンテナンスウィンドウを尊重することを確認してください
トランスペアレントレポート:ステータスページと月間可用性レポート

マルチレギュレーションまたはマルチサービスSLA: 複数のコンポーネント(API、データベース、CDN)に依存している場合、それぞれ99.9%, 結合された可用性はより低いです。例: API 99.9% × DB 99.9の% ≈ 99.8% エンドツーエンド。冗長性の設計と不良の混入を避けるため。

SLAを入力してください