运营的未来是平台工程师

导读

原文：The Future of Ops is Platform Engineering
作者：Charity
地址：https://charity.wtf/2022/09/30/the-future-of-ops-is-platform-engineering/
本文为部分翻译，总结，内容用作学习交流

软件工程师的五十年

一开始，人们将开发与运营职能分开。而今天，工程师们慢慢转别为DevOps，在可预想的不久之后"软件人"这个概念会代替开发与运营。
注意，这并不等于说运营将消失，在系统变得越来哦复杂的今天，运营技能比过去任何时候都更加值得重视。
在过去3到5年，公司将运营工作尽可能的外包出去，尽可能将预算花在赚钱的代码上，专注于核心业务的团队总是会胜过那些精力分散在几十个非创收项目上的团队。让其他人来构建和管理所有依赖项和相关项目。
过去: 一些工程师写代码，另一些运行代码
现在: 所有工程师都负责写和运行

平台工程师站在你和未知之间

当你要求软件工程师深入参与到代码在生产环境的部署时，总会有些人抱怨：“你不能要求我知道一切”。
平台工程师就是为此而生的，并不要求每位工程师在总体上承担更多工作或理解更多内容，而是在于劳动分工和责任分配方式发生了变化。
过去: 一些工程师写代码，另一些运行代码
现在: 所有工程师都负责写和运行，但我们将责任领域按照层次或功能进行划分。

最小有效服务层的出现

在团队初创之时最初的几位工程师通常会通过阅读文档，博客文章，或者向他人请教来搭建基础设施。
然而，市面上各种API、SDK以及组件纷繁复杂，即使是经验丰富的运维人员也会感到困惑不已。不久之后，就需要有人来做出明智决策，挑选出一套满足团队需求的计算与存储方案，并编写一些工具将所有元素整合成一个连贯的整体。
这套工具至少应能实现以下功能：

1. 运行测试并生成新构件（artifacts）
2. 部署构件，进行版本控制，并能够回滚
3. 仪表视图化、监控及调试
4. 在某处存储数据，管理架构和迁移
5. 根据需要调整容量
6. 将所有组件及其关系以代码形式定义并提交
   任何开发者平台的关键原则之一就是：正确的事情应当容易做，错误的事情则应当难以做。

平台工程师和传统运维的区别

平台团队需要成员有能力写软件，而不只是脚本和自动化程序。平台团队有着和产品团队一样的运作形式产品经理（也有可能有设计师、开发倡导者或用户体验研究员）。
但是，这并不意味着平台团队只需要召集软件工程师去搭建开发工具就够了，一个强大的平台团队需要同时具用深入的开发和运营经验。平台团队是基于云原生的，它们主要涉及构建在云本身之上的平台——paas、IaaS、一切——aas、serverless等等概念。
Ops/DevOps团队以管理基础设施为主要工作内容。他们的领域从数据中心，裸金服务器到虚拟化、容器和云。他们根据SLOs（Service Level Objectives）和DORA（ (DevOps Research and Assessment) 标准来度量自己。如果系统启动/可用并且用户满意，您就知道他们做得很好。
平台团队的目标是为开发人员提供良好的体验。开发者越快、越容易的管理他们的代码，你的平台团队就越好。在平台模型中，卓越运营实际上更多地是其他工程团队(和/或相邻的SRE(站点可靠性工程)团队)的责任，而不是平台团队的责任。平台团队涉及的基础设施较少。他们倾向于尽可能多地外包运维工作，以节省自己宝贵的开发资源专注于核心产品。

平台工程师和运维工程师的区别

	平台工程师	运维工程师
花在代码上的时间	>50%	<50%
其他时间工作	收集产品需求 做用户调查，架构讨论，优化网络工作流 研究新工具，优化工具 分析团队需求差异 帮助不同的工程师扩展，部署代码 修复CI/CD流水线	修复定时任务 自动化文档上的一些工作 将PXE/rsync转换为Chef/Puppet 将Chef/Puppet转换为Terraform 将vm转换为容器 部署，调试软件，构建新服务 编写监控检查 回溯分析 帮助软件工程师调试他们的代码 检查系统中的可疑文件
工作职责	是团队能够在生产环境中掌控，运行代码 创建标准可复用的组件和流程	基础设施容量规划、扩展、性能调优、升级。 可靠性和弹性、SLOs和监视/警报。 为客户提供优质的体验。
需求方	网络开发组织	客户
部署风格	基础设施作为一种产品	基础设施作为代码
是否与产品经理合作	是	否
是否与用户体验设计师合作	有时	否
图形化工作界面	使用APM、可观察性、跟踪。 非常关心设施和应用性能监控。	使用metrics、日志和仪表板; 监视、警报和代理/侧车/黑匣子监控。
代码工作内容	写测试，服务，功能代码 和软件工程师一样	自动化、配置、DSLs、扩展和调试现有代码。 一些系统工作。
编程语言	Go Rust	Python Ruby
评价标准	开发人员可以很容易使用服务搭建基础设施 并在生产环境中掌控自己的代码。	基础设施是可伸缩的、安全的、经济高效的、可靠的 让并且客户满意。
领域	Serverless IaaS,Paas 开发的接口	实例，虚拟机，容器 regions multi-cloud (多云)
SSH	否	是
Shell	REPL	bash/zsh
箴言	Run Less Software 系统中的程序要少而必要	Cattle, Not Pets 表示服务器资源的随取随弃

谈谈SRE（站点可靠性工程师）

DevOps对于那些拥有大量基础设施需要管理的公司来说，是一个颇具现实意义的概念。这类公司往往设有开发团队与运维团队，或是开发团队与DevOps团队（🙄）。它们面临着大量的运营工作需要自动化、测试和运行，如配置管理、虚拟化、容器化等，往往要管理几代技术栈，甚至可能涉及到数据中心和裸金服务器。DevOps适用于那些拥有诸如裸金服务器、虚拟机、地域、可用区、多云环境、网络设备、自管数据库等多种组合的企业。
DevOps包容万象，包罗众多。DevOps编写代码，同时也管理着海量代码。
然而，DevOps正逐渐变得过时。我们正迅速步入一个后DevOps时代。
相比之下，SRE（Site Reliability Engineering，站点可靠性工程）给我一种不同的感觉。我认为SRE与那些规模庞大的公司紧密相关，这些公司通常让软件工程师对其在生产环境中的代码拥有所有权，但可能在实际操作中仍面临一些挑战。SRE团队通常嵌入在软件工程团队或产品组中，正如其名所示，他们的工作重点在于系统的可靠性。
这意味着他们较少从事基础设施的操作或自动化工作（尽管仍需编写一些代码），而是更多地关注于仪表化、监控、可观测性，以及跨部门协作。他们负责应急响应，开展无责回顾，且往往是规模化运营的专家。
若一家公司同时拥有DevOps团队和SRE团队，通常情况下，我会预期SRE团队更多地活跃在前线，参与处理事件、维护遥测数据等，而DevOps团队则更偏向后台，专注于管道和基础架构层面的工作。

运维已死，运维万岁

我花了很多时间思考这个问题，因为我们一直难以精准界定Honeycomb的客户群体究竟是谁。有时我们的买家是运维团队，为他们的软件工程师购买产品；有时是身处故障中的SRE（站点可靠性工程师）；有时是工程部副总裁或总监、架构师、CTO，甚至是全栈工程师团队，甚至产品经理。要把这些人统统纳入一个简洁的答案之中，实属不易。
每一位新的市场拓展候选人在接触我们时，问出的前几个问题通常是：“你们的买家是谁？”以及“我们如何帮助他们？”对此，我的回答往往是一段长达五分钟的絮叨，列举出上述所有角色及其各自痛点。显然，这并非他们期待的那种明确答案。
社会技术趋势潮起潮落。一年前，克里斯汀和我猜测，平台工程或许即将整合构成我们理想买家所需的诸多要素：

1. 编写并部署代码，需要理解自己的代码
2. 能够帮助其他团队制定监控工具和策略
3. 坚定地采用云原生技术，不受硬件或传统基础设施束缚