×

SRE的具体工作职责

标签: 暂无标签

SRE 是什么,不是什么









SRE,Site Reliability Engineering 的缩写。其中 site 是指 website,可以翻译为网站可靠性工程。这个工种是 Google 在 10 年前创造的,他们刚出了一本讲 SRE 的书,以下简称《SRE》。相应的,做这份工作的人叫 Site Reliability Engineer ——网站可靠性工程师,缩写也是 SRE。类比:Software Engineering 软件工程,Software Engineer 软件工程师,缩写 SWE。例句:我在 Google 的头两年是当 SRE,现在换成了 SWE。SRE 到底是干什么的
这基本上是我面试的每个应聘 SRE 职位的人都会问的问题,三句两句说不清楚,但愿读完本文之后您能有个大概的了解,也消除一些误解。SRE 是一个比较新的职位,目前只有少数业界领先的互联网公司才有这个 position(职位),包括 Google、Facebook、Twitter、Dropbox、Uber 等等,其中后面几家的 SRE 部门多是 Google 离职的 SRE 参与创建的。(辨析:前一句的两个 SRE 分别是什么的缩写?)
在 Google 招聘网站上可以搜到  SRE 的 job description,这里列出两个供参考:

  • about/careers/search#!t=jo&jid=84745001&
  • about/careers/search#!t=jo&jid=86645001&
为了方便读者,我放一个截屏:
Usenix 迄今已经举办了三次 SRE 会议(SREcon),从会议网站可以找到具体议程:
  • SREcon14 Program | USENIX
  • SREcon15 Program
  • SREcon16 Program
我估计读完以上这些材料,大家还是不明白 SRE 具体是做什么的。在遇到新事物的时候,人们习惯用旧事物作类比,“哦,SRE 不就是 Google 给 XXX 起的名字嘛。” 像番茄、胡椒、洋葱这些名字就是这么来的,番茄和茄子区别有多大不用我说吧。

SRE 具体工作内容
一说到 Software Developer,人们脑子里就能反映出编码、调试、测试、修 bug、刷知乎等具体工作内容。那 SRE 呢?

SRE 的首要工作任务是保证 SLA。SLA 是 service-level agreement 的缩写,没有贴切的中文翻译,我们继续用缩写好了。SLA 一般指的是系统的功能指标,比方说系统可用性(availability)达到 99.99%;对于 95% 的请求,响应延迟(latency)低于 200 毫秒等等。《SRE》第 4 章会具体讲 SLA、SLO、SLI 的含义及用法。
我个人把 SRE 工作内容分为以下几个方面:
  • 容量规划与实施

要回答两个基本问题:要支持每秒 X 个请求的流量,需要多少台机器?给你 Y 台机器,如何部署服务栈(serving stack)使其服务容量(capacity)最大,即每秒支持的请求数最多。serving stack 由很多服务程序(server)构成,各个 server 有各自的资源需求(每个进程用多少内存,多少CPU)。每个 server 有多个 replica,我们要算出各个 server 的 replica 的合理数目,让计算资源得到充分利用。SRE 开发了专门的工具来做这件事件,因为我们不想对全球多个数据中心都分别手算一遍。 server 的性能会随时间变化(新版本通常会变慢,因为加了更多的功能),我们要及时调整 replica 的数目。每个 server 的性能变化不一样,replica 的数目要“配平”。

  • 部署新的服务集群(serving cluster)

每年都有新的数据中心(Data Center)上线,也有旧的数据中心下线,那么我们的 serving stack 也会跟着迁移。“部署”不是去机房安装机器,实际上工作这么多年,我一次也没有见过跑我写的服务程序的机器。新的数据中心通常会有新一代的硬件,我们的容量规划工具要能适应多种的硬件类型(CPU 数目、内存大小)。
  • 冗余与容错

在 Google,我们有数据中心级别的容错,任何一个数据中心可以随时下线维护,对外服务不受影响。进一步说,我们的容量规划要做到允许两个数据中心同时下线。比方说某个数据中心正在例行下线维护,这时另外一个数据中心受突发事件影响必须立刻下线,那么我们的系统还要能正常提供服务。
  • 负载均衡

《SRE》第 19、20 章。
  • 上线新的服务(on-boarding service)
《SRE》第 32 章。

  • 监控(Monitoring)

不是一天到晚盯着 dashboard 看,而是编写合适的监控与报警规则,让我们能快速找到故障根源。几个最基本的监控指标:
  • 流量 traffic, eg. queries per second
  • 延迟 latency
  • 错误率 error ratio
  • 资源使用率 utilization

见《SRE》第 6 章。
  • 值班(on-call)

这其实是最少的工作,如果一个 SRE 团队有 8 个人,每人每次值班一周,那么平均 2 个月才轮到一次,占 1/8 的工作量。值班的时候,如果没有突发事件,还是该干嘛干嘛。而且 Google SRE 是全球团队,不用值夜班,到了下午把工作交接给地球另一边的同事就行了。见《SRE》第 11 章。
  • 救火(Firefighting)

这是 SRE 最刺激的工作内容,见《SRE》第 12~15 章。
SRE 不是什么
SRE 不在数据中心上班,不搬机器。
SRE 不是系统管理员,不会帮你重置用户密码,也不安装操作系统或升级安全补丁。
SRE 不是测试工程师,不管持续集成和发布新版本。
SRE 不是运维,不过我其实不了解国内的运维具体是做什么的。







上一篇:SRE谷歌运维解密目录
下一篇:SRE和微服务架构如何适配
admin

写了 856 篇文章,拥有财富 28883,被 26 人关注

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

成为第一个吐槽的人

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