SRE：Google 运维解密：应急响应解决方案的借鉴与思考

菏泽炫佑科技

SRE：Google 运维解密：应急响应解决方案的借鉴与思考

SRE 的核心是什么？

我的结论是：通过软件工程的方式开发一些自动化的工具体系（规定 SRE 团队必须把 50% 的精力放在真正的开发工作上），把传统运维工程师从大量重复、手工的操作中解放出来，让新一代的 SRE 工程师有更多的时间去做：

SRE 工程师应具备哪些素质？

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

SRE 工程师职责

SRE 的职责是运维一个或一组服务，确保服务能够正常运行和维护。为了实现这个目标，SRE 需要开发监控系统、规划容量、处理紧急情况，并确保跟踪和修复故障的根本原因。

细化后主要包括：

SRE 方法论

它不仅仅是一种方法论，更是 SRE *佳实践的保证。

为了保证SRE工程师的职责和目标，主要的实践集中在以下几个方面：

确保研发工作的长期关注点在事上而不是在人上：目标是尽早发现和堵塞漏洞，而不是掩盖或推卸。这与国内一些公司有很大不同。在保证服务SLO的同时，*大化迭代速度

在企业中，产品开发与运维的主要矛盾，就是解决迭代创新速度与产品服务稳定性的矛盾。我们应该提供什么级别的应用系统可靠性？是100%稳定自动化软件开发，还是99.99%？为了保证这*后的0.01，企业可能要付出的成本和客户感受到的价值收益是完全不成比例的。因此，认为应该从提供给客户的产品服务角度来衡量，并体现在“错误预算”中：

通过引入错误预算，研发团队和 SRE 团队之间的组织冲突得以解决。SRE 团队的目标不再是零事故运行，SRE 和产品开发团队的目标一致，都是在保证业务服务可靠性的同时，加速功能上线。

监控系统

基于SRE的监控系统和传统监控系统*大的区别在于：

注：这里说的系统自动化分析，是指监控产生告警之后，系统会先根据告警判断问题类型，然后执行SRE工程师设计的程序或者脚本，对问题进行自动分析、判断和自修复。

衡量一个团队恢复系统能力*有效的指标就是MTTR，任何需要人工操作的事情都只会延长MTTR，因此建议采用以下两种应用事件处理方案：

更换管理层

内部实践经验显示，超过70%的生产事故都是由一些部署变更引发的。我们针对国内某银行的部分客户，与不同角色的运维工程师沟通后发现，这个比例大概在70-80%。因此，变更管理的*佳实践建议如下：

需求预测和产能规划

需求预测和产能规划，简而言之，就是确保企业有足够的产能和冗余来满足预测的未来需求。

容量规划包括：

容量规划步骤：

SRE 负责并领导容量规划过程。

资源部署

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

效率与性能 SRE 的目标是根据预设的延迟目标部署并维持足够的容量。例如，当软件负载增加时，延迟也会增加。当负载达到临界线时，逐渐变慢的系统*终会停止所有服务。如何确保人才落地中国的成本

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

因此，要确保其在中国得到实施SRE：Google 运维解密：应急响应解决方案的借鉴与思考，需要承认SRE工程师的价值和能力，并给予其相应的薪酬和待遇。

内部驱动，外部补充

如果没有这个激励机制，我们可以换个角度考虑，这里借鉴一下我之前在四大银行之一参与智能运维系统建设的经验。

银行数据中心应用运维部门一直在思考如下问题：

这是他们走向 SRE 的内在驱动因素，但受限于内部的人才结构、组织结构、能力等多种因素，SRE 的能力需求被分为两个层级，分别由内外部团队来补充：

实例

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

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

总结

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

炫佑科技专注互联网开发小程序开发-app开发-软件开发-网站制作等