篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了SRE Google 运维解密读书笔记一：SRE 方法论概述相关的知识，希望对你有一定的参考价值。
SRE Google 运维解密，是 SRE 领域的启蒙之作，讲述了 Google 的 SRE 实践，SRE 就是从 Google 流传出来的。本文是读书笔记，第一篇，概述 SRE 方法论
SRE Google 运维解密，是 SRE 领域的启蒙之作，讲述了 Google 的 SRE 实践，SRE 就是从 Google 流传出来的。本文是读书笔记，第一篇，概述 SRE 方法论。帮大家把书读薄，当然，也加入了一些我的个人理解，希望对你有帮助。
为何需要 SRE
传统的 sysadmin 的方式，偏手工运维，机器越多所需运维工程师越多，对于 Google 的体量（毛估估现在大概有几百万台机器）和增长速度，成本（人工成本、管理成本等）不可承受。
因为目标不同、技术背景不同、对可靠性理解不同，传统运维和产品研发团队之间，很容易形成巨大的鸿沟，有时会上升到部门之间的信任和尊重层面。比如拿变更举例，研发部门想要：“随时随地发布新功能，没有任何阻拦”，传统的运维团队想要的则是：“一旦一个东西在生产环境中正常工作了，就不要再做任何改动”。这样的两个团队，是没法很好的合作的，尤其是在 Google 的体量和增速下，得改。解法就是 SRE。
Google SRE 概述
Google SRE 的创始人是 Benjamin Treynor Sloss，研发出身，2003 年加入 Google，被任命领导一个 7 人小组（现在，SRE 团队已经上千人了），负责“生产环境维护”。Google 当时的增速是非常快的，如果按照传统的玩法，招人的速度完全无法匹配机器增速，怎么做这个“生产环境维护”的工作呢？
Benjamin Treynor 是资深研发，自然就会考虑用软件工程的手段来解决遇到的各类问题，所以 Google SRE 首先，得具备研发技能，用研发技能来解决各类生产维护重复工作。他们具备如下特质：
- 对重复性、手工性的操作有天然的排斥感
- 有足够的技术能力快速开发出软件系统以替代手工操作
但是，做过运维的人都知道，总有一些日常运维的工作无法避免，有时根本没时间写代码，比如处理工单、手工操作，尤其是在基础设施平台工程不完备的情况下。这可咋整？
Google 提出了 50% 的原则，即日常运维的时间不能超过 50%，即需要至少拿出一半以上的时间来做工程研发，釜底抽薪，用工程手段解决手工操作。那有的时候，日常运维工作繁重，超过了 50% 时间分配原则，怎么办？把相关工作交给产品研发团队的 leader，让他来帮忙消化掉一部分工作。研发 leader 一看，运维侧的工作好多啊，是不是我们的软件不够鲁棒、很多应该自动处理的逻辑没有自动处理，就会去改进，形成正向循环。当然，这个机制需要公司管理层强力推动。如果遇到一个研发团队说，运维的活你们运维干不完，干不完可以招人啊，管理层也不作为，就完了。
DevOps 还是 SRE
Benjamin Treynor 认为，SRE 是 DevOps 模型在 Google 的具体实践，带有一些特别的扩展。
SRE 技能组成
实际的人员组织来看， SRE 团队分两类人，一类就是纯研发，一类是具备八九成研发能力，同时还懂一些 UNIX 知识、网络知识。如果国内运维团队想要转型为 SRE 组织，就这个技能要求就很难达成（其实除了 Google，其他国外的公司也很难做到）。咋办？
国内的组织的做法：一个人能力有限，弄个团队来顶上，团队里既有只懂研发的人，又有只懂网络的人，又有只懂操作系统的人，应该就可以了吧。个人的看法是，这个做法基本是对的，但是不完全够。因为虽然是一个团队，但是不同的小组或个人的知识仍然是无法完全共享的，这使得在做工程决策、实践的时候，没法做到像 Google SRE 那样如臂指使。
稍微改进一下的做法是：团队里仍然要招聘一两个 SRE 专家，姑且称为 SRE COE，既懂开发又懂运维的那种，统筹所有工作，然后那些单方面的技能人才，辅助 SRE COE 来完成工作，相对会更靠谱一些。
SRE 方法论
SRE 团队的职责：可用性改进，廷迟优化，性能优化，效率优化，变更管理，监控，紧急事务处理以及容量规划与管理。要转型的团队注意了，用软件工程的手段达成以上目标，就说明你们团队转型成功了:)
在保障服务 SLO 的前提下最大化迭代速度
变更是万恶之源，生产环境中的故障，大概有 70% 都是变更引起的。屁股决定脑袋，运维团队就希望尽量别有变更，研发团队要上线新 feature，那就需要频繁变更，咋整？Google 提出了 “错误预算” 的理念。
产品首先得确定 SLO，比如某个服务的季度 SLO 目标是 99.99%，那不可用的 Quota 预算就是 0.01%，每个月按照 30 天来算，一个季度 90 天，允许的不可用分钟数是：
90 * 24 * 60 * 0.01% = 12.96 分钟 ≈ 13 分钟
只要服务的季度不可用时长低于 13 分钟，随便折腾，但是一旦超过了 13 分钟，说明 Quota 用光了，就不能随意上线了，非得要上线，行么？也行，VP 审核通过吧。那意思就是：你看这个研发团队，上线老是出问题，不可信赖，现在又要上线了，SRE 是不准备放行了，VP 大佬来决策吧，VP 大佬也非要允许上，那就上。
咋样，这个方法听着不错吧。贵司可以试试。这里要注意，服务要想减少故障时长，是需要有良好的基础设施保障的，比如研发上线发现问题，想回滚，结果部署系统不可靠，这找谁说理去。所以，错误预算这个方法可以用，但是不同的公司，SLO 的阈值得谨慎制定，没有金刚钻不揽瓷器活，基础设施很烂，SLO 就定低点吧。
SLO 谁来定？
SLO 应该是业务来定，但是 SRE 要提供一些信息，告诉业务达成什么样的 SLO 要付出什么样的成本，业务有了这些信息了，再来确定制定什么样的 SLO。比如某个业务不盈利，就是个实验性质的业务，SLO 低一点很正常，具体要看业务本身的决策，所以 SLO 的制定需要业务拍板。
监控系统
核心要学习的是：每个需要通知到人的告警，必须对应 Runbook，即预案手册。如果一个告警发出来，没有人响应，没有相应的动作执行，这个告警就是无效的。Runbook 链接一般配置在告警规则里，比如 Grafana、Nightingale、Datadog 的告警规则配置，都支持这么干。告警规则的 Runbook 预置率是一个很好的告警治理指标。
有些告警可以不用立即处理，但是至少得创建个工单留待后续处理。
应急事件处理
提前准备好 Runbook，即预案手册，比即兴发挥，效果好 3 倍。
变更管理
要自动化！要自动化！要自动化！自动化完成以下项目：
- 采用渐进式发布机制
- 有良好的监控系统，可以快速发现问题
- 当问题发生时，可以安全回滚
需求预测和容量规划
要考虑的点包括：
- 自然增量：随着用户自然增长带来的增量
- 非自然增量：比如市场活动
- 周期性压测：这点很关键，这点很关键，这点很关键，通过压测才知道你的系统瓶颈在哪个微服务，才能把系统原始资源和业务容量对应起来
资源部署
扩容需要部署资源，变更也需要，这就是 Borg 的作用，其他公司可以采用类似 Kubernetes 的方案。不管使用什么方案，能够快速、正确的完成部署，最大化资源使用，就可以了。
效率与性能
SRE 也需要关注服务性能，提升了性能，其实就是提高了资源利用效率，同样的硬件可以支撑更大量的客户。NetFlix 有专门的 Performance 工程师，Google 的话 SRE 一并干了这个事情。
小结
SRE 团队的职责：可用性改进，廷迟优化，性能优化，效率优化，变更管理，监控，紧急事务处理以及容量规划与管理。我们要用软件工程的思维来解决这些问题，完活。留个问题：
SRE 要不要修改业务代码？
比如增加一些监控埋点，或者优化一个算法提升软件性能，或者换了一个更合理的存储？欢迎大家留言讨论 :)
排查出线上问题，并找到根本原因加以解决，是一件很有成就感的事情，曾经有人问过我，“你是怎么想到问题出现在xxx的？又是怎么确认根本原因是xxx的？”，我只能淡淡的说：“靠经验”，然后感觉这个逼装的自己还算满意。
其实这个“靠经验”说的很模糊，一直以来，大家都觉得排查问题要靠经验，但是又说不出具体通过啥经验排查出了问题，最后让排查问题逐渐变成了一门玄学。
排查问题犹如破案
排查线上问题，就和侦探破案一样，就是一个不停分析线索，推理的过程，在你准备破案之前，先要明确以下两点。
系统异常是正常的，正常是特例
时至今日，计算机系统已经变得异常复杂，一次用户请求可能要经过发送请求，DNS解析，运营商网络和IP转换，负载均衡，服务器硬件，虚拟机/容器,视业务逻辑的复杂程度，可能还要调用其它组件，存储，数据库，缓存等。每个环节都可能出现问题，有的组件又是分布式的，大大增加的排查问题的难度，所以出现问题后，不要着急，保持好心态，要认为“系统异常是正常的，正常是特例”。
飞行员首要任务是保持飞机飞行
在初级飞行员的课程中捡到，在紧急情况中，飞行员的首要任务是保持飞机飞行，相比保证乘客与飞机安全着陆，故障定位和排除是次要目标。--SRE
所以，恢复线上系统是首要任务，而不是找到它发生的原因。
明确案情
先评估出这个问题的影响范围，是全网用户不可用，还是某些用户，是某条业务线出现问题，还是很多业务线都出现问题，评估出案情的大小，是普通的民事案件，还是刑事案件。
真相只有一个
计算机是一门科学，而且计算机是由0|1组成的世界，在这个世界里只有“是或否”，没有中间地带，所以在计算机世界“凡事都有根本原因”，“没有偶然发生，一切都是必然”。
所以，你要坚信真相只有一个。
理清线索
理清目前得到的线索和信息，比如监控上有网络报警，有用户反馈无法访问，有开发人员反馈服务器有问题，不要漏掉看似无关紧要的线索，把这些线索先整理下来，后面一并分析。
扩大信息量
尽可能扩大你接受到的信息量，比如问询一下开发人员今天有没有做线上改动，网络组有无重大调整。获取到有价值的信息，对于排查问题至关重要。
查看监控，细看某个监控项的变化，追踪日志和调试信息都是扩大信息量的手段。
分析证词
分析用户反馈的现象，数据是可信的，有时候人说的是不可信的，举个例子，之前有开发反馈我们虚拟机有问题，有些虚拟机接口返回异常，有些正常，他就让我们帮查查虚拟机的问题，但是最后是代码调用一处动态配置造成的。
很多反馈的信息描述，是经过描述者过滤加工过的信息，他的排查和分析有可能把你“带歪了”，先要用怀疑的态度，分析每个人的证词。
当你听到蹄子声响时，应该先想到马，而不是斑马
排查问题不要先入为主，有时候你觉得极其简单，看似非常不可能发生的事情，可能就是原因，不要轻易的排除掉某项原因，比如“宇宙射线导致某个电路信号出错”。
我们之前有个mysql连接异常的问题，查了很久，做了很多调优都没有解决，最后发现是网卡跑满了。
从大到小，从上到下
排查步骤，先“从大到小”，先看比如运营商网络，机房状态等比较宏观的地方是否有问题，逐一排除，逐步缩小问题范围。“从上到下”，先从现象发生的顶端调用链逐一排查，逐步向下深入。
SRE给出的一些方法
SRE给出了一些方法可以借鉴：
- 问题排查的几个步骤：定位，检查，诊断，测试/修复，治愈。
- 什么，哪里和为什么，找出系统正在执行“什么”，询问系统“为什么”执行这些操作，以及系统的资源都被用在了“哪里”可以帮助你了解系统为什么出错。
- 确定“最后一个修改”发生的时间。
- 提供丰富的诊断和监控工具。
下次遇到问题，使用以上方法试试看，让问题排查不再是“很玄妙的东西”。