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

x33g5p2x  于2022-08-17 转载在 其他  
字(3.1k)|赞(0)|评价(0)|浏览(305)

很久没有写文章记录了,上一篇文章像流水账一样,把所见所闻一个个记录下来。这次专门聊聊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实践过程是漫长和艰难的,平台能力是整个组织一起努力的结果,不要试图你的团队单枪匹马搞成这个事情,离不开你的“客户”(需求),离不开上层领导的支持(自上而下推动),离不开组织运营规范的牵引(流程规范)。

相关文章