我几年来一直在推文中讲话和怒吼，一次又一次地被问到同样的问题：“如何成为 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 轮换，那么你可以在薪资谈判中提到这一点。重复一遍，可能不会第一次尝试就得到梦寐以求的工作，所有的公司都有其优点和缺点。牢牢地记住哪些因素破坏了双方的印象，并尽力去搞清楚哪些公司存在这个因素。
资源
现在，你已经了解了什么是 SRE，并且有一条通向它的道路。下一步就是发展你的技能！
如上所述，通往 SRE 有很多道路，包括计算机科学学位和编码训练营。但那些要花钱，并且可能对你来说遥不可及。可以利用免费资源进入市场，我认为每个人都应该拥有同样的机会。
以下是 SRE/Ops/Systems 社区提供的免费教育资源的合集，我还没有亲自把所有的都使用过，所以也没有什么排名，但每一个都强烈推荐。这里提供了这些材料的不同类型，以便你根据自己的学习方式进行选择。
你在这里的所有学习都不要停下来。选择看起来很有趣的内容，如果不能解决问题，请选择其它内容。使用以下列表作为学习指南，来作为填补你空白的备忘单，它甚至还是检查你是否会享受 SRE 工作的一个好方法！
一般/多个主题
Architecture
Cloud
Databases
Git
Networking
Operating system internals
Programming
Puppet
Security
Unix / Linux operations
Vim
原文链接：How to Get Into SRE
暂无签名
中国开发者画像洞察研究报告 2024
分析开发者的行为模式、工作价值、职业发展等内容，帮助整个行业生态更深入地理解开发者，为他们提供更精准...
评论 1 条评论