从员工的角度理解 DevOps

2021年11月22日 阅读数:2
这篇文章主要向大家介绍从员工的角度理解 DevOps,主要内容包括基础应用、实用技巧、原理机制等方面,希望对大家有所帮助。

问:为何从员工的角度出发?微信

答:若是从领导者的角度解释,说着说着,咱们会逐渐开始【唱高调,提出正确的废话】,对于员工来讲,根本没法体会。框架

DevOps 是一个很是模凌两可的概念,主流大公司针对于 DevOps 都有本身的解释,写得也很抽象,你们能够自行参考一下。运维

历史演变

既然 DevOps 的概念不太好理解,那咱们就看一下【软件研发流程】的历史变迁。工具

咱们接触到的名词,例如,Agile, Lean, Kanban, Scrum 的根源,其实来源于 TPS(丰田生产系统)。很多的概念和模式都是受到 TPS 的启发。学习

因此,Agile(敏捷开发)或者 Lean(精益开发)并非软件领域的大佬们凭空想出来的,而是由工业制造领域获得了验证。测试

这里,咱们要消除掉第一个疑虑!优化

Agile(敏捷开发),Lean(精益开发),DevOps 等等,的的确确有好处的,并非唱高调。网站

名词解释

在继续阅读以前,让咱们先用最通俗的语言来解释【软件研发流程】一系列名词。google

名词 解释
Waterfall 一气合成地开发方式,一口气完成整个开发流程。
Agile(敏捷开发) 项目管理,产品研发流程方法论集合。解决的问题:生产流程优化,团队协同。
Epics 属于 Agile,工做的度量单位。比方说,开发一套线上点餐系统,就属于一个 Epics。
Stories 属于 Agile,工做的度量单位。比方说,点餐系统中的登录逻辑,就属于一个 Story。
Task 属于 Agile,工做的度量单位。比方说,点餐系统中,登录逻辑中的二维码登录功能,就属于一个 Task。
SAFe Scaled agile framework。解决的问题:如何在整个企业中推广 Agile
Scrum Agile 的延伸,项目排期方法论。解决的问题:项目排期。
Scrum master 属于 Scrum,负责 Scrum 的有序进行的人,千万不要只让 Leader 去当,要全部人轮流。解决的问题:确保项目进度。
Sprints 属于 Scrum,一种时间单位,通常为2周,好比以2周围单位,进行项目进度总结。解决的问题:项目排期。
Backlogs 属于 Scrum,代办列表。解决的问题:记录工做中出现的,须要高优解决的问题。
Standups 属于 Scrum,站会,天天早上进行的简短会议。解决的问题:共享工做信息。
Kanban 可视化工做量和工做进度的方法论。解决的问题:以可视化的方式排期,提升效率。
Lean(精益开发) Agile 的延伸。解决的问题:优化产品研发成本。
DevOps 补充了 Agile(敏捷开发)缺失的部分,一种 IT 企业文化。解决的问题:全方位提高企业效率。
ChatOps DevOps 的分支,经过 Chat 工具,进行运维。解决的问题:让流程透明化。
GitOps DevOps 的分支,把部署流程写到代码库的方式。解决的问题:让开发者涉及到运维当中。
FinOps DevOps 的分支,云财务运营。解决的问题:节约云资源成本。
AiOps DevOps 的分支,把 AI 技术融合到运维中,孵化期。

有了上面的名词解释,咱们就能够继续往下走了。url

理解 Agile(敏捷开发)

在进一步阐述 DevOps 以前,咱们先要了解 Agile(敏捷开发),由于 DevOps 是 Agile 的一个扩展。

我相信不少人已经在公司里参与到了 Agile,不过没有什么感受而已,甚至,很多时候,咱们认为的【浪费时间】的一些操做,有可能就是 Agile 的一部分。

以前咱们提到过,Agile 是研发流程方法论的集合,先来看看 Agile 中最经常使用的方法论结合吧。

是否是很熟悉,好多常常听到的名词和流程。其实咱们平时在公司里接触到的操做,就是 Agile 的一部分。

固然,若是咱们对公司里进行的 Agile 模式感到厌倦,不是由于 Agile 自己,而是 Agile 的应用方式出了差错。

就比如,火锅自己是好吃的,厨师把火锅作的难以入口,就不该该怪火锅。

Agile 的方法论集合里,包含了项目排期,项目管理,产品管理,工做量评估,软件开发,我的绩效等方面。也有其余的一些,不过这里咱们不细讲。

知道了 Agile 里有哪些方法论,也能够推导出,Agile 里使用者有哪些。

  • 产品经理
  • 项目经理
  • 研发,测试
  • 团队 Leader

员工疑问

谈到这里,咱们就能够得出那一系列问题的答案。 你们都是员工,凭心而论,你们应该都有过下面的疑问,我就是其中之一。

问1:为啥咱们的团队在进行 Agile,不过没啥效果?

问2:每天作 Agile,还不如多写几行代码!

问3:产品经理,项目经理每天只会画表格,到底在干什么?

问4:公司干吗要推 Agile?

问5:每次周会都要作什么表格来汇报,直接说不行吗?

问6:OKR 是个什么东西?年终绩效,还不是看谁和老板关系好?

疑问解答

在了引入 Agile 的时候,环节出了问题。而不是在员工。

咱们的决策者们,发一封内部邮件,作一次全员大会,组内大会,就开始推广 Agile 了。

以后,你会看见公司内网上多了几个买过来的 Agile 产品。

问题来了:东西买来了,我该怎么用?很多决策者是没有考虑到这个的。

正确的作法是,产品 + 说明书 + 培训。咱们缺乏的就是,【说明书】+【培训】这个环节。

就比如,我发给了你一支枪,没教你怎么打仗,上去就是活靶子。

开始讲讲 DevOps

咱们用通俗的方式介绍了一下 Agile,如今开始讲讲 DevOps,老办法,用大白话来说。

DevOps 是 Agile 的一个延伸产物,最终形态是【企业生产文化】。

若是说,Agile 的使用者包含了【产品经理,项目经理,研发&测试,团队 Leader】,那么,DevOps 把【运维】【决策者】这个角色也引入了进来。

若是说,Agile 的方法论集中在了【项目管理】【产品管理】【团队管理】【软件研发】,那么,DevOps 补充了【产品运维】【客户管理】。

若是说,Agile 的核心在于【团队协同】,那么,DevOps 的核心在于【自动化】【文化】【评估】【共享】。

若是说,Agile 对于生产线的流程是【协同做战】,那么,DevOps 在这个流程之上,注重了【闭环】。

让咱们一个一个展开来看看。

DevOps 使用者

咱们诚实地讲,一个公司要是引入了 Agile,最开始活跃的是项目经理和团队 Leader。

为啥?看一下 Agile 方法论集合,大多数集中在了项目管理那一层。

至于研发体系下的员工,工做内容没啥区别。不过,要想想,一个 IT 公司,人最多的是研发体系下的人。

这个会引入一个很大的团队内部矛盾。 【研发体系员工】和【产品体系员工】相互看不上,互怼,这种现象仿佛已经成了必然,都成了段子。

这些矛盾从何而来?简单点儿说,就是:咱们产品线都引入了这么先进的方法论,大家研发线的生产力咋跟不上?

因此,DevOps 在 Agile 之上,把研发,测试,运维体系也归入了进来。把整个生产线都作了一个闭环。

说白了,要进步,得大伙儿一块儿进步,不是说项目管理方法进步了,你的项目就进步了,这是不合理的。

DevOps 方法论

除了使用者获得了扩展,方法论方面也获得了扩展。Agile 的方法论集中在【我咋能把这事儿计划好】,DevOps 拓展成了【我咋能把事儿作好】。

除了项目管理层面的方法论,DevOps 还拓展了以下几个方面。

  • 测试
  • CI/CD
  • 监控告警
  • 服务运维
  • 服务评估

咱们在后续的文章中会重点介绍几大方法论。这里就先有个了解。

DevOps 核心

说到核心,网上的 Agile 的核心不少,你们也有本身的见解。不过,咱们认为,Agile 的核心就是【团队协同】。

从哪里能够看出来?最简单的方法就是看那些 Agile 的产品。

即时聊天平台(企业微信,钉钉,飞书),团队文档平台(Confluence),项目管理平台(Jira,Trello,Kanban)。这些产品的核心就是【促进团队协同】。

DevOps 既然是 Agile 的一个拓展,那么天然要比 Agile 丰富了很多。总共有4个大核心,叫作 CAMS。

  • 文化 Culture
  • 自动化 Automation
  • 评估 Measurement
  • 共享 Sharing

怎么去理解这四个核心?就那你如今的团队或者公司作个比较,来回答一下这个问题吧。咱们举几个例子。

  • 还记得大家公司的文化口号是啥吗?
  • 公司对于员工在工做时出错,是一个怎么样的处理方式?
  • 公司对于普通员工的学习是一个怎么样的文化?
  • 从项目开始到项目交付,全部环节的自动化是怎么样的?
  • 对于每个产品,每个人,每一项工做,公司是怎么评估的?是否使用了客观数据?
  • 公司内部有没有共享知识的平台(这里不是指八卦共享平台)?
  • 每一个事故是否都会共享给其余团队?

上面的这些问题,看似不重要,不过正是一个企业健康发展,员工满意的一个核心指标嘛。

DevOps 就是要解决这类问题。

DevOps 流程

DevOps 的流程就是咱们常常看到的那个像八卦图同样的东西。

也有很多人认为,DevOps 的流程就是把测试,运维职位干掉,让研发作全部的事情。固然,像 Amazon,Google 确实是如此。

不过,咱们的建议是:根据企业/团队自身状况来判断。

简单点来讲,Amazon,Google 能作到这一点,是由于人家的自动化,评估,共享,文化这些作的比较完善,而且员工能够站在【巨人,也就是技术大佬】的肩膀上工做。 咱们可不行,因此,不要一刀切。按照实际状况,一点一点改变。

因此,DevOps 流程的最重要的一点在于【自动化】和【评估】。DevOps 的理念中,要把全部的流程尽可能作成自动化,而且能够随时观察。这但是个大工程,不是随便买一套产品就能够的。

顺便聊一聊:一站式平台

针对于企业效率提高,国内好像很是喜欢推出一站式平台,就是把全部东西都塞到一块儿,就在一个网站上操做。

说一说个人观点。

一站式的优势比较明确(仍是用大白话讲)。

  • 一会儿就能展示成果,我花了1个月的时间,就搭建了一个企业效率平台。
  • 企业不用花经历去搞企业效率提高的东西。
  • 不太熟悉企业效率提高的知识,可是就能马上上手。
  • 跟着流行趋势走

不过,个人观点有所不一样,一站式虽然能快速搭建,不过,效果却不怎么样。仍是老问题,你只给我工具,没教我怎么用。就比如,只学会了招式,心法没学。

此外,一站式就意味着封闭,不管是,流程仍是底层技术,人家给你什么,你就用什么。到时候,有新技术出来,又得逼着人家给你出一个新版本。

还有就是,每一个团队,对于流程的理解,需求不同,根本没法用一样的流程来走。

因此,我的认为,一站式有它的好处,不过,从长远角度看,一站式未必是个好东西。我的更推荐把单个产品引入进来,自行根据须要搭建。虽然会花一些精力,财力。 不过,在这个过程当中,既能学到新东西,也能按照自己条件来搭建,产品线的核心流程也会掌握在本身手里,还能根据技术潮流,随时更新底层框架。更甚至,若是流程是本身的,后续换大方向也是很容易的事情。

总结

Agile,DevOps,Lean 这些都不是凭空想出来的东西,而是在工业领域获得过验证的。

想提高企业效率,提升员工幸福感,不是买一套产品就能解决的。

企业最重要的仍是员工,提高企业效率的基础,不是让挤压员工,而是把【人】,【工具】,【规矩】用得恰到好处。