# Summary Site Reliability Engineering SRE 团队：会设定网站必须 $99.9\%$ 可用（SLO），当流量激增时自动扩容，出问题时快速回滚；同时写工具让运维自动化。 # Cues [[SLO]] # Notes 你问的这个其实是一个经典缩写问题（术语辨析类）的变体——很多人第一次听到 SRE 时会混淆它到底指的是职位、团队，还是一种工作方法。 --- 什么是 SRE？ SRE = Site Reliability Engineering（站点可靠性工程）。 它最早由 Google 提出，本质上是一种把软件工程方法应用到运维/系统可靠性上的理念与实践。 * 定位：介于开发（Dev）和运维（Ops）之间的角色 * 目标：让系统在规模化运行时依然保持高可用性（高可靠、低延迟、可扩展） * 方法：用工程化手段（自动化、监控、故障预案、容量规划等）替代传统“人肉运维” --- SRE 的核心思想 1. 错误预算（Error Budget） * 不是追求 $100\%$ 可用，而是根据 SLA/SLI/SLO 定义“可接受的错误范围”。 * 在错误预算内可以大胆发布新功能，超出预算则必须优先修复可靠性问题。 2. 自动化 * 尽量减少手工操作，所有重复性、容易出错的工作都自动化（CI/CD、监控报警、扩缩容等）。 3. 监控 & 可观测性 * 关注指标：延迟、流量、错误率、资源使用。 * SRE 团队常会搭建完善的监控系统（如 Prometheus、Grafana）。 4. 事故响应与复盘 * 出现故障时，强调快速响应（On-call 轮值）。 * 事后复盘（Postmortem）不追责，而是找出系统性改进方法。 --- 举个例子 假设你有一个电商网站： * 开发团队：负责写新功能，比如优惠券系统。 * 传统运维：负责上线部署、服务器维护。 * SRE 团队：会设定网站必须 $99.9\%$ 可用（SLO），当流量激增时自动扩容，出问题时快速回滚；同时写工具让运维自动化。 --- 要不要我再帮你对比一下 SRE 和传统运维/DevOps 的区别，用一个表格总结？