很多人问我关于SRE职位的问题。这是一个很大的话题。让我介绍一下这个博客中的一些想法。SRE到底是什么？这是谷歌最先提出的概念。我的理解是软件是用来解决运维问题的。标准化、自动化、可扩展性和高可用性是主要任务。这个职位提出的时候，要解决的问题是打破开发人员想要快速迭代和运维人员想要保持稳定拒绝频繁更新之间的矛盾。SRE目前还是比较难招的。一方面，这个职位需要一定的经验，应届毕业生一般没有运维复杂软件的经验；工作，有拒绝这项工作。最根本的，其实这个职位要么找有运维经验的开发人员，要么找有软件开发能力的运维工程师。所以很难找到合适的人。现实生活中，不同公司的SRE岗位差别很大，有的甚至可能会把传统的运维岗位换个名字。比如蚂蚁金服有两种SRE。一个负责稳定性，也就是大家理解的SRE；另一个叫资金安全SRE，不负责服务的正常运行，但负责资金数额正确，对账无误，工作的主要内容是开发，主要是资金验证平台和验证规则（没做过，只是个人理解）。从某种意义上说，它不再是SRE，而是在专业领域的发展。谁开发和维护Netflix[1](2016)模型。SRE负责提供技术支持和咨询服务。Netflix在全球170个国家有服务，只有5个CoreSRE。微软有专门的GameStreamingSRE[2]，负责XBox在线游戏的稳定性。因此，不同公司的SRE内容各有侧重，要看公司要提供什么样的服务。我们可以学习网络分层的方式，将SRE的一般工作内容从下到上分为三类：基础设施：主要负责最基础的硬件设施，网络，类似IaaS，要做的事情可以参考DigitalOceanPlatform：提供Middleware技术，一些开箱即用的服务，类似PaaS，可以参考Heroku、GCP、AWS等业务SRE：维护服务、应用，维护业务的正常运行。InfrastructureInfrastructure和PlatformSRE其实是可有可无的，其实这几年商业服务越来越多。例如，如果公司选择将所有服务都部署在AWS中，那么就不需要自己搭建Datacenter和维护网络。它只需要几个AWS专家。能。如果是这样，工作内容也可大可小。可以从管理购买的vps开始，也可以从购买硬件服务器开始。我觉得InfrastructureSRE的工作内容可以定义为：负责服务器采购、预算、CMDB管理。需要知道（可以查询）每个站的负责人，他们在做什么。这个非常重要。如果做得不好，会造成巨大的资源浪费。提供可靠的软件部署环境，通常是虚拟机，或者裸机。统一维护操作系统的版本，Linux发行版的版本，Kernel的版本等。维护机器上的基础软件，比如NTP，监控代理，其他代理。提供机器登录方式、权限管理和命令审计。维护一套可观察性基础设施，如监控系统、日志系统、追踪系统等。为了维护网络，大公司可能会自行在机房设计网络。这些包括：网络连接，这是必需的。对于上层用户（PlatformSRE），交付的服务应该是任意两个IP都能ping通，也就是三层以下的网络要管好。b.NAT服务C.DNS服务D.防火墙E.四层负载均衡，七层负载均衡f．CDN证书管理每个项目可以是一个大团队或只有一个人来商业化Infra服务。您可以使用开源产品或开发自己的产品。PlatformSREInfrastructureSRE维护基础设施。PlatformSRE使用他们提供的基础架构来构建软件服务，允许公司内的开发人员使用开箱即用的软件服务，例如Queue、Cache、计划任务、RPC服务等。主要任务包括：RPC服务：允许不同服务相互发现并调用私有云服务队列服务，如Kafka或RabbitMQ分布式cronjob服务缓存网关服务：反向代理配置对象存储：s3其他数据库：ES、mongo等.一般而言，关系型数据库由DBA运维，而NoSQL或图数据库一般由SRE维护。内部开发环境：a．SCM系统，如自建Gitlabb．CI/CD系统c.镜像系统，如Harbord．其他开发工具，如分布式编译、Sentry错误管理等。10.一些离线计算环境，大数据服务业务SRE有PlatformSRE的支持，开发者在编写代码时基本不需要关心部署问题。您可以专注于开发并使用公司的开箱即用服务。这一层的SRE更贴近业务，知道业务是如何运行的，请求是如何处理的，它依赖于哪些组件。如果X有问题，可以采取哪些降级策略。参与应用架构设计并提供技术支持。主要工作内容有：参与系统的设计。比如熔断、降级、扩容等策略。进行压力测试以了解系统的容量。做好容量规划。业务方面随叫随到。对于一个专业的SRE来说，以上技能应该没有明显的界限。比如业务SRE也需要掌握一些网络技能，InfraSRE也需要写一些代码。很多工具被各个岗位的人使用，比如Ansible/Puppet/SaltStack等IT自动化工具，或者Grafana/Prometheus等监控工具。只有了解它们才能正确使用它们。换句话说，对于业务SRE来说，虽然基本上不会管理四层以下的网络，但是如果遇到网络问题，可以通过现有的工具和权限排查交换机问题，向InfraSRE求助：“Pleasehelpme看xxIP到交换机有没有异常，因为xxx显示的结果是xx”，比“我怀疑xx网络有问题，请帮忙排查”要好？以上是岗位职责的大致划分。这种分层其实没什么意义，但是可以让读者了解SRE涉及到什么样的工作。下面是一些日常工作。Deployment服务部署分为两种：Day1：服务在线部署的那一天Day2+：服务部署完成后，会有很多更新、升级、配置变更、服务迁移等，Day2+有要做很多次，Day1做的很少，持续迭代升级后很难保证Day1可靠运行。换句话说，我们在服务部署之后不断地进行变更，同时我们也需要保证服务能够在新的环境中可靠地部署。硬编码部署环境，怪异的工作，会破坏Day1的可靠性。在以前的公司，扩建新机房的过程是一场噩梦。奇怪的配置和硬编码太多，导致所有业务都无法部署到新机房之前，坑了无数坑。Day2+的操作并不简单，主打稳定性。对于重要的变更操作，需要设计变更方案，如何做灰度测试，出错了如何回滚，如何保证回滚成功（如何测试回滚）等等。部署的操作在理想情况下应该是可追踪的，因为并非所有导致问题的操作都会立即导致问题。比如，当时一个操作完成是没有问题的，但是一个月后，不小心重启或者内存达到某个指标就触发了这个问题。如果可以记录操作，我们可以回溯之前所做的修改，方便定位问题。Git现在通常用于跟踪部署过程中的更改(gitops[3])。OncallOncall简单的说就是保证在线服务的正常运行。典型的工作流程是：接到告警，查看告警原因，确认在线服务是否有问题，定位问题，解决问题。收到警报并不总是意味着真正的问题，也可能是警报设置不当。告警和监控面板不是静态的配置，应该天天变化，时刻调整。如果发现没有真正在线问题的告警，则需要修改告警规则。如果发现当前监控不能快速定位问题，应调整监控面板，增加或删除监控指标。业务在发展，请求量在变化，某些阈值需要不断调整。没有通用的定位问题的方法。你需要根据实时看到的情况，结合自己的经验进行猜测，然后使用工具来验证你的猜测，进而确定问题的根源。但是有一种解决问题的方法论，叫做SOP，标准操作程序[4]。即：如果出现这种现象，那么通过执行那个操作，就可以恢复业务。应提前制定SOP文件并验证其有效性。需要注意的是，以上定位问题和解题没有先后顺序。一个常见的错误是，当故障发生时，需要很长时间才能定位故障的根本原因，然后进行修复。这通常需要更长的时间。正确的做法是根据现象看现有SOP能否恢复营业。比如当前错误只发生在某个节点上，那么该节点会直接下线，具体原因稍后查看。从当前故障中恢复始终是第一要务。但是，还必须测试恢复操作。例如，如果您猜测重启可以解决问题，则可以重启一台设备进行测试，而不是一次性重启所有服务。大多数情况都需要实地分析，这是一个紧张而刺激的过程。从故障中恢复需要多长时间？可以容忍多少失败？如何标记服务的稳定性？我们使用SLI/SLO来衡量这些问题。制定和交付SLI/SLO维护服务级别协议听起来是一件非常简单的事情，只需“设定一个可用率”然后实现即可。然而，事实并非如此。例如，在制定可用性率时，并不意味着我们“实现4个9”（99.99%的时间可用）就足够了。我们有以下几个问题需要考虑：1.这个可用率如何定义？例如，我们的目标是可用性>99.9%。如果一项服务部署了5个区域，则一个区域已关闭，其余区域可用。可用率是否被破坏？可用率是按每个Zone计算还是所有Zone一起计算？2.计算可用性的最小单位是什么？如果1分钟内有50秒没有达到可用率，这一分钟算down还是up？3.可用率的期限是如何计算的？按一个月还是按一周？一周是最后7天还是算一个日历周？4.如何监控SLI和SLO？5.如果错误预算用完了怎么办？比如减少发布？如果不满足SLI和SLO会怎样？等等，如果这些问题没有考虑清楚，那么SLI和SLO恐怕就没有意义了。SLI/SLO也适用于对公司内部用户的承诺，让用户对我们的服务有期待，而不是盲目信任。例如，当谷歌对SLI/SLO仍有预算时，它会在满足SLI/SLO时对服务做一些损害，这样用户就不会产生服务100%可用的错误预期。SLI/SLO也会让SRE更加了解当前服务的稳定性，并可以据此调整运维、变更、发布计划。崩溃恢复崩溃恢复的唯一目的是减少故障的发生。我目前认为有一些是好的做法。故障恢复需要记录在案，包括故障发生的过程、时间线记录、操作记录、故障恢复方法、故障根源分析、故障发生原因分析等。文件应提供给公司的所有所有者，并匿名所有各方的姓名。很多公司都对故障文档设置了查看权限，我觉得没有意义。一些公司的故障恢复甚至是公开的[5]。恢复失败时，用代码代替当事人的名字，这样可以营造更好的讨论氛围。并非所有故障恢复都需要采取措施。在回顾之前公司的失败时，因为要给领导一个“交代”，所以每次都会采取一些措施来防止同样的失败再次发生，比如增加审批流程等等。这是荒唐的。一个他看不懂的操作要请高层领导批准，只会让领导更加痛苦，让操作流程又臭又长。到最后大家都会忘记这里为什么会有审批。但是没有人敢删。你删除它，你对发生的事情负责。责怪自由文化？以前觉得挺好的但后来发现，有些问题是因为不按流程办的，在某种程度上也是有罪的。比如不勾选下线服务，没有tcp连接，直接下线，或者所有操作都没有canary。非理性行为导致的故障。但条条框框也不能太多，否则工作就做不成。容量规划容量规划是一个非常复杂的问题，甚至存在一些悖论。容量需要提前规划，但是容量规划需要知道业务的扩??容速度，而扩容速度是无法提前规划的。所以我一直觉得很难做到这一点，我从来没有看到过很好的例子。但至少你可以为维护的系统建立一个模型，知道可以容纳多少台机器，多少资源，多少容量。这样在遇到大促等活动时，可以及时预估需要的资源量。用户支持用户支持也是日常工作的一部分。包括技术咨询，以及用户要求的在线故障排除。这里需要提到文档的重要性。如果不维护文档，用户会一遍又一遍地问同样的问题。写文档也是一门技术活，优秀的需要长期积累。文档也需要经常更新。我通常这样做，保持这样一种状态，即用户可以从文档中找到他需要的所有答案，而无需其他任何人。如果我发现某个用户的问题在文档中找不到，或者很难在文档中的什么地方找到，我会更新文档，或者重新整理文档。如果文档中已经发现用户的问题，则直接将文档发送给他。如果用户的问题很明显是连文档都没看过（很多人压根就没看过文档，只看文档是谁写的，直接问这个人），直接忽略即可。优秀的文档应该尽量少引入专有名词，少用无用的专业词汇描述，只描述有指导意义的事实。假设用户不具备相关背景知识，列出使用示例，并给出一些实际中会用到的例子。不是强行举例，而是澄清了一个不好的案例。等等，这其实是一个很大的话题，这里就不展开了。目前能想到的就这些了。下面是我经常看到的一些误解，以及别人经常问到的问题。没有经过培训就没有做项目的专业团队。这是抱怨最多的。虽然说在工作上SRE要花费50%的开发时间和50%的运维时间，但实际情况是，SRE即使有一些开发工作，大部分也是面向内部用户和开发人员的公司内部。大部分项目都是一些idea，需要自己去尝试看看行不行，基本上不会有专业的设计资源，PM资源。这种项目需要SRE具备各种技能，包括对产品的理解，对它的痛点有清晰的认识，最好是自己经历过的痛点，然后还要理解设计，管理开发进度。然而，这样的人很少。事实上，能为中型项目编写代码的SRE很少。因此，公司内部的大部分项目都会难以使用且复杂。甚至有专业配套的PM和设计，甚至是前端资源。基本上也是一场灾难。我也经历过这样的团队。这种内部项目对标不是互联网项目，更像是toB项目。用户UI设计、交互逻辑、操作流程、交付周期等都需要另一个领域的知识。否则，人越多，只会增加沟通成本，拖慢项目进度。回到我经常听到的抱怨，据说SRE团队没有开发团队那样的“正规军”，有设计和PM，各司其职，后端开发只需要对齐API，然后实现它。大多数应届毕业生都有这样的幻想，但事实并非如此。最主要弄错的一点是，学习主要靠自己，跟别人关系不大。我觉得可能是在一个大的团队里，很多人一起做一件事情，他们心里的疑惑和焦虑会少一些。人在这样的工作状态下会心安理得，误以为是“成长”，所有的工作都自己一个人做，更多的是焦虑。事实是，在大团队工作可能会学到更多的沟通技巧，比如在工作目标的不同阶段与不同的人保持一致，其他的还是要靠自己。例如，如果你得到一个设计并按原样实现它，你将不会学到任何东西。但是要明白为什么要这样设计，为什么不那样设计。自己做的话，思考过程基本是这样的，怎么设计，选什么。两者：思考、选择、尝试、体验、思考……另一个需要澄清的误解是模仿不是学习。我在团队里体验过一个设计。如果我记得这个设计，下次我会用这个设计来解决类似的问题。这不能称为学习。我看过业务部做过支付的SRE写的代码。在内部系统中，实现了订单业务的订单和交易的概念，完成了一个运维过程，连Model的名字都没有改变。用锤子找钉子会让系统变得更糟、更复杂。总之，分工更细并不代表工作就会更专业。一个身兼多职的人，可以在各个方面都很专业。重要的是要不断学习，使用正确的做事方式，向优秀的项目和优秀的开发人员学习。关于肮脏的工作。每份工作都有其肮脏的工作：没有什么可学的，没有乐趣可做。可能是整理系统的监控，可能是整理现有的文档，可能是清理一些旧的运维脚本，可能需要做一些与不同团队的沟通工作[6]，等等.这是不可避免的，如果可以的话，学会从每一份工作中找出一些偷懒的方法，比如编写一些工作的脚本，以更聪明的方式工作等。但是如果这种工作的比例太高，则有必要要思考工作方法的问题。如果你陷入恶性循环，看看你能不能在工具和工作流程上做一些改变。如果没有，考虑换工作。关于承担责任。互相指责的工作环境无疑是非常糟糕的工作环境。如果同一个团队或者不同的团队需要相互勾心斗角，如果工作环境不允许大方承认自己的错误（SRE难免会犯一些错误），说明公司营造的氛围是有问题的。比如有的公司规定，出现P1级错误必须开除Px级员工，出现P0级错误必须开除Py级员工。如果是这样的话，公司其实是在用偷懒的方法，通过增加人为压力来提高系统的稳定性。有没有影响我不知道，但是可以肯定的是，在这种情况下，没有人会开心工作。建议换工作。如何转行？其实难度并没有想象的那么高。毕竟大学里没有叫SRE的专业。SRE需要的知识也是写代码，设计系统，了解操作系统和网络等等。所以学好大学里的本科课程，尝试做（和维护）一些自己的项目，基本达到要求的时候你毕业了。如果非专业的学生想转行，也可以参考大学的课程内容来补充这方面的知识。需要注意的是，培训班出来的人做开发、完成业务是可以的，但是做SRE是不够的。SRE不仅需要让事情运转起来，还需要了解其背后的原理。面试会问什么？我觉得和后端开发的面试内容基本一样。如果你应聘的是这个职位需要的一些技能，比如K8S、监控系统等，你也可能会问一些该领域的知识。虽然这部分工具性的东西是可以学的，但是如果有人要的是有经验的人，或者是入职后能干活的人，那么面试成功的几率就会小很多。当然，没必要郁闷。这是由市场供求关系决定的。如果对方执意要寻找符合特定要求的人选，对方的选择范围就会小很多。不要因为错过了这个机会而后悔没有学习。什么工具。话又说回来，你拥有的技能越多，你的选择就越多。排查错误可能是切换到SRE的最大障碍，这需要一定的经验。如果没有经验，就补一些操作系统的知识，这样就可以用已知的知识和工具来解决未知的问题。您需要能够编写代码才能成为SRE吗？是的，而且对写代码的要求不低于专业的后端开发。选择大公司还是小公司？这是两种截然不同的工作环境。小公司一般都有一个救火英雄，在公司里待的时间长，对所有组件的部署结构，什么都了如指掌。向这种人学习，成长会很快。大公司有很多部门。本文前面列出的每一项都可能是大公司的一个团队，可以深入研究某个领域。所以这取决于你想做什么。我个人更喜欢靠谱的小公司，或者大公司靠谱的小团队。如何判断一家公司靠不靠谱？对于SRE这个职位，我总结了一些判断技巧。比如你可以判断对方现在的业务和SRE员工数量是否处于“正常”状态，人数是否随着业务（机器数量）的增长而增长？这是一个不好的迹象。SRE是否太多？如果SRE人太多，有两种可能的原因：1）某领导为了扩大自己的影响力，为一些“不需要”的岗位招人，会导致人多事少，大家都开始做一些奇怪的事情奇怪的事情，发明奇怪的需求，以各种方式浪费我的时间来领取公司的工资；2）这家公司基础太差，大部分工作都需要人运维，导致基本上有多少人就有多少机器。总之，不是什么好事。一些技术比较好的公司并没有庞大的SRE团队，比如Instagram、Netflix（现在可能有很多人），一些初创公司甚至可能没有专门的SRE。优秀的SRE首先是开发人员。开发人员离SRE也不远了。一些知名的服务，例如webarchive等数据量，实际上只有少数人在维护[7]。几年前，我面试过一家国内公司。当机房遍布全球，业务做的比较大（上市）的时候，SRE团队只有10个人。另外一个我喜欢问的问题是对方怎么看AIOps。因为我之前在这件事情上做了两年，最后得出的结论是，这基本上是浪费时间，欺骗了上级领导[8]。AI的不可解释性，本质上与运维操作的因果性背道而驰。所以经常喜欢问面试官怎么看这个技术，基本上就可以判断靠谱不靠谱了。当然这是我个人职业阴影造成的后遗症，只能代表我个人的看法。说了这么多，只是个人的一些理解，不一定对。写这篇文章，感觉就像在指点江山。其实我也才做几年，所以本文内容仅供参考。
