作者 | Alice Goldfuss译者 | 杨雷编辑 | 张婵

如何成为 SRE？很多人都想问这样的问题，作者根据自己的经历向大家介绍了什么是 SRE，以及如何成为一名 SRE。

几年来我一次又一次地被问到同样的问题：“如何成为 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，但我的观点是这样的服务可能支持更大的面向客户的平台）。

[img=1,0][/img]

一个需要 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，最好是因为你对这个工作感兴趣。

我自己的路

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

我普通的道路

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

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

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

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

你的道路

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

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

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

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

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

[img=1,0][/img]

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

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

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

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

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

面试

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

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

编码

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

故障排除

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

可靠性

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

对于入门级 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 轮换，那么你可以在薪资谈判中提到这一点。重复一遍，可能不会第一次尝试就得到梦寐以求的工作，所有的公司都有其优点和缺点。牢牢地记住哪些因素破坏了双方的印象，并尽力去搞清楚哪些公司存在这个因素。

写在最后

现在，你已经了解了什么是 SRE，并且有一条通向它的道路。下一步就是发展你的技能！如上所述，通往 SRE 有很多道路，你需要学习系统、运维、数据库、网络等等多项技能，不要停止学习！

                                                       

                       

                                               

                               

作者 | Alice Goldfuss译者 | 杨雷编辑 | 张婵

如何成为 SRE？很多人都想问这样的问题，作者根据自己的经历向大家介绍了什么是 SRE，以及如何成为一名 SRE。

几年来我一次又一次地被问到同样的问题：“如何成为 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，但我的观点是这样的服务可能支持更大的面向客户的平台）。

[img=1,0][/img]

一个需要 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，最好是因为你对这个工作感兴趣。

我自己的路

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

我普通的道路

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

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

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

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

你的道路

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

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

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

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

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

[img=1,0][/img]

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

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

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

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

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

面试

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

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

编码

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

故障排除

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

可靠性

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

对于入门级 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 轮换，那么你可以在薪资谈判中提到这一点。重复一遍，可能不会第一次尝试就得到梦寐以求的工作，所有的公司都有其优点和缺点。牢牢地记住哪些因素破坏了双方的印象，并尽力去搞清楚哪些公司存在这个因素。

写在最后

现在，你已经了解了什么是 SRE，并且有一条通向它的道路。下一步就是发展你的技能！如上所述，通往 SRE 有很多道路，你需要学习系统、运维、数据库、网络等等多项技能，不要停止学习！