指导思想
拥抱风险
管理风险
管理服务的可靠性很大程度上是通过管理风险来进行的。
需要将运维风险和业务风险结合。提高一项服务的可靠性，但不会超过该服务的可靠性
高昂的成本在于以下两个维度
- 基于时间的可用性：可用性 = 系统正常运行时间/(系统正常运行时间+停机时间)
- 合计可用性：可用性 = 成功请求数/总的请求数
服务的风险容忍度
消费者服务的风险容忍度
- 需要的可用性水平是什么
- 不同类型的失败对服务有不同的影响吗
- 我们如何使用服务成本来帮助在风险曲线上定位这个服务
- 有哪些其他重要的服务指标需要考虑
可用性目标
服务的可用性目标通常取决于它提供的功能 - 用户期望的服务水平
- 这项服务是否直接关系到收入
- 这是有偿还是免费的
- 市场有竞争对手，那竞争对手提供的服务水平如何
- 服务是针对消费者还是企业的
故障类型
根据业务对服务的停机时间的容忍程度有多高成本
- 构建再过一个9的系统，收益会增加多少
- 额外的首付是否能抵消为了达到这一可靠性水平付出的成本
基础设施服务的风险容忍度
不同于消费者服务，基础设施组件有多个客户，而且他们通常有很多不同的需求
关键战略：明确划分水平
质量服务目标
SLI(服务质量指标)
几个关键指标
- 请求延迟
- 错误率(请求处理失败的百分比)
- 系统吞吐量(每秒请求数量)
- 可用性(服务可用时间的百分比)
SLO(服务质量目标) Service Level Objectives
某个SLI值<=目标值或者SLI在某个目标范围SKA(服务质量协议)
指服务和用户之间的一个协议，描述没有达到SLO之后的后果
减少琐事
琐事
- 手动的
- 重复性的
- 可以被自动化的
- 战术性的
- 没有持久价值的
- 与服务同步线性增长的
SRE活动 - 软件工程：
编写修改代码，以及所有其他相关的设计和文档工作。如，编写自动化脚本，创造工具或者框架，增加可用性扩展和可靠性服务或修改基础设施代码使其更稳健 - 系统工程：
配置生产系统、修改现存配置或通过一种一次性工作产生持久的改进的方法来书写文档。例如，监控的部署和更新、负载均衡的配置、服务器配置和操作系统参数调整和负载均衡器的部署 - 琐事：
- 流程负担：
与运维服务不直接相关的行政工作。如任务系统的定期清理，工作总结，自我评价以及培训课程
分布式监控
- 监控：收集、处理、汇总并显示光宇某个系统的实时量化数据。如请求类型和错误数量和类型，以及处理用时，应用服务器的存活时间
- 白盒监控：依靠系统内部暴露的一些性能指标进行监控。包括日志分析，java虚拟机提供的监控接口或者一个列出内部统计数据的HTTP接口监控
- 黑盒监控：通过测试某种外部用户的系统行为进行监控
- 监控台页面：提供某个服务核心指标一览服务的应用程序。该程序提供过滤功能、选择功能。主要用以显示系统最重要的指标。
- 警报
- 根源问题
- 节点和机器
为什么需要监控
- 分析长期趋势
- 跨事件范围比较或者观察实验组和控制组之间的区别
- 报警
- 构建监控台页面：回答有关服务的一些基本问题。如四个黄金指标
- 临时性回溯分析：在线调试
四个黄金指标
- 延迟：服务器处理某个请求所需要的时间
- 流量：系统某个高层次的指标针对系统负载需求锁进行的度量
- 错误：请求失败的速率
- 饱和度：系统中目前最为受限的某种资源的某个具体指标的度量
简化监控系统
最能反映真实故障的规则越简单越好，可预测性强,非常可靠
不常用的数据收集、汇总以及警报配置应该定时删除
收集到的信息，但是没有暴露给控制台或者没有被任何警报规则使用的应该定时删除
减少误报
该规则是否能够检测到一个目前检测不到的、紧急的、有操作性的，并且即将发生或者已经发生的用户可见故障
是否可以忽略这条警报？什么情况下可能会导致用户忽略这条警报，如何避免？
这条警报是否确实显示了用户正在受到影响？是否存在用户没有收到影响也可以触发这条规则的情况。例如测试环境和系统维护状态下发出的警报是否被过滤掉
收到警报后是否需要进行某个操作，是否要立即执行。该操作是否可以被安全自动化，操作的效果是长期还是短期
是否也会有其他人收到相关的紧急警报，这个警报是否不必要
每个警报都应该是具体可操作的
每个紧急警报的回复都是需要某种智力分析过程，如果某个紧急警报只是需要一个固定的机械动作，那就不应该成文警报
每个紧急警报都应该是关于新问题的，不应该彼此重叠
自动化的价值
发布工程
发布工程的哲学
- 自服务模型
- 追求速度
- 密闭性
- 强调策略和流程
简单化
SRE管理系统：工作最终是在系统灵活性和稳定性上维持平衡
为了最小化意外复杂度，应该
- 在他们所复杂的系统音符意外复杂度，及时提出抗议
- 不断努力消除正在接受的和已经负责运维的系统的复杂度
软件的简单性是可靠性的前提
