SRE不是做底层硬件维护，而是负责各种服务的性能和稳定性。远离底层硬件，更多靠近软件基础架构层面，帮助企业客户打造强大的软件基础构架。
涉及的范围呢：代码管理和部署，配置管理，监控，应急响应，故障处理，压力测试，容灾等等

Devops的核心概念就是通过脚本实现自动化 -> Automation。现在有一个新的概念叫做NoOps，目的是实现自主运维，系统自动发现并解决问题，完全不再需要自动化脚本 -> Autonomy 。传统运维将死，不会写代码的都该失业了...

容量规划与实施：
要回答两个基本问题：要支持每秒 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不是做底层硬件维护，而是负责各种服务的性能和稳定性。远离底层硬件，更多靠近软件基础架构层面，帮助企业客户打造强大的软件基础构架。
涉及的范围呢：代码管理和部署，配置管理，监控，应急响应，故障处理，压力测试，容灾等等

Devops的核心概念就是通过脚本实现自动化 -> Automation。现在有一个新的概念叫做NoOps，目的是实现自主运维，系统自动发现并解决问题，完全不再需要自动化脚本 -> Autonomy 。传统运维将死，不会写代码的都该失业了...

容量规划与实施：
要回答两个基本问题：要支持每秒 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 不是运维，不过我其实不了解国内的运维具体是做什么的。