SRE 侧重系统稳定性，DevOps 强调开发运维协作。SRE 实践助力DevOps，提升系统稳定性与团队协作效率。
SRE 运用软件工程的原理，将系统管理员的手工任务自动化，负责运维由系统组件构成的服务，确保服务稳定运行。SRE职责涵盖监控开发、资源规划、紧急事件处理及事故根源追踪等，致力于消除重复性、手工性操作。
DevOps强调开发与运维的协同合作，通过工具链和流水线实现高效衔接，持续反馈以优化研发到运维的流程。
两者虽各有侧重，但SRE的实践正是DevOps建设思路的体现，通过自动化和智能化手段提升运维效率，促进开发与运维的紧密合作，共同推动系统稳定性与业务价值的提升。
一、理解 SRE 和 DevOps 异同
有人说 SRE 就是 DevOps，DevOps 等于 SRE，其实是不对的。DevOps 是一种协调开发和运维之间协作关系的思想理念，SRE 是在 Google 类似于 DevOps 思想理念的一种实践。SRE 更关注站点或产品或应用服务等运行的稳定性，以 “错误预算” 协调开发和运维之间的利益关系，所以 SRE 其实更多是在 Ops 端。但关注 “运维 Ops” 这无疑是正确的，和我们习惯于更关注 “开发 Dev” 是不一样的。SRE 强调用工程化的手段应对运维问题。软件运维问题达到一定规模时，也确实只能通过软件工程化的手段来解决。
SRE 团队替代了很多研发 Dev 的工作，使 Dev 更专注于业务应用或产品的研发，而不再关注软硬件基础设施和中间件工具，所以研发的工作就聚焦化了。同时通过 SRE 团队所构建的自动化工具链、流水线等提升了研发效率。
DevOps 和 SRE 的关系类似于 SOA 和 ESB 的关系。SRE 是 DevOps 思想落地的一种方式。SRE 模型成功的关键在于对工程的关注，如果没有持续的、工程化的解决方案，运维的压力就会不断增加，也就需要更多的人来完成工作。SRE 的终极目标是推动整个系统趋向于无人化运行，也就是智能化，不仅仅是自动化。“如果系统正常运转中需要人工干预，应该将此视为一种 bug”。
SRE 既做运维也做开发。其开发时间不少于 50%。既保障 SRE 有足够的时间和精力去进行真正有创造性的、自主性的研发工作，同时也保障了 SRE 团队有足够的运维经验，深度理解运维的需求，从而让他们设计出切实解决问题的系统。但 SRE 只是关注于运维工具和流程自动化的研发，而不做业务应用或产品的研发。这也从实践说明了 DevOps 的建设是需要靠自己而不是靠外部厂商。因为这是一个持续的，不断变化改进的过程。
二、研发和运维之间的利益冲突
企业中研发 Dev 和运维 Ops 之间最主要的矛盾就是应用服务迭代创新的速度与应用服务稳定运行程度之间的矛盾。我们总是强调敏捷研发、敏捷交付，但是研发之后交付之后改怎么运维却考虑的比较少。虽然目前智能运维 AIOps 等很多人都在讲，但个人觉得目前更多只是噱头，远未到智能运维的阶段。试想基本运维都没做好就去做智能运维，就像让不会走的小孩就要跑起来，有点可笑。要解决 Dev 和 Ops 双方的利益冲突，则需要同时能关注矛盾双方的诉求、保障矛盾双方的利益。既要保证 “速度”，更要关注 “稳定性”。但任何软件系统都不应该一味追求 100% 可靠。对最终用户来说，99.99%、99.999% 和 100% 的可用性并没有实质的区别。因此 DevOps 建设就是追求这种矛盾的统一。
我们说过，在软件整个生命周期过程中，研发阶段可能只占 20%，大部分时间都是在运维、在持续优化。所以 SRE 关注运维是正确的。解决方式就是通过软件工程化、系统化的方法来解决运维问题，这也就是很多人说的 “研发运维一体化”（这里的研发是 “运维研发”，不是 “产品研发”）。企业 DevOps 建设就需要设法协调研发与运维之间的矛盾，满足双方的利益诉求。SRE 是通过高层所定下的 “错误预算” 来协调双方矛盾的（但错误预算有其局限性，我们将在后续详细讨论 DevOps 效率建设问题）。在 DevOps 建设中，研发关注需求、CI，CD 则需要和运维协作，这也是我们一直反对在容器云平台做流水线做 CICD 的一个原因。运维平台、运维工具、运维方法、运维流程、运维组织和运维思想的首先建立是必要的。做好运维，将会更好的支撑敏捷研发和持续部署发布，真正实现敏捷。
三、DevOps 建设思路
对 DevOps 的错误理解之一就是一个人什么都干。要提升软件工程效率，就必须实现分工。这和社会生产发展规律也是一样的。只有分工才能提升效率。因此 DevOps 建设首先就需要考虑职责分工。从 SRE 实践我们看到，DevOps 建设要关注运维，运维要分层，职责要轮换，体系要简单，追求矛盾的统一。用软件工程化的方式建设软件基础设施来支撑产品研发，提升研发效率。
（1）DevOps 建设重点在运维
Google SRE 虽然也做运维工具和运维组件的研发，但本质上是运维团队。只有运维团队把软硬件基础设施准备好了，应用或产品开发团队才能更好的享受软硬件基础设施所带来的便利。研发的敏捷性往往是由运维的稳定性驱动的。只有持续构建部署稳定可靠的应用服务，研发才能真正地实现敏捷迭代，而不是陷于应对繁琐的基础设施工作中不能自拔。这和我们习惯的关注 CICD 的 DevOps 理念是不同的。只有从整体上考虑 DevOps，从顶层设计考虑 DevOps，才能把 DevOps 建设好。开发和运维的工作量基本上是 2：8，完成开发，应用或产品的生命周期才刚刚开始不久，更长生命阶段是在运维和完善。因此软硬件基础设施的建设和完备是产品研发的基础和巨人的肩膀。
（2）软硬件基础设施运维分层
软硬件基础设施内容众多，这也是 DevOps 建设比较困难的一个地方。从 SRE 来看，其通过团队职责的细化实现了基础设施的分层运维。这涉及到组织架构的优化。和我们传统一个团队什么都运维的思路是不同的。通过专业化的分工使运营效率大幅提升。而通过提供服务化的方式又可以和其他团队平滑合作。
DevOps 建设中运维内容我们可以简单的划分为：硬件基础设施（服务器、存储、网络、DataCenter、机柜、机架……）资源、软件基础设施和通用工具（OS、通信、认证、权限、监控、日志、调度、配置、消息组件……）、数据平台和数据工具（数据库、大数据平台、机器学习平台……）、应用支撑平台（虚拟化、云管、PaaS、服务治理平台、负载均衡器、中台服务……）、业务应用和业务系统等。业务应用和业务系统在这些软硬件基础设施之上部署运行，由各个运维团队来进行日常维护和管理。同时这些团队需要完成日常运维工作所需的工具开发、自动化流程等。
我们可以很容易的看到，软件产品的研发需要考虑的内容很多。如果没有运维的经验，软件产品也很难设计好。比如组件的部署方式、部署位置、部署数量等等。因此要设计研发出真正好的软件产品，需要具备相应的运维意识和能力。
（3）职责轮换，促进理解和提升技能
这里职责轮换包含两个循环：一是 Dev 和 Ops 职责的轮换，二是 Ops 内部开发和运维人员的职责互换，这部分其实就是 google 的 SRE。开发和运维角色互换，更有助于开发理解运维工作，而运维的经验也让开发人员更关注部署、运维的细节，避免开发导致的部署和运行缺陷。
很多开发人员从来没做过运维，没有运维经验和体会，不理解应用服务和产品的稳定性运维运营问题，所以也很难设计出满足稳定性的产品和应用来，在稳定性、客户体验等众多方面都达不到要求，也使很多开发人员难以虚心求教，反而自以为是，带来大量的产品问题。
以 Ops 内部小循环带动 DevOps 大循环，真正理解软件工程生命周期过程，减少设计和编码缺陷，提升系统稳定性和用户体验，这才是建设 DevOps 的意义，也是软件人员快速成长的捷径。不过这样的方式无疑改变了传统的项目管理方式和组织管理方式。组织改进最严重的阻碍是来自于组织文化、领导想法和领导魄力。打破传统守旧的文化和思维体系，可能难于上青天。不过若要获得成功，就必须在整个组织里培养一种生机型的文化和组织战略。
（4）保持简单
软件工程的一个关键思想是保持简单。把复杂的系统简化，是一个合格的软件架构师、工程师必须考虑的问题。软件系统本质上是动态的和不稳定的。需求在不断的变化，软件系统在不断的改进和调整。唯一不变的是变化。DevOps 的工作就是在系统灵活性和稳定性之间选择平衡，在敏捷研发部署和系统稳定运行之间达成一致。最简单的流程和步骤将会是最高效的。软件的简单性是稳定性的前提。
大道至简，保持简单就需要从软件工程的各个阶段各个层次以最简单的方式解决最复杂的问题。至简源码、最短链路、最小依赖、自动化、自服务等首先软件工程和业务系统的简单化，从而实现可预期的稳定性。
1. 最简化源码
删除不需要的源码和注释，使代码最简化。我们知道添加到项目中的每行代码都可能引入新的缺陷和错误。敢于剪除多余的冗枝，绿植往往会长的更好。没有什么可以去掉的时候，往往才是最好的、最合适的。所以在编码阶段就要敢于删除冗余不用的代码，不要想着某一天还会用到。不删除，基本上这些代码永远也用不上了。
2. 最短链路
我把最短链路作为微服务设计的一个原则。一方面是效率考虑，一方面也是简单化。避免复杂链路的容易出现的循环调用。最短链路在 DevOps 建设中也可以作为一个原则，指导研发人员服务的设计和系统架构。
3. 最小化依赖
最短链路原则会减少服务、系统之间的依赖关系。但不仅仅是服务之间。其实我们在讨论容器云平台设计时也说过，引入的不必要组件导致了整个平台的复杂化、资源浪费和不稳定。
4. 自动化
自动化是 DevOps 建设的基本要求之一。自动化才能消除众多的人工重复性操作，从而减少人为错误，提升工作效率。最简单的例子，我们有数百台容器节点，每三个月需要按要求修改密码。如果人来做，是很大的工作量，而自动化，几分钟就可以按规则修改完毕。Google SRE 就是通过软件工程的方法实现自动化运维，把人工运维工作降到最低。
5. 自服务
首先团队需要实现自给自足。这在团队职责划分、团队服务能力抽象整合、标准化信息服务 API 等建设都需要有合理的规划和设计。SRE 开发工具、自动化流程、平台等一方面实现自身运维运营需求，另一方面支撑产品研发团队可以自己掌控和执行自己的发布流程。
四、总结
我们可以把 SRE 看作是 DevOps 理论的一项具体实践。SRE 的很多方法和做法是值得我们思考和尝试的。同时也不能完全照搬 SRE 的实践，不能把它当作最佳实践神化。SRE 以软件工程化、系统化思路是用错误预算来解决开发运维之间的协作问题，有其合理性，也有局限性。不过其关注运维、限制 SRE 运维总时间投入以确保研发能力、保持简单化、运维分层等思想是非常值得吸收的实践经验，值得我们在建设 DevOps 中思考和采用。
