顾黄亮：了解DevOps：实现协作、工具化和价值交付

在 DevOps 的实践和落地过程中，其价值输出是分阶段的，不同能力子域的能力输出和不同阶段的能力输出是可靠 IT 和敏捷 IT 不断融合的过程。在企业的业务创新过程中，这种有机结合的方式能够让企业的 IT 组织站在更高的位置进行科技赋能，对业务转型提供更好的支撑和帮助。

根据 DevOps 落地的模型，我们可以得知，组织、技术和流程是 DevOps 的核心要素，文化、工具和能力输出是 DevOps 落地的 3 个阶段。要素和阶段是 DevOps 落地基本原则中的构成部分：

• DevOps 推进者的原则；
• DevOps 管理者的原则；

• DevOps 各能力子域的原则；

在 DevOps 的实践和落地过程中，企业会遇到各种各样的问题。常见的问题分为以下几类。

• 相关能力子域对 DevOps 有超出预期的计划；
• 推进太快，导致在 DevOps 的实践和落地过程中出现断层；
• 工具选型不清晰，导致工具组链失败；

• 数据生命周期管理缺失，导致度量和反馈不准确。

近日，ITPUB 有幸采访到《DevOps权威指南》作者顾黄亮老师，一起探讨敏捷开发、持续部署、持续集成等内容，以及如何做好 DevOps 流程中的安全等问题。

大家好，我是顾黄亮，畅销书《DevOps权威指南》和《技术赋能 数字化转型》的作者，中国商联专家智库入库专家、国家互联网数据中心产业技术创新战略联盟（NIISA）智库专家委员会副主任委员、江苏银行业和保险业金融科技专家委员会候选专家、工信部企业数字化转型IOMM委员会特聘专家、江海职业学院客座讲师、财联社鲸平台智库入库专家、中国信通院可信云标准特聘专家、中国信通院低代码/无代码推进中心特聘专家，腾讯云最具价值专家TVP，阿里云最有价值专家MVP，容器云技能大赛课程出品人，多个技术峰会演讲嘉宾，拥有丰富的企业级DevOps实战经验，专注企业IT数字化的转型和落地，致力于企业智慧运维体系的打造。

问题 2：数据关联和数据联动中，如何保证数据完整性、一致性和鲜活性？

在CMDB的范畴中，通常由物理设施、应用、数据库、流量调度或请求链路构成。应用、数据库、流量调度三个模型的关联是双向的，而物理设备、网络设备和存储设备的数据关联是单向的，这是基础架构的特性。如果将任何一个应用实例进行模型化展示，PaaS层模型之上会关联另一个模型，每个模型都有一个属性数据供其他模型进行使用，从而衍生出一个庞大的数据关联图。因此只要任何一个属性数据发生了变化，相关的数据关联都会发生变化，甚至会引发数据联动的情况。举一个简单的例子来描述CMDB范畴内的数据关联，当运维团队对某个对象进行监控时，收到一个监控指标的预警信息，运维负责人首先关注是否影响业务连续性或可持续提供服务的能力是否受到影响，具体负责这个对象的工程师需要在短时间内对这个对象的上下游关系进行故障排查，如这个对象的故障是否因下游组件造成，是否对上游系统造成问题，这个对象在应用服务中处在什么环境，是否具备高可用能力，所承载的应用属于那个团队，近期是否有变更，是否和其他组件存在依赖关系，是否因为基础架构自身的原因造成。在这个时候，就需要一套完整的CMDB数据关联的拓扑图谱，如应用拓扑、集群拓扑、模块拓扑、容器云资源拓扑、数据关联关系。

在DevOps的度量反馈范畴中，数据关联和数据联动通常用在交付度量、需求全生命周期管理度量，后评价度量，因此需要将研发数字化的所有数据进行标准的采集、处理和分析，如接口系统、研发管理系统、自动化测试系统、需求管理系统、应用监控系统、配置中心系统、统一鉴权系统、运维流程系统，双边系统在对接过程中，任意两个模型都需要通过数据关联的方式，形成单向或多向的关系。

问题 3：何时才是企业运用DevOps的合适时机？如何定义数据的关联粒度和维度，更好的在DevOps过程中连接业务场景和基础设施？

关于数据的关联粒度和纬度，本质上是形成最终可度量的数据指标，让参与者和管理者更好的发现主观事件客观呈现的效果。比如说，在实际的度量过程中，工程效率管理是研发活动的典型度量场景，通常会遇到一些常见的度量误区。在需求分解成任务，任务挂靠研发团队的环节，项目经理通常会进行研发组织的工时预评估，在项目实际进行过程中，进行人员能效的实际评估都会出现各种因为数据指标覆盖率不全，或者度量方式不一致、价值输出口径不同、虚荣性指标过于凸显的问题产生困惑。因此会衍生出如下疑问，你说的数据，我每天都在统计，可这些数据怎么就成体系了？做成了体系又能怎样？为什么我不觉得基于我的团队或者个人指标不成体系？因此，DevOps团队需要根据DevOps实践计划，动态的定义数据关联粒度和维度，有数据的深入分析，没数据的进行采集。

问题 4：CI/CD是否需要分开？CI/CD部署需要哪些必要的组件，整个持续集成部署过程是怎样运作的？

持续交付应包括持续集成和部署，面向DevOps全局流水线，为IT组织活动的阶段性结束，持续交付基于项目管理和业务运营正向反馈，同时对IT组织进行滞后性度量，用来优化新项目和内部管理和过程优化，同时通过产品的市场表现进行项目后评价将DevOps的能力范围延伸至最终的价值交付，因此持续交付最佳实践是企业内部数字化度量问题。

通过下面一幅图可以了解持续交付的运作过程，部署结果由业务连续性进行深度主导、能力子域之间的协作以服务目录的方式进行、持续部署需要控制部署的泛滥、部署过程通过热部署进行、环境管理能够和云计算进行集成。

问题 5：DevOps在对生产系统稳定性要求较高的行业下如何落地？在devops大流行下，镜像如何优化，更贴近企业使用场景下的需求？

针对持续改进，有几种方式，比较常见的有持续集成阶段的改进，持续部署阶段的改进，持续交付阶段的改进，最终告别传统交付过程中的“大版本”和“全需求”模式。比如，通过持续改进让有价值的业务需求快速交付，最小化产品交付依托最小化成本的管理方式，测试左移、安全左移、运维左移和业务需求右移增加IT组织的弹性。

关于如何优化镜像，这个问题就比较聚焦，通常情况下，我们可以通过精简基础镜像、清理中间产物和减少层数的方式进行镜像的优化。如果我们在DevOps的范畴内，通过采取容器云特性的方式，增强DevOps的能力，如容器的快速部署，容器的镜像共享工程环境。随着容器的编排能力越来越强，对接DevOps工具的功能也不断增强，DevOps体系基于容器云平台的赋能效果将会越来越明显。

问题 6：CI/CD的安全隐患和面临的威胁，如何做好DevOps流程中的安全？DevOps 推行遇到的权责和数据安全问题有哪些？

CICD过程中的安全问题主要是质量交互不成体系，质量交互只要集中在环境管理、开发活动、配置活动、测试活动、构建活动、集成活动和部署活动中。通常，没有质量内建，将会导致技术债的逐渐恶化，还会导致项目进行过程中出现缺陷消减的矛盾，团队对于质量丧失信心，最终导致延迟交付，不能快速的将产品投放市场。

如何更好的进行质量交互，主要有几种方式，如工具的自动化集成、测试左移和代码评审。

DevOps工具链的自动化集成是质量内建的必备阶段，通过工具链的自动化集成可以实现自动化发布、自动化打包、自动化构建、自动化测试等，尤其是自动化测试能够更好的进行质量内建。通过工具的组链，能够实现“一切能被自动化的都应该被自动化”，有效的在集成、部署和交付阶段更好的保证质量。工具链的自动化集成能够完成知识的沉淀，将知识通过工具的方式进行正向传递，并能够提高效率，解放生产力，还可以固化流程，降低出错率。

测试左移主要集中在持续集成阶段，持续集成是一种软件开发的实践，即团队开发成员经常集成他们的工作，通常每个成员每天至少集成一次，也就意味着每天可能会发生多次集成。每次集成都通过自动化的构建来验证，从而尽快地发现集成错误。许多团队发现这个过程可以大大减少集成的问题，让团队能够更快的开发内聚的软件。持续集成阶段进行测试左移能够实现质量控制的左移，可以在集成阶段及时的进行质量反馈，越频繁的集成，意味着越早期的发现代码中的问题。

代码评审是质量的关键门禁，同时也是进行知识分享的一个途径。在代码评审过程中，需要在不同的阶段采用不同的评审策略。在团队稳定，编码规范掌握较好的阶段，评审的重点集中在业务逻辑方面，如在一个磨合阶段的新团队中进行评审，编码规范和编程语言的语法是评审的重点。在公司业务发展的不同阶段也需要采用不同的代码评审策略，如To B的业务在稳定推进，代码评审可能需要更仔细和严格，保证代码质量的同时也需要保证代码的可读性和可维护性。如To C的互联网业务，根据不同的业务发展周期，需要通过代码评审平衡代码走读力度和业务交付的要求。

问题 7：敏捷、持续集成/持续交付和 DevOps 三者之前有什么关联和区别呢？DevOps是否适合企业的所有场景？企业转型DevOps的关键要素有哪些？

回到敏捷，从本质上说，敏捷开发是关于软件开发的功能和模式，DevOps是关于提升组织级能效和质量的框架和方法，从过程上说，敏捷开发是关于开发、需求和项目管理之间的活动，DevOps是关于价值交付过程中所有能力子域的活动。敏捷开发和DevOps从表面上看是不同区域的活动，但目标是一致的，两者都是更好、更快、更完美的为客户创造价值，促进产品达成商业目标。在这过程中，敏捷开发和DevOps在过程上是协同和扩展的关系，两者都遵循敏捷的原则，将开发活动内嵌至价值交付全流程，同时DevOps也将敏捷的效益扩展至代码以外的活动中。

由于敏捷开发和DevOps的目标相近，因此在实践过程中，通常将敏捷开发当做DevOps的某个节点，或者将DevOps和敏捷开发所交叉的方法进行提炼，作为协作流程和沟通机制最终反馈到组织和文化，有助于提供客户快速的交付和极致的用户体验，最终达成降本增效和提质的目标。从全局的角度，二者的关系更多的是包含，可以通过敏捷开发驱动DevOps，同样可以通过DevOps将敏捷开发纳入至价值交付流水线，将敏捷交付的价值进行放大。

如果我们对DevOps的认知，上升到DevOps可以解决组织级的能效和质量，那DevOps可以用在企业的所有场景。在绝大多数企业，因企业的类型、业务场景、驱动模式、组织架构以及IT组织的规模和技术能力均不相同，甚至企业的经营层对IT的支撑能力和创新能力也具备不一致的度量和要求，因此DevOps落地要根据企业的实际情况因地制宜、因人施策、因势利导。笔者总结了DevOps落地模型，组织、技术、流程是DevOps的三要素，文化、工具、能力是DevOps落地的三个阶段，文化、工具和能力输出作为DevOps实践过程中的重心，折射出对组织、流程、技术的关注，无论是组合的多样性还是融入性，三者都应该融为一体，缺一不可。只能将组织、流程和技术的有机结合，通过文化、工具和能力输出的不同阶段进行推进，才能实现DevOps有价值的进行落地。

问题 8：对于 DevOps 系统工程中，组织架构上如何更好地设计？

企业在DevOps实践和落地过程中，形成了多种形式的衍变，从原生的研发、运维，到后续的研发、测试、运维，一直到项目、需求、研发、测试、运维、安全，目前已经具备两种核心方向，一种是以技术运营为主的价值交付，还有一种是以产品生命周期管理的价值输出，两者随着企业类型的不同而形成交叉，是一种包含和被包含的关系。

同时，一个理想的DevOps组织应该是一个跨IT职能的组织，成员组织可以包括运营、产品、需求、研发、测试、运维，还包括具备矩阵特性的项目管理和架构师。通常情况下，各能力子域的成员应该共享目标和价值，并对各自的过程和结果负责，具备统一的价值观，并有标准的流程和工具。组织负责价值交付和价值输出，而各能力子域需对最终的产品负责。而在实际情况中，各能力子域的职责划分要比DevOps的总体架构划分容易的多，这也导致了在实际落地过程中，因不同组织的模式而产生各种各样的问题。一般情况下，组织的模式会产生不同组织结构，而不同的组织结构会造成不一样的效率，笔者重点描述平衡式的DevOps组织模式。

在DevOps最佳实践中，成功落地的企业都具备一个相同的特征，通过跨职能组织的协同合作，共担职责，打破部门墙，并具备期望合作的愿望。因此，具备这种特性IT组织的能力子域是最有可能具备平衡式的DevOps组织模式。在实践过程中，相同的价值观促使组织成员同承担责任、实现共同目标，各能力子域也可以有效地合作以确保最终价值交付和价值输出。但这种高度协同的模式的达成是一个漫长的过程，需要组织的领导者具备高度统筹的能力，也需要技术的支撑具备一体化的赋能。在实践过程中，通常需要以某些领域达成阶段性目标，如DevOps的原生阶段，集中在研发和测试阶段，研发和运维阶段，需求和研发阶段，意味着有一个过渡阶段的组织平衡过程。

通常，组织内部会通过交付链路的关键节点来承担试点职责，具备此特性如研发的敏捷，测试和运维的自动化，需求的精准，项目的风险管理。这个试点成员也将成为DevOps文化的种子， DevOps的布道师、流程和工具相关的领域专家。

问题 9：未来，贵公司安全运维的规划主要包括哪几个方面？预期达到什么效果？

首先是组织的变革，相较于DevOps，AIOps的人员结构肯定也发生了一些变化，最显著的变化就是加入了算法工程师这个角色。有的团队会倾向于叫算法开发研发工程师，也就是既具备算法的能力也具备平台开发能力的工程师。当然如果一个算法工程师能够具备良好的工程能力，这个对于整体的团队发展肯定是有正向影响的。

其次是技术变革，随着微服务的发展，业务组网愈加复杂，问题的定界定位分析变得尤为困难。故障的识别和诊断是运维场景中智能分析的核心部分。AIOps提供的故障识别和根因定位能力，即是通过数据挖掘的手段，综合故障数据和人工经验自动提取故障特征，自动定位故障。

最后是能力变革，AIOps有广阔的空间，AIOps提供了运维领域范围极广的分析问题和解决问题的能力，涵盖智能监控，智能分析，智能搜索，智能执行等细分领域，提供可直接应用于产品策略的运维技术能力。

问题 10：如何实现“智能化”目标，需要“三步走”，即DevOps、DataOps和AIOps，这三者有什么区别？您对于运维从业人员有什么好的建议？

首先，DevOps到DataOps，再到AIOps，并不是一蹴而就的，如果从狭义上说，DevOps更多的聚焦流程的自动化，DataOps需要海量的数据进行度量和分析，AIOps具备“智能化”能力。AIOps不是到了某一个点就突然质变的，而是在持续演进过程中实现的。

通过DevOps阶段，大量工具的运用，形成全局的流水线。通过DataOps阶段，大量数据被采集存储和分析，形成数据仓库和数据湖。随着算法的日益成熟，整个运维体系也在改进的过程中逐渐完善，AIOps的道路才会慢慢清晰。

针对DevOps到DataOps，再到AIOps这个完整的过程，作为运维人员，需要在达到AIOps能力之前，还有很多的工作需要完成，包括构建端到端自动化的运维体系、将运营效能够通过数字化的方式进行度量，最后再是运维数据体系的建设。运维数据体系的建设又包含运维数据的治理、运维平台工具的建设以及运维场景的建设。建设完成后的企业已经基本实现敏捷运维体系，为AIOps的演进打下坚实的基础。