开发人员与 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。通过这种形式，他们能够改善现有服务并增强将来的新零碎。
参考链接：
- https://mp.weixin.qq.com/s/4yvvRIL1uo5uTtIRUwxU5w
- https://circleci.com/blog/platform-engineering-devops-at-scale/