SRE Google 运维解密笔记

引言

各位运维老铁们，今天想跟你们聊聊 SRE 这个话题。之前读完了 Google 那本《Site Reliability Engineering》，感触挺深的，觉得有必要把笔记整理出来分享一波。这本书真的刷新了我对运维的认知，原来运维还可以这么玩！

什么是 SRE？

SRE 全称 Site Reliability Engineering，也就是站点可靠性工程。Google 在 2003 年就提出了这个概念，简单来说就是把软件工程的思路应用到运维领域。

传统运维往往是「救火队」模式——系统挂了就去修，出了故障就去排查。这种被动的方式真的很累人，而且容易陷入恶性循环。SRE 则强调用工程化的方法来预防问题、提高系统的可靠性。

Google 内部有句话我很认同：可靠性是产品的核心功能之一。如果你的服务经常宕机，用户会用脚投票，再好的功能也没用。

核心原则：错误预算

SRE 里面有个特别重要的概念叫「错误预算」(Error Budget)。听起来高大上，其实理解起来很简单：

> 错误预算 = 1 - SLO

举个例子，如果你设定服务的可用性目标是 99.9%（也就是大家常说的三个九），那错误预算就是 0.1%。如果你的服务运行了一个月，这个 0.1% 就意味着大概 43 分钟的不可用时间。

这个概念为啥重要呢？它给开发和运维提供了一个共同的量化目标。以前开发和运维经常互相甩锅，现在好了，大家都有一个明确的目标，一起为可靠性努力。

错误预算用完了怎么办？很简单，停止新功能上线，全力修复可靠性问题。这听起来很残酷，但其实是保护产品和用户的最佳实践。

SLO 和 SLI：可靠性指标怎么定

SLO 是服务等级目标 (Service Level Objective)，SLI 是服务等级指标 (Service Level Indicator)。这三个概念经常把人绕晕，我来说说我的理解：

- SLI：你实际测量到的指标，比如延迟、错误率、可用性

- SLO：你承诺的目标，比如「99.9% 的请求延迟小于 200ms」

- SLA：你对外宣传的承诺，违反了这个要赔钱的！

实践中，我建议 SLI 要选用户能感知到的指标，比如：

# 常见的 SLI 指标示例
- 请求延迟 P99 < 200ms
- 错误率 < 0.1%
- 可用性 > 99.9%
- 吞吐量 > 1000 QPS

SLO 的设定也有讲究，不能太宽松（失去意义），也不能太严格（根本达不到）。我的经验是先从当前实际水平开始，然后逐步提高。

可观测性：出了问题怎么办

SRE 特别强调「可观测性」(Observability) 的重要性。以前我们总是说「监控」，但现在更流行的说法是可观测性，因为它包含的范围更广：

1. 指标 (Metrics)：数值型的聚合数据，比如 CPU 使用率、请求数

2. 日志 (Logs)：事件发生时的详细记录

3. 链路追踪 (Tracing)：请求在分布式系统中的完整路径

这三大支柱缺一不可。我见过很多团队只关注指标，出了故障根本定位不了问题。日志和追踪真的很重要，关键时刻能救命的！

现在很多开源工具可选，Prometheus + Grafana 做指标，ELK 做日志，Jaeger 做追踪，都是不错的选择。

日常运维实践

书里有几个日常实践我觉得特别实用：

总结

读完这本书最大的感受是：SRE 不仅是一套方法论，更是一种思维方式。它让运维从「被动救火」变成「主动建设」，用工程化的方法来解决可靠性问题。

如果你也是做运维或者开发的，真的建议看看这本书。不管你是想提升自己的专业能力，还是想推动团队的运维现代化，SRE 都值得一试。

好了，今天的分享就到这里，我们下期再见！有问题欢迎评论区聊聊。