后端人员如何应对线上故障

最新推荐文章于 2024-04-02 14:56:56 发布

一杯甜酒

最新推荐文章于 2024-04-02 14:56:56 发布

阅读量1.4k

点赞数 4

CC 4.0 BY-SA版权

分类专栏：干货杂记文章标签：后端人员如何应对线上故障

本文链接：https://blog.youkuaiyun.com/u012562943/article/details/88021217

干货杂记专栏收录该内容

167 篇文章 ¥39.90 ¥99.00

订阅专栏

超级会员免费看

本文讲述了后端人员在面对线上故障时如何快速定位问题、止损恢复，并提供了故障发生前的准备工作和故障发生后的复盘方法。强调全链条排查的重要性，推荐了包括重启、限流降级、回滚和紧急更新在内的恢复手段，以及故障等级设定、服务资源图、应急方案和故障演练等预防措施。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

分享一个大神的人工智能教程。零基础！通俗易懂！风趣幽默！还带黄段子！希望你也加入到人工智能的队伍中来！点击浏览教程

1、快速定位故障

在复杂的系统架构中，尤其是微服务架构中，一旦发生故障可能会出现“多米诺骨牌效应”，系统会由一个故障点波及到其他关联的模块。那么一旦定位不及时，不仅仅会扩大故障，还可能会由于多个模块都在报错、报警，给故障源的定位带来困难。因此我们要有一套快速的故障定位方法。我比较推荐的就是全链条投入排查。即一旦发现线上故障，当前系统以及相关系统所对应的开发、运维、测试等方向，各抽调对口人，全都叫到线上去处理问题，各自排查各自模块/服务，如果排查自己负责的范围没有问题就可以在旁边待命，以备在需要的时候进行配合。重点就是从一开始就一起介入。不要小看这一点，看似平淡无奇，但实际场景下，要能保证有序的这么去做到，还是挺难的，亚马逊都是通过一套制度和任务分配系统来保障这种全链路排查方案得以持久实施的。其实这么做的目的就是在跟故障抢时间。我们平时大多数情况下是怎么做的呢，收到一个线上功能的错误报告，然后对应功能的前端同学开始排查，排查了半天，发现是后端接口不正常，将问题转到后端同学继续排查，后端同学经过一段时间排查后，发现是运维问题或者是依赖的其他模块的问题，就再次将问题转到运维或者其他项目组，然后后者接手开始排查。这样来来去去，等定位到真正故障源的时候，黄花菜都凉了，不仅导致服务长时间的不可用，而且故障随着时间的推移也在不断扩大波及面，问题也越来越难以定位。