首先我们如何定义线上问题呢？

个人觉得线上问题分为几类

• 是直接对用户造成使用上的影响（功能性或体验性等）
• 对用户或者平台造成资金损失的
• 对系统本身造成影响的（如对软硬件的影响，内存泄漏等）

其次我们如何以正确的姿态应对线上问题？

遇到线上我们切记不应该直接沉入到代码或者一些细节之中

遇到问题首当其冲的是快速止损，优先从今日变更入手，重启或者回滚，当然是由于流量激增的问题可以考虑扩容

【稳定性三板斧要拿捏的稳稳的 -> 可监控，可回滚，可降级】

所以我们的排查方向也是优先于这些变更，避免大海捞针

还有一点比较关键的是，遇到线上问题，不要偷摸摸自己消化，而是要快速拉群同步上升

基本大多的线上的问题都是因为最近的服务和配置变更导致的

回滚后需要确认业务是否恢复，记录问题出现时间，止损和恢复时间

然后在仔细的去排查，排查的手段无非是监控，日志，arthas，直接去查redis, db，whaterver，用尽一切手段，如果还是排查不到问题

就只能一行行去撸代码了，或者远程连容器一行行调试代码了

如果确认是代码问题，需要考虑修复方案，需要考虑短期的和长期的，也需要考虑当前问题的影响面和人力时间成本等，搞一个当前最佳的修复方案

当然这里如果对用户资金造成了损失，还需要给用户做金额补偿

最后还需要根据问题大小，确定是否为故障，是否达到定级的条件，然后写故障复盘

描述问题的全流程，问题处理过程中还有哪些不足的地方以及后面需要做的事情。

然后就是最关键的我们如何发现问题呢？

需要配置核心链路的监控报警，oncall需要每日巡检监控大盘，

然后有业务异常会通过报警周知组内开发人员，介入排查

这里有个需要注意的地方是监控报警一定不要泛滥，

如果监控太多了，你会发现你压根不知道要关注哪块，眼花缭乱

如果报警多了，就相当于没有报警，狼来了的故事相信大家也都听过。。。

最后我们再聊下，如何尽量保证少出线上问题呢？换句话说是提升我们的研发质量？

• 深入理解需求的细节，最小成本和风险的实现需要，尽量只做有意义的需求
• 核心链路需要可监控，可回滚，可降级
• 功能的可测试性
• 考虑接口流量的大小，考虑读写分离、热点问题和缓存不一致等问题
• 面向失败的设计，考虑上下游依赖
• 恰到好处的监控报警，能够帮你快速发现和定位系统问题和业务异常
• 适当的日志，关键链路、error信息
• 保证系统的可读性和可维护性
• 开关保证新逻辑不影响主流程
• 完善上线checklist

转载请注明：汪明鑫的个人博客 » 正确应对线上问题