数据中心要全天候运行，难免会出现这样那样的故障。出现故障后，如何迅速找到故障原因并消除故障是一个数据中心运维效率的最直接体现。数据中心一旦发生故障，影响了数据业务，将给数据中心带来巨大的经济损失，有时甚至是毁灭性的打击，所以数据中心都不希望出现任何的故障。当然，愿望是美好的，现实是残酷的，数据中心包含有太多的电子设备和大量的软件，虽然部署了很多的备份技术和设备，但依然很难做到永远都不出故障。那么问题来了，一旦数据中心出现了故障，该如何高效处理？本文将针对如何处理数据中心故障列出八条“军规”，建议遇到数据中心故障时，能遵守这些“军规”，尽量减少故障给数据中心带来的损失，同时避免相同的故障出现第二次。
第一条：摸清故障现象
数据中心的故障表现复杂多样，先要弄清楚故障现象是什么？一般数据中心故障都是先从应用层面表现出来，如果从这些方面开始分析，很容易走错方向。比如：应用部分反馈访问网页慢、支付系统完成不了支付、游戏业务玩不了了等等，这些应用业务的故障表现往往是片面的，不同技术水平的人和不同的业务部门的人反馈的故障现象都有差别，很容易让人不知道该从何查起。这时要对反馈的故障现象进行收集和整理，找出其中的共性。所谓摸清故障现象，就是找出此时数据中心里统一的故障现象。
第二条：测试并确认故障范围
根据故障现象，我们要查看这些故障是否来自于同一台服务器、同一条链路或者是同一台网络设备等。所有的应用业务都是在这些物理硬件设备上运行的，其中的任何一个环节的设备出现故障，都会导致问题。此时，各种网络探测诊断工具就派上用场了。通过使用PING、Tracert、镜像、流量统计、抓包等一系列手段，确定故障位置。经过这样一系列的诊断，可以将故障范围缩小到某一台设备或只有数台设备的网络区域。
第三条：尝试定位
一个经验丰富的数据中心技术人员，往往可以根据故障表现迅速找到故障原因。这时，如果故障影响是可以容忍的，在条件允许的情况下，可以尝试定位问题，试图找到触发此次故障的根本原因。此时技术人员一定要思路清晰，一步步来采集各种信息，深入分析。数据中心里有太多的设备，这些设备来自不同厂家，各自的技术特点也不同，没有哪个数据中心技术人员能全部掌握，如果在短时间内无法定位问题，或者是分析来分析去已经没有任何思路，此时就要放弃继续定位。
第四条：收集故障时必要信息
一定要在故障的时候收集一些设备的日志、诊断、操作记录、内部隐藏信息，很多信息是设备厂家要求在故障时收集的，要按照厂家的要求将信息收集完整，以便这些信息可以供设备厂家分析，日后找出故障发生的原因。很多时候，数据中心的技术人员急于恢复业务，往往忽略收集这些信息，这将为日后定位问题造成了极大难度。
第五条：故障恢复
为了尽快消除故障，需要对故障进行恢复。此时不要上来就对疑似故障的设备直接重启或者更换、下电，这样极有可能会造成更为严重的故障。本来原来的故障可能只是偶尔有访问出错，有丢包，经过设备重启就可能造成整网的业务中断。故障恢复的操作应该从轻到重，逐步来尝试执行。比如路由异常，可以先对特定路由进行删除重建，不行的话，再对某一个邻居进行复位重建，还不行的话再对整个路由协议进行重建，这样一来最严重也是影响这一类路由协议的转发，对其它业务并没有影响。还是不行再考虑重启框式设备的板卡，再不行再考虑重启整机设备，此时也尽量不要断电重启，很多设备只要不是断电重启还是会留下一些有意义的历史记录信息。如果数据中心的各个故障环节都是备份系统，可以暂时将业务迁移到备份系统上来，故障的主用系统继续保留，供技术人员继续排查故障，直到找到故障原因，彻底消除后，再将业务切换回来。
第六条：再次验证业务的正确性
故障恢复后，要再次对数据中心承载的业务进行各种测试，看是否所有的业务都恢复正常，同时与各个业务部门人员交流，确认业务的正确性。当得到准确反馈，所有业务都恢复正常后，再停止业务验证。
第七条：长时间观察
数据中心故障有时会容易反复，尤其是在没有找到故障原因的情况下，所有的故障恢复手段都可能不是很有效的，很可能会再次出现故障。这时要密切关注数据中心业务运行情况，一旦发现异常，及时处理。
第八条：分析故障原因，总结经验教训
故障发生后，在还未明确故障原因的情况下，及时将收集的信息发给设备厂商，协同分析，在事后故障分析上要投入大量的人力、物力，直到找到故障原因。如果无法找到故障原因，对于数据中心是最可怕的事情，很可能会再次发生，造成二次的损失，所以要在故障分析上多投入，直到找到故障原因。找到故障原因后，要对产生这次故障的原因进行深入分析，结合目前数据中心的运行状况，看是否有改进的空间，及时总结故障处理过程中不足的地方，对薄弱环节进行加强，避免同样的故障再次发生。
处理数据中心故障要严格依照这八条“军规”，只有这样才能在遇到故障时，处理起来有章法、高效率，并能够在处理故障的过程中积累实践经验，不断提升数据中心的运维水平。
热门专题
