SRE核心体系了解

参考B站视频资料链接https://www.bilibili.com/video/BV1ak4y1975Z?spm_id_from=333.1007.top_right_bar_window_custom_collection.content.click

SRE源头

https://sre.google/books/

SRE是什么？

• SRE-全称”Site Reliability Engineering“，站点可靠性工程，起源于2003年
• 一个可靠的运维大规模系统的框架
• 就是让软件工程师来设计运维功能所发生的事情
• 在运维层次上负责生产系统的运行
• 构建和运行高可靠性系统的、普遍适用的最佳方式

什么不是SRE？

• SRE原理听着不错，但是，它在我们这里水土不服，南橘北枳，它只能在特定文化里生长，只对超大规模才有意义
• SRE vs DevOps，两者有冲突，谁更好？应该选择哪个方向
• 可以把传统工程师和团队的名字改名为SRE 工程师/团队/部门

SRE体系结构的五大根基

SLO是什么？

• 系统的服务质量目标定义了系统应当具有的正常表现
• 专注于跟踪客户（人/机）的使用体验
• 假如客户是满意的，那么SLO就达标了

系统需要的uptime是几个9？

• 2个9是：99%
• 3个9是：99.9%
• 4个9是：99.99%
• 5个9是：99.999%
• 6个9是：99.9999%
• 7个9是：99.99999%

SLA Uptime在线计算器：
https://www.xarg.org/tools/sla-uptime-calculator/

SLO级别分布

将SLI度量数值转换成SLO百分位

面对SLI的度量，监控指标的单位本来就是不一致的；

• 网卡流量MB/s、磁盘写入write/s、HTTP响应ms、网站首页打开时间多少s等等

持续度量SLI的数值，并将采集到的SLI数值换算为在不同百分位上的数值：

• 在最近10分钟内，SLI-首页打开时间，P90(90%)均值为259ms
• 在最近10分钟内，SLI-首页打开时间，P99(99%)均值为589ms
• 在最近10分钟内，SLI-磁盘写入，P90(90%)均值为45 write/s
• 在最近10分钟内，SLI-磁盘写入，P99(99%)均值为12 write/s

思考
SLI度量数值在P90和P99的分布状态，客户满意吗？

错误预算的逻辑

吃鸡游戏案例分析

实施面向SLO的系统监控

采集负载均衡器的指标

CloudWatch可以提供采集数据
github地址：https://github.com/prometheus/cloudwatch_exporter
用Prometheus监控工具的notation表示SLI，部分示例代码如下：

指标计算

使用4周的数据计算初始SLO

建立SLO相关文档和沟通流程

• 为手游应用系统建立正式的《SLO文档》
  –获得所有利益干系者的认可：产品经理、开发人员、运维人员
• 建立《出错预算策略》文档
  –面向后果的，得到管理层的授权，SRE有权叫停特性的交付，有权将系统的运维工作退回给开发团队
• 建立SLO的监控仪表面板、报表和错误预算燃尽图
• 持续优化SLO目标的设置，持续优化监控方式

基于SLO和错误预算的决策

SRE工作原则

SRE需要设计和实施面向后果的SLO。
任何组织，甚至连一个SRE都不用雇，就能够设计错误预算策略。
这意味着识别和利用任何能够防范客户遭遇痛点使用体验的抓手。
你就可以开始实施：度量、负责、行动

SRE需要有时间进行优化改善。
一旦SRE人员就绪：就要确保他们知道，他们的工作不是继续遭遇运维工作的罪，而是每天都优化运维工作。
”更聪明的工作“可能意味着做不同的事情：这要看SRE能找到什么最有用最有价值的工作事项。

SRE需要有能力调控他们的工作负载。
SRE团队需要能够安排优先级并开展工作。
每一个新系统的维护都需要人力成本。
必须能够压制不可靠的工作实践，推回不可靠的系统。