SRE Google 运维解密读书笔记一：SRE 方法论概述

SRE Google 运维解密，是 SRE 领域的启蒙之作，讲述了 Google 的 SRE 实践，SRE 就是从 Google 流传出来的。本文是读书笔记，第一篇，概述 SRE 方法论。帮大家把书读薄，当然，也加入了一些我的个人理解，希望对你有帮助。

为何需要 SRE

传统的 sysadmin 的方式，偏手工运维，机器越多所需运维工程师越多，对于 Google 的体量（毛估估现在大概有几百万台机器）和增长速度，成本（人工成本、管理成本等）不可承受。

因为目标不同、技术背景不同、对可靠性理解不同，传统运维和产品研发团队之间，很容易形成巨大的鸿沟，有时会上升到部门之间的信任和尊重层面。比如拿变更举例，研发部门想要：“随时随地发布新功能，没有任何阻拦”，传统的运维团队想要的则是：“一旦一个东西在生产环境中正常工作了，就不要再做任何改动”。这样的两个团队，是没法很好的合作的，尤其是在 Google 的体量和增速下，得改。解法就是 SRE。

Google SRE 概述

Google SRE 的创始人是 Benjamin Treynor Sloss，研发出身，2003 年加入 Google，被任命领导一个 7 人小组（现在，SRE 团队已经上千人了），负责“生产环境维护”。Google 当时的增速是非常快的，如果按照传统的玩法，招人的速度完全无法匹配机器增速，怎么做这个“生产环境维护”的工作呢？

Benjamin Treynor 是资深研发，自然就会考虑用软件工程的手段来解决遇到的各类问题，所以 Google SRE 首先，得具备研发技能，用研发技能来解决各类生产维护重复工作。他们具备如下特质：

• 对重复性、手工性的操作有天然的排斥感
• 有足够的技术能力快速开发出软件系统以替代手工操作

但是，做过运维的人都知道，总有一些日常运维的工作无法避免，有时根本没时间写代码，比如处理工单、手工操作，尤其是在基础设施平台工程不完备的情况下。这可咋整？

Google 提出了 50% 的原则，即日常运维的时间不能超过 50%，即需要至少拿出一半以上的时间来做工程研发，釜底抽薪，用工程手段解决手工操作。那有的时候，日常运维工作繁重，超过了 50% 时间分配原则，怎么办？把相关工作交给产品研发团队的 leader，让他来帮忙消化掉一部分工作。研发 leader 一看，运维侧的工作好多啊，是不是我们的软件不够鲁棒、很多应该自动处理的逻辑没有自动处理，就会去改进，形成正向循环。当然，这个机制需要公司管理层强力推动。如果遇到一个研发团队说，运维的活你们运维干不完，干不完可以招人啊，管理层也不作为，就完了。

DevOps 还是 SRE

Benjamin Treynor 认为，SRE 是 DevOps 模型在 Google 的具体实践，带有一些特别的扩展。

SRE 技能组成

实际的人员组织来看， SRE 团队分两类人，一类就是纯研发，一类是具备八九成研发能力，同时还懂一些 UNIX 知识、网络知识。如果国内运维团队想要转型为 SRE 组织，就这个技能要求就很难达成（其实除了 Google，其他国外的公司也很难做到）。咋办？

国内的组织的做法：一个人能力有限，弄个团队来顶上，团队里既有只懂研发的人，又有只懂网络的人，又有只懂操作系统的人，应该就可以了吧。个人的看法是，这个做法基本是对的，但是不完全够。因为虽然是一个团队，但是不同的小组或个人的知识仍然是无法完全共享的，这使得在做工程决策、实践的时候，没法做到像 Google SRE 那样如臂指使。

稍微改进一下的做法是：团队里仍然要招聘一两个 SRE 专家，姑且称为 SRE COE，既懂开发又懂运维的那种，统筹所有工作，然后那些单方面的技能人才，辅助 SRE COE 来完成工作，相对会更靠谱一些。

SRE 方法论

SRE 团队的职责：可用性改进，廷迟优化，性能优化，效率优化，变更管理，监控，紧急事务处理以及容量规划与管理。要转型的团队注意了，用软件工程的手段达成以上目标，就说明你们团队转型成功了:)

在保障服务 SLO 的前提下最大化迭代速度

变更是万恶之源，生产环境中的故障，大概有 70% 都是变更引起的。屁股决定脑袋，运维团队就希望尽量别有变更，研发团队要上线新 feature，那就需要频繁变更，咋整？Google 提出了 “错误预算” 的理念。

产品首先得确定 SLO，比如某个服务的季度 SLO 目标是 99.99%，那不可用的 Quota 预算就是 0.01%，每个月按照 30 天来算，一个季度 90 天，允许的不可用分钟数是：

90 * 24 * 60 * 0.01% = 12.96 分钟 ≈ 13 分钟

只要服务的季度不可用时长低于 13 分钟，随便折腾，但是一旦超过了 13 分钟，说明 Quota 用光了，就不能随意上线了，非得要上线，行么？也行，VP 审核通过吧。那意思就是：你看这个研发团队，上线老是出问题，不可信赖，现在又要上线了，SRE 是不准备放行了，VP 大佬来决策吧，VP 大佬也非要允许上，那就上。

咋样，这个方法听着不错吧。贵司可以试试。这里要注意，服务要想减少故障时长，是需要有良好的基础设施保障的，比如研发上线发现问题，想回滚，结果部署系统不可靠，这找谁说理去。所以，错误预算这个方法可以用，但是不同的公司，SLO 的阈值得谨慎制定，没有金刚钻不揽瓷器活，基础设施很烂，SLO 就定低点吧。

SLO 谁来定？

SLO 应该是业务来定，但是 SRE 要提供一些信息，告诉业务达成什么样的 SLO 要付出什么样的成本，业务有了这些信息了，再来确定制定什么样的 SLO。比如某个业务不盈利，就是个实验性质的业务，SLO 低一点很正常，具体要看业务本身的决策，所以 SLO 的制定需要业务拍板。

监控系统

核心要学习的是：每个需要通知到人的告警，必须对应 Runbook，即预案手册。如果一个告警发出来，没有人响应，没有相应的动作执行，这个告警就是无效的。Runbook 链接一般配置在告警规则里，比如 Grafana、Nightingale、Datadog 的告警规则配置，都支持这么干。告警规则的 Runbook 预置率是一个很好的告警治理指标。

有些告警可以不用立即处理，但是至少得创建个工单留待后续处理。

应急事件处理

提前准备好 Runbook，即预案手册，比即兴发挥，效果好 3 倍。

变更管理

要自动化！要自动化！要自动化！自动化完成以下项目：

• 采用渐进式发布机制
• 有良好的监控系统，可以快速发现问题
• 当问题发生时，可以安全回滚

需求预测和容量规划

要考虑的点包括：

• 自然增量：随着用户自然增长带来的增量
• 非自然增量：比如市场活动
• 周期性压测：这点很关键，这点很关键，这点很关键，通过压测才知道你的系统瓶颈在哪个微服务，才能把系统原始资源和业务容量对应起来

资源部署

扩容需要部署资源，变更也需要，这就是 Borg 的作用，其他公司可以采用类似 Kubernetes 的方案。不管使用什么方案，能够快速、正确的完成部署，最大化资源使用，就可以了。

效率与性能

SRE 也需要关注服务性能，提升了性能，其实就是提高了资源利用效率，同样的硬件可以支撑更大量的客户。NetFlix 有专门的 Performance 工程师，Google 的话 SRE 一并干了这个事情。

小结

SRE 团队的职责：可用性改进，廷迟优化，性能优化，效率优化，变更管理，监控，紧急事务处理以及容量规划与管理。我们要用软件工程的思维来解决这些问题，完活。留个问题：

SRE 要不要修改业务代码？

比如增加一些监控埋点，或者优化一个算法提升软件性能，或者换了一个更合理的存储？欢迎大家留言讨论 :)