分享人：孙长虹 京东云 DevOps 解决方案架构师
复旦大学计算机系毕业，并拥有人民大学心理学硕士学位。曾任职于 Alcatel-Lucent，IBM 和惠普，具有丰富的大型复杂产品研发及项目管理经验，擅长组织级敏捷和 DevOps 转型，并拥有 EXIN Agile Coach, 业务敏捷，DevOps Master，以及 SPC 认证，也是 EXIN 授权敏捷和 DevOps 讲师。他负责京东云 DevOps 解决方案，也为零售、金融、交通等多个行业的大型企业客户提供过敏捷和 DevOps 咨询服务。
Question：如何理解 DevOps 与云原生之间的关系？
孙长虹：根据 Pivotal 的定义，云原生包括 DevOps、持续交付、微服务以及容器；其中，持续交付也是广义的 DevOps 一部分，因此从概念上来讲，DevOps 既是云原生的重要组成部分；同时也是云原生能力的一个集大成者。
云原生是业务快速变化背景下的必然技术趋势，云原生关乎速度和敏捷性，它的价值在于加速企业把新想法推向市场进行验证和实现增长；而 DevOps 能够帮助企业快速、频繁和可靠地交付软件，从而实现云原生价值。
云原生带来了 IT 变革，主要包括软件架构的变革和研发模式的变化，软件架构的变化是大型单体应用向微服务的转变，研发模式的变化是大批量阶段式或瀑布式的开发向小批量增量开发的转变。而敏捷和 DevOps 的理念、方法和实践是当前研发模式变革的主要手段。
接下来我将带领大家从四个方面一起探究京东的 DevOps：介绍京东对 DevOps 的理解和所做的探索，然后重点介绍沉淀了京东 DevOps 经验的行云研发协同平台，它的一些关键特性和典型应用场景。随后介绍一下京东云所能提供的 DevOps 转型服务。
Question：软件开发复杂度提升带来了哪些问题？
孙长虹：如果让我们用一个词来形容当前的时代特征，那么 VUCA 一定会排在前列。VUCA 是易变性、不确定性、复杂性和模糊性这四个词的首字母缩写。在 VUCA 时代，命令与控制的传统方式不再适用，组织必须能够快速响应变化和不确定性，灵活应对复杂性和模糊性。
与此同时，软件在这个时代的重要性与日剧增。
早在 2011 年，原网景公司的创始人安德森提出“软件吞噬世界”这一大胆论述，如今这一设想逐渐成为现实；譬如伴随着新零售的崛起，有人提出“程序员吞噬零售”的说法；伴随着汽车技术的飞速发展，又有人提出“软件吞噬汽车”的论述。无论如何，几乎现在所有业务都离不开软件，软件已经成为企业的核心竞争力。
然而，软件的复杂度与日俱增，使得交付过程困难重重，这是一个典型的软件交付过程的价值流：
在需求分析阶段，遇到了像业务需求模糊，需求不确定性，分析周期长等困难。
在规划排期阶段，常常有大量的需求积压；以及跨团队的开发排期难等问题。
在设计和编码阶段，会遇到需求变更多，跨系统联调的困难。
而在功能测试阶段，很多团队依旧依赖手工测试，质量问题多，从代码到测试的整个过程的周期长，代码质量低，返工多等。
在 SIT/UAT 阶段，会遇到集成时间晚，集成问题的排查难等困难。
从规划到最终的上线，又会遇到应用之间耦合大，跨团队协调复杂，集成周期长等困难。
在部署发布阶段，传统手工投产过程非常脆弱，容易出现问题，问题追溯困难也都很常见
端到端地看，就会发现：业务需求的前置时间长，开发过程不透明，不可预测，需求变更困难，需求价值不明确，大量低质量需求产生了大量浪费等各种困难。
软件开发是一个复杂的过程，先驱者们得出软件开发需要采用经验性过程的结论。经验性过程是相对于“已定义过程”而言的，所谓已定义过程，就是在一个项目开始的时候，就制定详细的计划，识别全部的工作项，然后在整个项目执行过程中，严格遵循计划，直至所有工作完成。经验性过程是在项目之初明确目标，把高优先级的工作项识别出来；然后用增量的方式持续进行检查和调整，直至目标达成。
Question：敏捷在不同时期的定义是怎样的？
孙长虹：传统的定义过程，只能支持简单类型的工作，为支撑复杂工作，必须采用经验性过程，也就是敏捷组织这样一种工作方式。正如 Scrum 指南中所指出的，Scrum 是为了解决复杂问题的。敏捷的重要性早就得到了行业领先者们的重视。
IBM 在其《CEO Study》中所阐述的，CEO 们的首要任务是提升企业的业务敏捷性，以应对快速变化且高度复杂的环境。而麦肯锡公司在《麦肯锡月刊》中指出：3/4 的受访者表示，组织敏捷性是头等大事，近 40%的受访者目前正在进行组织敏捷性转型。
敏捷并没有一个明确的概念。在传统软件开发方法无法应对快速、多变、和动态市场环境的背景下，作为一种替代方法被提出。以《敏捷宣言》为标志，包括一组价值观和原则，多种软件开发框架和方法，以及一系列最佳实践。
敏捷有这样一些具体特征：
1、以客户为中心关注价值，即由客户定义价值，并且由价值来驱动开发，另外就是最小可行产品进行测试和学习，以增量的方式来进行交付，先交付小批量功能，通过用户的反馈来得到学习；
2、跨职能自组织团队通力协作，即组建跨职能团队，能够负责端到端这样一种交付，另外 3、端到端的快速流动和及时的反馈，以及持续的改进工作方法。
如果我们仔细审视这些特征，会发现这些特征不但适用于软件开发，实质上敏捷已经成为一种新的工作方式，不仅仅应用在 IT，而是广泛应用在整个组织。
Question：DevOps 如何演进？
孙长虹：DevOps，实际上是继承了精益和敏捷方法，并将其渗透到整个交付过程。采用大量卓越的技术实践，它是交付方法论和技术实践引进的这样一种融合，从而使得组织能够更加快速、频繁和可靠的去构建、测试和发布软件，以满足业务的这种快速变化的要求，使得企业更加适应市场竞争的需要。
正如知名的研究机构 Forrester 所指出的那样，现在各行各业都在做数字化转型，要想获得数字化的收益，就需要一些具体的举措，比如移动应用 互联网 大数据等等，但是将数字化转型仅限于这些举措是远远不够的，应当专注于在他们下层更为关键和基本的需求，也就是为未知将来的持续的商业和技术变革做好准备。数字化是要求企业具备应对变化的能力，敏捷和 DevOps 恰恰可以帮助企业实现 IT 的转型，帮助企业在业务上能够具备适应变化的能力，从而被认为是数字化转型的一个基本的能力。
Question：京东在 DevOps 方面的探索历程如何？
孙长虹：京东在 DevOps 的探索主要从两方面开展：一方面是实践，比如敏捷或 DevOps 的管理和工程实践，包括像 Scrum、看版方法、业务敏捷、持续集成、持续交付、DevOps 等等。另外一方面是支撑这些实践落地的工具在整个集团层面的持续演进。
具体来看，京东在 DevOps 的探索有三个领域：
第一个领域是提升研发的管理水平。讲到研发的管理水平，其实我们面对的问题不是没有方法，而是我们所面临的方法太多，京东在探索中基于典型的研发场景，组合一些方法和实践，并且得到了工具平台的这样支撑，从而达成在各个场景下的目标。
第二个探索的领域是增强研发的工程能力，我们现在所使用的很多的研发的工程的实践方法，实际上已经存在很长一段时间，京东在 DevOps 探索中，基于 DevOps 平台的价值流，把各种工程技术的实践做了有机的整合，从而能发生更大的功效。
第三个探索领域是研发的效能度量，京东拥有一个组织级的研发效能度量的一个体系，像度量基本原则、指标的选择的原则等。基于京东价值流交付模型，也建立了一系列完整的指标体系，然后在行云效能度量平台的支撑下，实现度量数据的一种场景化的应用，从而支撑效能的持续的改进。
京东的 DevOps 探索可以浓缩在这张 DevOps 全景图里。
在这张全景图的最下面，是一系列的最佳实践，包括需求和业务的实践、编码的实践、开发的实践、测试的实践，以及运维的实践等。所有这些实践都由一些具体的效能组件来支撑，例如项目管理、需求管理、代码库、流水线等，基于 DevOps 一体化的这种理念，我们整合了这些组件，形成了一个面向一线产研用户的一体化平台，包括项目协作域、开发域、测试域、运维域等。基于这个平台的大规模应用，沉淀了很多研发数据，基于这些数据又可以做研发的效能度量，基于效能度量实现的业务洞察，来持续改进我们的实践组合，进一步的做提炼。
京东的 DevOps 经验可以提炼成黄金三角，黄金三角的中心是其目标，也就是快速、流畅、可靠和可持续的交付价值。三角的三部分，分别是效能实践，它是京东多年多形态大规模研发效能的实践经验，这些经验沉淀在效能平台上，这个效能平台是一站式的 DevOps 平台，覆盖了软件交付的全生命周期，也支撑了整个组织的大规模的研发活动的开展，第三部分是效能度量，效能平台产生的数据，对它进行挖掘形成洞察，可以用来优化效能实践，随着效能实践的提升，来进一步对效能度量提出更高的要求，也完善效能度量。与此同时效能度量的应用也推动了效能平台在整个集团的应用更加深入。这三者是相辅相成的关系。
效能平台作为另外两个部分效能实践和效能度量的一种支撑，起到了整个京东研发效能底座这样一种作用。
Question：行云 DevOps 研发效能平台有哪些关键的特性？
孙长虹：这里列出了行云 DevOps 平台的一些核心的功能。主要包括这么几个部分：
首先是管理协作域，它包括面向项目管理人员 PMO 的项目管理能力。
第二部分是需求管理，是面向业务人员的需求的端到端的管理。
第三部分是团队空间，是面向研发团队的管理研发任务，敏捷的迭代支撑，都可以在这里得到了支持。
另外是测试管理，是面向测试人员，包括像普通的测试用例的管理、测试计划全线的跟踪提测等。另外就是工程协作域，包括京东自研的大规模代码库，自研的大规模流水线，以及部署和发布这样的能力。右上角是行云的效能度量。基于平台所沉淀的研发活动数据，进行效能的分析和洞察，从而支持效能的持续改进。
不同的 DevOps 平台，在功能上其实差异并不是很大，京东经过多年的大规模应用，也形成了自己的一些关键特性，这里列出了 8 个关键特性。
第一个关键特性：端到端统一价值流。Gartner 在 2021 年曾提出精益的价值流将会被融入 DevOps 的论述，同时也提出了价值流交付平台的概念。这个价值流交付平台就是国内的 DevOps 一体化平台。京东在这一块走的更进一步，不但具备端到端的一体化的平台，实现了整个价值流在线上的协同，价值流的可视化以及可改进，具体来说，首先京东在整个集团层面统一了研发价值流；其次实现了从业务提出需求，到最终需求上线和收益验证，端到端流转的线上化，基于统一的研发价值流，形成了整个集团层面统一的研发效能的指标定义，此外在各个研发团队的层面又可以根据自己的实际情况，灵活定义自己研发一个状态，以及这些研发状态的流转的规则，简单来说，就是通过 DevOps 一体化的平台，能够落地京东的这种价值流交付的模型，为整个集团层面的研发协同和效能度量奠定了基础。
第二个关键特性：多视角和跨领域的协同。第一个视角其实是业务的视角，整个需求的端到端的跟踪，第二个视角是产品视角，赋能产品经理，能够对自己的产品进行规划、进行价值探索，进行持续的运营。第三个视角是研发的视角，管理研发活动，管理研发的工作任务
以及支持像敏捷开发，第四个视角是面向传统的项目管理，以及 PMO 的视角，实现了像工时的管理，整个项目范围里程碑风险的管理等等。
第三个关键特性：端到端的流程打通，以及整个研发活动的流畅衔接。需求从提出之后，进入了需求管理，在需求管理模块进行需求的一种受理，需求的沟通，并把业务需求拆分成一个个 IT 系统的一种产品需求，再把产品需求分配到一个个研发团队，在研发团队会并行的进行开发和测试，开发人员使用代码库进行代码管理，提交代码，然后触发了代码的质量检查以及代码的评审，代码提交之后，触发了自动的流水线，实践自动的构建，包括自动的冗余验证，测试人员基于，开发人员的提测来进行测试的规划，然后执行测试、管理缺陷。行云研发协同平台也集成了一系列的自动化测试的能力，可以被流水线调用，或者是在测试人员执行测试的时候已经调用。在这里我们实现了自动测试和测试管理的统一，统一自动测试和手工测试用力，统一执行，然后形成统一的测试报告，经过验证的制品，会进入制品库，然后通过部署和发布应用，把它发布到目标的环境中去，包括线上环境。总结一下，从业务提出需求，到产品和业务沟通受理需求，需求分配到开发团队，然后再执行具体的开发和测试的工作，直至上线验收，以及收益的一个验证，实现了全流程的线上化，整个的过程全是打通，并且是非常流畅的进行衔接。
第四个关键特性：数据的关联全程可追溯。基于价值流，也就是需求，我们把各种管理对象都进行了关联，比如说与代码进行关联，与测试进行关联，与缺陷进行关联，与发布进行关联等，从而实现了全程的可追溯。
第五个关键特性：状态的更新。能够实现自动和准确及时的这样一种状态的更新，我们在做效能度量的时候经常会遇到这样一个问题，平台上采集的数据有可能不准确，解决这个问题，固然可以采用一些管理手段，但是行云提供了一种技术手段。行云提供了需求评审的线上评审能力，我们在线上进行需求评审，评审通过之后，这个需求的状态就自动流转到待上线，因为我们的需求也是跟代码进行关联的，当开发人员创建分支进行编写代码的活动的时候，这个需求的状态就自动更新到那个开发中，当开发人员进行提测，测试人员开始测试之后，需求就自动的进入到测试中的状态，当测试人员完成这个提测标志提测通过，这个需求又会自动的将其状态变为待上线，整个端到端的绝大部分的这个过程的这种状态，都可以自动更新，从而保证了研发过程数据的准确，以及快速的得到采集，从而支撑了我们更好的去做效能度量。
第六个关键特性：能力的开放比较容易扩展，行云研发效能平台，提供了完善的开放 API
拥有插件化及组件化的能力，易于集成和被集成，同时行云通过应用商店，建立了整个的工具链生态。
第七个关键特性：安全和高可用。从网络应用数据和运维多个层面确保安全，全链路的端到端的高可用，另外采用 K8S 集群部署，确保无单点故障。
第八个特性：国产信创和自主可控，整个平台采用了纯自研的架构，基于包括芯片、服务器、操作系统以及数据库和中间件全栈的国产信创生态，实现了自主可控。
Question：行云 DevOps 研发效能平台有哪些典型的应用场景？
孙长虹：我们梳理了行云 DevOps 平台的 6 个典型应用场景
第一个场景是敏稳双模的研发协同。在研发过程中，不论组的大小，都会遇到既存在传统的瀑布式的这样一种项目，又存在敏态的迭代增量式的项目，并且这些项目需要协同的场景。行云研发协同平台一方面提供了稳态的支持能力，通过项目管理模块；另外一方面又提供了敏态的支持能力，通过团队空间，在团队空间里面支持迭代，像 Scrum 经济看板这样的一种研发的模式，又提供了面向业务的需求管理模块，能够通过对需求的，端到端的跟踪需求的层次化可视化，来把稳态和敏态的项目进行关联，能够更加透明化的来进行协作，从而能够有效的支撑敏稳双模的研发协同。
第二个场景是多层次的价值闭环，随着敏捷或 DevOps 转型的深入，我们越来越多的发现更大的瓶颈可能是在业务和产研的协同上，研发团队更多的去问产研我们这个需求的价值是什么，在这里行云也提供了一些相对比较简单的功能，但是也非常有效的实现了多层次价值闭环，首先是在业务目标的层面，在规划项目的时候，要求填入项目的 ROI，同时在项目的中后期，也可以对项目的 ROI 进行验证，在业务提出需求的时候，也可以提示业务人员输入需求的价值，需求要有哪些收益，在需求验收之后，也提供了这种收益验证的这样的功能。
业务目标由用户的具体使用场景所承载，所管理的对象就是业务需求，在业务需求的层面，我们会要求需求提出者明确需求的场景以及验收标准，在需求交付之后，要进行业务的场景演示以及业务需求的验收，从而实现了在业务需求层面的闭环。业务需求又分解成一个个的产品功能，在这个产品的功能层面，我们会要求我们的 PO 或者业务分析人员，基于敏捷的方式去编写需求，比如说用户故事的这样的模板，编写验收标准等，在迭代结束之后要进行产品功能的演示，以及产品功能在迭代后期的测试，实现了在产品功能层面的闭环。最后是在代码层面的一个闭环，从而实现了四个层面的从目标到业务需求到产品功能及代码，多层次的价值闭环。
第三个场景是大型产品、大型项目或者是大型需求的协同。在组织里可能会遇到这样的场景，一个业务需求有可能需要多个研发团队的协同，同样每个研发团队同时有可能会接收到，来自不同的多个业务单元的需求，这就形成了非常复杂的多对多场景，解决这样复杂的场景协同问题，一方面要有跨团队协同的机制，比如如何做目标对齐，如何做研发节奏的同步，同时也需要一个平台支撑，比如说行云研发系统平台就提供了整个需求的层次化需求，端到端的这样一种流动可视化，从而能够帮助我们在大型协同中的关联方，能够对整个项目的状态有比较清楚的认识，促进高质量的项目决策，从而实现大型团队的协同。
第四个场景是持续集成和持续部署，也就是 CICD；CICD 将 DevOps 主要的工程实践，从代码的编写、构建、验证、部署都集成在一起，从概念上来说，CI 和 CD 通过制品库进行连接实现了在 CI 的一次构建，通过 CD 能够随时随地进行部署，CD 既是持续部署的一个简称，也是持续交付的简称，我们可以把持续交付理解为持续集成和持续部署的一个总和。通过 CICD 能够实现频繁的提交和集成代码，并且代码一经提交就触发包含自动化验证的构建流水线，部署的目标环境，直至发布上线。
第五个场景是研发的质量内建。这里主要包括这么几个部分，首先是测试左移，然后开发和测试更加紧密的协作，测试的自动化，能够实现快速的反馈和频繁的执行。第三部分是高质量的持续集成，这里包括代码的提交纪律，每日构建和提交构建等，还有就是质量门禁，代码以高质量在不同的环境中晋级，通过测试左移、分层测试自动化，以及多环节质量卡点，加快反馈，尽早发现和解决缺陷，提升代码质量。
第六个场景是精细化研发管理。提供了不同视角的研发管理的精细化，比如研发视角的不同角色的工作任务的排期可视化，项目管理视角的工时申报，整个工时分布的管理，还有管理视角的人力资源饱和度日历，还有从业务视角可以看到自己的成本分开，以及所有的需求以及子需求的计划和实际消耗的工时等等，从而支撑了各个不同角色的精细化研发管理。
Question：京东组织级 DevOps 转型整体框架是怎么样的？
孙长虹：DevOps 转型服务其实并不容易，首先是在团队层面可能会遇到这样的一些挑战，一个是能力的缺失，可能团队缺少 DevOps 的知识，或者是实践的经验；第二个是意愿缺失，很多团队没有把研发效能的持续改进作为自己的主要的职责，只关注于日常的需求交付，缺少持续改进的意愿和意识。第三点是缺乏业务的参与，如果仅仅是产研参与的话，实际上没有办法最大化 DevOps 的价值，第四个就是外部团队来负责改进，这样真正的改进的主体，也就是我们的一个个的 DevOps 团队，他们是被动去做改进，这种改进不持久。此外还有临时的项目团队，当有项目需求的时候临时组建团队，从各个不同的职能团队获取资源，组建团队，项目完成之后又解散团队，这样使得 DevOps 的能力没办法得到沉淀。
另外 DevOps 转型在组织层面也存在着很多的挑战，首先是整个组织转型的目标不明确，或者是不对齐，无法形成一个合力，其次整个转型活动缺乏统一的领导和组织，使得各个不同的职能机构做一些局部的改进，工具也是碎片化；第三点是瀑布式或者是毫无章法的 DevOps 转型的实施，使得转型难以落地或者执行不到位；第四是缺乏规模化推广的手段，在部分项目团队或者是试点项目里面，能够见到一些成效，但没办法大规模的去复制。第五点是没有效能度量，或者是效能度量的应用水平低，从而无法实现组织层面的持续改进。
DevOps 转型在个人层面其实也面临着很多的挑战，对个人而言工作方式的转变，这个会挑战个人的一个舒适区；第二个是个人能力的缺失或者是差距，比如说个人无法胜任在新的工作模式下的要求；第三点是被动参与，这会导致参与人员缺乏心理安全；第四点是缺乏自我改进的动力，部分在 DevOps 转型中受到影响的人员，会拒绝这种这种变化，拒绝学习、拒绝改进；第五就是实际的日常工作中，其实会对透明和协作提出非常高的要求，团队成员会受到来自同伴很大的压力，也都会阻碍转型顺利开展。
基于这些转型的挑战，我们总结了一个组织级的 DevOps 转型整体的框架，这一方面是京东自己 DevOps 转型经验的提炼，同时也是我们服务客户、帮助客户转型，所做的一个总结。
DevOps 转型的整个目标是快速流畅可靠和可持续的交付价值，支撑这一目标实现的是研发体系、研发管理和工程实践，以及支撑体系和实践落地研发工具，仅仅有这些还不够，特别对于大型组织还需要文化的建设和能力建设，以及支撑长久和持续转型的组织建设。
Question：京东云能提供哪些 DevOps 转型服务？
孙长虹：这样一个框架的落地并不容易，京东云可以为我们的客户提供一些转型的服务。我们可以一起看一下。
首先是培训赋能，就包括敏捷或 DevOps 的基础培训、管理实践和工程实践的培训，以及面向核心人员的深度培训，还有一些认证培训等，使得我们的客户能够快速全面地了解敏捷和 DevOps 的前沿方法，以及京东的一些最佳实践，为组织转型破冰。
第二个是转型规划，有些企业在自身的数字化转型之下来进行开展，或者有些组织已经启动了敏捷和 DevOps 的转型，但也有些组织在采用行云 DevOps 平台的时候，其实并没有整个 DevOps 转型的考量，这种情况下我们就可以帮助这样的客户组织，来制定一个企业级的系统化的转型框架，从而使得客户更加有信心开启 DevOps 的转型之旅。
第三个服务是平台的建设和运营，我们可以帮助客户规划 DevOps 平台建设的整体思路和实施路径，然后以行云为基础，基于客户的实际的需求，为客户定制专属的 DevOps 平台，并且把平台进行推广应用，然后再基于使用过程中用户的反馈，来持续的演化平台、运营平台。
第四个是体系建设，我们可以帮助客户基于 DevOps 理念和客户研发的实际现状，对标业内研发效能提升的一些优秀实践，帮助客户建立端到端的研发体系，并承载在 DevOps 平台上
第五个是标杆团队的打造，DevOps 的平台建成之后，只是 DevOps 的应用的一个起点，更重要的是 DevOps 平台如何能够为我们一线的产研团队带来价值，我们可以帮助客户来进行 DevOps 的试点，选择一些团队作为标杆，来验证一整套的 DevOps 方法和理念，在客户的研发环境中如何能够更好的落地，并且承载在这个 DevOps 平台上，解决使用过程中的各种各样的问题，从而为大规模的推广积累经验。
第六个服务是文化建设，在大型的研发组织里面，肯定会存在某些团队，这里可能也比较符合二八原则，有 20%的团队他们很有改进的意识，愿意去尝试新的方法，尝试新的工具来提升效能，但是大多数的研发团队，还是主要的关注点在自己日常的交付活动，没有把研发效能的持续改进作为自己的一个重要的职责，通过文化建设活动，能够激活一线的研发团队，帮助他们建立转型的紧迫感，转型的主体意识，以及采取行动的意愿。
第七个服务是教练培养，我们可以帮助客户建立内部教练的这种运作模式和培养的机制，
帮助他们选拔识别一些内部教练的种子，通过教练训练营等活动来帮助客户培养自己的内部教练，并且支撑这些内部教练来进入各个一线的产研团队，支持一线产研团队更加深入和更加持久的转型。
第八个服务是组织建设，我们可以帮助客户打造一个面向产研提供卓越的敏捷和 DevOps 服务的一个高效的支撑组织，从而支撑我们的客户更加持久和更加深入的转型。DevOps 组织建设是基于一线产研团队的实际需求，来梳理 DevOps 的支撑组织，比如说敏捷的 PMO 或者 DevOps 能力中心，基于他们的需求来梳理我们所需要提供的服务，然后进行能力的盘点，识别能力的差距，建设服务的支撑能力。京东可以帮助我们的客户，来规划和建设和运营这样的组织，并且帮助我们的客户的 DevOps 能力中心，进行能力的持续建设。
Question：京东 DevOps 的主要优势有哪些？
孙长虹：首先，京东的 DevOps 是经过了我们的实践的检验，是我们整个集团大规模多形态研发场景的多年打磨，另外也经历了像 618 、11.11，以及像 2022 年春晚项目的严苛考验。
第二，行云 DevOps 平台是内外同源，所有的工具都源自于集团内部，并且持续在演化。
第三，行云研发协同平台是行业领先的一个价值流交付平台，能够支撑业务和技术更好地协同，能够实现研发价值流的这种可视、可度量以及可改进。
最后一点，我们不但能够提供，支撑各个行业典型研发场景的平台，我们也能够提供组织级的实施方法论，以及我们的实施服务来帮助我们的客户去做转型，此外行云研发协同平台也拥有一些业内的行业权威资质，比如说信通院 DevOps 解决方案先进级，以及效能度量的先进级的认证，我们实施的专家，也都具备很丰富的 DevOps 或者敏捷转型辅导，和敏捷平台落地经验。
最后我做一个简单的总结，我们了解了京东对 DevOps 理解和京东对 DevOps 探索，学习了承载京东 DevOps 经验的行云研发协同平台，8 个主要特性和 6 个典型的应用场景，以及 8 个咨询服务，相信通过今天的视频，大家对于京东的 DevOps 已经有了一个比较全面的了解，那么最后祝愿大家在今后的工作中，能够拥抱 DevOps，拥抱云原生，拥抱变化。
扫一扫
671
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
