扫码阅读
手机扫码阅读
线上故障的正确打开方式
135 2024-02-24
思维导图
事前:发现故障
监控告警:建立完善的监控告警平台,除了如CPU、内存等基础指标监控外,还有诸如链路追踪、业务监控等; 定时巡检:通过自动化手段定时开展基于业务场景的巡检,这也是线上稳定性保障最核心的一点:业务防资损; 异常治理:对于偶尔抛出来的异常也要提高重视,定期分析筛选,针对可能带来更大影响的风险进行专项处理;
事中:处理故障
优先止血:即故障发生后,以恢复正常的业务运行为首要目标。 保留现场:比如服务集群挂了,踢出不健康的服务集群并重启时,建议保留至少一个故障服务实例。这样做的好处在于:一方面便于研发和运维同学更好的排查定位原因,另一方面也可以作为复盘时的证据,客观分析后沉淀案例库,便于后续的复盘改进。 单一决策:出现故障后最怕的就是病急乱投医,因为引起故障的原因可能有多个,不能只通过故障的表现就头疼医头脚疼医脚,而是需要尽可能收集相关的监控数据、日志,结合业务场景综合判断评估,才能比较合理的解决问题。这也是为什么上面提到的需要有专人来负责信息数据的汇总分发,以及上级领导决策的原因。 应急预案:面对线上故障,技术同学要做的更多是发现和预防应对,而不是四处救火。因为故障是无法避免的,也可能随时发生,四处救火只会疲于奔命。因此需要在前期做好风险评估,制定对应的线上故障应急预案并演练,这样在故障出现时可以更快的响应和解决,将故障带来的影响控制在可接受范围内。
事后:复盘故障
借助现场证据(故障应用/监控数据和日志),客观分析深层次的原因; 故障改进措施需要具备良好的可行性,且从改进方案中应沉淀出应急预案; 改进措施应该有明确的deadline和目标,且需要进行验证,确保改进的有效性; 故障复盘对事不对人,故障定级应该有合理且被大家接受的方式,否则很容易变成甩锅大会;
原文链接:
http://mp.weixin.qq.com/s?__biz=Mzg2NDAwMjM1NQ==&mid=2247487251&idx=1&sn=19f3a926ac933b2da9762403bc9487d3&chksm=ce71474ff906ce596c613d874a19e188a67676c3cb3e3deb1c4826dd72da4a2c15b3c6bf5937#rd
老张的求知思考世界的其他文章
加入社区微信群
与行业大咖零距离交流学习
软件研发质量管理体系建设
白皮书上线