到此为止，我也思考自己和所在的团队是否具备线上排障的能力，需要的基础设施是否健全。下面我就这方面的内容展开介绍一下。
1. 现状
在生产环境遇到故障时，你们都是什么样的状况，是否会有下面描述的情形，如果是小公司的话，可能大部分都能遇到，这也是我们目前的现状：
处理故障的责任人不明确，出现等待情况；
支撑混乱，无统一资源调度；
人员响应慢；
无故障处理流程，方法论；
应用日志输出不规范；
故障处理时间长；
无法复盘，找出问题根源；
无总结知识，推而广之；
消息发布无统一口径，影响团队信誉度；
其中，有些是管理的问题，有些是技术和基础设施储备的问题。
2. 原因
导致当前现状的原因有哪些呢，讨论之后也总结了一些：
业务逻辑不熟悉，难以定位问题；
硬件及操作系统了解太少；
部门协调慢；
原因分析不明确，片面，限于表象；
测试环境不具备调试条件；
对于项目业务/技术不熟悉；
人员分工不明确；
缺乏配合人员信息（公司外部系统）；
处理中缺乏消息沟通；
不了解已发现的bug（排查方向）；
监控和处理问题的人员缺少备份；
责任心和对生产问题的重视程度有待提高；
3. 应对措施
针对上面的各种原因，我们可以采取一些措施来改善这种现状：
优先恢复业务；
明确当日值班人员及备份人员；
制定常规的故障处理流程；
制定故障排查顺序；
总结归纳以往故障和问题，形成可查询的问题库（wiki）；
处理故障时，采用约定分工，并行方式处理；
健康性检查和业务拨测；
做好例行检查，最好实现自动化检查；
最好工具，防止误操作；
4. 故障排查方法
这里根据个人经验提供一个故障排查方法，希望能有作用。排查故障的时候，你的大脑再高速运转，思考相关怀疑点，然后进行一一排除，最终定位故障，排除故障。
常见怀疑点：
新版本发布
相关设备或系统（数据库/网络设备/操作系统）升级变化
激发潜在bug（高并发）
业务量暴涨（机器扛不住压力）
下游服务异常
网络问题
服务器故障
有了这些故障怀疑点，这就是我们的目标，一个个排除，一般排除的时候也是按照这个顺序做。定位故障，需要一定的技术和工具辅助。
5. 故障排查所需技术
在实际的故障排除中需要全面的技术能力和完善的基础设施支撑。
5.1. 技术能力
linux命令的能力，常用ping、telnet、netstat、grep、less、top、df、ps等。
jvm相关分析能力，dump内存分析，jstack打印线程堆栈等。
掌握web服务器（tomcat、jetty、nginx、Apache等）。
掌握网络设备（交换机、防火墙、F5等）和基础网络知识（七层协议栈、长连接、短连接等）。
掌握数据库原理（连接池、数据库事务等）。
5.2. 基础设施
现在大部分系统都是分布式系统，部署的机器少则四五台，多则几十台。如果使用人肉支持查询日志，困难可想而知，这时需要日志集中收集平台，比如ELK。
日志的质量问题，日志中必须有关键的信息能够将日志串联起来，单独的一条日志意义是不大的，系统需要引入标准的日志格式化定义。
服务器监控指标，包括cpu、内存、io、tcp连接数、disk、线程数、GC、连接池等，比如工具zabbix和nagios。
服务监控指标，一般使用了分布式服务框架的系统，都会有对服务维度的监控，包括调用服务的错误数、错误率、服务的时延、最大值、平均值、吞吐量等。
服务监控
服务治理，当遇到服务请求量暴增需要对非重点服务进行服务降级时，当遇到下游系统故障需要对服务降级或者隔离时，或者调整机器负载时，这时服务治理系统就派上用场了。
服务治理
业务监控指标，与服务监控相比这个的维度更大，从业务角度能看到公司全局的系统状况，有利于排查系统关联性故障，例如天旦系统。
系统上线历史版本的维护，当遇到需要回退版本时使用，相关工具比如SVN（GIT）和Jenkins。
拥有了这些技术和基础设施，可以帮助我们快速进行线上故障的定位和处理。
6. 总结
为了在遇到线上故障时能够完美地处理，需要各种能力储备。从管理流程到技术人员能力，再到基础运维设施建设都需要完善。想想我们这些系统基本已经健全，但是真正能够运用自如的技术人员好像极少，所以最后人是关键中的关键。
作者：rabbitGYK
链接：https://www.jianshu.com/p/08eae8ad08ac
共同学习，写下你的评论
评论加载中...
作者其他优质文章
