Infrastructure, ops, devops, systems engineering, sysadmin, infraops, SRE, platform engineering。对于我这样从事计算机相关工作的人，这些术语实际上是相似的。但假如我想向其他人讲明白我的工作内容时，这些术语会让人一头雾水。

每一家科技公司都有一个软件工程团队来构建软件，还有一个运维团队来构建运行该软件的基础设施。在过去十年的某个时候，他们会将这个运维团队更名为devops或SRE，但不管名字是什么，那就是我的团队。

但除非你是基础设施公司，否则基础设施就不是你的核心任务: 这意味着投入基础设施工作的每一秒钟以及致力于基础设施问题的每位工程师，都会使你偏离核心的工作目标。而且，这种干扰是源自本身。因为(在基础设施上)花费的时间和精力越多，分散的精力就越多，就失去了本应该用于解决业务问题的时间和精力。

众所周知，从基础设施和运维到核心的业务问题其实是有一段距离。在过去几乎每家公司都必须首先在硬件、数据中心、网络、操作系统、配置管理等方面提升内部专业技能，才到解决核心的业务问题。基础设施和它的运维一直以来都是让人分心但又必须投入的事情，但是直到最近，有了新的方法来满足我们的需求。

有什么变化呢？现在我们有了更多的选择权。当然，你可以像过去一样自己构建内部的基础设施，但现在我们更多的是通过API的方式(从云厂商那里)获取基础设施。

这是否意味着运维不再重要。不再需要？这一天还差的远 ! 运维和可运维性比以往任何时候都重要。让我们从较高的角度看待运维行业的发展、新兴挑战以及这一切都会对我们的职业产生影响。

一、拥抱变化

除了广泛使用云服务，我们还看到这些变化:

1.从单体架构到微服务

已经有很多文章讲述微服务架构下的运维需求: 现在函数之间的调用都涉及到网络的传输，所以哪怕是最简单的问题调试都不能绕过运维。微服务将游戏规则从写代码变成做系统，这就推动大家写越来越多运维相关的代码。

2.从监控到可观测性

诸如Prometheus和DataDog之类基于指标的工具是相当不错的基础设施监视工具。当你负责基础设施的时候，你需要关心指标的聚合、趋势、阈值以及容量。监控工具可以正确的满足需求，因为这是你感知基础设施是否健康以及如何变健康的方式。

另一方面，可观察性工具运用在我们每天编写和交付的代码，它试图检查和理解用户、产品和代码之间的联系。 可观察性工具还保留了请求完整的上下文，这方便我们细化和梳理问题的相关性，还可以按时间查看事件（即tracing）。 可观察性就是如何将软件与业务实际的影响，以及工程师与用户体验之间的点点滴滴联系起来。

注意: 现在很多监控工具在自身缺少核心功能的情况下声称自己是可观测工具。二者之间是有本质区别，详见这篇文章

3.从魔幻的自动埋点到有目的的埋点

指标埋点是注释和记录代码的另一种形式。有些工具可以保证自动为你完成指标埋点，但它们并不能感知开发者的目的。自动化监控埋点也许可以告诉你大量的辅助细节，但它们永远不会预测到写这段代码的工程师想要的业务价值。所以还是好好给代码做监控埋点吧!

二、运维已死，运维万岁

(原模式下的)运维团队正走在渡渡鸟之路(译者注: 渡渡鸟是一种著名的已灭绝动物)，但是可运维性、弹性伸缩和可靠性却从未如此重要。 运维工程师的角色正在快速变化，并在基础设施问题上分离。 在未来，传统的“运维工程师”（或devop工程师）将分成2种角色:一种聚焦于基础设施软件即服务的构建，一种是使用基础设施专业知识来帮助工程师团队更有效地交付软件……通常是通过构建尽可能少的基础设施来实现。

如果你是真心喜欢解决基础设施问题，那你是非常幸运! — 比以往任何时候都幸运。加入基础设施公司，比如AWS、Azure，以及其他开发者工具公司 — 这些公司的任务就包括构建基础设施软件，成为世界上最好的基础设施软件并将该专业技能出售给其他公司。这里有大量喜欢构建基础设施即服务解决方案的软件工程师，还有专门的运维人员角色来大规模地运维这些基础设施，以及大规模地管理数据服务。

否则，请接受这样一个事实：你原本的工作是构建基础设施系统来让工程师团队发布能够创造核心业务价值的软件，而在未来要尽可能少地自建这类基础设施，那你还有什么价值？

1、服务供应管理工程(Vendor engineering)

有效地将基础设施组件外包给供应商，并将它们编排成一个无缝的整体。这需要大量的系统架构和领域专业知识，这种技能是非常罕见的，而且被严重低估，尤其当要考虑通用性时。 想一想。，如果你在一家大公司工作，与其他内部团队打交道像与外部供应商打交道。 而如果你在小型公司工作，与其他供应商打交道就像与其他团队打交道。

如果想要在SRE领导层中拥有长期而充满活力的职业生涯，可以将精力投入到以下领域：

• 学习有效评估供应商及其产品。 多问些尖锐而探索性的问题来评估是否兼容和合适。 确定哪些问题是可以容忍，哪些是不能接受。
• 学习计算和量化时间和人力成本。 为了聚焦于核心业务，要尽力减少(基础设施相关的)人力成本。
• 学习管理真正的成本，并在内部倡导和教育正确的解决方案，特别是与高层和财务人员打交道的时候

2、产品工程(Product engineering)

基础设施的一大悲剧是: 我们大多数人是如何彻底地避开了过去20多年来学习到的产品管理和如何与设计师合作的经验教训。大多数基础设施工具都需要无休止的人员培训和认证，它们根本不像现代人类的产品。

• 我推荐一种速成班。把你自己投入到B2B或B2C功能交付团队中一段时间。学习他们的节奏，学习他们的语言，吸收他们的一些能力。你需要他们来平衡和融合你对架构正确性评估、扩缩容和灭火的能力。
• 你不必成为发布特性方面的专家。但是你应该像一个优秀的产品经理那样学习构建关系的要素。你必须对产品生命周期有足够的了解，这样你就可以帮助调试和扭转那些路线图毫无希望地交织在一起并且其路线图正在逐渐停止的团队。

3、社会技术系统工程(Sociotechnical systems engineering )

SRE/devops技能集中最核心的部分就是围绕着制定高效、有效的社会技术反馈循环来进行，从而使工程师能够有信心地快速发布代码。你的工作不是说“不”或是设置路障，而是想办法帮助他们实现“是”。

• 从拥抱发布开始。努力学习部署流水线(pipeline)。最安全的差异就是最小的差异，应该自动且强制性地发布。优化测试，CI / CD等，以便当合并到主分支时能自动进行部署，从而一次merge触发一次部署，无人干预，并且一切都在开发人员提交代码后的几分钟内自动生效。这是你的必杀器，大多数团队都达不到的水准。
• 设计和优化on-call机制，以公平、可持续地平衡工作量，不会使人筋疲力尽。在管理上施加适当的压力，以投入足够的时间进行可靠性和修复工作，而不仅仅是发布新功能。告警要有反馈机制，以便使收到警报的人员有能力有动力去解决它们。理想情况下，你应该每次都呼叫到能进行变更的人。
• 在整个组织内传播无罪论的同时，培养主人翁精神和责任心。欢迎(开发)工程师进入生产环境，并帮助他们愉快地、成功地在生产环境的水域自由航行。

4、技术投入的管理(Managing the portfolio of technical investments)

• 可运维性是最长期的技术投入，也是技术债最主要的来源，而运维工程师又是最能帮助评估和解决这些风险的人。与运行代码多年花费的大量资源相比，编写代码的投入实际上不值一提。
• 擅长迁移。不要支持任何遗留下的、落后的、陈旧的系统-这些都是团队的巨大负担。 将这种资源消耗暴露给决策者(来投入资源升级改造)，而不是让它悄悄溃烂。
• 少造不必要的轮子。(造之前)问问自己,“此工具的维护计划是什么？”
• 宣导和影响力。 (向领导)游说可运维性至上， 在职级晋升文档上做改进。 除非他们编写并支持可运维的服务，否则不应晋升为高级工程师。

这个世界瞬息万变，而且变化正在加速。 运维现在是每个人的工作，而许多工程师不知道这意味着什么，但已经吸收了挥之不去的恐怖文化。 我们需要纠正错误的观念。 我们必须找到奖励尝试而不是惩罚探索的方法。

作者 Charity Majors是Honeycomb的CTO，前Facebook product engineering经理. 原文链接:https://acloudguru.com/blog/engineering/the-future-of-ops-jobs?fbclid=IwAR1J9IPSdZNkPHSUeb-2522vG1nQi2GMF_6DYw8cir_0nxhqcyZwdTM5FqQ

参考阅读: 《Site Reliability Engineering》