记录初衷
本人一直在从事企业内DevOps落地实践的工作,走了不少弯路,也努力在想办法解决面临的问题,期间也经历过不少人和事情,最近突然有想法把经历过的,不管好的不好的都记录下来,分享给和我一样的一线实践者。
我会通过一个个典型故事或场景来叙述,不谈理论,不谈技术, 只谈遇到的人和事,我和我的团队伙伴怎么解决实践中遇到的问题。
1)DevOps好像很火,我们也来做个搞吧
“DevOps好像大厂都在搞,听说能提高效能,我们的项目经常延期,要不我们也搞吧~”可能这是很多企业领导实施DevOps的初衷, 这个初衷本没有错,可是真的准备好了吗?想清楚做什么了吗?没关系,可以请外部专家讲下,听下来感觉就是一大堆工具的组合,不就是开发一个一体化平台吗?
如果只是看到了别人的成果,没有清楚中间付出的艰辛和改进,没有好的方法论指导,很容易照猫画虎,内部的改进“走形”!
2) 买了你们的平台,多久能有效果出来?
在企业DevOps实践初期,对于自研和外部采购还存在一些犹豫,一方面觉得如果自己投入资源研发,周期比较长,自己等不了,所以希望能够尽快通过成熟的外部工具快速达到自己的期望的目标。于此同时,外部的DevOps平台厂商或者咨询就会看到机会开始介入,对自己的产品和方案进行推广。对于外部的咨询和厂商 ,领导常问的问题就是“我买了你们的平台,多久能出效果?”,或 “你们过去的案例一般需要多久?”,“是不是我们买了你们的平台,团队可以马上用了”,诸如此类的问题往往令外部的咨询和销售无法回答,因为真正做过落地实践的人都清楚,不可能给出一个明确的答案。
其实,这种现象也反映了组织内领导没有真正清楚这个事情到底要怎么做,他们觉得工具能解决问题。这是对于DevOps的一个误区。
3)“DevOps”应该从管理层认可开始
DevOps出现之后,大家也许曾经提出或者听到过一个很关键却又普遍的问题——“DevOps转型应该从哪里开始?”
工作中,并非所有人都信任DevOps,通常遇到的第一个难题是得到管理层的认可与支持,因为DevOps的核心含义可能会掀起公司的大变革。
但是即使有管理层支持,如果管理层没有懂DevOps的带头人,往往也会出现“事倍功半”的情况,管理层基于得到结果,忽视了这是一次变革,不是某一个团队就可以进行的。
4)通过工具平台接入率来衡量改进效果?
在领导的支持下,企业开始打造自研效能平台,但是怎么推广呢?往往会陷入一个误区,就是开发了,大家接入使用就好了,接入使用效能自然就提高了。可是真的这么简单粗暴吗?
接入率能说明什么呢?接入好坏效果怎么评价?什么算接入?创建一条流水线,跑通了整个流程就算接入了,就能提高效能了?
企业为了推广自己的平台,让团队接入本来无可厚非,可是方法错了,如果为了团队的KPI, 团队自然会投入人力接入,可能团队自己没有认识到这个事情的价值,只是因为领导需要我们这么做。可以接入完了,团队继续按照自己过去的搞法玩,竹篮打水一场空。
5)找出问题比空喊口号更有用!-价值流分析
“你觉得你们团队能给团队带来哪些效能提升?”有次和上层开会,领导的这个灵魂拷问让我记忆犹新,说实在的,作为深谙DevOps理论和实践的一线实践者竟然不知如何回答。下来请教了很多行业内大咖,“找出问题就基本成功一半了”,这是一个专家的回答。突然我意识到,这不是就刚开始来找团队做的“价值流分析”吗,找到问题所在,走着走着迷失了方向~
虽然各家企业DevOps落地方案各不相同,但是有一个基本的共识就是到底要解决什么问题,只有真的弄清楚问题,才能想办法解决。
在实施初期,我们一般会选择比较有代表性的项目,进行调研和分析。我们会从需求管理、开发、代码管理、构建、测试、部署、发布这几个方面进行调研和分析,判断项目是否适合迁移到DevOps平台,项目研发过程的某些环节是否需要进行改进和完善。
- 需求管理:需求管理工具、用户故事、任务、迭代等
- 开发:开发语言、开发工具、技术框架、运行环境、组件划分及依赖关系等
- 代码管理:代码及文档管理工具、代码库分支及用途、分支策略、代码质量检测工具及质量指标等
- 构建:构建工具、构建过程及构建策略、构建介质策略、中间介质及最终介质管理等
- 测试:用例和Bug管理、自动化测试工具、验收标准等
- 部署:环境规划、环境配置、部署方式、依赖的中间件和公共组件等
- 发布:上线交付物、发布流程、应用及数据备份方式、回滚方式等
本阶段产出文档:调研问卷、提升建议和改进方案。
6) 寻找“反抗军”因为他们真的痛
项目试点是非常重要的环节,也是后续能否进行推广的重要评判依据。经过前期的项目改进,以及流程规范的普及推广,试点项目作出适当调整,试点项目的迁移是对之前所有工作的一个重要检验。
在试点阶段,一方面是要通过试点项目的规范化改造,打造同类项目的流程规范,形成可复制的流水线模式;另一方面看迁移前后给试点项目带来哪些好的效果,是否符合预期,是否还有需要改进的空间,平台能力是否需要提升等等。项目试点阶段产出的文档和手册是后续推广的重要资源。当试点项目的迁移达到预期效果,就可以进行DevOps平台的普及推广
但往往启动阶段,就会面临谁是第一个“吃螃蟹”的团队,这个时候寻找合适的“反抗军”是至关重要的,因为他们真的“很痛”,受研发效能底下困扰已久,他们迫切需要改变。这个初心比任何的行政命令更有效,这是发自他们内心的!
在和这些团队一起协作的时候,也需要主要投入产出比,上来不要找一些高大上的,不切实际的最佳实践。先让他们看到效果甜头,他们才愿意投入资源进行改造。当然,过程中必要的沟通技巧,和团队leader的个人关系也要搞好。
7) 平台建设思路
在DevOps实施过程中,工具链的打通必然涉及各种工具的整合。除了DevOps平台本身已经集成的Jira、Gitlab、Jenkins、Nexus、SonarQube等工具,比较常见的是对客户已有工具等集成,如客户自建的项目管理平台、CMDB平台、自动化测试平台等等。
对于用户自建工具的整合,首先需要去理清整合的真正目的是什么,能为用户带来哪些价值。比如,对项目管理平台的整合,DevOps平台可以对项目等迭代、需求、任务等信息进行收集和汇总,最终项目的进度、成本一目了然。再比如,对CMDB的集成,对于CD过程中使用的资源(主机、容器),直接从CMDB拉取数据即可,无需在DevOps平台中重新配置一遍。
这里建议,对已有工具的整合,整合的是数据,目的是让数据流转和汇总起来,而非做功能的整合。
规范化、统一化
项目迁移到DevOps平台,各个项目可以在一个统一的DevOps平台进行CICD,无需各自搭建持续集成平台。通过制定合理的规范,不同的项目遵守一致的规范,避免了代码库、CICD流程的管理混乱和不规范。制定度量指标和规范,对软件开发成果和开发过程的测量和分析,帮助对软件开发过程持续进行改进,有效提高软件交付质量和效率。
研发效能提升
可视化和可编排,无需编写pipeline脚本,一次配置,多次执行。提交或合并代码出发、定时触发或手动一键执行构建和部署,提高研发人员效率。有效减少系统变更部署上线的时间,快速响应业务变化。
报表展示、可度量
从效率、质量、进度三个维度展示任务、代码、构建、部署相关数据,结合项目看板、报表和度量指标,各环节干系人可以对进度、质量等进行判断和干预。
DevOps的建设是难以短期内完成的,需要进行总体规划,然后分阶段实施。无论是工具的整合,还是度量体系的实施,都需要按部就班、循序渐进,逐步完成建设,最终实现预期目标。
8) 以终为始,确立统一的目标,避免各自为政
上面一点提到了工具的整合,在企业组织内部,工具可能会分布在不同的部门里,主要涉及到项目管理,需求管理,代码管理,构建部署,测试等,DevOps效能平台的目标是拉通所有的工具,进行数据的整合。虽然说是工具的整合,其实不如说是工具背后部门间协作方式,和如何建立共同目标。
过去一段时间,笔者经历过各工具背后的部门间思想没有统一,大家名义上都在为一个目标服务,但是缺乏有效的统一目标和方案,说白了各自为政,这给后期的平台度量整合带来很大的麻烦,有可能系统要重新设计,各系统间的数据模型需要花大力气去适配和调整。
所以,其实在DevOps建设团队的内部也需要通过虚拟的组织和明确的领导模式来合作,避免资源浪费和冲突。一个明确的建设体系和组织,至关重要,自己都是松散的,怎么整合数据,怎么说服研发团队?
9)规范在哪里?避免停留在“纸面上”的规范
代码库规范:包括分支和标签命名规范、分支管理规范(管理流程、hotfix流程、分支策略)、代码提交规范。
以分支开发、主干发布为例,管理流程规范中会涉及代码库准备、开发集成、验收测试、发布环节,每个分支的用途,每个环节中涉及的角色,角色的操作流程都有详细规范。
CICD流程规范:命名规范:组件、介质仓库、构建定义、构建产物别名、发布定义。流水线规范:开发流水线、用户验收测试流水线及回滚流水线、发布流水线及回滚流水线、hotfix流水线。
通过制定流水线的规范,形成不同类型项目的CICD流程模版,可以作为组织级规范进行审计。
除了以上规范外,还包括项目管理规范,敏捷开发规范,测试管理规范,安全规范,发布规范,版本号规范等等。有的组织可能之前有了类似的规范,但是大多都停留在“纸面上”,实际落地很难,除非在研发过程有严格的卡点审核,否则团队很难落地执行。另一方面,规范先行很有必要,否则自研平台的开发就会形成无水之源,无本之木。
规范的建立,需要结合企业实际情况,需要流程制定部门和研发团队共同制定,并且基于可以落地的方式,而不是空口理论和举措,离开工具的标准,规范简直就是“白纸一张”!
10) 基于现状进行自研平台的开发,避免脱离团队实际
对于流水线的定义和设计,需要考虑客户的环境规划和网络策略。一般情况下,会设计和定义开发测试流水线、用户验收测试流水线、发布流水线这些常规流水线,对应开发测试环境、用户验收环境、生产环境。开发测试流水线经过多次执行,业务系统形成稳定版本,交付到用户验收测试流水线,通过用户验收测试之后,再转到发布流水线进行发布上线;这个过程也设计到代码分支和标签的维护。
有的客户,阶段交付物是某个版本的工件介质,并且介质库可以多环境共享或者同步,这种情况下需要在开发测试流水线中设计构建环节和部署环节,在用户验收流水线和发布流水线不需要构建环节,因为交付介质像下一个环境同步即可。流水线设计如下:
有的客户阶段交付物是代码,且各个环境有网络策略限制。这种类型的流水线,不同环境需要根据对应的代码分支或标签将介质构建出来,然后再进行部署。
这里想强调的是,自研平台的开发不能离开业务研发团队的实际场景,必须和他们进行沟通交流,如果单靠借鉴业界的通用流程,很可能最后会发现,团队需要的根本不是这样的。即不要离开业务场景去开发平台,需要和业务团队进行紧密的沟通和面谈,了解他们的需求,这也需要投入人力去梳理形成方案。如图所示,通过团队沟通形成交付流水线流程图,可以清晰的让双方达成共识。
11) 工具并不能解决问题, 必须依靠完整的DevOps体系
- 立项:务必获取高层领导的支持与推动;
- 目标:分阶段建设,明确年度目标,不宜贪大求全;
- 组织:结合建设目标和现状,明确牵头部门,关注跨部门协同的难点;
- 落地:规则约束,可先研讨、线下验证,再线上约束、逐步调整,且不宜初期就设置过于细致的规约;
- 文化:切勿重系统、轻文化,一定要关注人文关怀,重视组织文化建设,保障一个相对温和的实践环境。
- 完整的 DevOps 体系建设,不仅仅是新工具、新规则,更是新文化,而且在文化变革打头阵的情况下,很可能取得更好、更持久的成果,让组织具备自我纠偏的能力。
企业的DevOps实践绝对不是自研一套平台或者买一套商用平台,缺乏规范指引,团队赋能和培训,指标引导等要素会寸步难行,这真的不是夸张,而是来自一线的真实感受。这也是为什么DevOps落地如此之难的原因!
工具拉通,以平台为抓手,规范为指导,度量为方向,推进落地
12) 建立虚拟的工程效能改进组织
如图所示,左边需要建立虚拟的研发效能组织,包括项目管理,平台研发,运营推广,规范审计,敏捷教练,工程教练等诸多部门和角色,右侧对接业务开发团队,需要建立定期沟通机制,了解团队平台需求,同时提供最佳实践的培训和赋能。于此同时,度量指标结合规范一起制定,帮助团队持续改进。
13) 度量-效能提升永远绕不开的痛
度量,这是研发效能永恒的话题。抛开度量的业务和技术本身,探讨度量的所见所闻和所思。
企业管理者之所以关注效能提升,目标就是希望能看到度量数据,这是他们的刚需,其实并不是研发团队的刚需。如果真的把度量数据曝露在领导面前,研发团队的一举一动就摆在明面上了,一切以数据说话。这就是度量的两面性的根源。
那么在做自研效能平台时候,如何考虑度量的建设呢?我把之前提问专家的回复贴出来。
- “如果做DevOps自研平台,什么时候引入度量合适?”
无论是用devops工具平台自动收集度量数据,还是通过手工收集,合理的度量越早引入越好。因为度量数据的收集,需要经历一个较长的过程,才能看到供改进参考的数据。 - “可不可以边做,边设计指标收单点局部指标数据?”
可以,而且DevOps自研平台,也应该是小步迭代地实现度量数据的收集。不要一上来就设计和实现大批量的度量数据。因为大批量交付度量指标,会让这批度量指标很晚才能交付,不利于尽早度量。 - “如果问题很明显了,有必要做度量,去暴露问题吗?感觉既然很明显了,就先改进解决问题”
问题很明显了,也有必要做度量。一方面能通过度量数据,让领导和团队看到现状。另一方面,在改进问题期间,收集度量数据所形成的变化趋势,能让大家看到改进举措是否能有所成效。
目前,真正进行内部度量体系的建设,快被搞崩溃了。前期的基础数据准备相当重要,业务之复杂远超工程领域,后面再单独写文章聊。
未完待续
先写这些,后面遇到更多的坑,再分享出来。