点击上方蓝字 
关注大侠之运维
后台回复99.99% 获取运维干货物
大家好，这里是大侠之运维，每天分享各类干货。
翻译自：charity.wtf/2022/09/30/the-future-of-ops-is-platform-engineering
如下内容是国外一位大佬对于运维、devops、SRE、平台的观点。
原文如下：
两年前,我在The New Stack上撰写了一篇关于运维职业未来的文章。接近尾声时,我写道:
事实是,通用的系统基础设施工作正在慢慢消失:这个世界不再需要成千上万精通postfix、SpamAssassin和ClamAV调优的人——这个世界已经有Gmail了......
构建基础设施和运营专业知识曾经统一地打包到一个角色中。但这个行业现在正在基础设施断层线上分化,基础设施导向的工程师和运营导向的工程师的重叠正在迅速消失。喜欢这项工作的工程师越来越有必要做出选择。你可以选择1)通过加入一家以基础设施即服务为业的公司,在基础设施上走的更深入;或者2)通过加入一家公司,帮助他们尽可能少地搭建基础设施,在运营方面走的更广泛。
我将第二类描述为“不含基础设施的运维”,致力于评估和组装第三方平台提供商的生产技术栈,使软件工程师能够自助服务并在生产中拥有自己的代码。我说过:
你的工作是通过找到有效的方式来外包或最小化基础设施劳动,来积极最小化你的组织在基础设施上投入的周期。如果有任何可行的替代方案,你就不要深入研究。
你的工作是与所有其他软件工程团队进行跨职能合作,寻找方法来加速他们的时间到价值,并帮助他们在生产中拥有自己的代码。
你的工作是要摆脱古老的“外包”模型,转向更精细的对如何利用抽象以及在何处利用抽象的理解,这可以极大地加速开发。
我描述的第二类现在有了一个名称。我们称这些团队为“平台工程”。
软件职业的五十年历程
起初,有编写和运行软件的人。在某个时候,我们从开发技能中剥离出运维技能,形成了两个不同的职业,但这被证明是一个巨大的错误,所以DevOps出现了,将它们重新统一。如今,随着运维团队被解散,运维作为一个独立的职业正在逐渐消失。以前被称为系统管理员或运维的工程师已经转型成为DevOps工程师,不久之后就会再次只有“软件人”。事情就是这样发展的。
请注意,这与说“运维已经死了”或者“运维技能不再有价值或不再需要”是完全不同的1。我们的系统只会变得越来越复杂,操作难度越来越大,与此同时,对地球生活而言也越来越关键,这意味着运营卓越从未如此迫切地需要过(如果你不尊重这一点,你就注定要遭受痛苦)。
过去三到五年,这个行业的主要故事是我们正在努力找到方法来帮助软件工程师在生产中拥有他们自己的代码2,逐步淘汰专门的运维团队,并尽可能多地外包基础设施。
我们也应该这样做。开发人员的周期是你公司最稀缺的资源,你应该尽可能地把这些周期花在你的核心产品上:皇冠上的明珠,使你成为企业的代码。相比工程周期,金钱更便宜,专注于核心业务的团队总会优于注意力分散在几十个非收入项目上的团队。让其他人来建立和运行所有依赖项和配套设施。
过去:一些工程师编写代码,一些工程师运行代码。
现在:所有工程师编写代码,所有工程师运行他们编写的代码。
平台工程正是你与黑暗之间的隔离
当你开始谈论让软件工程师对自己的代码负责,并普遍更多地参与生产时,你会听到一定百分比的绝望哀嚎:“你不能指望我对一切了如指掌!”
的确;我们不能。平台工程团队就是这个完全合理的抱怨的部分答案。并不是你被要求全部都要做更多事情,但是劳动力和责任的分配正在发生转变:
过去:一些工程师编写代码,一些工程师运行代码。
现在:所有工程师编写代码,所有工程师运行他们编写的代码——但是我们根据层或功能划分责任领域。
最低可行的自助服务层的出现
在一个公司最初的日子里,头几名工程师最终会通过阅读AWS文档或博客文章,或向朋友寻求建议来启动基础设施,比如开始设置托管的容器服务或配置Terraform,一段时间里每个人都会部署和拥有自己的代码,正如上帝所设计的那样。
但是认知限制很快就会展现出来。那里的API、SDK和组件迷宫简直令人不知所措,即使对于有经验的运维人员来说也是如此。不久之后,做出好的决策,选择一套满足团队需求的计算和存储选项,并编写一些将所有内容整合成一个连贯的整体的工具——这就成了某人的工作,至少要让你能够:
- 运行测试并生成新工件
- 部署工件、版本化并回滚
- 检测、监控和调试
- 将数据存储在某处,管理schema和迁移
- 根据需要调整容量
- 将所有组件及其关系定义并提交为代码
一旦这些都建立起来,任何工程师都可以使用模板和现有服务的组件轻松启动新服务。使用预置的路径应该比任何其他路径都简单容易得多,如果偏离预置路径则应该会遇到阻力。
恭喜你!你刚刚被平台化了🎉。任何开发者平台的关键原则之一是,做正确的事情应该很容易,做错误的事情应该很困难。
平台工程与传统运维的区别
平台团队通常由善于编写软件的工程师组成。不仅仅是编写脚本和自动化,而且还要编写测试和进行代码审查。平台团队在操作上也更像产品开发团队,有产品经理(有时还有设计师、开发者倡导者或UX研究人员)。
这并不意味着平台团队中的每个人都必须原本就是软件工程师;事实上,平台团队的一个非常常见的失败状态就是认为他们只需要雇佣软件工程师来构建开发者工具。一个强大的平台团队在运维经验和软件开发方面都有同样深厚的积淀。在这两个领域都是专家的人才相对较少,但是你可以通过组装混合了一些运维经验的软件工程师和一些软件开发经验的运维或DevOps工程师的团队,让他们互相学习和成长,从而组建一个强大的全面团队。
平台团队决定致力于云原生;他们实际上主要涉及构建在云之上的平台自身——PaaS、IaaS、全部即服务、无服务器等。
运维/DevOps团队以管理基础设施为导向,通常会管理几代不同的基础设施。他们的地盘从数据中心和裸机一直延伸到虚拟化、容器和云(他们不是云原生的,而是云启用的)。他们用SLO和DORA指标来衡量自己。如果系统正常运行且用户满意,就可以说他们正在做好工作。
平台团队以为开发者提供自助服务和自我管理代码的良好体验为导向。开发者能够更迅速、更轻松地推进,你的平台团队就越好。在平台模式中,运营卓越实际上更多是其他工程团队(和/或相邻的SRE团队)的责任,而不是平台团队的责任。
与运维、DevOps或SRE团队相比,平台团队通常在更高的技术栈中工作,极少涉及基础设施。相反,平台团队致力于支付其他人来运行尽可能多的基础设施,以保留自己稀缺的开发周期用于他们的核心产品。
下面是这些角色之间相似与不同之处的较为谑剧化的表格。
平台工程师 vs. DevOps 工程师
DevOps 与 SRE 的区别
关于 DevOps 与 SRE 的区别已经有无数文字进行了阐述,我不会在此重复3。
我要说的是:对我来说,DevOps感觉适合有大量基础设施要管理的公司。那些确实有开发团队和运维团队的公司,或者有开发团队和 DevOps 团队(呕)的公司,往往有大量运维自动化、测试和运行的工作要做。他们使用配置管理、虚拟化和容器,通常需要管理几代不同的技术,有可能甚至需要管理数据中心和裸机。DevOps适用于拥有一些裸机、VM、区域、可用区、多云、网络设备、自管理数据库等组合的公司。
DevOps包含非常广泛的内容。它囊括了多种多样的东西。DevOps编写代码,并且有大量代码要管理。
它也正在走向变得不再相关。我们正在迅速进入后DevOps时代。
相比之下,对我来说,SRE感觉不同。我将SRE与非常大的公司联系起来,在那里他们大多由软件工程师来运行自己的代码,但可能在这个方面仍有点困难。SRE通常嵌入在软件工程团队或产品组中,他们非常关注可靠性,顾名思义。
这意味着他们进行的基础设施操作或自动化更少(虽然他们仍在做一些编码)。他们通常对检测、监控和可观察性有很多建议,并专注于跨职能协调。他们运行事件响应和无责障碍回顾,并且通常是扩展专家。
如果一个公司同时有DevOps团队和SRE团队,我通常期望看到SRE团队更在前线,参与事件、遥测等,而DevOps团队则更在后台,铺设管道和管线。
可观察性工程作为案例研究
在我之前引用的同一篇文章中,我还写道可观察性团队在很大程度上不应该在内部运行自己的监控和图形化软件。但是,可观察性团队仍有其存在的意义:它们仍然是外包解决方案与内部开发人员需求之间的关键纽带。
该团队应该编写库、生成示例并推动标准化;引入一致性、可预测性和可用性。他们应该与内部团队合作评估用例。他们应该与供应商合作作为路线图的关键影响者。他们也可能编写粘合代码和助手模块以连接不同的数据源并创建内聚的可视化。基本上,该团队成为你组织与外包工作之间的一个集成点。
我最初是针对可观察性编写这些,但它同样适用于整个平台工程。这个角色就是作为其他供应商和你自己的核心软件之间的桥梁。这是一个非常高杠杆的位置。
运维的未来究竟是怎样的？
我花了很多时间思考这个问题,因为我们很难明确地确定Honeycomb的客户是谁。有时我们的买家是为他们的软件工程师购买的运维团队,有时是处在停机中的SRE,有时是工程副总裁或总监,或架构师,或CTO,或“全栈”工程团队,甚至可能是产品经理。从这个列表中拼凑出一个简洁的答案是很困难的。
每个新上市人员询问我们的前两个问题都是“你的买家是谁?”和“我们如何帮助他们?”对此我的回答是一个五分钟的喋喋不休,列出每一个上述人员及其痛点。这远非他们想要的确切答案。
end
大侠之运维，相识便是缘
收集不易,点赞、留言、分享就是大侠🦸♀️写下去的动力!
👆点击查看更多内容👆
推荐阅读
记得星标记一下，下次更容易找到我
PS：因为公众号平台更改了推送规则，如果不想错过内容，记得读完点一下“在看”，加个“星标”，这样每次新文章推送才会第一时间出现在你的订阅列表里。点“在看”支持我们吧!
