01｜SRE迷思：无所不能的角色？还是运维的升级？
有人认为 SRE 就是一个岗位，而且是一个具备全栈能力的岗位， 只要有这么一个人，他就能解决所有稳定性问题。这还只是一种理解，而且这个理解多是站在管理者的角度。
SRE是指Site Reliability Engineer (网站可靠性工程师)。他是软件工程师和系统管理员的结合，一个SRE工程师基本上需要掌握很多知识：算法，数据结构，编程能力，网络编程，分布式系统，可扩展架构，故障排除。
SRE不是做底层硬件维护，而是负责各种服务的性能和稳定性。
也有人站在运维人员的角度，认为做好 SRE 主要是做好监控，做到快速发现问题、快速找到问题根因；还有人站在平台的角度，认为做好 SRE 要加强容量规划，学习 Google 做到完全自动化的弹性伸缩；甚至还有人认为，SRE 就是传统运维的升级版，把运维自动化做好就行了。
你看，其实不同的人站在不同的角度，对 SRE 的理解就会天差地别，但是好像又都有各自的道理。
所以，我特别强调实践的角度，我们不站队，就看真实的落地情况。我总结了一下从实践角度看 SRE 的关键点，就一个词：体系化。SRE 是一套体系化的方法，我们也只有用全局视角才能更透彻地理解它。
好了，下面我们就一起来看怎么理解 SRE 这个体系化工程。
SRE，我们应该怎么来理解它？
我先给你分享一张图，这是结合我自己团队的日常工作，做出来的 SRE 稳定性保障规划图。
这就是为什么我一直给你打气，说 SRE 并不神秘。学习 SRE，我们可以有非常熟悉的抓手。但是，我们不能停留在向 Google 或其他大厂学习具体的技术经验上，而是更应该学我们最初画这张图是为了提高故障处理效率，将每个阶段可以做的事情填了进去，并在实践中不断补充完善，最终形成了我们探索 SRE 的框架图。你应该也发现了，这里面很多事情都很常见，比如容量评估、故障演练、服务降级、服务限流、异常熔断、监控告警等等。
习如何将这些技术有机地结合起来，形成一套稳定性体系，让体系发挥出力量，告别只发挥某项技术的能力。
同时，结合这些具体的事情，你应该明白，这些工作并不是某个人、某个角色，甚至是某个团队就可以单枪匹马完成的。比如这里的很多事情要依赖运维自动化，像容量扩缩容，必然会与运维团队有交集；如果做得再弹性一些，还需要与监控结合，就要与监控团队有合作； 同时还可能依赖 DevOps 提供持续交付、配置变更，以及灰度发布这些基础能力，就要与开发和效能团队有交集。
这些能力之间的相互依赖，就决定了从职能分工上，SRE 体系的建设绝不是单个岗位或单个部门就能独立完成的，必然要求有高效的跨团队组织协作才可以。
所以，不要想着设定一个 SRE 岗位，就能把稳定性的事情全部解决掉，这明显不现实。你应该从体系的角度出发，设置不同的职能岗位，同时还要有让不同角色有效协作的机制。
从另一个角度来讲，如果当前我们的稳定性建设还仅仅聚焦在某个或某些具体的技术点上， 每个角色和团队之间的工作相对还是独立、各自为战的，那就说明 SRE 体系和组织的真正威力还没有发挥出来。
所以，如果你已经是这些领域的实践者，比如你是一个运维工程师，或者是一位监控开发工程师，又或者是一个 DevOps 开发工程师，我建议你除了负责当前的事情外，应该更多地关注一下 SRE 全局视图。这样会帮助你深入了解 SRE 岗位所需要的技术能力，进而提升你的平台架构能力。
总结一下，从实践角度来看，SRE 的力量不能通过一个岗位、一个或几个技术就发挥出来。SRE 是一个体系化工程，它需要协同多个部门、多项技术。
做好 SRE 的根本目的是什么？
认识到 SRE 是个体系化的事儿还不够，我们还可以“以终为始”，看看 SRE 最后要达成什么样的目标，以此来加深对它的理解。
SRE 做了这么多的事情，最后的目的是什么呢？
这个答案很明显嘛，就是提升稳定性。但是怎样才算提升了稳定性呢？要回答这个问题，我们有必要来讨论下稳定性的衡量标准。
从业界稳定性通用的衡量标准看，有两个非常关键的指标：
- MTBF，Mean Time Between Failure，平均故障时间间隔。
- MTTR，Mean Time To Repair， 故障平均修复时间。
还来看前面的 SRE 稳定性保障规划图，你会发现我们把整个软件运行周期按照这两个指标分成了两段。通俗地说，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 和 DevOps 都是很好的方法论，我应该怎么选？到底哪个更适合我？今天我们讲了 SRE 应该怎么理解，我想对这个问题你应该有答案了。那就请你来说一说，SRE 和 DevOps 到底哪个更适合你？它们有什么区别和相同点？
请你在留言区说出自己的思考，也欢迎你把今天的内容分享给身边的朋友，和他一起讨论。我们下节课见。
DevOps主要是以驱动价值交付为主，搭建企业内部的功效平台。
SRE主要需要协调多团队合作来提高稳定性。
