前述

一直有朋友和木子说，你这博客标题是“ DevOps 文化 & SRE 实战分享平台”，但前面分享的都似乎与DevOps&SRE关系不大，能不能详细聊聊DevOps&SRE？于是便有了这篇文章。正如同“每个故事里都有一个胖子”一样，在每个开发(Dev)和运维(Ops)心中都应该存在一个DevOps&SRE的梦。有同学可以会问为什么不是DevOps，而是SRE了？DevOps和SRE是目前相对热门的开发、运营文化及技术实现，两者之间有着很高的相似度，如下图所示，两者是一个存在相互重叠的现行趋势学科，是一个多层级的复合型人才需求（根据企业的不同定位及需求，木子觉得SRE可以更大概论的扩充到DevOps全域）。在工业4.0的时代，类复合型人才更加紧缺，怎么使用DevOps的思维快速推动工业4.0智能智造的发展，也是一个值得我们思考的问题。

早期有很多同学会把SRE视为和DevOps是两种不同的实践方式，必须在其中选择一种方式来执行，其实这个是错误的。如果把DevOps比作是水果，SRE比作是香蕉，那么结果就是香蕉是一种水果，但水果并不是香蕉。请永远记住：

 SRE is a DevOps（香蕉是一种水果）
DevOps is NOT a SRE（水果不是香蕉）  

DevOps 并不是一个工作职称，SRE才是。就像我们去菜市场买菜一样，我们不会和老板说我要买青菜，而会和老板说我需要买上海青或者小白菜一样。
如果要用软件工程师的思维来总结DevOps与SRE之间的关系，那就是：

 class SRE implements DevOps  

当然你会发现在一些招聘平台上，不乏一些大厂在招聘DevOps工程师或者SRE工程师，这就是中国特色，国内一些企业从DevOps的文化层级抽象出了DevOps工程师这个职位。
那么到底SRE是什么？SRE和DevOps有什么相同与不同点了？早在2018年初的时候，Google工程师就在一系列的视频中尝试去解答这些问题，希望能够有效减少社区之间的意见分歧，有兴趣的同学可以去油管查找对应视频。而对于两者之间的区别，我们可以通过五个DevOps理论与SRE实践来进行说明：

站在今天，回看2013年自己在DevOps的实践之路，其实在当时木子不仅仅只是关注于DevOps，更多的是希望能够帮助企业实现数字化转型，只是当时的情况不允许。就如同4G不出抖音必挂是一个道理，每一个物类的产生，都必须有其自然生长的规律及周边环境的培育。得益于2013年的坚持，让我在2019年的SRE道路上可以走得更远、更长，虽然我还并不是一个完全合格的SRE，但至少为企业降低了上百万的运营成本，并在企业内部推动DevOps文化的建设，因而获得年度最佳技术创新奖。当然这并不是为了炫耀什么，而是想说DevOps文化体系的建设与SRE方法的实践，对于企业来说是一个不错的方向。因试图通过一篇文章能够说清楚DevOps及SRE（基本是不太可能的），所以篇幅可能有一些长，希望能够帮助各位同学找准自己未来的定位与方向。

什么是DevOps？

对于布道者而言，DevOps是一种文化和转型。对于工程师而言，DevOps是一套敏捷工具和技术集的实现。对于领导者而言，DevOps则是一种方法论。对于HR而言，DevOps只是一个职位。不同人对其定位不同，关键在于你自己怎么理解，站在什么位置去思考这个问题。本质上来说，DevOps是Development和Operations的一个组合词。它是一种文化理论的框架性输出，在整个产品或服务开发生命周期中，开发与运维或者说运营管理人员之间相互协作的价值体现。这种模式或方法可以改变人与人之间对于工作的看法，并重视团队内部技能的多样性。DevOps鼓励实施SOP流程标准化（其中我们会发现由于工业革命在互联网革命之前，所以很多现行的互联网标准或体系都是从工业体系中演变而来），以加快业务收益的回报率。其通过自动化“软件交付”和“架构变更”的流程，实现从计划、编码、构建、测试、发布、部署、运行、监控于一体的一站式解决方案，使得发布、构建、测试、软件能够更加地快捷、频繁和可靠。它是一套理论体系，但我们可以从其中抽象出其可实践的方法，即SRE。DevOps解决了原本开发和IT运营团队在传统模式下，分散的工作流之间频繁通信和持续实时协作所带来的高昂沟通成本、管理成本、低能低效。它通过组织工作流的方法用能够实施敏捷计划和实践（例如持续集成，持续交付和基础架构自动化）的多学科整合，取代原本孤立的开发和IT运营团队，以达到应用程序及服务的快速交付。

技术社区使用各种术语来描述DevOps的本质。它是一种文化，一种运动，一种哲学，一套实践以及使用工具软件来实现自动化和改进管理体系的方法论。不管您如何描述它，DevOps文化其中所融入的 敏捷开发 和精益思想，让我们更加注重服务和质量。既然我们说到它是一种文化，那它究竟是怎样的一种文化呢？其核心本质在于CALMS，而CAMLS分别代表5个英文单词的缩写。

• Culture
• Automation
• Lean & Agile
• Measuring everything
• Sharing

1）Culture[文化]

DevOps 是一种文化。传统开发模式每个阶段的人员，可能只专注自己的部分，但在整个产品成型的过程中，并不是只要把自己的部分做好就OK，是需要我们在每个阶段都适当沟通分工合作的，而DevOps就是为此而设计的。它真正的核心正是文化，强调建立人与人之间的合作、责任以及分享的精神文化。

2）Automation[自动化]

自动化是开发团队最重视的问题，而在整个产品生命周期中测试与部署也是造成delay不容忽视的一环，正是因为这种信息与部门之间的孤立，造成了产品层的delay。而自动化（CI、CD）则更好的解决了此问题，不但可以减少开发、测试、运维人员之间沟通落差造成的问题，更加可以在开发与应用整合上更加快捷、迅速。

3）Lean[精益开发]&Agile[敏捷开发]

正因为DevOps涵盖精益开发（Lean）和敏捷开发（Agile），因此我们完全可以套用精益开发的七大核心思想及敏捷开发的12个基本原则。 精益开发七大核心思想：

1. 消除浪费——Eliminate Waste
2. 建立质量——Build Quality In
3. 创造知识[增强学习]——Create Knowledage[Amplify Learning]
4. 延迟决策——Defer Commitment[Decide as Late as Possible]
5. 快速交付——Deliver Fast[Deliveras Fast as Possible]
6. 尊重他人[放权他人]——Respect People[Empower the Team]
7. 整体优化[着眼全局]——Optimize Whole[See the whole]

敏捷开发12个基本原则：

1. 最高优化级是客户的满意度。（Highest priority is customer satisfaction）
2. 欢迎更改需求。（Welcome changing requirements）
3. 持续交互。（Frequent delivery of software）
4. 业务人员与开发人员全天候合作。（Business people & developers cooperating daily）
5. 围绕有动力的人员构建项目。（Build projects around motivated people）
6. 面对面的沟通是最好的。（Face-to-face conversation is best）
7. 通过工作软件衡量进度。（Progress measured by working software）
8. 可持续发展的步伐。（Sustainable development pace）
9. 持续关注卓越技术。（Continuous attention to technical excellence）
10. 简单性。（Simplicity）
11. 自组织团队。（Self-organizing teams）
12. 定期反思和适应。（Regular reflection & adaptation）

我们一定要清楚两者之前最基本的区别，精益开发基础思想源自于消除浪费，而敏捷开发的初衷为应对变化，以不变因万变，不变的是体系、框架和实现，万变的是Code。精益可以说是一种比较完善的管理思想或理论，而敏捷可以说是一种做事原则或方法。

4）Measuring everything[度量一切]

DevOps理论确认了任何一切事物都可以被量化，并产生可度量值。DevOps主要专注于整个开发过程以及用户反馈，并对其过程进行记录、跟踪，并通过获得的反馈及结果持续改进。通过ITSM运维分析并遵循数据驱动的理念，来降低可预见的风险。

5）Share[分享]

DevOps是一种文化，文化正是透过人与人之间的互动产生的。可以分享的内容有很多，如经验、工具、数据、技术文档等都可以分享。例如上面所提到的度量值就可以分享给整个团队，让开发人员、测试人员甚至业务人员都可根据数据做出更好的决策分析。分享不仅仅只是一种文化，它还是增强团队透明度的一种方法。

DevOps人才分类

在这里我还需要重申一次，DevOps本质上是一种文化或者说管理思维的方法论。DevOps工程师的出现是 具有中国特色社会主义 的时代性产物。很多社区一直在讨论DevOps工程师，我们应该怎么进行分类以及怎么进行自我转型升级，下面就从技术维度来进行说明。 偏向于开发（Dev）的DevOps工程师： 在整个产品的开发过程中，扮演软件开发的角色。他们日常工作的一部分是利用持续集成 / 持续交付（CI/CD）、共享仓库（Git/SVN）、云（KVM/ OpenStack /公有云）和容器（Docker/K8S），但他们不负责整个基础架构的规划与实施，但他们了解基础架构，并且在成熟的环境中，能将自己的代码推向生产环境。偏开发的DevOps他们了解公司的开发技术栈，并对特定开发语言的构建、部署、故障排除有深入的了解，能够根据不同开发语言的特性进行资源需求的提前预警，并能够通过不同维度进行应用程序性能指标的监控与预警，并能提供诸如应用软件开发最佳实践支持之类的工作。 偏向于运维技术（Ops）的 DevOps 工程师： 在整个产品的开发过程中，扮演着运维管理及SOP推广员的角色。他们了解软件的开发，但并不会把一天的重心放在构建应用上。相反，他们更多的支持软件开发团队实现手动流程的自动化，以提高开发人员的工作效率。还可能需要做遗留代码的分解，并通过自动化脚本来实现重复及频繁的工作，当然还需要进行基础架构的规划与实现，并教会开发团队如何利用 CI / CD，以及负责推行新型标准化流程的落地。偏运维的DevOps具有硬件、网络、存储、操作系统等技能，并且可以熟练地使用Shell、PowerShell、Python等自动化脚本语言。负责整个基础架构的实现与演进，并帮助解决整个基础架构组件可能遇到的问题。 DevOps专家： 他们精通Dev与Ops两项技能，并能够协助开发及运维的同事，解决技术上的难点。在他们可能不擅长某种开发语言或应用组件，但能够提供给他们一些解决问题的思路或方法，协助他们梳理思维逻辑，快速定位并解决问题。他们能及时了解IT行业中DevOps的最新信息并以践行。在一定的维度上DevOps专家已经达到了SRE或者说超越了SRE的水平。通过上面不同技术维度的分解，我们对DevOps人才分类有了一定程度的了解，相信对入准备转型的同学应该会有一定的帮助。同时希望能够帮助到正在招聘的公司或企业，找准DevOps的定位，也希望能够帮忙到HR找到更加适合公司的人才。

DevOps过程中遇到的问题

任何事情并非一蹴而就的，DevOps亦是如此。对于新团队来说，DevOps并不是一个顺利的事情，DevOps转型所带来的对于团队的挑战，并不亚于造一颗原子弹，当然这里有一点夸张。但在一个团队内同时实施DevOps与开发转型（.Net Framework转.Net Core、Golang、Python）也并非一件容易的事情。因为DevOps与团队文化以及团队技术能力的变革息息相关，怎样在团队文化、团队技术能力与DevOps之间找到一个平衡点，逐步推进是对管理层及DevOps工程师的一个不小的挑战。作为过来人，送给正准备推行DevOps文化的同学一句最经典的话，“永远不要试图去改变一个人”这句话适应于两夫妻之间，同样适应于任何团队。

什么是SRE？

“一切皆代码，指标可量化，应用能自治，系统可自愈。”是每一个SRE应该深入骨髓的思想。对于SRE团队来说，存在一系列的规则参与到整个产品的生命周期管理，不仅只是生产环境，还包括开发团队，测试团队，客户等等。SRE团队负责可用性、延迟、性能、效率、监控、变更管理、紧急响应和容量规划。SRE不仅仅需要具有软件开发能力及自己的一技之长，还需要对编程语言、数据结构、算法、性能优化等有足够的了解，且对于计算机硬件、网络技术、操作系统、数据中心等管理有自己的研究，另外对于中间件、数据库等也需要有独到的见解。SRE基于企业本身的条件来创建产品，在满足用户需求的情况下，达到最佳的成本优化，在节能降费的同时，提高客户的满意度。比如：要你构建IaaS层基础架构，你可以用商业的VMware vCenter Datacenter，也可以用开源的OpenStack或KVM，其本质上都可以满足需求，而在企业自身条件有限，财力支出有限的情况下，SRE可以更好的做出选择。当然这仅仅只是一个举例，SRE不仅仅只是完成这些基础工作，更多的致力于产品本身。利用可用性和可靠性标准推行业务前进的方向，有助于最大程度地减少故障并减少时间的浪费。从而减少因故障花费在人力、资源组织上的成本。SRE致力于寻求最大化吞吐量并最小化运营成本的解决方案，通过部署可预测和预防性的维护程序，来消除宕机时间，并减少停机时间。正因为SRE要求的全面性，很难找到合适的SRE工程师。因为在开发、系统、运维、硬件、团队协作等软硬性技能方面的需求，对于招聘要求也会更高。另外由于SRE是一门现行跨多学科的综合性学科（这也是工业4.0的难点所在），因此在整个行业内如何建立和管理SRE团队目前来说行业标准和信息都很有限，毕竟很多大厂也还在摸索当中。另外它需要强大的管理层的支持，才能够突破一些非常规的东西，而这也恰恰是一个难点之一。

SRE根据不同的职位给出不同的度量标准。对于工程师、PM和客户来说，整个系统的可用性以及该如何评级都有不同的呈现方式。如果无法制定出可运行时间的度量标准，开发团队往往会将稳定性视为一个潜在的问题，这个也就造成的后续部门或团队之间的消耗，这也是为什么SRE会产生的原因。SRE确保公司内的任何一个人（包括：CEO、CTO、CIO、VP、运营团队、开发团队等等）都知道系统的可用性及服务故障恢复时间等，以确保在出现任何问题的时候，可更好的按照既定指标协助处理。SRE会和所有相关人员去沟通，决定出SLIs（ Service Level Indicators）、SLOs（Service Level Objectives）、SLAs（Service Level Agreements）等各项重要指标，这也是衡量一个SRE工程师是否合格的重要指标之一。

1）SLIs

SLIs： 定义了系统与响应时间相关的技术指标。例如：响应时间、每秒最大吞吐量、每秒最大请求量等等。我们需要将这些指标转化为比率或平均值。

2）SLOs

SLOs： 与相关部门沟通，得到一个系统可用时间区间，并期望系统能够在既定的SLIs技术指标区间内运行。比如说：1万并发，1ms的响应时间等等，对应指标也可以作为业务代码编写、测试的一个重要标准，并将其贯穿于整个产品的生命周期。如果无法衡量一个系统的运行时间及可用度的话，是非常难以维持线上系统的持续运行的，常常会造成运维团队处于救火的状态。

3）SLAs

SLAs： 虽然这个指标不是SRE每天需要关注的数字，但是作为一个线上服务提供商，SLA不仅仅只是对客户的承诺，也是在整个产品的开发周期内需要考虑的一个重要指标，允许停机时间、业务切换逻辑、风险与容错范围等都需要考虑在其中。DevOps提出任何问题都可以被度量，而SRE则从SLIs、SLOs、SLAs三个层级，将其量化成可操作的数据，这也就是为什么我们前面说class SRE implements DevOps的原因之一。

SRE人才分类

从Google的实践来看，Google的SRE团队由50%的软件工程师和50%的网络系统硬件工程师组成。从定位上来说，目前国内DevOps与SRE工程师的区别不大，所以可以参考DevOps人才分类，只是需要强调的一点是，国内对于DevOps的定位还是更多的偏向自动化，而SRE更加关注的是服务本身。

DevOps & SRE之间的区别

通过上面的DevOps与SRE的介绍，相信各位同学对DevOps与SRE有了一个基础的认识。DevOps旨在帮助IT部门以敏捷和高效的方式推进团队发展。它在运维团队和开发团队之间建立健康的工作关系，使每个人都能看到他们的工作如何影响彼此。SRE和DevOps都是解决生产运营管理需求的方法。但是，这两者之间的差异是非常显着的：DevOps提出问题并将其分发给Dev来解决（可以不了解或基础了解业务逻辑），而SRE则是发现问题并解决其中的一些问题（必须了解相关业务逻辑及实现方式）。DevOps团队通常会选择更为保守的方法，而SRE在保持稳定的生产环境的同时，对推动快速变更和软件更新更有信心。Google SRE 工程副总裁（Ben Treynor）推荐的另一种有趣的方法与SRE的专业性和效率密切相关，他允许SREs在不同项目之间互动，并允许SREs转移至产品开发领域，更好的了解产品本身的属性。由于两个团队的工作相似，因此这些过渡有助于Ops团队更好地了解产品和代码，并将Dev团队带入生产环境以帮助他们理解其挑战。这极大地促进了团队气氛。并让Dev团队处理了5％的运维工作，这增加了SRE团队的动能和效能。SRE工程师负责在部署后监视应用程序或服务，确保所有可以自动化的地方都实现自动化，以增强系统的运行状况和可用性。DevOps工程师负责从一开始就执行开发自动化愿景，从项目开始到实现。DevOps和SRE在开发过程中具有共同点。DevOps工程师在培养文化和系统方面处于最高位置，该系统可在开发过程中自动执行构建等任务。SRE是DevOps的补充，因为它体现了DevOps的理念，并通过既定的规则来度量业务的自动化运维。

DevOps & SRE 必备知识点

说了这么多，可能很多同学都有一个疑问，DevOps&SRE工程师到底应该具备怎么样的技能，通过下图相信各位可以了解一个大概，为此木子特地绘制了一张DevOps&SRE工程师应该具备哪些技能的图谱，可能不是很全面或存在错误的地方，但应该可以反馈大部分的技能需求。

从上图我们可以看到DevOps&SRE工程师对技能需求还是蛮高的，当然上图只是体现了表层实现的技能需求，涉及到业务底层的实现就要求更高了，包括数据结构、算法、内核等等。

公司对于DevOps & SRE的认知与定位

很多公司管理层将DevOps视为成本，而不是收入来源。他们将DevOps人员当作可互换的对象，拒绝投资DevOps人员平衡工作所需的资源。除了缺乏支持之外，DevOps人员可能还做着脏活累活，成为背锅侠。从公司管理者的角度来说，如果你没有能力从现有员工内部培养出优秀的DevOps工程师，那么就该多问自己几个为什么了。对于真正要招聘DevOps或SRE工程师的团队，在面试时，我们需要问清楚雇主“谁对生产业务中断负责”。如果回答是DevOps或SRE工程师，那你就需要多考虑一下了。如果他们说整个产品团队，那么至少他们对DevOps&SRE有了清晰的认识，出了问题不会只想找人背锅，这样的团队才更适合自身的发展，以及企业的成长。

写在最后

不过理想是丰满的，现实是残酷的。毕竟不是每一个公司都叫Google，Google的SRE可能比我们绝大多数公司的软件工程师写的代码还牛，比网络工程师还懂网络技术，比系统工程师更懂Linux，比业务运维工程师更擅长业务逻辑梳理。从目前各大招聘平台上看到的关于DevOps&SRE的职位，都没有能够很好的描述DevOps&SRE工程师的职责和工作范围，可见现实并不像我们想像的那么美好。部门之间的隔阂，权力的斗争可能也是阻碍DevOps文化推行的一个重要因素之一。改变需要我们不停的前进与推动，正如特区目标的三个阶段一样。关于DevOps&SRE木子就写到这里，如果你有任何其它的想法与不同意见，欢迎在下方评论区留言，我们相互沟通与讨论。