解决问题或排查故障的一般思路
- 2024-06-03 12:30:39
- 丁国栋
- 原创 262
解决问题或排查故障的一般思路包括以下几个步骤：
- 确认故障现象：首先要明确故障的现象和表现，这可以通过用户的反馈或观察到的系统行为来获取。需要收集问题或故障的具体信息，如明显报错、信息提示、日志记录等。确认问题是否普遍，之前是否有问题，最近是否有过改动。
- 复现故障：在确认故障现象后，要尽可能的复现故障。要确认故障是否是可复现的。通过复现故障可以更好地理解问题的本质，并且为后续的排查工作提供指导。
- 故障定位：在确认故障存在后，需要找到问题的发生点，到底是哪一个具体位置发生了问题。可以从硬件、软件、配置和数据等方面入手，逐步缩小排查的范围。可以利用一些排查工具和技术，如日志分析、调试工具等。
- 根因分析：问题的原因分为间接原因、直接原因和根本原因。间接原因是诱因，直接原因是表面，根本原因是深层原因。需要进行根因分析，即确定故障的根本原因，可以利用5W分析法（多问个为什么）找到问题的根本原因。
- 解决问题：一旦确定了故障的根本原因，就可以采取相应的措施来解决问题。这可能包括修改配置、修复软件漏洞、更换硬件等。需要在解决问题之后进行验证，确保故障已经得到解决。
- 故障总结：在解决问题后，需要对整个故障进行总结和分析。可以记录故障的原因、解决方法及所花费的时间和资源等。这有助于提高故障排查的效率和质量，并为类似的故障提供参考。
基本原则：
- 优先解决问题和恢复使用，不要让故障持续进行。例如快速回滚和适时重启，（但是重启系统是一个危险的操作），重启之前必须要明白可能导致的后果和带来的任何影响。
- 通过缩小问题范围来确认问题发生点。了解问题是否是普遍存在，先外部后内部，利用排除法、类比法、替换法（隔离法）、二分法等将故障范围逐渐缩小到某一点。
- 谨慎做出结论。下结论前先三思，想到所有可能存在问题的点，特别是与别人讨论和描述问题时更应该注意。不要把话说死，留出一定的余地。注意哪些是观点哪些是事实，尽量陈述事实而不是发表观点。
- 记录问题。做好文档备案工作，如记录故障现象、故障分析、故障原因、处理流程、处理结果、结论与经验等。
5W分析法
- What? 是什么？首先明确问题的表述，描述现象“发生了什么”。
- Why? 探究导致问题发生的直接原因，问“为什么会这样”。
- Why? 继续深入，追问导致直接原因的根本原因，再次问“为什么会这样”。
- Why? 重复询问“为什么”，一层层分析问题的根源。
- Why? 再一次追问"为什么"，力图找到问题发生的根本原因。
常见案例
案例1：“XXX网页不能访问了 或 XXX服务连不上了”，例如收到服务告警或者客户向服务台反馈 https://www.example.com/ 无法打开了，或者 123.123.123.123:6443 上的服务连不上了。
注：工程师作为服务台技术支持必须有足够知识储备和解决问题的能力，提供专业的服务 。
确认故障现象：
用户用PC端浏览器无法打开 Internet 上的 https://www.example.com/ 网站（故障确实存在，且之前是好用的（最近也没上新没改动）。其他人也打不开，更换客户端或网络也打不开，说明是个普遍问题，不是个例问题，换句话说问题是出现在服务端而不是客户端）
复现故障：
使用浏览器尝试打开 https://www.example.com/ 网站，发现确实访问不到（在服务台侧（工程师排查问题的地方）测试确实也存在问题）。
故障定位：
（前提是工程师需要对访问链路和系统架构非常熟悉）在服务端本地测试，观察是否可以访问，如果服务端本地也无法访问，说明服务本身就有问题，需要检查服务状态是否在运行中，端口是否在监听中，如果服务运行中且没有错误日志则考虑检查防火墙、安全规则、安全策略、防护策略等。通过对该服务所在的主机的监控，查询故障时间段内主机或者系统的负载情况（包括CPU、内存、网络、磁盘等）。此处假设问题是服务没有正常运行，且服务没有异常日志。
根因分析：
已知问题是由于服务没有正常运行导致的，而通过服务日志却没有找到有用的信息。此时应该去查看操作系统的日志，通过操作系统日志去检查是否有OOM（Out of Memory超出内存），辅以登录日志和操作日志确定没有更改。如果是超出了内存，则考虑增加内存资源或者优化应用代码降低内存的占用和内存泄露。
解决问题：
通过重新启动服务恢复访问。为了避免后续再次出现问题，通过编写脚本来检测服务是否运行中，如果不是运行中则尝试重新启动服务并发出告警。
故障总结：
根据问题的根本原因，通过监控和自动化的手段来保障应用的运行。
启示和技巧：
- 重要服务应该添加监控和告警，当服务发生异常或者有异常趋势时能通知维护者去解决；
- 通过监控可以准确的判断出服务异常的时间和恢复用时；
- 重要的服务应该有健康检查和恢复机制，通过健康检查确定服务是否是运行中，通过恢复机制能将失败的服务快速拉起，通过告警通知将服务的情况告知给维护者；
