知识框架图，包含了课程的核心知识，和自己的实践感受。它是为了让我们更好的传播知识，更便捷的在组织内应用，如果要了解更详细的内容，建议还是看赵老师的课程。
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以此来驱动业务开发关注和提升稳定性。nnPE关注的方向：稳定性 > 效率 > 成本(资源消耗的成本n数据) (前面两个方向如何通过平台已经可以提供，那么n就需要PE更加关注成本方向)
