发现了一个来自LinkedIn的关于SRE的非常好的教程👇: https://linkedin.github.io/school-of-sre/level101/systems_design/intro/ 其中它提到了Google的SRE教程(这个才是体系化的SRE)👇: https://sre.google/workbook/non-abstract-design/
通过搜索以及向New Bing提问，解除了我的一些疑惑:
- 需求分析是软件生命周期中的一个阶段。软件生命周期包括: 需求分析、架构设计、详细设计、编码、测试、部署和维护。
- "UML建模"可以在需求分析、架构设计和详细设计阶段使用，用于描述软件系统的静态和动态特征。
- 在详细设计阶段之后，应该就产出了与具体代码密切相关的产物，比如类图、序列图、活动图等文档。
- 软件架构师会根据现在流行的 DDD 设计方法与微服务架构方法论来设计服务，比如: 我这个软件里有哪些API，这些API分别在哪些微服务中。
- SRE工程师也应该根据 DDD 设计方法以及微服务方法论来理解软件的业务逻辑。
- SRE的侧重点在于使用SLIs以及SLOs等SRE特有的方法论来参与到软件架构中，以便在系统设计的过程中就能评估对资源的需求，比如: 多少带宽服务多少用户、每天产生多少数据、这些数据占用多少容量。
- 为什么SRE要参与到系统设计? 再举个例子，on-call的时候，不了解服务的细节，不知道如何对应，微服务数量众多，难道每个服务都安排人员on-call？参考: What the Microservices SRE Team are doing as SRE Evangelists
- 谷歌提出的NALSD概括了SRE层面的系统设计的目标: "Practically, NALSD combines elements of capacity planning, component isolation, and graceful system degradation that are crucial to highly available production systems."
- 谷歌说，为什么要在软件系统设计层面上考虑SRE: "We find that deferring reliability issues during design is akin to accepting fewer features at higher costs. By following an iterative style of system design and implementation, we arrive at robust and scalable designs with low operational costs. We call this style Non-Abstract Large System Design (NALSD)."
- SRE 除了在上述NALSD方法论下参与系统设计之外，还有一系列的体系建设，包括技术、管理、流程、组织架构，以及文化建设的方法论和最佳实践。
- 与传统运维重合最高的方面是:围绕"故障"这个影响稳定性的核心事件，建立故障发现、故障处理、故障复盘的体系。
我的总结:
什么是SRE？
- 从传统运维角度来看，我们每天做的监控告警、运维自动化、故障处理和复盘工作，就是SRE的一部分。你会发现，Google在介绍SRE的时候，很多篇幅介绍的就是这些我们熟悉的内容。
- 从2015年左右开始，随着微服务、容器等技术的普及，不同类型、不同规模的企业IT团队，为了提升用户价值的交付效率，也开始积极采取这些技术。应运而生的是Cloud-Native技术生态圈和DevOps这样的先进理念。
- 这些技术是涉及到技术和组织架构的演进的。IT团队通过自动化、平台化等方式提高了效率，也要应对随之而来的挑战，也就是技术架构越来约复杂，稳定性就很难得到保障。
- 在系统设计层面考虑SRE问题，那么你可以: 增加最少的资源来增加最大的服务负载;当你的系统受到外部攻击或者因为bug发生错误，被害在可控制范围内(component isolation, graceful system degradation)。
- 在SRE概念下，软件系统的技术架构中诞生出了技术中台、业务中台以及业务前台这样的概念。
- SRE = PE(Production Engineer) + 工具平台开发 + 稳定性平台开发
- 业务中台和前台这两层的运维职责，通常就是我们常说的应用运维、PE（Production Engineer）或者叫技术运营这样的角色来承担。
- PE 要跟业务开发团队一起对业务系统的稳定性负责。