# SRE过气了吗

LLMS 索引： [llms.txt](/llms.txt)

---

> 原作者：瑞典马工 · [微信公众号转载页](https://mp.weixin.qq.com/s/pyub-KOpUlqB706k7f11Lw)

SRE 至今还没有一个被广泛接受的中文名，但是很可惜，这个岗位在业界已经被抛弃了。

Site Reliability Engineer 因为来自于Google，一直听起来很酷，实际上，它无非就是指代会写代码的运维（Ops）。不论在中国还是欧美，大量的 SRE 都是运维ops或者系统管理员sysadmin换张名片而已。

SRE 仍然割裂了开发和运维。读过谷歌那几本 SRE 书的朋友可以明显的看出: 谷歌仍然没有解决 ops 不懂代码进而无法独立解决故障的根本缺陷。根据业界经验，70%的故障都是变更引起的，而变更大部分来自于开发修改代码或者配置。不参与代码维护的工程师，不管是戴运维帽子还是 SRE 帽子，天然的会具备劣势。

和 SRE 相对的理念是 DevOps。这个理念的指导下，有一个全功能团队负责自己产品的所有工程工作，包括但不限于: 需求分析，概念验证，架构设计，编码实现，测试，安全，部署，维护，合并分拆，到下线。系统的可靠性值班由团队成员轮流承担。这种团队一般不大，6-12人左右，用亚马逊的说法就是两个披萨能喂饱全团队。同时这个团队具备工程上的自主性（autonomy），能够选择自己需要的编程语言，框架，数据库和中间件。

全功能团队一般不严格分工，而是要求所有人都参与产品的开发和维护。笔者的几个团队都假定任意一个同事可以工作于任意一个ticket，不管ticket是关于业务逻辑修改，端到端测试，数据库升级，网络性能排故或者MQ性能优化。

开发任务决定了此类团队主要由developers 组成。维护任务则迫使开发者不得不去熟悉基础设施(infrastructure)。众所周知，并非所有开发者熟练掌握 infra 知识。这就带来了一个问题: 怎么降低 infra 的管理成本使得一个普通开发者也能胜任其管理工作？

这个问题展开来说很长，此处简单的分享下笔者的经验。

0\. 上云。上云之后，大量的基础设施管理工作，比如换盘，扩容，加秘等，都委托给了更专业的云厂商。

1\. 使用infra as code技术，把基础设施转化为代码，和业务代码统一由git管理。

2\. 使用gitops，把基础设施和业务代码的修改视作等同，从同一套CI/CD pipeline部署。

3\. 使用云原生架构。云原生架构定义不清，但是有一点是确定的: 云原生架构能够自动处理底层虚拟机的宕机。这样就大量的降低了团队的运维工作。有关这个话题，可以参考我的朋友王明松写的《云原生王四条》。

4\. 使用PaaS。传统的运维团队有很大一部分工作是维护系统使用的开源中间件。这部分工作无聊而且风险很大，很容易出现一人离职无人接手的尴尬状况。如果团队使用托管的PaaS，不管是 AWS 的 Kinesis，还是 Aiven 的托管卡夫卡，还是观测云的可观测系统，可以免去团队的运维风险，并且降低总体拥有成本（TCO）。这个对低人才密度的团队来说尤其有效，当然对于招了一堆清华硕士毕业生又不知道用来干嘛的互联网大厂，另说。

始于 2009 年比利时的 DevOps 方法论有十几年历史了，推行的不太普及。一个重要原因就是上文所述的开发者难以胜任基础设施的运维工作。但是近些年来，云计算把基础设施标准化，基于标准硬件发展了一系列的良好实践（goid practices），已经彻底的改观了基础设施的管理工作。以笔者本人为例，笔者一直是开发者，现在一家金融科技公司帮助 30 几个全功能团队管理 500 个数据库实例，毫无压力。实际上，我们整个公司没有 DBA ，也没有专职 SRE。

综上所述，SRE 这个岗位划分方法论，实际上已经过时了。保留 SRE 实际上在阻碍全功能团队对工程负全部责任，会产生极大的沟通成本，引发大量的甩锅和无效自我保护。

如果您的组织还在设置招聘SRE，建议您再考虑下。如果您还在从事 SRE 岗位，建议您早做打算。时代的浪潮是难以抗拒的。