线上问题处理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–