导读
原文：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以及组件纷繁复杂，即使是经验丰富的运维人员也会感到困惑不已。不久之后，就需要有人来做出明智决策，挑选出一套满足团队需求的计算与存储方案，并编写一些工具将所有元素整合成一个连贯的整体。
这套工具至少应能实现以下功能：
运行测试并生成新构件（artifacts）
部署构件，进行版本控制，并能够回滚
仪表化、监控及调试
在某处存储数据，管理架构和迁移
根据需要调整容量
将所有组件及其关系以代码形式定义并提交
任何开发者平台的关键原则之一就是：正确的事情应当容易做，错误的事情则应当难以做。
平台工程师和传统运维的区别
平台团队需要成员有能力写软件，而不只是脚本和自动化程序。平台团队有着和产品团队一样的运作形式产品经理（也有可能有设计师、开发倡导者或用户体验研究员）。
但是，这并不意味着平台团队只需要召集软件工程师去搭建开发工具就够了，一个强大的平台团队需要同时具用深入的开发和运营经验。显然平台团队是基于云原生的
| 平台工程师 | 运维工程师 | |
|---|---|---|
| 花在代码上的时间 | >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 表示服务器资源的随取随弃 |