DevOps落地实践点滴和踩坑记录-(2) -聊聊企业内部DevOps平台建设

开启掘金成长之旅！这是我参与「掘金日新计划 · 12 月更文挑战」的第2天，点击查看活动详情

很久没有写文章记录了，上一篇文章像流水账一样，把所见所闻一个个记录下来。这次专门聊聊DevOps平台的建设吧，有些新的体会和思考，希望给正在做这个事情的同学们一些启发吧。 DevOps落地实践点滴和踩坑记录-(1)

企业落地DevOps该买商用还是自己研发呢？

很多团队刚开始都会问这个问题，我的回答如下

• 如果团队人数少，技术栈或者技术债务不是很多，历史包袱不重，领导急于看到成果，可以使用devops商业产品。前提还是看商业产品是否满足你们目前场景。
• 自建工具链，分成简单工具搭建 和 更上一层的二次开发做平台，看你们需要哪种。
  • 前者相对容易点，比如常见的gitlab+jenkins+harbor/nexus+kubernetes等这样的组合
  • 后者 前期需要投入成本，还是看 你们目标是什么，解决什么问题。

以终为始，看目标，找合适的方案，是比较合适的。平台可大可小，功能也可大可小，解决的问题也可大可小，看看目前的问题是什么？

有哪些好用的DevOps价值流交付平台推荐？

国外

• Azure DevOps

国内

• Coding
• 蓝鲸
• JD行云
• 阿里云效
• 简单云ezone
• 华为DevCloud

国内很多，以上这些都算是整合各个环节比较综合的，其他像禅道、Ones等这些项目管理类平台虽然号称DevOps平台，但是他们更擅长垂直领域，不是综合性平台。

有哪些好用的DevOps VSDP（DevOps价值流交付平台）推荐？ – 知乎

自研DevOps平台面临的问题

上面说的平台都很好，但是面对上千规模的研发团队，往往会有“心有余力不足”，“杀鸡用牛刀，但是还杀不了鸡”的感觉。说白了，就是买了还是做二次开发，并且往往还不是简单二次开发这么简单。听我细细道来

1. 企业内部各平台鱼龙混杂

对于中小型企业，你可以通过采购外部DevOps平台服务的方式，快速形成战斗力。但是对于一定规模的企业，并不是一穷二白，而是各种平台已经存在了。 这是一个企业的案例，很明显管需求的在OA, 管工单在一个系统，项目管理在另外一个系统。那我买了外面的平台（一般都是全家桶的解决方案），到底和我内部系统怎么融合呢？

• 举个例子，如果公司已经用了JIRA, 外面大部分DevOps平台都自带同类功能的模块，你让我把JIRA干掉，买你的产品，尽管JIRA国内有点水土不服，但是这需要管理者做出抉择，哪怕是数据迁移也是需要成本和时间的。

2. 自研平台本质还是“企业的数字化转型”

对于传统软件企业，他们要的平台不仅仅是一个跑CI/CD，做部署的平台，更重要的是能够度量内部变革成果的平台。提到度量，就意味着你要打通整个研发过程所有环节，从外部客户需求，到内部研发环节，到对外发布，再到产品反馈，形成闭环。 可以想象，变革过程会遇到多少不同的角色，不同的平台，所以研发打造自己平台的过程也是企业内部自我变革的过程，这个过程会很漫长，也会很痛。

• 对于互联网企业，他们必须拥抱变化，快速抢占市场，所以从基础设施到人员素质，一定程度上比传统软件企业会好很多，数字化程度会好很多，他们关注更多其实是线上的快速发布，回滚，试错，监控告警。技术栈上，相对容易统一，个性化定制会很少，一般都是主干开发主干发布，或者主干开发分支发布。
• 可是，对于传统企业，他们的特点是产品线丰富，客户定制化需求多，重产品定制（轻运维），他们更需要规范化的管理和规则限制。但是往往他们的技术设施（容器化，环境快速生成）比较落后，研发人员不太重视工程化手段解决问题，技术栈没有很好统一，工具各个团队各自为政，因此整合工具链条就变得更艰难。

所以自研平台本质还是企业自我的变革和决心，如果把传统软件企业比作工厂，通过自研平台进行功能和数据的整合，就是希望构建一个真正的“数字化“工厂，让信息流动和共享。

3. 自研平台建设离不开部门间的拉通对齐

如下图所示，DevOps涉及诸多研发阶段和领域

• 项目管理
• 需求/缺陷跟踪
• 代码管理
• 构建/部署/测试
• 发布
• 日志监控

在企业内部刚起步阶段，可能缺乏专业的DevOps专家和人员，以为只是通过建设不同领域的工具平台，不知道如何拉通，为什么拉通，甚至可能不同的部门团队负责不同领域的工具。 缺乏最终目标的对齐和部门间拉通，可能导致如下问题

• 影响整体技术架构设计，可能导致很多返工
• 部门间配合缺失，各自为政，不仅无法形成合力，还可能相互掣肘，相互可能在做重复工作
• 无法制定长远平台演进规划
• 数据拉通遥遥无期
• 最终可能导致DevOps变革的失败，团队士气低沉，领导层看不到预期效果

解决思路-组织结构

1. 成立虚拟的过程改进团队，包含组织级研效管理团队，平台工具建设团队，效能/工程教练团队，对业务研发团队进行支撑
2. 业务研发团队对效能提高负主要责任，每个月业务技术leader 汇报进展；业务研发团队需要证明自己技术架构改进，解决成员的抱怨；需要对自己团队负责；
3. 杜绝“工具平台团队”对效能结果负责的局面，工具团队一般提供的是通用的功能，对于“北极星”指标（ps:产品成功的关键指标）影响有限； 对技术负责，打包更快，上线工作流更好
4. 效能/工程教练团队要走进一线，和团队成员面谈，深刻了解团队“痛点”，进行辅导
5. 组织级研效管理团队（一般是PMO组织），建立组织级规范进行发布；（PS: 实际情况中，该部门可能需要DevOps工具/教练团队的支撑，特别是工程技术方面，避免规范无法落地）
6. 需要一位德高望重，技术能力威望都还可以的领导统领过程改进团队 （PS: 解决拉通过程的困难，帮助协调资源，敢于拍板）

4. 围绕“版本”和“关联”做文章，构建研发领域模型

• **”版本“ **记录了整个研发过程的演进，通过“版本”作为纽带，串联起来真个研发过程的元数据，再合适不过。
• **”版本“**的规范化，也是流程规范化的重要体现，只有“版本”规范化，过程才可能规范化。试想，如果你的组织连规范的版本号以及发布规范都没有，其他自动化手段就根本不用提
• “版本”关联元数据 – 在笔者看来，是整个DevOps平台的重要目标之一，如果没有做到这一点，必然影响价值流打通

构建研发过程领域模型，可以帮助平台建设者理清业务实体之间的关系，指导平台的技术演进，串联起领域实体也是整个DevOps平台的重要目标一致

5. 围绕组织内真实业务场景，避免照虎画猫

在我们自己建设DevOps平台过程中，往往会参考一些商用的平台，这个无可厚非，但是要避免“机械模仿”。任何一家公司的DevOps演进都不是一蹴而就，或多或少都有历史原因，模仿的同时要思考他们为什么要这样做，是不是真的适合自己的场景，借鉴可以，但是要弄清楚为什么需要。 举例说明

• 大部分公有云的DevOps平台基因里都或多或少都有互联网的基因，它们的对于持续部署发布（灰度，蓝绿）会格外重视，那么作为传统软件企业，你是否真的需要？
• 再比如，这些平台的流水线编排都很灵活，但是在你的企业过度的灵活是否真的有用？ 也许开发团队只需要傻瓜式的，甚至无脑，严格控制的流程呢？

熟悉组织的软件研发活动，通过和业务研发团队座谈的方式，收集真实的痛点，在“灵活模式”和“死板模式”中需求平衡。功能做的再酷炫，不能解决实际问题，也是没有任何价值的。 如图所示，可以通过绘制业务流程图的方式，将平台的业务流程和实际的业务场景结合，指导平台分阶段建设，业务与技术演进相结合。

总结

上面我分享的几个问题，相信你都会遇到，这里仅供参考。每个组织想要的DevOps平台是完全不一样的，别人的场景功能未必就适合自己，主要还是以解决问题为目的。 DevOps实践过程是漫长和艰难的，平台能力是整个组织一起努力的结果，不要试图你的团队单枪匹马搞成这个事情，离不开你的“客户”（需求），离不开上层领导的支持（自上而下推动），离不开组织运营规范的牵引（流程规范）。