DevOps是研发推动的DevOps，SRE是运维推动的DevOps。

不要依赖工程师和管理人员的个人素质， 而应该尽可能的做好预案的演练，设置多层次的纵深防御和响应体系， 依靠制度与体系，构建高可用的服务架构。

SRE 的成员由纯开发和运维开发组成，从事开发工作的时间应该不小于 50%。这个需要由领导出面对工作进行协调，以保证这一比例。长远目标应该是消除一切运维工作。

在保证服务SLO的前提下最大化迭代速度。最主要的矛盾是迭代创新的速度与产品稳定程度之间的矛盾。在SRE模型中，我们正面对这些矛盾，使用的工具是错误预算

计算“错误预算”： • 基于用户习惯，达到多少用户才会满意；• 用户是否有其他替代选择；• 可靠性是否会影响用户的使用模式

用户通常不会注意到一项服务在高可靠性和极端可靠性之间的差别，因为用户体验主要是受不可靠组件主导。计算增加可用性目标后带来的成本增加和预期收益

服务质量指标 SLI（indicator）：量化指标，包括延迟、吞吐量、错误率、可用性、持久性等；• 指标不宜过多，应关注用户的真实需求；• 常用的指标度量应该尽量标准化（如时间间隔、频率等）

计划内停机：当某个服务在一定周期内超过了预期的 SLO 后，可以故意的令其停机，使其维持在略高于 SLO的状态。这样可以强迫其他服务不要过于依赖该服务的稳定性。

变更管理：经验来讲，70%的生产事故来源于变更。变更管理的最佳事件使用自动化来完成以下项目：◦ 渐进式发布机制。 - 减少受影响面积◦ 迅速而准确的检测到问题的发生。 - 减少故障时间◦ 出现问题时可以自动的快速回滚。 - 减少故障时间

大部分指标都应该以“分布”，而不是平均值来定义。监控系统的 4 个黄金指标：延迟、流量、错误和饱和度

监控中的紧急警报要尽可能的少，一切不需要智力解决的问题都不应该成为紧急。监控系统要尽可能的简单，“自动化”虽然可能减少工作量，但是会隐藏真正的问题，所以不要滥用。监控系统应该能自己分析报警信息，然后自动决策，  或者是给出合理的建议，让人去选择。不过有好些情况还是需要人工干预的。  通过事先预案并且将最佳方法记录在”运维手册“中，这样可以有效的降低MTTR。运维手册会不断的完善。也方便对新人做培训

过大的压力会导致人们倾向于采取直觉性的行动，而不是深思熟虑的理性行为。最理想的方法论是这样的：在有足够数据支撑的时候按步骤解决问题，同时不停地审视和验证目前所有的假设。环境过于稳定导致 SRE 压力不够也是一个需要注意和预防的问题。理解一个系统应该如何工作并不能使人成为专家。只能靠调查系统为何不能正常工作才行。运维人员需要跟进每一个问题，把问题的原委搞清楚才能得到成长和改进

on-call 升级：1. 清晰的问题升级路线；2. 清晰定义的应急事件处理步骤；3. 不指责、对事不对人的文化氛围

在进行故障模拟测试前，应先测试回滚机制（幂等）；在事故处理中，让每个人清楚自己的职责是非常重要的。明晰职责反而能够使每个人可以更独立自主的解决问题，因为他们不用怀疑和担心他们的同事都在干什么。

测试 ： • 单元测试；• 集成测试（主要依赖 mock） • 系统测试（联调：冒烟测试、性能测试、回归测试）• 生产测试（黑盒测试、金丝雀测试）
需求不明确或技术方案不明确时，其实反而更助于模块化的开发。因为模块化使得未来可能的替换更为简单。

跛脚鸭状态（优雅退出）：当一个服务仍在工作，但因为负载等原因决定不再接受更多的请求时，称之为跛脚鸭状态。此时应广播给所有的客户端，不要再继续发送请求。

为服务端计算一个子集，然后发送给客户端，作为可以链接的服务端列表。每个（或每一轮）客户端都会拿到完全不同的服务端子集，当第一个服务端无法连接时，就会连接第二个，以此类推。因为每个客户端拿到的列表都不一样，就实现了很好的客户端负载均衡。

地漏效应（sinkhole effect）：针对 lb 中的最闲轮询，如果一个服务目前不健康，错误返回的速度可能会非常快，导致 lb 认为其负载更低反而给其更多的流量。

链式服务调用，因为服务栈非常深，所以应该在每一层进行重试，一旦重试失败，则返回客户端“已过载，勿重试”。连锁故障（cascade）是由于正反馈循环导致的不断扩大规模的故障。优雅降级（graceful degradation）降低回复质量来大幅减少所需的计算量或所需的计算时间。

容量规划必须有几个必要的步骤:◦ 必须有一个准确的自然增长需求预测模型，需求预测的时间应该超过资源获取的时间。◦ 规划中必须有准确的非自然增长的需求来源的统计◦ 必须有周期性压力测试，以便准确地将系统原始资源信息与业务容量对应起来。

压测时，应该一直测到服务崩溃为止。一个合格的服务，应该在过载时针对多余的负载返回错误或者降级，而不应该降低它成功处理的速率。同时也应该测试一个服务从过载情况下如何恢复。

一个业务总资源使用情况由以下几个因素：◦ 用户流量 ◦ 可用容量 ◦ 资源利用率。SRE可以通过需求模型的预测和监控数据来优化资源的使用率。SRE可以通过设置预期的延迟目标和维护足够的容量解决。

惊群效应（thundering herd）：比如大量定时任务在一个时间点启动，造成机器超载；对大数据进行周期性的或者是持续性的变形操作程序通常被称为简单流水线

谷歌的研究表明：最常见的用户可见数据丢失场景是由于数据删除和软件 bug 造成的引用完整性问题。数据删除逻辑的 bug 非常常见，以至于快速复原一定时间内的删除操作是针对永久性数据丢失的第一道防线。

坏苹果理论：认为整个系统大体都是好的，只要摘除其中的坏苹果，系统就将会一直运行良好。但实际上，在任何一个交互关系错综复杂的系统中，错误是不可避免的。

结构化和理性的决策：• 某项决策的基本方向是事先决定的，而不是事后得出的• 决策时考虑的信息源是清楚的• 任何假设都应该明确说明• 数据驱动

为了避免用户可见的数据质量下降，以及在无法恢复之前检测到低级的数据损坏以及数据丢失，我们需要一整套带外（out-of-band）检查和修复系统来处理数据存储内部和相互之间的数据问题。

SRE是指Site  Reliability  Engineer  (网站可靠性工程师)。他是软件工程师和系统管理员的结合，一个SRE工程师基本上需要掌握很多知识：算法，数据结构，编程能力，网络编程，分布式系统，可扩展架构，故障排除。

SRE成员的特点：◦ 对重复性、手工性的操作有天然的排斥感◦ 有足够的技术能力快速开发软件以代替手工操作

SRE通过设计、构建自动化的工具来取代人工操作。  通过操作代码来管理机器，而不是人直接去管理机器。

DevOps是研发推动的DevOps，SRE是运维推动的DevOps。

不要依赖工程师和管理人员的个人素质， 而应该尽可能的做好预案的演练，设置多层次的纵深防御和响应体系， 依靠制度与体系，构建高可用的服务架构。

SRE 的成员由纯开发和运维开发组成，从事开发工作的时间应该不小于 50%。这个需要由领导出面对工作进行协调，以保证这一比例。长远目标应该是消除一切运维工作。

在保证服务SLO的前提下最大化迭代速度。最主要的矛盾是迭代创新的速度与产品稳定程度之间的矛盾。在SRE模型中，我们正面对这些矛盾，使用的工具是错误预算

计算“错误预算”： • 基于用户习惯，达到多少用户才会满意；• 用户是否有其他替代选择；• 可靠性是否会影响用户的使用模式

用户通常不会注意到一项服务在高可靠性和极端可靠性之间的差别，因为用户体验主要是受不可靠组件主导。计算增加可用性目标后带来的成本增加和预期收益

服务质量指标 SLI（indicator）：量化指标，包括延迟、吞吐量、错误率、可用性、持久性等；• 指标不宜过多，应关注用户的真实需求；• 常用的指标度量应该尽量标准化（如时间间隔、频率等）

计划内停机：当某个服务在一定周期内超过了预期的 SLO 后，可以故意的令其停机，使其维持在略高于 SLO的状态。这样可以强迫其他服务不要过于依赖该服务的稳定性。

变更管理：经验来讲，70%的生产事故来源于变更。变更管理的最佳事件使用自动化来完成以下项目：◦ 渐进式发布机制。 - 减少受影响面积◦ 迅速而准确的检测到问题的发生。 - 减少故障时间◦ 出现问题时可以自动的快速回滚。 - 减少故障时间

大部分指标都应该以“分布”，而不是平均值来定义。监控系统的 4 个黄金指标：延迟、流量、错误和饱和度

监控中的紧急警报要尽可能的少，一切不需要智力解决的问题都不应该成为紧急。监控系统要尽可能的简单，“自动化”虽然可能减少工作量，但是会隐藏真正的问题，所以不要滥用。监控系统应该能自己分析报警信息，然后自动决策，  或者是给出合理的建议，让人去选择。不过有好些情况还是需要人工干预的。  通过事先预案并且将最佳方法记录在”运维手册“中，这样可以有效的降低MTTR。运维手册会不断的完善。也方便对新人做培训

过大的压力会导致人们倾向于采取直觉性的行动，而不是深思熟虑的理性行为。最理想的方法论是这样的：在有足够数据支撑的时候按步骤解决问题，同时不停地审视和验证目前所有的假设。环境过于稳定导致 SRE 压力不够也是一个需要注意和预防的问题。理解一个系统应该如何工作并不能使人成为专家。只能靠调查系统为何不能正常工作才行。运维人员需要跟进每一个问题，把问题的原委搞清楚才能得到成长和改进

on-call 升级：1. 清晰的问题升级路线；2. 清晰定义的应急事件处理步骤；3. 不指责、对事不对人的文化氛围

在进行故障模拟测试前，应先测试回滚机制（幂等）；在事故处理中，让每个人清楚自己的职责是非常重要的。明晰职责反而能够使每个人可以更独立自主的解决问题，因为他们不用怀疑和担心他们的同事都在干什么。

测试 ： • 单元测试；• 集成测试（主要依赖 mock） • 系统测试（联调：冒烟测试、性能测试、回归测试）• 生产测试（黑盒测试、金丝雀测试）
需求不明确或技术方案不明确时，其实反而更助于模块化的开发。因为模块化使得未来可能的替换更为简单。

跛脚鸭状态（优雅退出）：当一个服务仍在工作，但因为负载等原因决定不再接受更多的请求时，称之为跛脚鸭状态。此时应广播给所有的客户端，不要再继续发送请求。

为服务端计算一个子集，然后发送给客户端，作为可以链接的服务端列表。每个（或每一轮）客户端都会拿到完全不同的服务端子集，当第一个服务端无法连接时，就会连接第二个，以此类推。因为每个客户端拿到的列表都不一样，就实现了很好的客户端负载均衡。

地漏效应（sinkhole effect）：针对 lb 中的最闲轮询，如果一个服务目前不健康，错误返回的速度可能会非常快，导致 lb 认为其负载更低反而给其更多的流量。

链式服务调用，因为服务栈非常深，所以应该在每一层进行重试，一旦重试失败，则返回客户端“已过载，勿重试”。连锁故障（cascade）是由于正反馈循环导致的不断扩大规模的故障。优雅降级（graceful degradation）降低回复质量来大幅减少所需的计算量或所需的计算时间。

容量规划必须有几个必要的步骤:◦ 必须有一个准确的自然增长需求预测模型，需求预测的时间应该超过资源获取的时间。◦ 规划中必须有准确的非自然增长的需求来源的统计◦ 必须有周期性压力测试，以便准确地将系统原始资源信息与业务容量对应起来。

压测时，应该一直测到服务崩溃为止。一个合格的服务，应该在过载时针对多余的负载返回错误或者降级，而不应该降低它成功处理的速率。同时也应该测试一个服务从过载情况下如何恢复。

一个业务总资源使用情况由以下几个因素：◦ 用户流量 ◦ 可用容量 ◦ 资源利用率。SRE可以通过需求模型的预测和监控数据来优化资源的使用率。SRE可以通过设置预期的延迟目标和维护足够的容量解决。

惊群效应（thundering herd）：比如大量定时任务在一个时间点启动，造成机器超载；对大数据进行周期性的或者是持续性的变形操作程序通常被称为简单流水线

谷歌的研究表明：最常见的用户可见数据丢失场景是由于数据删除和软件 bug 造成的引用完整性问题。数据删除逻辑的 bug 非常常见，以至于快速复原一定时间内的删除操作是针对永久性数据丢失的第一道防线。

坏苹果理论：认为整个系统大体都是好的，只要摘除其中的坏苹果，系统就将会一直运行良好。但实际上，在任何一个交互关系错综复杂的系统中，错误是不可避免的。

结构化和理性的决策：• 某项决策的基本方向是事先决定的，而不是事后得出的• 决策时考虑的信息源是清楚的• 任何假设都应该明确说明• 数据驱动

为了避免用户可见的数据质量下降，以及在无法恢复之前检测到低级的数据损坏以及数据丢失，我们需要一整套带外（out-of-band）检查和修复系统来处理数据存储内部和相互之间的数据问题。

SRE是指Site  Reliability  Engineer  (网站可靠性工程师)。他是软件工程师和系统管理员的结合，一个SRE工程师基本上需要掌握很多知识：算法，数据结构，编程能力，网络编程，分布式系统，可扩展架构，故障排除。

SRE成员的特点：◦ 对重复性、手工性的操作有天然的排斥感◦ 有足够的技术能力快速开发软件以代替手工操作

SRE通过设计、构建自动化的工具来取代人工操作。  通过操作代码来管理机器，而不是人直接去管理机器。