[转帖]SRE 是什么,不是什么

Posted jinanxiaolaohu

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了[转帖]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,这里列出两个供参考:


为了方便读者,我放一个截屏:

技术图片

Usenix 迄今已经举办了三次 SRE 会议(SREcon),从会议网站可以找到具体议程:

我估计读完以上这些材料,大家还是不明白 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 看,而是编写合适的监控与报警规则,让我们能快速找到故障根源。几个最基本的监控指标:

  1. 流量 traffic, eg. queries per second
  2. 延迟 latency
  3. 错误率 error ratio
  4. 资源使用率 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 是什么,不是什么的主要内容,如果未能解决你的问题,请参考以下文章

[转帖]到底什么是时间复杂度

DevOps和SRE有什么不同,每个意味着什么

[转帖]什么是“可转换可赎回优先股”?小米集团实例详解

SRE实战手册 带你搞定系统稳定性

[转帖]浅谈IOC--说清楚IOC是什么

SRE vs DevOps:是敌是友?