从 2016 年底就开始阅读 《SRE Google 运维解密》 这本书，断断续续看得差不多。对于 Google 这种超大规模的互联网公司，他的运维体系在相当长的时间内都是领先业界很多，虽然说其公开的资料已经是 Google 几年前的事情了，但是其体系还是有很大的研究和实践价值。
这本书的重点是指导思想+具体实践，其中的关键词是分布式。众所周知，Google 在分布式系统方面的理论和实践相当先进，其分布式存储 GFS、分布式计算 MapReduce，分布式数据库 BigTable 也是被广泛地研究与学习。
现在开始进入正文，什么是 SRE ？
SRE 的全称是 Site Reliability Engineering，直译是“站点可靠性工程师”。他承担运维工作，但不是传统意义上的运维工程师。
SRE 的要务：
（1） 确保长期参与研发工作
（2） 在保障服务 SLO 的前提下最大化迭代速度
（3） 监控系统
（4） 应急事件处理
（5） 变更管理
（6） 需求预测和容量规划
（7） 资源部署
（8） 效率与性能
指导思想
SRE 其实是 DevOps 的一种具体实践。
Dev，致力于快速发布新特性；Ops，致力于生产系统的稳定可用。两者结合解决了开发和运维之间的矛盾，并且统一了团队的目标，即：在保障服务 SLO （服务等级目标） 的前提下最大化迭代速度。
下表描述了 DevOps 五大支柱和相对应的 SRE 实践：
| DevOps | SRE |
|---|---|
| 减少组织内的孤立 | 通过在整个技术栈使用同样的工具和技术来与开发者一同承担 |
| 接受失效是常态 | 使用一个公式在新版本发布和事故/失效之间做平衡 |
| 实现渐进式变更 | 实现渐进式变更 |
| 使用工具和自动化 | 鼓励“将今年的工作自动化掉”，最少化人工操作，以此将精力集中到能给系统带来长期价值的工作上 |
| 测量一切 | 坚信运维是一个软件问题。定义标准化的方法来测量可用性，运行时间，中断和苦力 |
1 风险管理
首先，我们需要考虑系统的可用性是什么。SRE 给出了如下两个公式：
（1） 可用性 = 系统正常运行时间 / （系统正常运行时间+停机时间）
（2） 可用性 = 成功请求数 / 总的请求数
用户的需求以及SLO确定的可用性是很高的，但是并不是意味着我们不能一味地追求最高的可用性，我们还需要考虑成本和迭代速度。如下：
可用性： 99.99% —-> 99.99(…n个9)%
成本： c1 —-> c1*b^n ~ inf
迭代速度： s1 —-> s1/b^n ~ 0
即：在可用性提高的同时，相应的系统成本就会显著提高、版本的迭代速度就会显著的下降。（这里的公式只是代表趋势，不能做实际的数值计算）
2 减少琐事
何为琐事？
琐事就是运维服务中手动性的，重复性的，可以被自动化的，战术性，没有持久价值的工作。而且，琐事与服务呈线性关系的增长。
手动性的：手动执行一些命令或者脚本。
重复性的：需要不停地反复做的事情。
可以被自动化的：如果计算机和人类一样可以完成某个任务。
战术性的：突然出现的应对式的工作，而非计划内安排的。如处理紧急警报。
没有持久价值：并非对服务带来永久性改进的工作。
与服务同步线性增长：如果工作所涉及的任务与服务的大小、流量或用户数量呈线性增长关系，那这项任务可能就属于琐事。
为什么要减少琐事？
SRE 的一个公开的目标是保持每个 SRE 的工作时间中运维工作（即琐事）的比例低于 50% 。SRE 至少是 50% 的时间花在工程项目上，以减少未来的琐事或者增加服务功能。增加服务功能包括提高可靠性、性能、或利用率，同时也会进一步消除琐事。
什么是工程项目工作？
工程项目工作是有创新性和创造性的，着重通过设计来解决问题。工程工作有助于团队在维持同等人员配备的情况下接手更大或者更多的服务。
典型的 SRE 活动分为如下几类：
软件工程 —— 编写或者修改代码，以及所有其他相关的设计和文档工作。包括：项目特性代码，自动化脚本、工具代码等。
系统工程 —— 配置、部署、更新等。
琐事 —— 与运维相关的重复性的、手工的劳动。
流程负担 —— 会议、总结、招聘、培训等。
3 自动化
自动化的价值
- 操作的一致性，避免不同人不同时候做同一项配置的不同操作。
- 平台性，错误集中化，降低对人的依赖与要求（随时、频繁、精确）。
- 修复速度更快，有时候能够有效地降低 MTTR 。
- 节省时间，一个自动化系统可以被多次、多人执行。避免用人类的鲜血、汗水和眼泪来养活机器。
另外，通过一下这个图我们可以大致决定我们的工作是否需要被自动化。
注：横轴表示任务执行的频率，纵轴表示每次任务执行时间，单元格表示 5 年的时间内，任务执行下来需要花费的时间。左下角的任务是花费时间最长的任务，是需要优先被自动化的任务。