High Availability и SLA

1）術語與業務關系

SLI（服務級別指標）是可測量的服務指標（請參閱2xx/3xx ≤ T ms成功查詢的百分比）。
SLO（服務級別目標）是SLI的目標值（例如。"99。95%的請求≤ 300毫秒）。
SLA（服務級別協議）-對客戶的合同義務（違規時的罰款/貸款）。
HA（高可用性）是允許執行SLO/SLA的體系結構和操作措施。

原理：SLA依賴於SLO，SLO依賴於觀察到的SLI。你不能在SLA中承諾不衡量什麼。

2）「九」和無障礙數學

期內可用性=「時間_工作/一般_時間」。地標（年份）：

可用性	馬克斯。簡單/年份
99.0%	≈ 3天15時
99.5%	≈ 1天20小時
99.9%	≈ 8小時45米
99.95%	≈ 4小時23米
99.99%	≈ 52米34秒
99.999%	≈ 5分15分c

無障礙的構成

串行鏈（「紅色路徑依賴性」）：'A_total=Π A_i'（每個組件都會減少總和）。
平行資產節點：「A_total=1 − Π（1 − A_i）」（儲備金增加總額）。

3）究竟要測量什麼（正確的SLI）

用戶視圖：成功完成關鍵操作（登錄、存款、支票）及其潛在性p99。
一小時走廊：按滑動窗口（5/30/60分鐘）和區域匯總。
例外：SLO中考慮了「計劃窗口」，SLA中僅考慮了合同中規定的窗口。

SLI類型：

可用性：成功答復率≤ T。
質量：p95/p99 latency。
組成：「成功存款的比例≤ 5 c。」

4）錯誤預算和燃燒速度

Error Budget = `1 − SLO`.對於99。95%的月度窗口為0。05%的錯誤/停機。
Burn-rate：預算支出的速度（例如4 ×意味著你在6小時內吃了白天的限制）。
政策：快速燃燒-停止發布，專註於穩定，功能凍結。

5） HA體系結構： 從節點到區域

5.1個節點/服務

N+1：至少一個冗余副本（Dployment ≥ 2, PDB, anti-affinity）。
資源隔離：CPU/RAM/IO限制，優先級（PriorityClass）。
Graceful shutdown/Drain：在重新啟動時沒有查詢懸崖。

5.2個區域/區域

Multi-AZ：不同區域的復制副本,跨區域平衡,獨立電源/網絡。
多區域：資產資產（更難：數據/一致性）或資產資產（更簡單：高於RPO）。
數據：現金/訂單的CP（法定人數/RAFT），緩存/店面的EC/AP。

5.3網絡層和外圍

L7-LB с health-checks, retry/timeout/circuit-breaking.

GSLB/DNS/Anycast用於全球流量，TTL短。
到外部PSP/提供商的 Egress控制和容錯通道。

6）降解而不是掉落

Feature kill-switch（幻燈片標誌）：關閉非關鍵,保留「紅色路徑」。
切換到簡化路徑：同步→ asinchron/隊列,「被接受處理」。
利率限制/配額：限制流量比奪走所有人更好。
Stale模式：在原點不可用時提供緩存/靜態數據。

7）依存關系管理

依存映射（服務地圖）：直接/傳遞,臨界,每個SLO。
弱勢環節：沒有SLA的外部提供商-包裹緩存/隊列/復制。
Bulkhead隔離：慢路的不同連接/配額池。
Timeouts> Retries：短時間,最多1個靜止操作的靜止。

8）操作和更改

更改管理：通過金絲雀/藍綠色、SLO門、自動回滾發布。
計劃窗口：標準化-長度、周期性、通信。
事件：角色（IC/Comms/Tech/DB），runbook'和，具有糾正行動的驗屍。
證券活動：在損害時-「恐慌模式」（只閱讀/代幣/輪換/鎖定）。

9）可觀察性和異位

每個路由的RED模型（Rate，Errors，Duration）。
SLI-dashbords：區域和客戶細分市場的可用性/潛在性。
燃燒率差：快速（1h, 14.4 ×），緩慢（6h，2 ×）-SLO崩潰前的信號。
實例（Exemplars）-通過trace_id從度量轉換為軌跡。
合成：來自外部點（周邊，支付流）的樣品。

10）容錯測試

遊戲日：AZ/區域斷開連接、 DB/緩存降級、外部提供商故障的場景。
Chaos工具：網絡資料庫（latency/loss）, kill-pods, CPU/IO過熱。
DR-drills：為Tier-0系統運行RTO/RPO（請參閱「Backaps and DR」）。

11） SLA設計

「可用性」定義：什麼被認為是事件（5xx, time,> T,域錯誤）。
結算窗口：月/季度；包括或排除計劃工作。
學分/罰款：比率（見99。9–99.99%為X%,低於Y%）。

客戶責任： 集成,在合理範圍內轉發,限制.

符號化和點擊過程：時機，格式，證據基礎（邏輯/度量）。
不可抗力：法律措辭和界限。

示例（草圖）：

「SLI API的可用性」成功≤ 500毫秒不超過99。95%的日歷月。計劃窗口（在48小時內宣布最多60分鐘/月）不包括在內。99歲。90–99.95%的貸款為5%；99.80–99.90% — 10%;<99.80% — 25%.»

12）九經濟學

每個額外的「九」都不會線性增長成本（雙重區域，法定人數，提供商配對，24 × 7）。應用SLO tiering：

Tier-0（金錢/訂單）：99。95–99.99％，多個AZ，DR準備就緒。
Tier-1（主要fichi）：99。9–99.95％，多個AZ。
Tier-2（非關鍵）：99。5–99.9%，事件允許退化/停止。

13）按層分列的HA模式

外圍：CDN/edge，multi-CDN或GSLB，WAF，限位。

平衡： L7與outlier ejection, taymouts/retrai, sticky/consistent-hash.

應用： 水平滑板,準備/生活,PDB, topology spread.

數據：leader+replicas, quorum for CP, L2緩存,idempotency, PITR。
隊列：鏡像/multiclaster、dedup、DLQ。
秘密/騙局：GitOps，核彈頭，滾動。

14）反模式

SLA沒有測量工具和外部合成材料。
單個區域/群集為SPOF。
失控的後退→ 「sami-DDoS」。
熱路上的長交易/突變體。
「繁重」的遷移/發行沒有金絲雀和回滾計劃。
事件中缺乏跑步簿和與牛排者的交流。

15）實施清單（0-60天）

0-15天

定義關鍵的自定義SLI,按Tier-0/1/2級別設置SLO。
包括burn-rate alerta、SLO-dashbords、合成周長檢查。
刪除SPOF：復制副本≥2，PDB，用於前端和關鍵DB的multi-AZ。

16-40天

引入帶有SLO門和自動回滾的金絲雀版本。
每個「紅色路徑」的依賴圖+配額/池/taymout/SV。
計劃窗口和通信法規，事件消息模板。

41-60天

遊戲日：AZ關閉，外部提供商失敗，「burst」流量。
重新計算SLA和信用,向客戶發布報告。
修訂「九↔成本」和橫桿。

16）成熟度量

≥ 95％的關鍵路線具有SLI/SLO和burn-rate alerta。
SLO錯誤伴隨著自動凍結發布（策略）。
Multi-AZ覆蓋Tier-0=100％，成功的DR-drills ≥ 1/季度。
「檢測→多聯」時間p50 <5分鐘，p95 <15分鐘。
「發布↔事件」相關性-保持和縮寫（rollback rate↓）。
公共事件/貸款報告-在N工作日內。

17）示例和嗅覺

Burn-rate alerta（規則的想法）：

快速："SLO 99.95%，窗口1小時，burn ≥ 14。4× → page on-call».
緩慢：「窗口6小時，燒傷≥ 2 × →門票和監控。」

Envoy — circuit breaking/outlier:

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）結論

高可用性不僅是集群和復制品，而且是一套連貫的體系結構，流程和指標：明確的SLI/SLO，現實的SLA，具有經濟性的「九個」，降級而不是下降，計時/配額紀律，金絲雀發布，定期演習和透明溝通。使可用性可測量和可管理-它將成為競爭優勢而不是彩票。

High Availability и SLA