我们生活在被软件吞噬的世界，而在软件构建领域，几乎每年就会出现一波浪潮。今年，平台工程仿佛成为了一个“新贵”，Gartner 10月发布的2023年十大战略技术趋势中，平台工程就位列其中，它的目的在于为负责构建产品和服务的开发团队提供所依赖的通用共享服务，从而让开发更聚焦于开发，运维聚焦于运维。平台工程不是第一次尝试解决构建和运行软件方面的普遍难题，也几乎肯定不会是最后一次。之前就有敏捷、DevOps、站点可靠性工程（SRE）和数字化转型，目标宏伟，但结果好坏不一。软件解决方案带来了新问题，许多问题由急切的供应商通过提供带来新问题的解决方案来解决。平台工程试图驾驭创新、采用、碎片化和停滞这个无休止的循环，从而满足不断进步的需求。
支持开发项目需要工具，同时保持工程师的高效工作。期望应用程序开发团队运行所有东西不切实际。因此，很多企业团队选择组装一套第三方服务和开源系统，并添加了其他非开发人员以保持系统运行。无论构建什么样的应用程序，都在一个平台上编写它们。需要一个起点来构建软件。你可以采用数据库、消息队列、容器编排、操作系统和各种开发者工具等框架和工具来搭建应用程序运行的“堆栈”或环境。但特例和偏好会破坏统一性，导致碎片化。因此需要在易维护性和灵活性之间保持微妙的平衡，从而在保持简单易懂的整体环境的同时又能让每个团队发挥所长。
划分构建和维护软件系统方面任务的简单二分法是分为开发（Dev）和运营（Ops）。开发为客户构建新的特性和功能，运营确保它们在发布后正确运行。DevOps试图奉行“谁构建，谁运维”的理念，从而消除这种分裂。这种理念认为，通过将运营所有权交给带来软件错误的人（开发者），自然激励会迫使组织正视技术债务，一开始就构建更好的软件。实践上的挑战在于，DevOps已成为介于Dev和Ops之间的第三个孤岛，处理双方都不想做或不能做的事情。尽管有观点认为“DevOps工程师”一开始就不该存在，但这个角色还是迅速流行起来。它指代这类人：处理搭建持续集成/持续交付（CI/CD）系统、将基础架构配置为代码、为新应用程序配置云环境以及竭力跟上Dev和Ops任何一方面不断出现的变化。
SRE概念理论上听起来不错，在适当规模和类型的组织中非常有效。达到足够的规模和复杂性后，确保可靠性本身就成了一项挑战。这个角色常常处理重复的操作任务，并通过采用或构建新的交付和生产力工具和流程来不断识别和消除“脏活”，从而使公司的整体系统逐渐更具竞争力。实际上，许多组织在实现SRE的承诺时遇到了挫折。有时只是重新命名运营团队，而不改变技能组合或实施可以减少脏活的项目；或者给SRE团队进行改变的余地太小。费用上升（因为更高技能和分配预防性容量的成本高达四倍），而且投资回报多半值得怀疑。
对于试图在日益网络化的环境下站稳脚跟的老企业来说，数字化转型概念可能是个宏伟的目标，听起来就像将旧的家庭视频转换成MPEG文件，或扫描纸质合同、改用DocuSign。管理顾问乐于领导这些昂贵、缓慢又痛苦的项目，将组织带入云计算时代。代价高昂的数据泄露增添了暂时的动力，与全球系统集成商签署的多年协议也是如此。不过，数字化转型的最大外在驱动力是疫情，这最终迫使每个人都想方设法使用二维码来点菜。
“平台”这个词几乎意味着任何东西。首先，平台意味着可以在其上面构建产品。平台随时可供使用。除非组织可以将平台用于多种用途，否则它只是产品的一部分。平台为应用程序、工作负载、租户、运营商、开发者和客户（间接）提供服务。大多数软件架构现在以“服务”为导向，这也意味着平台必须为服务而存在。可以说平台为在它上面构建产品的其他团队提供服务。每当我们试图确定“平台”的确切定义时，会开始听起来像是营销噱头。我们可能谈论“计算平台”、“数字基础设施平台”，甚至是“云平台”。我们谈论的平台涵盖一些既模糊又具体的东西：人员、流程、工具、文档、知识、升级路径、供应商合同、SLA、期望、计划和成本结构，这些使组织持续关注平台。- 平台使得做一些事情变得容易，做其他事情更困难（有意或无意）
如果你的公司没有一个平台团队，那么你们就还没有平台意识。也许你期望供应商为你做一切工作，或者数字化转型顾问集成这些系统，以便无缝地运行，以降低风险、获得很高的投资回报。值得注意的是，平台工程师已挺身而出。他们试图将文档编写糟糕的工具、服务、开源项目、巧妙的改动、待办列表和技术债务变成类似产品的东西。目标不是虚幻的（“生产力”或“可靠性”），而是务实的（“不妨构建人们想要使用的产品”）。
贵公司内部的平台好比推向市场的产品。你想构建贵组织想要使用的东西，因此用户会游说管理层，以确保资源持续不断。所以你需要关注负责重大任务的大型团队，你可以帮助他们加快行动、减少失败并高效运行。你必须了解内部客户的优先事项、痛点、建立规模经济的机会以及可持续的商业模式。你需要使平台易于采用，同时还考虑当前情况的实际限制。平台采用产品理念可带来与采用 DevOps、SRE、数字化转型或敏捷全然不同的结果。现在有了人们想要使用的东西：平台，它可以减轻他们的负担，并让他们专心致志。他们不必担心云提供的所有细节，他们有一个基于平台的限制和决定的受限菜单。当然，没有人会纯粹为了平台而使用平台；团队必须赢得客户的信任和认可，否则他们只能将工作量带回家。
所有权可能根植于人类心理学，也可能是层次化管理结构的产物。在现实世界中，当你尝试运作重大项目时，就要知道谁在做什么，并相信他们会继续做下去。否则，整个组织会分崩离析。一旦没人知道组织结构图，纷争、指责、冷漠和跳槽很快接踵而来。谷歌的SRE并不负责可靠性，他们大多将自己视为内部可靠性顾问。谷歌SRE试图帮助产品团队在设计系统时做出正确的选择。他们帮助设定服务水平目标（SLO），以确保可靠性目标已明确定义。也许最重要的是，他们推动团队一贯采用来自整个谷歌技术基础架构（可以称之为平台）的标准服务。SRE是平台即产品的客户成功团队。
平台工程潮流越来越盛。LinkedIn和Twitter上将“平台”添加到头衔中的人越来越多。CEO们将平台工程师视为主要客户。当我试图更好地了解当下的形势时，我问了所有的SRE朋友他们对平台工程有何看法。每个人都会怀疑这是新瓶装旧酒，只是营销噱头。不止一个SRE告诉我“实际上，我们是平台团队，而不是SRE团队。”我认识的以前在性能工程、安全和数据管理方面工作的朋友和同事都已经向平台工程转型。我最喜欢平台工程的是所有权，最不喜欢的是平台工程在定义方面的模糊性，诸如在“平台是什么、不是什么”方面缺乏明确性。我对DevOps穷途末路和SRE一败涂地的说法持保留态度。DevOps工程师的工作仍然需要完成，即使换了新名字。想象一下平台团队在你的公司聚在一起，接管其他产品、应用程序和IT团队面临的常见问题，结果会如何。原文链接：
https://dzone.com/articles/the-rising-tide-of-platform-engineering
直播简介：数字化时代，商业环境与职场环境都发生了巨变，很多岗位将会被取代。对此，技术从业者该如何应对？职业高地在哪里？如何设计个人发展规划？【T·TALK】特别邀请三位数字化转型领域专家，就数字化转型对技术从业者个人职业发展的影响进行深入探讨。
点击视频号卡片，立即预约直播
关注公众号：拾黑（shiheibook）了解更多
[广告]赞助链接：
四季很好，只要有你，文娱排行榜：https://www.yaopaiming.com/
让资讯触达的更精准有趣：https://www.0xu.cn/
51CTO技术栈
关注网络尖刀微信公众号
