SRE Goole运维解密
不能将碰运气当成战略. —— SRe俗语
SRE：Site Reliability Engineering;专注于整个软件系统的生命周期管理，goole将此职位称为站点可靠性工程师(SRE);
1.SRE是工程师，SRE使用计算机科学和软件工程手段来设计和研发大型、分布式计算机软件系统。
2.SRE的关注焦点在于可靠性。可靠性应该是任何产品设计中最基本的概念:任何一个系统如果没有人能够稳定的使用，就没有存在的意义。SRE专注于对其负责的软件系统架构设计、运维流程的不断优化，让大型软件系统运行的更可靠，扩展性更好，能更有效的利用资源。
3.SRE的主要工作是运维在分布式集群管理系统上运行的具体业务服务，不论是储存服务、web搜索服务、E-mail服务。
SRE职责：
可用性改进、延迟优化、性能优化、效率优化、变更管理、监控、紧急事务处理、容量规划与管理
SRE准则：
1.在每8-12小时的on-call轮值期间最多只处理两个紧急事件，事后撰写事后报告。
2.如果一个产品事故没有触发警报，事后总结意义更大，因为它可以揭示监控系统中的漏洞。
3.事故报告：事故发生、发现、解决的全过程、事故根本原因
产品预算- 研发团队与SRE团队
- 基于用户的使用习惯，服务可靠性要达到什么程度用户才会满意？
- 如果这项服务的可靠程度不够，用户是否有其它的替代选择？
- 服务的可靠程度是否会影响用户对这项服务的使用模式？
监控系统
监控系统是SRE团队监控服务质量和可用性的一个主要手段。
最普遍的和传统的报警策略是针对某个特定的情况或者监控值，一旦出现情况或者监控超过阀值就触发E-mai警报。但是这样的报警策略并不是非常有效：一个需要人工阅读邮件和分析警报来决定目前是否需要采取某种行动的系统从本质上就是错误的。监控系统不应该依赖人来分析警报信息，而是应该由系统自动分析，仅当需要用户执行某种操作时，才需要通知用户。
一个监控系统应该有三类输出：
- 紧急警报（意味着收到警报的用户需要立即执行某种操作，目标是解决某种已经发生的问题或者避免即将发生的问题）
- 工单（意味着接受工单的用户应该执行某种操作，但是并非立即执行。系统并不能自动解决目前的情况，但是如果一个用户在几天内执行这项操作，系统不会受到任何影响）
- 日志（平时没有人需要关注日志信息，但是日志信息依然被收集起来以备调试和事后分析时使用。正确的做法是平时没人会去主动阅读日志，除非有特殊需要）
应急事件处理
一个可以自动恢复的系统即使有更多的故障发生，也要比事事都需要人工干预的系统可用性更高。
通过事先预案并且将最佳方法记录在“运维手册”上通常可以使MTTR（平均恢复时间）降低3倍以上。
变更管理
大概70%的生产事故由某种部署的变更而触发。变更管理的最佳实践是使用自动化来完成以下几个项目：
- 采用渐进式发布机制
- 迅速而准确的检测到问题的发生
- 当出现问题时，安全迅速的退回改动
需求预测和容量规划
需求预测和容量规划就是保障一个业务有足够的容量和冗余度去服务预测中的未来需求。一个业务容量的规划，不仅要包含自然增长（随着用户使用量上升，资源用量也上升），也需要包括一些非自然增长的因素（新功能发布、商业推广、以及其它商业因素）
容量规划的步骤：
- 必须有一个准确的自然增长需求预测模型，需求预测的时间应该超过资源获取的时间
- 规划中必须有准确的非自然增长的需求来源的统计
- 必须有周期性压力测试，以便准确的将系统原始资源信息与业务容量对应起来
1.概览
物理服务器（machine）：
代表具体的硬件（有时候也代表一个VM虚拟机）
软件服务器（server）：
代表一个对外提供服务的软件系统。
2.分布式系统的监控
监控
收集、处理、汇总、并且显示关于某个系统的实时量化数据，例如请求的数量和类型，错误的数量和类型，以及处理用时，应用服务器的存活时间等。
白盒监控：
依靠系统内部暴露的一些性能指标进行监控。包括日志分析、Java虚拟机提供的监控接口、或者一个列出内部统计数据的HTTP接口进行监控。
黑盒监控：
通过测试某种外部用户可见的系统行为进行监控。
控制台页面：
提供某个服务核心指标一览服务的应用程序（一般基于Web）。该应用程序可能会提供过滤功能、选择功能等，但是最主要的功能是用来显示系统最重要的指标。该程序同时可以显示相应团队的一些信息，包括目前工单的数量、高优先级的Bug列表、目前on-call工程师和最近进行的生产发布等。
警报：
目标对象是某个人向发向某个系统地址的一个通知。目的地可以包括工单系统、E-mail地址，或者某个传呼机。
根源问题：
指系统中的某种缺陷。这个缺陷如果被修复，就可以保证这种问题不会再以同样的方式发生。某一故障情况可能同时具有多个根源问题，如有可能自动化程度不够，软件在异常输入下崩溃，以及对生成配置文件的脚本测试不足等。这里每一个因素都是一个根源问题，并且每一个都需要被修复。
监控系统指标
延迟：
服务处理某个请求所需要的时间。这里区分成功请求和失败请求很重要。
流量：
使用系统中的某个高层次的指标针对系统负载需求所进行的度量。对Web服务器来说，指标通常是每秒HTTP请求数量，同时可能按请求类型分类（静态请求与动态请求）。针对音频流媒体系统来说，这个指标可能是网络I/O速率，或者并发会话数量。针对键值对储存系统来说，指标可能是每秒交易数量，或每秒的读取操作数量。
错误：
请求失败的速率，要么是显示失败（例如HTTP500），要么是隐式失败（例如HTTP200回复中包含了错误内容），或者是策略原因导致的失败（例如如果要求回复在1s内发出，任何超过1s的请求就是失败请求）。当协议内部的错误代码无法表达全部失败情况时，可以利用其他信息，如内部协议，来跟踪一部分特定故障情况。监控方式也非常不一样：在负载均衡器上检测HTTP500请求可能足够抓住所有的完全失败的请求，但是只有端到端的系统才能检测到返回错误内容这种故障类型。
饱和度：
服务容量有多“满”。通常是系统中目前最为受限的某种资源的某个具体指标的度量。（在内存受限的系统中，即为内存；在I/O受限的系统中，即为I/O）。注意，很多系统在达到100%利用率之前性能会严重下降，增加一个利用率目标也是很重要的。
长尾问题
构建监控系统时，很多人都倾向于采用某种量化指标的平均值：延迟平均值、节点的平均CPU利用率、数据库容量的平均值等。由于CPU和数据库等利用率可能波动很大，根据其实际使用波动取其值。
设计原则
简化：
- 那些最能反映真实故障等规则应该越简单越好，可预测性强，非常可靠
- 那些不常用的数据收集、汇总，以及警报配置应该定时删除
- 收集到的信息，但是没有暴露给任何监控台，或者被任何警报规则使用的应该定时删除
SRE参与模型
- 系统的体系结构和跨服务依赖
- 指标的选择、度量和监控
- 紧急事件处理
- 容量规划
- 变更管理
- 性能：可用性、延迟和资源效率
事后总结
- 究竟发生了什么？
- 响应的有效程度
- 下次是否可以采用其它方案解决问题
- 如何确保这次故障不会再次发生
3.数据完整性：读写一致
大数据云计算应用都是优化以下5项的某种组合：在线时间、延迟、规模、创新速度和隐私。
在线时间：
经常也用“可用率”指代，代表某个服务可以被用户使用的时间比率。
延迟：
服务对用户的相应时间。
规模：
某个服务的用户数量，以及能够维持正常服务水平的最高负载
创新速度：
某个服务能够在合理成本下，为用户提供更好的服务的创新速度。
隐私：
这个名词的定义比较复杂。简单来说，用户删除服务中的数据后，数据必须在合理时间内真正被摧毁。
云计算环境下的需求
云计算环境引入的技术难点：
- 如果该环境使用了混合交易型和非交易型的备份和恢复方案，那么最终恢复的数据不一定是正确的
- 如果某个服务必须在不停机的情况下更新，那么不同版本的逻辑可能同时并行操作数据
- 如果所有其他有交互关系的服务不是同步更新的，那么在更新过程中各服务的不同版本之间可能会有多种组合，那么就更加增大了数据意外丢失和损坏发生的概率。
扩展API特性：
- 数据本地性和缓存
- 本地和全局的数据分布
- 强一致性/或最终一致性
- 数据持久性，备份于灾难恢复
数据完整性是手段，数据可用性是目标
维护数据完整性：
- 全量、增量以及相互竞争的备份和恢复机制
- 保留期 - 数据备份保存时间
- 确保数据恢复策略正常运行
交付一个恢复系统，而非备份系统
造成数据丢失的事故类型
根源问题：
某种无法恢复的用户数据丢失是由以下几个因素造成的：用户行为、管理员的错误、应用程序的Bug、基础设施中的问题、硬件故障和部署去的大型事故。
影响范围：
有些数据丢失是大规模的，同时影响很多实体。有些数据丢失是非常有针对性的，仅仅是一小部分用户的数据损坏或者丢失。
发生速度：
有些数据丢失失一瞬间造成的，而有些数据丢失是缓慢持续进行的。
4.产品发布
发布流程
轻量级：
占用很少的开发时间。
鲁棒性：
能够最大限度的避免简单的错误。
完整性：
完整的、一致的在各个环节内跟踪重要的细节问题。
可扩展性：
可以应用在很多简单的发布上，也可以用在复杂的发布过程中。
适应性：
可以适用于大多数常见的发布，以及可以适用全新的发布类型。
发布检查列表
检查列表可以用来减少失败，并且在多个职能部门之间保证一致性和完整性。
- 问题
- 待办事项
原则：
- 每个问题的重要性必须非常高，理想情况下，都必须有之前发布的经验教训来证明
- 每个指令必须非常具体、可行，开发者可以在合理的时间内完成
架构与依赖
依赖列表可以用来保证该服务的相关依赖都有足够的容量。
示例问题：
- 从用户到前端再到后端，请求流到顺序是什么样的？
- 是否存在不同延迟要求的请求类型？
特办事项：
- 将非用户请求与用户请求进行隔离
- 确认预计的请求数量。单个页面请求可能造成后端多个请求。
集成
- 给服务建立一个新的DNS
- 微服务配置负载均衡系统
- 为服务配置监控系统
容量规划
- 新功能通常会在发布之初代来临时的用量增长，在几天内会消除。这种尖峰式的负载或流量分布可能与稳定状态下有显著区别，之前的压力测试可能失效。
示例问题：
- 本次发布是否与新闻发布会、广告、博客文章或者其他类型的推广活动有关？
- 发布过程中和之后预计的流量和增速是多少？
- 是否已经获取到该服务需要的全部计算资源
故障模式
针对新服务进行系统性的故障模式分析可以确保发布时服务器的可靠性。
客户端行为
客户端的滥用行为很容易影响到服务器的稳定性。
示例问题：
- 该服务是否实现了自动保存/自动完成（完成框）/心跳等功能？
待办事项：
- 确保客户端在请求失败之后按指数型增加重试延时
- 保证在自动请求中实现随机延时抖动
流程与自动化
使用标准工具来自动化一些常见流程。
示例问题：
- 维持服务运行是否需要某些手动执行等流程？
待办事项：
- 将所有需要手动执行等流程文档化
- 将迁移到另外一个数据中新的流程化文档
- 将构建和发布新版本的流程自动化
开发流程
待办事项：
- 将所有的代码和配置文件都存放到版本控制系统中
- 为每个发布版本创建一个新的发布分支
外部依赖
示例问题：
- 这次发布依赖哪些第三方代码，数据、服务、或者事件？
- 是否有任何合作伙伴依赖于你的服务？发布时是否需要通知他们？
- 当我们或者第三方提供商无法在指定截止日期前完成工作时，会发生什么？
发布计划
在大型分布式系统中，很少有能够瞬间完成的事件。就算能够做到，为了保障可靠性，这样快速发布也并不一定是好主意。复杂的发布过程可能需要在不同子系统上单独启动各个功能，每个配置更新都可能需要数小时才能完成。在测试实例中可以工作的配置文件并不能够保障一次性被推送到生产实例上。有时候为了成功发布，可能要进行一个复杂的操作过程或者编写特殊的代码来保障流程的正确性。
待办事项：
- 为该服务发布制定一个发布计划，将其中每一项任务对应到具体的人
- 针对发布计划中的每一步分析危险性，并制定对应的备用方案
