1.3 选择SRE

在实际的环境中，一个组织的运维方式是选择DevOps还是选择SRE很多时候和组织的规模、团队成员构成等因素息息相关。

回到之前讲的 DevOps 流行背景，有很大的一块是 Chrome 浏览器发展带来的Node.js技术。JavaScript的广泛流行带来了一个全栈工程师的概念，既然是全栈工程师，应该可以同时担当运维角色。全栈工程师对自己的代码很了解，部署环境等都不是问题，线上运维就是做个环境将代码运行起来的事情。这种做法在团队较小的时候非常好用，而且效率高、成本低。但是当团队较大的时候，应用这种做法往往会遇到一些问题。当然也可以举反例，如团队中有很厉害的架构师，可以将所有组件的规范和流程都处理得很好。如果一个团队的业务组件都很规范、流程不是很复杂、所有开发团队都清楚地知道相互关系，并且开发团队都具备全栈开发能力的时候，DevOps的执行往往会很好。现实中有这样的团队，但是大多数以Startup公司为主。更多的公司往往是已经有了开发团队和运维团队，它们面临的多是选择DevOps还是选择SRE的问题。

选择DevOps的第一反应是先将CI/CD管道线做好，以便能自动化发布优化过的流程，运维团队做的事情不多了，基本就可以砍掉了。这个选择不一定有问题，尤其是在当前很多的公司都使用云服务器后，运维团队的处境其实很尴尬。原来需要运维团队搭建数据库HA、做负载均衡KeepAlive等，现在都不需要了，开发团队都能自己发布了，只要做好相关的CI/CD等平台，就不需要传统运维了。

在现实情况中DevOps可能会被很多人推崇（个人感觉还是因为开发团队在组织内部有较强的话语权，所以在宣传上会有较大的优势），但是不一定适合所有的团队。在我遇到的场景中，DevOps能执行的场景还是相对少的，尤其是当我们的团队需要运维的平台高度复杂而且需要深入底层时就不能使用 DevOps。可能我们的开发团队对某个模块或软件有深入的开发和发布能力，但是因为系统的复杂度太高，根本没有办法完整地控制住。例如，在芯片制造过程中，CPU设计工程师可以设计芯片，但是他能自己从头开始直接做，能完成从 CPU 芯片设计到生产的完整过程吗？这显然是一件很困难的事情，更多情况下还是需要芯片生产工艺工程师帮助 CPU 设计工程师进行相关的调整，最终完成CPU的生产。

SRE 从某种程度上来说是为了适应大型复杂团队中的运维需求而诞生的。SRE清楚所有开发的情况，能和开发团队聊算法，能结合实际情况调整线上相关运维策略，让开发团队聚焦各自的需求开发。

要知道在大部分公司中，很多开发团队都在Windows上做Java开发，如果真的让他们去服务器做Linux环境，不是不能做，但真的很低效。这就是传统运维存在的意义。每天开发团队的手头上都堆着大量的业务需求，想让开发团队在完成业务需求的同时针对线上做运维相关的工具，在国内的公司，很多时候这是不现实的。另外开发团队的人力成本相对较高，用相对较高的人力成本去做线上运维的事情，在成本上也不是最优的。反过来讲，经过多年的培养，国内的运维团队大部分都具备了Python 等相关开发技能，在不让运维团队进行复杂开发的情况下，只是了解某个算法的技术原理，懂得开发团队的“黑话”不是一件困难的事情。运维团队在日常的工作中，很多时候都是“久病成良医”，对线上各种问题的解决都有丰富的经验，有时候甚至开发过对应的工具，在能力上已经能帮助开发团队对大部分稳定性需求进行兜底，唯一欠缺的是一个转身的契机。在大型互联网公司中，因为业务组织的复杂度和健全度，SRE有更高的落地可能性。因为这个转变一方面符合成本要求（不可否认的是在国内公司里大部分情况下开发成本比运维成本高），另一方面符合运维能力发展趋势。