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

devops,实践,落地,角度,谈谈,流程,规范,模式 · 浏览次数 : 32

小编点评

**流程规范是指明确说明流程执行方式的规格、要求、标准、方法等信息,以便帮助开发人员理解和执行流程,以实现流程的规范化。** **流程规范的意义是:** 1. 明确流程执行方式,便于开发人员理解和执行流程。 2. 促进流程的重复性,提高流程的效率。 3. 降低开发人员的学习曲线,提高开发效率。 4. 确保流程的质量,提升流程的可靠性。 **流程规范包含以下内容:** * 流程步骤:详细描述流程的各个步骤,包括哪些工具或技术使用。 * 流程需求:描述流程的各个需求,包括哪些数据、工具、资源等需要使用。 * 流程规则:描述流程的运行规则,包括哪些安全约束、错误处理等。 * 流程日志:记录流程执行过程中的日志,以便分析和改进流程。 **流程规范如何帮助DevOps落地?** 1. 明确流程执行方式,便于开发人员理解和执行流程。 2. 降低开发人员的学习曲线,提高开发效率。 3. 确保流程的质量,提升流程的可靠性。 4. 促进流程的协作,提高团队合作效率。 5. 方便进行流程测试和调试。

正文

最近在经历的一些事情,让我突发灵感,觉得要写点关于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实践落地的角度谈谈“流程”和“规范"的反模式相似的内容:

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

最近在经历的一些事情,让我突发灵感,觉得要写点关于DevOps体系建设过程中的“流程规范”,记录下来。 如何解读"流程规范" 谈到DevOps落地,无一例外都会提“流程规范“,我想没有人会反对,甚至会”不放在眼里“,因为概念本身没有什么晦涩难懂。可是一到落地,好像就是另外一番场景,“一地鸡毛”,“形

DORA指标:公司业务成果的“占卜师”

从DORA指标出发,一起探索 DevOps 实践与业务成果之间的预测联系。

【敏捷研发系列】前端DevOps流水线实践

作者:胡骏 一、背景现状 软件开发从传统的瀑布流方式到敏捷开发,将软件交付过程中开发和测试形成快速的迭代交付,但在软件交付客户之前或者使用过程中,还包括集成、部署、运维等环节需要进一步优化交付效率。因此Devops的产生将敏捷的相关理念扩展到运维侧,从而将产品、设计、开发、测试、运维团队更紧密的结合

一文梳理2048小游戏从开发到上云全流程

摘要:本文主要以Cocos2d Web项目2048小游戏的开发上云为例,介绍DevOps开发实践的全流程 前言 本文主要以Cocos2d Web项目2048小游戏的开发上云为例,介绍DevOps开发实践的全流程,主要涉及开发工具为华为云软件开发平台DevCloud和CocosCreator。按照整体

DevOps全面综述:从概念到实践

这篇文章详尽介绍了DevOps的背景、核心实践、工具和技术,探讨了团队协作、文化建设及组织变革,旨在帮助企业高效实现持续交付和创新。 关注作者,分享互联网架构、云服务技术的全维度知识。作者拥有10+年互联网服务架构、AI产品研发经验、团队管理经验,同济本复旦硕博,复旦机器人智能实验室成员,阿里云认证

研发效能DevOps推荐书单

专注 300 页之内的经典书籍推荐 研发效能涉及的知识很多,从大的方向去划分包括制度、组织、平台、运营等;单从软件研发的角度去看也包括很多,包括最底层的软工认知、实践,到团队管理和组织、敏捷研发,项目管理、源码管理、发布管理、可观测性,到产品的运营和反馈。 现在很多公司已经组建了或者正在组建研发效能

AI 和 DevOps:实现高效软件交付的完美组合

AI 时代,DevOps 与 AI 共价结合。AI 由业务需求驱动,提高软件质量,而 DevOps 则从整体提升系统功能。DevOps 团队可以使用 AI 来进行测试、开发、监控、增强和系统发布。AI 能够有效地增强 DevOps 驱动流程,从开发人员的业务实用性和支持的角度来看,评估 AI 在 D

NodeJS 实战系列:DevOps 尚未解决的问题

本文将通过展示 NodeJS 应用里环境变量的提取过程,来一窥 DevOps 技术是如何应用在现在云平台上的运维工作中的。同时我也想让大家在这里看到 DevOps 的另外一面,即它并非全能,从本地开发到持续部署再到实际运行,有一些运维鸿沟依然还未被填平。“人工操作”依然是工作中的最大风险。

DevOps 必备的 Kubernetes 安全清单

Kubernetes 是当今许多公司采用的容器编排平台,它的实施需要对其生态系统有一定的了解,以便部署一个准备好用于生产的集群。然而从原则上来说,Kubernetes 并不是一个安全的平台,因为它缺乏处理大多数与安全相关任务的本地工具。 因此,Kubernetes 的实施工作原理或工具至关重要,这个

从 DevOps 到平台工程:软件开发的新范式

DevOps 是一种将开发和运营结合起来的方法,在应用规划、开发、交付和运营方面将人员、流程和技术结合起来。DevOps 使以前孤立的角色(如开发、IT运营、质量工程和安全)之间进行协调和合作。一直以来,DevOps 的采用都是以帮助企业更快地向客户提供价值,更好地适应市场和竞争,并保持系统的稳定性