Abstract	MDD for SRE
Authors	Walter Fan
Category	learning note
Status	v1.0
Updated	2025-08-24
License	CC-BY-NC-ND 4.0

MDD for SRE

when you got through the storm, you won't be the same person who walked through it. 当你穿过风暴走出来时，你已经不是走进去的那个人了。
—— 致每一个被线上事故洗礼过的 SRE

一、MDD 是什么鬼？

度量驱动开发（Metrics Driven Development，MDD）听起来很学术，其实核心思想一句话就能概括： 别拍脑袋做决策，用数据说话。

在 SRE 体系里，MDD 就像一台“系统健康检测仪”，把模糊的“系统要稳”翻译成具体的指标：吞吐量、延迟、错误率……让我们从“感觉差不多”升级到“数据有证据”。换句话说，MDD 就是从“玄学经验”走向“量化科学”。

二、三大法宝：SLI、SLO、SLA

要想把系统运营好，少不了这三兄弟：

• SLI（Service Level Indicator）：系统健康的“体温计”。
  吞吐量、响应时间、错误率，这些指标就是你系统的血压心跳。

• SLO（Service Level Objective）：系统的“健身目标”。
  例如：请求成功率 ≥ 99.9%，平均响应时间 ≤ 500ms。
  SLO 不仅帮团队设定方向，还能防止产品经理天天嚷嚷“要 100% 可用”。

• SLA（Service Level Agreement）：法律背书 + 赔偿承诺。
  就是把 SLO 写进合同：没达标？赔钱！SLA 是系统可靠性与客户信任之间的“法律护城河”。

一句话总结：
SLI 告诉你“我现在健康吗”，SLO 告诉你“我要多健康”，SLA 告诉客户“我保证健康，不然我掏钱”。

三、MDD 的开发周期：数据先行，不再救火

• 设计阶段：需求评审不只聊功能，还要把可靠性指标写进文档。就像写代码要有单测，设计方案也要有“可测性”。
• 开发阶段：写代码时就埋好监控点，用自动化测试和监控平台保证指标不跑偏。
• 运维阶段：实时监控 + 智能告警 + 自动化回滚。别等线上炸了再喊“谁来救火”，而是提前用数据发现隐患。

一句话，MDD 让 SRE 从“消防员”变成“城市规划师”。

四、最佳实践：少而精，别乱堆指标

• 业务对齐：指标必须和业务挂钩，比如 API 延迟要能体现用户体验，而不是只看 CPU 飙到 90%。
• 最小完备：指标不要贪多，核心指标 3～5 个就能反映全局。指标一多，大家就会陷入“监控眼花症”。
• 动态演进：随着业务迭代，指标体系也要升级，别让老旧指标绑架了新系统。

此外，团队文化和工具链也很重要：
度量评审会议要定期开，监控平台要整合好，别让指标散落在 10 个系统里，最后没人能拼出全貌。

五、Go 微服务的实践：用代码把指标钉死

拿一个 Go 订单服务举例，核心套路就是：
1. 埋点（用 OpenTelemetry / Prometheus）
2. 设目标（SLO + 错误预算）
3. 签契约（SLA）
4. 自动化响应（触发回滚 / 扩缩容）

代码示例：
```go // 定义请求计数器 var requestCounter = metric.Must(metric.NewInt64Counter( "order_service_request_count", metric.WithDescription("Total number of requests"), ))

// 在 HTTP 中间件中埋点 func metricsMiddleware(next http.Handler) http.Handler { return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) { requestCounter.Add(r.Context(), 1, metric.WithAttributes( attribute.String("method", r.Method), attribute.String("path", r.URL.Path), )) next.ServeHTTP(w, r) }) } ````

之后配合 Prometheus 写几个公式，就能把吞吐量、错误率、延迟一网打尽。

顺带一提：

• 错误预算超了？自动触发回滚（ArgoCD 蓝绿部署）。
• CPU 连续高于 80%？HPA 自动加 Pod。
• 想查慢请求？Jaeger 一键 Trace 到 SQL。

这才是真·全链路闭环。

六、运维的收益：从“救火队”到“架构师”

• 故障处理效率：MTTR 从 20 分钟缩短到 5 分钟。再也不是“凌晨两点 VPN 登录排查日志”的悲惨故事。
• 日常监控成本降低：监控报表自动生成，日志和指标联动，SRE 不用盯着 Grafana 大屏熬夜。
• 角色转型：运维不再只是“修电脑的”，而是系统可靠性的设计者，提前参与架构评审，和开发并肩作战。

七、挑战与解法

• 指标采集开销大：频繁采集可能拖慢系统 → 调整采样频率，用 summary 替代 histogram。
• 跨服务链路难分析：微服务一多，指标像散沙 → 强制引入 X-Request-ID，用 Trace 串起来。

八、未来展望：MDD + AIOps

未来，随着 AIOps 的发展，MDD 还可能升级成“智能度量驱动”：

• 自动发现关键指标（AI 告诉你：原来用户流失和这个指标挂钩）。
• 智能扩缩容（AI 提前两小时预测流量高峰，Pod 已经扩好）。

换句话说： 👉 未来的 SRE 可能不用天天盯监控，AI 会变成你贴心的“可靠性副驾驶”。

九、结语

MDD 不只是一个“高大上”的概念，而是 SRE 的生存之道。 在 Go 微服务的场景下，它帮助我们从“上线即祈祷”进化为“上线即有数”。

记住一句话： 可靠性不是救火救出来的，而是用度量设计出来的。

---

本作品采用 知识共享署名-非商业性使用-禁止演绎 4.0 国际许可协议 进行许可。