《SRE实战手册》总结 (基础篇 06-10)

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

SRE实战手册 总结 (实践篇 06-10)
	《06 | 故障发现：如何建设On-Call机制？》
		故障处理的关键环节
			MTTR流程图
				 
			MTTR各环节所占时长(IBM)
				 
			分布式系统的实际情况，时长占比
				 
			处理故障的目的
				提升每个MTTR环节的效率，缩短整个MTTR，\n减少故障对错误预算的消耗
			MTTI：从发现故障到响应故障
				#故障平均确认时间，故障发生时间到采取实际行动前的这段时间
				要做的两件事
					1. 判断出现的问题是不是故障
						根据错误预算消耗情况，判断故障等级
					2. 确认有谁来响应和召集
						On-Call人员
				分支主题
			蘑菇街On-call流程机制建设
				1.确保关键角色在线
					每个组件都有On-Call人员，故障第一时间接收人是SRE，\nOP这样的角色，业务开发要确保响应SRE发起的故障应急
				2.组织War Room应急组织
					消防群，为应急响应而组建的临时群，包含故障响应相关方
				3.建立合理的呼叫方式
					每个组件对应一个固定号码，号码背后是On-call人员
				4.确保资源投入的升级机制
					在调度人员解决故障时，可以升级给领导帮助协调资源
				5.与云厂商联合的On-Call
					云厂商作为系统的一部分，而不是第三方，加强合作，\n联合故障演练
			我的On-call实践
				应急响应
				参考手册处理日常事务
				向业务研发答疑运维产品
					智能问答系统
					问答分析系统
	《07｜故障处理：一切以恢复业务为最高优先级》
		处理故障原则
			在故障处理过程中采取的所有手段和行动，一切以恢复业务为最高优先级
		案例：一次应急操作导致故障蔓延
			1. 蔓延的原因是缺少故障隔离(服务治理)方案  
			2. 关键角色和流程机制的缺失，缺少应急流程，分工不明确，缺少决策，\n反馈等机制
			3.缺少演练
				实际中不敢尝试演练，是因为担心影响到故障  
					这也从侧面说明我们的方案不够成熟完善。相对宽松的\n情况下都不敢演练，到真正故障时更不敢操作了。\n应该通过演练，倒逼我们考虑的更完善才对
		故障响应的本质
			1.技术方面\n2.流程机制方面
		如何建立有效的故障响应应急机制
			面对大促，故障相关方在一个物理空间内；\n关键角色分工，沟通机制
		Google的指挥体系
			关键角色分工
				Incident Commander，故障指挥官，简称为 IC。他最重要的\n职责是组织和协调，二不是执行。\nCommunication Lead，沟通引导，简称 CL。负责对\n内对外信息收集和通报，要求沟通能力要好；\nOperations Lead，运维指挥，简称 OL。负责指挥或\n指导故障预案的执行和业务恢复\nIncident Responders，简称 IR。具体的执行这，故障\n恢复的执行者
			流程机制
				1. 故障发现后，On-Call快速组建故障群\n2. 如果故障和预案明确，则On-Call可以直接承担IC角色,优先恢复业务。\n3. 故障影响较大时，On-Call应该将IC角色转移给受损最大方
			反馈机制
				1.每隔一段时间反馈一次\n2.决定操作前做通报\n3.没有进展也是进展\n4.信息透明\n5.CL的沟通要尽量业务话\n6.没有恢复时间时，给反馈时间
		总结：影响故障处理效率的三个因素
			1.技术层面故障隔离方案是否完备\n2.故障中的指挥体系是否完善\n3.故障处理演练是否足够
	《08｜故障复盘：黄金三问与判定三原则》
		故障复盘的意义
			在失败中学习
		不好的故障复盘
			1. 定责推诿扯皮
				1. 定责\n2. 推诿扯皮\n3. 从不同的角度能得到不同的故障根因
				总结：故障的根因不止一个，不如一起看看引\n起故障的原因都有哪些，是不是有改进空间
		如何做故障复盘
			#将故障过程中的每个环节对应到Timeline图中，\n针对耗时较长的环节反复讨论如何改进，产生待办事项
			故障复盘的黄金三问
				第一问：故障原因有哪些？\n第二问：我们做什么，怎么做才能确保下次不会再出现类似故障？\n第三问：但是我们做了什么，可以用更短的时间恢复业务？
		由谁来承担改进职责
			1. 健壮性原则\n2.第三方默认无责\n3.分段判定原则
		故障
			故障是系统运行的常态，正常才是特殊状态
	《09｜案例：互联网典型的SRE组织架构是怎样的？》
		组织架构与技术架构相匹配
			技术架构实现组织目标，组织架构服务并促成技术架构的实现
		SRE是分布式和微服务架构的产物
			分布式系统的复杂性，特别是在运维层面的超高复杂性，\n对传统运维产生了冲击。
		引入SRE运维体系的前置条件
			技术架构是否在朝着服务化,分布式,微服务的方向演进
		引入SRE要在组织架构上的变更
			至少是协作模式要做出一些变革
		蘑菇街SRE组织架构实践
			组织架构图
				蘑菇街组织架构图
			基础设施层：定义为Iaas层，主要以资源为主\n技术中台：各种分布式组件，缓存，消息，数据库，对象存储，\n大数据等产品，这一层的特点是有状态，存储数据的产品。\n业务中台：将具有业务共性的产品能力提炼出来，比如用户，\n登陆，交易，风控等，支撑上面的业务前台的应用\n业务前台：通过中台提供的共享能力快速构建起来的应用\n接入层：主要是四层和七层负载均衡
			技术保障平台
				这部分能力来自于技术中台        \n总结：运维能力一定是整个技术架构能力的体现，而不\n是单纯的运维的运维能力体现
		应用运维(Production Engineer),PE
			#或者叫技术运营，位于业务中台和前台，非常接近SRE。\nPE角色是未来引入SRE非常重要的一环。\nPE整理业务方需求沉淀到平台工具团队和稳定性开发团队，\n又需要和业务团队沟通，来适配技术中台，属于核心枢纽。
			PE和SRE能力差别
				PE软件工程能力较弱
			职责：业务运维
		工具平台团队
			现在devops的能力范围
			职责：建设运维自动化平台
		稳定性平台团队
			负责稳定性保障相关的标准和平台，监控，服务治理，容量\n压测于规划，为稳定性保障提供支撑，可以直接支撑业务开发
			职责：建设稳定性平台
		互联网组织架构图
			互联网组织架构图
		总结
			从分工来看：SRE = PE + 工具平台开发 + 稳定性平台开发
	《10 | 经验：都有哪些高效的SRE组织协作机制？》
		保障电商大促的准备工作
			1.大促项目开工会
			2.业务指标分解以用户模型分析评审会
			3.应急预案评审会
			4.容量压测及复盘会
		各角色发挥的作用总结
			PE：PE关注全局运行状态，业务研发更关注自己的应用，深入代码层分析工作。\nPE：PE关注公共部件的容量水位，例如redis，mq等；关注服务治理策略，应急预案。\n工具开发和稳定性开发团队参与不多，他们的输出主要在对平台的开发上，\n容量压测规划，链路分析等。此时他们参与的越少越好。
		哪些工作可以例行化
			#大促压测会产生例行化工作\n#还会产生一些周期性工作
			1.核心应用变更及新上线业务的稳定性评审工作
				和业务研发一些评估应用变更，并关注SLO
			2.周期性技术运营工作
				关注错误预算，每周或每月输出系统整体运行报表；\n关注异常SLO与业务研发评估，后续采取改进措施，\n以此来驱动业务开发关注和提升稳定性。\n\nPE关注的方向：稳定性 > 效率 > 成本(资源消耗的成本\n数据) (前面两个方向如何通过平台已经可以提供，那么\n就需要PE更加关注成本方向)