为什么 DevOps 需要一个内部开发者平台
来源：《云原生》第5期
越来越来多的组织开始搞敏捷和 DevOps 转型，打造了很多的 DevOps 基础设施，比如有管理需求的 Jira， 有持续集成的 Jenkins，有容器编排的 K8S 等等。可是这纷繁复杂的 DevOps 工具链，同时也给企业带来新的困扰。
想象一下如果企业有10几个产品研发团队，每一个团队独立维护自己的技术栈、工具链和流程。这些团队大概率都会去解决类似的问题，导致在技术栈的集成、基础设施维护等方面投入太多的时间和人力，这些成本本应该投入到团队实际负责的产品价值创造中。同时缺少对技术和流程的标准化，也会产生其他问题：跨团队的知识共享会变得非常困难；在云原生时代，许多产品开发团队实际上并不具备基础设施架构运维的专业知识和技能。
因此需要有一个具备自服务 API、工具、服务、知识库和技术支持能力的内部数字化平台产品，应用产品开发团队可以利用该平台以更快的速度交付产品功能，减少协调。
CI/CD Pipeline在 DevOps 中的重要性
DevOps 就是为了打破开发人员和运维人员之间的“Fence”，而CI/CD Pipeline 可以帮助实现这个目的。同时，CI/CD Pipeline 有利于缩短应用的发布周期，提升应用的发布效率，为市场需求做出及时的响应。
Gene Kim 主创的小说体 IT 管理读物《凤凰项目》是公认的 DevOps 入门第一本书，书中比尔团队的故事很好佐证了上述观点，当比尔团队厘清业务部门 ( Dev )与 IT 部门 ( Ops ) 在凤凰项目中的部署流程，并通过自动化“流水线”改造后，极大提升了凤凰项目发布频率和成功率的同时，业务部门和 IT 部门的矛盾也变得越来越少。
DevOps为什么需要可观测
企业管理协会 ( Enterprise Management Associates ) 小组最近的研究表明，DevOps 团队在2021年面临的第一大挑战是可观测性。报告显示，开发和运维团队 50% 的时间都花费在了查明问题的根本原因上面。此外，专注于可观测性的团队能够将开发速度提高 70%，并以将近四倍的功能数量保持更高的产品研发速度。
如何打造CI/CD Pipeline 可观测性
目前 Pipeline 虽然有广泛的应用，但低效率的、不稳定的 Pipeline 往往会影响变更的部署频率，降低交付质量，更严重的甚至会阻塞开发流程。实际使用 Pipeline 过程中，会有很多因素导致运行一次 Pipeline 的时间会很长，比如：
» 可以并行的任务没有并行执行，等待的任务拉长了整体执行时间
» 运行 Pipeline的运行时（RunTime）的资源不足，导致任务排队时间太长
» 没有使用缓存，虽然是运行相同的构建，但每次都需要重新下载全部依赖
因此商用的 CI/CD Pipeline 必须具备良好的可观测性。
下图来源于 MiK Kersten 的《Project to Product》，Flow Time 是衡量一件事从开始到结束需要多长时间。在 DevOps 中，Flow Time 是指客户需求（Request）被接纳时，计时开始，当对应该需求的变更生效并在生产环境中运行时，计时结束。
价值流示意图
具备价值流能力的CI/CD Pipeline可以自动化得跟踪和统计组织内组件的迭代 FLow Time，直观反应组织内不同团队的 E2E 软件交付效率。
CI/CD Pipeline 自身的数据可视化，度量指标包括构建频率、故障率、平均或P95执行分布时间等，不仅可以让开发人员能过深入了解 CI 测试和 pipeline 执行失败的原因、监控测试集的实际耗时，同时也可以了解 CI/CD 工程本身的运行健康状况和性能。
可观测性不是“银弹”
数据驱动的DevOps 工程化虽然有助于研发效能提升，但是真正研发效能的提升的核心还是在于研发团队工程技能的提升，比如需求分析技能、架构设计技能、编码技能等。所谓 DevOps 就是将人、流程和技术结合起来，持续为客户提供价值。
点击下载>>云原生（第5期）
- 点赞
- 收藏
- 关注作者
评论（0）