凌晨 3 点,你的手机响了。又是一个 CPU 使用率 > 80% 的告警——但系统运行正常,用户没有受到影响。你翻了个身继续睡。第二天早上,你发现昨晚有 30 条告警,你忽略了 28 条——其中 2 条是真正重要的。
这就是阈值告警的困境:告警太多,真正重要的被淹没。
SLO(Service Level Objective)驱动的告警从根本上改变了这个问题——告警不再基于”某个指标超过阈值”,而是基于”错误预算的消耗速度”。如果错误预算在快速燃烧,说明用户体验正在恶化,需要立即处理;如果错误预算消耗缓慢,说明系统在可接受范围内运行,不需要告警。
一、SLO 基础
1.1 SLI → SLO → SLA
| 概念 | 说明 | 示例 |
|---|---|---|
| SLI | 可度量的服务质量指标 | 成功率 = 99.95%、P99 延迟 = 200ms |
| SLO | SLI 的目标值 | 成功率 ≥ 99.9%、P99 ≤ 500ms |
| SLA | 未达 SLO 的商业后果 | 可用性 < 99.9% → 赔付 10% 费用 |
1.2 SLI 设计
好的 SLI 应该从用户视角度量服务质量:
| 类型 | SLI | 计算方式 | 说明 |
|---|---|---|---|
| 可用性 | 请求成功率 | 成功请求数 / 总请求数 | 用户能否成功使用服务? |
| 延迟 | 请求延迟 | P99 ≤ 500ms 的请求比例 | 用户体验是否流畅? |
| 正确性 | 数据一致性 | 一致性检查通过率 | 数据是否正确? |
| 吞吐量 | 处理能力 | 每秒处理请求数 | 系统容量是否足够? |
1.3 SLI 定义方法论
定义 SLI 不是拍脑袋的事。一个好的 SLI 需要满足以下条件:
原则 1:从用户行为出发
不要从系统指标出发定义 SLI,而要从用户行为出发:
| 错误的 SLI | 正确的 SLI | 原因 |
|---|---|---|
| CPU 使用率 < 80% | 请求成功率 ≥ 99.9% | 用户不关心 CPU,关心请求是否成功 |
| 内存使用率 < 70% | P99 延迟 ≤ 500ms | 用户不关心内存,关心响应是否够快 |
| 磁盘 I/O 延迟 < 10ms | 数据写入成功率 ≥ 99.95% | 用户不关心 I/O,关心数据是否写入成功 |
原则 2:SLI 必须可度量且可计算
SLI 应该可以用 PromQL 直接计算:
# 可用性 SLI:成功请求比例sum(rate(http_requests_total{status!~"5.."}[5m]))/sum(rate(http_requests_total[5m]))
# 延迟 SLI:P99 延迟histogram_quantile(0.99, sum(rate(http_request_duration_bucket[5m])) by (le, service))
# 正确性 SLI:数据一致性检查通过率sum(rate(consistency_check_total{result="pass"}[5m]))/sum(rate(consistency_check_total[5m]))原则 3:区分”好事件”和”坏事件”
大多数 SLI 可以用”好事件 / 总事件”来计算:
| SLI 类型 | 好事件 | 坏事件 | 总事件 |
|---|---|---|---|
| 可用性 | HTTP 2xx/3xx/4xx 响应 | HTTP 5xx 响应 | 所有 HTTP 响应 |
| 延迟 | 耗时 ≤ 500ms 的请求 | 耗时 > 500ms 的请求 | 所有请求 |
| 正确性 | 一致性检查通过 | 一致性检查失败 | 所有检查 |
注意:HTTP 4xx 是客户端错误,不应该算作服务端的”坏事件”。只有 5xx 才是服务端的问题。如果你的可用性 SLI 把 4xx 也算作坏事件,那么客户端的一个 bug 就会烧光你的错误预算。
1.4 SLO 定义模板
# SLO 定义apiVersion: sloth.slok.dev/v1kind: PrometheusSLOspec: service: order-service slo: - name: "availability" objective: 99.9 description: "99.9% 的请求成功返回" sli: events: error_query: sum(rate(http_requests_total{service="order-service",status=~"5.."}[{{.window}}])) total_query: sum(rate(http_requests_total{service="order-service"}[{{.window}}])) alerting: name: OrderServiceAvailabilitySLO labels: team: order-team page_alert: labels: severity: page ticket_alert: labels: severity: ticket
- name: "latency" objective: 99.0 description: "99% 的请求在 500ms 内完成" sli: events: error_query: | sum(rate(http_request_duration_seconds_bucket{service="order-service",le="0.5"}[{{.window}}])) / sum(rate(http_request_duration_seconds_count{service="order-service"}[{{.window}}])) total_query: "1"二、错误预算
2.1 什么是错误预算?
错误预算(Error Budget)是 SLO 的”反面”——如果 SLO 是 99.9%,那么错误预算就是 0.1%:
错误预算 = 1 - SLO30 天错误预算 = 30 × 24 × 60 × 60 × 0.1% = 2592 秒 ≈ 43.2 分钟| SLO | 错误预算 | 30 天允许停机 | 1 年允许停机 |
|---|---|---|---|
| 99.9% | 0.1% | 43.2 分钟 | 8 小时 45 分钟 |
| 99.95% | 0.05% | 21.6 分钟 | 4 小时 22 分钟 |
| 99.99% | 0.01% | 4.3 分钟 | 52 分钟 |
| 99.999% | 0.001% | 26 秒 | 5 分钟 |
2.2 错误预算的计算
错误预算的计算需要考虑时间窗口和请求量:
30 天总秒数 = 30 × 86400 = 2,592,000错误预算秒数 = 2,592,000 × 0.1% = 2,592 秒 ≈ 43.2 分钟
30 天总请求数 = 1000 × 2,592,000 = 2,592,000,000允许失败请求数 = 2,592,000,000 × 0.1% = 2,592,000| 请求量 | SLO 99.9% | 30 天允许失败数 | 每小时允许失败数 |
|---|---|---|---|
| 100 QPS | 99.9% | 259,200 | 360 |
| 1,000 QPS | 99.9% | 2,592,000 | 3,600 |
| 10,000 QPS | 99.9% | 25,920,000 | 36,000 |
错误预算的计算要基于实际请求量,而不是理论值。低流量服务的错误预算天然更紧张——如果一天只有 1000 个请求,10 个失败就是 1% 的错误率,已经烧掉了 10 天的错误预算。对于低流量服务,考虑使用更宽松的 SLO 或更长的评估窗口。
2.3 错误预算的使用
错误预算不是”可以浪费的额度”,而是”创新的燃料”:
| 错误预算状态 | 行动 | 说明 |
|---|---|---|
| 充裕(> 50%) | 可以发布新功能、做实验 | 创新期 |
| 紧张(10-50%) | 谨慎发布、加强测试 | 过渡期 |
| 耗尽(< 10%) | 停止发布、专注稳定性 | 稳定期 |
| 超支(< 0%) | 事故复盘、优先修复 | 救火期 |
错误预算的核心价值不是惩罚,而是对齐——它让开发团队和 SRE 团队在”什么时候应该优先稳定性”这个问题上有了客观的判断标准,而不是靠主观感觉。
2.4 错误预算策略
不同团队可以采用不同的错误预算策略:
| 策略 | 描述 | 适用场景 |
|---|---|---|
| 滚动窗口 | 过去 30 天的错误预算 | 通用 |
| 日历月 | 每月 1 日重置 | 与业务周期对齐 |
| 消耗式 | 不重置,直到 SLO 恢复 | 严格模式 |
| 分级 | 核心服务严格,非核心宽松 | 多服务场景 |
三、燃烧率与多窗口告警
3.1 燃烧率
燃烧率(Burn Rate)是错误预算消耗速度的度量:
燃烧率 = 实际错误率 / 允许错误率| 燃烧率 | 含义 | 错误预算消耗 |
|---|---|---|
| 1 | 恰好按预算消耗 | 30 天耗尽 |
| 2 | 2 倍速消耗 | 15 天耗尽 |
| 6 | 6 倍速消耗 | 5 天耗尽 |
| 14.4 | 14.4 倍速消耗 | 2 天耗尽 |
| 43.2 | 43.2 倍速消耗 | 16.7 小时耗尽 |
3.2 燃烧率的计算详解
燃烧率的计算需要理解”错误率”和”允许错误率”的关系:
# 完整 PromQL( sum(rate(http_requests_total{status=~"5.."}[1h])) by (service) / sum(rate(http_requests_total[1h])) by (service))/(1 - 0.999) # 允许错误率 = 1 - SLO燃烧率告警的关键洞察:燃烧率越高,错误预算消耗越快,告警越紧急。
3.3 多窗口告警
Google SRE 推荐的多窗口告警策略,使用两个时间窗口来平衡灵敏度和误报率:
# 多窗口告警规则groups: - name: slo-burn-rate rules: # 快速燃烧:14.4x 燃烧率,1h/5m 窗口 - alert: SLOFastBurnRate expr: | ( sum(rate(http_requests_total{status=~"5.."}[1h])) by (service) / sum(rate(http_requests_total[1h])) by (service) ) / ( sum(rate(http_requests_total{status=~"5.."}[5m])) by (service) / sum(rate(http_requests_total[5m])) by (service) ) > 14.4 for: 5m labels: severity: page
# 慢速燃烧:6x 燃烧率,6h/30m 窗口 - alert: SLOSlowBurnRate expr: | ( sum(rate(http_requests_total{status=~"5.."}[6h])) by (service) / sum(rate(http_requests_total[6h])) by (service) ) / ( sum(rate(http_requests_total{status=~"5.."}[30m])) by (service) / sum(rate(http_requests_total[30m])) by (service) ) > 6 for: 30m labels: severity: ticket3.4 多窗口告警参数
| 告警级别 | 燃烧率 | 短窗口 | 长窗口 | 检测时间 | 误报率 |
|---|---|---|---|---|---|
| Page(立即处理) | 14.4x | 5m | 1h | ~5 分钟 | 低 |
| Ticket(工作时间内处理) | 6x | 30m | 6h | ~30 分钟 | 极低 |
3.5 为什么是 14.4 和 6?
这两个数字不是随意选择的,它们来自 Google SRE 的数学推导:
# 快速燃烧(Page 级)# 条件:14.4x 燃烧率在 1 小时窗口内持续# 错误预算消耗:14.4 × (1h / 720h) = 2%# 含义:1 小时内消耗 2% 的 30 天错误预算# 30 天错误预算在 2 天内耗尽 → 需要立即处理
# 慢速燃烧(Ticket 级)# 条件:6x 燃烧率在 6 小时窗口内持续# 错误预算消耗:6 × (6h / 720h) = 5%# 含义:6 小时内消耗 5% 的 30 天错误预算# 30 天错误预算在 5 天内耗尽 → 工作时间处理| 燃烧率 | 30 天预算耗尽时间 | 告警级别 | 理由 |
|---|---|---|---|
| 1x | 30 天 | 无 | 正常消耗 |
| 6x | 5 天 | Ticket | 需要关注但不紧急 |
| 14.4x | 2 天 | Page | 需要立即处理 |
不要设置太多 SLO 告警。每个 SLO 最多两个告警级别(Page + Ticket)。如果 Page 告警超过每周 1-2 次,说明 SLO 太严格或系统需要改进。
3.6 告警规则模板
以下是一个通用的 SLO 告警规则模板,可以直接复用:
# SLO 告警规则模板# 替换 {{SERVICE}} 和 {{SLO_THRESHOLD}} 即可使用groups: - name: slo-{{SERVICE}}-burn-rate rules: # ===== 可用性 SLO ===== - alert: {{SERVICE}}AvailabilityFastBurn expr: | ( sum(rate(http_requests_total{service="{{SERVICE}}",status=~"5.."}[1h])) / sum(rate(http_requests_total{service="{{SERVICE}}"}[1h])) ) > (1 - {{SLO_THRESHOLD}}) * 14.4 for: 5m labels: severity: page slo: availability service: "{{SERVICE}}" annotations: summary: "{{SERVICE}} 可用性 SLO 快速燃烧" runbook_url: "https://wiki/runbooks/{{SERVICE}}-availability"
- alert: {{SERVICE}}AvailabilitySlowBurn expr: | ( sum(rate(http_requests_total{service="{{SERVICE}}",status=~"5.."}[6h])) / sum(rate(http_requests_total{service="{{SERVICE}}"}[6h])) ) > (1 - {{SLO_THRESHOLD}}) * 6 for: 30m labels: severity: ticket slo: availability service: "{{SERVICE}}" annotations: summary: "{{SERVICE}} 可用性 SLO 慢速燃烧"
# ===== 延迟 SLO ===== - alert: {{SERVICE}}LatencyFastBurn expr: | ( 1 - sum(rate(http_request_duration_bucket{service="{{SERVICE}}",le="0.5"}[1h])) / sum(rate(http_request_duration_count{service="{{SERVICE}}"}[1h])) ) > (1 - 0.99) * 14.4 for: 5m labels: severity: page slo: latency service: "{{SERVICE}}" annotations: summary: "{{SERVICE}} 延迟 SLO 快速燃烧"四、SLO 实施方法论
4.1 SLO 选择原则
| 原则 | 说明 | 反模式 |
|---|---|---|
| 从用户视角定义 | 度量用户体验,而非系统指标 | CPU 使用率 SLO |
| 少即是多 | 3-5 个核心 SLO 足够 | 20 个 SLO |
| 可行动 | SLO 违规时你知道该做什么 | 无法行动的 SLO |
| 渐进式收紧 | 先设宽松 SLO,逐步收紧 | 一开始就设 99.999% |
| 分类分级 | 核心服务严格,非核心宽松 | 所有服务同一个 SLO |
4.2 SLO 分类
| 服务类型 | 可用性 SLO | 延迟 SLO | 告警策略 |
|---|---|---|---|
| 核心服务(支付、认证) | 99.95% | P99 < 200ms | Page 级 |
| 重要服务(订单、搜索) | 99.9% | P99 < 500ms | Page + Ticket |
| 一般服务(推荐、通知) | 99.5% | P99 < 1s | Ticket 级 |
| 实验性服务 | 99.0% | 无 | 无告警 |
4.3 不同服务的 SLO 示例
示例 1:支付服务(核心)
spec: service: payment-service slo: - name: availability objective: 99.95 description: "99.95% 的支付请求成功完成" sli: events: error_query: sum(rate(payment_requests_total{status!="success"}[{{.window}}])) total_query: sum(rate(payment_requests_total[{{.window}}]))
- name: latency objective: 99.9 description: "99.9% 的支付请求在 3s 内完成" sli: events: error_query: | sum(rate(payment_duration_bucket{le="3"}[{{.window}}])) / sum(rate(payment_duration_count[{{.window}}])) total_query: "1"
- name: correctness objective: 99.99 description: "99.99% 的支付金额一致" sli: events: error_query: sum(rate(payment_reconciliation_errors_total[{{.window}}])) total_query: sum(rate(payment_requests_total[{{.window}}]))示例 2:搜索服务(重要)
spec: service: search-service slo: - name: availability objective: 99.9 description: "99.9% 的搜索请求返回结果" sli: events: error_query: sum(rate(search_requests_total{status=~"5.."}[{{.window}}])) total_query: sum(rate(search_requests_total[{{.window}}]))
- name: latency objective: 99.0 description: "99% 的搜索请求在 500ms 内完成" sli: events: error_query: | sum(rate(search_duration_bucket{le="0.5"}[{{.window}}])) / sum(rate(search_duration_count[{{.window}}])) total_query: "1"示例 3:通知服务(一般)
spec: service: notification-service slo: - name: delivery objective: 99.5 description: "99.5% 的通知在 5 分钟内送达" sli: events: error_query: sum(rate(notifications_total{delivered="false"}[{{.window}}])) total_query: sum(rate(notifications_total[{{.window}}]))4.4 SLO 生命周期
4.5 SLO 最佳实践
| 实践 | 说明 | 常见错误 |
|---|---|---|
| 先度量后定义 | 先收集 SLI 数据,再设定 SLO | 凭直觉设 SLO |
| 从宽松开始 | 先设 99.5%,逐步收紧到 99.9% | 一开始就设 99.99% |
| 月度评审 | 每月回顾 SLO 达成情况 | 设了就不管 |
| 区分 SLO 和 SLA | SLO 是内部目标,SLA 是外部承诺 | 把 SLA 当 SLO |
| 错误预算驱动发布 | 预算充裕时发布,耗尽时冻结 | 不看预算盲目发布 |
五、SLO 仪表盘设计
5.1 SLO 仪表盘的核心组件
一个好的 SLO 仪表盘应该一目了然地回答三个问题:SLO 达成了吗?错误预算还剩多少?燃烧率是多少?
5.2 SLO 仪表盘的 PromQL 查询
# 1. 当前 SLI 值1 - ( sum(rate(http_requests_total{status=~"5.."}[30d])) / sum(rate(http_requests_total[30d])))
# 2. 剩余错误预算1 - ( (1 - sum(rate(http_requests_total{status=~"5.."}[30d])) / sum(rate(http_requests_total[30d]))) / 0.999 # SLO 目标)
# 3. 燃烧率( sum(rate(http_requests_total{status=~"5.."}[1h])) / sum(rate(http_requests_total[1h])))/(1 - 0.999)
# 4. 错误预算消耗趋势(30 天窗口)1 - ( sum_over_time((1 - (sum(rate(http_requests_total{status=~"5.."}[5m])) / sum(rate(http_requests_total[5m]))))[30d:]) / sum_over_time((1)[30d:]))5.3 SLO 仪表盘布局建议
| 行 | 面板 | 类型 | 说明 |
|---|---|---|---|
| 1 | SLO 状态概览 | Stat Panel | 大字体显示 SLI 值和 SLO 目标 |
| 1 | 错误预算剩余 | Gauge | 0-100%,颜色随预算变化 |
| 2 | SLI 趋势 | Time Series | 30 天 SLI 趋势 + SLO 目标线 |
| 2 | 错误预算趋势 | Time Series | 30 天预算消耗趋势 |
| 3 | 燃烧率 | Time Series | 当前燃烧率 + 告警阈值线 |
| 3 | 事件时间线 | Annotations | 部署/事故/变更标记 |
六、事件响应工作流
6.1 SLO 驱动的事件响应
6.2 事件响应流程
| 阶段 | 时间目标 | 行动 | 产出 |
|---|---|---|---|
| 响应 | < 5 分钟 | 确认告警、加入 oncall 频道 | 响应确认 |
| 评估 | < 15 分钟 | 评估影响范围、确认 SLO 违规程度 | 影响评估 |
| 缓解 | < 30 分钟 | 实施缓解措施(回滚/限流/扩容) | 缓解确认 |
| 修复 | 视问题而定 | 修复根因 | 修复确认 |
| 复盘 | 48 小时内 | 无指责复盘、更新 SLO/告警 | 复盘报告 |
6.3 复盘模板
## 事件复盘
### 基本信息- 事件时间:YYYY-MM-DD HH:MM - HH:MM- 影响时长:X 分钟- SLO 影响:可用性 SLO 从 99.9% 降至 99.X%- 错误预算消耗:X%
### 时间线- HH:MM - SLO 告警触发- HH:MM - 值班工程师响应- HH:MM - 定位根因- HH:MM - 实施缓解- HH:MM - SLO 恢复
### 根因分析- 直接原因:- 贡献因素:- 根本原因:
### 行动项- [ ] 修复根因(负责人,截止日期)- [ ] 更新 SLO 告警规则(负责人,截止日期)- [ ] 增加防御性检测(负责人,截止日期)七、Grafana SLO 平台
7.1 Grafana SLO 功能
Grafana 提供了 SLO 管理界面,支持:
- SLO 定义和可视化
- 错误预算追踪
- 燃烧率告警
- SLO 报告
7.2 Sloth 工具
Sloth 是一个 SLO 生成器,将 SLO 定义转换为 Prometheus recording rules 和告警规则:
# 安装 Slothgo install github.com/slok/sloth/cmd/sloth@latest
# 生成 Prometheus 规则sloth generate -i slo.yaml -o prometheus-rules.yaml
# 应用规则kubectl apply -f prometheus-rules.yaml7.3 Sloth 生成的 Recording Rules
Sloth 生成的 Recording Rules 大幅简化了 SLO 查询的复杂度:
# Sloth 自动生成的 Recording Rulesgroups: - name: sloth-slo-rules-order-service-availability rules: # SLI 当前值 - record: slo:sli_error:ratio_rate5m expr: | sum(rate(http_requests_total{service="order-service",status=~"5.."}[5m])) / sum(rate(http_requests_total{service="order-service"}[5m]))
# 30 天错误预算剩余 - record: slo:error_budget:remaining expr: | 1 - ( slo:sli_error:ratio_rate30d / (1 - 0.999) )
# 燃烧率 - record: slo:burn_rate:rate1h expr: | slo:sli_error:ratio_rate1h / (1 - 0.999)八、从阈值告警到 SLO 告警
8.1 迁移路径
| 阶段 | 告警类型 | 告警数量 | 误报率 |
|---|---|---|---|
| 阶段 1 | 纯阈值告警 | 500+ | 90% |
| 阶段 2 | 阈值 + 核心 SLO | 300+ | 60% |
| 阶段 3 | SLO 为主 + 少量阈值 | 50+ | 20% |
| 阶段 4 | 纯 SLO 告警 | 20+ | < 5% |
8.2 保留的阈值告警
即使迁移到 SLO 告警,以下阈值告警仍需保留:
| 告警 | 原因 | 严重级别 |
|---|---|---|
| 服务不可达 | SLO 无法度量死掉的服务 | Page |
| 磁盘满 | 系统级问题 | Page |
| 证书过期 | 安全问题 | Ticket |
| 副本数不足 | 可用性风险 | Ticket |
8.3 迁移步骤
| 迁移步骤 | 行动 | 预期效果 |
|---|---|---|
| 1. 选择核心服务 | 挑选 3-5 个核心服务 | 聚焦高价值 |
| 2. 定义 SLO | 为核心服务定义可用性+延迟 SLO | 建立 SLO 基线 |
| 3. 配置 SLO 告警 | 燃烧率告警(Page + Ticket) | SLO 告警上线 |
| 4. 并行运行 | SLO 告警和阈值告警并行运行 | 对比效果 |
| 5. 逐步移除阈值 | 移除被 SLO 告警覆盖的阈值告警 | 减少告警噪音 |
| 6. 扩展到更多服务 | 将 SLO 推广到更多服务 | 全面覆盖 |
九、动手实践
9.1 定义 SLO
# slo.yaml — 订单服务 SLOspec: service: order-service slo: - name: availability objective: 99.9 sli: events: error_query: sum(rate(http_requests_total{service="order-service",status=~"5.."}[{{.window}}])) total_query: sum(rate(http_requests_total{service="order-service"}[{{.window}}]))9.2 生成并应用规则
# 生成 Prometheus 规则sloth generate -i slo.yaml -o rules.yaml
# 应用规则# 将 rules.yaml 添加到 Prometheus 配置9.3 模拟 SLO 违规
# 注入错误,模拟 SLO 违规for i in $(seq 1 100); do curl -s -o /dev/null -w "%{http_code}" http://localhost:8080/api/v1/errordone
# 观察燃烧率告警是否触发curl http://localhost:9090/api/v1/alerts9.4 验证清单
| 检查项 | 验证方式 | 预期结果 |
|---|---|---|
| SLO 指标可查询 | PromQL 查询 | 返回 SLI 值 |
| 错误预算可视化 | Grafana 面板 | 显示剩余预算 |
| 燃烧率告警 | 模拟错误 | 触发告警 |
| 多窗口检测 | 持续错误 | 快速/慢速告警分别触发 |
| SLO 仪表盘 | 查看 Dashboard | 所有面板有数据 |
十、本章小结
上一章剖析了信号关联与 Exemplar。 这一章覆盖了SLO 驱动的可观测性的关键设计。
| 主题 | 核心要点 | 关键词 |
|---|---|---|
| SLI/SLO/SLA | SLI 是度量指标,SLO 是目标值,SLA 是商业后果。SLI 必须从用户视角度量,可计算且可行动。 | SLI/SLO/SLA |
| 错误预算 | SLO 的反面,是创新的燃料——充裕时可以实验,耗尽时必须专注稳定性。计算要基于实际请求量,低流量服务需要特别关注。 | 错误预算 |
| 燃烧率 | 错误预算消耗速度的度量,是 SLO 告警的核心。14.4x 燃烧率意味着 2 天耗尽 30 天预算,需要立即处理。 | 燃烧率 |
| 多窗口告警 | 快速燃烧(14.4x, Page)+ 慢速燃烧(6x, Ticket),平衡灵敏度和误报率。两个数字来自数学推导,不是随意选择。 | 多窗口告警 |
| SLO 仪表盘 | 一目了然地回答”SLO 达成了吗?预算还剩多少?燃烧率是多少?“ | SLO 仪表盘 |
| 事件响应 | SLO 驱动的事件响应流程,48 小时内完成无指责复盘。 | 事件响应 |
| 迁移路径 | 从阈值告警渐进式迁移到 SLO 告警,保留少量系统级阈值告警。 | 迁移路径 |
支持与分享
如果这篇文章对你有帮助,欢迎支持作者或分享给更多人
部分信息可能已经过时






