从实践角度看 SRE 的关键点，就一个词：体系化。SRE 是一套体系化的方法，我们也只有用全局视角才能更透彻地理解它。
我先给你分享一张图，这是结合我自己团队的日常工作，做出来的 SRE 稳定性保障规划图。
学习 SRE，我们可以有非常熟悉的抓手。但是，我们不能停留在向 Google 或其他大厂学习具体的技术经验上，而是更应该学习如何将这些技术有机地结合起来，形成一套稳定性体系，让体系发挥出力量，告别只发挥某项技术的能力。
同时，结合这些具体的事情，你应该明白，这些工作并不是某个人、某个角色，甚至是某个团队就可以单枪匹马完成的。比如这里的很多事情要依赖运维自动化，像容量扩缩容，必然会与运维团队有交集；如果做得再弹性一些，还需要与监控结合，就要与监控团队有合作；同时还可能依赖 DevOps 提供持续交付、配置变更，以及灰度发布这些基础能力，就要与开发和效能团队有交集。
这些能力之间的相互依赖，就决定了从职能分工上，SRE 体系的建设绝不是单个岗位或单个部门就能独立完成的，必然要求有高效的跨团队组织协作才可以。
所以，不要想着设定一个 SRE 岗位，就能把稳定性的事情全部解决掉，这明显不现实。你应该从体系的角度出发，设置不同的职能岗位，同时还要有让不同角色有效协作的机制。
思：SRE的实现不是靠某一个团队就能完成，而是要形成一个体系，串联运维团队、监控团队、开发团队，光设置一个SRE岗位不够，必须把从SLO出发把SRE相关的各项事情打通，从故障预防、故障发现、故障定位、故障修复和故障改进多个方面进行全流程优化。
从另一个角度来讲，如果当前我们的稳定性建设还仅仅聚焦在某个或某些具体的技术点上，每个角色和团队之间的工作相对还是独立、各自为战的，那就说明 SRE 体系和组织的真正威力还没有发挥出来。
思：SRE的建设需要整体考虑，而不是聚焦在某一个技术点上。
做好 SRE 的根本目的是什么？
SRE 做了这么多的事情，最后的目的是什么呢？
这个答案很明显嘛，就是提升稳定性。但是怎样才算提升了稳定性呢？要回答这个问题，我们有必要来讨论下稳定性的衡量标准。
从业界稳定性通用的衡量标准看，有两个非常关键的指标：
• MTBF，Mean Time Between Failure，平均故障时间间隔。
• MTTR，Mean Time To Repair， 故障平均修复时间。
通俗地说，MTBF 指示了系统正常运行的阶段，而 MTTR 则意味着系统故障状态的阶段。
如果想提升稳定性，就会有两个方向：提升 MTBF，也就是减少故障发生次数，提升故障发生间隔时长；降低 MTTR，故障不可避免，那就提升故障处理效率，减少故障影响时长。
从 SRE 稳定性保障规划图中，可以看出 MTTR 可以细分为 4 个指标：MTTI、MTTK、MTTF 和 MTTV。我把它们的具体解释做了一张图，你可以保存下来，有时间就琢磨一下。这 4 个指标，你要烂熟于心。
我们再来看 SRE 稳定性保障规划这张图，你就会理解，为什么要把所做的事情分组分块呈现。目的就是区分清楚，我们做的任何一件事情、开发的任何一套系统、引入的任何一个理念和方法论，有且只有一个目标，那就是“提升 MTBF，降低 MTTR”，也就是把故障发生时间的间隔变长，将故障影响的时间减少。
比如，在 Pre-MTBF 阶段（无故障阶段），我们要做好架构设计，提供限流、降级、熔断这些 Design-for-Failure 的服务治理手段，以具备故障快速隔离的条件；还可以考虑引入混沌工程这样的故障模拟机制，在线上模拟故障，提前发现问题。
在 Post-MTBF 阶段，也就是上一故障刚结束，开启新的 MTBF 阶段，我们应该要做故障复盘，总结经验，找到不足，落地改进措施等。
在 MTTI 阶段，我们就需要依赖监控系统帮我们及时发现问题，对于复杂度较高和体量非常大的系统，要依赖 AIOps 的能力，提升告警准确率，做出精准的响应。
同时 AIOps 能力在大规模分布式系统中，在 MTTK 阶段也非常关键，因为我们在这个阶段需要确认根因，至少是根因的范围。
按照以终为始的思路，SRE 要实现的目标就是“提升 MTBF、降低 MTTR”，从这个角度出发，我们再次认识到一定要把 SRE 作为一个体系化的工程来建设，因为单纯在某些技术点上发力是没有多大意义的。
总结一下，你需要记住下面这两点。
第一，我们需要从全局的角度去理解 SRE。SRE 一定是靠整个技术和组织体系发挥作用的，单纯从某个技术点或环节出发，都无法呈现出效果，也就是说 SRE 一定要从全局考虑，体系一定要“配套”。
第二，SRE 的目的，本质上是减少故障时间，增加系统正常运行时间，也就是 “减少故障，提升 MTBF；同时，提升故障处理效率，降低 MTTR”。SRE 要做的所有事儿，都是为这两个目标服务的。
思：
SRE是一个系统化的工程，需要从开发、架构、运维、组织共同来实现，而不是单独说监控或者应急，这是需要整体上考虑的整体方案。
SRE的目标是为了尽可能提高系统的稳定性和可用性，可以通过两个指标来体现，增加MTBF也就是正常运行时间，减少故障出现情况，降低MTTR故障时间，需要提高故障处理效率。
而为了实现这两个目标，可以从事前、事中、事后三个阶段来分析，事前做好架构优化、应急预案、混沌工程，事中做好监控、定位和快速恢复，事后做好复盘和优化。
这是指导我们做好运维的方法论，值得深入学习和实践。
此文章为7月Day2学习笔记，内容来源于极客时间《SRE实战手册》，强烈推荐该课程
