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,但我的观点是这样的服务可能支持更大的面向客户的平台)。
一个需要 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 工作的一个好方法!
一般 / 多个主题
- Ops School (docs collection)
- SRE Weekly (newsletter)
- SREcon (conference videos)
- DevOpsDays (conference videos)
- Eli the Computer Guy (videos)
- Katacoda (interactive training)
- Sysadmin Casts (podcast)
- The Google SRE Book (book)
- The Geek stuff (blog)
- DevOps BootCamp (course)
- Coursera (courses)
Architecture
- The System Design Primer (guide)
- Distributed Systems (videos)
Cloud
- The Open Guide to Amazon Web Services (docs)
- Architecting Distributed Cloud Apps (videos)
Databases
- sqlzoo (interactive SQL training)
- Andy Pavlo’s courses (online course material)
- Readings in Database Systems (book)
- Intro to SQL: Querying and managing data (online course with videos)
- MongoDB University (courses)
Git
- Introduction to git (video)
- Ry’s Git Tutorial (book)
- Learn git branching (interactive tutorial)
- Git Immersion (interactive tutorial)
Networking
- How DNS Works (comic)
- Understanding IP Addressing: Everything You Ever Wanted To Know (whitepaper)
- Beej’s Guide to Network Programming (book)
Operating system internals
- Operating system basics (video)
- Unix system calls p1 (video)
- Unix system calls p2 (video)
- fork() and exec() (video)
- Wizard Zines (online zines, mostly free)
- NAND2Tetris (online course / book)
- Programming from the Ground Up (book)
- MIT’S Operating System Engineering (course)
- Crash Course Computer Science (videos)
- Intro to Operating Systems (videos)
- Operating Systems: Three Easy Pieces (book)
Programming
- Codecademy (interactive tutorials)
- Learn Python (interactive tutorials)
- Awesome Python (curated list of resources)
- Automate the Boring Stuff (book)
- Learn to Program (book / tutorial)
- Higher-Order Perl (book)
Puppet
- Puppet Learning VM (interactive tutorial)
Security
- The Big Blog Post of Information Security Training Materials (blog)
- Cyber Aces (courses)
- Over the Wire (capture the flag games)
Unix / Linux operations
- The Unix Workbench (book)
- Advanced bash scripting guide (book)
- Introduction to Linux (online course)
- Unix toolbox (cheatsheet)
- Command Line Challenge (games)
Vim
- VIM Adventures (interactive game)
免责声明:本文仅代表文章作者的个人观点,与本站无关。其原创性、真实性以及文中陈述文字和内容未经本站证实,对本文以及其中全部或者部分内容文字的真实性、完整性和原创性本站不作任何保证或承诺,请读者仅作参考,并自行核实相关内容。文章投诉邮箱:anhduc.ph@yahoo.com