我们生活在一个被软件吞噬的世界，而在软件建设领域，几乎每年都会掀起一波浪潮。今年，平台工程似乎成了“新贵”。在Gartner10月份发布的2023年十大战略技术趋势中，平台工程位列其中。其目的是为负责构建产品和服务的开发团队提供服务。共同共享服务，让开发更专注于开发，让运维更专注于运维。平台工程并不是解决构建和运行软件的普遍挑战的第一次尝试，而且几乎肯定不会是最后一次。之前有敏捷、DevOps、站点可靠性工程(SRE)和数字化转型，目标雄心勃勃，结果喜忧参半。软件解决方案带来了新问题，而热切的供应商通过提供带来新问题的解决方案来解决许多问题。平台工程试图驾驭创新、采用、碎片化和停滞的永无止境的循环，以满足持续改进的需要。1、为什么开发不能DIY？需要工具来支持开发项目，同时保持工程师的工作效率。期望应用程序开发团队来运行一切是不现实的。于是，很多企业团队选择组装一套第三方服务和开源系统，加入其他非开发人员来维持系统运行。无论您构建什么应用程序，都将它们编写在同一个平台上。构建软件需要一个起点。您可以使用数据库、消息队列、容器编排、操作系统和各种开发人员工具等框架和工具来构建您的应用程序运行的“堆栈”或环境。但例外和偏好会破坏团结并导致分裂。因此，需要在可维护性和灵活性之间保持微妙的平衡，让每个团队在保持简单易懂的整体环境的同时发挥最大的作用。2.DevOps将构建和维护软件系统的任务划分为开发(Dev)和运营(Ops)之间的简单二分法。开发为客户构建新的特性和功能，运营确保它们在发布后正常工作。DevOps试图通过采用“谁构建，谁运营”的理念来消除这种划分。这个想法是，通过将运营所有权赋予带来软件错误的人（开发人员），自然激励迫使组织首先面对技术债务并构建更好的软件。实际挑战在于DevOps已经成为Dev和Ops之间的第三个筒仓，处理双方都不想做或不能做的事情。尽管人们认为“DevOps工程师”从一开始就不应该存在，但这个角色很快就流行起来。它指的是那些负责构建持续集成/持续交付(CI/CD)系统、将基础架构配置为代码、为新应用程序配置云环境并努力跟上开发或运维不断变化的人员。3.站点可靠性工程SRE概念在理论上听起来不错，并且在适当规模和类型的组织中运作良好。在足够的规模和复杂性下，确保可靠性本身就成为一个挑战。这个角色通常处理重复性的操作任务，并通过采用或构建新的交付和生产力工具和流程来不断识别和消除“脏工作”，从而使公司的整体系统逐渐更具竞争力。事实上，许多组织在实现SRE的承诺时都经历过挫折。有时只是重命名运营团队而不改变技能组合或实施可以减少脏工作的项目；或者给SRE团队做出改变的余地太小。费用增加（因为更高的技能和预防能力的分配成本是原来的四倍），而且投资回报率大多值得怀疑。4.数字化转型对于试图在日益网络化的环境中站稳脚跟的老牌企业来说，数字化转型的概念可能是一个宏伟的目标，听起来像是将旧的家庭视频转换为MPEG文件，或者扫描纸质合同，切换到DocuSign。管理顾问喜欢领导这些将组织带入云计算时代的昂贵、缓慢、痛苦的项目。代价高昂的数据泄露增加了暂时的动力，与全球系统集成商的多年交易也是如此。然而，数字化转型最大的外部驱动力是疫情，最终迫使大家想方设法使用二维码点餐。5.平台即将到来“平台”这个词几乎可以指代任何东西。首先，平台意味着可以在其上构建产品。该平台随时可用。除非组织可以将平台用于多种目的，否则它只是产品的一部分。平台为应用程序、工作负载、租户、运营商、开发人员和客户（间接）提供服务。现在大多数软件架构都是面向“服务”的，这也意味着平台必须为服务而存在。平台可以说是为其他在其之上构建产品的团队提供服务。每当我们试图确定“平台”的确切定义时，它开始听起来像是一种营销噱头。我们可能会谈论“计算平台”、“数字基础设施平台”，甚至“云平台”。我们谈论的是关于平台的一些模糊和具体的东西：人员、流程、工具、文档、知识、升级路径、供应商合同、SLA、期望、时间表和成本结构，使组织专注于平台。我建议进行以下测试以确定我们是否在谈论平台：平台提供有价值的服务平台符合可重用接口平台要求工作负载有价值平台间接支持最终用户平台提高生产力平台得到资助和维护平台可靠、安全且安全性能设定标准平台使一些事情更容易，其他事情更难（有意或无意）必须谨慎更改平台以避免连锁反应平台可能包括手动任务、工单、运行手册和知识平台通常包括几类组件作为基本计算、网络和存储处理自定义或随机请求票务系统身份、身份验证和授权服务就绪检查表安全扫描监控、可观察性和报告SLA各种数据库恢复和故障转移邮件服务器（这有多方便？）Kubernetes如果哟你的公司没有平台团队，你还没有平台意识。也许您希望供应商为您做所有事情，或者希望数字化转型顾问集成这些系统，以便它们无缝工作以降低风险并获得高投资回报。值得注意的是，平台工程师挺身而出。他们试图将文档不足的工具、服务、开源项目、巧妙的更改、积压工作和技术债务变成类似产品的东西。目标不是空想的（“生产力”或“可靠性”）而是务实的（“让我们构建人们想要使用的东西”）。6.平台就是产品你公司内的平台就像你推向市场的产品。您想要构建您的组织想要使用的东西，因此用户游说管理层以保持资源运转。因此，您需要专注于承担重大任务的大型团队，您可以帮助他们更快地行动、减少失败并高效运行。您必须了解内部客户的优先事项、痛点、建立规模经济的机会和可持续的商业模式。您需要使平台易于采用，同时还要考虑当前情况的实际限制。为平台采用产品理念可能会产生与采用DevOps、SRE、数字化转型或敏捷截然不同的结果。现在人们想要使用一些东西：一个可以减轻他们肩上负担并让他们集中精力的平台。他们不必担心云提供的所有细节，他们有一个基于平台的限制和决策的受限菜单。当然，没有人会纯粹为了自己而使用一个平台；团队必须赢得客户的信任和支持，否则他们只是把工作量带回家。7、所有权的思想所有权可能植根于人类心理，也可能是等级管理结构的产物。在现实世界中，当您尝试运行一个大型项目时，关键在于了解谁在做什么并相信他们会继续这样做。否则，整个组织就会分崩离析。一旦没有人知道组织结构图，纠纷、责备、冷漠和跳槽很快就会接踵而至。Google的SRE不负责可靠性，他们大多将自己视为内部可靠性顾问。GoogleSRE试图帮助产品团队在设计系统时做出正确的选择。他们帮助设置服务级别目标(SLO)以确保明确定义可靠性目标。也许最重要的是，他们推动团队始终如一地采用来自Google技术基础设施（您可以称之为平台）的标准服务。SRE是平台即产品的客户成功团队。8.下一步是什么？平台工程的趋势越来越大。LinkedIn和Twitter越来越多地在它们的标题中添加“平台”。CEO将平台工程师视为重要客户。当我试图更好地了解当前形势时，我询问了我所有的SRE朋友他们对平台工程的看法。大家会怀疑这是新瓶装旧酒，营销噱头而已。不止一个SRE跟我说“其实我们是一个平台团队，不是SRE团队”。我认识的以前从事性能工程、安全和数据管理工作的朋友和同事都已过渡到平台工程。我最喜欢平台工程的地方是所有权，而我最不喜欢平台工程的地方是它在定义上的模糊性，比如对平台是什么不是平台缺乏明确性。我认为DevOps已死，SRE已死。DevOps工程师的工作仍然需要完成，即使是换了个名字。想象一下，您公司的一个平台团队齐心协力解决其他产品、应用程序和IT团队面临的共同问题的结果。平台不是更快的船，而是涨潮。原文链接：https://dzone.com/articles/the-rising-tide-of-platform-engineering
