主导 ChatGPT 宿主公司 OpenAI 巨额投资的微软第三任 CEO、萨提亚·纳德拉（Satya Nadella），近期在和著名记者、作家，NYT 专栏作家，HBO 电影《大而不倒》原著作者安德鲁·罗斯·索金的采访对话中指出：“AI 时代，每个公司都是软件公司，他们需要更多的开发者。事实上，这个世界需要 10 亿开发者”。在 AI 的时代大背景下，作为 Gartner 2023 年十大战略技术趋势之一的“平台工程”对于企业和个人意味着什么？InfoQ 于 4/18 日再次请到特邀主持人、vivo 互联网研发总监杨振涛，对话平台工程践行者、KodeRover / Zadig 创始人兼 CEO 李倩，为大家带来了一场精彩的探讨。本次讨论内容摘要如下（完整版视频参看：https://www.infoq.cn/video/rt4CNXXlVbzmRCPumWPe）
平台工程如何创造价值（典型要素 / 应用实践 / 价值呈现、数字化启示、企业实践路径）
以 Zadig 为代表的平台工程如何在企业落地实施
平台工程和 AI 对行业、从业者的影响分析（行业的适用性、企业组织的迭代、从业者的职业发展）
我们先来回顾两位嘉宾在 4/3 日的第一次探讨时的内容提要
企业发展与工程师生存的矛盾
企业大力投入开发者体验的意义
提升开发者体验的典型工具和产品
从自动化到 DevOps 实践，到 Xops 泛化
平台工程的现实商业意义预测
平台工程是否是造轮子，昙花一现？
以 ChatGPT 为代表的 AI 技术是否会替代工程师？
以下为本次讨论内容整理全文：
杨振涛：大家好，欢迎收看 InfoQ 特别直播栏目《极客有约》。我是今晚的主持人杨振涛。今晚，我们有幸邀请到 KodeRover 的创始人兼 CEO 李倩女士作为我们的嘉宾。今晚，李倩女士将与我们一同探讨的是从 DevOps 到平台工程的话题。现在，让我们热烈欢迎李倩女士与大家打个招呼！
Landy：大家好，非常荣幸能够与大家见面！我是 KodeRover 的创始人兼 CEO，同时也是 Zadig 产品的作者。很高兴能够参与这次关于平台工程的探讨。上次的讨论意犹未尽，所以我们将继续深入探讨这个话题。再次感谢大家的到来！
内容提要：
平台工程可以被视为 XOps 概念的延伸和实践，平台工程让软件研发与商业世界建立更深入和直接的联系。
杨振涛：在直播的最后部分，我们将回答一些粉丝提出的问题。在观看直播的过程中，如果你有任何问题，请随时在评论区提出。我们的视频号小助手会收集这些问题，并邀请我们的嘉宾来解答。接下来，我们将延续上次直播的内容，请李倩老师先对目前为止的讨论进行总结。从您的角度来看，DevOps 和平台工程之间的关系是怎样的呢？
Landy：实际上，DevOps 最初是从一种方法论或理念开始的，其本质是为了减少团队之间的沟通和认知负担，以共同实现交付目标。现在，我们在不断地对其进行广义化和扩展，出现了许多基于 Ops 的概念，例如 TestOps、MLOps、DataOps、FinOps 等等。在我看来，平台工程可以被视为这些 Ops 概念的延伸和实践，或者说是对其进行实例化的过程。更深层次地理解的话，我认为平台工程是软件研发与商业世界更深入联系的一种方式。这些观点是我在产品开发和实践过程中逐步形成的理解，当然，这些理解也在不断迭代中。
杨振涛：嗯，好的。让我们来具体讨论一下平台工程。之前，InfoQ 发布了一些关于平台工程的文章，我们也注意到一些读者在评论区提到了一个观点，即平台工程可能涉及基础设施的可编程能力，以及 CI/CD 等方面。您认为这个观点是否准确？以及在整个基础设施及代码的发展历程中，不断出现了许多方法和工具，它们如何改变了整个 DevOps 实践呢？
Landy：嗯，没错。我认同您提到的观点，平台工程确实包括了基础设施即代码（Infra as Code）和持续集成 / 持续交付（CI/CD）。平台工程是一个更广泛、更综合的概念。它涵盖了与开发者接近的一端，也涵盖了与基础设施接近的另一端。
个人而言，我认为平台工程是软件交付生命周期的一个重要组成部分。它涵盖了如何构建软件以及管理整个交付过程。在其中涉及了 CI/CD、监控告警、系统集成以及各种支持系统。此外，它还包括了研发和运营的建设。
对于 Infra as Code 的发展，我认为它主要是从基础设施方面解决复杂性问题。像 HashiCorp 等公司在创业初衷上就致力于解决基础设施的自动化和环境治理等问题。同时，AWS 和其他云服务提供商也提供了许多基础设施管理的 as code 实践。Infra as Code 在 DevOps 中扮演了重要角色，对其产生了明显的影响。
过去，开发和运维之间存在很大的合作隔阂。但现在，我认为双方都希望进一步加强合作。一些公司甚至成立了专门的平台工程团队，以促进双方更密切的合作。这样的组织能够承载这种能力，并构建平台工程所需的基础设施和流程。
内容提要：
平台工程是一个综合性的解决方案，核心要素可能包括以应用为中心的现代服务管理和交付管理，需要注重开发者体验、内部运维、安全等一系列建设。
平台工程本质目标是让企业能够敏捷、可靠、安全、高效地交付应用，以提供更好的用户体验。
杨振涛：聊到这里，你认为平台工程到底是什么？它的典型要素有哪些？当我们采纳或者实施平台工程，这种实践会有哪些一些典型的表现，或者说我们如何判断某个团队或某家公司是有典型的平台工程应用的和实践的？
Landy：平台工程类似于复杂的学科，它是系统工程范畴中综合性的方法。在这个过程中，它主要是构建、运行和管理整个流程所需的能力，并将技术和流程融合在一起。它有点像解决方案的存在。当然，在这个过程中面临的复杂性不仅仅是单一的连接。
所以对于平台工程，我理解它是一个综合性的解决方案，面向企业内部构建更好的应用。它的核心要素可能包括以应用为中心的现代服务管理和交付管理。另外，它还注重开发者体验、内部运维、安全等一系列建设。它的本质目标是让企业能够敏捷、可靠、安全、高效地交付应用，以提供更好的用户体验。这是我对平台工程的一些核心要素的理解，以及对其好处的简单描述。
我们可以将其分为几个视角来讨论价值体现：首先是组织协同的视角。平台工程可以减少组织之间的摩擦，让团队更高效地协同工作，提升整体工作的愉悦度，可以给研发团队带来更好的体验。其次是研发视角。在研发过程中，平台工程可以帮助加快发布应用的速度，提高稳定性和效率，保障应用的安全性。这方面。最后是面向业务需求的视角。平台工程可以缩短交付周期，让产品更快地上市或者试错，从而提升服务质量。因为万物都离不开为组织提供价值，所以这个视角是更高维度的。
总体而言，平台工程在研发协作体验、研发交付和需求交付等方面都有一些典型表现，可以带来一些显著的好处，使其更加有效。
我熟悉平台工程这个词汇并没有很长的时间，但实际上我了解到的一些实践案例比这个词汇出现的时间要早得多。在我们所涉及的一些企业中，比如最近极氪汽车，他们主要使用的就是 ZadigX 价值链平台。他们内部数字战略提出了“三化平台”，这是一种企业数字化战略的新方法。我觉得这个思路非常具有前瞻性，所以我将他们的三化平台视为平台工程的一个典型案例。甚至我认为在这个行业中，这个案例都有一定的借鉴意义，可以让我们思考和探索。
内容提要：
平台工程背后说明了我们正在经历数字化转型的巨大浪潮。平台工程回答了企业研发管理的可视化 / 数字化价值，同时回答了如何证明数字化的价值和投入产出比的关键问题。
平台工程代表了一种复杂性，通过将用户界面放在平台上，将底层复杂度整合起来，实现可治理性，从无序变为有序。它的目标不是解决具体的业务问题，而是为业务发展提供了杠杆（乘法效应），增加数字价值。
平台工程非常有变革性，从 DevOps 到平台工程，涉及到组织升级、研发模式转变，指向的是一种方法和解决方案，更好地是让企业能够推进自身的数字化转型发展，并使其 IT 架构更适应当下的市场变化。
杨振涛：好的，接下来的问题是关于平台工程的趋势发展。我们之前提到，不仅 Gartner 将平台工程列为了 2023 年的十大战略技术趋势，而且最近 CNCF 发布了云原生计算平台工程的白皮书。那么这些背后的趋势发展说明了一些什么呢？包括我们之前看到 Gartner 和 CNCF 关于平台工程的不同描述，以及他们从自己视角看到的企业实践。那么这些背后的趋势是什么，或者说有什么原因呢？让我们来分析一下。
Landy：就 Gartner 和 CNCF 来说，我认为它们更多地是对这个趋势进行了报道。它们在当前的云计算、DevOps 和企业数字化转型等方面提出了一些新的要求。通过平台工程，可以很好地赋能现代企业的 IT 架构，以满足市场和各个方面的需求。我认为平台工程提供了一种解决方案，让企业的 IT 在数字化转型或数字经济下具备更强的竞争力。
从 Gartner 和 CNCF 的报告中，我看了一下，实际上在视角上可能会有一些小的差异，但本质上它们都在提供一种完整的技术架构和实践，或者是一个集成的综合解决方案，这是我观察到的。但从本质上来说，我觉得这背后主要说明了我们正在经历数字化转型的浪潮，以及企业对于研发管理的可视化和数字化价值的呈现，以及如何证明数字化的价值和投入产出比的问题。平台工程给出了一个很好的回答。所以在这个大的背景下，平台工程更多地是让企业能够推进自身的数字化转型发展，并使其 IT 架构更适应当下的市场变化。
杨振涛：其实我们可以从 CNCF 的白皮书中看到作为一个成功的平台所需的要素，或者作为一个成功的平台团队所需的要素。这些要素在某种程度上也有助于在当前行业内推动达成一些基本共识。
Landy：是的，我非常认同这个说法。
杨振涛：在刚才提到的车企、以及传统企业中，研发团队的规模是不尽相同的。在有数百甚至上千人的研发团队中，在大中型组织中实施规模化 DevOps 一般会存在哪些方面的挑战？平台工程是否能够给传统企业数字化这过程带来新的启示？
Landy：嗯，我认为这个话题非常有价值，主要是关于组织的复杂度对于技术、产品和数字化转型的影响。在传统企业中，我观察到许多挑战实际上并不是技术上的挑战。例如，流程、数据和能力往往在孤立地建设，与早期建设的能力无法直接为公司或团队提供价值。这些老的工具、系统和思想在面对变革时成为挑战，有些人积极拥抱变革，而有些人保持守旧的态度。同时，也出现了一些人使用新工具却仍持有旧有思想的现象，这种情况与敏捷团队的战队模式不符。敏捷团队的目标是全栈小分队解决问题，但实际上交付方式却更像是瀑布模式，这可能是因为思想尚未完全转变。这种情况可能会导致奇怪的现象和不协调的局面。在大型企业中，这些挑战可能会更加严重，对 DevOps 实践和数字能力建设产生阻碍。
在这方面，平台工程可能提供一些新的启示，涉及到组织升级、研发模式升级。平台工程代表了一种复杂性，通过将用户界面放在平台上，将底层复杂度整合起来，实现可治理性，从无序变为有序。它的目标不是解决具体的业务问题，而是提供一种乘法效应，为业务增加价值。因此，从平台团队组织建设以及平台工程所指向的方法和解决方案上看，它为实施 DevOps 和相应的平台建设带来了新的机会和可能性。
杨振涛：这个角度来讲，平台工程是否具有一定的变革性，我们从传统工程环境和基础设施上过渡到更先进的这种实践上了吗？
Landy：嗯，我认为平台工程非常有变革性，因为它涉及到组织和研发模式的转变。它的目标是打破过去传统的孤岛式流程和数据隔离，通过更多的协作和集成方式进行交付。其中包括基础设施的自动化和标准化，以提供标准化能力，并实现自动化构建和标准化模板化的组织模式，从而简化整个软件交付过程。这种变革可以提高整体质量和效率。
内容提要：
小团队采用自下而上的方式解决痛点、产生价值，并逐步迭代。而大团队则根据当前的发展情况，采用自上而下的战略考量，将关键特征的业务或场景迭代进平台建设，并开始在内部推广或运营平台的雏形。
杨振涛：对于小型团队，例如三五十或者二三十人的这种小规模团队，他们是否有必要去考虑投入资源实施自己的平台工程？你认为什么样的团队或者企业需要或者更适合平台工程？不同规模的团队，如何平衡长期主义的平台建设和短期的业务交付的压力？
Landy：刚才提到的是关于从传统到先进的过渡问题，这涉及到很多方面的思考。其中一个关键点是团队是否具备这样的能力，以及顶层设计是否能够支持这种过渡。例如，你的老板在组织层面上是否有这种意识。对于平台工程来说，它是一个重要但不紧急的事情，在许多业务开发中，大多数小公司主要是为了生存而战。因此，如果不是编写业务代码，其他角色可能只会暂时或短暂地参与，不会全力投入。通常情况下，可能会有一个人代表团队来开展项目开发或类似的任务。因此，在小团队中，可能不需要投入太多的资源来进行大规模的平台工程计划。但是，可以运用自动化的思想来沉淀一些最佳实践，例如确保持续集成 / 持续部署（CI/CD）的流程，实现自动化部署等。许多公司都在努力构建这种基本的自动化流程。随着团队规模的扩大和业务的增长，可以考虑建立一个专门的团队或者启动一个项目来进一步推进这个过渡。
然后，刚才提到的另一个问题是平衡的问题。这个问题与基础设施迭代、软件研发模式迭代以及业务产品形态之间有很大的关联。在平台建设方面，我认为从本质上来说，如果能够在一段时间内满足业务需求交付，就不要过度制造轮子。对于特别小的团队，可以先采用自动化的方式，如前面提到的 CI/CD，由痛点驱动，采用一种自下而上的解决问题，先解决一些共性问题，然后在构建平台工程时应用这些最佳实践。对于稍微规模大一点的团队，根据现状分析，需要建设平台时，此时建议采用自上而下的方式推动变革，并针对一些共性问题，比如一些关键业务或典型业务，抽象出一些最佳实践或模式。然后通过平台建设，将这些东西固化下来一些模式，然后后续根据组织形态和流程不断迭代这种模式。
总结下来有两种方式，小团队采用自下而上的方式解决痛点、产生价值，并逐步迭代。而大团队则根据当前的发展情况，采用自上而下的战略考量，将关键特征的业务或场景迭代进平台建设，并开始在内部推广或运营平台的雏形。然后再根据后续的迭代方向，根据技术的变化进行调整。
杨振涛：在企业评估是否需要采用平台工程实践时，研发效能是否可以作为一个关键的价值点进行考量？同时，开发人员可能更关注开发体验。这两个方面是否存在所谓的资方和劳方之间的博弈或矛盾？
Landy：近年来，研发效能备受关注。我已有近 10 年的实践经验，起初研发效能是自我迭代和改进的概念。但由于各种原因，包括大公司对指标度量方式的问题，导致人们对指标抱有抵触情绪。度量工作通常由非开发或非技术人员负责，他们对研发工作了解有限，可能会采用不合理的度量方式，比如代码行数。这种方式就像认为飞机越重越好，与实际情况完全不符。
因此，关键是确保科学度量指标。在投入平台工程和研发效能方面，我们需要确保使用的度量指标合理有效，能准确反映研发团队的实际效能，以更好地评估和改进研发团队的效能。
在度量方面，我们应该关注需求到研发交付的整个过程，包括可行性分析、需求拆解、设计、编码测试，以及后续的运维和发布过程。可以按阶段划分，并建立关键节点和关键环节的度量体系。重点关注接口处的效率，并确保每个指标对应两个角色，而不仅仅度量开发。
此外，在评估价值时，我们应注重证明平台工程的价值，而不仅仅关注研发效能。通过全流程分解确定可能的指标，包括过程指标和结果指标，以更全面地评估平台工程的价值。
针对不同阶段，我们应向业务部门证明平台工程的指标或价值。例如，需求交付的平均周期可作为"北极星"指标来回答产品部门的上线时间问题。研发模式设计也应考虑，如从每月发布一次改为每周发布一次，具体取决于不同业务形态和核心发布速度的确定。此外，通过细粒度的度量，了解平均需求交付时长、从需求到研发拆解的时间等，清晰了解时间分配情况和结果产生的原因，以有效评估平台工程的建设情况。
同时，我们还需评估平台工程对业务的最终效果和开发者体验。平台工程旨在解决组织系统流程复杂性问题，若未从更好的生产者角度或以人为本的角度设计系统，平台工程就无法发挥作用。解决劳资博弈问题是平台工程的目标，若未解决好，开发者会感到与平台产生博弈，形成恶性循环。这表明方向偏差，许多公司出现这种感觉实际上是因为平台工程还只是一个平台，而非真正的平台工程。它未考虑到复杂性降低和整体生产力提升，更多关注各部分之间的连接问题。
因此，确保平台工程考虑到复杂性，降低复杂性并提高整体生产力至关重要。只有这样才能解决劳资博弈问题，否则将陷入恶性循环。因此，许多公司出现这种感觉实际上是因为平台工程未朝正确的方向发展。
杨振涛：可能实践上，有一些把用来度量团队或组织的研发效能的指标落到开发者个人身上，变成一些考核的指标。
杨振涛：内部开发者门户 / 平台 IDP 作为平台工程的典型表现之一，如果选择一个开源方案作为我们的内部开发者平台时，我们需要考察哪些关键要素？（或讲讲 Zadig 和 Backstage 等解决方案的思路、优缺点？）在此方面国内外是否存在显著的发展不同步现象？
Landy：在选择和开发企业内部的开发者门户或平台时，有几个关键因素需要考虑。首先是评估复杂性，不仅关注结果，还要考虑组织的迭代和发展过程，以免导致不可持续性。避免盲目追求快速发展或重复造轮子的现象这一点非常重要。
一个实体软件或平台不能单独带来价值，因为构建平台的抽象难度很高。需要具备业务和工程领域能力，并对基础设施有一定的理解，无论是采用开源解决方案还是自行构建。否则，所构建的东西可能失去平衡，无法满足真正的需求。选择平台开发方案时，需要具备全面的视角和理解，尤其在选择企业级应用方案时，需要具备功能性、安全性、可扩展性和可定制性等基本特性。还需要考虑应用性能指标和社区支持等因素，根据企业特点选择适合的方案。
内部开发者门户或平台是平台工程的一种外在表现。在企业内部，从简单的资源提供演变为为用户提供界面。有人将其视为简单的资源提供平台，有人持续改进为工程平台，有人演化为内部产品和服务目录。
Zadig 和 Backstage 是两种不同的解决方案，它们有不同的适用性和优缺点。Zadig 是基于云原生基础发展起来的，更注重作为基础平台的连接性和承载能力。它可以作为内部开发者平台的核心，提供整体连接和底层能力的管理。而 Backstage 则更像是一种表层的门户，提供 UI 和展示能力，让业务视角下的数据进行聚合和展示。相比之下，Zadig 更注重连接所有价值提供方，提供面向开发者的协作平面。
国内外在这个领域的发展存在显著差异。国外生态链中的工具链和生态多样性更丰富，从代码管理到项目管理再到 CI/CD 和交付物管理等方面有众多工具可选。国内则主要依赖大型公司的能力溢出和国外工具的使用，工具生态主要集中在这些领域。这与国内云生态系统的支持体系和工具链与云生态建设有关。但是云原生方面，无论从业务场景还是平台产品，中国都有更优势的发展环境。
杨振涛：在 Zadig 中是如何进行动态配置管理的？大家都知道，DMS 动态配置管理是目前在基础平台中比较重要的一个实践点，我们是用到了哪些相关的方法或解决方案，包括涉及到哪些配置，我们涉及到哪些存储相关的文件，去降低它的复杂性，让整个开发的体验更好？包括在过程中有没有一些特殊的挑战？
Landy：嗯，配置管理领域的复杂性确实存在。我们可以将配置划分为不同的层次。在当前业内常见的业务配置管理工具中，比较熟悉的有 Nacos 和 Apollo 等。此外，对于 Kubernetes 原生的配置管理，常用的是 configmap。从配置的形态上看，可以分为基础设施配置和业务配置两类。这两类配置的管理模式和变更流程是不同的。业务配置更多是动态配置，其动态能力取决于所使用的配置管理工具。而对于系统级的配置，例如与运行时环境相关的配置，变更点更多地是在平台级别，而不是针对特定业务的变更。对于平台而言，更注重的是大规模一致性的变更，而对于业务而言，更关注的是一次变更所带来的业务变化。业务变更通常由开发者或担任变更角色的人员发起。
所以在配置管理方面，复杂性主要取决于你所选择的管理模式。在 Zadig 中有两种模式，一种是 GitOps，另一种是通过变量来抽象内部的几个模式，以实现相应的配置变更，从而降低复杂性。第一种我们可以通过 GIT 来管理配置，例如使用 GitOps 的方式来自动化业务和配置变更。但是是否开启自动同步机制取决于研发流程或者所期望的方式。而另一种则是模板加变量配置，配置中通常存在一些共性的部分，开发人员需要进行的实际变更并不多。因此 Zadig 的变量能力，可以区分不同环境，并在不同环境中对变量进行赋值。对于开发人员来说，他们可以在图形用户界面上更改特定环境下的服务配置。
但实际上，对于管理平台或运维管理平台来说，它只是定义了开发人员可以选择的选项或类别，开发工程师处理的是填空题还是选择题不需要跟基础设施打交道，这样可以降低管理负担，并实现运维管理的统一化。举个例子，对于配置中的一些设置，比如 Skywalking，可以在变量配置中将其作为一项进行开启或关闭，无论是对于运维操作的一致性管理，还是对于开发人员的使用，这都是一个较好的方案。Zadig 对配置变更工具 Apollo 和 NACOS，数据变更 DMS 也提供原生自动化工作流支持，因此在这方面开发者并没有太多复杂的事情需要考虑。
杨振涛：作为一个偏基础平台的产品，在整个开发过程中，除了刚才提到的这种动态配置管理之外，还遇到过哪些关键性的挑战？在整个演进的过程中，是怎么去保证平台产品不会发展得过于臃肿？我们知道在长期的演进过程中，企业组织内部使用的平台产品经常会开发很多低频使用的功能，我们如何去平衡这种被低频使用的功能？
Landy：当面对挑战时，我们在实现 Zadig 过程中遇到了一些问题。其中一个挑战是我们的抽象层次是否足够基础。这个问题关键在于你的抽象是否能满足更多的场景嵌入需求。我们需要平衡自由用户平面和管理平面，避免系统过于泛化和臃肿。在这个过程中，我们有两个重要的抽象概念。
首先是对环境的抽象，环境指的是我们的产品在基础设施上的完整实例化，也就是说，将其部署到测试集群就是测试环境，部署到生产集群就是生产环境。环境提供了一个统一的开发者协作平台，使大家能够验证、测试和发布应用程序。无论是调试、自测还是联调，特别是在微服务架构下，开发者的交互变得非常复杂。通过环境的抽象，我们为开发者提供了一个协作平台，简化了这些复杂性，让大家能够更好地验证、测试和发布应用程序。
其次是工作流的抽象，我们重新推出了一个自定义工作流引擎。这个引擎基于 Kubernetes 构建，但更注重业务的灵活性。企业可以自定义任务并编排到工作流中，实现流程与外部系统的衔接。我们已经内置了许多流行的工具，同时也支持企业和开源社区客户根据自己的需求进行任务定制和编排、OpenAPI 的全开放调用。这种灵活性为企业提供了强大的业务扩展性，同时避免了从头开始开发或堆积功能的痛苦。我们相信，基于平台属性进行开发，直接面向业务赋能，将会带来更有价值的产品，而不是仅仅堆砌一些少数特定情况的功能。
我们与客户合作，通过收集问题来找到产品的方向。用户的反馈和易用性对于产品的价值至关重要。我们避免陷入一厢情愿的开发，而是注重倾听用户的需求和反馈。对于任何平台产品或其他产品，开发者的反馈和终端用户的友好易用性都是首要考虑的因素。只有通过这种方式，我们才能迭代出更有价值的产品，而不是开发一些很少使用或只适用于特殊情况的功能。
在需求分析时，我们考虑时间和空间维度。空间维度更多考虑业务趋势的变化和迭代，而时间维度则考虑从零到一再到十的功能规模，以及其迭代路径。我们将问题从多个维度进行思考，而不仅仅线性分析。这样才能更好地理解产品的终态，并避免堆积代码和冗余功能。我们希望保持功能的精简和高效性，因为越少的功能意味着更少的维护工作。
因此，在建立一个平台时，我们综合考虑架构演进、业务变化、时间空间和角色维度。通过考虑这些因素，我们确保产品具有高度的灵活性和扩展性，同时保持功能的精简和高效性。
杨振涛：刚好我们提到这个开源的话题，KodeRover 是怎么基于或者面向社区去构建这种平台类的产品的？第二个部分是我们怎么保障使用平台的用户消除他担心平台锁定的问题？
Landy：嗯，这一点非常重要。关于如何构建开发者平台，实际上我们的产品 Zadig 是面向开发者提供产品和平台服务的，通过开源方式持续提供给开发者更好用的产品。关于如何避免平台锁定问题，我们需要分层次探讨。首先什么是平台锁定？平台锁定指的是当你的组织、流程、技术或基础设施发生变化时，你无法自由、可扩展地调整。当你需要迁移时，会非常麻烦且成本高昂。我曾经见过一些公司将其业务从一个云迁移到另一个云，这个过程耗费了长达六个月的时间，这实在是令人恐惧而痛苦的经历。
从平台的角度来看，云服务提供商的锁定问题确实比较严重，因为使用了他们的基础设施，就好比用了他们的水、电和管道，如果你现在要搬家，他们什么都没有提供。因为它们与其他平台不兼容，这一点非常痛苦。因此，解决平台锁定问题是首要任务，不过 Kubernetes 本身是解除厂商锁定的，也已被各个云厂商商业化支持，而 Zadig 是建立在 Kubernetes 之上，天生就是面向多云友好的，也天生帮助客户降低平台锁定的风险。
实际上，很少有人询问 Zadig 平台锁定问题，相反，Zadig 从设计上尽可能的帮助客户识别容易被锁定的方面。例如，在设计系统之初，我们不依赖于某一特定云服务商。我们将整个云层作为一个抽象层来支持，可以接任何资源和基础设施，即使遇到基础设施中集成难度高的，Zadig 也可以通过工作流的能力来编排。因此，弱集成也是可行的。我认为做任何平台产品都需要考虑采用云原生的方式进行，否则很难发挥云原生最大化的价值，未来发展空间也会非常有限。
另外一个方面是 Zadig 管理服务的方式使用原生的资源定义 YAML 或者 Helm Chart，运维同学使用模板库管理规范，开发者不需要学习另一种 DSL 语言可以很快使用起来。有些平台会定义自己的 DSL 语言，其本质上也是一种锁定，尤其是在面向应用交付领域中，离开后一种语言范式就无法应用到其他地方了，技术栈切换成本，迁移复杂度都非常高。在我们设计产品的时候会把云原生性作为最为重要的考虑因素，关注资源的定义的原生性、变更管道的可扩展性和基础设施的广泛兼容性等方面。举个最近的例子：我们有一个车企战略客户，从一家云服务商迁移到另一家云服务商，作为 Zadig 的用户，他们很愉快地完成了迁移，因为 Zadig 天然支持多云分发和全球部署模式，所以基本上没有网络障碍。这为他们提供了很大的价值，虽然这超出了商业合作范围，但意外地帮助他们实现了云迁移。
总结来说，Zadig 平台是从云原生的角度来构建产品，并考虑整个生态系统，以确保产品在各个环节的定义或其他方面不受限制。您可以尝试使用 Zadig 平台，在现有构建的体系基础上，快速迁移到 Zadig 上，几乎不需要进行改动，只需导入服务定义或同步代码仓。此外，我们的工作流也支持使用 YAML 文件模式，尽管它本质上可能不算是一种锁定，因为工作流本身就是复杂的，您可以进行编排。因此，您可以选择自由地使用 YAML，或者选择使用 GUI 提供的最佳实践，以节省一些麻烦。
另外，还有一种有益的锁定，即当某种模式成为一种被广泛认可的优秀模式后，您离不开它。这并不是因为它不好，而是因为您已经习惯了它，它真的非常好用。因此，从这个角度上来看，我认为锁定意味着您选择了一种正确的东西，它可以持续地与您进行迭代。总体而言，我觉得锁定并不是一件坏事。
杨振涛：刚才你也提到了，我们支持全球化部署，那作为一个开源项目，是否会有一些海外的用户？是否有观察到海外跟国内的实践上的一些差异？
Landy：最开始是小鹏自动驾驶，他们的海外团队促进了我们迭代海外版本。后面遇到极氪、路特斯全球化战略又一次将国际化提到很重要的位置。
杨振涛：客户的全球化推动了我们项目的全球化。
Landy：在我看来，在中国这个复杂的市场环境下，工程平台的迭代非常有利。最初，我们选择在 GitHub 上进行开源，吸引了大量国内企业的关注。这些使用场景为我们打磨和积累产品能力提供了充足的机会，并为市场需求提供了所需的价值。在过去的一年半中，已有近 2000 家企业开始使用我们的产品，而且不断有更多的客户加入。这主要得益于市场需求的推动，因为国内供应链、电商物流和车企等行业的海外扩张正在成为重要趋势。我们的产品基本上是根据客户的业务需求推着我们国际化，并实现相应的能力迭代。目前，我们已经提供了国际化支持，并正在进一步完善产品文档。据我们了解，也有相当数量的国外用户正在使用我们的产品。在海外场景中，我们还需要解决许多问题，例如欧洲的 GDPR 合规要求等，这也是一个迫切的场景需求。
如果有更多的推动力，我们可能会在这方面做出更多努力。尽管使用我们软件的海外用户的场景规模可能相对简单一些，且集成工具链更加多样化，但本质上并没有太大的差异。作为技术驱动的软件，我们并没有特殊性。然而，我们也针对不同规模的差异进行了优化和实践。因此，在这个领域，我们认为国外市场相对来说可能更容易一些。
杨振涛：面对整个平台工程当前的热度，持续的发展的背景，未来的产品愿景和预期是什么样子的？如果我们持续去推进平台工程，是不是未来开发人员自身会越来越多地被平台，包括所谓的 AI、ChatGPT、Copilot 等等所取代？从更长远的角度来看，软件行业的从业者应该从哪些方面去发展和增强自己的技术知识和能力？
Landy：我们团队开源的 Zadig 实际上是典型的平台工程产品，早在“平台工程”概念兴起之前，Zadig 的平台工程实践就已经存在。在早期，由于市场对这一概念的认知不足，我们决定采用一个更易理解的定位，将 Zadig 定位为云原生的 CI/CD 平台。事实上，CI/CD 平台并不负责处理环境治理问题，而 Zadig 最早是从环境治理起步迭代的。最近，我们发布了商业产品 ZadigX，将其正式升级为 DevOps 价值链平台。
尽管市场上有太多概念存在，但我们的核心目标始终不变，那就是将整个软件工程过程智能化，帮助企业实现数字化建设。我们希望在未来的发展中，工程师能够专注于高效的软件工程实践，发挥自身价值，而不仅仅是浪费时间与他人对齐、开会和争吵。对于企业而言，我们希望软件成为企业创新的内在动力，通过软件工程的数字化转型推动数字经济的发展，为各行各业提供快速、高质量、安全的数字化价值，提供更好的用户体验和客户服务。这是我们对产品愿景的期望。
对于持续推进平台工程是否会导致工程师或开发者被平台或人工智能取代的问题，我认为这是一个相对简单、没有太多思考的提问。一个人的核心价值随着职业发展规划和技术趋势而不断进步，这是一个双向螺旋的迭代过程。在迭代过程中，不论你是开发工程师、测试工程师还是运维工程师，你都可以在垂直方向上进行专业能力的建设和持续能力的提升，更应该关注的是如何提供你的价值。如果一个职位容易被替代，那可能意味着这个岗位要么转变为更加熟练使用工具的人，要么它的生命周期就以不同的形式存在。例如，你可能会从测试转变为测试开发，或者从运维转变为关注基础设施的 SRE 或 DevOps。这与早年我们讨论的运维转向业务运维开发的逻辑是一样的。换句话说，你不再需要去操作机器，云服务提供商来处理那些事情。
然而，提到这个话题时，隐含的意思是平台和 AI 有可能取代人类。在之前的讨论中，我们简单地探讨了这个话题，并且我们与 Google 的一些朋友也进行过深入的讨论。我的观点是，目前软件工程或软件系统的复杂度还没有达到完全被信息世界所表达的状态。尽管我可能表达得不够准确，但我的意思是它还没有完全被现实世界信息化的表达所取代。因此，它的迭代和推演更多地依赖于组织和技术的双向演进所产生的合力。所以，它本身并不是纯粹的技术演进问题。
在相当长的一段时间内，如果被 AI 替代，那基本上可以理解为我们进入了下一个时代。因此，我核心观点的判断是，人类的创造力、好奇心以及对现实世界的感知和反馈能力，在相当长的一段时间内不会被 AI 所替代。所以，我个人并不感到焦虑，我也希望更多的工程师们不要感到焦虑。但是在不焦虑的情况下，我们应该更多地去拥抱这个新事物。为什么呢？因为从职业发展的角度来看，当别人已经骑上电动车时，你还在骑自行车是不可行的。
另外，AI 确实是一个不容忽视的重要节点。所以，大家应该以一种新的思维方式去看待这个问题，看看能否将手边的一些事情交给那些可以靠高密度计算能力解决的部分，同时需要考虑全局架构，需要考验你的领导力等综合能力。我认为 AI 无法取代领导力，因为领导力是一个非常综合的概念。因此，你需要知道哪些是你独特的东西。AI 可以在一定程度上取代你的一部分工作，但相对来说还是单一的。还有一些东西，比如意识，到目前为止还没有定论，还没有达到那个阶段，但确实更高级别的知识密度和智慧正在涌现出来。
长远来看，对于大家的职业发展建议，就像之前提到的，不管是工程师还是其他领域的人，都需要思考如何利用 AI 来提升自己的核心竞争力。无论如何，最终还是回归到价值本质上，思考自己到底能够创造什么价值。不要盲目跟从别人的意见，多动手实践，每个人都应该有自己的判断力。
所有新的趋势都是在老的模式下提供新的解决方案。平台工程的引入和发展使得运维工程师能够更好地扩展其支持的业务规模，专业属性和专业化程度越来越高。
杨振涛：在这个阶段，我们收到了一些观众的提问。有一个观众问到关于应用运维和业务运维的事情，我理解这个问题的背景是，一旦建立了平台工程，这些角色可能会失去任务或工作内容。
Landy：实际上，所有这些新的趋势都是在老的模式下提供新的解决方案。因此，应用运维和业务运维这些岗位是永远存在的，只是它们的形态在不断迭代。工程师在这方面有两种属性，一种是面向业务形态，另一种是面向平台属性。这两种属性可以并行存在，而且在一段时间内可能会相互切换。所以，这些角色肯定不仅仅有平台工程的事情要做，主要的职责可能还是与其相关的业务运维或应用运维。
杨振涛：是的，我能感受到大家对于这个问题的焦虑感。在过去的人肉运维时代，一个运维工程师可能只能支持一两个或两三个业务。但是现在，有了平台工程的存在，甚至在过渡期中，单个运维工程师支持的业务规模是持续增大的。也就是说，平台工程的引入和发展使得运维工程师能够更好地扩展其支持的业务规模。这样的变化确实带来了一些不确定性和焦虑，但也为运维工程师提供了更大的机会去适应和应对这种变化。
Landy：相反地，随着业务范围的扩大，可以理解为这个职位的专业属性和专业化程度越来越高。换句话说，如果这个职位具有很高的可替代性，那么从本质上来说，它可能在今天或明天就会被取代。因此，人们不断努力拓宽自己的边界，将自己的职位不断迭代到更加有利于个人发展的状态。随着职位的发展，行业相关职位的薪资水平和职业发展路径也会有大幅度的提升。这种持续的进步有助于推动整个行业向前发展。
在以互联网为代表的数字原生企业中，重点放在业务中台等领域的迭代上，而在行业场景中从事平台工程的迭代具有更大的意义。这些行业场景对一致性的要求更高，对基础设施管理和高质量、自动化的要求也更高。
杨振涛：下一个问题是平台工程在金融制造场景是否有应用，还是说更适合互联网行业？
Landy：就平台工程在哪些行业会更加成熟或具有应用场景这个问题，我认为实际上平台工程或类似的领域，并不特别敏感于行业属性的垂直度。它更关注于业务的安全性，更多关注于行业特定的安全、效率和合规等方面的特殊需求。但在共性需求方面，它本质上是一种工程，对行业并不挑剔。然而，在实践中肯定会有一些长短不一的情况。
目前我观察到的平台工程更倾向于基于 DevOps 的能力向上延伸，或者说是基于链条的能力，即以封装或者更浅层次的平台形式存在。这种平台工程与工程本身仍然存在一定的距离。互联网行业的平台工程能力可能会相对较弱。原因可能在于互联网行业本身就是数字原生企业，或者是以数字经济为生的企业。这两类企业对平台工程的需求不同，数字原生企业更侧重于业务中台等领域的迭代。尽管早期它们也属于平台工程的一类，但垂直属性更加明显。因此，在更为严肃的行业中，我认为平台工程的迭代意义更为重大。这些行业对一致性的要求更高，对基础设施管理和质量较高的自动化要求更高。因此，我认为在传统行业中从事平台工程可能会更加稳健，不会过于急躁，而是经过深思熟虑后明确自己的目标。
核心观点：
平台的价值始终以业务为导向，平台工程团队的使命就是作为支持层，支撑各个业务的能力发展。
评价业务平台工程团队成功的核心指标是业务对他们的认可和满意度，并且能够为各个业务带来共性价值。
杨振涛：我们看到有一位观众分享了自己的观点。他说，短线产品价值和长线系统价值要靠开源来平衡，也需要对短线和长线两种价值进行两种不同的激励系统。我们怎么平衡长期对平台工程的投入和短期的业务的高优先级的开发任务？
Landy：现在在业务迭代的过程中，很多公司通常只考虑业务需求，并且有时会纳入一些数据需求用于观测或为业务体验提供支持，以帮助老板做决策。然而，有一类非常重要的需求却没有得到认真评估，那就是技术需求。我的观点是，在每次大的迭代或一段时间内的结束时，应该评估技术需求。这些技术需求的依据应该来自业务的反馈，也就是说，你在处理了很多业务需求后，肯定要对这些问题进行复盘，包括事故和质量问题。复盘之后，你应该有一个结论，即确定这个问题最可能在哪个阶段解决。如果在架构期间需要关注它，那么你就要将一些技术需求纳入考虑范围。因此，平台的价值同样是由业务来决定，也就是说你需要证明平台的价值始终以业务为导向，而且能够体现业务价值的感受。但是，它需要通过不断迭代来实现。如果有一个平台工程团队，他们的使命就是作为支持层支持各个业务的能力发展，而业务团队则负责业务开发。
对于如何评价平台工程团队的成功来说，核心指标就是业务对他们的认可，也就是他们的满意度很高，并且能够为各个业务带来共性价值。因此，你们两个团队的评价体系可能会有所不同。这已经到了一个相对的阶段，如果有独立的团队来负责平台工程；如果没有的话，那么这类平台工程很可能更多地依赖于对技术需求的评估时机：也就是说，当你的痛点明确，并且时机合适，而且老板的意识非常到位。在过去，他可能具备很高的素养和品味，我们就可以直接自上而下地推动这个过程，短期可能会有些阵痛，但中期会非常顺利，长期来看会展现出很高的远见。但是改革总是伴随着变革的阵痛，所以从上至下的人是有意识去面对的，但是从下至上的人大多不愿意承担责任。
平台工程团队类似面向企业内部的 To B 服务商，他们需要提供面向业务的解决方案，包括制定相应的产品策略、市场推广等运营体系。
杨振涛：我们再回答一个问题。平台建设和软性的体系建设是否都是平台工程团队的职责范围，我认为这个问题隐含了一个词，就是平台团队或者平台工程团队。因为我们知道在许多中大型企业中，都存在所谓的平台团队，但是大家对于平台团队的职责并没有非常明确的共识，每家企业可能都有自己的定义。这个问题聚焦在就这个团队而言，平台建设和软性的体系建设是否都是在这类似这种团队的职能范围？
Landy：我认为任何平台从产品演化到平台阶段都需要具备解决问题的能力。作为一个内部团队（可以理解为平台团队），类似于面向企业客户的 To B 部门，你的服务对象是内部的各个团队，因此你必须提供相应的解决方案，包括制定相应的策略、推广等运营体系。可能性的路径：首先在某条业务树立一个标杆，然后进行更大规模的业务推广，并不断迭代和改进你的平台能力。从这个角度来看，它本质上是一个完整的 To B 循环。
在我之前的公司，我负责平台工程的建设。最终团队成熟的形态有点像以流程变革为主导，用相应的工程平台来支撑（即平台工程），专门面向业务的服务化团队做下沉式服务（BP team）。BP 他们会不断整理技术需求，并对业务本身也非常了解。他们的目标是如何将平台和业务打通，实现效能平衡。最后很自然形成了一个改进循环，涵盖了“流程变革、工程沉淀、服务化（BP 化）“的三角形的闭环。
因此，我认为这些建设都应该由平台团队承担，尽管在初期可能会有一些混乱，但这是很正常的，因为任何实践都需要时间去找到适合自己的方式。
杨振涛：刚才提到的实践，其实也是我个人特别想问的一个不在计划内的问题。我们之前提到了平台工程，它倡导了一些实践方法，比如内部开发者平台、内部开发者门户以及开发者接口的自助能力等。平台级产品的引入可以改善开发者的体验，并提供丰富的文档供自助使用。另外，平台能力的接入以及上线后的自动运维等也是重要的考虑因素。然而，这些实践方法可能与你之前提到的需求存在一些矛盾，有时在特定场景下，确实需要一个业务合作伙伴来协助平台的导入。
Landy：这是一个非常好的问题。就像任何产品一样，平台工程也经历了从零到一的建设阶段。我理解到目前为止，真正成熟的平台工程并不是很多，所以我描述的情况并不是指终态，而是我们希望达到的目标。当前的状态可能是混乱和孤立的，存在着流程不明确、冗余和一些难以解决的问题。这些问题包括企业内部的文化和组织问题。因此，这个终态是大家都希望实现的理想状态，即每个人都能够专心编写代码并感到开心，团队合作愉悦，工作不累且不需要加班。这是一个终极目标。
然而，当真正实现自服务的时候，我们可能会对另一个问题产生怀疑。是否存在可能，像 ChatGPT 这样的生成式 AI 技术会将我们整个同化掉？因为一旦所有事物都可以被描述，它实际上可以生成新的模式。所以目前还存在许多人感到困惑，通过平台工程，我们试图降低这种混乱，将熵减少，并沉淀一部分能力，以便让所有角色都能发挥出核心价值。总的来说，这是一个相对能够达到的状态，至少是我目前认为可能实现的状态。
内容提要：
DevOps 并不是快速交付时才需要，目的是更好更有效的满足用户的需求。敏捷开发降低试错周期并提高成功的概率。在任何领域，不管是汽车制造企业还是其他行业，开展 DevOps 都是非常必要的。
汽车制造是现代工业皇冠上的明珠，工程复杂度极高，通过平台工程可以降低成本、缩短科技研发时间。中国车企也正在软硬并行的推进 DevOps 建设和平台工程，以在全球范围内获得更大的优势和发展空间。
杨振涛：接下来我们进入答疑的环节，已经有不少的问题，我们来挑选一些。有一位观众说，能不能请老师聊一下汽车制造业的 DevOps 开展的必要性，或者说收益是啥？
Landy：嗯，这让我想起了汽车领域，我曾经深入研究过汽车制造，因为造车并不是一件简单的事情。汽车可以说是现代工业皇冠上的明珠，它代表了完整的复杂度。我曾经花了大约三个月深入了解这个行业，并与一些客户合作，以获取关于这个行业的详细资料。实际上，汽车行业可以简单的分为两类，一类是新势力造车，一类是传统汽车制造商，很多会开辟新能源汽车领域。它们有着不同的战略打法和发展方式。
关于 DevOps，我认为存在一个误区，即认为只有在需要快速交付时才需要 DevOps，以及只有在需要快速交付时才需要进行持续集成 / 持续交付（CI/CD）。这个观点本身是错误的。敏捷开发并不是为了让我们犯更多的错误，相反，敏捷开发的目的是降低试错周期并提高成功的概率。敏捷开发的理念包括一个很好的例子，就是"四菜一汤"的逻辑。当上菜时，如果四道菜和一碗汤都上来后发现全都很咸，那就没法改变了，这就是大规模交付的问题。然而，如果采用敏捷或者 DevOps 的方式交付，我会先尝一口汤，如果太咸了，厨房可以及时调整。这样，在一个小时内我就可以享受到四道菜和一碗汤，而且可以不断调整以满足我的口味。而那种一次性上齐的方式可能只需要 40 分钟或者 30 分钟上菜，但你会发现它不能满足用户的需求。所以，这是一个核心问题，就是要理解它是一个不同维度的问题。因此，在任何领域，不管是汽车制造企业还是其他行业，开展 DevOps 都是非常必要的。
在车企领域，中国造车并没有核心的底层单点技术优势。要在市场占有率上获得优势，车企需要在差异化和成本优势方面下功夫。其中，平台工程和 DevOps 可以带来平台优势，尤其在成本和交付效率方面。举例来说，吉利集团的 SEA 浩瀚架构是一种硬件架构，可以理解为硬件工程的 DevOps。相比之下，我们更多地从事软件的 DevOps，因为只有通过这种平台工程，才能将成本优势最大化。与制造单车的成本相似，软件开发也遵循类似的原理。无论是制造一件产品还是开发软件，采用工程化的方式都会带来更高的效率、质量和迭代效果。我研究过的 SEA 浩瀚架构有四千多个 API，重新定义新三电。从硬件上支持从 A 级到 F 级车，是一种高度可扩展和自由弹性伸缩的硬件架构。实际上，DevOps 本身也提供了一种类似骨骼的能力，让你连接各种能力并建设各种能力。因此，在车企领域，我认为更需要进行这种 DevOps 实践。虽然这项工作难度较大，从企业收益的角度来看，通过平台工程降低造车成本是非常明确的目标。在我个人看来，如果能通过平台化的思想造车能大大的降低成本，让中国在全球范围内都具备更大的优势和发展空间。除此之外，其他优势可能很容易追平，但这个隐藏的优势非常重要。
通过平台化造车可以降低成本、缩短科技研发时间，目前中国车企在硬件 DevOps 领域已投入大量资源。刚才提到的浩瀚架构，据估计大约花费了 180 亿。像极氪 X、极氪 001 和 smart 等车型，都是使用该架构作为支撑，这事其实非常有趣的。此外，在车企领域，整个研产供销服的全流程数字化、供应链的复杂度、难度都非常高。对于 C 端，可能涉及营销面向消费者的场景，例如相关的 APP 等。而对于 B 端，涉及到企业内部整个流程的数字化，以实现更好的衔接和服务。
内容提要：
信息化发展现状下，可以分为两类企业：一类是数字原生企业，像互联网大厂，另一类是利用数字技术提升行业生产效率的企业，它与行业成熟度和发展现状有关，制造业是我国重要发展方向，尤其像车企已经有大量的信息化尝试包括云原生、DevOps 等。
并不能单纯以发展现状来评估是否前沿，制造业本身存在复杂度，是远远高于互联网形态的企业。成熟度方面，从企业内部迭代效率、组织的敏捷性以及业务的感知度来看，都还有很大的发展空间。
杨振涛：观众说总感觉信息化发展前沿还是以互联网大厂和移动端为主。那目前制造业信息化发展比较好的案例有哪些企业？
Landy：嗯，就这个问题而言，我可能不能完全以大样本的方式回答，但可以通过一些自己的发现或者一些浅显的观点来探讨。我认为信息化发展主要包括信息化、数字化以及后续的智能化。刚才提到了互联网巨头或者互联网公司，它们本身就是数字原生企业。而我们更应该面向更有价值的场景，深入到产业和行业中去。要将数字化或者信息化提升到更高的层次。
因此，可以将其分为两类：一类是数字原生企业，另一类是利用数字技术提高行业生产效率的企业。这似乎是信息化时代的发展趋势。但我更认为有价值的、真正积累价值的是在产业和行业中实现这种发展。而且，目前各行各业都在等待我们利用技术赋能它们，包括使用 Kubernetes 等技术。然而，各个行业的成熟度和现状各不相同，特别是在工业或者我认为在制造业方面，这是我国未来非常重要的发展方向。它需要利用数字能力、技术和工程能力来实现更好的发展。因此，从趋势上来看，大致是这样的理解。
那么，哪些公司在这方面做得比较好呢？我认为刚才提到的平台工程中的案例，比如极氪，他们在这个领域相对较为出色。他们非常擅长做一些比较"geek"的工作，例如极氪全域数字化部门，提出数字战略“三化平台”，也就是平台工程商业化的体现，非常具备前瞻性。他们通过不断迭代这些平台来为业务的发展提供支持。然而，实践起来，造车的难度肯定很大，因为整个系统本身的复杂性很高。在制造业中，像他们这样走在前沿的公司可能会有一些相应的 DevOps 建设，包括蔚小理等公司。但是就成熟度而言，目前看来还没有达到一个相对成熟的状态。至少从内部的迭代效率、组织的敏捷性以及业务的感知度来看，都还有很大的发展空间。
核心观点：
AI 技术演进过程会对运维平台的形态会有变化，我们需要对技术保持敏感度，不断发挥更大的技术价值，同时根据个人擅长的领域去规划职业发展方向。
AI 技术替代的更多的是事务性的低附加值劳动，反而随着应用规模会越来越大，运维需求更加多样，岗位价值会越来越高。
杨振涛：时间关系，我们再来挑选最后一个问题来回答，这个问题其实我们之前有提到一部分，观众提问说 AIOps 和 ChatGPT 对传统运维平台有啥挑战，大家如何面对这些变化？学习转型，感觉越来越全栈化。焦虑感十足。
Landy：实践出真知，我们还是具体来看到底改变了你的哪些方面，不能臆想出一个人工智能来替代我，比如在运维领域它能做什么。我们可以列举一些实际应对变化的例子，确实会逐步朝某种形态发展。因为任何一个平台都不是静止的，不可能说你公司买了一个叫做"AIOps"的平台后你就下岗了，这是不可能的。它是有一个演进过程的，在这个演进过程中，首先要对技术保持敏感度，另外要勇于尝试新事物，抱着试试看的态度，它能带来价值，那你就获得了价值；如果没有带来价值，你也看清了真相。所以我认为作为工程师，我们要一直运用自己最擅长的东西，进行实践，采用这种方法论去做事情。我确实看到很多公司对运维岗位有一种泛化的趋势，上一期提到业务运维、平台运维，还有一些 DevOps 或 SRE，边界不是特别明确。
我的建议是，对于那些想在技术领域发展的同学，可以向云原生方向转型。而如果你对公司业务非常了解，并且具备架构等能力，可以朝平台架构的方向发展，这两个方向都可以。目前我还没有看到太多关于运维平台的相关技术方面的挑战，相反，在代码生成方面，比如 ChatGPT 和 Codex，对于开发工程师的提效会有一些帮助。我认为对于传统的运维平台或者运维工作来说，你可能要面对的应用规模会越来越大，运维需求更加多样。为什么呢？因为人工智能带来了新的应用场景。所以它离你还有一段距离，如果非要推翻谁的命运，那么先影响到开发者，然后再到运维，因为运维的复杂度更高一点，相对来说会比较晚一点。
杨振涛：其实从整个行业的发展规律或者说轨迹来看，运维的单个的人效是持续在提升的。
Landy：非常认同，所谓的职位的垂直化和专精化程度越来越高，也就意味这个岗位的价值越来越高。
杨振涛：好的，对于运维的同学们也不需要过于焦虑。我们的嘉宾李倩老师给出了很多关于学习、发展和转型的建议，非常感谢她和所有观众的参与。平台工程主题系列的三期直播访谈今天全部结束了，但平台工程仍将持续演进，我们也将继续关注。欢迎大家在我们的平台工程技术群中进行进一步讨论、交流，以及分享各自团队的实践经验。今天的直播到此结束，谢谢大家的参与。
Landy：谢谢大家，非常高兴跟各位探讨。
李倩，KodeRover 创始人兼 CEO，开源持续交付产品 Zadig 作者，前七牛云工程效率部研发总监。
杨振涛，vivo 互联网研发总监，目前关注开源治理、技术社区与工程文化建设。具有 15 年多个领域的软件研发经验，此前先后从事生物信息与基因测序领域的科研工作、电商与 IM 架构以及搜索引擎研发。开源技术与技术传播爱好者，先后参与和负责 Circos、Redis、Jenkins、Elasticsearch 等社区的本土化，也是 TED Translator & Reviewer。为了更加系统地收集并记录平台工程主题的技术趋势及发展历程，我整理并创建了一个 awesome list 供大家参考，欢迎各位参与贡献和维护。Github 地址：https://github.com/toptechevangelist/awesome-platform-engineering。
你也「在看」吗？ 👇
文章引用微信公众号"AI前线",如有侵权,请联系管理员删除!
