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、管道网关、多供应商和真正的出口计划将依赖提供商转变为您平台的可控制、可衡量和经济可预测的部分。