平台工程中认知负荷的挑战

在最近的一篇文章中，Syntasso 首席运营官Paula Kennedy分享了她对开发团队所承受的不断增加的认知负荷的看法。她解释说，平台工程方式试图减轻开发团队的一些认知负荷，但这可能是以将认知负荷转移给平台团队为代价的。

认知负荷理论（CLT）由 John Sweller 于 1988 年首次提出，它认为人类的认知是工作记忆和长期记忆的结合。工作记忆的容量有限，由负责引导注意力和协调认知过程的多个组成部分组成。另一方面，长期记忆具有无限的存储容量，可以根据需要与工作记忆一起检索信息。

CLT 最初被设计为一种改善课堂教学的手段，但也有应用于软件开发。Sweller 确定了三种类型的认知负荷：内在的、外在的和增生的。内在认知负荷是与手头任务相关的努力。在数学课上，这可能是 2+2 或尝试化简一个多项式方程。用教学术语来说，这通常被认为是不可变的。

外在认知负荷产生于强加给执行任务的个人的任务本身及任务之外的要求。它可能包括分散注意力的信息、糟糕的指令或以不理想的方式传达的信息。例如，口头向某人提供配置负载平衡器的步骤，而不是以书面文档的形式提供。

正如 Psychologist World 的一篇文章所述，增生认知负荷是：

通过构建模式生成，被认为是可取的，因为它有助于学习新技能和其他信息。

在认知科学中，模式是一种先入为主观念的心理构造，就像是一个代表世界各方面的框架。虽然内在认知负荷被认为是不可变的，但我们希望最小化外在认知负荷，并尽量最大化增生认知负荷。

对平台工程中开发人员体验的关注是对负责整个产品开发生命周期的团队所承受的沉重认知负荷的一种回应。Puppet 的区域首席技术官Nigel Kersten解释说，实施完全自主 DevOps 团队的组织，尤其是大型企业，可能会对局部进行优化，但会以牺牲其他团队为代价：

这可以很好地为特定的价值流团队或应用程序进行局部优化。但它并不是针对整个组织进行优化，而是为审计人员、IT 资产管理人员以及所有围绕成本控制和安全的治理问题创造了认知负荷。你如何从一个团队切换到另一个团队？所有这些都会变得非常非常复杂。

随着对开发团队需求的增加，我们开始触及可处理信息量的极限。沉重的认知负荷会对有效完成任务的能力产生负面影响。Kennedy 指出：

对于任何试图驾驭复杂技术环境的人来说，这是一场持续的斗争。每天都会有新工具发布，跟上新功能、评估工具、为工作选择合适的工具，更不用说理解这些工具如何相互交互以及它们如何适用于你的技术堆栈，这都是一项艰巨的任务。

这些活动与分配给业务流（stream-aligned）团队的关键任务无关，因此会干扰实现业务基本优先级的快速流动。对于业务流开发团队来说，交付业务价值是团队应该花费大量时间和精力的任务。对于大多数公司来说，像更新新的 CI/CD 工具或最新的安全威胁之类的任务对其所销售的产品来说并不是直接至关重要的。

MYOB 架构主管Evan Bottcher将平台描述为：

数字平台是自助服务 API、工具、服务、知识和支持的基础，它们被分配为一个引人注目的内部产品。自主交付团队可以利用该平台以更快的速度交付产品功能，同时减少协作。

这就是为什么开发人员的经验对于一个设计良好的平台来说是如此重要的原因。一个引入了额外外部认知负荷的平台，或者不是一个促进健康增生认知负载的模式，实际上会增加使用它的开发人员的认知负荷。一个不以最终用户为中心、不欣赏用户体验的平台将无法成功地改善它们的交付。

正如 Amenitiz 的高级工程师Cristóbal García García和 Thoughtworks 的技术主管Chris Ford所言：

你永远不要忘记，你正在开发的产品是为了取悦它们的客户——你的产品开发团队。任何阻碍开发人员顺利使用你的平台的因素，无论是 API 可用性方面的缺陷还是文档方面的差距，都会威胁到平台商业价值的成功实现。

从认知负荷理论的角度看，愉悦感成为了一种限定平台为开发团队及其在完成任务的工作中所带来的认知负担的方式。正如 Kennedy 所描述的那样，平台团队的主要关注点是“提供‘开发人员愉悦”，同时避免技术膨胀，避免陷入构建不满足开发人员需求且未被采用的平台的陷阱。”

她接着指出了铺砌路径（也称为黄金路径）的重要性：

通过向开发人员提供黄金路径，平台团队可以鼓励他们使用业务首选的服务和工具。这有助于简化提供的工具数量，减少过多选项的认知负荷，并减少平台的技术膨胀。

应用认知负荷理论，铺砌路径是一种增加增生认知负荷的方法，它为开发团队提供了一种模式，以更好地理解他们所处的问题空间。

在最近的一条推文中，《团队拓扑》的合著者Matthew Skelton回应了这种观点以及遵循良好模式所能带来的价值：如果“平台工程”中最重要的部分是维护一个高质量的 wiki，它具有经过验证的共情模式，以供业务流团队遵循，那该怎么办？在教育学领域，有大量的研究表明，提供实际的例子有助于提高学习。正如 Dan Williams所指出的那样，这些步骤为学习者提供了指导和支持，帮助他们创建如何解决问题/任务或“好”的心理模型。另一方面，发现或基于问题的学习会给工作记忆带来负担，因为学习者没有足够的先验知识来支持他们的学习。

铺砌路径和经过验证的模式有助于为开发团队提供从包含合规性和治理等领域的整体问题空间中获得良好的外观。由于大多数开发工作都是模仿基于问题的学习，因此开发团队的认知负荷已经非常高了。铺砌路径，以及相关的平台工具，可以简化问题空间，减少外在认知负荷。

Kennedy 确实担心，在给团队分配建立这个平台的任务时，我们不仅仅是均匀地分散认知负荷，而是把它推给了平台团队。她注意到这些团队已经开始负责提供开发人员体验了，但由于需要整合许多工具，以及合规性和治理等其他问题，他们面临着巨大的认知负荷。这通常是一个投资不足的团队，但他们还要负责提供支持客户价值交付的平台。

Kennedy 想知道，除了当前对开发人员体验的关注之外，我们是否还应该讨论并改善平台工程师的体验。

InfoQ 与 Kennedy 进行了坐谈，更详细地讨论了这篇文章。

InfoQ：通过将负担转移到平台工程师身上，你表明我们实际上是把认知负荷往下推，而不是把它均匀地分摊出去。这感觉就像是我们在试图解决应用程序工程师当前的困境时，引入了一个新的问题。你建议我们如何确保平台团队不会超载呢？

Paula Kennedy：在过去几年中，有很多关于如何改善开发人员体验或“DevEx”的讨论和关注，以使开发人员更容易交付并减轻他们的认知负荷。不幸的是，这种认知负荷并没有消失，而且通常只是转移给其他人来管理了，比如平台工程师。

 

为了帮助减轻这一负荷，我很乐意看到有人谈论平台团队体验以及我们如何改进它。无论平台团队是管理云提供商、运行现成的 PaaS，还是在 Kubernetes 之上构建了自己的平台，我认为我们都需要为这些平台团队提供更多的资源和工具，以使它们能更容易地规划支持其组织的平台。随着对平台工程主题的讨论越来越多，我很高兴看到出现了帮助解决这一挑战的模式和工具。

InfoQ：你注意到，平台团队“负责提供支持客户价值交付的平台”，但通常投资不足。你认为这是为什么？平台团队可以做些什么来纠正这一问题？

Kennedy：根据我的经验，平台工程通常是有机发展，而不是刻意组建的平台团队，我们至少在三个方面看出这一点。

 

首先，当组织接受 DevOps 文化并使团队能够自主地将其软件交付到生产中时，这些 DevOps 团队最终会在无需任何额外资源的情况下管理平台级的关注点。

 

其次，一些组织认为任何内部平台都是基础设施团队的责任，被视为另一个需要最小化的基础设施成本。

 

最后，我看到一些组织引入了一个由供应商支持的平台即服务，希望它能够解决所有的内部平台挑战，并且只需要最少的维护，因为一切都“开箱即用”的——但事实并非如此。

 

在所有这些情况下，都没有理解管理内部平台所需的技能和资源，从而导致投资不足。

 

值得庆幸的是，我们看到越来越多分享平台工程和平台团队可以带来的好处的资源和经验。《团队拓扑》是一本我经常推荐的书，因为它提供了一个词汇表来描述如何通过明确的团队职责和减少团队之间的摩擦来实现价值在整个组织中的流动，并最终流入客户手中。

 

在《团队拓扑》中，作者主张拥有一个支持多个业务流团队的平台团队，这些团队应该协作来理解彼此的需求并建立同理心，同时推动 X-As-a-Service 模式，在这个模型中，平台团队确保业务流团队能够自助提供所需的工具和服务。随着越来越多关于平台团队为软件交付生命周期所带来的价值示例被公开分享，公司开始认识到投资于该团队的重要性，以确保他们拥有正确的技能和工具来支持更广泛的组织。

 

平台团队还可以采取措施在内部展示其价值，方法是通过考虑对其组织非常重要的指标或关键绩效指标（KPI），以及他们的工作是如何有助于改进这些指标的。这可能看起来像是运行价值流映射练习，确定哪里存在浪费或重复，并演示平台团队如何提供集中服务来改善这一点。

 

如果合规性是一个组织的关键问题，那么平台团队可以推动与合规团队和应用程序团队之间的密切合作，通过内置的合规步骤来创建无摩擦的生产路径，确保更快、更合规地交付软件。内部指标或 KPI 在很大程度上与具体环境密切相关，但通过旨在度量对业务重要的内容，平台团队可以随着时间的推移证明其价值及其所做的改进。

InfoQ：你提到 DevOps 在试图纠正因 Dev 和 Ops 分离而产生的问题时，导致开发人员背负了更多的认知负荷。平台工程范式正试图通过将部分负荷转移到一个自助平台上来解决这一问题，该平台可以处理将代码投入生产并处理支持代码的大部分负荷。我们是否正面临着重新引入 DevOps 试图打破的孤岛风险呢？

Kennedy：“DevOps”这个术语对不同的人来说有着不同的含义，尽管这个术语已经出现了十多年，但它仍然经常引起混淆。就我个人而言，我喜欢引用 Patrick Debois 在 2010 年的定义：

 

Devops 运动是周围着这样一群人建立的，他们相信适当的技术和态度的结合应用可以彻底改变软件开发和交付的世界。

 

DevOps 运动的核心绝对是减少孤岛，增加团队之间的沟通和同理心，以及提高自动化，并努力实现持续交付。对我来说，拥有一个内部平台团队只是 DevOps 的自然演进，尤其是规模上的 DevOps。

 

平台团队的成员负责他们的内部平台产品，他们既需要开发该平台以满足其用户（应用程序团队）的需求，也需要日常运维这个平台。

 

对于专注于向最终客户提供功能的软件开发人员，他们负责开发其软件，并使用平台团队支持的自助服务工具进行操作。在这个模型中，每个人都在做“DevOps”，即每个人都在开发和运维自己的软件。但要想真正发挥作用，避免出现更多的孤岛，还需要考虑一个重要的文化因素，这就是平台团队将其平台视为产品的思维方式转变。

 

在过去的几年里，我曾多次谈到这一问题，但这取决于平台团队在组织中的演变，这可能会带来巨大的挑战。当将内部平台视为产品时，这包括理解用户需求（应用程序团队）、分批交付以寻求反馈、提供高质量的用户体验以取悦开发人员、内部营销和平台宣传等等。只要平台团队接受这种思维方式，我们就能看到显著的好处，如 Puppet 2021DevOps 状态报告（Puppet State of DevOps Report 2021）等行业研究所证明的那样：“并不是每个平台团队都会自动获得成功，但成功的团队会将它们的平台视为一种产品。”

原文链接：

https://www.infoq.com/articles/cognitive-load-platform-engineering/

相关阅读：

DevOps 已死，平台工程才是未来

滴滴工程效能平台建设之路