Sre总结
Google SRE读后感
《SRE Google运维解密》一书由Google SRE团队各成员所写的短文组成，书中记载了SRE团队在支持Google业务规模不断扩大的过程中所总结的经验以及实际案例。即使在IT行业发生翻天覆地变化的今天，此书仍然弥足珍贵，它详细记录了Google迈过分水岭时期的全过程。很显然，这些经历没有办法完全复制，也许只能被模仿，但是却可以启发读者，指引未来。
本书分为以下4部分： 1. 概述——了解SRE的定义，以及该职位与传统IT行业运维职位的不同 2. 指导思想——详细讨论SRE的工作模式、行事方式，以及日常运维工作中关注的焦点 3. 具体实践——理解SRE日常工作背后的理念，讨论具体的构建与运维大型分布式系统的实践 4. 管理——探索Google在培训、内部沟通，以及会议方面的最佳实践
一、概述
什么是SRE？在Google没有“运维”这个职位，只有SRE团队（Site Reliability Engineering）。SRE团队主要由两部分人组成，一部分是全职开发人员，另外一部分人需要掌握两方面的技能，95%的开发技能和5%的运维思想、技能；同时所有人都必须非常愿意、也非常相信用软件工程方法可以解决复杂的运维问题。这样组成的团队具有以下特点：对于重复性、手动性的操作有天然的排斥感；有足够的技术能力快速开发出软件系统以替代手工操作。
二、指导思想
DevOps还是SRE？
DevOps是很早就流行起来的一种说法，核心思想是尽早将IT相关技术与产品设计和开发过程结合起来，着重强调自动化而不是人工操作，以及利用软件工程手段执行运维任务。这些思想与许多SRE的核心思想和实践经验相符合。我们可以认为DevOps是SRE核心理念的简化版，也可以试着从DevOps开始去理解SRE思想。
Google所有的SRE团队都有一套共同的核心方法论：
1、确保长期关注开发工作
SRE成员每天花费在纯运维工作上的时间不能超过工作时间的50%，剩余的时间应该花费在项目研发上。并且要长期关注研发工作。
2、在保障服务SLO的前提下最大化迭代速度
在企业中，最主要的矛盾就是迭代创新速度与产品稳定程度之间的矛盾；正如运维与开发的矛盾一样，开发关注产品迭代速度，运维关注线上稳定性。为了解决这种矛盾，SRE提出了“错误预算”理念：任何产品都不是，也不应该做到100%可靠。一般来说，任何软件系统都不应该一味地追求100%可靠，因为对最终用户来说，99.999%和100%的可用性是没有实质区别的。 通过引入“错误预算”概念，让研发团队和运维团队的目标达成一致，都是在保障业务服务可靠性的同事尽可能地加快功能上线速度。
3、监控系统
如何了解和掌握各个系统的稳定性和可用性，监控系统是必不可少的一个主要手段。SRE团队认为：一个需要人工阅读邮件和分析警报来决定是否需要采取某种行动的系统从本质上就是错误的，一个监控系统应该只有三类输出：alert / ticket / log。 监控系统不应该依赖人来分析告警信息，而是应该由系统自动分析，仅当需要用户执行某种操作时，才需要通知用户。
4、应急事件处理
评价一个团队将系统恢复到正常情况的最有效指标，就是MTTR（评价恢复时间）。任务需要人工操作的事情都只会延长恢复时间，一个可以自动恢复的系统即使有更多的故障发生，也要比事事都需要人工干预的系统可用性更高。
5、变更管理
SRE经验：大概70%的生产事故都是由某种部署的变更而触发的。变更管理的最佳实践是使用自动化来完成以下几点：采用渐进式发布机制、迅速而准确的检查到问题的发生、当出现问题时，安全迅速地回退变更。
6、需求预测和容量规划
需求预测和容量规划就是保障一个业务有足够的容量和冗余度去服务预测中的未来需求。
7、资源部署
资源的部署是变更管理和容量规划的结合物，资源的配置和部署必须能够非常迅速的完成。
8、效率与性能
高效的利用各种资源是任何盈利性服务的都要关心的，因为SRE最终负责容量的部署和配置，因此SRE也必须承担起任何有关利用率的讨论及改进。
9、文档化
实现细节永远只是短暂存在的，文档化的设计过程才是无价之宝。
三、具体实践
本部分将描述SRE日常工作背后的指导思想——工作模式、行为方式，以及平时运维工作中关注的重点。
指导思想包括以下方面：
- 风险处理
- 服务质量目标
- 减少琐事
- 分布式监控系统
- Google的自动化系统的演进
- 发布工程
- 简单化
- 基于时间序列数据库进行有效报警
- on-call轮值
- 有效的故障排查手段
- 紧急事件响应
- 紧急事故管理
- 事后总结 从失败中学习
- 跟踪故障
- 测试可靠性
- 应对过载
- 处理连锁故障
- 利用分布式共识来提高可靠性
其中印象较深的有减少琐事、服务质量目标（SLO）和事后总结 从失败中学习。
琐事的定义：手动性、重复性、可自动化、战术性、无持久价值、与服务同步线性增长。运维一天的工作时间中，其实有很大部分时间都花费在处理琐事上面，或者正当你非常投入的在解决一个问题时，突然来了琐事需要处理。这会导致运维的时间非常碎片化，并且会给运维人员带来太多的“上下文切换”，直接导致工作效率下降。SRE团队使用“工程工作”来解决这个问题，工程工作通常是具有创新性和创造性的，着重通过设计来解决问题，解决方案越通用越好。
利用SLO让产品、开发以及运维团队在目标上达成一致，就像开头指导思想中提出的“错误预算”类似。以及基于SLO提出了SLI（服务质量指标）和SLA（服务质量协议），SLI就是SLO的具体体现，到底有没有达到SLO，从SLI上就可以直观的看出来；SLA详细描述了达到或者没有达到SLO的后果。
在SRE的文化中，最重要的就是事后总结对事不对人。这里要注意的是，书写事后总结并不是一个惩罚措施，而是整个公司的一次学习机会，正所谓学习是避免失败最好的办法。同时也为后面的新成员培训提供了非常有价值的资料。
四、管理
本部分内容涵盖了新手培训、团队内部合作以及团队之间协作的话题。
SRE对于新员工的培训非常重视，同时也有一套SRE培训计划图。其中分为四个阶段 - 第一阶段包含阅读事后总结、反向工程 - 第二阶段包含灾难演戏角色扮演、破坏并修复真的东西 - 第三阶段是修改文档、见习on-call；第四阶段是培训效果验收——加入on-call，同时还包含项目工作与责任感强调 - 第四阶段之后就是自身持续的学习
其中前三个阶段都会含有集中学习的课程，由SRE老员工指导。
对于团队之间协作性的开展工作，SRE提出以下几点建议： - 开展生产会议。生产会议的目标有两个，一是让参会的每个人对服务的状态了解程度达到一致；二是通过将在生产中获取的知识应用到服务中以便改善服务。 - 将沟通结果文档化。文档化是抵消物理或逻辑距离的主要技术之一，一定要多用。
结束语
《SRE Goggle运维解密》中包括运维、开发、软件工程等等方面的一些指导性思想，此书不仅针对运维人员，开发人员也可以从中获益。书中还提到了Kubernetes的前身Borg，以及Google在哪个阶段创造的Borg和其原因。看完此书再来思考这两个问题：为什么Kubernetes能统领容器编排领域？为什么Google能创造出Kubernetes？