C. Google SRE 实践

C. Google SRE 实践
    概述
        服务可靠度层级模型
            产品设计
            软件开发
            容量规划
            测试 + 发布
            事后总结和问题根源分析
            应急事件处理
            监控
    监控（10）
        组件
            接口
                时间序列信息操作语言
            服务端：基本上每个集群一个实例，不同实例之间的数据是互通的
                时间序列数据的存储
                规则计算：数据汇总
                报警
                监控系统的分片机制
                    收集层：运算和汇总，每个集群部署一个或者两个（避免单点故障）
                    全局层：计算层和展示层
            客户端：应用程序的监控埋点
        白盒测试：主要是应用自己收集自己的测试数据
        黑盒测试
        配置文件
            自动化测试工具，测试配置文件是否正确
            模板管理
                将某一个代码类库暴露的所有监控信息模板化
                    HTTP服务器类库
                    内存分配器类库
                    存储系统客户端类库
                    通用RPC框架
                    等等
                将单实例监控数据按级汇总到全局范围的模型
                等等
    应急事件处理（11 ～ 14）
        on - call 轮值
            生产系统中的维护需求响应时间，跟业务需要的可靠性有关
                直接面向最终用户的服务或者时间爱呢非常紧迫的服务：5分钟
                非敏感业务：30分钟
            主副on-call机制
                机制一：副on-call处理主on-call没有响应的事情
                机制二：主on-call处理生产系统紧急情况，副on-call负责处理其他非紧急的生产环境变更需求
            机制
                每12个小时最多只能处理2个紧急事件
        排查故障
            理论
                反复采用假设 - 排除 手段的过程
            步骤
                故障报告
                定位
                    合理判断一个问题的严重程度
                检查
                诊断
                测试/修复，有可能失败
                治愈
            注意点
                在遇到一个大型问题是，首先要做的是尽最大可能让系统恢复，而不是立即开始故障排查过程
                    比如说将用户流量从问题集群导向其他还在正常工作的集群
                    将流量抛弃以避免连锁过载问题
                    关闭系统的某些功能以降低负载
                    等等
        紧急事件响应
        紧急故障管理
            角色
                事故总控
                事务处理团队
                发言人
                规划负责人
            措施/机制
                划分优先级：控制影响范围，恢复服务，同时为根源调查保存现场
                事前准备：事先和所有事故处理参与者一起准备一套流程
                信任：充分相信每个事故参与者，分配职责后让他们自主行动
                反思：在事故处理过程中主意自己的情绪和精神状态。如果发现自己开始惊慌失措或者感到压力难以承受，应该寻求更多的帮助
                考虑替代方案：周期性地重新审视目前的情况，重新评估目前的工作是否应该继续执行，还是需要执行其他更重要或者更紧急的事情
                联系：平时不断地使用这项流程，知道习惯成自然
                换位思考：上次你是事故总控负责人吗？下次可以换一个职责试试。鼓励每个团队成员熟悉流程中的其他角色。
            什么时候对外宣布事故
                是否需要引入第二个团队来帮助处理问题？
                这次事故是否正在影响最终用户？
                集中分析一小时后，这个问题是否依然没有得到解决？
        运维压力
            量化运维压力：比如说 每天工单数量 < 5，每次轮值报警实践 < 3等
            降低报警数：一个异常可能触发多条报警，可以合理地分组报警信息
            极端情况下：停止支持某个服务，或者和研发团队共同分担
        机制
            保证每个工程师每个季度至少参与on-call一次，最好两次
            每年举办一次持续数天的全公司灾难恢复演习，针对理论行和实际性的灾难进行演练
    事后总结和问题根源分析（15，16）
        事后总结报告：对事不对人
            重点关注如何定位造成这次事件的根本问题，而不是职责某个人或者团队的错误或者不恰当的举动。
            报告评审
                关键的灾难数据是否已经被收集并保存起来了？
                本次事故的影响评估是否完整？
                造成事故的根源问题是否足够深入？
                文档中记录的任务优先级是否合理，能够及时解决了根源问题？
                这次事故处理的过程是否共享给了所有相关部门？
            建立事后总结文化
                本月最佳事后总结
                Google + 事后总结小组
                事后总结阅读俱乐部
                命运之轮：将某一篇事后总结的场景再现，一批工程师负责扮演这篇文档中提到的各种角色
                收集关于时候总结有效性的反馈
            挑战：投入产出比的质疑
                首先进行几轮完整的和成功的事后总结，证明它们的价值。
                确保对有效的书面总结提供奖励和庆祝。不光通过前面提到的公开渠道，也应该在团队或个人的绩效中体现
                鼓励公司高级管理层认可和参与其中。
        跟踪故障
            聚合：将多条报警聚合成一个单独的故障，或许能够有效解决这个问题
            加标签：对故障做标签（不同团队对标签要求不一样，比如说有些团队只需要标注到 network 就行了，有些团队可能需要更加细化，比如说network:switch 或者 network:cable）
            分析
                每周/每月/每季度 的故障数量和每次故障的报警数量
                对比团队/服务 以及按时间分析趋势和模式。跨团队的数据统计
                需要语义分析的技术：找到更广泛的问题，而不仅仅是简单的计数，比如说 寻找基础设施中造成故障最多的一部分。通过跨团队收集，可以从中找出系统性的问题。
    测试（17）
        测试类型
            传统测试
                单元测试
                集成测试
                    mock测试
                系统测试
                    冒烟测试：如果该测试不通过，那么其他更昂贵的测试可以不用进行了
                    性能测试：性能测试可以保证随着时间推移系统性能不会下降，或者资源要求不会升高
                    回归测试：保证之前的Bug不会重现
            生产测试
                配置测试：针对配置文件的测试
                压力测试
                    数据库容量满到什么程度，才会导致写请求失败
                    向某应用每秒发送多少个请求，将导致应用过载并导致请求处理失败。
                金丝雀测试：灰度发布
                    指数型升级部署：先部署1台，然后部署2台，然后部署4台等等
                    以0.1%的用户流量服务器容量开始，同时按24小时增长10倍推进。与此同时，还要考虑到变更部署的地域性分布。
        创建一个构建和测试环境
            区分项目的重要性， 确定测试的优先级
            良好的测试基础设施
        测试大规模使用的工具
        针对灾难的测试
        发布到生产环境
        集成
            多种类型的测试工具互相验证，有些类型只负责报错，不做修复
        生产环境探针
            已知的错误请求
            已知的正确请求，可以针对生产重放
            已知的正确请求，不可以针对生产重放
    其他
        容量规划（18 ～ 22）
        软件开发（23 ～ 25）
        数据的备份和恢复（26）
        产品发布（27）