平台工程和ChatGPT会让运维们失业吗？

Landy：这是一个很好的话题，虽然软件工程经历了 50 多年的发展，但国内却很少提及。更多集中在软件技术和应用方面，这让工程这个词显得好像并不是那么性感。

我认为在整个软件工程化方面，与企业现状存在着严重的不一致。在国内，过去一段时间，大多数企业都是在冲业务，处在一个业务为王的时代，如果跑得慢，就会被淘汰。短期内先证明自己的商业模式，中期再去维修技术栈，很多公司基本上很少有工程化，他们的代码可能有十年二十年之久，这导致了历史负担和后期维护困难的问题。在这个过程中，中国也发展了大量的软件形态的公司。

软件工程最早的成熟期是在国外，那个时候工程是一件确定性很强的事情，软件工程有很严格的质量管控和大量的管理过程，包括一些 SQA 的流程来保障软件工程的稳定运行，像 IBM、微软等公司都有很多这方面的实践。软件工程化早已经出现，但是随着云技术等变革，其实现方式发生了变化。

现今，软件工程化在行业内和企业需求之间存在哪些不一致呢？企业需要更快地发布软件，以满足客户需求并保持竞争力，这给软件开发人员带来了巨大的压力，要求他们在短时间内交付高质量的代码。然而，相当一部分企业试图通过增加人力和研发投入的时间来解决业务问题，这并不一定是最好的解决方案，而且还存在安全问题和人才短缺问题。但从企业的角度来看，他们并不一定意识到这是工程化问题。

具体来说，企业和软件开发人员之间存在许多矛盾。例如，工程师的工作强度很大，经常需要加班 996，而且他们也面临着 35 岁的职场焦虑和职业寿命较短的问题。然而，由于企业存在大量的会议和对齐等工作，工程师很难有时间专注于编写代码，可能只有 20% 的时间用于编写代码。这些矛盾和问题使得企业很难理解研发人员在做什么，同时也影响到了软件工程化的实施。事实上，研发人员的工作更多地涉及到问题的定义，例如需要解决什么问题，遇到了哪些问题，以及为什么这些问题难以轻易解决等。作为业内人士，我们了解现实世界需要被抽象化，同时我们也需要面对许多实际问题，需要进行大量的沟通、协作、需求分析和架构问题的解决。因此，从这个矛盾和痛点的角度来看，我认为现在企业的发展和软件开发领域已经到了可以解决且迫切需要解决这些问题的阶段。在我看来，这个矛盾和痛点非常明确、明显、痛苦，对企业和研发人员来说都是如此。

综上所述，双方体感不太好的方面主要集中在研发人员的工作压力和企业对软件开发的理解不足。即企业方面，对研发的感知是不确定他们在做什么，经常要证明自己的价值，研发团队在国内的存在感和地位普遍都很低。工程师方面长期负荷过重，参加大量会议，投入较少在编码和技术上，工作体验也较差。

杨振涛：好的，现在让我们更深入地探讨企业和开发人员这两个角度。在我们日常的编码交付和上线运行的循环过程中，对于软件企业来说，它在开发体验方面的投入，特别是在软件开发方法、工具和平台方面，有什么价值呢？

Landy：关于第一个问题，在软件企业中，流程、方法和工具对于提升开发者体验的价值是非常大的，尽管很多企业并没有真正解决这个问题。我认为一个软件公司如果不能让工程师在日常开发工作中感到愉悦，那么这家公司的效率一定不高。存活下来的公司员工体验都是很好的，对于软件公司来说，工程师是主导力量，他们的体验对于公司的成功与否有着重大的影响。因此，提供无缝的流程、工具和平台，可以帮助工程师更好地创新、提高速度和效率，并最大化公司的价值。这对于任何一家企业客户来说都是一样的，因为未来所有的企业都将以数字驱动，而提升研发部门的体验是改善数字经济和走向市场的重要方式之一。

举个例子，比如做汽车企业智能座舱软件的研发，如果软件更新速度慢或更新质量差，就会直接影响终端消费者的体验。那么这里更新的关键点是什么？更新的关键就在于内部的软件工程师能否更快、更高质量地进行软件迭代。这是一个企业内外循环的过程，只有通过内部循环打通，企业才能为外部提供更好的商业价值，例如更快的上市时间、更好的客户服务、更多的创新等。因此，在这方面，企业应该投入更大的力量改善研发体验，那些没有意识到这一点的公司很容易失败，因为他们无法用技术武器武装自己。

杨振涛：目前业界有哪些典型的工具或产品可以通过减少开发人员的重复性工作和认知负荷来提高他们的开发体验呢？我们都知道，新技术每天都在不断更新，但业务开发人员不可能每天都去追这些新技术。因此，对于开发人员来说，减少重复工作或新技术带来的认知负荷，是开发体验中非常重要的一个组成部分。

Landy：在我看来，近年来的趋势在软件工程和开发人员方面有了很大的改善。现在有很多工具或产品可以帮助减少重复性劳动，比如集成开发环境、代码高亮、自动完成和调试工具等。例如我们现在全员使用的 Copilot，它作为一个好的助手，可以大大提高日常编写代码的效率。另外还有一些专注于不同语言的编辑器，例如 Golang 可以使用 GoLand 或者 VS Code，Java 可以使用 JetBrains 全家桶等。当然还有一些专注于机器学习等领域的 IDE，这些工具都与代码终端最相关的开发工具有关。

在 CI/CD 工具部分，解决的问题是如何让重复的流程更加自动化，包括整个 pipeline 或 workflow 的管理。这个过程的自动化是开发中的公共基础设施的一部分，让自动化成为现实，避免每个人都去找某个环节的负责人。通过 webhook 和其他方法，可以快速地将代码从 code 到 ship 全链路地自动化。我们开源 Zadig 也在这个领域开展了工作。

此外还有一些低代码平台，它们有一些领域建模的能力，让业务人员在不需要开发人员参与的情况下，通过组装可用的构建块来创建业务应用程序。这些平台可以减少重复性的开发工作，避免实施外包。通过让业务人员自己创建和维护他们的应用程序，这些低代码平台能够使组织更加敏捷和创新。

当然，还有像 DevOps 平台这样的工具，虽然 DevOps 这个词在近两年才逐渐流行起来，但它的演进过程非常丰富。从最初的一个方法论，到后来逐渐衍生出各种 DevOps 平台，它的本质是希望降低团队之间的认知负荷，达成共同的目标。现在，它统称为 Xops，还在不断地扩展和泛化，万物皆可 Ops，就比如我们经常提到的 FinOps、TestOps、MLOps、DataOps 等。最终，它要达到的目标是让团队可以更加高效地运作，释放更多的价值。所以，这个领域也非常重要，可以减轻开发人员的认知负荷。

关于典型的减少开发重复工作和认知负荷的工具或产品，我认为技术人员追求技术或体验新技术是正确的，平台工程并不是要求开发同学使用标准的技术，这是一个错误的论断。相反，平台工程应该让适合的技术得到应用和发挥，让成熟的技术得到沉淀。这是平台工程的解决方向，但平台并不能解决所有问题。这是我抛出的一个简单论点。

因此，我认为在开发中，投资开发体验是非常重要的，需要加大投入。只有工程师体验好了，企业通过软件实现创新，才能在市场中赢得份额。此外，开发人员日常使用各种类型的工具，包括自动化工具、IDE 工具、DevOps 平台和低代码平台等，以降低重复性工作和认知负荷，并提高开发体验。这些方面的投资可以大大提高开发效率，使团队能够更快地交付高质量的软件产品。

杨振涛：好的，我们之前已经聊到了 DevOps，现在让我们继续深入这个话题。DevOps 作为业内高度共识的一种优秀实践，您认为目前工具化与自动化的程度是否可以作为 DevOps 实施成功的一个标志？大规模 DevOps 实践的关键挑战是什么？

Landy：这个问题很好，它涉及到几个关键要素。工具化和自动化是 DevOps 中非常重要的组成部分或指导思想之一。一些公司将大量工具整合成一个平台，以解决一些重复的问题，包括 pipeline 和自动化引擎。但是，要真正实现 DevOps，除了工具化和自动化之外，还需要其他要素，比如文化转变、持续改进和团队协作沟通等。这些因素更加难以实现。

很多人可能会误解 DevOps，认为“我们不需要 DevOps，因为我们不需要那么快上线”。因此，了解 DevOps 的本质非常重要。成功实施 DevOps 的标志是从文化实践到工程落地的一个系统性工程，而不是仅仅实现工具化或自动化。因此，一个强大的 DevOps 平台应该能够创建一套相对标准化的工具流程，并能够非常灵活地适应各种场景。此外，它还应该包括一些基础设施的自动化，以及持续交付和持续集成等好的实践。

尽管工具化和自动化并不能准确地表达 DevOps 的标志，但它们是推动 DevOps 实践的关键因素之一。当人们提到 DevOps 或自动化时，这意味着他们已经认识到了自动化和工具化的重要性，并且正在朝着这个方向努力。因此，工具化和自动化的意识比很多其他的做法要好得多，它们是推动 DevOps 实践的关键因素之一。

大规模 DevOps 实践成功的关键挑战在于是否理解了问题的本质。实际上，这个词提出的背景就表达了一种冲突，“DevOps” 本身就是一种博弈，代表了开发和运维之间的零和博弈。为什么需要 DevOps？因为开发团队希望快速交付产品，而运维团队希望确保应用程序的稳定性和安全性。这种博弈不仅存在于 DevOps，还涉及到其他角色，例如开发、测试、运维、安全、IT、财务等。任何一个环节的问题都会对整个价值链产生影响，因此需要从博弈论的角度来解决这个问题。DevOps 需要解决的核心问题是如何将零和博弈转化为多边博弈。我们需要思考如何在开发、测试、部署和运维等环节中建立多方合作的机制，以实现整个价值链上的协同效应。这不仅需要技术工具的支持，更需要从文化和组织架构上的变革，以及人员间的协同和沟通等方面的不断探索和实践。因此，只有当我们真正理解了 DevOps 问题的本质，才能够在实践中获得成功。

杨振涛：因为 DevOps 本身与实施规模直接相关。新兴的平台工程趋势能否为我们带来一些新的启示和解决方案呢？

Landy：平台工程这一概念是 DevOps 概念的具体延伸和实现，它可以被视为软件工程的实例化。让我们来用字面意思拆解一下“平台工程”这个词：其中，“平台”这个词很好地涵盖了整个价值链，只有能够上链的环节才能提供价值。这个价值链的两端分别是各种职能工程师和生产运行服务（软件）。所有在链上的人都有双向关系，通过平台化能力，可以建立共识。然而，由于涉及配置、基础设施等多种因素，这个过程也会存在链下的部分，需要解决系统性问题，包括人、流程、系统和组织等多种因素。另一个词“工程”很好地涵盖了这个部分。因此，平台工程提供了一种可能性，让我们能够更系统地解决软件开发这个复杂的问题，并提供了一个很好的思路。

在过去，DevOps（Xops） 可能被视为一个概念，而现在平台工程将其可以被实现并具有实际的商业意义。平台工程需要高度抽象，灵活自由，扩展性强，并且与业务密切相关，可以被看作是基础设施的一层，业务系统的支撑层，通过提高软件交付的质量和速度，为企业带来更多的商业价值。

杨振涛：我们提到平台工程，总有些不可避免的话题。您认为平台工程和 DevOps，包括 SRE 之间是一个什么样的关系？从团队职责到概念的内涵外延等方面有何异同？

Landy：实际上目前许多公司在运维职责划分方面存在混乱。有些称之为 DevOps、SRE 等，还有其他各种称谓，如业务运维、系统运维、基础运维等。职责划分经常调整，公司的组织结构也在变化，总是不断合并和分裂，进行组织重构。

这个混乱的原因在于需要有一个能够承担所有权的人来解决问题，因此出现了许多不同的平台组或其他组织形式。因此，不强调 DevOps 和 SRE 之间或平台工程之间的区别，因为它们都是解决问题时产生的不同视角。它们的核心视角可以分层，具体实现方式取决于团队或公司的不同方式运作，以及如何将业务流程呈现给用户。在不同公司中，这些职位的名称也不尽相同，如 SRE、运维、云原生工程师等等。

无论是 DevOps 工程师、SRE 工程师还是平台工程师，他们都可能在做类似的工作。从这个角度来看，他们之间的区别可能不明显。但从企业或研发组织需要什么样的工程师来看，越来越需要为开发者、公共平台层建立研发团队来解决共性问题。

因此，从面向业务和面向公共两个角度来看，无论是 DevOps 工程师还是 SRE 工程师，还是其他类似的职位，更多的要看他们是面向业务还是面向公共的。如果是面向业务的，像 SRE 这样的定位可能更为合适；如果是面向公共的，那么 DevOps 可能更加明确一些。在更垂直的领域中，可能还需要加上领域专家的属性。相对来说，DevOps 这个概念比较混沌，因为它解决的问题很广泛，很多公司都将其视为一种上帝角色。因此，本质来讲更多的是根据自己是面向业务还是非面向业务来区分职责。

在更广泛的职责范围内，平台工程师将技术研发与业务价值联系起来，使得研发价值可以更好地理解和传达。以前，研发被认为是一个黑盒子，不能清晰地解释技术与业务的关系，但好像出了任何问题又与我们有关。老板不理解软件的复杂性，很多公司的 CTO 也很尴尬，因为大多是技术出身，没有太多商业意识。作为花钱的部门，也不知道可以创造多少商业价值。但是平台工程提供了一种可能性，让研发更好地与商业联系起来，通过产品或平台向业务展示价值。这种服务能力可以被标价，研发可以通过效率、质量和成本等指标来证明对业务的贡献。因此，平台工程提供了通向商业价值的路径，为 CTO 或 VP 们提供了一个澄清业务价值的通道。

外延方面我举个例子，FinOps 是一种元年技术趋势，它主要是通过工程、财务和产品团队协作，优化资源的使用，平衡投入产出比。平台工程提供了这种可能性，让我们能够更好地度量细粒度的成本、效率和质量，并优化资源的使用。如果没有平台工程的支持，这将是非常困难的。因此，从工程化和服务化的角度来看，平台工程将是软件工程走向成熟的基石，可以帮助团队更好地实现商业价值，并且可以提高软件开发生产力，是一个非常好的发展趋势。

在未来的企业内部，软件将成为一种商品存在。为了评估软件产品的价值，需要商业化并计算开发成本、资源成本和业务调用的资源成本。但如果没有基于平台工程的工程化基础，这些细节很难被度量。因此，工程化是软件工程朝着服务化、数字化和 AI 智能化发展的基础。这对于商业、团队价值呈现以及软件研发本身的发展阶段都非常重要。工程化能够将软件工程转化为一种商品化存在，使其走向更成熟的发展阶段。通过服务化和商业化标价，我们能够更好地理解软件产品在效率、成本和质量等方面的表现。此外，工程化还提供了从资源视角来看待问题的可能性，以便更好地理解软件产品的投入成本和产出价值。

总之，软件工程正在逐步走向数字化阶段的成熟发展轨迹。对于整个生产链条中的生产力（例如工程师）来说，这也是一个非常好的发展趋势。通过工程化、服务化、数字化和 AI 智能化的发展，软件工程转化为成熟商品一样存在，从而证明技术和研发的价值。

杨振涛：今天有不少的问题，我们先来选几个回答一下。有观众问说。平台工程如何确保不是在重新发明轮子？

Landy：我的理解是，发明轮子是工程师的天性。我认为发明轮子并不是坏事情，因为它是创新的根源。有了不断产生的轮子，一些轮子被留下，一些被淘汰。这是很正常的。当然，制造轮子是必要的。平台工程是一个非常好的例子，因为工程这个词本身就代表了复杂性。因此，平台很可能需要制造轮子。在软件开发和国内工程效能、效率工程、平台等领域，团队往往被认为正在发明轮子。我们需要反向思考为什么会有这种观点。

在国内存在一种普遍现象，即人们通常采用相对实体成果的方法来解决问题。例如，敏捷组织如果没有开发出一个平台，就很难证明其价值。由于脑力劳动难以通过物理化表达，很多人采用一种手法，即先开发几个工具，然后将它们连成一串以展示给老板。这样就能达到季度的 OKR 和 KPI，最终获得奖励。但半年后，人们会发现一个问题，即不知道如何证明这个平台的价值，也不知道如何向老板讲述这个故事。这是很多平台开发者都会面临的问题。因此，每当有一个想法或问题出现时，人们倾向于制造一个轮子来直观地向老板展示其价值。老板认为实际存在的东西更为重要，这就导致人们的认知、知识和方法可能变得不那么重要。这种表现实际上是思考不够深入的结果。

在平台工程领域，制造轮子并不是目的，而是手段。平台工程需要处理的复杂度很高，不能随随便便就能造出来。如果随便搭建一个平台，将其各个部分串联起来，可能会遇到一些问题，如 Zadig 与客户打交道时常常遇到其他类别的内部平台或者外部系统，它拥有比 Zadig 系统多的多的功能点，但是仍然带不了协同效率的提升，研发同学体感仍然是很差的。其实平台工程需要通过规模化、可复制的模式来解决这些问题，用新的模式创新或者新的技术创新来解决这个问题，而不是只是简单的堆砌。这才是平台工程和传统开发的本质差异。

举例来说，NASA VS SpaceX 的研发速度差异，与马斯克的工程思维密切相关。马斯克善于将重复的工作流程化和自动化，甚至将一些自动化的步骤进一步简化和抽象化，从而提高工艺效率和质量。

因此，在平台工程和工程领域中，我们需要摒弃“发明轮子”的思维方式，要从根本上去思考问题，并用新的模式和技术去解决问题。

杨振涛：我们把这个问题再深入一下。在云原生持续发展的今天，看起来是一切都在自动化。自动化做得越来越好是不是意味着一些技术岗位有可能被人工智能所取代？大家现在都很关注 ChatGPT 是否会让一些人失业，从实践表现中看，它确实有一些这方面的潜力。它擅长一些规律性强，执行层面的工作，很擅长从人类去学习，能够快速去提取这些信息，能够处理重复的模式化的工作。那这个问题李老师是怎么看的？

Landy：最近大家都有不同程度的 ChatGPT 焦虑症，正好我们 Zadig 团队前段时间邀请了来自 Google 的知识图谱专家、数据专家以及技术专家一起讨论了这个话题。我相信在 ChatGPT 时代已来，每个行业都会重新思考他们的工作和是否有可能被替代的可能性，这不仅仅是工程师，而是所有人都可能会面临的问题。

不过我个人认为技术岗位在不断迭代，新技术的出现会为这个职业带来更多的扩展性和延展性。这就像过去没有计算机，但随着计算机的出现，工程师才得以诞生。未来，技术岗位也会随着技术的发展而不断变化。因此，我认为大概率在短期或一段时间内，技术岗位不会被取代掉。

另外一个点就是，很多人认为软件开发工程师只是在写代码，但这种认知并不准确。作为工程师，我们知道实际上有相当一部分时间是用来思考问题的，而不是在写代码。我们需要思考如何定义问题，如何将现实世界抽象成计算机可以理解的形式，而这些都是机器代替不了的。机器不可能替代人类，思考一个连需求都讲不清楚的问题。因此，我们的能力更多的是在于思考、定义抽象问题，而不仅仅是写代码。当然，写代码是我们工作中非常重要的一部分，而现在有很多优秀的工具和技术可以帮助我们更高效地完成这项工作，这使得我们能够将更多的时间用在思考和解决问题上，将码农变成工程师。

总之，新技术的到来必将带来各行各业的变化。虽然一些具有规律性强或执行性高的工作可能被自动化取代，但很多需要人类特质的工作，如创造力、决策力、情感和沟通协调等，是难以被替代的。因此，新技术更应该被视为我们共同的工具，工程师应该积极接触并将其与工作相结合，以更好地提高工作效率和创造力。

我的日常工作已经离不开各种相关工具了。比如，写代码时使用的 Copilot 或微软基于 GPT4 推出的 的 office 组件。这些工具可以提供一些建议，帮助我更高效地撰写文档和描述问题。使用这些工具确实提高了我的效率，因此，我建议工程师们快速开始使用这些工具，结合自己的工作实践去尝试这些新技术。不需要过多的焦虑和压力，只需去尝试并感受这些技术能够解决哪些问题，这比听别人讲多少或者造成多少焦虑声音都更有意义。

随着新的 AI 技术的到来，将会带来许多新的机会和需求。我的个人预测是，基于 AI 技术的应用会更加大规模，软件研发的体量和应用（服务）也会增加。因此，软件研发工程师的角色可能会更加多元化。但每个工程师都应该深入思考自己的工作是否真正带来了价值。无论是否使用 AI 技术，都应该思考核心价值。当然，我们今天讨论的平台工程不仅仅是业务开发，而是提供核心价值的好方法之一。因此，构建平台也是一个很好的思路。

杨振涛：其实我们也可以从另一个角度来看待这个问题。虽然我们担心被替代，但如果我们看看目前我们正在做的事情，例如 SRE 和 DevOps 相关的平台，AI 目前还无法完成这些任务。这至少说明了，在短期内，这些同学不必担心失业的问题。

Landy：我认为，SRE 和 DevOps 工程师仍然属于相对年轻的领域。通常工作范围非常广，需要依据他们的技能和经验来做出许多决策和操作。虽然未来自动化 AI 等技术的发展将越来越发挥作用，但目前短期内 DevOps 和 SRE 的工作仍有很大缺口，因此这些工程师不必担心失业问题。相应的，业务开发人员可能需要更多地关注全局视角和大局观，并提高抽象和写作能力。而对于 SRE 和 DevOps 工程师来说，他们应先掌握基本技能，例如搭建工程、构建良好的平台和基础设施，为研发团队提供更好的支持，并解决实际生产中的问题。由于软件工程本身尚未完全被理解和掌握，使用更高模式级别的技术仍需要一段时间。

我认为，人工智能技术的基础是对现实世界描述和信息的理解。然而，软件研发、DevOps 和 SRE 工程师所面对的现实世界是非常混沌的。由于很多公司的软件研发现状是孤立、分散、抽象和碎片化的过程，实现工程化还需要一段时间。这种情况下，人工智能技术的应用可能需要很长时间。我们不能低估人的复杂性，它总是比系统和技术的复杂性更高。因此，在这个过程中，我们需要不断思考、改进和创新，以更好地利用人工智能技术推动软件研发的发展。

杨振涛：好的，因为时间关系，我们今天的访谈不得不提前结束了，后续我们会再次安排一个时间，为大家呈现一个完整、精彩的访谈。感谢今天观看本次访谈的所有观众，也感谢提问的观众们。最后，非常感谢李倩老师的分享和讨论，谢谢大家！

4月18日，我们将继续讨论该主题，欢迎大家预约观看。