外国黄冈网站推广平台,大型门户网站建设 费用,wordpress双栏极简,做一个医院网站多少钱概述#xff1a;作为一个SRE、运维工程师#xff0c;当我们在治理系统稳定性时#xff0c;方法有很多#xff0c;但往往无从下手。本文以一张逻辑图的形式#xff0c;为读者提供治理稳定性的体系化思路。
先上图#xff1a; 1、治理目标
我们做稳定性的目标#xff0c…概述作为一个SRE、运维工程师当我们在治理系统稳定性时方法有很多但往往无从下手。本文以一张逻辑图的形式为读者提供治理稳定性的体系化思路。
先上图 1、治理目标
我们做稳定性的目标借用GoogleSRE提出的一个理念故障无感化。我们不是要消除故障且故障也没法消除只要这世上还有bug存在故障就无法消除。
所谓故障无感化就是指我们可以对故障抱着更加open的态度当故障发生时一切有序地执行、恢复、整改就像它不曾发生一样。当然做到这个的前提是要将稳定性建设做到比较好的程度。
2、治理对象
有上可知我们治理的对象就是故障那么问题来了如何定义一个故障我们需要一个基线于是故障等级定义由此而来。
2.1 故障等级定义
故障等级定义要表达清楚具体业务域下某业务指标影响范围和影响时长举例如下
P0订单交易成功量下跌10%P1首页打开错误率大于5%
制定的逻辑可先定场景再定影响。场景代表客户真是的体感可由业务团队明确有了场景就可以搜罗对应的监控并按周、按月观察监控趋势以影响客户数量为基准确定故障等级。举例订单交易成功量下跌的数量、支付失败的数量、履约失败的数量必须一致或同一量级可归为同一个故障等级。 2.2 故障生命周期
故障生命周期可归纳为发生--发现--响应--恢复--复盘
2.2.1 发现阶段
在发现阶段我们主要依赖于三类型的监控基础架构、业务监控、客户反馈/投诉。基础架构的监控一般不会直接影响到业务指标主要还是依靠后两者。是不是发现和故障等级定义串起来了 2.2.2 响应阶段
在响应阶段要明确应急小组里的每个角色以及指责。试想下当你们公司交易下跌10%时一时间call上来过多少人每个人七嘴八舌没有组织恢复效率可想而知。
应急小组主要由SRE、领域专家、决策人、其他组织架构构成。
SRE作为响应阶段的控场人物首先要发起组织其次记录故障时间线并间歇同步同时以最小化原则协调资源并在恢复会议或者沟通群中控制所有人的发言避免信息泛滥。在排查问题时把控方向并在关键时刻找到特殊领域专家帮助定位同时在执行方案上做风险把控。 2.2.3 恢复执行
恢复执行没什么好说的重点是观测业务指标的回升以及准备好回滚方案。
2.2.4 复盘
复盘重点关注过程分析和根因分析。
过程分析即发现、响应和恢复的过程中具体指标是多少比如阿里提出的1-5-10指标1分钟发现、5分钟响应、10分钟恢复。在复盘中问自己三个问题发现阶段有没有监控覆盖响应阶段有没有高效执行恢复阶段有没有应急预案
根因分析围绕是否变更导致。如果是变更导致那需要review变更的三板斧是否有对应策略和方案如果不是变更导致则需思考从架构层面的高可用和高可靠性是否做的充分。 3、治理专项
到此大家应该也能大致猜到专项治理是要治理什么了我们不妨以应急SLA1-5-10作为目标从监控覆盖、应急预案、应急演练三个方向展开治理。 3.1 监控覆盖
以故障等级定义为基线整体review所有的故障等级定义是否都有相应的业务监控覆盖可以是多个监控对应一个故障场景。
3.2 应急预案
同样是以故障等级定义为参考是否每个条目都有对应的预案可以及时恢复就算有的场景实在恢复不了是否有止血方案可以组织故障影响的扩大。
3.3 应急演练
再做足监控覆盖和应急预案之后不定期地组织演练。演练需要关注两个点我们的应急组织是否完善、各个角色的应急响应是否及时方案是否有效是否可以自动化执行方案的可读性是否足够高能让任何一个工具人都可以执行恢复。
总结
稳定性治理依托于故障等级定义、围绕着故障生命周期展开。故障的生命周期中每个节点都是我们可以去展开、去思考如何做的更优并同时反哺到故障等级定义中二者相辅相成密不可分。希望本文对在做稳定性的读者们有所启发。
