如何成为 SRE?先了解这些真相和面试情况

阅读数:4248 2019 年 4 月 22 日

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

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

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

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

目录

  1. 定义
  2. 现实
  3. 我自己的路
  4. 你的道路
  5. 面试
  6. 资源

定义

那么,什么是 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,会做两件事:

  1. 找到离我最近的 SRE 组织(请记住,它可能不会被称为“SRE”!)。
  2. 弄清楚成为 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

收藏

评论

微博

发表评论

注册/登录 InfoQ 发表评论

最新评论

泽明 2019 年 04 月 22 日 19:30 0 回复
mark 作者信息 Alice Goldfuss Alice Goldfuss Alice Goldfuss is a systems punk currently helping GitHub run their cutting-edge container platform. She loves kernel crashes, memory design, and performance hacks. :rainbow: :floppy_disk: :octocat: Alice has consulted on some books (Docker: Up & Running, Effective DevOps, Site Reliability Engineering vol 2), presented at some conferences (SREcon, Velocity, Container Summit), and run some others (LISA17, DevOps Days Portland). You can follow her on Twitter :bird: (@alicegoldfuss), but you’ll probably regret it.
没有更多了