首先我们如何定义线上问题呢?
个人觉得线上问题分为几类
- 是直接对用户造成使用上的影响(功能性或体验性等)
- 对用户或者平台造成资金损失的
- 对系统本身造成影响的(如对软硬件的影响,内存泄漏等)
其次我们如何以正确的姿态应对线上问题?
遇到线上我们切记不应该直接沉入到代码或者一些细节之中
遇到问题首当其冲的是快速止损,优先从今日变更入手,重启或者回滚,当然是由于流量激增的问题可以考虑扩容
【稳定性三板斧要拿捏的稳稳的 -> 可监控,可回滚,可降级】
所以我们的排查方向也是优先于这些变更,避免大海捞针
还有一点比较关键的是,遇到线上问题,不要偷摸摸自己消化,而是要快速拉群同步上升
基本大多的线上的问题都是因为最近的服务和配置变更导致的
回滚后需要确认业务是否恢复,记录问题出现时间,止损和恢复时间
然后在仔细的去排查,排查的手段无非是监控,日志,arthas,直接去查redis, db,whaterver,用尽一切手段,如果还是排查不到问题
就只能一行行去撸代码了,或者远程连容器一行行调试代码了
如果确认是代码问题,需要考虑修复方案,需要考虑短期的和长期的,也需要考虑当前问题的影响面和人力时间成本等,搞一个当前最佳的修复方案
当然这里如果对用户资金造成了损失,还需要给用户做金额补偿
最后还需要根据问题大小,确定是否为故障,是否达到定级的条件,然后写故障复盘
描述问题的全流程,问题处理过程中还有哪些不足的地方以及后面需要做的事情。
然后就是最关键的我们如何发现问题呢?
需要配置核心链路的监控报警,oncall需要每日巡检监控大盘,
然后有业务异常会通过报警周知组内开发人员,介入排查
这里有个需要注意的地方是监控报警一定不要泛滥,
如果监控太多了,你会发现你压根不知道要关注哪块,眼花缭乱
如果报警多了,就相当于没有报警,狼来了的故事相信大家也都听过。。。
最后我们再聊下,如何尽量保证少出线上问题呢?换句话说是提升我们的研发质量?
- 深入理解需求的细节,最小成本和风险的实现需要,尽量只做有意义的需求
- 核心链路需要可监控,可回滚,可降级
- 功能的可测试性
- 考虑接口流量的大小,考虑读写分离、热点问题和缓存不一致等问题
- 面向失败的设计,考虑上下游依赖
- 恰到好处的监控报警,能够帮你快速发现和定位系统问题和业务异常
- 适当的日志,关键链路、error信息
- 保证系统的可读性和可维护性
- 开关保证新逻辑不影响主流程
- 完善上线checklist
说点什么
您将是第一位评论人!