Welcome everyone

正确应对线上问题

工作 汪明鑫 307浏览 0评论

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

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

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

 

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

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

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

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

 

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

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

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

 

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

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

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

 

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

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

 

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

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

 

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

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

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

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

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

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

 

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

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

 

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

喜欢 (12)

说点什么

您将是第一位评论人!

提醒
avatar
wpDiscuz