线上问题处理SOP
线上出问题如何保证快速响应快速解决,如何设计和防范问题,出问题如何高效处理?
开发是个苦逼的差使,除了保证日常需求如期上线,还需要维护服务运行、保证稳定性,一旦出点问题都是麻烦事。而体现技术价值的也在这里,这是少有的可以技术主导推进的事情。
问题处理原则
5分钟内响应,半小时止损,当天修复完成,3天内复盘。
考核故障的指标不是单看问题大小,最核心指标其实是影响时长,5min内处理完和1个小时处理完完全不是一个量级。举个当年在京东的例子,有一次早上刚上班,空调页面panic了,接到报警开始处理,前后有了差不多3min吧,最后啥事没有,也不需要发故障通报,就是因为有预案、处理快。
一般处理流程
问题发现&初步排查 -> 问题同步 -> 线上止损 -> Bug解决 -> 总结复盘
问题发现&初步排查
发现问题后需要初步定位问题,确定影响面。确定是已知问题还是新增问题:
- 定位问题原因、故障模块
- 确定问题开始时间,是否有对应上线操作
- 确定影响数据量
这步非常关键,和故障的等级强关联,如果有提前准备预案辅助定位分析缩小范围,那么处理就会快很多;当然,处理的人也很关键,需要冷静+果断,尤其是预案不足的情况,不管用什么方案要尽快产出止损方案。
拉群同步
如果影响面较大、问题难定位、或者需要拉人决策,需要拉群、拉会同步信息(业务相关RD、PM、TL、QA)。
不同的角色要有分工:
- 技术专注在故障止损上,QA提前准备上线流程、回归case;
- 业务根据影响面评估进线方案、话术、法务风险;
- 产品需要配合安抚,一方面帮助业务整理故障话术,一方面帮技术隔离无效沟通,让技术专注解决问题;
线上止损
如果确定了止损方案就立刻实施。一般都是上线引入的,回滚上线操作、配置操作、数据库操作。
如果一下子无法完美止损,先尝试部分止损,例如MysQL打满时 kill 慢 SQL,先处理一部分;比如服务端负载被打满,先加限流保证负载降下来,一部分流程能成功。
Bug解决
技术来主导,但是QA把控好质量,建好工单跟进不能不了了之。
- 确认是否需要二次数据修复;
- 默认需要当天修复上线,如果问题较小或者确保不会再发生,可以周知后排期修复;
总结复盘
- 时间线梳理;
- 问题定位工具和方案;
- 如果第一时间是通过Oncall渠道等非技术报警反馈的问题,说明报警设计待优化,需要复盘业务报警,需要确保业务报警及时性;
报警
报警等级要怎么划分?按照报警分业务报警和技术报警来看。
业务报警
业务报警的含义是业务受影响要高优报警 Critical,例如下单失败率过高,下单单量环比下降50%。 制定规则:前期需要根据业务场景制定好规则,所有业务报警都需要高优响应和处理。
技术报警
技术视角的报警,例如网关限流、CPU负载高,它算是业务报警的下钻报警,处理业务报警时要参考技术报警来分析定位。如果只有技术报警而未影响实际业务,我们也就不需要太着急了。 制定规则:按照业务报警拆解,优先对核心接口监控,其次考虑横向展开。
报警 & 监控
报警、监控一般是一起做,不过真有问题看监控肯定来不及,优先要把下钻辅助分析的制作为报警。
响应率
如果只报警不响应,那么报警毫无意义,需要定期Review响应率,业务报警需要100% 5min内响应,技术报警需要95%响应。
- 需要制定好值班计划,并宣导及时响应的要求,如果没有及时响应需要预警backup;
- 也需要关注噪音,核心报警可以按照核心系统数量来估算,系统动线上的关键节点有多少,就对应做多少业务报警,切记不要太多。
原文链接:线上问题处理SOP,转载请注明来源!
–EOF–