企业 DevOps 落地实践经验分享
共 6805字，需浏览 14分钟
·
2023-06-21 21:25
来源：InfoQ架构师头条
链接：https://mp.weixin.qq.com/s/uMAh-uqerEpLtrrp-UYTTw
DevOps 始于 2009 年，这种范式让许多组织能够加快软件交付速度和提升业务绩效，正如“Accelerate 报告”及其著名的 DORA 指标——速度、稳定性和恢复——所描述的那样。
敏捷首当其冲，与 DevOps 成为组合，在相同的工作流中平衡业务价值和技术交付。
最近的一些实践，如可靠性或安全性，都采用了“SRE”和“DevSecOps”这两个术语。
然而，来自 谷歌、Puppet、CircleCI 和 Dynatrace 等公司的各种 DevOps 状态报告都揭示了他们对这个生态系统的一些相似的发现——难以持续及时交付业务价值和创新、孤立的团队缺乏一致性、碎片化的工具链和质量的牺牲。
本文将分享如何利用过去几年积累的经验和实践，通过质量工程来改进 DevOps 范式，从而带来更多的价值，并解决这些已知的痛点。
DevOps 没有固定的宣言，理由很简单——为演进留下空间。
“我们并没有对 DevOps 做出确切的定义。我们让它朝着各个方向扩展，研究不同方向之间的改进可能意味着什么。人们很纠结 DevOps 究竟是应该是怎样的。”——Patrick Debois，Snyk（之前的 DevOpsDays）顾问，摘自由 Puppet 和 CircleCI 提供的“2020 年 DevOps 状态报告”
最初促进开发和运营流程的 DevOps 概念走向了多个方向。在安全性方向有了“DevSecOps”，在深入 研究企业实践 后，谷歌甚至将可靠性作为指标的一部分添加了进去。
图 1. DevOps 继续在许多方向上发展演进
但当前生态系统中的创新和竞争在不断提高参与者的门槛。一些新公司可以在 不到 3 个月的时间 里达到 10 亿美元的估值，这给同一领域现有的公司带来了压力。因此，85% 的公司 感到有必要通过软件来重塑他们的业务以求得生存。
对于许多组织来说，软件交付仍然是一个业务限制因素。
图 2. 软件限制因素会直接对业务造成限制
因此，DevOps 目前的发展状态水平还不够高。业务价值、安全性和可靠性只是保持竞争力需要满足的部分需求。平衡质量和速度需要一个跨越整个软件生命周期（从业务想法到运维）的范式转换，要“构建得更好，构建得更快”。
要达到这一水平，DevOps 必须能够发展到通过全速质量软件（Quality at Speed Software）在工程系统的所有领域实现持续的价值交付。
DevOps 最初在从代码到运维方面进行了大量改进，这导致出现了许多专注于加速开发团队和运维团队之间的流程的方法。
然后，敏捷和精益等方法与 DevOps 结合，以便用更高的效率更好地关注价值交付，旨在实现“全速软件（Software at Speed）”。还增加了一些具体的要求，如持续性实践，包括监控、安全性或测试。
图 3.即使有了 Accelerate 报告中所提及的发现，质量需求也只是刚刚开始被考虑到
Accelerate 报告解释了软件交付和业务结果之间的正相关关系，定义了执行者类别——“精英”执行者们每天稳定地进行多次发布。
但随着每天多次交付成为当今竞争的常态，只能通过交付更多的价值来获得竞争优势。因此，DevOps 必须进行转变，以便更好地与现有方法集成，创建全速质量（Quality at Speed）流程。
图 4.DevOps 必须简化质量流程
第一个改变是综合“从客户到代码”和“从代码到客户”这两个数字转型流程，正如米其林集团首席信息官 Yves Caseau 在《数字转型的精益方法》一书中所说的那样。
DevOps 必须从一开始就将敏捷、全面质量和精益启动与全局视角相结合。将用户描述与 CI/CD 平台中的代码部署联系起来只是一个开始。共享的工作方式和支持工具必须进行更好地集成，以便实现更快、更有价值的从业务想法到运维的迭代。
第二个改变是创建专门的实验、核心业务和技术平台价值流。 与 DevOps 打破端到端孤岛的思维模式保持一致，每个流必须能够相互解耦迭代，以确保它们对质量和速度的需求能够得到满足。
图 5.左移是实现全速质量软件的范式之一
SRE 和 DevOps 是专门用于满足可靠性和安全性非功能性需求的流程。后续的演进目标是满足软件生命周期中的其他需求，如可观察性、可用性和可持续性，避免无法实现它们或试图在之后通过高成本的返工来恢复。
最后一个改变是系统性地应用端到端价值流约束理论。 整个生命周期中最薄弱的一点是确定 整个系统 的质量和速度水平，价值流映射和移除限制因素必须成为 DevOps 改进习惯的一部分。
虽然这些演进改进了协作流程，获得了更多价值，但预期的加速需要的不仅仅是方法。技术必须让组织能够快速地演化和采用软件。
为了支持更快的迭代，DevOps 非常强调集成和部署阶段的自动化。部署自动化通过为开发人员提供原生管道提升了软件质量，并降低了总体维护成本。2020 年 Puppet 报告 显示，超过 60% 的公司表示他们的 DevOps 处于中期演进阶段。
图 6.GitLab 2022 年全球 DevSecOps 调查报告显示，现代 DevOps 提升了安全性，但缺乏集成
好的方面是在利用技术和思维方式的变化为开发人员提供自助服务功能方面取得了进展。所有这些逐步利用云原生功能的自动化经验让我们能够更好地设想目标架构，从而帮助我们实现“更好、更快的构建”。
通过自助服务改进的自动化和协作生成了更多关于流程执行、性能和交互的数据。随着运维数据科学的不断成熟，部署的 MLOps 和 AIOps 组件将能够提供跨生命周期的持续可见性和自动化，就像 Sealights 那样。
图 7.DevOps 架构必须整合全速质量平台
DevOps 转变需要整合以下这些平台。
基础设施平台；
开发者平台；
实验平台。
每一个平台都是在彼此的基础上逐步成熟，以最小的承诺和返工来满足质量要求。这种渐进式实现就是所谓的 最小可行架构，通过交付最小的架构增量来支持产品迭代，实现更好的目标匹配和更快的采用。
基础设施平台 让运维团队能够通过自动化和云能力来提升生产力。这些改进可以用于构建 开发者平台，支持更快的核心业务变更迭代，同时又能满足多种质量需求，包括功能可用性、性能和安全性。
然后，业务可以利用满足质量需求的软件交付加速周期来迭代业务变更。在这个阶段，公司可以主张独特的价值，并且可以通过实验平台提供的自助工具和集成解决方案更快地实现它们。
图 8.Uber的实验平台
构建基础设施的工程师、开发人员和实验平台都要将用户视为他们的客户。每个平台的满意度和性能直接与它们试验和改进业务的能力挂钩，并最终提供良好的用户体验。
MACH（微服务、API、云、Headless）架构显著提升了平台组件的模块化、可组合性和可伸缩性。它不再是关于构建孤立的模块和框架，而是关于构建可伸缩的平台，为企业价值交付的加速周期提供支持。
这种技术转变需要团队在同一个愿景上保持一致，具备使其成为现实的灵感和动力，克服组织的阻力，并有效地改变在软件生命周期中参与协作的参与者的习惯。
这里是管理发挥关键作用的地方。
Puppet 的 DevOps 报告 中提到了让公司陷在 DevOps 转变中间阶段的文化障碍——阻碍冒险（21%）、责任不明确（20%）、缺乏快速确定优先级的能力（18%）——导致反馈循环不足，限制了公司加快价值主张的速度。
成功实现 DevOps 转变的公司明白，有效的管理对于打破现有的藩篱并实现更快的迭代流程是必要的。但是，从遗留文化模型到 DevOps 模型的重大转变让许多管理人员被困在技术和工程问题的泥潭里。
DevOps 团队需要专注于他们的工作，以便提高组织的成熟度和改进组织流程。然而，这导致一些人认为 DevOps 只是与工程问题有关。为了对迭代的端到端流程产生更大的影响，并交付更多的业务价值，管理者必须走出他们的舒适区。
图 9.DevOps 中的管理转变必须是端到端的，并且能够增加价值交付
DevOps 中的管理者角色必须改变其定位。
提升（Shift Up）DevOps 的价值定位并增加交付；
分享愿景，为产出结果赋能；
驱动端到端转型变化。
Shift Up 这个概念 来自软件质量，软件质量的定义、沟通和度量是在运维团队之外完成的，以使整个组织系统在质量需求上保持一致。例如，与 C 级高层、总监和业务线经理协作定义软件产品的质量需求。
其好处是通过让关键利益相关者对每个角色的价值和对软件产品的期望保持一致来改进变更管理。然后利用这个共识来获得必要的投资和支持，以实现质量需求和组织变化，特别是当它们涉及到技术时。
要让 DevOps 成为实现成功的数字化转型的必要条件也需要同样的转变。凤凰项目就是一个很好的例子，它向我们展示了 DevOps 是如何帮助改进业务的。推动 DevOps 的管理者必须走出他们的舒适区，与业务利益相关者互动，促进一种观念上的改变——即 DevOps 不是关于工程，而是关于加速业务再造。
第二个关于管理上的改变是在公司的所有团队之间系统地共享 DevOps 愿景，而不是将想法局限在工程领域。这种鼓舞人心的愿景必须涉及业务目标、设想的未来、即将到来的变化、风险和计划，这有助于团队实现这些变化。
图 10.DevOps 管理必须消除最重要的限制因素
这就要求管理者关注端到端的领导力变革。他们首先需要实现控制管理，为他们的团队赋能，解决跨组织的障碍，并改进业务价值交付。他们必须适当地分配工作，推动最大程度的变化发生。例如，当团队需要花费几天或几周时间定义规范时，却花时间在改进只能减少几分钟时间的自动化上。
管理层还要负责让组织保持一致，创建与目标业务架构保持一致的生态系统。
许多公司的重组都会更新可视化的组织结构图，但没有做日常的业务做出任何改变。他们通常试图让每个人都参与进来，让他们感受到“参与”和“包容”，但却未能给陷入重组周期的公司带来持久的变化和改善。
表面的重组有一个共同的问题，那就是没有让组织与流程保持一致，缺乏对不断变化的交互和强有力决策的关注，比如哪些团队应该首先做出改变，哪些职责必须发生改变，以及如何实现有效的责任模型。
DevOps 组织是关于如何实现业务再造。
图 11.DevOps 组织必须在以产品为中心的组织中与业务相结合
为了扩大 DevOps 的影响，必须进行结构化的改变。
定义真正的产品组织；
建立真正的“平台即产品”团队；
与职责模型保持一致。
要让公司采用产品组织模式，首先需要消除“产品管理”（即业务）和“产品工程”（即“IT”）的藩篱，从全局考虑问题。这种人为的分离仍然在许多组织中存在，让人们觉得藩篱仍然很重要，从而限制了沟通互动，造成了许多低效率的放任。
团队必须作为单一的跨职能单位，在拥有端到端流程全部所有权的地方专注价值流的交付。挑战在于如何组合团队，以满足他们职责范围内的特定质量需求。例如，致力于用户体验的部门与财务后台部门所面临的挑战是不一样的。
实现 DevOps 产品组织的第二个变化是采用《团队拓扑》一书中所描述的“平台即产品”方法。其目标是通过逐步创建一个提供自助服务平台、支持跨职能团队的专业角色或交付领导角色的平台团队让 团队的结构 和交互与目标架构保持一致。
图 12.用团队拓扑建立全速质量增量组织
为了实现上述的措施奏效，领导层必须做出强有力的投资决策，并向组织阐明这些投资决策。由于资源有限，公司不得不对投资做出权衡，但过多的妥协会导致绩效降低，远远达不到要求。
领导层必须决定哪些团队获得更多的资源——甚至可以超出保证服务持续性所需的资源，而让一些团队仍然使用有限的资源。他们需要阐明哪些团队必须为复杂的子系统（如单体系统）尽最大努力地工作，或者哪些决策仍然是中心决策，如为了保持一致性而采用的中心架构。
近来的演变还包括为实现“全速质量”目标而出现的特定角色。“交付所有者”负责价值交付流程，“实践领导者”负责高标准地开发专业技能，并确保知识得到共享。
组织一致性是促进和维持业务和架构转变的主要动力之一。在日常工作中，结构和交互的定义依赖于技术，但主要还是依赖于参与者跨生命周期的协作。最后一个重要的转变是技能。
对 DevOps 技能的关注反映了生态系统的成熟度，对“云工程师”的培训侧重于自动化、基础设施即代码，或特定的云服务部署。虽然这些基本能力都是必要的，但还不足以为公司再造提供足够的质量和速度。
图 13.DevOps 路线图仍然停留在较底层的技术上（LinkedIn）
面临的一个主要挑战是技能专业化虽然提升了质量，但同时也降低了交付速度。一方面，专业知识引入了更多的垂直领域，如“SRE”或“安全性”，但由于技能之间存在区别，这些专业角色之间的协作变得更加困难，这可能会影响价值交付的速度。
全球技术人才稀缺不利于应对这一挑战。组织努力吸引和保留转型所需的人才，而全球都面临着直接限制公司转型的人才稀缺的压力。一些重新转化人才和简化技术的措施有所帮助，但还不够。
为了实现全速质量，组织必须通过以下几个要素来平衡技能。
灵活和开放的职业道路；
在可扩展的技能（即平台）上的投入；
用于技能发展的专门资源。
第一个转变是拥抱更灵活、更开放的职业道路。许多组织甚至为 DevOps 引入了 Taylorism 模型，为特定任务设置了“云工程师”职位。不过，在利用他们的互补技能的同时，他们可以学习工作的中部分内容，从而让公司能够加速进一步的转型。
“T 型”技能出现在那些能够结合垂直技能（如软件工程师）和水平技能（如敏捷）的人身上。研究表明，这种模式正在朝着“π型”甚至“梳子型”的方向发展，人们能够结合多种专长，从而让与个人的合作变得更加快速，并让他们可以有更丰富的职业生涯。
图 14.在一个持续学习的生态系统中，DevOps 技能获得横向发展
这种适应和持续学习的能力意味着组织必须改变范式和生态系统来支持这种变化。他们必须为指导计划进行专门的投入，引入实践领导的角色来激励人们，并确保每周有系统的培训时间，而不是一年一次。
其他的实践，如实践社区、会议和演讲，对于培养一个有吸引力的生态系统来说仍然是很有用的。在这里，人们可以获得自我发展。Zalando、Uber 或 Netflix 等公司成功地将开源作为吸引人才的方式，同时对产品进行内源化，让人才能够在产品上进行全球性协作。
虽然并非所有的公司都有这些巨头那样的规模和资源，但所有的公司都可以直接在可重用和可扩展的技能上投入，如技术集成和平台。在一个技术组件变成模块化服务的生态系统中，公司需要构建的东西将更少，需要组合的东西将更多。
这种跨越方法、架构、管理、组织和技能领域的 DevOps 转变要求整个软件工程系统进行横向的演进，以便实现持续的价值交付。
文化、方法和自动化都是 DevOps 的良好开端，但我们的竞争生态系统只会维持那些能够通过全速质量软件迅速改造和扩展其价值主张的组织。
我们在想，基于这种演变，DevOps 是否还应该保持同样的叫法，毕竟它超越了“Dev”和“Ops”的界限，并成为支持组织数字化转型的不可或缺的支柱。
DevOps 的未来是 质量工程。
- END -
推荐阅读 30天拿下高含金量K8s CKA+CKS双认证！ Wireshark 找出 TCP 吞吐瓶颈 K8s Kubectl集群管理工具使用技巧 K8S 常用资源 YAML 详解 DevOps与CI/CD常见面试问题汇总 我会在Docker容器中抓包了！ 19 个 K8S集群常见问题总结，建议收藏 运维高可用架构的 6 大常规方案 运维监控指标全方面总结 9 个实用 Shell 脚本，建议收藏！ 详解 K8S Helm CI/CD发布流程 ES+Redis+MySQL，这套高可用架构设计太顶了！ 一台服务器最大能支持多少条TCP连接？ K8S运维必知必会的 Kubectl 命令总结 16 张图硬核讲解 Kubernetes 网络 史上最全 Jenkins Pipeline流水线详解 主流监控系统 Prometheus 学习指南 搭建一套完整的企业级 K8s 集群（二进制方式） 40个 Nginx 常问面试题 Linux运维工程师 50个常见面试题 点亮，服务器三年不宕机
