线上问题的思考
线上问题的思考
# 问题法则
牢记两个问题法则：
墨菲定律：如果事情有变坏的可能，不管这种可能性有多小，它总会发生。
海恩法则：每一起严重事故的背后，必然有29次轻微事故和300起未遂先兆以及1000起事故隐患。
# 应急原则
止损：第一时间恢复系统，而不是彻底解决问题，快速止损；
升级：财产损失，要第一时间升级；
求援：当前负责人不能短时间内解决问题，立马求援；
归档：处理过程在不影响用户体验的前提下，保留现场（error log、dump文件）；
心态：稳住情绪，包括自己和用户，包括事前和事后；
# 处理流程
# 一、发现问题
发现问题的途径：
1.主动发现问题
1.定期巡检
2.监控项检查
3.迭代开发、测试
2.系统监控报警
1.服务器监控：CPU、内存、磁盘、网络等
2.数据库：慢SQL、死锁等
3.中间件：MQ、Redis、RPC等
4.应用：线程、GC、连接池等
3.业务监控报警
1.可用率降低
2.流量异常
3.业务阈值
4.相关系统追溯
1.下游依赖系统问题追踪
5.生产事件上报
1.用户反馈
# 二、定位问题
定位问题的过程：收集—>假设—>验证—>尝试
1.收集：收集线上信息：问题描述、截图、视频、操作日志、日志、dump文件等；
最近新版本的发布情况
本服务的异常/error日志
本服务的调用量变化情况，是否存在暴涨？
本服务的时延，是否出现突然增大？
服务器TCP的连接情况？
服务器的cpu使用率，是否突然飙升？
服务器的磁盘，空间是否已经用完？
服务器的内存，内存是否爆掉？
数据库或者存储是否挂掉？
2.假设：产生怀疑点；
新版本发布有问题
潜在的程序bug被激发，比如在访问量暴增的情况下，并发bug被激发
业务量暴涨
上下游服务调用异常，服务宕机
网络问题
服务器故障，如磁盘满，内存等
应用故障
数据库故障
。。。
3.验证：进行推理排查验证
4.尝试：尝试复现
很多故障并不是由于单一原因造成的，而是多个条件同时满足时才出现的，所以，需要多收集信息，综合得到的信息，产生怀疑点，快速推理和验证，最后找到问题点，定位到故障。这个过程中可以集合大家的力量，并行去check各个点，并快速反馈信息。
故障定位是一个不断‘收集--假设--验证--尝试’的循环过程，不过对于问题的定位仍需要做到“迅速”；
# 三、评估影响
影响用户数
严重程度
严重程度 描述 处理方式
致命：最高级别，系统或服务完全停止或无法使用：立即采取紧急措施进行解决
严重：次高级别，系统或服务部分停止或使用受限：尽快地采取措施进行解决
一般：一般级别，系统或服务的使用没有明显的影响：但需要在合理的时间内进行处理，以防发展成更高级别的故障
轻微：最低级别，不影响系统或服务使用的小问题或异常：日常维护过程中逐步处理
# 四、 解决问题
问题分类
▪质量问题：系统问题、数据问题
▪环境问题：网络、机器
▪设置问题：配置问题
▪使用问题：客户使用问题
解决问题
修复上线：紧急修复，对应影响较小的非紧急bug，正常修复验证发布上线；
限流降级：定位到某些服务有异常，但不清楚异常出现的原因，直接将这些服务降级，确保其他服务不受影响；
紧急扩容：无法定位到是哪些服务造成的，服务器资源飙升，扛不住压力时，紧急扩容服务器；比如恶意攻击、营销活动，秒杀等场景带来的突发情况；
回退版本：有新版本发布，但是不能迅速确定是否和新版本有关系，先做版本回退，确保线上服务回到上一个稳定版本。
重启
原则是：确保线上服务快速恢复，不能完全恢复的情况下，确保线上服务尽可能少地受到影响。
# 五、回顾问题
目的是在故障排除后，冷静地回溯整个线上故障的发现/定位/排除过程，找出流程中/架构中/制度中的缺陷，并将该缺陷消灭掉，同时推而广之到其他系统。
问题回顾的最终目标不是为了追责，更重要的是让大家长记性，避免后续再次踩坑；
总结：
1.问题本身
▪架构优化/开发流程优化
▪开发人员工程意识：code review、double check
2.问题处理流程
▪缩短问题发现和定位时间
▪优化问题处理思路和策略
沉淀：
1.流程记录：归档存储经验教训知识库
2.分析报告：
▪分析bug是在哪个阶段引入？是设计阶段、开发阶段、测试阶段？
▪分析bug引入的原因是什么？是流程问题、技术问题、管理问题？
▪处理问题的流程是否合理？是否有问题预警、是否有紧急上线规范？
3.举一反三
▪检查其他的业务是否有同类型的问题，有问题的话提前解决，避免遗漏上线
# 总结
全面的监控体系、完善的日志记录、高效的故障处理机制是线上故障预防及处理的强大保障；