"当咱们在说 DevOps/SRE/PE/NoOps 的时,咱们在说什么"?

2022年05月11日 阅读数:10
这篇文章主要向大家介绍"当咱们在说 DevOps/SRE/PE/NoOps 的时,咱们在说什么"?,主要内容包括基础应用、实用技巧、原理机制等方面,希望对大家有所帮助。

本文做者:柯浩html

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

file

Note: 如下观点不表明本人就任的公司。系做者我的观点。这些观点和做者的本人工做经历有关,可能不够面面俱到。github

从 Devops 的由来讲起

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

devops 的职位安全

file sre 的职位 file服务器

几乎全部的互联网公司都在提出作 DevOps 建设(固然了,否则怎么会有这些职位的招聘呢:) 有的公司还有SRE团队网络

  • 有的公司并无区分 DevOps/SRE ,他们有所不一样吗?
  • DevOps 与 CICD 有什么关系呢?
  • 稳定性建设/ SLA/SLO 到底是谁来负责呢?
  • 等等,好像还看到过PE工程师,还有 NoOps 的提出
  • 安全的同窗说,咱们还有 DevSecOps

各位,有没有好奇过这些?没有的话,那如今你能够好奇一下,本文会一一道来。架构

这些职位到如今的发展,在有的招聘中已经和当时提出来的时候的概念不太同样了。 但这没关系,咱们能够先从这些职位的溯源来看他们提出来的时候的背景和当时的要求。负载均衡

其实,DevOps 自己是一种技术文化,它自己旨在打破 Dev 和 Ops 之间的墙,让你们的沟通更顺畅。less

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在作什么

file 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。

本文由博客一文多发平台 OpenWrite 发布!