很多人问我了解SRE的职位。这是一个很大的话题。让我介绍一下在这个博客中想到的一些事情。

SRE 到底是什么？这是由.首先提出的概念。我的理解是软件是用来解决运维问题的。标准化、自动化、可扩展性、高可用性是主要工作内容。这个职位提出的时候，它想要解决的问题就是打破​​想要快速迭代的开发人员和想要保持稳定、拒绝频繁更新的运维人员之间的矛盾。

SRE 目前仍然面临招聘困难。一方面，这个职位需要一定的经验，而应届毕业生一般没有复杂软件的操作和维护经验；另一方面，很多人仍然认为这是一个“运维”工程师，认为他们所做的事情是低水平的、重复的。工作，我对这份工作很排斥。最根本的是，这个职位实际上要找的要么是有运维经验的开发人员，要么是有软件开发技能的运维工程师。所以找到合适的人就更难了。

现实生活中，不同公司的SRE职位差异很大，有的甚至可能有与传统运维名称不同的职位名称。

例如，蚂蚁金服有两个SRE。一个负责稳定性，也就是大家理解的SRE；另一种称为资金安全SRE，不负责服务的正常运行，但负责资金数额正确、对账无错误。 ，工作内容主要是开发，主要是资金验证平台和验证规则（我没做过，只是个人理解）。从某种意义上来说，它不再是SRE，而是专业领域的开发。

[1] (2016) 模式由 WHO 开发和维护。 SRE负责提供技术支持和咨询服务。服务遍及全球170个国家，核心SRE只有5人。

微软有专门的游戏SRE[2]，负责Xbox网络游戏的稳定性。

因此，不同公司的SRE内容侧重点不同，取决于公司想要提供什么样的服务。

我们可以学习网络分层方法，将SRE的一般工作内容从下到上分为三大类：

：主要负责最基本的硬件设施和网络，类似IaaS，请参考

：提供中间件技术和一些开箱即用的服务，类似于PaaS，可以参考GCP、AWS等。

业务SRE：维护服务、应用，维护业务的正常运行

和SRE其实都是可有可无的。近年来，商业化服务越来越多。例如，如果一家公司选择将自己的所有服务部署在AWS上，那么它就不需要构建和维护自己的网络。只需要几位 AWS 专家即可。

如果有的话，工作内容可大可小。您可以从管理购买的 VPS 开始，也可以从购买硬件服务器开始。

我觉得SRE的工作内容可以这样定义：

负责服务器采购、预算和 CMDB 管理。你需要知道（可以查）每个站的负责人是谁，他们在做什么。这非常重要。如果做得不好，就会造成资源的巨大浪费。

提供可靠的软件部署环境，通常是虚拟机或裸机。

统一维护操作系统的版本、Linux发行版的版本、.

维护机器上的基础软件，如NTP、监控代理等代理。

提供机器登录方式、权限管理、命令审计。

维护一套可观察性基础设施，如监控系统、日志系统、跟踪系统等。

为了维护网络，大公司可能会在机房设计自己的网络。这些包括：

网络连接是必要的。对于上层用户（SRE）来说，下发的服务应该是任意两个IP都可以ping通，即三层以下的网络要管理好。

网络地址转换服务

域名解析服务

防火墙

4层负载均衡、7层负载均衡

CDN

证书管理

每个项目可以是一个大型团队，也可以只有一个人来提供商业基础设施服务。您可以使用开源产品或开发自己的产品。

SRE

SRE 维护基础设施。 SRE利用他们提供的基础设施来构建软件服务，允许公司内部的开发人员使用开箱即用的软件服务，例如Queue、Cache、计划任务、RPC服务等。

主要工作内容包括：

RPC服务：允许不同的服务互相发现和调用

私有云服务

队列服务，例如 Kafka 或

分布式服务

缓存

网关服务：反向代理的配置

对象存储：s3

其他一些数据库：ES、mongo等。一般来说关系型数据库会由DBA来运维，但是NoSQL或者图数据库一般都是由SRE来维护。

内部开发环境：

自建单片机系统等

持续集成/持续交付系统

镜像系统，例如

其他一些开发工具，比如分布式编译、错误管理等。

一些离线计算环境和大数据服务

业务SRE

在SRE的支持下，开发者在编写代码时基本上不需要担心部署问题。您可以专注于开发并使用公司的开箱即用服务。这一层的SRE更贴近业务，知道业务是如何运行的，请求是如何处理的，依赖于哪些组件。如果 X 存在问题，可能的降级策略是什么？参与应用架构设计并提供技术支持。

主要工作内容包括：

参与系统的设计。比如熔断、降级、扩容等策略。

进行压力测试以了解系统的容量。

进行容量规划。

在业务方面。

对于一个专业的SRE来说，上述技能不应该有明确的界限。比如业务SRE也需要掌握一些网络技能，基础设施SRE也需要写一些代码。有很多工具是每个岗位上的每个人都可以在某种程度上使用的，比如 // 这种 IT 自动化工具，或者 / 这种监控工具。只有了解了，才能正确使用。换个角度来说，对于业务SRE来说，虽然它基本上不管理四层以下的网络，但是如果遇到网络问题，可以利用现有的工具和权限来排查交换机问题，然后去Infra SRE寻求帮助：“请帮帮我”检查xx IP与交换机之间是否有异常，因为xxx显示的结果是xx。”是不是比“我怀疑xx网络有问题，请帮忙排除故障”更好？

以上是大致的工作职责划分。这种分层其实没有什么意义，但是可以让读者了解SRE涉及到什么样的工作。

下面是一些日常工作内容。

部署服务

部署分为两种：

Day 1：服务部署上线之日

Day 2+：服务部署后，会有很多更新、升级、配置变更、服务迁移等。

Day 2+的工作需要做很多次，而Day 1做的很少。经过不断的迭代升级，很难保证Day 1的可靠运行。也就是说，我们在服务部署之后不断地改变它，我们还需要保证服务能够可靠地部署在新的环境中。部署环境的硬编码和奇怪的工作会破坏Day 1的可靠性。对于以前的公司来说，扩建新机房的过程是一场噩梦。太多奇怪的配置，导致在新机房部署所有服务之前遇到了无数的陷阱。

Day2+的操作也不简单，主要注重稳定性。对于重要的变更操作，需要设计变更计划，如何进行灰度测试，出现问题如何回滚，如何保证回滚能够成功（如何测试回滚）等。

理想情况下，部署的操作应该是可跟踪的，因为并非所有导致问题的操作都会立即导致问题。例如，一个操作完成没有任何问题，但一个月后，意外重启或内存达到某个指标触发了问题。如果可以记录操作，我们可以回顾之前的更改，方便定位问题。 Git 现在通常用于跟踪部署过程中的更改（[3]）。

简单来说，就是保证网上服务的正常运行。典型的工作流程是：接收报警、检查报警原因、确认在线服务是否存在问题、定位问题、解决问题。

收到警报并不一定意味着确实存在问题，也有可能是警报设置不合理。报警和监控面板不是静态配置。它应该每天都在变化，并且一直在调整。如果您发现发出的警报并不代表线上存在真正的问题，则应修改警报规则。如果发现当前监控无法快速定位问题，则应调整监控面板，添加或删除监控指标。业务在发展，请求量在变化，某些阈值需要不断调整。

定位问题没有一刀切的方法。你需要根据实时看到的情况，结合自己的经验做出假设，然后使用工具验证你的假设，进而确定问题的根本原因。

但可以有一种解决问题的方法，称为SOP，标准操作程序[4]。即：如果出现这种现象，则执行该操作来恢复业务。应提前制定SOP文件并验证其有效性。

需要说明的是，上述定位问题和解决问题之间不存在先后关系。一个常见的错误是，当发生故障时，需要很长时间才能定位故障的根本原因，然后进行修复。这通常需要更长的时间。正确的做法是首先根据现象检查现有的SOP能否恢复业务。例如，如果当前错误只发生在某个节点上，那么就会直接将该节点下线，稍后再调查具体原因。从当前故障中恢复始终是首要任务。然而，还必须测试恢复操作。例如，如果您认为重新启动可以解决问题，则可以先重新启动一项服务进行测试，而不是一次性重新启动所有服务。大多数情况都需要现场分析，这是一个紧张而又令人兴奋的过程。

从故障中恢复需要多长时间？可以容忍多少次失败？如何体现服务的稳定性？我们使用 SLI/SLO 来衡量这些问题。

开发和交付 SLI/SLO

维护服务水平协议听起来是一件非常简单的事情，只需“设定一个可用率”，然后实施即可。然而，现实并非如此。

例如，在制定可用率时，并不意味着我们“达到四个九”（99.99%的时间可用）就足够了。我们有以下问题需要考虑：

如何定义这个可用率？例如，如果我们的目标可用性> 99.9%，一个服务部署了5个Zone，那么有一个Zone宕机了，剩下的Zone可用，可用性是否被破坏了？此可用性率是针对每个区域计算还是针对所有区域一起计算？

计算可用性的最小单位是什么？如果1分钟内50秒没有达到可用率，这一分钟算下降还是上升？

可用期限是如何计算的？是一个月还是一周？一周是最后7天还是按日历周计算？

如何监控SLI和SLO？

如果错误预算即将耗尽怎么办？喜欢减少发布？如果不满足 SLI 和 SLO 会发生什么？

等等，如果这些问题没有考虑清楚，那么SLI和SLO很可能就没有意义了。 SLI/SLO也适用于公司内部对用户的承诺，让用户对我们的服务有期望，不能盲目信任。例如，当还有SLI/SLO的预算时，在满足SLI/SLO的情况下会对服务造成一定的损害，这样用户就不会产生服务100%可用的错误期望。 SLI/SLO还将让SRE更好地了解当前服务的稳定性，并可以据此调整运维、变更、发布计划。

故障回顾

故障复查的唯一目的是减少故障的发生。目前我认为有几个方法不错。

故障审查需要形成文件记录，包括故障发生的过程、时间线记录、操作记录、故障恢复方法、故障根本原因分析、故障发生原因分析等。这些文件应向公司所有者公开，各方姓名均匿名。很多公司都设置了故障文档的查看权限，我觉得没有道理。一些公司的故障审查甚至被公开[5]。

在审查故障时，应将当事人的姓名替换为代码，以营造更好的讨论氛围。

不应该要求生成所有故障审查。在之前公司的一次失败审核中，因为要给领导“解释”，所以每次都会采取一些措施来防止同样的失败再次发生，比如增加审批流程。这太荒谬了。要求高层领导批准自己无法理解的操作，只会让领导更加痛苦，让操作过程变得更漫长、更臭。最后大家都会忘记这里为什么会有审批。但没有人敢删掉。如果你删除了，万一出了什么问题，你自己负责。

无责文化？以前我觉得还不错。但后来发现，有些问题应该归咎于不遵循流程。比如服务下线时，没有检查就直接下线，也没有TCP连接，或者在操作过程中什么都不做就进行了所有操作。这种不公正是由理智行为造成的故障。但不应该有太多的规章制度，否则你就无法做好你的工作。

容量规划

容量规划是一个非常复杂的问题，甚至存在一些悖论。容量必须提前规划，但容量规划需要了解业务的扩展速度。扩张速度无法提前规划。所以我一直觉得这件事很难做，也没有见过做得好的例子。

但至少我们可以建立一个正在维护的系统的模型，知道可以容纳多少机器、多少资源、多少容量。这样，在重大销售等活动期间，可以及时估算所需的资源量。

用户支持

用户支持也是日常工作的一部分。包括技术咨询，以及用户要求的在线故障排除。

这里就需要提到文档的重要性。如果不维护文档，用户将一遍又一遍地问相同的问题。写文档也是一项技术活，需要长时间的积累才能精益求精。文档也需要经常更新。我通常尝试将其保持在这样的状态：用户可以从文档中找到他需要的所有答案，而无需其他任何人。如果我发现用户的问题在文档中找不到，或者很难在文档中的某个地方找到，我会更新文档或者重新整理文档。如果在文档中发现了用户的问题，则直接将文档发送给他。如果用户的问题明显是他们没有读过文档（有很多人根本不读文档，他们只看文档是谁写的，然后直接问那个人），就忽略它。

优秀的文档应该尽量少介绍专有名词，少用无用的专业词汇描述，只描述有指导意义的事实，假设用户没有相关背景知识，列出用法示例，并给出一些实际会用到的例子生活。与其强行举例，不如澄清坏案例。等等，这其实是一个很大的话题，这里就不多说了。

我暂时能想到的就是这些。以下是我看到的一些常见误解以及其他人经常提出的问题。

没有专业团队接受该项目的培训。

这是最常见的抱怨。虽然说SRE的工作应该是50%的开发时间和50%的运维时间，但真实的情况是，即使SRE有一些开发工作，但大部分都是针对公司内部用户和开发人员的。大多数项目只是一些想法，需要尝试看看是否可行。基本上没有专业的设计资源或者PM资源。这种项目要求SRE具备很多技能，包括对产品的了解，清楚其痛点，最好是自己经历过的痛点，然后需要了解设计和管理开发进度。然而，这样的人却很少。事实上，能够为中型项目编写代码的 SRE 很少。因此，大多数公司内部项目都难以使用且复杂。

即使有专业的配套PM和设计，甚至前端资源。基本上也是一场灾难。我也经历过这样的团队。这个内部项目的目标不是互联网项目，而更像是一个toB项目。用户UI的设计、交互逻辑、操作流程、交付周期等都需要另一个领域的知识。否则，人多了只会增加沟通成本，拖慢项目进度。

回到我经常听到的抱怨，据说SRE团队没有像开发团队那样的“正规军”，有设计师、有PM。每个人都履行自己的职责。后端开发只需要把API对齐，然后实现即可。大多数应届毕业生都有这样的幻想，但现实却并非如此。最被误解的是学习主要靠自己，与别人关系不大。我想可能是在一个大的团队里，很多人一起做一件事，心里的疑虑和焦虑就会少一些。人们在这种工作状态下会感到安心，误以为是在“成长”，所有的工作都是自己做。更多的焦虑。

事实是，在大型团队中工作时，您可能会学到更多的沟通技巧，例如在不同阶段与不同的人协调工作目标。如果你想学其他的东西，还是要靠自己。例如，如果你得到一个设计并按原样实现它，你实际上不会学到任何东西。但我们需要理解为什么要这样设计以及为什么不那样设计。如果自己做的话，思维过程基本是一样的，怎么设计，选择什么。它们都是：思考、选择、尝试、体验、思考……

另一个需要澄清的误解是模仿不是学习。我在团队中经历了一次设计。如果我记得这个设计，下次我就会用这个设计来解决类似的问题。这不能称为学习。我见过业务部门做过支付的SRE写的代码，在内部系统中实现订单业务中的订单、交易等概念，完成一个运维流程，甚至连Model的名字都没有改变。用锤子找钉子会让系统变得更糟、更复杂。

总之，把工作划分得更细并不意味着工作就会更专业。身兼多职的人也可以在各个方面都很专业。重要的是不断学习，用正确的方式做事各种工作岗位职责说明书，向好的项目和好的开发者学习。

关于肮脏的工作。

每项工作都有其肮脏的工作：你学不到任何东西，而且做起来也没有乐趣。可能是组织系统监控，可能是整理现有文档，可能是清理一些旧的运维脚本，可能是与不同​​团队做一些沟通工作[6]等等。

这是不可避免的。如果可以的话，学会在每项工作中找到一些偷懒的方式，比如使用脚本来处理一些任务，以更聪明的方式工作等等。

但如果这种工作比例太高，我们就需要思考工作方式了。如果您陷入恶性循环，请看看是否可以对工具和工作流程进行一些更改。如果没有，请考虑寻找不同的工作。

关于承担责任。

人们互相指责的工作环境无疑是一个非常糟糕的工作环境。如果同一个团队或者不同的团队需要互相争吵，如果工作环境不允许他们公开承认自己的错误（SRE难免会犯一些错误），那么公司营造的氛围就有问题。例如，有的公司规定，如果发生P1级错误，必须解雇Px级员工，如果发生P0级错误，必须解雇Py级员工。如果真是这样的话，那公司实际上是在采取一种偷懒的方式，通过增加人力压力来提高系统稳定性。我不知道会不会有什么效果，但我确信在这种情况下没有人会高兴地工作。我建议你换个工作。

如何转行？

其实难度并没有想象的那么高。毕竟大学里没有叫SRE的专业。 SRE需要的知识也是写代码、设计系统、了解操作系统和网络等等。所以大学里好好学本科课程，尝试做（和维护）一些自己的项目，基本就满足了毕业时的要求。非专业人士如果想转行，也可以参考大学课程来补充这方面的知识。

需要注意的是，培训班出来的人或许能够做开发、完成业务，但对于一个SRE来说还远远不够。 SRE不仅需要做出作品，还需要了解其背后的原理。

面试时会问什么？

我觉得面试内容和后端开发基本一样。

如果你应聘的是该职位需要的一些技能，比如K8S、监控系统等，也可能会被问到一些该领域的知识。虽然这些工具是可以学习的，但如果想要找一个有丰富经验或者入职后就能胜任这份工作的人，那么面试成功的机会就会小很多。当然，没有必要沮丧。这是由市场的供求关系决定的。如果对方执意要寻找符合特定要求的候选人，那么对方的选择范围就会小很多。不必因为错过这个机会而后悔没有读书。什么工具。话又说回来，你拥有的技能越多，你拥有的选择就越多。

排除错误可能是切换到 SRE 的最大障碍，这需要一些经验。如果没有经验，可以补充一些操作系统知识，这样就可以用已知的知识和工具来排除未知的问题。

这个存储库是面试问题的一个很好的集合：[7]

我需要能够编写代码才能成为 SRE 吗？

是的，而且编写代码的要求不低于专业后端开发人员。

选择大公司还是小公司？

这是两种完全不同的工作环境。小公司通常都有一位救火英雄，他在公司呆了很长时间，知道所有组件的部署结构，什么都懂。向这样的人学习，你会成长得很快。

大公司有很多细分部门。本文前面列出的每一项都可能是大公司的一个团队，可以在某个领域进行深入研究。

所以这取决于你想做什么。我个人更喜欢靠谱的小公司，或者大公司里靠谱的小团队。

如何判断一家公司是否靠谱？

对于SRE岗位，我总结了一些判断技巧。例如，可以判断对方目前的业务以及SRE员工数量是否处于“正常”状态。人数是否随着业务（机器数量）的增加而增加？这是一个不好的迹象。 SRE 是否过多？如果SRE人员过多，可能有两种原因：1）某位领导为了扩大自己的影响力，正在招聘一些“不必要”的职位。这样就会导致人多物少，大家都会开始做一些奇怪的事情。做奇怪的事情，发明奇怪的需求，用各种方式浪费自己的时间来领公司的工资； 2）这家公司基础太差，大部分工作都需要人工操作和维护，导致基本上有多少台机器就有多少人。简而言之，这不是什么好事。

例如，一些技术相对较好的公司没有大型的SRE团队（现在可能有很多），而一些初创公司甚至没有专门的SRE。一个优秀的SRE首先必须是一个开发者，一个优秀的开发者。离SRE也不远。一些我们熟悉的服务，比如这么大的数据量，其实背后只有少数几个人在维护[8]。几年前，我面试过一家国内公司。当机房遍布全球，业务发展到比较大的规模（上市）时，SRE团队只有10个人。

我想问的另一个问题是对方对 AIOps 的看法。因为我之前在这件事上工作了两年，最后得出的结论是，这基本上是浪费时间，是欺骗上层领导的事情[9]。 AI的不可解释性本质上与运维操作的因果关系是相反的。所以我经常喜欢问面试官对这个技术的看法。基本上他就能判断到底靠谱不靠谱。当然，这是我个人职业阴影造成的后遗症，只能代表我个人的看法。

就这样。以上纯属个人理解，不一定正确。写这篇文章感觉就像是在提供建议。其实我做这件事才几年，所以这篇文章的内容仅供参考。如果您有任何疑问各种工作岗位职责说明书，可以在评论中提问，我会尽力解答。