SRE google运维解密读书笔记

SRE google运维解密读书笔记

SRE:site reliablility engineering 站点可靠性工程师

系统运维的本质：人与计算机共同参与的一项系统工程。

1. SRE的职责

软件系统架构设计，运维流程不断优化，是的软件系统运行的更可靠，扩展性更好，能更有效的利用资源。

传统dev（开发）/ops（运维）分离的团队模型存在一些无法避免的问题：

1.直接成本

2.间接成本：工作目标，技术背景，沟通分歧。

2. SRE团队的两类工程师

50%-60%的标准软件工程师基本软件工程师标准+额外技能（linux细节，网络知识）

3. Devops 和SRE的区别和联系

devops 2008年开始流行起来。devops 是sre核心理念的普适版，可以用于更广范围内的组织结构，管理结构和人员安排。同时sre是devops模型的具体实践，带有一些特别的扩展。

4. SRE的核心方法论

确保长期关注研发工作：50%的精力放到项目研发上，运维工作限制在50%。在保障服务SLO（服务质量目标）的前提下最大化迭代速度。创新速度与产品稳定的矛盾。99.99% 和100%对用户而言没有实质意义的好处，此问题并不是一个技术问题，而是产品问题。灰度发布，AB测试。监控系统：自动自动分析报警，当需要用户执行某种操作时，才需要通知用户。紧急警报，工单，日志。应急事件处理：可靠性是MTTF(平均失败时间)和MTTR(平均恢复时间)的函数。关注日常运维手册维护编写。变更管理需求预测和容量规划：自然增长（用户，资源的增长） 非自然增长（新功能，新业务拓展）增长模型，压测模型对应起来。资源部署：变更管理和容量规划的产物。效率性能

5. SRE视角

硬件

典型的网络拓扑

园区-->数据中心--->集群----机柜排-->机柜--->物理服务器。

SDN网络技术：使用openflow标准协议。

系统管理软件管理物理服务器：任务实例与机器并没有一对一的固定对应关系，不能简单的用ip地址和端口来指代某一个具体的任务实例。存储网络分布式锁服务:paxos 协议提供分布式一致性监控与警报系统：中立第三方。以此对标服务目标。软件基础设施研发环境

6. 实施SRE的指导思想

拥抱风险管理风险度量服务的风险：计划外停机  可用性=系统正常运行时间/(系统正常运行时间+停机时间)，4个9，表示一年最多停机52.56分钟。请求成功率=成功请求数/总的请求数服务的风险容忍度

7. 关注的服务质量目标

服务质量指标：请求时延，错误率，吞吐量。可用性，存储持久性。指标标准化：汇总间隔，范围，度量频率。4个黄金指标：延迟，流量，错误，饱和度。长尾问题----直方图观察，百分位数。服务质量协议：重点描述未达到slo后有什么后果（退款，罚款）

8. 减少琐事

琐事：运维服务中手动性的，重复的，可以被自动化的，战术性，没有持久价值的工作。中断性工作。需要投入至少50%的精力在增加服务功能上，可靠性，性能，利用率。禁止退化为专门从事运维工作的组织。

9. 自动化系统的演进

手动-->自动--->自治自动化的价值：一致性，平台性，修复速度更快幂等的解决不一致情况

10. 发布工程

发布哲学：自服务模型，追求速度（测试通过即可发布），密闭性（容器，避免环境不一致），强调策略和流程，持续构建与部署（配置管理）。

11. 简单化，模块化

系统稳定性于灵活性的均衡。

12. 测试可靠性

传统测试：单元测试，集成测试，系统测试（冒烟测试--验证功能正确性，性能测试，回归测试--以前的bug不会重现，维护Buglist）生产测试：配置测试，压力测试（找出系统性能边界），金丝雀测试（灰度发布，放金丝雀到煤矿，其是否能安全返回）。

13. 容量规划考虑的几个因素

依赖关系：服务与服务之间存在什么依赖。性能指标：性能指标是依赖关系的粘合剂优先级：资源不足的情况下那些资源请求可以被牺牲掉。如主备模式，高可用是否必须。

14. 资源规划模型：

数据信息：压测或者历史数据获得。每个服务的需求预测数据：业务QPS资源供给：资源价格：优化的目标之一。意图配置信息求解器资源分配计划

15. 应对过载

进行好的容量规划增加资源进入降级模式：给每个用户设置限制客户端侧的节流机制：重试次数，重试间隔。消除有害流量

16 .管理经验

极化时间，避免不必要的上下文切换，尽量保持长片的静心工作模式。

附记：Devops实践落地

道-->法-->器-->术