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，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 不是运维，不过我其实不了解国内的运维具体是做什么的。