认知负担的挑战与平台工程的机遇

偏执的太偏执、 2024-03-17 16:18 142阅读 0赞

开发人员与 DevOps 不断增加的认知负担被认为是软件工程中最大的问题之一。随着越来越多的工具、框架和方法可以选择，以及“You build it, you run it”的 DevOps 思想的发展，我们可以看到为了提供面向客户的产品和服务，认知负担也随之大幅增加。

在今天的文章中，我们将初步了解认知负担的基本概念，一起探讨对于开发人员与 DevOps 工程师来说，他们的认知负担来自哪里，平台工程将如何减轻认知负担并改进相应工作流程。

### 了解认知负担 ###

通常来说人在任何给定时间内可以处理的复杂性是有限的，同时存在于我们脑海里的想法数量也是有限的，通常是在三到七个之间。而一些不必要但又不得不处理的信息或分散手头任务的注意力也增加了我们所处理的复杂性。复杂性还来自于我们整合想法及概念以帮助理解的过程。这些都构成了我们在尝试执行任务时所需要承受的认知负担。在心理学中，每种类型的负担都有对应的名称：

*  **内部认知负担**\-由于任务内在难度而产生的负担
 *  **外部认知负担**\-处理分散注意力或不必要的元素产生的负担
 *  **附加认知负担**\-由于建立对任务的理解而产生的负担

随着对任务的熟悉程度越来越高，当我们开始整合理解并建立一个关于任务的更高阶心智模型，内部认知负担将随之减少。例如，当我们第一次尝试驾驶时可能感到力不从心，即使在路况良好的情况下我们也需要高度集中，这时驾驶给新手司机产生的内部认知负担是极高的。随着对车况更加熟悉且驾驶技术有所提高，开车这项任务所带来的认知负担逐渐减少。当然，我们的驾驶技能依然会受到外部认知负担影响，比如在开车时手机突然响了等因素。

### 开发人员的认知负担 ###

开发人员往往喜欢谈论架构、抽象和实施细节方面的事情。架构通常是整体想法或创意，也就是系统如何在宏观层面上组合在一起。抽象则是概括，也就是如何在架构中重用代码或组件。实施细节就是如何实现抽象的具体版本。

这种层次结构允许开发者们在忽略各种细节的情况下仍然能够理解他们正在工作的系统。通常来说，参与软件开发项目的每个人都应该熟悉总体体系结构。在实际情况中，如果开发人员需要了解软件系统的所有细节可能不是啥好事，比如软件中某个地方有 bug 或者更糟心的，架构某处存在缺陷。

开发现代软件是一项高度复杂、涉及多职能及高度协作的过程。例如，专注于构建 web 端相应式 UI 的开发人员可能不一定知道如何配置为应用程序提供服务的 K8s 集群。理想情况下，该开发人员会专注于构建 UI 并保持较低的外部认知负担，而配置 K8s 机群会分散对核心任务的注意力。对于该开发人员来说，K8s 是一个隐藏在抽象层下的实施细节，与构建 UI 并没有直接关联。**所以当每个人可以专注于自己的专业领域时，开发团队的价值就能发挥的最大**。团队中的每个人都可以忽略与手头任务不相关的事情时，相应的外部认知负担就会很低。

### DevOps 的认知负担 ###

尽管 DevOps 旨在提高软件开发效率，但 DevOps 工程师经常面临大量艰巨的任务，这些任务增加了他们的认知工作量。让我们来看一些常见的例子。

首先，**DevOps 工程师经常需要为新的软件项目设计新的流程**，例如持续集成和持续交付（CI/CD）流程。DevOps 工程师可能还需要启动开发环境的基础设施，同时确保与生产环境的兼容性。这涉及管理 Docker 文件、Helm 图表和 Terraform 代码，随着项目的发展，这些文件需要定期维护和支持。CI/CD 管道也需要构建，尽管工程师可以从以前的项目中获取某些部分，但新项目的新测试或构建要求会增加额外的复杂性。

现有流程必须扩大或缩小以满足当前需求。这些流程包括扩展基础设施以满足新的处理或存储要求，以及修改为不断壮大的小型工程师团队设计的现有工作流程。

**DevOps 工程师还管理软件工程生命周期许多方面的所有权**。这包括在内部代码库和基础设施之上管理第三方工具和产品。其他开发人员还需要进行代码审查和会议来讨论需要专业 DevOps 知识的潜在解决方案选项。此外，DevOps 工程师必须确保系统正确记录日志，并且可以收集和分析指标。掌握不同软件应用程序的性能对于确保它们顺利运行至关重要。它还可以帮助工程师了解需要扩展的潜在领域。

除了满足服务级别协议 (SLA) 和其他内部业务目标之外，所有这些都给 DevOps 从业者带来了巨大的认知压力。每个任务和流程都会产生 DevOps 从业者必须处理的额外开销，通常会从他们的创新和优化的主要目标中消除资源。

随着认知负担的增加，相关的复杂性和压力也会增加，导致倦怠、错误的增加。这会显著降低团队生产力，并最终抑制创新。

### 平台工程有效划分复杂性 ###

平台工程的存在就是为了提供多职能团队共同处理同一软件项目所需的抽象。平台将软件运行在实施细节上的基础架构提供给开发人员，而在此基础架构上运行的软件也能同时成为运营团队的实施细节。**平台工程有效减少了日常工作的认知负荷，开发人员在平台中可以以自助服务的方式使用资源**，消除了由于必须处理的流程（例如工单系统）而导致的额外认知负荷。

**平台工程的核心之一就是有效划分复杂性**。企业组织中每个团队都有自己的职能领域，该团队中的成员擅长处理该领域中的复杂问题，于此同时其他人可以安全地忽略这些领域。每个人都根据共同的抽象和对信息组合在一起的理解来处理实施细节。

举个例子，对于开发团队和运营团队来说，架构是一个共享协议，整个系统需要运行才能使客户满意。这两个团队都使用抽象：容器是在各种系统上运行的单元，数据库等资源可用于根据需要存储数据。而实施细节根据职责有所区分，对于运营团队的成员来说，实施细节包括网络、集群中的 Pod 策略和管理数据库实例。开发人员对实施细节就是要解决的业务问题。在整个项目中，**平台工程是每个人实现其实施细节而进行沟通的途径和方式**。

### 将平台工程纳入开发与 DevOps 中 ###

在这一部分，我们将结合一个用例来说明平台工程如何降低 DevOps 和开发人员的认知负担并改进工作流程。

想象一下一家企业设计的 Web 应用程序都遵循类似的架构模式。有一个数据库、一个 API 和一个基于 Web 的前端，有预构建的 Docker 镜像和 CI/CD 模板。但是这一切都是手动完成的。DevOps 工程师必须为每个项目创建 Docker 文件、实施 Terraform 脚本并构建 Git 管道。然后，他们将与开发人员合作，确保环境满足他们的需求，并向生产基础设施添加监控和警报。这些任务与响应现有基础设施的 SLA 和执行定期维护一起发生。

这给 DevOps 工程师带来了巨大的压力。主要问题是无论复杂程度是怎样，所有任务都直接交给 DevOps 团队。因此，工作堆栈最终会延长希望推进项目的开发人员的交付时间。这时平台工程师可以通过将其构建到内部开发者平台（IDP）中来自动化这些工作。例如，开发人员可以从 IDP 请求存储库，然后由 IDP 进行创建，而不是手动设置 Git 存储库。然后，IDP 将分配正确的用户组并自动集成正确的 CI/CD 模板。同样的模式适用于创建开发环境和部署核心基础设施。IDP 充当开发人员请求服务和应用配置的自助服务平台，了解默认内置的安全最佳实践和监控。IDP 还可以在项目跟踪软件和文档模板中自动设置项目。

可见，**平台工程师通过将一套标准化模式构建成自助式内部开发平台来增强工作流程**。这样以来消除了项目初始化的负担，团队也可以立即开始提供业务价值，而不用花费项目设置的前几周时间来解决初期问题。同时，由于开发人员将更加自主，平台工程师可以专注于解决更大的架构挑战并将其反馈给 IDP。通过这种方式，他们可以改善现有服务并加强未来的新系统。