《Google SRE》读后感

注：这是去年国庆时的一篇读书笔记，最近线上故障频繁，从新读了下这篇读书笔记，以为《Google SRE》很是棒，遂从简书再搬家到博客园，但愿你们受益。个人简书地址：daoqidelv

国庆长假，出门太堵，遂待在魔都，花了三天时间将《Google SRE》中文版翻了一遍，好书一本，不论是开发人员、运维人员仍是架构师，均可以读一读，受益不浅的。

鉴于本身是作开发的，因此对于运维相关流程化的内容没有涉猎。不过这部份内容对于运维leader应当是大有裨益的。

SRE是个全能手，DevOps的实践者

SRE全称：Site Reliability Engineering，翻译过来就是：站点可靠性工程师。SRE的职责确保站点的可用，为了达到这个目的，他须要对站点涉及的系统、组件熟悉，须要关注生产运行时的状态，为此，他须要有不少工具和系统支撑其完成上述工做，好比自动化发布系统，监控系统，日志系统，服务器资源分配和编排等，这些工具须要他们本身完成开发和维护。

SRE是一个综合素质很高的全能手，须要懂服务器基础架构、操做系统、网络、中间件容器、经常使用编程语言、全局的架构意识、很是强的问题分析能力、极高的抗压能力（以便沉着高效地排障），他们还须要懂性能调优理论...

SRE的工做是Develop+Operate的结合，SRE是DevOps的实践者，他们的工做内容和职责和传统运维工程师差很少：发布、部署、监控、排障，目标一致。可是SRE的手段更加自动化，更高效，这种高效来源于自动化工具、监控工具的支撑，更由于其做为这些工具的开发者，不断优化和调整，使整个工具箱使起来更加驾轻就熟，这也是DevOps的魅力所在。

分布式环境运维大不一样于传统运维

个人理解：在分布式环境下，系统的复杂度增大、维护目标增多，按照传统的手工或者半自动维护来作，是不行的。因此，须要转变思路：

事务性的工做工具化。好比：版本发布、服务器监控；

让系统自反馈。完善的监控告警机制，完善的日志记录和分析体制，可视化系统的健康状态，使得系统变得可追踪和调校；

分布式策略应对巨量运维对象。负载均衡、流控、数据完整性、批处理的变得不同，须要从新设计和实践。同时，更要重视连锁式故障。

分布式系统的核心——分布式共识

分布式共识问题是指“在不稳定的通讯环境下一组进程之间对某项事情达成一致的问题”。

分布式共识系统能够用来解决：领头人选举、关键共享状态、分布式锁等问题。或者绝对点，全部的分布式问题都应当考虑到分布式共识的问题。

分布式共识的理论基础和实现都不是很好理解，抽时间搞清楚是大有裨益的，这里罗列一下几个关键词：

拜占庭问题

可复制状态机

Paxos算法

Zookeeper

Chubby

监控很重要！很重要！很重要！

监控是SRE眼睛的延伸。

监控系统应当解决两个问题：现象（什么东西出故障了？），缘由（为何出故障？）

现象—— 用户可感知的现象，好比：登录不了、支付订单变慢；

缘由—— 形成现象的潜在因素，可能只是中间因素或者相关因素，并不是根本缘由，根本缘由须要SRE介入分析并肯定。好比：login 服务CPU超过警惕值，订单服务器的CLOSE_WAIT状态的TCP连接数猛增等等。

四个黄金指标：时延、流量（PV）、错误、饱和度（服务器资源使用状况）。前三个是对服务进行监控，后一个是对服务器进行监控，固然也能够包含容器的状态监控，好比线程池、GC等。

几条箴言：

指标简化到不能再简化

关注长尾现象，要时延分布，而不是平均时延

慎重发出紧急警报，预防“狼来了”现象，紧急警报都是课操做的，且不能惯性得出结论的问题

警报不要重复，避免浪费SRE的注意力

排障

定位故障点。合理断定问题的严重程度，尝试尽快恢复服务或者缓解问题。

借助监控工具和日志工具检查系统或者服务状态。服务时延和错误率、系统资源使用状态状况、日志统计分析

逐层检查和分解问题，解析问题现象，不断假设/验证地进行诊断，找到根本缘由

发布

自动化发布应看成为基础设施，第一优先级建设，他的重要性和自动化测试同样。以前参加的“软件工程的精益化管理”课程实验中，实践证实了自动化工具的威力很大，可以明显提高整个团队的生产力。

关于自动化发布的内容和分享网上很是多，并且国内各大互联公司分享出来的材料也是汗牛充栋，用到是能够学习。

反思 and 总结

这两个优势对于SRE非常重要，反思使得SRE从失败中学习教训，总结使SRE从时间中得到经验，我的和团队须要学习和践行这种精神，可是对事不对人。

Google的作法是：时过后总结机制。

避免指责，提供建设性意见，充满正能量

过后总结报告须要评审，避免低质量的过后总结带来负面影响

google的过后总结模板

追本溯源、怀疑一切

SRE是天生怀疑论者，怀疑一切，眼见为实，追本溯源是本性，感受本身的性格还蛮适合的~

拥抱风险

传统运维是厌恶风险的，可是开发和产品却更关注变化速度，他们都但愿迭代速度越快越好，可是这回给系统运行带来风险，因此这天生是矛盾。

为了解决风险和变化的矛盾，google提出了SLI-->SLO-->SLA的机制。

SLI——服务质量指标，如：延时、吞吐量、错误率、可用性等

SLO——服务质量目标，服务的某个SLI的目标值，或者目标范围。好比：SLI<=目标值，min=

SLA——服务质量协议（Agreement），服务（SRE）和用户（开发、产品）之间的一个明确的、或者不明确的协议，描述了在达到或者没有达到SLO以后的后果。或者能够转化为先行的KPI，好比系统可用性99.99%等。

开发和运维针对某个系统协商好一个SLA后，你们有一个量化的指标，一旦出现冲突时，算一下，看看是否违反SLA，若是违反，那么就升级走流程。这样既灵活，也有章可循。若是开发团队牛逼，代码质量高或者运气好，你能够迭代快，反之你须要慢点来，间接地，你们都对线上系统负责了。

反直觉的真理

一、不要承诺你的系统100%可靠。

由于这样会要其余人过度依赖于你，一旦你出问题，那么将成为众矢之的，相反的，你应当对本身的系统了如指掌，好比能承受的压力，可用性目标，一些明显的坑，一些不支持的属性等，广而告之。

二、有意识地破坏你的系统

不一样于演练，而是真实生产系统，在可控范围内，人为制造故障，而后在有人值守的状况下，找到系统的短板和问题。这样等到真正的故障来临时，能够有章可循，快速解决问题。

主动暴露本身的不足好于别人忽然揭发你，固然更重要的是要及时纠正不足。

 线上排障实践

如何快速处理线上故障

线上故障处理——大量异常堆栈日志输出影响服务可用性

线上故障处理——发布顺序错误引发的数据库异常

线上故障处理——发布顺序错误引发的数据库异常