平台工程的兴起

平台工程并不是第一次尝试解决构建和运行软件的普遍困难，而且我几乎可以肯定它不会是最后一次。敏捷、DevOps、站点可靠性工程和数字化转型都以崇高的承诺和不同的结果出现。软件解决方案催生了新问题，其中许多急切的供应商通过提供无限地产生新问题的解决方案来解决这些问题。平台工程试图驯服无休止的创新、采用、碎片化和停滞的循环，这是不知疲倦的进步所需要的。 

为什么我不能DIY？
您需要工具来支持开发工作并保持工程师的生产力。期望应用程序开发团队运行所有东西是不切实际的。因此，您组装了一组 3rd 方服务和开源系统，并添加了其他非开发人员以保持系统运行。无论您构建什么样的应用程序，您都在平台之上编写它们。 

您需要一个起点来构建您的软件。您可以采用数据库、消息队列、容器编排、操作系统和各种开发人员工具等框架和工具来设置应用程序运行的“堆栈”或环境。特殊情况和个人偏好破坏了统一性，有利于提高生产力的碎片化。在易于理解和维护的简单、单一的方法与让每个团队做任何他们想做的事情的最大灵活性之间存在微妙的平衡。

开发运维
划分构建和维护软件系统的任务的简单二分法是划分开发和运营。Dev 为客户构建新特性和功能，Ops 确保它们在发布后正确运行。 

DevOps 试图通过采用“如果你构建它，你运行它”的世界观来消除这种分裂。该理论认为，通过将运营所有权交给创建错误的人（开发人员），自然激励将迫使组织计算技术债务并立即构建更好的软件。 

实践中的挑战在于，DevOps 已成为位于 Dev 和 Ops 之间的第三个孤岛，负责处理双方都不想（或不能）做的事情。尽管理论认为“ DevOps 工程师”一开始就不应该存在，但这个角色已经激增。它已成为处理设置 CICD 系统、将基础架构配置为代码、为新应用程序配置云环境以及疯狂地尝试跟上来自各个方面的不断变化的人们的简写。

现场可靠性工程
SRE 的概念在理论上听起来不错，并且在适当规模和类型的组织中非常有效。当您达到足够的规模和复杂性时，确保可靠性本身就是一项努力。这个角色经常处理重复的操作任务，并通过采用或构建新的交付和生产力工具和流程来识别和消除随着时间的推移而产生的“辛劳”，从而使公司的整体系统随着时间的推移更具竞争力。 

在实践中，许多组织在实现 SRE 的承诺时遇到了挫折。有时只是简单地重新命名运营团队而不改变技能组合或实施可以减少工作量的项目——在其他情况下，给 SRE 团队改变任何事情的余地太小，让他们对崇高的理想大喊大叫而没有贯彻到底。费用增加（因为更高的技能和分配预防能力的成本高达 4 倍），而且投资回报充其量仍然值得怀疑。 

数字化转型
对于试图在日益网络化的世界中站稳脚跟的老企业来说，这也许是一个崇高的目标，数字化转型的概念听起来就像将旧的家庭视频转换为 MPEG 文件或扫描纸质合同并转向 DocuSign。管理顾问乐于领导这些昂贵、缓慢且痛苦的项目，将组织拖入云计算时代。代价高昂的数据泄露增加了一些暂时的动力，与全球系统集成商的多年协议也是如此。但当然，数字化转型的最大驱动力是 COVID-19，它最终 迫使每个人都想办法使用 QR 码点餐。

平台来了
“平台”这个词被重载了，几乎可以意味着任何东西。在大多数“平台工程”团队中谈论“平台”时，让我们尝试更准确地了解人们的意思。 

首先，平台意味着您可以在其上进行构建。就其本身而言，该平台处于惰性状态，随时可以使用。除非组织可以将平台用于多种目的，否则它只是产品的一部分。该平台为应用程序、工作负载、租户、运营商、开发人员和客户（间接）提供服务。 

大多数软件架构现在都遵循“服务”导向这一事实意味着平台必须为服务而存在。所以我们可以说一个平台为在它之上构建的其他团队提供服务。

每当我们试图确定“平台”的正确定义时，我们就会开始听起来像是营销废话。你可以说我们谈论的是“计算平台”、“数字基础设施平台”，甚至是“云平台”。我们正在谈论的平台包含一些既模糊又具体的东西（而且绝对不是技术性的）：构成该平台的人员、流程、工具、文档、知识、升级路径、供应商合同、SLA、期望、计划和成本结构对组织的持续关注。

我建议进行以下测试以确定我们是否在谈论平台：

平台提供有价值的服务
平台符合可重用接口。
平台需要工作负载才有价值。
平台间接支持最终用户。
平台提高了生产力。
平台得到资助和维护。
平台为可靠性、安全性和性能设定了标准。
平台使做一些事情变得容易，而做其他事情则更具挑战性（有意或无意）。
平台必须谨慎更改以避免连锁反应。
平台可能包括手动任务、票证、运行手册和知识。
平台（无论是否称为）通常包括的事物类型：

基础计算、网络和存储。
用于处理定制或随机请求的票务系统。
身份、身份验证和授权服务。
准备清单
安全扫描
监控、可观察性和报告。 
服务水平协议
各种数据库
消息队列
灾难恢复和故障转移
邮件服务器（这有多方便？）
Kubernetes
如果您的公司没有平台团队，您还没有确定平台。也许您希望供应商让这一切都为您服务。或者数字化转型顾问集成了这些系统，因此他们可以无缝地工作以降低风险并产生出色的投资回报率。 

值得注意的是，平台工程师已经站出来加强并取得所有权。他们试图将这个包含记录不充分的工具、服务、开源项目、优雅的 hack、TODO 和技术债务的抓包变成类似于产品的东西。目标不是深奥的（“生产力”或“可靠性”），而是实用的（“让我们构建一个人们想要使用的东西”）。 

平台即产品
将公司内部的平台视为您正在“推向市场”的产品。您想构建您的组织想要使用的东西，因此他们将游说管理层以确保您的持续资源和存在。所以你需要去行动所在的地方；具有重要关键任务的大型团队，您可以帮助他们更快地行动、更少失败并高效运行。您必须了解（内部）客户的优先事项、痛点、建立规模经济的机会以及可持续的商业模式。您需要使平台易于采用，同时还要考虑当前情况的现实限制。

将产品思维方式应用于您的平台会产生与采用 DevOps、SRE、数字化转型或敏捷完全不同的结果。你现在有了一个人们想要使用的东西（一个平台！），它可以减轻他们的负担并让他们专注。他们不必担心 The Cloud 提供的所有旋钮和开关；他们有一个受平台约束和决定通知的受限菜单。当然，没有人会为了这个平台而使用它；团队必须赢得信任和服务这些客户的权利，否则他们将承担工作量并回家。

所有权心态
我不知道它为什么或来自哪里，但所有权有效。它可能深入人类心理学，也可能是分层管理结构的产物。在现实世界中，当您尝试进行重大努力时，您需要知道谁在做什么，并相信他们会继续这样做并且（老实说）留在他们的车道上。否则，整个组织就会分崩离析。一旦没人知道组织结构图，政治、指责、冷漠和磨练简历很快就会出现。 

Google 的 SRE 并不拥有可靠性，他们大多将自己视为内部可靠性顾问（当他们不回答可怕的寻呼机时）。Google SRE 试图帮助产品团队在设计系统时做出正确的选择。它们有助于设置服务水平目标 (SLO)，以确保明确定义可靠性目标。也许最重要的是，他们推动团队始终如一地采用来自整个 Google 技术基础架构（我们可以将其描述为平台）的标准服务。SRE 是平台即产品的客户成功团队。 

（脚注：Google Cloud Platform 拥有一支客户可靠性工程师 (CRE) 团队，其行为类似于云的客户成功团队，并提供有关有效采用 GCP 以充分利用它的技术指导。）