关于devops:DevOps落地实践点滴和踩坑记录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 实际过程是漫长和艰巨的，平台能力是整个组织一起致力的后果，不要试图你的团队人多势众搞成这个事件，离不开你的“客户”（需要），离不开下层领导的反对（自上而下推动），离不开组织经营标准的牵引（流程标准）。