1. 指标体系：从“能看图”到“能决策”
指标不是装饰性图表。高价值指标必须能够触发动作：扩容、降级、暂停发布、回滚。 建议先用四大黄金信号（延迟、流量、错误、饱和度）搭骨架，再补业务 SLI（下单成功率、支付完成率、搜索命中率）。 你应该能回答：这个指标波动时，谁应该在几分钟内采取什么行动。
2. SLI/SLO：定义“好服务”的方法学
SLI（Service Level Indicator） 是实际测量值， SLO（Service Level Objective） 是目标约束。 举例：过去 30 天内，`checkout` 接口 99.9% 请求延迟小于 300ms，且错误率小于 0.2%。 一旦 SLO 被持续侵蚀，发布节奏必须收敛：这就是 error budget 的治理意义。
| Term | Meaning | Example |
|---|---|---|
| SLI | measured quality signal | p99 latency, success ratio |
| SLO | target threshold + window | 99.9% under 300ms in 30d |
| Error Budget | allowed unreliability | 0.1% failure budget |
# Illustrative SLI/SLO formulas
# Success ratio (SLI)
sum(rate(http_requests_total{status!~"5.."}[5m]))
/
sum(rate(http_requests_total[5m]))
# Error budget burn (conceptual)
burn_rate = current_error_rate / allowed_error_rate3. 告警工程：从“噪声轰炸”到“可行动通知”
告警设计要回答三件事：谁被叫醒、为什么叫醒、醒来后先做什么。 推荐采用多窗口告警（fast burn + slow burn）：既捕捉突发事故，也避免短时抖动造成误报。 每条告警都应附上 runbook 链接、最近发布标记、关键仪表盘与一键查询入口。
4. 多窗口告警（Burn-rate alerts）：兼顾“快反应”和“低噪声”
单窗口阈值往往导致两种极端：过于敏感（误报）或过于迟钝（漏报）。 多窗口 burn-rate 策略可同时监控短窗口与长窗口：短窗口捕获急性故障，长窗口确认趋势稳定。 在实际执行中，告警条件通常要求“两窗同时触发”，从而减少噪声。
# Illustrative multi-window burn-rate alert logic (conceptual)
# Short window: 5m, Long window: 1h
if burn_rate_5m > 14 and burn_rate_1h > 6:
page("critical")
elif burn_rate_30m > 6 and burn_rate_6h > 3:
ticket("warning")
5. 指标治理：命名、标签、基数与成本
指标系统最容易“慢性中毒”的问题是标签基数失控。像 `user_id`、`session_id` 这样的高基数字段会迅速放大存储和查询成本。 建议制定指标规范：统一命名（`service_operation_duration_seconds`）、标签白名单（`service`, `region`, `status_class`）、 以及采样/聚合策略。把成本治理写进平台规范，而不是等账单暴涨后补救。
6. 本章清单
- 定义服务核心 SLI（延迟、错误、可用性）并与用户旅程对齐。
- 为关键服务设置 SLO（目标阈值 + 时间窗口），并建立 error budget 解释规则。
- 构建可行动告警：多窗口 burn-rate、告警去重、团队路由、runbook 链接。
- 为每次发布打 release markers，便于指标回归与故障因果分析。
- 制定指标命名和标签规范，控制高基数带来的系统成本。
- 预告下一章：分布式追踪（Tracing），把“慢在哪里”定位到具体调用链。