《SRE实战手册》总结 (基础篇 01-05)

知识框架图，包含了课程的核心知识，和自己的实践感受。它是为了让我们更好的传播知识，更便捷的在组织内应用，如果要了解更详细的内容，建议还是看赵老师的课程。

---

SRE实战手册 总结 (基础篇 01-05)
	01 | SRE迷思：无所不能的角色？还是运维的升级？
		蘑菇街SRE稳定性保障规划图.png 
			蘑菇街SRE稳定性保障规划图.png
			代表稳定性的两个指标
				MTBF，Mean Time Between Failure，平均故障时间间隔。
				MTTR，Mean Time To Repair， 故障平均修复时间。
					MTTR指标细分
			如何在自己的组织中使用这张规划图？
				理解规划图后，集思广益收集相关活动\n在相应位置填充它，填的越多越好
			规划图的目的？
				我们做的任何一件事情、开发的任何一套系统、引入的\n任何一个理念和方法论，有且只有一个目标，那就是\n“提升 MTBF，降低 MTTR”
		提升稳定性的两个方向
			提升 MTBF，也就是减少故障发生次数，提升故障发生间隔时长
			降低 MTTR，故障不可避免，那就提升故障处理效率，减少故障影响时长
		SRE的根本目的
			持续提升业务稳定性。或持续提升 MTBF、持续降低 MTTR
	02 | 系统可用性：没有故障，系统就一定是稳定的吗？
		衡量系统可用性的2种方式
			时间维度：Availability = Uptime / (Uptime + Downtime)
				时长维度的可用性包含三个关键要求
					衡量指标，也就是系统请求状态码；\n衡量目标，也就是非5xx占比，请求率99%；\n影响时长：持续10分钟
				时长维度缺点
					当系统产生波动，一天多次，每次持续几十秒，没有大面积影响到用户，\n这种程度的异常抖动，无法被计算到故障中。但是从长远来看，\n这种异常抖动确实影响到了稳定性，那么该如\n何将这种异常抖动也加入稳定性的统计范围内呢？从请求的维度
				时长维度可用性对照表
					时长可用性对照表
			请求维度：Availability = Successful request / Total request
				请求维度的可用性包含三个关键要素
					衡量指标，也就是请求成功率；\n衡量目标，也就是成功率99%；\n统计周期，也就是在一个周期内计算整体状况。
				请求维度可用性的优点
					这个维度精确到了每一个请求，在这个维度下评估稳定性，\n是通过叠加的方式来统计的；正好弥补了时长维度的缺陷；
			结论
				故障一定意味着不稳定，但是不稳定，并不意味着一定\n有故障发生；要想确定系统是否稳定，就一定要从时长\n维度和请求维度综合来看。
			扩展
				待实践确认：根据稳定性一词的含义，"响应延时" \n也可以纳入衡量稳定性的一个维度
		设定系统稳定性目标要考虑的三个因素
			1. 成本因素
				考虑ROI(回报率)，在追求可用性的过程中参考边际效益
			2. 业务容忍度
				例如黄金流程的业务要求保障99.99%；离线服务99%, \n普通服务98%；\n可以将业务划分为不同的等级，给每一个等级设定固定的SLO
			3. 系统当前稳定性状况
				结合实际情况，定一个合理的标准比定一个更高的标准\n更重要；SLO的设定应该分阶段可达成，逐步迭代。
	03 | SRE切入点，选择SLI,设定SLO
		SLI
			Service Level Indicator  服务等级指标；例如请求成功率，SLI是要监控的指标
		SLO
			Service Level Objective  服务等级目标；例如请求成功率 大于 99%，\nSLO是这个指标的目标
		SLA
			Service Level Agreement 服务等级协议；是指提供服务的企业\n与客户之间就服务的品质、水准、性能等方面所达成的双方共同\n认可的协议或契约；用于服务企业与客户
		落地SRE第一步
			选择合适的SLI，设定对应的SLO
		如何在众多指标中选择几个作为SLI？
			找到稳定性主体
				这个指标能否标识主体的是否稳定吗？
		选择SLI指标的原则
			1. 选择能够标识一个问题是否稳定的指标\n2. 优先选择与用户体验强相关或用户明显感知的指标
		Google快速识别SLI指标的方法
			#VALET: 选择SLI指标的五个维度
				1. Volume容量\n2. Availablity可用性\n3. Latency时延，定位出不同的置信区间，有针对性解决\n4. Errors错误率\n5. Tickets 人工介入
			google SLO样例图
				google SLO样例图
			google SLI和SLO模板
				https://landing.google.com/sre/workbook/chapters/slo-document
		扩展
			对于SLO的制定和可视化，需要基础设施的支撑，\n目前可以实现的有：ELK提供日志统计收集与分析，\n将分析结果使用Grafana可视化或集成开发
	04 | 错误预算：达成稳定性目标的共识机制
		设定SLO之后的难点
			关于达到SLO的活动，并不明确
		将SLO转化为错误预算
			错误预算的作用
				提示你还有多少次犯错的机会；警示效\n果比可用率更直观，感官冲击力更强
			错误预算如何计算
				错误预算 = 不可用百分比 * 总请求数    
		应用错误预算
			#目的：通过下列活动，促使达成SLO
			1. 用燃尽图表示
			2. 按照错误预算消耗比例给故障定级
				蘑菇街故障等级设定
					蘑菇街故障等级设定
			3. 稳定性共识机制
				a. 剩余预算充足或未消耗完之前，对问题的发生要有容忍度\nb. 剩余预算消耗过快或即将消耗完之前，SRE 有权中止和拒绝任何线上变更。
			4. 基于错误预算的告警
				google SLO告警算法：\nhttps://landing.google.com/sre/workbook/chapters/alerting-on-slos/
		如何衡量SLO的有效性
			1. SLO达成情况\n2. 人肉投入程度\n3. 用户满意度
		我自己的实践
			将SLO转化为不可用性
				计算不可用性，定位到具体的api，逐个解决，降低不可用性，来提升可用性。
	《05 | 案例：落地SLO时还需要考虑哪些因素？》
		电商系统设置SLO原则
			找到黄金流程(核心链路)，然后设定SLO，最后根据黄\n金流程SLO进行链路分解
		核心链路
			1. 区分哪些是核心应用哪些是非核心应用\n2. 区分强依赖和弱依赖
			总结：\n设定SLO的时候，肯定不能大面积的设定，要\n从业务的核心链路切入，将核心链路中的应用进行分应\n用等级，不同等级设定不同的SLO
			实践感受：这部分信息的确定，大多通过线下沟通得\n到，耗时费力
		设定SLO原则
			1. 核心应用SLO更严格，非核心应用可以放宽\n2. 强依赖之间的核心应用，SLO要一致\n3.弱依赖中，核心应用对非核心应用要有服务治理手段，避免非核心应用异常导致核心应用SLO不达标\n4.错误预算消耗完，要禁止这条链路的变更
		如何验证核心链路SLO
			#如何验证核心链路SLO保障的有效性
			容量压测
				通过压测观察QPS的SLO达到的容量水位\n验证服务治理手段是否有效
			混沌工程
				通过模拟故障验证SLO保障的有效性
		SRE与混沌工程关系
			混沌工程是SRE稳定性体系建设的高级阶段。\n我的理解：混沌工程是SRE实现稳定性的一种方式。
		应该在什么时机做系统验证？
			错误预算充足的情况下\n评估模拟故障带来的影响