SRE 是有史以来最棒的事
Source: Dev.to
如果你不知道 SRE 是什么，别担心……我来给你解释。
我是 Jairo Jr.，在 Mercado Livre 担任 Software Engineer，居住在巴西，过去几个月我一直在学习 SRE。
SRE 改变了我看待生产环境的方式。
在接触 SRE 之前，我对生产的认知是：
- ✅ “部署完成”
- ✅ “功能正常”
- ✅ “继续下一个任务”
深入了解 SRE 后，我开始把生产环境看成：
“好……但如果它在凌晨 3 点崩溃了怎么办？”
那么……什么是 SRE？
SRE 代表 Site Reliability Engineering（站点可靠性工程）。它起源于 Google 大约在 2003 年，当时他们意识到一个简单的真理：
如果你的产品在增长，问题也会随之增长。
真正的痛点并不是仅仅出现问题（每个系统都会有）。而是要应对：
- 每周都会出现的问题
- 破碎的用户体验
- 压力山大的人们
- 值班变成噩梦
- 公司在你像侦探一样调试日志时亏损 🕵️♂️
SRE 是一种让软件：
- ✅ 可扩展
- ✅ 可靠
- ✅ 可度量
- ✅ 更少“随机” 的方法
SRE 并非只是带有花哨名称的 DevOps
很多人认为 “SRE 是 DevOps，对吧？” 实际并非如此。SRE 将 DevOps 目标 与 工程思维 结合起来。
与其永远手动解决问题，SRE 会问：
- “我们能自动化吗？”
- “我们能预测吗？”
- “我们能在客户发现之前检测到吗？”
- “我们能更快恢复吗？”
它将实践从被动响应转向主动预防。
日常示例（真实案例）
想象这样一个经典情形：
- 你部署了一个新功能。
- 一切看起来正常。
- 十分钟后：
- 延迟飙升 📈
- 部分请求开始失败
- 你的指标仪表盘像圣诞树一样 🎄
你可能会听到那句魔法般的话：“对我来说它在正常工作…”，但对用户来说：
❌ 并非如此。
SRE 帮助你快速回答：
- 到底哪里坏了？
- 什么时候开始的？
- 是影响所有人还是只有部分客户？
- 是我的服务出问题，还是依赖的服务出问题？
- 有什么变化了吗？
- 我能多快回滚？
如果没有 SRE 文化，你通常会通过以下方式发现问题：
- Slack 消息
- 客户投诉
- 经理问 “发生了什么？” 😭
SRE 教你衡量可靠性
SRE 以数字为基础。与其说：
❌ “我们的服务非常稳定”
不如说：
✅ “我们的服务是稳定的，因为我们的 SLO 为 99.9 %，且我们仍在误差预算内。”
这使得可靠性成为一个具体的讨论对象，涉及：
- 工程师
- 产品团队
- 经理
- 业务相关者
所有人都能理解。
SLO 和错误预算（不同之处）
如果你的 SLO 是 每月 99.9 % 可用性，那么你大约可以承受 每月 43 分钟的停机时间。这就是你的 错误预算。
经验法则：
- ✅ 在预算内 → 你可以部署更多。
- ❌ 预算已耗尽 → 停止推送风险更高的更改，专注于可靠性。
换句话说，SRE 的建议是：“快速前进…但不要愚蠢地快。”
SRE 是让你不再是英雄的原因
没有 SRE 时，常见的文化会出现：
- 出现故障。
- 有人醒来后，修复所有问题，成为“英雄”。
这种陷阱使系统依赖于人类。人类：
- 会感到疲惫
- 会犯错
- 会生病
- 会休假
- 会换工作
SRE 推动你构建不需要英雄的系统。这不是关于“谁修复得更快”，而是关于：
- ✅ 为什么会发生
- ✅ 我们改进了什么
- ✅ 我们如何防止再次发生
- ✅ 我们如何在下次降低影响
值班不是问题（糟糕的值班才是）
值班是工作的一部分，但 糟糕的值班 会毁掉团队。糟糕的值班表现为：
- 无用的警报不断打扰你
- 没有运行手册
- 没有清晰的仪表盘
- 没有回滚计划
- 没有负责人
- 每次事故都像是第一次
优秀的 SRE 通过推动团队构建以下内容，使值班更轻松：
- 清晰的监控
- 有意义的警报
- 快速的恢复流程
- 完善的事故处理流程
因此团队从“恐慌模式”转向“流程模式”。
真正的目标：保护你的用户
归根结底，用户并不在乎：
- Kubernetes、Kafka、重试、p95 延迟、缓存失效
他们在乎的是：
- ✅ 应用能够正常运行
- ✅ 支付顺利完成
- ✅ 界面加载迅速
- ✅ 订单得到确认
SRE 帮助你 每天 都实现这些，而不仅仅是在本地机器上。
为什么我认为 SRE 是有史以来最棒的东西
因为它改变了你的思维方式。
SRE 让你不再只考虑：
🧩 “如何构建这个功能”
而是开始思考：
🔥 “如何让这个功能在生产环境中为数百万用户持续运行”
这是一种不同层次的工程。