“SRE最佳实践” https://cloud.tencent.com/developer/article/1971093
SRE背景
- 背景：互联网行业不断发展；
- 目的：提升用户价值交付效率；
- 措施：积极采用微服务、容器及其他分布式技术产品，并积极引入DevOps之类的先进理念；
- 优势：交付效率提升巨大；
- 挑战：复杂系统架构的稳定性很难得到保障；
- 最佳实践：业内稳定性领域的最佳实践是Google SRE；
1、SRE包含哪些工作事项
稳定性规范制定，监控、压测、服务治理、大促稳定性保障、故障应急管理、组织架构建设；
2、SRE常见的问题与困惑
3、我们所看到的SRE
理念：SRE 到底是什么？我们应该怎么来理解它？有哪些关键点？
实践：到底应该从哪里入手建设 SRE？组织架构应该怎么匹配？
4、稳定性保障的切入点
切入点：稳定性保障的标准化！
跨团队部门沟通：没有共识、统一的稳定性衡量标准；
衡量稳定性的标准：SLO是稳定性保障的共识；
稳定性保障的核心：合理的组织架构可以有效应对各种稳定性问题！
5、DevOps和SRE的区别
DevOps核心是做全栈交付，SRE核心是稳定性保障，关注业务所有活动，两者共性是：都使用软件工程解决问题。
DevOps的诞生是由于互联网商业市场竞争加剧，企业为减少试错成本，往往仅推出最小可行产品，产品需要不断且高频的迭代来满足市场需求，抢占市场(产品的迭代是关乎一整条交付链的事)，高频的迭代则会促使研发团队使用敏捷模式，敏捷模式下对运维的全栈交付能力要求更严格，则运维必须开启DevOps来实现全栈交付。
因为不断的迭代交付(也就是俗称的变更)是触发故障，非稳定性根源，而互联网产品/服务稳定性缺失会造成用户流失，甚至流到竞争对手那里， 因此关注业务稳定性也变得十分重要，SRE由此诞生
SRE根本目的
目的：提升稳定性，保障高效的用户价值交付。
通用衡量指标及计算公式：
MTBF(Mean Time Between Failure)：平均故障时间间隔。
MTTR(Mean Time To Repair)：故障平均修复时间。
提升稳定性的2个措施：提升故障时间间隔，降低故障修复时间，SRE以这两个指标为宗旨。
做SLO 的指标标准是怎么来的， 比如某个SLI 达到多少是异常 ， 大于500ms是异常，这个是怎么评估的 ？
定义 Service Level Objectives （SLOs）时，需要考虑业务需求、用户期望以及系统性能。
通常，指标的选择和标准的设定是基于以下几个方面：
-
- 用户体验：
- SLO 应该与用户体验直接相关，反映用户对系统性能的期望。
- 例如，页面加载时间、服务响应时间等指标。
-
- 业务需求：
- 了解业务需求和目标，将SLO设定为可以满足业务目标的水平。
- 例如，电商网站可能将订单处理时间作为关键SLO。
-
- 历史数据分析：
- 分析过去的系统性能数据，了解系统在不同负载和条件下的表现。
- 确定系统的稳定性水平，并以此为基础设定 SLO。
-
- 用户反馈：
- 收集用户反馈，了解用户对系统性能的期望和不满意的地方。
- 将用户反馈作为设定 SLO的参考依据。
-
- 竞品分析：
- 分析竞品或同类产品的性能水平，了解行业标准和用户期望。
- 将竞品的表现作为设定 SLO的参考点。
针对某个具体的SLO，例如响应时间，大于500ms是否异常，可以通过以下方式评估：
-
- 统计分析：
- 分析历史性能数据，了解系统响应时间的分布情况。
- 通过均值、中位数、百分位数等统计指标，找到一个合理的临界点，超过该点则判定为异常。
-
- 用户期望：
- 了解用户对系统响应时间的期望，确保 SLO 的设定符合用户的预期。
- 可以通过用户调查、反馈等方式获得相关信息。
-
- 业务需求：
- 根据业务需求和目标，设定一个合理的响应时间阈值。
- 确保 SLO 的设定不仅考虑用户体验，还要满足业务运营的要求。
-
- 系统架构和技术限制：
- 考虑系统架构、技术栈以及实际的技术限制。
- 确保 SLO的设定在系统实际情况下是可达到的。
需要注意的是，SLO 的设定不是一成不变的，随着业务和系统的变化，可能需要调整
SLO 来适应新的情况。此外，SLO 不仅仅是关注异常情况，还要关注服务在正常情况下
的表现，以确保服务始终在用户和业务的期望范围内。
「真诚赞赏，手留余香」
观测猿
真诚赞赏，感谢认可
使用微信扫描二维码完成支付
