从员工的角度理解 DevOps-阿里云开发者社区

开发者社区> 开发与运维> 正文
登录阅读全文

从员工的角度理解 DevOps

简介: 从员工的角度理解 DevOps
问:为什么从员工的角度出发?

答:如果从领导者的角度解释,说着说着,我们会逐渐开始【唱高调,提出正确的废话】,对于员工来说,根本无法体会。

DevOps 是一个非常模凌两可的概念,主流大公司针对于 DevOps 都有自己的解释,写得也很抽象,大家可以自行参考一下。

历史演变

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

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

所以,Agile(敏捷开发)或者 Lean(精益开发)并不是软件领域的大佬们凭空想出来的,而是由工业制造领域得到了验证。

这里,我们要消除掉第一个疑虑!

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

devops-his.png

名词解释

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

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

有了上面的名词解释,我们就可以继续往下走了。

理解 Agile(敏捷开发)

在进一步阐述 DevOps 之前,我们先要了解 Agile(敏捷开发),因为 DevOps 是 Agile 的一个扩展。

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

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

agile-methodology-set.png

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

当然,如果我们对公司里进行的 Agile 模式感到厌倦,不是因为 Agile 本身,而是 Agile 的应用方式出了差错。

就好比,火锅本身是好吃的,厨师把火锅做的难以入口,就不应该怪火锅。

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

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

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

员工疑问

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

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

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

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

问4:公司干嘛要推 Agile?

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

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

疑问解答

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

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

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

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

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

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

agile-prob-answer.png

开始讲讲 DevOps

我们用通俗的方式介绍了一下 Agile,现在开始讲讲 DevOps,老办法,用大白话来讲。

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

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

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

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

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

devops-vs-agile.png

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

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 这些都不是凭空想出来的东西,而是在工业领域得到过验证的。

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

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

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

分享:
开发与运维
使用钉钉扫一扫加入圈子
+ 订阅

集结各类场景实战经验,助你开发运维畅行无忧

其他文章
最新文章
相关文章