0%

一次OOM引发服务雪崩的思考

前几天核心基础服务(简称S,两节点)发生了一次线上故障,导致整个基础服务雪崩,最终,该基础服务故障导致整站多项功能失效;

故障现象

  1. 4:15 开始S的多个上游服务开始出现大量超时,而且出现告警
  2. 4:30 S的节点S1出现OOM停止服务 ,同时告警系统发出了告警信息
  3. 4:50 S的节点S2由于操作系统内存不足被系统kill ,同时告警系统发出了告警信息
    ….
  4. 8:00 运营同学反馈问题,技术同学开始排查
  5. 8:05 技术同学发现S故障,重启S服务,服务正常

原因分析

  1. S的上游应用某定时任务在凌晨4:10请求了大量(一次超过200w)的数据将S1先拖死,导致流量全部到S2,S2逐渐不堪重负,导致被系统kill
  2. S对上游数据请求量没有限制,没有启用限流分组功能
  3. 告警信息没有引起足够重视,告警被忽略
  4. 告警信息仅仅报告给monitor,没有到系统的owner

后续措施

  1. 启用限流,分组功能
  2. 必须严格执行code review
  3. 告警信息必须分级,而且必须同时报告给monitor和系统owner;接警人接到报警后根据不同的级别进行处理

反思

在互联网领域我们为了追求n个9,会采取一系列的流程措施来保障系统的可用性;但,真正落实到位的有多少? 其实,线上故障不可怕,可怕的是没有相应的应对措施;更可怕的是有相应的应对措施,但没有落实到位; 比如: 在服务化推进的过程中架构团队已经提供了限流,分组等功能,而且也进行了宣讲;但,最终这些措施还是没有落实到位;也许这就是大厂和创业公司的区别,大厂里面的架构师大部分也是螺丝钉,只要自己有产出符合预期完成KPI就是一个合格的架构师;但是,创业公司的架构师要考虑更多的因素,从最初的技术方案到设计,实现,最终的落地执行都需要全程参与确保每一个功能真正落实到位