关于数据库:我们还需要-SRE-吗

在「一文讲透研发，SRE，运维，DevOps 的区别」里，咱们讲了几大工种的区别，这篇咱们重点讲一下 SRE (Site Reliability Engineering)。

SRE 的衰亡

SRE 最早起源于 2003，由 Google 提出。SRE 既是一种理念，也是一套围绕这个理念的实际，由这个实际也诞生了一个新的工种，同样叫 SRE。SRE 的衰亡有多方面的起因：

• 地利 – 互联网在线服务大规模遍及。一边服务复杂度极具晋升，一边稳定性的要求越来越高。
• 天时 – 由 Google 带头的一批头部科技公司背书，尤其是 2016 年 Google SRE 团队撰写的 Site Reliability Engineering: How Google Runs Production Systems 堪称行业里最经典的著述。
• 人和 – Ops 们须要找新的前途，因为云服务等基础设施的欠缺毁灭了传统运维 (IT Ops) 的大量工作。

SRE 和 Dev 间的生产关系

对于 SRE 和 Dev 之间的关系，网上读到的一个精彩形容：

再具体一点，咱们能够拿 DORA 的四大外围指标来看：

1. Deployment frequency (部署频率）
2. Lead Time for Changes (从代码提交到最终公布耗时）
3. Change Failure Rate (公布失败率）
4. Time to Restore Services (服务复原工夫)

前两个指标指向的是 Velocity (速度)，后两个指向的是 Stability (稳定性)。Dev 的指标是优化迭代速度，而 SRE 的指标则是优化稳定性。DORA 报告里提到的精英团队能做到即快又稳，但这也是相对而言的。毕竟大家都晓得，变更是造成生产故障的第一大根因，这也是为什么许多团队会定下周五不公布的规矩。每一个研发组织还是要在 Velocity 和 Stability 之间做衡量，这也天然导致负责 Velocity 的 Dev 和盯着 Stability 的 SRE 团队间产生摩擦。正好前不久 Google SRE 团队又发表了一篇文章 How Google SRE And Developers Collaborate 着重谈了这点：

SRE 和 Dev 之间的生产关系，顶层是 Peer，执行层则是 Funding，SRE 的 HC 是由 Dev 团队提供的。具体几点：

1. Funded by Dev
2. Strategic Partnership
3. Dev Ownership
4. Joint Partnership
5. Shared Endeavor

总体而言在 SRE 和 Dev 的关系里，Dev 还是占主导地位。在 Google 的组织架构里，尽管 SRE 是一条独立的汇报线，但 SRE 的日常工作是嵌入在 Dev 团队中的。那为什么不间接把 SRE 归并到 Dev 组织中，而要独自设一条线呢：

1. 更好地制衡 Dev，Dev 无论是从本身还是因为产品经理的压力总是想着尽快上线性能，而漠视长期的服务稳定性和可运维性建设。把 SRE 独立进去能够起到更好的监督作用。
2. SRE 组织外面也有两局部，一部分是嵌入在 Dev 团队中的，叫作业务 SRE，同时也有横向的 (在 Google 里叫 Horizontal)，来制订整体的标准，提供通用的基础设施和工具。
3. SRE 的工作内容和 Dev 还是有显著差异，比方负责稳定性就要随时应急，须要寰球 7 x 24 笼罩。Google SRE 团队通常会散布在美国和欧洲，而许多 Dev 团队都只须要在一个时区。

其余公司也会采纳不同于 Google 的组织架构，比方采纳双线汇报，SRE 既汇报给 SRE 的负责人，同时又汇报给 Dev 负责人。有些公司的 SRE 会有自主 HC，并不需要 Dev 团队的赞助。不同的架构取决于组织心愿 SRE 和 Dev 走得有多近，过近达不到制衡的目标，而过远则会造成更多的协同摩擦。但两个部门的存在，摩擦是很难防止的。以下是一个常见的 Dev 和 SRE 关系倒退工夫线:

Dev: 运维压力太大，还要做业务需要，开发团队忙不过来了，看上周又出了个 P1 故障，还是找个 SRE 团队来帮忙吧。

SRE: 这些 xx 监控指标先加一下，咱们看看当初服务的稳定性再说。

(过了一段时间)

Dev: 咱们弄了一些，但业务压力太大了，咱们切实不行了，你们连忙来吧。

SRE: 好吧。

(又过了一段时间)

Dev: SRE 如同也只会接个告警，排查还是要咱们上。还老是卡上线，每做一个性能，都要加这加那指标。原本上周的公布又被 SRE 叫停了。

SRE: Dev 开发性能都不测试，一上线各种问题，让咱们中午起来擦屁股，上周又出了一个 P1 故障，这个月 SLA 曾经破线了，不能让 Dev 公布了。

(开始逐步相互看不惯对方，要么将就相处，要么一拍两散)

即便是 SRE 届的标杆 Google，SRE 和 Dev 都产生过炒对方鱿鱼的事件。在 Google 外部，每当生产事变产生后，都会写 postmortem。有时 SRE 和 Dev 在离别的时候，也会以 postmortem 的形式写离别信，这总会引起大家的围观，因为每个人对于 SRE 和 Dev 间的相爱相杀都或多或少地感同身受吧。

SRE 的身份认同

因为 SRE 在组织架构中的模糊性，导致 SRE 团队的本身定位也始终是个问题。

首先，许多组织设立的 SRE 团队只是把原来的 Ops 团队换了一个高大上的名字，这显然会造成部门内外的认知困扰。

而在真正的 SRE 团队外部，业务 SRE 更多是参加到 Dev 团队的我的项目里。尽管不属于 Dev 团队，却又扮演着不讨好的看门人角色，以及负责压力更大的线上稳定性工作。横向 SRE 更多的工夫则花在基础设施建设上，其所做的工作又根本和 Infra Dev 无异。后面提到的 Google SRE 文章里还提到 Meaningful Work：

Dev 通常更容易找到 Meaningful Work，因为用户感知到的性能次要由 Dev 来开发，SRE 则须要在 Dev 圈好的地之外再去挖掘机会，难度更高。

SRE 们往往负重前行，但相比 Dev 们更短少鲜花和掌声。优良的 SRE 容易散失，毕竟一个具备研发能力的 SRE，能够转成 Dev。在 Google，从 SRE 转成 Dev 的数量是要远远多于 Dev 转成 SRE 的。

SRE 还被须要吗

来到题目里的疑难，首先 SRE 承当的职能还是会长期存在，然而只有 SRE 和 Dev 间的生产关系跳不出 Google 当初所设计的领域，SRE 的倒退就有局限性。咱们总是听到 Dev 埋怨 SRE 只会接一个告警，问题最终还是要交给 Dev 来看。很大水平上这是组织设计的锅，因为 SRE 和 Dev 不是同一个团队，SRE 关注的 Stability 往往又站在 Dev 的 Velocity 对立面，而产品则还是由 Dev 团队 own。这也是为什么当初更多的团队抉择纯 DevOps，只有 DevOps 一个工种，本人 Dev 本人 Ops，这样没有协同的损耗，从激励机制上也是更正当的。

当年互联网大潮开启，从单机利用走向互联网服务。疾速迭代，海量并发，时刻在线，这些互联网业务独有的个性对于服务的稳定性带来了微小挑战。那时 Dev 忙着上线业务，Ops 又心愿转型，而行业又短少体系化的伎俩来解决稳定性问题，SRE 的呈现恰好补了位。通过这些年的打磨，解决服务稳定性的方法论和最佳实际曾经成型，云基础设施保障了底层的稳定性，各种 SaaS 服务，开源产品也大大降低了 Dev 本人做 Ops 的门槛，这个时候 SRE 团队和 Dev 团队之间的组织摩擦就逐步回升为了主要矛盾。过来 20 多年，行业从没有 SRE，到拥抱 SRE，再到去 SRE：

这个过程和中台演进也颇为类似，前些年是建中台，这两年开始去中台，SRE 就相似提供零碎稳定性的中台职能。去掉 SRE，并不是放弃稳定性，而是看到 DevOps 自身能够在保障系统绝对稳固的状况下更快地进行业务迭代。当靠 DevOps 团队也能做到 99.9% 的 SLA (Service Level Agreement) 时，许多团队便不会再引入 SRE，以就义迭代速度的代价换取晋升 SLA 到 99.99%。

SRE 留下的财产

即便未来 SRE 景色不再，但整个 SRE 周期也留下了一堆的财产。

首先 Google 想出了 SRE 这个好名字，Site 代表规模，Reliability 代表稳定性，Engineering 代表工程，正好形容了 SRE 是用工程的办法来解决规模化后的稳定性问题。

因为 SRE 而诞生的 SLI (Service Level Indicator), SLO (Service Level Objective), SLA (Service Level Agreement) 定义了稳定性工作的北极星指标；Blameless, Postmortem 的文化也是通过 SRE 和 Dev 的一直磨合成为了业界共识；Logs, metrics and traces 三大件，Chaos Engineering 这些也都是由 SRE 推动成为了最佳实际，在此之上也建设起了 Datadog, Elastic 这样的商业帝国。

其次 SRE 帮忙传统 Ops 实现了转型，如果没有 SRE 作为过渡，Ops 很难间接转型为 Dev，是 SRE 让 Dev 和 Ops 能够 meet in the middle。而通过 10 多年的 battle，SRE 最终焚烧了本人，消融了 Dev，再一起合体成了 DevOps。

船停在码头是最平安的，但那不是建造他的目标。辞别 SRE，也辞别 Dev，间接挂上 DevOps 的旗子，不必再争执明天是否能够出海，这切实是太好了。

Ship it

💡 你能够拜访官网：https://www.bytebase.com/，收费注册云账号，立刻体验 Bytebase。