浅谈站点可靠性工程之SRE
1.SRE概述
SRE(Site Reliability Engineering)是 IT 运维的软件工程方法。SRE 团队使用软件作为工具来管理系统、解决问题并实现运维任务自动化。SRE 执行的任务以前通常由运维团队手动执行，或者交给使用软件与自动化来解决问题和管理生产系统的工程师或运维团队执行。
在创建可扩展和高度可靠的软件系统时，SRE 是宝贵的实践。它可帮助您通过代码管理大型系统，对于管理成千上万台机器的系统管理员（sysadmin）来说，代码更具可扩展性和可持续性。
站点可靠性工程的概念由 Google 工程团队的 Ben Treynor Sloss 率先提出。借助 SRE，团队能够在发布新功能和确保用户可靠性之间找到平衡。在这种背景下，标准化和自动化是 SRE 模型的两大重要部分。在这里，站点可靠性工程师寻求增强和自动化运维任务。
通过这些方式，SRE 有助于提高当今的系统可靠性，并且会随着时间的推移不断提高。SRE 支持团队从传统 IT 运维方法改用云原生方式。
2.不同视角下的SRE
- 管理者角度:SRE是一个具备全栈能力的岗位，需要一个技术能力全面的技术专家，解决所有稳定性问题。
- 运维工程师角度：SRE 主要是做好监控，做到快速发现问题、快速找到问题根因，是传统运维岗位的升级版，一定要把运维自动化工作做好
- 平台架构师角度:SRE要加强容量规划，学习Google 做到完全自动化的弹性伸缩，
3.SRE的根本目的
MTBF，Mean Time Between Failure，平均故障时间间隔。
MTTR，Mean Time To Repair，故障平均修复时间。
MTTI(Mean Time To ldentify，平均故障发现时间)，也就是从故障实际发生，到我们真正开始响应的时间。这个过程可能是用户或客服反馈、舆情监控或者是监控告警等渠道触发的。
MTTK(Mean Time To Know，平均故障认知时间)，更通俗一点，可以理解为我们常说的平均故障定位时间。这个定位指的是root cause，也就是根因被定位出来为止。
MTTF(Mean Time To Fix，平均故障解决时间)，也就是从知道了根因在哪里，到我们采取措施恢复业务为止。这里采取的手段就很多了，比如常见的限流、降级、熔断，甚至是重启。
MTTV(Mean Time To Verify，平均故障修复验证时间)，就是故障解决后，我们通过用户反馈、监控指标观察等手段，来确认业务是否真正恢复所用的时间。
4.系统可用性的衡量方式
目前业界有两种衡量系统可用性的方式，一个是时间维度，一个是请求维度，我们先来看这两个维度的计算公式。
时间维度:Availability=Uptime/(Uptime + Downtime)
请求维度:Availability=Successful request/Total request
5.系统稳定性衡量标准
5.1时间
时长维度，是从故障角度出发对系统稳定性进行评估。
衡量故障的三要素：衡量指标、衡量目标、影响时长
5.2请求
- 请求维度，是从成功请求占比的角度出发，对系统的稳定性进行评估。
- 关键要素:系统可用性监管包含三个关键要素:衡量指标、衡量目标、统计周期。
- 严格监管方式:通过请求成功率、成功率达到指定目标(如95%)、统计周期来评估系统整体状况。
- 不漏任何问题:该方式对系统运行状况监管更为严格，不会掉任何一次问题的影响。
- 故障与稳定性关系:故障意味着不稳定，但不稳定不一定有故障发生。
- “几个9”的稳定性:系统的稳定性通过几个9来定量衡量，接下来将讨论何为系统的稳定性。
6.如何设定稳定性目标
- 成本因素：系统稳定性目标的设定需考虑成本与回报之间的平衡，企业需评估成本承担能力与预期回报率。
- 业务容忍度：系统稳定性目标应与业务重要性和影响度相匹配，核心业务通常对稳定性要求更高，非核心业务则更具容忍度。
- 实事求是原则：根据当前系统稳定性状况与实际情况，设定合理的稳定性标准。逐步提高标准，以实现稳定性的持续提升，同时避免过高标准的设定影响团队信心和积极性。
7.SRE、云和云原生开发
从传统 IT 和本地数据中心迁移到混合云环境，是企业每年产生的运营数据平均增加两到三倍的主要原因之一。SRE 的重要性逐步提高，随着 IT 环境愈加复杂，SRE 可利用此类数据自动执行系统管理、运营和事件响应，同时提高企业可靠性。
云原生开发方法，具体而言，即以微服务形式构建应用并将其部署到容器中，可以简化应用开发、部署和可扩展性。但云原生开发也创造出一个日益分散的环境，让监管、运营和管理变得更加复杂。 SRE 团队可通过云原生方法支持快速创新，并保证或提高系统可靠性，同时不会给 DevOps 团队带来更多运营压力。