GOOGLE SRE 运维模式解读

最近要整理一些关于应急响应方面的解决方案材料，又重新翻阅了一遍《SRE：Google 运维解密》这本书，非常值得我们借鉴和思考。本文将包括如下内容：

SRE核心是什么
SRE工程师具有什么样的气质
SRE工程师职责
SRE方法论
如何保障在国内落地
总结

SRE核心是什么

我总结下来是：通过软件工程的方式开发（GOOGLE规定SRE团队必须将50%的精力花在真实的开发工作上）一些自动化的工具系统来解放传统运维工程师大量重复和手工操作，从而让新生代的SRE工程师有更多的时间：

思考如何让系统能够更健壮地运行
出现问题能够通过事先编制的自动化处置策略，最短时间自愈
事后思考如何让该事件的问题撤底修复，如果不能，SRE是否可以开发一些自动化的工具系统能够代替人工在最短的时间解决问题
最终：SRE可以有更多的时间享受生活，而非像传统运维工程师疲于奔命…

SRE工程师具有什么样的气质

在本书的第4页，我们可以找到答案，总结果如下：

对重复性、手工性的操作有天然的排斥感
有足够的技术能力快速开发出软件系统以替代手工操作
SRE团队成员都非常愿意、也非常相信软件工程方法可以解决复杂的运维问题
SRE工程师必须具备写与代码的能力，在本书中也提到SRE团队包括两类工程师：
- 第一类：团队中50-60%是标准的软件工程师
- 第二类：是基本满足GOOGLE软件工程师标准（具备85-99%所需要的技术），但同时具有一定程序的其他技术能力，如UNIX系统内部细节和1-3层网络知识是GOOGLE最看重的两类额外能力。

SRE工程师职责

SRE的职责是运维一个或一组服务，保障服务可以正常运维，为完成这个目标，SRE需要完成开发监控系统、规划容量、处理紧急事件、确保故障根因被跟踪和修复。

细化后主要包括：

可用性改进
延迟优化
性能优化
效率优化
变更管理
监控
紧急事务处理
容量规划与管理

SRE方法论

与其说是方法论，不如说是SRE的最佳实践保障。

为了保障SRE工程师的职责目标，主要实践围绕以下几个方面：

确保长期关注研发工作

磨刀不误砍柴工：运维工作限制在50%以内，将剩余的时间花在研发工作上，这是一个安全性，非常重要，因为这样才能够保障他们有足够的时间编程，以避免将来会被运维工作所淹没
运维工作：在每天8-12H的轮班基间，最多只处理两个紧急事件。这保障SRE可以正确处理故障、恢复服务，并且编写一份高质量的事后报告。如果处理问题过多，那么每个每人问题就不可能被详细调查清楚。
事后总结：所有的生产事故都有对应的事后总结：
- 如果该事故是人工报障没有触发监控，则需要揭示监控系统为什么没有报障，如何优化
- 总结应该包括发生、发现、解决的全过程、根本原因、预防或优化的解决方案
对事不对人：目标是尽早发现和堵住漏洞，而不是去掩盖、推脱他们，这跟国内一些企业有很大的区别。

在保障服务SLO的前提下最大化迭代速度

企业中，产品开发和运维的主要矛盾是解决迭代创新速度与产品服务稳定程度之间的矛盾。我们究竟要提供一个什么可靠等级的应用系统？是100%稳定还是达到99.99%就可以，为了保障这最终的0.01企业可能要负出的成本和客户体验到的价值收益是完全不对等的，因此GOOGLE认为要从为客户提供的产品服务的角度去衡量，并体现在“错误预算”中：

基于用户使用习惯，服务可靠性达到什么程度用户才会满意？
如果这项服务的可靠程度不够，用户是否有其他的替代选择？
服务的可靠程度是否会影响用户对这项服务的使用模式？

通过引进错误预算来解决研发团队和SRE团队之间的组织架构冲突。SRE团队的目标不再是零事故运行，SRE和产品研发团队目标一致都是在保障业务服务可靠性需求的同时尽可能加快功能上线速度。

监控系统

GOOGLE认为基于SRE的监控系统和传统监控系统的最大区别：

传统监控系统：配置监控策略，一旦出现情况或者监控值超过阈值就触发EMAIL。然后人工阅读、分析、处理问题。
SRE的监控系统：GOOGLE认为传统的监控效率是不高的，他们认为监控系统不应该依赖人来分析告警信息，而是由系统自动分析，仅当需要用户执行某种操作时，才需要通知用户。

注意：这里所讲的系统自动分析，是指监控产生告警之后，系统会优先根据告警判断是哪类问题，然后再执行由SRE工程师设计的程序或脚本对该问题进行自动化的分析判断和自愈。

应急事件处理

评价一个团队将系统恢复到正常情况的最有效指标就是MTTR。任何需要人工操作的事情只会延长MTTR。因此，GOOGLE推荐如下两种应用事件处理方案：

自动恢复：也是最推荐的一种方案，通过SRE工程师事后的不断总结和工程化、自动的解决方案，可以更快地使系统故障得到恢复，同时也提供了比人工操作更高的准确性。
RUNBOOK手册：当不可避免的人工干预时，通过事先记录的应急预案及解决问题的方法、过程记录到RUNBOOK手册中可以使MTTR降低3倍以上。初期需要SRE的专家工程师来解决问题，并整理RUNBOOK手册，后续可以通过该“葵花宝典”让on-call工程师处理。因此，RUNBOOK手册是应急事件处理中不可或缺的。

变更管理

GOOGLE内部的实践经验总结约70%以上的生产事故是由某种部署的变更而触发，国内一银行的一些客户我们同不同角色的运维工程师进行沟通得到的结果是约70-80%。因此，GOOGLE建议的变更管理最佳实践如下：

采用渐进式发布机制（搜索了半年也没有找到渐进式发布是个啥，有了解的读者可以告知我一下）
迅速而准确地检测到问题的发生
出现问题时，可以安全快速的回退

需求预测和容量规划

需求预测和容量规划简单来说是保障一个业务有足够容量和冗余度去服务预测中的未来需求。

容量规划包括：

自然增长（随着业务及用户的增长，资源用量也将上升）
非自然增长
- 新功能的发布
- 商业推广
- 其它

容量规划步骤：

需要有一个自然增长的需求预测模型，可以有效预测未来一段时间的业务增长
针对非自然增加的因素，需要有准确的需求来源统计
必须有周期性的压缩测试，以便准确将系统的原始资源信息与业务容量对应起来

SRE承担和主导容量规划的过程。

资源部署

也是SRE的职责范围，主要关注点：

部署要快速
保障正确执行
必须执行测试，因为一次资源部署通常要修改配置文件、负载均衡、网络等。

效率与性能

SRE关注如何高效地利用各种资源
关注资源利用率，并有效降低系统的总成本
业务总体资源使用情况综合考虑三个因素，并通过这三个因素失去服务效率的提升：
- 用户流量
- 可用容量
- 系统资源的使用效率
SRE的目标是根据一个预设的延迟目标部署和维护足够的容量

如：软件一般来说负载上升的时候，会导致延迟升高。当负载到达临界线的时候，一个逐渐变慢的系统最终会停止一切服务。

如何并保障在国内落地

人才成本

SRE工程师需要具备开发和运维能力，同时了解运维体系。为了更好地服务业务，还需要具备一定的业务感知能力。这种人才的薪酬通常比普通的运维工程师高出30%-40%左右。在薪酬体系上，国内一些大型金融机构比较难打破之前的薪酬水平，只有一些大型互联网企业能够招聘到这种人才。

因此，要保障在国内的落地，就需要承认SRE工程师的价值和能力，并给予相应的薪酬和特权。

内部驱动、外部补充

如果没有这样的激励机制，我们可以从另一个角度考虑。在此，我借鉴了之前在某四大行参与智能运维体系建设的经验。

在该行数据中心的应用运维处室一直在思考如下问题：

减少故障事件，降低对业务的负面影响
加快故障的处理时间，缩短故障诊断时间
通过自动化的手段协助分析、处理故障

这些是他们迈向SRE的内部驱动因素。但是，受到人才结构、组织结构、能力等多种内部因素的制约，对SRE的能力要求被划分为两个层面，通过内、外部的团队来互相补充：

对内，传统的运维工程师+需求分析师：
培养复合型人才需要考虑许多因素，组织可能长时间内不太可能让自己的人才达到SRE的能力。在这种情况下，企业可以在原有运维工程师的基础上增加需求分析师的能力，即挑选一些专业的运维工程师（对自己所在领域的知识非常了解，知道流程、工具的缺陷、渴望通过新工具来解决自身问题、提高效率），让他们提出运维能力提升的工具需求，并交给外部的合作伙伴来进行工程研发、落地和改进。
对外，补充产品设计及工程研发能力：
通过外部的研发能力或企业自身已有的研发团队来解决传统运维工程师最缺少的工程研发能力。运维工程师可以针对日常运维过程中发现的问题整理需求，并与外部的工程研发团队一起分析、总结、设计相应的工具。最终，帮助企业完成运维工具和针对特定事件解决问题的自愈工具等的落地能力。

实践示例

在日常运维过程中，应用运维团队经常需要手动到日志系统获取APM的交易日志，进行复杂的查询以分析并解决业务层交易链路产生的告警。这样的操作非常耗费时间且会增加业务中断风险。因此，他们建议在发生业务交易层告警时采取以下措施：

根据业务层的告警情况，故障分析系统会自行触发并到日志系统拿取故障时段的交易日志数据
根据交易日志数据，自动分析并形成业务调用链路
针对同一链路上的不同业务系统所产生的告警能够合并观察
针对同一链路上的告警能够通过不同的情境系统自动分析故障的根因节点
…

为了满足以上需求，我们可以与外部的产品设计及研发工程团队合作，共同完成工具系统的建设和实施，具体包括以下内容：

针对需求及场景可行性进行评估，并提供可行的解决方案
原型设计、系统设计
数据接口设计
产品落地
…

总结

Google SRE文化的精髓在于将软件开发和运维相结合，实现了自动化运维，从而提高了服务的可靠性和可维护性。SRE团队通过对生产环境的监控和分析，不断改进服务的性能和稳定性。此外，SRE团队还积极参与软件开发和架构设计，为产品的可靠性和可扩展性提供支持。