全站性故障的抢修思考

“润物无声”的故障

很多时候，突然出现的全站大规模故障往往让人措手不及，但是，故障真的是从天而降无法预计到的么？

• 服务器”随机”出现crash：实际上往往是某个版本内核在特定数据包、内核调用时出现的kernel crash

• 应用服务少量的core: 可能受到攻击、滥用导致的panic，也许在某些业务高峰实践会出现大面积的雪崩

作为DevOps的实践，监控和趋势判断是非常重要的基础能力，这需要在监控和数据分析中添加数据分析能力，如果能够融入机器学习，应该能够更为敏锐地发现异常。

备注

任何一位维护线上系统的SRE，都需要非常专注且敏锐都意识，绝对不能忽视系统给我们提供都异常”线索”/

“雪崩”

很多时候，我们在抢修系统时往往会急于恢复全站功能，大批量重启服务以期缩短恢复实践。不过，心中一定要有对全站每个组件能力的预估，或者说，我们重启服务的速度实际上应该不是随机选择的，而是在平时已经经过演练，知道重启速度会对系统的最短板应用的压力。

很多时候，快速启动服务A可能会导致关联的服务B在大量涌入的并发请求中出现雪崩，无法响应，甚至导致连锁的全站瘫痪。

如何解决这个问题，一些想法:

• DevOps的服务重启要通过平台来进行，平台的并发速度要在日常中做过压测

• 通过自动全链路的监控，能够在不断重启的服务及时反馈出阻塞和异常

• 系统要不断优化提供自动反馈来限制操作行为