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

本文主要是介绍从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实践者，不讲理论，没有认证加持， 从”实践“中反思总结改进。

---

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