《SRE Google 运维揭秘》读书笔记

[Shellbye]

SRE Site Reliability Engineering

前言
    在牛顿被世界正式认可为物理学家之前，他经常被称作是最后的炼金术士

第一部分 概览

第1章 介绍
        不能将碰运气当成战略    ——SRE俗语
    系统管理员模式
        Dev / Ops 分离带来的问题
            1. 直接成本
            2. 间接成本
    Google 的解决之道： SRE 
        SER 团队成员的特点
            a. 对重复性、手工性的操作有天然的排斥感
            b. 有足够的技术能力快速开发出软件系统以替代手工操作
    SRE 方法论
        确保长期关注研发工作
        在保障服务 SLO 的前提下最大化迭代速度
        监控系统
            紧急警报
            工单
            日志
        应急事件处理
        变更管理
            采用渐进式发布机制
            迅速而准确地检测到问题的发生
            当出现问题时，安全迅速地回退改动
        需求预测和容量规划
        资源部署
        效率与性能

第2章 Google 生产环境： SRE 视角
    硬件
        物理服务器 machine
        软件服务器 server
    管理物理服务器的系统管理软件
        管理物理服务器
        存储
        网络
    其他系统软件
        分布式锁服务
        监控与报警系统
    软件基础设施
    研发环境
    莎士比亚搜索： 一个示范服务
        用户请求的处理过程
        任务和数据的组织方式

第二部分 指导思想

第3章 拥抱风险
    管理风险
        冗余物理服务器 / 计算资源的成本
        机会成本
    度量服务的风险
        可用性 = 系统正常运行时间 / （ 系统正常运行时间 + 停机时间 ）
        可用性 = 成功请求书 / 总的请求数
    服务的风险容忍度
        辨别消费者服务的风险容忍度
            可用性指标
            故障的类型
            成本
            其他服务指标
        基础设施服务的风险容忍度
            可用性目标水平
            故障类型
            成本
            例子： 前端基础设施
    使用错误预算的目的
            软件对故障的容忍度
            测试
            发布频率
            金丝雀测试的持续时间和大小
        错误预算的构建过程
        好处

第4章 服务质量目标
    服务质量术语
        指标
        目标
        协议
    指标在实践中的应用
        运维人员和最终用户各关心什么
            用户可见的服务系统
            存储系统通常强调： 延迟、可用性和数据持久性
            大数据系统
            正确性
        指标的收集
        汇总
        指标的标准化
    目标在实践中的应用
        目标的定义
        目标的选择
            不要仅以目前的状态的为基础选择目标
            保持简单
            避免绝对值
            SLO 越少越好
            不要追求完美
        控制手段
        SLO 可以建立用户预期
            留出一定的安全区
            实际 SLO 也不要过高
    协议在实践中的应用

第5章 减少琐事
    琐事的定义
        琐事就是运维服务中手动性的，重复性的，可以被自动化的，战术性，没有持久价值的工作
        琐事的属性
            手动性
            重复性
            可以被自动化的
            战术性的
            没有持久价值
            与服务同步线性增长
    为什么琐事越少越好
    什么算作工程工作
    琐事繁多是不是一定不好
        已知的和重复性的工作有一种让人平静的功效
        琐事的有害原因
            职业停滞
            士气低落

第6章 分布式系统的监控
    术语定义
        监控
        白盒监控
        黑盒监控
        监控台页面
        警报
        根源问题
        节点或者机器
        推送
    为什么要监控
        分析长期趋势
        跨时间范围的比较，或者是观察实验组与控制组之间的区别
        报警
        构建监控台页面
        临时性的回溯分析
    对监控系统设置合理预期
    现象与原因
    黑盒监控与白盒监控
    4个黄金指标
        延迟
        流量
        错误
        饱和度
    关于长尾问题
    度量指标时采用合适的精度
    简化，直到不能在简化
    将上述理念整合起来
    监控系统的长期维护
        Bigtable SER： 警报过多的案例
        Gmail： 可预知的、可脚本化的人工干预
        长跑

第7章 Google 的自动化系统的演进
    自动化的价值
        一致性
        平台性
        修复速度更快
        行动速度更快
        节省时间
    自动化对 Google SRE 的价值
    自动化的应用案例
        Google SRE 的自动化使用案例
        自动化分类的层次结构
    让自己脱离工作： 自动化所有的东西
    舒缓疼痛： 将自动化应用到集群上线中
        使用 Prodtest 检测不一致情况
        幂等的解决不一致情况
        专业化倾向
        以服务为导向的集群上线流程
    Borg： 仓库规模计算机的诞生
    可靠性是最基本的功能
    建议

第8章 发布工程
    发布工程师的角色
    发布工程哲学
        自服务模型
        追求速度
        密闭性
        强调策略和流程
    持续构建与部署
        构建
        分支
        测试
        打包
        Rapid 系统
        部署
    配置管理
    小结
        不仅仅只对 Google 有用
        一开始就进行发布工程

第9章 简单化
    系统的稳定性与灵活性
    乏味是一种美德
    我绝对不放弃我的代码
    “负代码行” 作为一个指标
    最小 api
    模块化
    发布的简单化

第三部分 具体实践
    监控
        没有一套设计周全的监控体系就如同蒙着眼睛狂奔
    应急事件处理
    事后总结和问题根源分析
    测试
    容量规划
    软件研发
    产品设计

第10章 基于时间序列数据进行有效报警
    Borgmon 的起源
    应用软件的监控埋点
    监控指标的收集
    时间序列数据的存储
        标签与向量
    Borg 规则计算
    报警
    监控系统的分片机制
    黑盒监控
    配置文件的维护
    十年之后

第11章 on-call 轮值
    介绍
    on-call 工程师的一天
    on-call 工作平衡
        数量少保持平衡
        质量上保持平衡
        补贴措施
    安全感
    避免运维压力过大
        运维压力过大
        奸诈的敌人————运维压力不够

第12章 有效的故障排查手段
    理论
        针对某系统的一些观察结果和对该系统运行机制的理论认知，我们不断提出一个造成系统问题假设，进而针对这些假设进行测试和排除
        当你听到蹄子声音的时候，应该先想到马，而不是斑马
    实践
        故障报告
        定位
            先恢复服务，后调查
        检查
        诊断
            简化和缩略
            什么 那里 和 为什么
            最后一个修改
            有针对性地进行诊断
        测试和修复
    神奇的负面结果
        负面结果不应该被忽视，或者被轻视
        一项试验中出现的负面结果是确凿的
        工具和方法可能超越目前的试验，为未来的工作提供帮助
        公布负面结果有助于提升整个行业的数据驱动风气
        公布结果

        治愈
            系统复杂度
            在生产环境中重现某个问题也许是不可能的
    案例分析
    使故障排查更简单

第13章 紧急时间响应
    当系统出现问题时怎么办
    测试导致的紧急事故
        细节
        响应
        事后总结
            做的好的地方
            做的不好的地方
    变更部署带来的紧急事故
        细节
        事故响应
        事后总结
            我们从中学到的
    流程导致的严重事故
        细节
        灾难响应
        事后总结
    所有的问题都有解决方案
    向过去学习，而不是重复它
        为事故保留记录
        提出那些大的，甚至不可能的问题：假如……
        鼓励主动测试

第14章 紧急事故管理
    无流程管理的紧急事故
    对这次无流程管理的事故的剖析
        过于关注技术问题
        沟通不畅
        不请自来
    紧急事故的流程管理要素
        嵌套式职责分离
            事故总控
            事务处理团队
            发言人
            规划负责人
        控制中心
        实时事故状态文档
        明确公开的职责交流
    一次流程管理良好的事故
    什么时候对外宣布事故

第15章 事后总结： 从失败中学习
    Google 的事后总结哲学
    协作和知识共享
        1. 实时协作
        2. 开放的评论系统
        3. 邮件通知
    建立时候总结文化
        本月最佳事后总结
        Google+ 事后总结小组
        事后总结阅读俱乐部
        命运之轮
    小结以及不断优化

第16章 跟踪故障
    Escalator
    Outalator
        聚合
        加标签
        分析
        未预料到的好处

第17章 测试可靠性
        如果你还没有亲自试过某件东西，那么就假设它是坏的
    软件测试的类型
        传统测试
            单元测试
            集成测试
            系统测试
                冒烟测试
                性能测试
                回归测试
        生产测试
            配置测试
            压力测试
            金丝雀测试
    创造一个构建和测试环境
    大规模测试
        测试大规模使用的工具
        针对灾难的测试
        对速度的渴求
        发布到生产环境
        集成
        生产环境探针

第18章 SRE 部门中的软件工程实践
    为什么软件工程项目对 SRE 很重要
    Auxon 案例分析： 项目背景和要解决的问题
        传统的容量规划方法
            1. 收集对未来项目需求的预测
            2. 定制资源的采购、构建和分配计划
            3. 评审，并且批准这个计划
            4. 部署和配置对应的资源
            不可靠性
            耗时巨大，同时不够精确
        解决方案： 基于意图的容量规划
    基于意图的容量规划
        表达产品意图的先导条件
            依赖关系
            性能指标
            优先级
        Auxon 简介
        需求和实现： 成功和不足
            近似
        提升了解程度，推进采用率
            向大型团队推广内部软件工具需要以下几点
                1. 持续的和完整的推广方案
                2. 用户的拥护
                3. 资深工程师和管理层的赞助，因为他们看到了项目的实用潜力
            设立期望值
            识别合适的用户
            客户支持
            在合适的层次上进行设计
        团队内部组成
    在 SRE 团队中培养软件工程风气
        在 SRE 团队中建立起软件工程氛围： 招聘与开发时间
        如何做到这一点
            创建并宣扬一个明确的信息
            评估组织的能力
            发布并快速迭代
            不要降低标准

第19章 前端服务器的负载均衡
    有时候硬件并不能解决问题
    实用DNS进行负载均衡
    负载均衡：虚拟 IP

第20章 数据中心内部的负载均衡系统
    理想情况
    识别异常任务： 流速控制和坡脚鸭任务
        异常任务的简单应对办法： 流速控制
        一个可靠的识别异常任务的方法： 坡脚鸭状态
            健康
            拒绝连接
            坡脚鸭状态
    利用划分子集限制连接池大小
        选择合适的子集
        子集选择算法一： 随机选择
        子集选择算法二： 确定性算法
    负载均衡策略
        简单轮询算法
            子集过小
            请求处理成本不同
            物理服务器的差异
            无法预知的性能因素
                坏邻居
                任务重启
        最闲轮询策略
            活跃请求的数量不一定是后端容量的代表
            每个活跃客户端的请求不包括其他客户端发往同一个后端的请求
        加权轮询策略

第21章 应对过载
    QPS 陷阱
    给每个用户设置限制
    客户端侧的节流机制
        用户配额不足
    重要性
    资源利用率信号
        执行器负载均衡值
    处理过载错误
        决定何时重试
    连接造成的负载

第22章 处理连锁故障
        连锁故障是由于正循环反馈导致的不断扩大规模的故障
    连锁故障产生的原因和如何从设计上避免
        服务器过载
        资源耗尽
            CPU
            内存
                任务奔溃
                GC速率加快，CPU使用率上升——GC死亡循环
                缓存命中率下降
            线程
            文件描述符
            资源之间的相互依赖
        服务不可用
    防止软件服务过载
        队列管理
        流量抛弃和优雅降级
        重试
        请求延迟和截止时间
    慢启动和冷缓存
            慢启动
                必需的初始化过程
                运行时性能优化
            冷缓存
                上线一个新的集群
                在某个集群维护之后恢复服务状态
                重启
        保持调用栈永远向下
            避免同层通信
    连锁故障的触发条件
        进程奔溃
        进程更新
        新的发布
        自然增长
        计划中或计划外的不可用
            请求特征的变化
            资源限制
    连锁故障的测试
        测试直到出现故障，还要继续测试
        测试最常用的客户端
        测试非关键性后端
    解决连锁故障的立即步骤
        增加资源
        停止健康检查导致的任务死亡
        重启软件服务器
        丢弃流量
        进入降级模式
        消除批处理负载
        消除有害的流量

第23章 管理关键状态：利用分布式共识来提高可靠性
        分布式数据存储 BASE 
            Basically Available
            Soft State
            Eventually consistency
    使用共识系统的动力： 分布式协调系统失败
        案例1 脑裂问题
        案例2 需要人工干预的灾备切换
        案例3 有问题的小组成员算法
    分布式共识是如何工作的
        Paxos 概要： 协议示例
    分布式共识的系统架构模式
            分布式共识算法是很底层的、很原始的，
            真正是的分布式共识系统有用的是那些高级的系统组建，
            如数据存储、配置存储、队列、锁机制和领头人选举服务

            Zookeeper 是第一个获得一定行业影响力的开源共识系统

        可靠的复制状态机
            复制状态机 (replicated state machine, RSM) 是一个能在多个进程中用同样顺序执行同样的一组操作的系统，
            RSM 是一个有用的分布式系统基础组建，可以用来构建数据和配置存储，
            执行锁机制和领头人选举
        可靠的复制数据存储和配置存储
            可靠的复制数据存储是复制状态机的一个应用
        使用领头人选举机制实现高可用的处理系统
            分布式系统的领头人选举是跟分布式共识等价的问题
        分布式协调和锁服务
        可靠的分布式队列和消息传递
    分布式共识系统的性能问题
        复合式 Paxos ： 消息流过程详解
        应对大量的读操作
        法定租约
        分布式共识系统的性能与网络延迟
        快速 Paxos 协议 ： 性能优化
        稳定的领头人机制
        批处理
        磁盘访问
    分布式共识系统的部署
        副本的数量
        副本的位置
        容量规划和负载均衡
    对分布式共识系统的监控

第24章 分布式周期任务系统
以下略
第25章 分布式处理流水线
第26章 数据完整性： 读写一致
第27章 可靠的进行产品的大规模发布

第四部分 管理
第28章 迅速配有SRE 加入 on-call 
第29章 处理中断性任务
第30章 通过嵌入 SRE 的方式帮助团队从运维过载中恢复
第31章 SRE 与其他团队的沟通与协作
第32章 SRE 参与模式的演进历程

第五部分 结束语
第33章 其他行业的实践经验
第34章 结语

=====================================================================>