从DevOps实践落地的角度谈谈“流程”和“规范"的反模式
最近在经历的一些事情,让我突发灵感,觉得要写点关于DevOps体系建设过程中的“流程规范”,记录下来。
如何解读"流程规范"
谈到DevOps落地,无一例外都会提“流程规范“,我想没有人会反对,甚至会”不放在眼里“,因为概念本身没有什么晦涩难懂。可是一到落地,好像就是另外一番场景,“一地鸡毛”,“形同虚设”,”无人问津“ ,”无人知晓“,”面子工程“等等状况历历在目。
首先,很多人把“流程规范”放在一起来看待,甚至认为是等价的,我过去也这么理解。不过,现在我觉得需要区分来看待
- **流程- Process: (步骤,程序,过程), **
- 规范- specification (规格,规范,明细单,说明书;明确说明)
上面这个图,足够形象解释了他们的区别,和关注的点。前者告诉了你做什么,后者具体告诉你怎么做。
流程虽好,为啥不能落地
现实中, 组织会定义很多 XXXX流程 - 步骤1 ,步骤2, 步骤3 , 角色A 要负责这个,角色B要负责这个。。。,阶段产出是XXX
看上去很清晰,文档规范,可是“角色”只是个名称,现实中却是活生生的“人”;如果把“人”变多,就成了“众”。
- 众口难调
- 从众心理
- 乌合之众
- 众人拾柴火焰高
- ...
每个词的背后,就代表了如何理解“众”;对于组织的变革者,你需要理解背后代表什么,不了解“众”,不了解“人心”,不感同“人心”,你的流程也会难以服众。
- 你的流程是否合理?
- 你的流程是否代表大多数,而不是个性化、差异化?
- 你的流程是否具有权威性?
- 你的流程是你拍脑门想的吗?是看某某权威的书启发的吗?
- 你的流程被挑战时候,是否妥协了?
- 你的流程是为谁而设计?代表组织的利益吗?或让组织因此而收益吗?
- 你的流程目标是什么?是为了改进吗?还是为了控制约束别人,发号施令?
- 你的流程是否大家都知道并能5秒内找到?是否只是“红头文件”,束之高阁?
工具的"神圣使命"
好像流程里,很少提工具,甚至“一笔带过”,那你的流程靠什么落地?
哇塞,工具啊!工具无敌,工具牛逼,工具能解决一起问题。彷佛霎那间,看到了胜利的曙光~, 仿佛工具一夜之间成了“救命稻草”,“银弹”。
”工具“突然被赋予了“神圣重任”
- 流程落地靠“工具”了
- 我买了你的“工具”,是不是我们流程就跑顺了,就规范了
- “工具”能不能给我出数据,能不能帮我XXXX,流程里面提到了“工具”
工具背后的“复杂性”
提到流程背后“工具”,我必须拿出下面这张图来说道说道
- 如果你的团队/组织只有10人左右,可以直接跳出这篇文章,因为你确实不需要工具“规范”
- 如果你的团队规模在超过10-50人(且属于一个团队),定义“简单的”规范即可,能说清楚就好;工具文档怎么说,按照怎么做就好
- 如果你的团队规模/数量,达到百人以上,那么你真的需要认真考虑下“工具规范”
面对如此之多的各种“DevOps”工具,每个领域选一个,最起码也有10+吧。如果工具的“规范”都没有,“流程”怎么可能落地?
- 工具怎么用?学习成本如何?
- 怎么命名规范一致?
- 怎么申请?
- 怎么协作?
- 怎么用好?
- 怎么采集数据?
- 怎么按照最佳实践?
- 怎么满足流程要求?
- 怎么面对个性化需求?
- 怎么满足既要,又要,还要?
- 怎么让工具“匹配并支持”流程
是不是很崩溃,这其实就是DevOps难以落地的其中一个原因~ “众口难调”和 “众望所归”,“自动化的工具体系”是“组织”最后的救命稻草。
工具背后的“规范”
如何把“众口难调”,变成 “说一不二,不可辩驳,被“驯化”,被“教育””,不管你是买,还是自己搞,这都是工具背后要去思考的。无非你买来的,人家帮你理清楚一些规范了,可是依然不能满足“众口难调”。
没有“完美的”工具,不要指望世界上有一款工具,能满足所有人的要求,所以“工具”要学会说不。满足所有人,就意味着不可能“好用”,甚至会成为“负担”。
- 立规矩
- 教育用户,引导用户
- 学会拒绝,不能拒绝就摆烂
- “一味迎合”,最终会是“一地鸡毛”
流程是死的,人是活的,解决什么问题?
这里要谈谈,为什么要有流程?
- 具体解决某个问题?经常出问题,所有要通过流程约束?
- 流程过时了,还要一味遵守吗?
- 流程不能解决问题,是不是证明原来本身就有问题?
“能够“ 切实解决问题,为团队减负的流程,才是好流程。一味不断加码,还不解决问题,谁会愿意遵守?
反模式
- 画个流程图,能满屏各种角色,这不是流程的问题,而是组织架构的问题,大道至简
- 一开始设计完美的流程,就意味无法落地-流程要在试错中不断完善,并且与“工具规范”磨合
- 缺少“工具规范”和最佳实践指引,没有“周到细致引导”的流程,谁会遵守呢,团队成员需要被“教育培训强化”
- 工具先行,靠工具来推动流程,把“工具”或者 DevOps当作“银弹”
- 设计流程的人,没有深入贴近群众,走进群众,甚至不考虑落地
- 过度迎合纵容“群众”,你是代表组织的,纵容迎合就是破坏自己亲手制定的流程
- 老旧的“流程”,还不舍得放弃,层层加码,“学会做减法”
总结
最后,简单总结,其实就是这么几个要素。每个要素不能自洽,或者缺失,很可能这个流程就无法落地,并深入执行。
- What - 流程定义了做什么
- How - 规范定义了怎么做
- Who - 谁来参与
- When - 什么时候做
- Why - 为什么要这么做?
”流程“ 和”规范“密不可分,流程代表了组织的角色协作,”规范“指导了如何做的问题。
- 没有”流程“哪里会有”规范“;
- 没有”规范“,怎么可能促进”流程“的运转;
- 清晰的“工具规范”有助于平台的建设,事半功倍
- 流程要”简单“,规范要”细致且严格,才会有事半功倍;否则”流程“就会成为”一纸空文“。
关于我,一个”野生“的DevOps实践者,不讲理论,没有认证加持, 从”实践“中反思总结改进。