大家好！

感谢大家的时间来阅读此文，如果您对以下内容感兴趣，欢迎关注我的公众号《叨叨叨的成长记录》，这里你可以收获以下内容：

专业的IT内容分享前沿LLM技术和论文分享个人对行业的思考投资理财的经验和笔记

如果您也对这些感兴趣，欢迎在后台留言，大家多多交流！

0、为什么诞生SRE？一、什么是SRE？1.1 SRE的基本了解

Google试从解决Dev和Ops之间的矛盾出发，雇佣软件工程师，创造软件系统来维护系统运行以替代传统运维模型中的人工操作。SRE团队和产品研发部分在学术和工作背景上非常相似，从本质上将，SRE就是在用软件工程的思维和方法论完成以前由系统管理员团队手动完成的任务。

SRE在Google不负责某个服务的上线、部署，SRE主要是保障服务的可靠性和性能，同时负责数据中资源分配，为重要服务预留资源，SRE并不负责某个业务逻辑的具体编写，主要负责在服务出现宕机等紧急事故时，可以快速作出响应，尽快恢复服务，减少服务掉线而造成的损失。

一般来说，SRE团队要承担以下几类职责：可用性改进、延迟优化、性能优化、效率优化、变更管理、监控、紧急事物处理以及容量规划与管理。

Tools Don't create reliability. Humans do. But tools can help.

在减少资源消耗的同时，从可用性和性能层面，提升用户的体验。

Operations should NOT be a part of SRE missions. Operation is a way to understand production.

在书中对各个职责有较为清晰的说明，感兴趣的朋友去可以翻翻原文，这里就谈一下个人的体会。

1.2 SRE的技能堆栈

常见业务设计方案，多种并发模型，以及相关 Scalable 设计

各类底层数据库和存储系统的特性和优化

问题定位工具

运维架构能力

理论

二、SRE是如何解决问题的？2.1 解耦中台系统与应用

SRE工程师中大部分是标准的软件工程师，他们擅长使用系统工程的方法去解决基础系统中的问题，同时持续的、工程化的解决问题，使得运维的压力不会随着上层应用的增加而线性增加（通常20人的SRE团队，可以支持上千研发同学的应用开发）。同时SRE同学对Unix系统内部细节、1～3层网络比较了解，可以同研发一起分析应用程序性能问题。

系统的元数据应该是系统的架构拓扑图，通过动态、准确的更新元数据可以将采集到的Event、Message、Metric等数据映射到真实环境中去，并能通过各种手段进行系统健康程度的诊断，是的自动化监控和管理成为可能。

为了让庞大系统的运行效率提高，要不断的优化系统中的热点，并将系统中的热点服务扩展、升级、重构成为一个组建化的服务，这也是SRE中解耦系统的方法。不仅如此，SRE对各个服务的可用性进行标准化定义，将统一的标准应用到不同的服务中去，将稳定性作为各个服务的重要度量指标，通过上述操作，收拢服务治理问题，提供系统的鲁棒性。

2.2 明确服务之间的可用性依赖2.2.1 面向SLO编程标准的推行

针对SLO，我们举一个例子来说明以下，

为什么要有SLO，设置SLO的好处是什么呢？

注：

2.2.2 面向SLO监控的设计 -> SLO结果导向的告警，而不是原因导向的告警

如何定义高质量的监控：

2.3 完善的场景化演练

自动化系统的建设中除了要考虑系统的能力外，还要考虑人在其中所发挥的重要作用，毕竟一旦一些突发的时事件若必须由人来处理，则这时刻人的稳定性和准确性也是需要保证的。微软在SRE大会中提出了一个有意思的观点：如果一个系统能够比人做的更好，那人应该知道如何监控这个系统本身。因此，在保证SLO的情况下，可以做一些攻防演练（关闭SRE系统的UI后，SRE该如何操作？）；或构建一个模拟系统，让人来执行系统；并学习故障的复盘报告等。

三、浅谈SRE的观察3.1 从SRE2019观察

SRE CONF 2019 传送门：

推荐几篇不错的Session：