我几年来一直在推文中讲话和怒吼，一次又一次地被问到同样的问题：“如何成为SRE？”

我的回答通常是漫无边际的。这么久，有时候我甚至都没有回信。可以说的太多了！太多的历史、太多的内容、太多由于不同个人情况而产生的因素。

所以，在这里表达一些我关于如何成为SRE的正式的回应：我认为它是什么，我是如何成为SRE的，要成为SRE你应该做些什么。本文是一本指南，可用作书签、参考和分享。它提供了一些见解，读者可以根据具体情况进行映射，以帮助开始自己特定的路径。

希望你在旅程中发现这些内容很有用。

目录

定义

那么，什么是SRE（网站可靠性工程）？根据Google SRE的书：“SRE就是软件工程师设计一个运维团队的过程。”由于多种原因，这个定义有点争议，尤其是它的含义是运维团队无法进行合理的系统设计，而不是运维团队经常资源不足。这个定义的争议性还在于它暗含着所有的SRE都在日复一日地对后端系统进行编码，而这在Google甚至都不正确。

虽然谷歌投入了相当多的资金来对外宣传SRE的定义，但业内人士根据自己的情况开始实践SRE，这样就导致了公司与公司之间有很大差异。而对它的定义，我看到的SRE指的是：

负责事件响应的团队；
负责内部部署工具的团队；
负责数据中心的团队；
负责所有工程可靠性流程的团队；
负责容器平台的团队；
负责数据库的团队；
负责网络的团队；
负责监控的团队；
嵌入开发团队中，做开发人员不负责的任务的团队

我想明确一点：本指南不是关于Google SRE的。Google SRE有自身SRE的实践风格，某种程度来说是一个完全不同的学科。其他大公司可能会采用Google SRE的一部分，但我不知道谷歌以外谁会完全这样实施。如果你想成为Google SRE，那完全没问题，但是这篇文章并不想这样引导。

那么，SRE更广泛的定义是什么呢？很难为所有公司确定一个定义，就像很难为所有公司定义软件工程一样。如果软件工程师（SE）是由代码定义的，那么SRE也是软件工程师。那么，SRE和需要on-call的软件工程师之间有什么区别呢？

如果你非要让我说，我会将网站可靠性工程定义为：“大规模构建和维护可靠的SaaS平台的实践。”我认为SRE适用于拥有大型SaaS产品的公司，他们通常有高流量的网站和相关服务。也就是说，我是按照“网站可靠性”的字面意思来下的定义。

（你可能认为大型的内部服务（例如数据库）需要SRE，但我的观点是这样的服务可能支持更大的面向客户的平台）。

一个需要on-call的软件工程师知道代码如何工作、破解和修复。网站可靠性工程师知道代码要如何适应公司的架构，并且需要设置整个系统以保证服务成功运行。

那么根据这个定义，SRE的一些关键技能覆盖哪些领域？

软件工程
分布式系统设计
操作系统
网络
数据库
安全
可靠性最佳实践
故障排除
客户支持

有人会抱怨“太多了！”，确实如此。SRE是一门广泛的学科，因为运行大型分布式站点需要很多的技能。事实上，许多SRE倾向于专注上述的一种或两种技能。你可能也发现了，有的公司通常有多个SRE团队，支持平台上的不同领域。也有的团队可能正在实践SRE但叫法不同，例如叫基础设施工程或生产工程。你还会发现有些拥有SRE团队的公司根本就没有在实践SRE。我鼓励大家把注意力集中在工作本身上，不用太纠结SRE的实际含义是什么。

现实

每当有人问我如何成为SRE时，通常他们最后会问自己为什么要做SRE。这样说似乎不太礼貌，让我们花点时间来解释一些可能对该领域的误解。根据Google的深度营销与行业整体情况，期望与现实之间可能存在很大差异。

期望

拥有一件皮夹克
收入比开发人员多
每个人都听你说的话
有权推迟交付实践，调整错误的优先级
一直研究跨技术的新兴事物
几乎不干体力活，只是一直在编码
如果要求on-call（译者：随叫随到，SRE在Google的特色之一）还态度粗鲁，可以随时挂断呼叫

现实

收入与开发人员一样
考虑到on-call的负担，实际收入可能比开发人员还少
要对自己的东西on-call
有时还要对开发人员的东西on-call！
可以一连几个月不写代码
同时，你需要知道如何读代码并诊断代码问题
可能要负责可靠性，但无权修复它
需要高级的客户支持技能，来说服开发人员采用大规模系统运行的最佳实践

上述现实并非在每个地方都是如此，但还是比很多人期望的要真实。有时你要为新的花哨平台构建工具，有时候需要与Puppet（一个自动化部署工具）和DNS作斗争。你需要具备灵活性并积累各种技能来完成工作。

SRE的其他一些现实

解决StackOverflow无法解决的真正有趣的问题；
有机会在整个软件/硬件堆栈中学习各种领域；
体验大规模问题的快感，比如部署数千台服务器或缓解DDoS攻击；
推进公司的全新流程；
磨练沟通技巧，比如解决内部开发过程中的纠纷，以及对公开事故的很长的事后分析；
作为负责和维护生产平台的人，得到该有的信任；
与各领域和职业生涯中的工程专业人士合作。

有一个非常老套的说法：如果是为了权力和荣耀，可能会感到失望。成为SRE，因为你对这个工作感兴趣。

我自己的路

有时人们会根据我职业生涯中的具体步骤来追问：书名，公司，会议等。他们希望得到尽可能多的信息，以便尝试复制我的道路。问题是，我的道路不容易复制。

我普通的道路

在计算机和互联网环境中长大，也就是说如果无聊我可以闲逛
拥有电影学位
经济衰退期间毕业，无法在创意领域找到工作
获得了一份技术支持的工作来支付学生贷款
对服务器管理的职位着迷
成为了一名光荣的接待员/销售代表
很无聊地成长，晚上开始学习Python
留下来为不同公司提供更好的支持工作
结识了很酷的开发人员，不断地在晚上学习Python
应聘了Python工作
没得到Python工作
应聘了内部工具的工作
获得了这样的共苦
Ops同事休了陪产假，暂时接过他的职务
SRE经理要我加入SRE团队

如果回放，这就是一个电影学生成为科技工作者的故事。只要努力工作，你也会实现自己的梦想！但这条道路是他人无法复制的，例如，当我面试支持方面的工作时，我是一个年轻的、白人、纯女性打扮的女人，由年长的、有家室的白种男性雇佣。他们决定“给我个机会”，并说我让他们想起了他们的女儿，其中有个人甚至基于他小女儿的学校作业面试了我！做这种关联的感觉并不好，虽然它确实对我有利，但我无法帮助你复制它。

我认为我的道路中可以而且应该复制的，是不断学习。我的整个科技生涯就是我做的工作和我正在学习的工作。我不断阅读书籍，观看讲座，上课，学习新语言，与业界朋友交谈。我不会满足于现状，如果对当前正在做的工作不感兴趣，我会在晚上找到一些有趣的东西，然后会付诸行动。最终，这些新技能可以帮助我完成目前的工作或保证下一个工作。

我没有做到，但是你应该去做的是利用你的社区。在开始一家科技公司的工作之前，我还不知道技术社区是怎么一回事，我一个人一直在抨击Python问题，而不是参加聚会并获得帮助。有一段时间我找不到工作，也不了解技术工作相关的情况。后来我终于找到了工作，但我认为这更多的是一些运气的成分而不是我的能力。利用你的社区吧！它会帮助你找到一份工作。

你的道路

我遇到过各种不同背景的人，他们都想要成为SRE。有些人已经是开发人员，有些人还在训练营，有些人在做QA或营销，他们都想知道下一步应该是什么。

官方的答案是“看情况”，这是认真思考权衡所有情况后的答案！但我知道这个答案没有什么用，所以让我们以不同的方式来往下说。

如果我现在试图成为SRE，会做两件事：

找到离我最近的SRE组织（请记住，它可能不会被称为“SRE”！）。
弄清楚成为SRE我需要跳（hop)几次。

你可能不熟悉这个术语 - “跳跃”（hops）。它是一种网络概念，指的是数据包在来源和目标之间发生的路由网络设备（路由器、网桥等）的数量。在家用wifi上的笔记本电脑和朋友的笔记本电脑之间传输的数据包，可能比在笔记本电脑和另一个国家/地区的朋友的笔记本电脑之间传输的数据包少。同样地，我认为与SRE团队合作的开发人员，比学习电影毕业后想要成为SRE的人之间的跳跃会更少。

职业生涯中的跳跃就像是技能和网络（人际网络！）间的组合。这是一个持续的过程，找到需要什么技能来进行下一跳，并找到能帮助你成功的人。你的下一跳很可能不是一个SRE工作，但它会让你更接近SRE！

与计算机网络非常相似，社交网络越大，道路就越有效率。这取决于谁帮助你、拥有的技能和时间，你的道路可能比同一个地方的其他人更长或更短。一个人的道路可能看起来像新兵训练营 -自由职业者 - 兼职开发人员 - 副业做做运维 - 系统管理员 -运维 - SRE。而另一个人可能会在刚毕业就找到SRE团队的实习机会。不同的人有不同的机会，你需要找到符合自己实际情况的机会。

因此，先找到SRE有哪些相关的技能然后缩小这些技能范围。缩小到什么程度呢，就是如果你拥有了这部分技能，你就可以得到一份更接近SRE的新工作。然后重复。

例如，如果不知道如何编程：学会编程！去训练营，参加在线课程，获得计算机科学学位，做一切合适的事情。扩展人际网络并找到招聘人员，或做自由职业。尽量让你的简历上有开发经历，然后在新职位中学习下一个技能，例如网络或数据库。参加更多的课程，找到更多的聚会，换新工作，一步步接近SRE。

最难的部分，是如何让你的脚踏进那道门槛。一旦有了开发人员或系统管理员的工作，一旦可以在简历上展示出某种形式的“工程师”，你就有空间来呼吸。坚持那份工作1到2年，获得一些经验，建立自己的网络，并开始下一个支点。这需要时间，但会是你职业生涯剩余的时间中，成为SRE并超越它的一个方法。

面试

无论你过程如何，最终都会碰到SRE工作的面试。恭喜！不同公司和团队的SRE面试是不同的，具体取决于你的职责。因此，提前研究好工作岗位（无论如何你都应该这样做），并准备好要涵盖的主要主题。

除了在所有面试中常见的行为方面的问题之外，SRE的面试还会包括编码、故障排除和可靠性方面的问题。

编码

无论是带回家的脚本问题还是现场的白板面试，你都不得不编码。
通常他们会告诉你哪些语言是可以接受的。如果他们没有告诉你，请提问。
- 通常，任何面向对象的语言都要会（Python、Ruby、C ++、Java等），Go是一个例外。
一般的建议是描述你正在思考的一切，但这方法在以前对我无效的。花时间静静地考虑你自己的方法，然后解释你将要做什么，如果需要就不断重复。
如果没有明确计时、还可以带回家的作业，那就花上你所需要的所有时间！员工肯定被安排在候选人之前去做这些作业，许多编码任务都没有计时，因此你可能需要花比他们认为的还多的时间。
- 如果他们问你需要多长时间，请给一个合理的谎言。除非它恰好是他们专有的应用程序，否则他们无法分辨。（译者：不赞成谎言，更合适的是一个合理的预估）

故障排除

他们希望看到你的思考方式，以及对系统的理解程度。
- 可能采取经验示例的形式，即告诉“碰到过的的故障以及自己的贡献”。
- 也可能采取谜题的形式，即“时区A的开发人员抱怨每天下午3点网络连接会速度慢，你会怎么调查这个？“
随意提问（“我有root吗？”）并在墙上抛出示例（“我会先查看日志，以防开发人员并不认为应该看那里。”）
这些问题的关键在于了解你对以前使用过的系统的熟悉程度、所拥有的体验以及碰到过的不常见的例子。重点是判断深度，而不是正确性。可以放心地说，“这就是我所知道的”或“我不知道，但我会试试它。”

可靠性

整个工作中，对可靠性的要求是明显的。
编写代码时，应该编写异常处理和测试。如果没时间，请写下来或解释你将如何解决这个问题。
- 会测试什么？怎样测？会如何进行变更？会怎么回滚？
在进行故障排除时，考虑可靠性以及每个步骤所承担的风险。
- 是否建议重启还在处理生产事务的服务器？如何确保故障不再发生？

对于入门级SRE，我希望能够使用一种灵活的编程语言，比如Python。可以创建一个小的应用程序，编写测试并处理异常。还希望看到像Linux这样的操作系统方面的一些能力，可以在命令行上搜索文件系统，知道如何grep日志，可以ping一个域。希望看到大规模技能方面的一些预见，例如使用配置管理系统或CI工具。可能无法负担运行AWS实例的费用，但也许已经使用免费的Heroku帐户，并在免费的监控add-ons程序中检出了你的应用程序指标。无论在SRE职业生涯中，无论是Kubernetes还是MySQL还是边缘网络，这些基础的技能都将帮助你取得成功。

一个有趣的部分，每次面试结束时都应该留出时间让你提问; 也就是说，你要面试公司。应该提前计划出这些问题，并写下来以供参考。要注意他们的答案。要从感觉上了解他们的工作文化、项目和团队的健康状况。

可能不会第一次得到你梦寐以求的工作，但是询问其中的一些问题，可以帮你了解这项工作将如何为下一次求职提供帮助。

“过去六个月你做了哪些项目？”

SRE的工作是周期性的，是主动和被动的混合体。六个月涵盖两个季度，可以很好地了解如何平衡你的工作。
在那段时间编了什么代码吗？或者手动停用了1,000台服务器？如果创建了什么，是否写了什么文档？

“你最后一次被呼叫的时间是什么时候，是因为什么？”

呼叫发生了。我们准备好了on-call，因为我们希望在某个时候被呼叫。
但是，“主数据库发生了故障，已经通知到了所有的人”，和“这个旧的服务器无法ping，这就是重要的一切，但没人有时间修复它”，这两者是有区别的。

“你所有的开发团队都on-call吗？”

分配on-call的任务，是DevOps文化的关键部分，应该知道公司处于什么阶段。
所有开发团队都on-call吗？到了这个阶段吗？如果是，它有多久了？哪些团队还没有on-call？适当的时候问这个问题，你会希望了解开发团队以及团队之间的关系。
如果觉得这个话题还可以继续，可以问问需要你on-call的内容是什么。答案可能很明显，但可能是另一个团队尚未替换旧的Nagios，你会被安排它的安装on-call。

问这些问题不是来确保呆在最好的公司，而是要清楚你想要的是什么。例如，如果喜欢未来的队友和福利套餐，但是知道自己正在进行可怕的on-call轮换，那么你可以在薪资谈判中提到这一点。重复一遍，可能不会第一次尝试就得到梦寐以求的工作，所有的公司都有其优点和缺点。牢牢地记住哪些因素破坏了双方的印象，并尽力去搞清楚哪些公司存在这个因素。