本文是对《SRE：Google运维解密》一书的笔记，并结合自己工作中的一些思考。
什么是SRE
全称为Site Reliability Engineering，wiki为：
Site Reliability Engineering (SRE) is a discipline that incorporates aspects of software engineering and applies them to infrastructure and operations problems.[1] The main goals are to create scalable and highly reliable software systems. According to Ben Treynor, founder of Google’s Site Reliability Team, SRE is “what happens when a software engineer is tasked with what used to be called operations.”[2]
中文翻译为网站可靠性工程。这个工种是 Google 在 10 年前创造的，他们刚出了一本讲 SRE 的书，以下简称《SRE》。相应的，做这份工作的人叫 Site Reliability Engineer ——网站可靠性工程师，缩写也是 SRE。
SRE与DevOps的关系
DevOps是一种文化和方法，旨在改善开发团队和运维团队的协作和沟通；
SRE是DevOps的一种实现： SRE implements DevOps；
SRE 是Google版本的DevOps；
主要工作内容
- 可用性改进
- 延迟优化，性能优化，效率优化
- 变更管理
- 监控
- 紧急事务处理
- 容量规划与管理
指导思想
管理风险和目标
在快速发展的互联网企业中，存在一个主要矛盾就是迭代创新的速度与产品稳定程度之间的矛盾。在SRE模型中，我们选择正面面对这种矛盾，使用的工具是「错误预算」。
快速占领市场 or 保证产品稳定
没有银弹，都是妥协
怎么定义可用性？
时间的可用性
可用性=系统正常运行时间/（系统正常运行时间+停机时间）。举例来说，一个可用性目标为 99.99% 的系统最多在一年中停机 52.56 分钟，就可以达到预计的可用性目标。
合计可用性
可用性=成功请求数/总的请求数。例如，一个每天可用性目标为 99.99% 的系统，一天要接受2.5M个请求。它每天出现少于250个错误即可达到预计的可用性目标。
一般来说，任何软件系统都不应该一味地追求 100% 可靠。因为对最终用户来说，99.999% 和 100% 的可用性是没有实质区别的。从最终用户到服务器之间有很多中间系统（用户的笔记本电脑、家庭WiFi、网络提供商和输电线路等），这些系统综合起来可靠性要远低于 99.999%。所以，在 99.999% 和 100% 之间的区别基本上成为其他系统的噪声。
可靠性进一步提升的成本并不是线性增加的，可靠性的下一个改进可能比之前的改进成本增加100倍。
成本源自哪里？物力成本（副本）？机会成本？
需要考虑成本与收益的关系
如果 100% 不是一个正确的可靠性目标，那么多少才是呢？这其实并不是一个技术问题，而是一个产品问题。要回答这个问题，必须考虑以下几个方面：
- 基于用户的使用习惯，服务可靠性要达到什么程度用户才会满意？
- 如果这项服务的可靠程度不够，用户是否有其他的替代选择？
- 服务的可靠程度是否会影响用户对这项服务的使用模式？
- 是否收费？
错误预算
公司的商业部门或者产品部门必须建立起一个合理的可靠性目标。一旦建立，“错误预算”就是“1-可靠性目标”。如果一个服务的可靠性目标是99.99%，那么错误预算就是 0.01%。这意味着产品研发部门和SRE部门可以在这个范围内将这个预算用于新功能上线或者产品的创新等任何事情。
通过引进“错误预算”的概念，我们解决了研发团队和SRE团队之间的组织架构冲突。SRE团队的目标不再是 “零事故运行”，SRE团队和产品研发团队目标一致，都是在保障业务服务可靠性需求的同时尽可能地加快功能上线速度。这个改动虽小，意义却很大。一次“生产事故”不再是一件坏事，而仅仅是创新流程中一个不可避免的环节，两个团队通过协作共同管理它。
如果两个团队是同一个boss还好。如果不是呢？
团队之间的妥协
例如，假设一项服务的 SLO（下文会介绍SLO）是每季度 99.99% 的查询成功率。这就意味着，这项服务在给定季度的错误预算是 0.01%。如果某个问题导致我们这个季度产生了 0.002% 的故障，就相当于占用了这项服务 20% 的季度错误预算。
使用这个控制回路来调节发布的速度：只要系统符合 SLO，就可以继续发行新版本。如果频繁地违反 SLO 导致错误预算被耗尽，那么发布就会暂停，同时需要在系统测试和开发环节投入更多资源使得系统更有弹性，以使性能得到提升。
服务质量目标
三个名词：服务质量指标（SLI）、服务质量目标（SLO），以及服务质量协议（SLA）。这三项分别是指该服务最重要的一些基础指标、这些指标的预期值，以及当指标不符合预期时的应对计划。平常最常见的是 SLA，但在 Google 这本书里面 SLO 是最常见的。
Service Level Indicator
一句话，采集的指标必须真实反映本系统的质量，无论是响应时间还是请求量。
Service Level Objective
比较有意思的两点是：
- 可以对外承诺较低的 SLO（内部使用更高的）
- 不要超额完成 SLO，可以定期可控地关闭系统
Service Level Agreement
服务提供方和使用方达成共识，如果 SLA 没有满足的话，可能会有钱的惩罚。
监控系统
监控系统不应该依赖人来分析警报信息，而是应该由系统自动分析，仅当需要用户执行某种操作时，才需要通知用户。一个好的监控系统应该是抽象程度更高的，处理更加汇总的信息。一个监控系统应该只有三类输出：
- 紧急警报（alert）
意味着收到警报的用户需要立即执行某种操作，目标是解决某种已经发生的问题，或者是避免即将发生的问题。
- 工单（ticket）
意味着接受工单的用户应该执行某种操作，但是并非立即执行。系统并不能自动解决目前的情况，但是如果一个用户在几天内执行这项操作，系统不会受到任何影响。
- 日志（logging）
平时没有人需要关注日志信息，但是日志信息依然被收集起来以备调试和事后分析时使用。正确的做法是平时没人会去主动阅读日志，除非有特殊需要。
通过邮件报警是一种好方法吗？
用户反馈系统即 toC 公司的工单
应急事件处理
可靠性是MTTF（平均失败时间）和MTTR（平均恢复时间）的函数。评价一个团队将系统恢复到正常情况的最有效指标，就是MTTR。
任何需要人工操作的事情都只会延长恢复时间。一个可以自动恢复的系统即使有更多的故障发生，也要比事事都需要人工干预的系统可用性更高。
正确的废话
缩短人工介入时长的有效方法是维护一个「运维手册」，虽然不论多么完备的“运维手册”也无法替代人的创新思维，但是在巨大的时间压力和产品压力下，运维手册中记录的清晰调试步骤和分析方法对处理问题的人是不可或缺的。
人在紧张的情绪下能力至少减半，所以有一个预案很重要
变更管理
SRE的经验告诉我们，大概 70% 的生产事故由某种部署的变更而触发。变更管理的最佳实践是使用自动化来完成以下几个项目：
- 采用渐进式发布机制。
- 迅速而准确地检测到问题的发生。
- 当出现问题时，安全迅速地回退改动。
程序变更 or 配置变更
灰测上线
立体监控
借助镜像技术和配置的历史记录快速回滚
需求预测和容量规划
简单来说就是保障一个业务有足够的容量和冗余度去服务预测中的未来需求。几个关键步骤：
- 必须有一个准确的自然增长需求预测模型，需求预测的时间应该超过资源获取的时间。
自然增长（随着用户使用量上升，资源用量也上升）
- 规划中必须有准确的非自然增长的需求来源的统计。
非自然增长的因素（新功能的发布、商业推广，以及其他商业因素在内）。
- 必须有周期性压力测试，以便准确地将系统原始资源信息与业务容量对应起来。
借助于k8s集群可以有效地增加计算能力的容量
但是存储能力的容量至今无法很便捷的快速扩容
资源部署
增加现有容量经常需要启动新的实例甚至是整个集群，这通常需要大幅度修改现有的集群配置（配置文件、负载均衡、网络等），同时还要执行一系列测试，确保新上线的容量可以正确地服务用户。