SRE 和 Devops 的相同与不同

有老友问 SRE 和 Devops 有什么不同，把理解简单整理一下。

SRE：

在 SRE 之前，运维/系统管理员通常关注的是服务器、数据库、网络的资源供给和可靠性，同时这些的可靠性本身也难有掌控力，比如服务器总数会有一定概率宕机、网络总是不可避免出现丢包或中断，运维会提出一个基础设施 SLA，实际上即使达到了 SLA 还是可能对业务有巨大的不可接受影响；同时传统运维更倾向通过人工操作或少量自动化来 case by casy 保证解决碰到的故障和问题；传统运维只关注自身领域的技术或可靠性，如 DBA、服务器、网络、SA、业务运维只关注应用、微服务、基础组件等，没人对业务产品可靠性最终负责。

而 SRE 是以业务产品的可靠性为目的，通过工程技术来保障。SRE 工程师懂得软件工程，软件开发，高可靠的知识和技术，对基础设施、软硬件环境有深入的理解和掌控。有风险意识，度量，管控。能对可靠性结果负责。要求 SRE 在监控、可靠性度量、风险管控、应急协同、可靠性设计、性能等方面都有成体系的打法，能够独立地承担起业务的可靠性。

Devops：

在实施 DevOps 之前，开发和运维团队是两个独立的团队，每个团队有各自职责，两个团队之间强依赖但弱协作，目标不同信息不通畅，中间有巨大的空白区域，造成效率不高和经常性出现问题。导致影响产品质量、稳定性和团队效率，从而最终影响用户体验和公司效益。

Devops 可以分为几个层次的理解：

L1：在部分人眼里是指 CI/CD/CT

L2：运维高度自动化，Dev 通过 Ops 开发的系统进行运维操作

L3：一种文化理念，Dev 和 Ops 深度合作，Dev 不仅写业务逻辑，也懂运维的部分稳定性、性能、高可用、有一些基础设施知识，Ops 不仅做基础设施运维，也懂得业务的架构、技术栈、甚至部分逻辑，能再公共/基础组件上深入业务的技术，甚至理解业务的计算框架，知道其中的高可用、可靠性的优缺点，在理解的基础上能提出更有效的保障方案

L1 分析：

早期部署是运维负责为主，CI/CD 能把运维从发布流程中抽离出来做成自动化流水线，从而提升发布过程的效率。同时因为发布是自动化的，发布可靠性也得到提高。此层级目标是最大程度提升交付效率和软件质量，所以 DevOps 里面包括了自动化的编译、打包、发布、自动化测试、较高的覆盖率、及在不同环境的验证，把 QA 也纳入了发布流程。尽快把代码转为用户能用的服务，实现业务价值。

L2 分析：

L2 是自动化发布的延伸，把更多运维操作通过系统平台交付给业务研发团队。运维团队增强系统开发的能力，开发运维系统让业务研发同学来使用，减少直接找运维人员，也减少运维人员的手工上机操作，由开发人员而非运维人员通过运维系统来完成更多的运维工作。运维产品是在充分理解运维技术和业务技术栈、业务场景的基础上提炼出来，运维人员更多精力转向运维系统的开发。

L3 分析：

第三层的 DevOps 中，大家的共同目标是更加高效更高质量地把业务产品交付给用户，尽快实现业务价值。在技术上的 Dev 和 Ops 都对对方的技术领域有一定的了解，能把中间的技术空白地带补齐。也能在互相沟通互相理解，对业务技术无死角分析的基础上互相促进、互相提要求、互相帮助，共同目标是提升运维的效率和可靠性。到这个阶段只是分工不同，技术深度广度都有非常高的程度了。

SRE 与 Devops 相同点：

如果要讲相同点，在 Devops L3 层上和 SRE 是很类似的。都强调对技术领域的深度广度掌控能力，对工作目标都包含可靠性。DevOps 和 SRE 都倡导减少运维中的琐事，提升自动化，提升稳定性和质量。《google SRE》一书也提到 SRE 是 Devops 理念在 Google 的一种实践。

SRE 与 Devops 不同点：

如果说有不同点，可能有 2 点：

SRE 有更强调稳定性/可靠性，而在 Devops 更强调协作；也可以说一个是过程，一个是结果。也可以这么理解，Devops 是强调过程的效率和无缝的协作（有一些新的提法 CI/CD/CT/CO，也有 DevOpsSec 等，把安全、QA 也纳入流程），而 SRE 更强调可靠性稳定性结果，当然可靠性也是 Devops 的目的之一。

一般 SRE 可能独立承担业务的可靠性，拥有更强的话语权，而 Devops 并没有明显区别或强调可靠性的职责分工。

总体上，不应该过度强调二者的区别和不同，更应该强调共同协作共同目标。交付效率、服务可靠性、运维效率、产品质量应该都是产品开发、基础团队、SRE/Ops 大家追求的共同目标。