简介
大型软件系统生命周期的绝大部分都处于“使用”阶段，而非“设计”或“实现”阶段。那么为什么我们却总是认为软件工程应该首要关注设计和实现呢？在《SRE：Google运维解密》中，Google SRE的关键成员解释了他们是如何对软件进行生命周期的整体性关注的，以及为什么这样做能够帮助Google成功地构建、部署、监控和运维世界上现存最大的软件系统。通过阅读《SRE：Google运维解密》，读者可以学习到Google工程师在提高系统部署规模、改进可靠性和资源利用效率方面的指导思想与具体实践——这些都是可以立即直接应用的宝贵经验。

任何一个想要创建、扩展大规模集成系统的人都应该阅读《SRE：Google运维解密》。《SRE：Google运维解密》针对如何构建一个可长期维护的系统提供了非常宝贵的实践经验。

详细内容
1、SRE介绍
四个方法论也给SRE指明一条可行的方法。手工操作和工单处理等传统运维工作不应该占用非常多的时间。运维SRE与开发团队认同50%的安全线的重要性，暂时性措施将过多的运维压力转移回开发团队，预留时间关注到开发工作上，改进流程或者报警等工作。

2、SRE视角

3、拥抱风险
共同定义一个基于SLO的错误预算，提供明确、客观的指标来决定服务能接受多少不可靠性。

4、服务质量目标
制订针对用户的服务质量目标，并且努力去达到这个质量目标。

5、减少琐事
50%的时间应该花在工程项目上，以减少未来的琐事和增加服务上。

6、分布式系统的监控
健康的监控和报警系统应该是非常简单、易于理解的。四个黄金指标是：延迟、流量、错误、饱和度。

7、自动化系统演进
以软件为基础的自动化是优于手动操作的，自动化的价值体现在一致性、快速性、可靠性。

8、发布工程
采用合适的工具、合理的自动化方式，以及合理的政策来发布。

9、简单化
在系统的灵活性和稳定性上维持平衡，软件的简单性是可靠性的前提。

10、基于时间序列进行有效报警
将测试和报警模型变成海量信息收集和中央化规则计算、统一分析和报警的模型。

11、on-call轮值
强调工程化手段来应对运维问题。

12、有效的故障排查手段
故障排查需要两个条件：通用的故障排查过程和发生故障的系统的足够了解。

13、紧急事件响应
平时不断的实践训练，建立和维护一套完备的训练和演习流程。

14、紧急事故管理
有效的紧急事故管理是控事故影响和迅速恢复运营的关键因素。

15、事后总结
事后总结是一次事故的书面记录，包括事故造成的影响，为缓解事故采取的措施，事故的根本原因，防止未来问题重现的后续任务。

16、跟踪故障
提高可靠性的唯一方法是建立一个基线，不断跟踪改变。收集监控系统发出的报警信息，同时提供标记、分组和数据分析功能。

17、测试可靠性
完善的测试可以提供足够的细节信息，帮助我们有效的预测某个系统未来的可靠度。

18、软件工程实践
团队大小不应该与用户服务规模成比例增长，以线性增长需要不断的进行自动化工具的研发，不同的优化工具、流程，消除一切其他运维工作相关的效率问题。

19、前端服务器的负载均衡
使用DNS和VIP进行负载均衡。

20、数据中心内部的负载均衡

21、应对过载
应对过载的一个选项就是服务降级，系统能够优雅的处理过载情况。

22、处理连锁故障
连续故障的测试：测试直到出现故障还要继续测试。

23、分布式来提高可靠性

24、分布式周期性任务系统
为提升cron的可靠性，将实际进程与物理机分开。

25、数据处理流水线
26、数据完整性-读写一致
数据完整性是手段，数据可用性是目标。

27、可靠的进行产品的大规模发布

28、迅速培养SRE加入on-call
系统性、累积性的学习方式，SRE应该积极主动的办法减少和限制被动性工作的产生。

29、处理中断性任务
为了限制干扰数量，应该减少上下文切换（工作类型、环境等改变）。

30、从运维过载中恢复
减少花在改进服务上的时间，服务的可扩展性和可靠性随之变差。

31、与其他团队的沟通协作
做任何高价值的事情都需要很多人协作。

32、参与模式的演进历程
SRE参与的时机越早，该服务的质量提升越快，最终质量也越好。

33、其他行业实践经验
在高可靠性的预期和快速变更与创新的追求之间寻求平衡。

34、结语
两种同等重要的工作：轮值工作，动手完成运维系统，观察和调整系统的弱点，理解如何能大规模扩展这些系统。另外需要时间反思与决策如何才能让这些系统更容易管理。

下载地址
链接: 立即下载 提取码: wtjy