DevOps落地实践点滴和踩坑记录-(1)-迷茫与焦虑

记录初衷

本人一直在从事企业内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自研平台，也应该是小步迭代地实现度量数据的收集。不要一上来就设计和实现大批量的度量数据。因为大批量交付度量指标，会让这批度量指标很晚才能交付，不利于尽早度量。

• “如果问题很明显了，有必要做度量，去暴露问题吗？感觉既然很明显了，就先改进解决问题”
  问题很明显了，也有必要做度量。一方面能通过度量数据，让领导和团队看到现状。另一方面，在改进问题期间，收集度量数据所形成的变化趋势，能让大家看到改进举措是否能有所成效。

目前，真正进行内部度量体系的建设，快被搞崩溃了。前期的基础数据准备相当重要，业务之复杂远超工程领域，后面再单独写文章聊。

未完待续

先写这些，后面遇到更多的坑，再分享出来。