从SRE看DevOps建设

Posted 2021-04-23 技术思维创新

       SRE就是在用软件工程的思维和方法论完成以前由系统管理员团队手动完成的工作。SRE的职责是运维一个服务，该服务由一些相关的系统组件组成，为最终用户（可以是内部用户也可以是外部用户）提供服务。SRE的终极责任是确保该服务可以正常运转。为达成这一目标，SRE需要完成开发监控系统、规划资源容量、处理紧急事件、跟踪修复事故根源等。SRE对重复性、手工性的操作有天然的排斥感，并有足够的技术能力快速开发出软件系统以替代手工操作。

DevOps的核心思想是协调开发Dev和运维Ops关系，使之能有效沟通和协作，通过工具链、流水线高效衔接，持续反馈，实现研发Dev到运维Ops流程的持续优化和完善。

一、 理解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建设要关注运维，运维要分层，职责要轮换，体系要简单，追求矛盾的统一。用软件工程化的方式建设软件基础设施来支撑产品研发，提升研发效率。

（一） DevOps建设重点在运维

Google SRE虽然也做运维工具和运维组件的研发，但本质上是运维团队。只有运维团队把软硬件基础设施准备好了，应用或产品开发团队才能更好的享受软硬件基础设施所带来的便利。研发的敏捷性往往是由运维的稳定性驱动的。只有持续构建部署稳定可靠的应用服务，研发才能真正地实现敏捷迭代，而不是陷于应对繁琐的基础设施工作中不能自拔。这和我们习惯的关注CICD的DevOps理念是不同的。只有从整体上考虑DevOps，从顶层设计考虑DevOps，才能把DevOps建设好。开发和运维的工作量基本上是2：8，完成开发，应用或产品的生命周期才刚刚开始不久，更长生命阶段是在运维和完善。因此软硬件基础设施的建设和完备是产品研发的基础和巨人的肩膀。

（二） 软硬件基础设施运维分层

软硬件基础设施内容众多，这也是DevOps建设比较困难的一个地方。从SRE来看，其通过团队职责的细化实现了基础设施的分层运维。这涉及到组织架构的优化。和我们传统一个团队什么都运维的思路是不同的。通过专业化的分工使运营效率大幅提升。而通过提供服务化的方式又可以和其他团队平滑合作。

DevOps建设中运维内容我们可以简单的划分为：硬件基础设施（服务器、存储、网络、DataCenter、机柜、机架……）资源、软件基础设施和通用工具（OS、通信、认证、权限、监控、日志、调度、配置、消息组件……）、数据平台和数据工具（数据库、大数据平台、机器学习平台……）、应用支撑平台（虚拟化、云管、PaaS、服务治理平台、负载均衡器、中台服务……）、业务应用和业务系统等。业务应用和业务系统在这些软硬件基础设施之上部署运行，由各个运维团队来进行日常维护和管理。同时这些团队需要完成日常运维工作所需的工具开发、自动化流程等。

                          

我们可以很容易的看到，软件产品的研发需要考虑的内容很多。如果没有运维的经验，软件产品也很难设计好。比如组件的部署方式、部署位置、部署数量等等。因此要设计研发出真正好的软件产品，需要具备相应的运维意识和能力。

（三） 职责轮换，促进理解和提升技能

这里职责轮换包含两个循环：一是Dev和Ops职责的轮换，二是Ops内部开发和运维人员的职责互换，这部分其实就是google的SRE。开发和运维角色互换，更有助于开发理解运维工作，而运维的经验也让开发人员更关注部署、运维的细节，避免开发导致的部署和运行缺陷。

很多开发人员从来没做过运维，没有运维经验和体会，不理解应用服务和产品的稳定性运维运营问题，所以也很难设计出满足稳定性的产品和应用来，在稳定性、客户体验等众多方面都达不到要求，也使很多开发人员难以虚心求教，反而自以为是，带来大量的产品问题。

以Ops内部小循环带动DevOps大循环，真正理解软件工程生命周期过程，减少设计和编码缺陷，提升系统稳定性和用户体验，这才是建设DevOps的意义，也是软件人员快速成长的捷径。不过这样的方式无疑改变了传统的项目管理方式和组织管理方式。组织改进最严重的阻碍是来自于组织文化、领导想法和领导魄力。打破传统守旧的文化和思维体系，可能难于上青天。不过若要获得成功，就必须在整个组织里培养一种生机型的文化和组织战略。

（四） 保持简单

软件工程的一个关键思想是保持简单。把复杂的系统简化，是一个合格的软件架构师、工程师必须考虑的问题。软件系统本质上是动态的和不稳定的。需求在不断的变化，软件系统在不断的改进和调整。唯一不变的是变化。DevOps的工作就是在系统灵活性和稳定性之间选择平衡，在敏捷研发部署和系统稳定运行之间达成一致。最简单的流程和步骤将会是最高效的。软件的简单性是稳定性的前提。

大道至简，保持简单就需要从软件工程的各个阶段各个层次以最简单的方式解决最复杂的问题。至简源码、最短链路、最小依赖、自动化、自服务等首先软件工程和业务系统的简单化，从而实现可预期的稳定性。

1. 最简化源码

删除不需要的源码和注释，使代码最简化。我们知道添加到项目中的每行代码都可能引入新的缺陷和错误。敢于剪除多余的冗枝，绿植往往会长的更好。没有什么可以去掉的时候，往往才是最好的、最合适的。所以在编码阶段就要敢于删除冗余不用的代码，不要想着某一天还会用到。不删除，基本上这些代码永远也用不上了。

2. 最短链路

我把最短链路作为微服务设计的一个原则。一方面是效率考虑，一方面也是简单化。避免复杂链路的容易出现的循环调用。最短链路在DevOps建设中也可以作为一个原则，指导研发人员服务的设计和系统架构。

3. 最小化依赖

最短链路原则会减少服务、系统之间的依赖关系。但不仅仅是服务之间。其实我们在讨论容器云平台设计时也说过，引入的不必要组件导致了整个平台的复杂化、资源浪费和不稳定。

4. 自动化

自动化是DevOps建设的基本要求之一。自动化才能消除众多的人工重复性操作，从而减少人为错误，提升工作效率。最简单的例子，我们有数百台容器节点，每三个月需要按要求修改密码。如果人来做，是很大的工作量，而自动化，几分钟就可以按规则修改完毕。Google SRE就是通过软件工程的方法实现自动化运维，把人工运维工作降到最低。

5. 自服务

首先团队需要实现自给自足。这在团队职责划分、团队服务能力抽象整合、标准化信息服务API等建设都需要有合理的规划和设计。SRE开发工具、自动化流程、平台等一方面实现自身运维运营需求，另一方面支撑产品研发团队可以自己掌控和执行自己的发布流程。

四、 总结

我们可以把SRE看作是DevOps理论的一项具体实践。SRE的很多方法和做法是值得我们思考和尝试的。同时也不能完全照搬SRE的实践，不能把它当作最佳实践神化。SRE以软件工程化、系统化思路是用错误预算来解决开发运维之间的协作问题，有其合理性，也有局限性。不过其关注运维、限制SRE运维总时间投入以确保研发能力、保持简单化、运维分层等思想是非常值得吸收的实践经验，值得我们在建设DevOps中思考和采用。