从DevOps实践落地的角度谈谈“流程”和“规范"的反模式

2023/9/16 1:53:46

本文主要是介绍从DevOps实践落地的角度谈谈“流程”和“规范"的反模式,对大家解决编程问题具有一定的参考价值,需要的程序猿们随着小编来一起学习吧!

最近在经历的一些事情,让我突发灵感,觉得要写点关于DevOps体系建设过程中的“流程规范”,记录下来。

如何解读"流程规范"

谈到DevOps落地,无一例外都会提“流程规范“,我想没有人会反对,甚至会”不放在眼里“,因为概念本身没有什么晦涩难懂。可是一到落地,好像就是另外一番场景,“一地鸡毛”,“形同虚设”,”无人问津“ ,”无人知晓“,”面子工程“等等状况历历在目。

首先,很多人把“流程规范”放在一起来看待,甚至认为是等价的,我过去也这么理解。不过,现在我觉得需要区分来看待

  • **流程- Process: (步骤,程序,过程), **

image.png

  • 规范- specification (规格,规范,明细单,说明书;明确说明)

image.png
上面这个图,足够形象解释了他们的区别,和关注的点。前者告诉了你做什么,后者具体告诉你怎么做。

流程虽好,为啥不能落地

现实中, 组织会定义很多 XXXX流程 - 步骤1 ,步骤2, 步骤3 , 角色A 要负责这个,角色B要负责这个。。。,阶段产出是XXX
看上去很清晰,文档规范,可是“角色”只是个名称,现实中却是活生生的“人”;如果把“人”变多,就成了“众”。

  • 众口难调
  • 从众心理
  • 乌合之众
  • 众人拾柴火焰高
  • ...

每个词的背后,就代表了如何理解“众”;对于组织的变革者,你需要理解背后代表什么,不了解“众”,不了解“人心”,不感同“人心”,你的流程也会难以服众。

  • 你的流程是否合理?
  • 你的流程是否代表大多数,而不是个性化、差异化?
  • 你的流程是否具有权威性?
  • 你的流程是你拍脑门想的吗?是看某某权威的书启发的吗?
  • 你的流程被挑战时候,是否妥协了?
  • 你的流程是为谁而设计?代表组织的利益吗?或让组织因此而收益吗?
  • 你的流程目标是什么?是为了改进吗?还是为了控制约束别人,发号施令?
  • 你的流程是否大家都知道并能5秒内找到?是否只是“红头文件”,束之高阁?

工具的"神圣使命"

好像流程里,很少提工具,甚至“一笔带过”,那你的流程靠什么落地?
哇塞,工具啊!工具无敌,工具牛逼,工具能解决一起问题。彷佛霎那间,看到了胜利的曙光~, 仿佛工具一夜之间成了“救命稻草”,“银弹”。

image.png

”工具“突然被赋予了“神圣重任”

  • 流程落地靠“工具”了
  • 我买了你的“工具”,是不是我们流程就跑顺了,就规范了
  • “工具”能不能给我出数据,能不能帮我XXXX,流程里面提到了“工具”

image.png

工具背后的“复杂性”

提到流程背后“工具”,我必须拿出下面这张图来说道说道

  • 如果你的团队/组织只有10人左右,可以直接跳出这篇文章,因为你确实不需要工具“规范”
  • 如果你的团队规模在超过10-50人(且属于一个团队),定义“简单的”规范即可,能说清楚就好;工具文档怎么说,按照怎么做就好
  • 如果你的团队规模/数量,达到百人以上,那么你真的需要认真考虑下“工具规范”

ContinuousDeliveryToolLandscape-fullsize.jpeg
面对如此之多的各种“DevOps”工具,每个领域选一个,最起码也有10+吧。如果工具的“规范”都没有,“流程”怎么可能落地?

  • 工具怎么用?学习成本如何?
  • 怎么命名规范一致?
  • 怎么申请?
  • 怎么协作?
  • 怎么用好?
  • 怎么采集数据?
  • 怎么按照最佳实践?
  • 怎么满足流程要求?
  • 怎么面对个性化需求?
  • 怎么满足既要,又要,还要?
  • 怎么让工具“匹配并支持”流程

image.png
是不是很崩溃,这其实就是DevOps难以落地的其中一个原因~ “众口难调”和 “众望所归”,“自动化的工具体系”是“组织”最后的救命稻草。

工具背后的“规范”

如何把“众口难调”,变成 “说一不二,不可辩驳,被“驯化”,被“教育””,不管你是买,还是自己搞,这都是工具背后要去思考的。无非你买来的,人家帮你理清楚一些规范了,可是依然不能满足“众口难调”。
image.png

没有“完美的”工具,不要指望世界上有一款工具,能满足所有人的要求,所以“工具”要学会说不。满足所有人,就意味着不可能“好用”,甚至会成为“负担”。

  • 立规矩
  • 教育用户,引导用户
  • 学会拒绝,不能拒绝就摆烂
  • “一味迎合”,最终会是“一地鸡毛”


**持续关注我,我会分享具体关于工具的规范~ **

流程是死的,人是活的,解决什么问题?

这里要谈谈,为什么要有流程?

  • 具体解决某个问题?经常出问题,所有要通过流程约束?
  • 流程过时了,还要一味遵守吗?
  • 流程不能解决问题,是不是证明原来本身就有问题?

“能够“ 切实解决问题,为团队减负的流程,才是好流程。一味不断加码,还不解决问题,谁会愿意遵守?

反模式

  • 画个流程图,能满屏各种角色,这不是流程的问题,而是组织架构的问题,大道至简
  • 一开始设计完美的流程,就意味无法落地-流程要在试错中不断完善,并且与“工具规范”磨合
  • 缺少“工具规范”和最佳实践指引,没有“周到细致引导”的流程,谁会遵守呢,团队成员需要被“教育培训强化”
  • 工具先行,靠工具来推动流程,把“工具”或者 DevOps当作“银弹”
  • 设计流程的人,没有深入贴近群众,走进群众,甚至不考虑落地
  • 过度迎合纵容“群众”,你是代表组织的,纵容迎合就是破坏自己亲手制定的流程
  • 老旧的“流程”,还不舍得放弃,层层加码,“学会做减法”

总结

最后,简单总结,其实就是这么几个要素。每个要素不能自洽,或者缺失,很可能这个流程就无法落地,并深入执行。

  • What - 流程定义了做什么
  • How - 规范定义了怎么做
  • Who - 谁来参与
  • When - 什么时候做
  • Why - 为什么要这么做?

”流程“ 和”规范“密不可分,流程代表了组织的角色协作,”规范“指导了如何做的问题。

  • 没有”流程“哪里会有”规范“;
  • 没有”规范“,怎么可能促进”流程“的运转;
  • 清晰的“工具规范”有助于平台的建设,事半功倍
  • 流程要”简单“,规范要”细致且严格,才会有事半功倍;否则”流程“就会成为”一纸空文“。

image.png
关于我,一个”野生“的DevOps实践者,不讲理论,没有认证加持, 从”实践“中反思总结改进。




这篇关于从DevOps实践落地的角度谈谈“流程”和“规范"的反模式的文章就介绍到这儿,希望我们推荐的文章对大家有所帮助,也希望大家多多支持为之网!


扫一扫关注最新编程教程