SLA/OLA與提供商

1）術語和界限

SLI是可測量的指示器（可用性，p99潛伏性，成功處理的webhook，RPO/RTO）。
SLO是每個測量窗口（例如99。9%/30天）。
SLA是具有法律約束力的文件（SLO+程序+報銷）。
OLA是執行SLA的內部目標和流程。
UC（Underpinning Contract）是與第三方（通道，數據中心，CDN等）的「基板」。

邊界：明確將提供商的責任範圍（雲/WAF/CDN/支付網關/KYC提供商）與您的區域（代碼、config、客戶端設置）分開。

2）臨界矩陣和模型選擇

SLA的深度，檢查範圍以及OLA/UC要求取決於矩陣。

3）度量指標和測量窗口

可用性（Availability）-服務根據公差執行請求的時間比例。
潛在性：關鍵操作的p95/p99；「緩慢的成功」被考慮在內。
數據可靠性：RPO（最大允許數據丟失）和RTO（恢復時間）。
帶寬/限制：保證配額（RPS/MBps）。
集成質量：交付的Webhook ≤ X Min的比例，2xx響應，重復和重復數據消除的比例。
測量窗口：每月/滾動30天,有限制的例外（計劃工作）。

• `Availability_ext = 1 − (Downtime_confirmed_outages / Total_minutes_in_window)`
• 其中outage是通過外部監控確認的不可用狀態，而不僅僅是提供商的狀態頁面。

4） SLA內容（分區模板）

1.主題和區域（服務，區域，API版本）。
2.定義（SLI/SLO，「事件」，「計劃工作」，「不可抗力」）。
3.按請求類別和區域劃分的服務目標（SLO）。
4.監測和證據基礎：傳感器的方式和頻率。
5.事件和升級：渠道，響應/更新時間，角色。
6.退款：貸款/罰款/獎金，門檻，公式。
7.安全和隱私：DPA，加密，日誌，違規通知。
8.服務更改：清除，註釋窗口，兼容性。
9.連續性和DR：RPO/RTO，恢復測試。
10.審計和合規性：審計權，報告，認證權。
11.出口計劃：數據導出、時間表、格式、遷移幫助。
12.法律規定：管轄權，不可抗力，保密，有效期。

5）措辭示例（片段）

5.1可用性和測量

"提供商提供99。每個日歷月可用95％。可用性由客戶從≥3地區的外部合成監視以≤1分鐘間隔進行測量。≥2地區的記錄不可用性同時被視為SEV2級事件，並計入Downtime"

5.2關鍵API的潛在性

"P99回復時間"POST/payments/authorize "≤ 95%的月份450毫秒。對於超過閾值的查詢，將提供一份報告，其中包含原因分析"

5.3事件和升級

"S1： ack ≤ 15分鐘，每≤ 30分鐘，目標恢復≤ 2小時；S2：ack ≤ 30分鐘，後期≤ 60分鐘；S3：下個工作日。頻道：電話24 × 7，聊天橋，電子郵件"

5.4退款（貸款）

If Availability_ext <99. 95% → credit 10% monthly fee
< 99. 9% → 25%
< 99. 5% → 50%

貸款不排除對重大過失的其他賠償方式。

5.5 Deprekate和兼容性

"對於中斷互操作性的更改,至少有180天的通知。並行支持vN和vN+1至少90天"

5.6退出（退出）

"在終止後30天內，提供商免費提供Parquet/JSON+電路格式的完整數據導出；額外的遷移服務-按票價X。副本的銷毀由該法案確認"

6）OLA： 外部SLA的內部支撐

• 目標：p99 gateway ≤ 200 ms，error rate ≤ 0。3%，DR：RPO 0，RTO 30分鐘。
• 責任：SRE-ON-CALL，24 × 7；一般的dashbords和alertes。
• 過程：發行版中的混沌笑聲，PR上的胡椒笑聲，著色啟發式。
• Gate：SLO/xaoc測試失敗時的沈降單元；強制更新運行手冊。

7）監測和證據

合成：外部樣本（HTTP/TCP），用戶路徑，「成功緩慢」。
RUM：用於確認影響的真實用戶監控。
相關：標記「provider」，「region」，「api_method」，「incident_id」。
工件：屏幕截圖/腳本/標誌，KPI導出，升級時間表。

rego package policy. sla deny["Release blocked: provider SLO risk"] {
input. release. affects_providers[_] == p input. slo. forecast[p].breach == true
}

8）事件和互動

1.SEV分類，打開戰爭室，指定IC。

2.通過「熱線」通知提供商,傳遞人工制品。

3.解決模式/幻燈片（stale，shading，rate-cap）。

4.協作時間線，恢復。

5.Postmortham+Actions：更新限值、密鑰、備用路由。

6.SLA貸款啟動，計費固定。

9）安全和DPA

DPA/隱私：控制器/處理器角色，數據類別，合法性數據庫，處理時間/目標，子處理器及其SLA。
加密：TLS1。2+, PFS;靜止數據，密鑰管理（KMS/HSM），輪換。
審計：訪問記錄，違規通知≤ 72小時，Pentest應要求報告。
本地化：存儲區域，禁止未經同意的出口。

10）供應鏈和兼容性

SBOM/漏洞： CVSS閾值策略和修復時間（批評≤ 7天,高≤ 14）。
API兼容性：合同測試，「沙盒」和穩定的偽造。
提供商更改：早期發行說明、預覽/beta窗口、向後兼容性。

11）多用戶和騙子

Active/Active：更復雜、更昂貴,但可用性更高（考慮一致性）。
Active/Passive：寒冷/溫暖的儲備,定期DR培訓。
抽象/適配器：單一合同，健康/價值/碳因子路由（如果相關）。
許可/商業條件：可移植性，數據輸出限制，egress成本。

12）出口計劃和定期排練

數據/圖形目錄和卷。
SDK/API可移植性腳本（最小值為第二源）。
幹輸出測試：導入/導入，恢復，不變量檢查。
發布後保留/刪除的法律期限。

13）合同測試和配對

API樣本：正面/負面，限制，錯誤和撤消。
事件交付/webhook：簽名/時間/去世/重播。
Perf基線：p99，帶寬；提供商發行說明的倒退測試。
跨區域：一個地區的退化不應在全球範圍內破壞SLO。

14）反模式

SLA「在狀態頁面上」，沒有外部測量。
所有區域/末端都有相同的目標。
缺乏審核權和詳細事件日誌。
沒有OLA/UC →內部沒有人履行外部義務。
不確定的退出計劃→供應商的人質。
「僅信用罰款」無權在系統性違規中終止。
Deprekate沒有過渡窗口。

15）建築師支票清單

1.SLI/SLO為關鍵流和地區定義?

2.選擇了外部監控方法和證據基礎?

3.SLA是否規定了事件、升級、計劃工作窗口和例外限制？
4.是否有信用額度/罰款和N違規終止權？

5.DPA/安全： 加密、日誌、通知、子處理器、本地化?

6.管道中的合同測試和沙箱?

7.內部OLA/UC是否執行外部SLO？
8.DR：RPO/RTO聲稱正在進行培訓，有報告嗎？
9.出口計劃：出口格式、時間表、幹出口做法？
10.CI/CD中的網關是否會阻止發布，從而增加違反SLA的風險？

16）迷你示例（草圖）

16.1提供商風險的「deplo-gate」政策

yaml gate: provider-slo-risk checks:
- name: forecasted-slo-breach input: slo_forecast/providers. json deny_if: any(.providers[].breach == true)
action_on_deny: "block-release"

16.2導出「事件證據」

bash curl -s https://probe. example. com/export? from=2025-10-01&to=2025-10-31 \
jq '.      {region, endpoint, status, latency_ms, trace_id, ts}' > evidence. jsonl

16.3合約webhook測試（偽代碼）

python evt = sign(make_event(id=uuid4(), ts=now()))
res = post(provider_url, evt)
assert res. status in (200, 202)
assert replay(provider_url, evt). status = = 200 # idempotency

結論

SLA/OLA不僅是「法律論文」，而且是風險和質量管理的體系結構機制。正確的指標和窗口、外部監控、清晰的事件和報銷程序、內部OLA/UC、管道網關、多供應商和真正的出口計劃將依賴提供商轉變為您平臺的可控制、可衡量和經濟可預測的部分。