关于devops:当我们在说-DevOpsSREPENoOps-的时我们在说什么

本文作者：柯浩

GitHub 地址: http://github.com/KeHaohaoke

Note: 以下观点不代表自己就任的公司。系作者个人观点。这些观点和作者的自己工作经验无关，可能不够八面玲珑。

从 Devops 的由来说起

近些年，DevOps 以及 SRE 的宣传和布道在国内越来越多，在各招聘平台也能够看到这些职位的招聘信息(呈现具体公司信息的，隐去)，以某招聘网站，地点抉择北京，别离搜寻 devops 和 sre 咱们能够看到

devops 的职位

sre 的职位

简直所有的互联网公司都在提出做 DevOps 建设 (当然了，不然怎么会有这些职位的招聘呢:)
有的公司还有 SRE 团队

• 有的公司并没有辨别 DevOps/SRE，他们有所不同吗？
• DevOps 与 CICD 有什么关系呢?
• 稳定性建设 / SLA/SLO 到底是谁来负责呢?
• 等等，如同还看到过 PE 工程师，还有 NoOps 的提出
• 平安的同学说，咱们还有 DevSecOps

各位，有没有好奇过这些？没有的话，那当初你能够好奇一下，本文会一一道来。

这些职位到当初的倒退，在有的招聘中曾经和过后提出来的时候的概念不太一样了。
但这不要紧，咱们能够先从这些职位的溯源来看他们提出来的时候的背景和过后的要求。

其实，DevOps 自身是一种技术文化，它自身旨在突破 Dev 和 Ops 之间的墙，让大家的沟通更顺畅。

DevOps 正式的被提出是在计算机届出名的出版公司 O’reilly 举办的 Velocity 大会上，在 2008 年的 Velocity 大会上，一场名为 10+ Deploys per Day: Dev and Ops Cooperation at Flickr 的演讲带来了 DevOps 的说法，咱们当初还能够在 O’reilly 的网站上看到这个视频。

在这场演讲中，John Allspaw (Flickr 的运维团队的总监)提出了要“构建疾速公布软件的工具和文化 ”， 留神，敲黑板，这里不仅有工具，还有文化 。
尔后，简直所有谈到 DevOps 理念的都会提到这场演讲。Patrick 过后并没有在会议现场，但他起初观看了会议视频，深有同感，这为 DevOps 埋下了种子。
Patrick 随后在 Twitter 上示意，他也想加入 Velocity 大会，一些工程师回应他，你能够举办你本人的 Velocity 大会，咱们都去加入。
工夫又到了 2009 年，这一年，Patrick 通过 Twitter 招集了本年的社区版“Velocity 大会”，并在比利时举办。因为是个会议，Patrick 得起个名字，他就想到了 Dev 和 Ops，因为会议举办了两天，于是会议被命名为 DevOps Days。

这也是 DevOps 畛域驰名的会议：DevOps Days 的第一次首秀，本次会议完结后，参会的工程师和管理人员们带着 Devops 的理念回到世界各地，逐步的在全世界范畴内推广和实际 DevOps。

DevOps 在做什么

Photo by PCB-TECH on https://pixabay.com

说了这么多，那么 DevOps 到底要做什么?
正如最早提出 DevOps 的 2008 年的 Velocity 大会所说，DevOps 的关注点之一，在疾速公布软件的工具和文化。
与此对应，并由此延长的：继续集成，继续交付，继续部署，甚至倒退了继续布局，继续测试等等。如果你想晓得还有哪些继续什么，能够参看这篇文档微软对于 DevOps 的介绍

不管怎样，DevOps 的主旨都在于尽可能多的，尽可能快的集成 / 部署 / 交付。

通过 CICD（继续集成和继续交付）流水线的设计，尽可能“疾速失败”。所谓尽可能“疾速失败”是为了让失败能尽早进行，尽早看到，尽快批改。
在这过程中，提倡测试尤其是自动化的测试更早的染指，所谓“测试左移”。

咱们回顾一下（可能有的同学回顾不了，没经验过那个时代）手工运维的时代：在没有任何自动化设施的软件公司，怎么公布软件：研发按需要开发，在本地打包构建，把包给运维同学，运维同学把包上传到服务器，批改配置文件为生产环境配置，重启服务以失效。
哦，好吧，每次公布都是折磨人，尤其是随着节点规模的逐渐的扩充，每操作一个节点，就要把上述操作全副进行一次，几乎了，忍耐不了。是的，那就须要 DevOps，回绝手工。

流水线，CICD

如上，设想一下没有流水线的场景，咱们须要手工做 CI 继续集成：代码 lint，单元测试，构建。而后再做公布验证。
如果不能自动化的做这些，那么，就不能 尽可能多和尽可能快 的继续交付价值。

在这个过程中，能够从几个纬度来考量 DevOps 带来的好处:

• 进步部署效率和频率
• 缩短部署前置批改工夫
• 疾速回滚（复原）的速度
• 进步更高的失败率

这些为什么重要呢？从交付速度 角度来说，越快的减速交付，就能越快的去验证商业逻辑、试错、进步 bug 修复到客户看到成果等各种过程的速度。

麻利与 DevOps

不论是国内，还是国外，提到麻利，就绕不开 DevOps。
咱们回顾一下上文提到的 Patrick 老哥，他在 Agile 2008 大会上的演讲中谈到能够将 Scrum（麻利一种实现）联合运维中。Patrick 在一个测试数据中心迁徙的我的项目与开发和运维团队一起工作。在他的工作中，须要频繁往返于开发与运维之间。

而麻利所强调的小步快跑，继续交付等理念正须要 DevOps 在技术上的无效反对能力落地，否则，麻利的这些环节就是海市蜃楼。

同时，DevOps 也借鉴了 Scrum 的理念，在 Dev 的用户故事之外提出了测试故事和运维故事。
并且在继承了 Agile 的理念的同时，更强调了 软件开发生命周期的理念（SDLC），强调了并不是编码和测试实现就是软件开发的完结。还须要运维的管控。

而对于传统的运维流程 ITIL。DevOps 则是有抉择的排汇，要有流程，但不是受制于流程，且流程的变更应该是自动化工具实现的推动和数据的流转，而不是依赖人工。

DevOps 文化

突破部门墙，建立 Ownership

这是在务实吗？不齐全是。
DevOps 确实强调文化。咱们又要提到 Patrick 老哥，前文已述，他的工作要频繁的往返于开发和运维之间。
而这两个团队，其实在 DevOps 理念宽泛的被承受之前，两个团队是割裂的：Dev 更喜爱尽快验证上线，而 OPS 团队则心愿尽可能少的变更，毕竟，越少的变更，越不容易出错。

而且，这两个团队的技术栈也有所不同，比方在早点的时候，国内一些公司，以本文作者经验过的一些不同的 100 多人的技术团队到几百人的技术团队到 2000 人左右的技术团队：一些传统的运维不会开发，只写业务逻辑的开发不懂零碎层 / 网络层的技术，这会导致两个团队的沟通老本比拟高，除此之外，因为 Dev 如果只关注写业务逻辑，不晓得生产环境的整体架构全貌，生产环境出了问题，须要找 OPS 理解生产环境，排查工夫也会变长。

DevOps 正是要突破这种部门墙，让 Dev 和 OPS 无效的沟通：

• 从技术栈来说：OPS 须要学习开发的常识，以便能够开发 DevOps 工具和平台，高效的实现 DevOps 工作。Dev 也须要理解零碎层面、网络层面的常识，去理解生产环境的架构，以更分明的晓得产品在技术层面的全貌，有利于对问题的剖析和排查。
• 从 Ownership 的角度来说，都要有主人翁精力，对本人负责的产品有 Ownership 意识，而 Ownership 并不是务实的，而是要通过 DevOps 的技术建设，让研发可能参加到公布之中。而在自动化建设不好的环境下，甚至须要专人来进行公布，Dev 也不晓得如何进行 CICD，这里，倡议不要用权限管制来说事，权限管制能够通过技术来实现，给予必要且刚好够用的权限，让 Dev 可能本人公布本人的产品，解放 OPS 的人力不是去专门的做公布点击工程师：）

对于 DevOps 不仅仅是工具，更应该是对于无效合作和沟通的文化，能够参看 scrum.org 的一段形容：

DevOps is more about Organisation Culture than about Tools

In fact, as we have learned tools and automation is only one-third of DevOps (I would say it is even less). In overall, DevOps is about Collaboration & Collective Ownership, Focus on the flow of value delivery and Learning and experimentation culture. But sadly, many tooling vendors position DevOps as tools and process for delivery pipeline (the vendors that I’ve witnessed in my market are more focused on tools but your experience may be different to mine). This will get the management excited because many managers whom I’ve met think that after buying and installing the “DevOps” tools without changing their organisation will make their company instantly agile. This is like putting the cart in front of the horse.

仅仅认为引入了自动化工具就是 DevOps 是不够的，还须要合作，关注价值传递。

康威定律与组织建设

康威定律：设计零碎的组织，其产生的设计和架构等价于组织间的沟通构造。

组织架构和技术架构是有相应的映射关系的，有什么样子的组织，就有什么样的技术架构。
严格考究职能边界的企业是很难无效的推广微服务和 DevOps 的。

在一个企业倒退初期，工程师可能都是多面手，能够实现开发和运维等诸多工作，这种情景下，沟通是高效的。随着企业的倒退，有了独立的 PM、QA、DEV、OPS 等部门，不同的团队之间就会呈现耦合和依赖，这会升高沟通效率和进步部署的老本：一个产品的上线要通过诸多沟通甚至人工的审批。

微服务的提出，要求团队之间解耦，团队要能在技术上自治，能够本人进行开发和运维，通过零碎调用或者接口调用实现自服务和自运维。

咱们如果朝着缩小组织各个团队之间不必要的沟通和协同（留神，不是不要沟通和协同，而是缩小不必要的沟通和协同）的时候，组织的自运行效率就会回升。

反之，各个团队之间通过比方 PM 来协调资源和沟通，就难以造成微服务的技术架构，而是会造成分层的技术架构。

这里，要特地指出，让运维团队参加研发日常流动，比方每日站会，也会让运维更好的了解研发工作和分享团队外部信息，对齐指标。

PS：平安的同学排汇 DevOps 的理念，强调 Dev/Sec/Ops 三者的合作，并把 DevOps 的办法融入到平安的工作中，就是 DevSecOps 了。

说了这么多，DevOps 只关注交付吗

好了，这个题目是成心的，是为了引出 SRE。
交付之后呢？就不论了吗？
一个利用上线之后，优化它，继续迭代（继续迭代还是偏 Dev 和 CICD），还有，还要继续监控它，最好能提前发现故障的迹象，及早的打消故障，甚至打消故障呈现的可能。

当遇到流量压力，应该能够 疾速的程度扩容，扩容是无感知的 。
该当关注 SLO（service-level object），并有正当的 SLA（service-level agreement）。

而这些是 DevOps 应该关注的吗？其实这个说法不一，以作者的个人经历认为：DevOps 既然是继续的关注交付价值和价值的流动，那么价值的流动并没有到交付就完结。而监控 / 无感知扩容 / 服务质量保障都是 DevOps 能够关注的。不应该局限于具体的技术名词的限度。但在理论工作中，能够有专一的畛域，毕竟，人的精力和专一度是无限的。

SRE & SRE vs DevOps

sre 是由 google 提出的：Site Reliability Engineer（网站可靠性工程师）。
在 google 的说法里，sre 是 devops 的落地。

SRE 的首要任务是保障 SLA, 重要的是 SRE 的工作登程是以开发人员表演的角色，SRE 都是从研发来的，而不是传统的运维。这是 SRE 和传统运维最大的不同。

SRE 是代替原有 IT 操作的一种形式，强调以自动化，编写工具的办法解决，即 treat [IT] operations as if it’s a software problem。

SRE 关注以下几个方面

• 容量布局
• 冗余和容错
• 流量过载
• 负载平衡
• 监控
• 救火（没有看错）

SRE 强调尽可能自动化的以编程的形式实现这些工作，但必须抵赖，有些工作可能是不好自动化的，比方 Troubleshooting。
在 Google 的 SRE 体系中，SRE 工程师将破费大概一半的工夫来开发新的工具和服务，这些工具的一部分用于自动化一些手动工作，而其余局部用于来一直填补和修复整个 SRE 体系外部的其余零碎。
对 Google 的 SRE 理念和他们的实际感兴趣的，能够浏览 [SRE: Google 运维解密]，英文版是[Site Reliability Engineering: How Google Runs Production Systems]。
这是 GoogleSRE 团队编写的书籍，全书从 SRE 工作的各个方面讲述了 SRE 在 Google 是如何落地实际的。

同时，也能够看到，对于流量过载和容量布局的须要，以及零碎应答流量过载的做法：疾速无感知的程度扩容，这就须要 云原生的技术，k8s 容器化、自动化的扩容，退出服务。
SRE 对于监控零碎的须要，在传统的监控零碎的根底上倒退了可观测性的理念。

SRE 是 DevOps 的落地，SRE 更偏差技术实际，而 DevOps 还有组织文化和流程等内容。
但两者不是对抗的，恰恰相反，SRE 工作就是开发和运维无效的联合，正是 DevOps 理念十分好的实际。

PE/NoOps/AIOps

PE 就是利用运维工程师，是国内很多公司的运维的理论角色。和 SRE（真正的 SRE）的不同是，PE 偏差只是利用运维。

NoOps 是一些公司提出的理念，实质还是在于打消手工运维，而不是打消运维，而是要通过解放原来的手工或者低效的沟通，解放原来运维做的大量的反复的、手工的比方仅仅是权限起因，有专职的公布运维；DBA 天天在复制粘贴开发提交的 SQL 等工作。
而通过 DevOps/SRE 的建设，让运维和 DBA 去干真正有价值的事件，比方关注中间件的原理和大规模实际，成为有特长和深耕的技术人，并在这些方面的运维有建树。

AIOps 是这几年才有的概念，但作者集体的经验联合看到的 DevOps 产品来说，因为理论生产环境的简单多样性，目前还没有 AI 来做 OPS/DevOps/SRE，哪个公司敢让 AI 决定怎么 Troubleshooging ? 至多目前还没有，当然，技术的倒退是超出人们设想的，兴许有一天，AIOps 或者是其余的某个 XXOps 真的能够实现智能运维。

总结

国内很多公司，SRE 还停留在口头，参看很多招聘的 jd 就能够晓得，其实只是利用运维换了个说法，包含一些 DevOps/ 运维开发的岗位需要也是，其实次要工作还是利用运维，即：部署 / 上线 / 监控 / TroubleShooting/On call。
其实，不论是 DevOps, 还是 SRE，都在强调自动化。在这一点上，咱们能够不那么在意这么多上述名词的区别，毕竟落地到工作中，都是很切实的工作。
能够先从高效的自动化开始，建设本人的 DevOps/SRE 体系。

能够尝试向真正的 DevOps 或者 SRE 转变，能够做先吃螃蟹的人。

如果你还在为部署 / 配置 / 整合买通各种 Devops 工具劳神，能够看看一个神奇的网站：DevStream 官网的开源工具：DevStream，它会帮忙你向真正的 DevOps 更进一步，在此基础上，你能够更好的学习和成长，以至于成为 google 定义的真正的 SRE。