SLA和SLO监视

1）术语和角色

SLA（服务级别协议）是对客户的外部合同义务（罚款条款，贷款）。
SLO（服务级别目标）是支持SLA执行的目标内部服务级别。
SLI（服务级别指标）是评估SLO/SLA的可测量指标。
错误预算是以下时期内"不可用/错误"的有效份额："预算=1 − SLO"。
Scope：通过用户的眼睛（端到端）进行测量。在微服务中-在组件和端到端路径级别。

2）SLI选择： 确切测量什么

标准是与用户体验和业务价值的相关性。

• 可用性：成功查询的比例。"SLI=成功/全部"。
• 潜伏期：查询比例比T. "SLI=P（潜伏期≤ T）"阈值快。
• 质量：正确答复的比例（无5 x/func）。错误）。
• 数据相关性：复制延迟/ETL ≤ X分钟。
• 业务流程绩效：成功付款/注册的比例。

反模式：只将200 ki视为"成功"，而忽略了业务错误；在测试网络而不是用户网络中进行测量。

3）公式和观察窗口

• `Availability = (OK_requests / All_requests) × 100%`.

• "P95 ≤ T" →更好地表述为份额：'SLI=T ≤查询的百分比。
• 示例："99％的搜索请求在28天内≤ 300毫秒。"
• 滑动窗口：28天或30天（灵敏度和稳定性平衡）。对于事件-添加剂窗口：1小时,6小时,24小时。

4）错误预算和更改率控制

计算：以'SLO=99。9%'预算='0。在此期间有1％的错误/无法访问。

• 预算>50%：发布和计划实验。
• 预算10-50%：只有低风险发行，加那利群岛收紧。
• 预算<10%：发行冻结、根源原因、可靠性提高。
• 与渐进发行版的联系：金丝雀/feature-flags"吃"预算剂量，降解时自动回滚。

5）警报政治： 从急流到燃烧率

为何不是"daupal SLO-alert子"：为时已晚。需要积极主动。

• "BR=（观察到的短窗口错误/该窗口的有效错误）"。
• 如果"BR> 1"-预算支出比正常水平快。

• 快速警报（噪音敏感，捕捉灾难）：窗口5-10分钟，BR阈值14-20 ×。
• 慢速警报（捕捉爬行降解）：窗口1-6小时，BR阈值2-4 ×。
• 条件组合：快速或缓慢工作-呼叫分页。
• 级别：用于定制SLO的寻呼机，用于灰色内部降解SLI的滴答声/通知。

6）可观察性和真相来源

Logi-原因诊断。
度量是数字SLI（成功/错误，潜伏期，分数，计数）。
Traces-直通路径，将"热"段本地化。
合成剂是来自外围的活性样品（区域-aware）。
实际事件-客户的RUM/遥测，业务指标（转换，成功支付）。

要求：发布和事件的行车记录簿中的单个图片，"版本/金丝雀/标志"注释。

7） SLO设计： 分步模板

1.描述关键路径（例如,"存款卡"）。
2.定义SLI：成功/错误、潜伏阈值、完整性。
3.商定SLO： 28天目标+例外（计划窗口）。
4.与SLA联系：法律义务≦实际的SLO。
5.指定所有者（服务所有者）、RACI和Alert通道。
6.定义警报策略（双窗口BR和自动回滚）。
7.实施报告：每周预算审查，事后评论。
8.每季度修订SLO（负载/体系结构变更）。

8） SLO示例（模板）

• 可用性：'≥ 99。95％'（28 d，不包括宣布的窗口≤ 30分钟/月）。
• 潜伏期："≥ 99%"答桉"≤ 400毫秒。
• 业务运营成功：'≥ 98.5％的成功授权（考虑了fraud过滤器）。

• 潜伏期："≥ 99%"查询"≤ 300毫秒。
• 缓存相关性：99%的"≤ 5分钟"积压。

• 交付：'≥ 99.9%在"≤ 60秒内"（端到端,带回程）。
• 损失：'≤ 0。01％的消息（启用了平均电平/重复数据消除）。

9）多区域和多特南特

SLO"按队列"：国家，支付提供商，VIP部门，设备。
边缘的本地SLO：来自最接近用户的点（edge/PoP）的度量。
聚合：通用SLO不应隐藏重要队列的失败。
切换提供商：在SLO门级别自动返回路由。

10）Dashbords和报告

发布的行车记录板：版本，金丝雀（流量百分比），SLI（成功/潜在），BR，标志注释。
操作减速板：每天的燃烧预算，顶级事件，MTTR，有问题的队列。
每周报告：预算余额，BR趋势，技术债务（瓶颈），改进计划。

11）过程： 事件，RCA和改进

事件管理：警报→ BR评估→加那利群岛/旗帜的规模→回滚/假冒。
RCA（根原因）：事实/时间线/假设/修复/SLI效果检查。
汲取的经验教训：非勤奋的后面面具，强制性的行动项目，包括所有者和时间表。
循环闭合：测试、幻灯片标志、限制、缓存、撤退、配额的变化。

12）合规与审计

SLO/SLI作为控制工件（策略即代码，不可更改的逻辑）。
绑定到要求（例如支付交易的可用性）。
证据：警报协议，预算报告，发行日志/回扣。

13）频繁的错误以及如何避免错误

“99.99％或死亡"：无法实现的目标→持续的警报噪音。选择现实的SLO。
全局平均值掩盖了局部失误→引入队列。
度量标准不是e2e：客户端实际降解时的高SLO →添加RUM/合成。
Alerta →通过一个阈值切换到双窗口燃烧率。
与更改无关→版本没有注释，没有自动回滚。

14）实施迷你支票清单

• 描述了关键路径及其SLI/SLO。
• 设置监视和排除窗口。
• 配置了双窗口BR-Alerta（快速和缓慢）。
• 发行版本和带有版本/标记注释的操作的行列。
• 错误预算策略会影响发行版。
• 定期预算审查和事后RCA。
• 文件和指标所有者。

15）计算示例（细节）

API可用性SLO： 99。9％在28天内→预算=0。1%.

7天内累积了0。06％的错误→花费了每周预算的60％。

在15分钟的短窗口中观察到2％的错误。此窗口允许： '0。1%的×（15分钟/40320分钟）≈ 0。000037%`.

Burn Rate ≫ 1（数十×）→触发快速寻呼机，金丝雀回滚高达1％，启用"degrade-payments-UX"字形标志，RCA触发。

16）结果

SLA/SLO监控不仅是报告中的数字，而且是管理变更风险和服务质量的机制。正确的SLI、逼真的SLO、错误预算管理、双窗口燃烧率和e2e可观察性将指标转化为工作解决方桉：更快地释放价值并保持用户体验的可预测性。