高可用性（SLA）

1）利用規約とビジネスとの関係

SLI （Service Level Indicator）-測定されたサービスインジケータ（たとえば、成功したリクエストの割合2xx/3xx ≤ T ms）。
SLO （Service Level Objective）-ターゲットSLI値（例："99.要求の95％ ≤ 300ms"）。
SLA（サービスレベル契約）-クライアントへの契約上の義務（違反の場合の罰金/クレジット）。
HA（高可用性）-SLO/SLAを実行できるアーキテクチャおよび運用対策。

原則：SLAはSLOに依存し、SLOは観測されたSLIに依存します。測定しないものをSLAで約束することはできません。

2）「ナイン」とアクセシビリティ数学

期間ごとの可用性='work_time/total_time'。ベンチマーク（年間）：

可用性について	マックス・マックス。ダウンタイム/年
99.0%	≈ 3日15時間
99.5%	≈ 1日20時間
99.9%	≈ 8時間45メートル
99.95%	≈ 4時間23メートル
99.99%	≈ 52 m 34 s
99.999%	≈ 5 m 15 s

可用性の構成

シーケンシャルチェーン（赤いパス依存関係）：'A_total=Π A_i'（各コンポーネントは合計を減らします）。
並列アセットノード：'A_total=1 − Π （1 − A_i）'（予備は合計を増加する）。

3）正確に測定するもの（正しいSLI）

ユーザービュー：キー操作（ログイン、デポジット、チェックアウト）とレイテンシp99の完了に成功しました。
時間回廊：スライドウィンドウ（5/30/60分）と地域別に集計します。
例外：「スケジュールされたウィンドウ」はSLOでカウントされ、SLAでは契約がそう言っている場合のみカウントされます。

SLIタイプ：

可用性：成功率≤ T。
品質：p95/p99レイテンシ。
コンポジット：「5秒≤成功した預金のシェア」。

4）エラー予算と燃焼率

エラーBudget='1 − SLO'。99のために。95％毎月のウィンドウは0を与えます。05％エラー/ダウンタイム。
燃焼率：予算消費の速度（例えば。4 ×は、6時間で毎日の制限を食べることを意味します）。
方針：急速な燃焼-停止リリース、安定化、機能凍結に焦点を当てます。

5） HAアーキテクチャ： リージョンへのノード

5.1ノード/サービス

N+1：少なくとも1つの冗長レプリカ（展開≥ 2、 PDB、アンチアフィニティ）。
リソース分離：CPU/RAM/IO制限、優先度（PriorityClass）。
Graceful shutdown/drain：再起動時にリクエストが切れることはありません。

5.2ゾーン/地域

マルチAZ：異なるゾーンのレプリカ、クロスゾーンバランシング、独立した電源/ネットワーク。
マルチリージョン：資産資産（ハード：データ/コンシステンシー）または資産責任（シンプル：RPOの上）。
データ：CP for money/orders （quorum/RAFT）、 EC/AP for caches/storefronts。

5.3ネットワーク層および周囲

L7-LB-健康チェック、再試行/タイムアウト/回路破壊。
グローバルトラフィックのためのGSLB/DNS/Anycast、短いTTL。
外部PSP/プロバイダへの出力制御およびフォールトトレラントチャネル。

6）落下の代りの低下

フィーチャーキルスイッチ（フィーチャーフラグ）：非クリティカルをオフにし「、赤いパス」を保存します。
簡略パスへの切り替え：synchronous→asynchronous/queue、「accepted for processing」。
Rate-limit/quotas：すべての人をドロップするよりもトラフィックを制限する方が良いです。
古いモード：オリジンが利用できない場合にキャッシュ/静的データを与えます。

7）制約管理

サービスマップ：direct/transitive、 criticality、各SLO。
脆弱なリンク：SLAなしの外部プロバイダ-キャッシュ/キュー/重複に変わります。
隔壁の分離：遅いルートのための別の接続プール/クォータ。
タイムアウト>リトリー：短いタイムアウト、idempotent操作の最大1リトレイ。

8）運営・変更

変更管理：カナリア/ブルーグリーン、SLOゲート、自動ロールバックによるリリース。
スケジュールされたウィンドウ：標準化-長さ、周波数、通信。
インシデント：ロール（IC/Comms/Tech/DB）、 runbook"および、是正措置を伴う死後。
セキュリティイベント：侵害された場合「、パニックモード」（読み取り専用/トークン/回転/ブロック）。

9）観察可能性および警報

各ルートのREDモデル（Rate、 Errors、 Duration）。
SLIダッシュボード：地域別および顧客セグメント別の可用性/遅延。
燃焼率アラート：高速（1h、 14。4 ×）、遅い（6h、 2 ×）-SLOの失敗の前の信号。
Exemplars-Switches from metrics to trace_id alignment。
合成：外部ポイントからのサンプル（境界、支払いフロー）。

10）フォールトトレランス試験

ゲーム日：AZ/リージョンを無効にするシナリオ、データベース/キャッシュの劣化、外部プロバイダの障害。
カオスツール：ネットワークフォルト（レイテンシ/ロス）、キルポッド、CPU/IOオーバーロード。
DR-drills： Tier-0システム用のRTO/RPOの開発（「バックアップとDR」を参照）。

11） SLAの設計

「可用性」の定義：インシデントとしてカウントするもの（5xx、時間>T、ドメインエラー）。
計算ウィンドウ：月/四半期；計画された活動の包含/除外。
クレジット/ペナルティ：スケール（例：99.9–99.99％-X％、 lower-Y％）。
クライアントの責任：統合、合理的な制限内での再試行、制限。
通知とクライムの手順：用語、フォーマット、証拠ベース（ログ/メトリック）。
不可抗力：法的文言と境界。

例（スケッチ）：

"SLIによるAPIの可用性"成功≤ 500ミリ秒"は少なくとも99です。カレンダーの月に95％。スケジュールされたウィンドウ（48時間以内に発表された60分/月まで）は除外されます。99歳。90–99.95％-ローン5％；99.80–99.90% — 10%;<99.80% — 25%.»

12）ナインズ経済

追加の各「9」は、直線的ではないコストを増加させます（二重領域、クォーラム、プロバイダの重複、24 × 7）。階層化SLOを使用する：

Tier-0（お金/注文）：99。95–99.99％、マルチAZ、 DR対応。
Tier-1（基本機能）：99。9–99.95％、マルチAZ。
Tier-2（非クリティカル）：99。5–99.9％、インシデントは劣化/停止が許可されています。

13）層によるHAパターン

周囲：CDN/エッジ、マルチCDNまたはGSLB、 WAF、レート制限。
バランスをとること：outlier-ejection、 timeouts/retraysの粘着性がある/一貫したハッシュのL7。
適用：横のスケール、準備/liveness、 PDBのトポロジーの広がり。
データ：リーダー+レプリカ、CP用クォーラム、L2キャッシュ、idempotency、 PITR。
キュー：ミラーリング/マルチクラスタ、dedup、 DLQ。
Secrets/configs： GitOps、 atomicスナップショット、ロールバック。

14）アンチパターン

SLAは測定器および外的な合成物なしで。
SPOFとしてシングルゾーン/クラスタ。
制御されていないリトレイ→「self-DDoS」。
ホットトラック上の長いトランザクション/ミューテックス。
「重い」移行/カナリアとロールバック計画のないリリース。
インシデントでのランブックの欠如と利害関係者とのコミュニケーション。

15）実装チェックリスト（0-60日）

0-15日

重要なユーザーSLIを定義し、Tier-0/1/2レベルでSLOを設定します。
バーンレートアラート、SLOダッシュボード、合成周囲チェックが含まれます。
SPOF： ≥ 2レプリカ、PDB、フロントおよびクリティカルデータベース用マルチAZを削除します。

16-40日

SLOゲートと自動ロールバックでカナリアリリースを紹介します。
各「赤いパス」の依存関係マップ+クォータ/プール/タイムアウト/PB。
計画されたウィンドウと通信、インシデントメッセージテンプレートの規制。

41-60日

ゲームデイ：AZの切断、外部プロバイダの障害、トラフィックの「バースト」。
SLAと実際のクレジットの再計算、顧客へのレポートの公開。
「9 ↔のコスト」の改訂と撮影ギャラリーに再設置。

16）成熟度の指標

重要なルートの95％に≥、 SLI/SLOとバーンレートのアラートがあります。
SLOエラーには、リリースの自動フリーズ（ポリシー）が伴います。
マルチAZカバレッジTier-0=100％、成功したDRドリル≥ 1/四半期。
「検出→緩和」時間p50 <5分、p95 <15分。
「Release ↔ incidents」の相関関係-維持・縮小（ロールバック率→）。
パブリックインシデント/クレジットレポート-N営業日以内。

17）例とスニペット

バーンレートアラート（ルールアイデア）：

高速："SLO 99。95％、窓1時間、燃焼≥ 14。4 ×→ページオンコール"
遅い：「ウィンドウ6時間、燃焼≥ 2 ×→チケット&モニタリング。」

Envoy-回路の破断/外側：

yaml circuit_breakers:
thresholds:
- max_connections: 200 max_pending_requests: 100 max_requests: 1000 max_retries: 1 outlier_detection:
consecutive_5xx: 5 interval: 5s base_ejection_time: 30s max_ejection_percent: 50

SLO解析を使用したカナリア（Argo Rollouts、アイデア）：

yaml analysis:
templates:
- name: slo-burn metrics:
- name: error-rate successCondition: result < 0. 005 provider: prometheus

SLI処方例：


SLI: fraction_of_good_requests = good(HTTP 2xx/3xx ≤ 500ms) / all(requests)
SLO: ≥ 99. 95% per calendar month, per region

18）結論

High Availabilityはクラスタやレプリカだけでなく、アーキテクチャ、プロセス、メトリクスの一貫したセットです。明確なSLI/SLO、現実的なSLA、経済学、劣化の代わりに、タイムアウト/クォータ規律、カナリアリリース、定期的な演習、透明なコミュニケーションです。手頃な価格の測定と管理が可能に-それは宝くじではなく、競争上の優位性になります。

高可用性（SLA）