×

扫描二维码登录本站

QQ登录

只需一步,快速开始

标签: 暂无标签

                                                       


                       

                                               

                               
作者 | 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 有很多道路,你需要学习系统、运维、数据库、网络等等多项技能,不要停止学习!





上一篇:SRE职位机会 AfterShip
下一篇:SRE概念快速普及
admin

写了 833 篇文章,拥有财富 28305,被 26 人关注

您需要登录后才可以回帖 登录 | 立即注册
B Color Link Quote Code Smilies

成为第一个吐槽的人

最新100贴|论坛版块|ITIL先锋论坛 |粤ICP备11099876号|网站地图
Powered by Discuz! X3.4 Licensed  © 2001-2017 Comsenz Inc.
返回顶部