运维中故障排查处理

详情描述：

当客户或者玩家遇到服务器运行缓慢情况，运维将会查找问题故障，针对这个故障，业务希望运维能否更快的解决故障的恢复，希望制定优化故障处理流程：
1、优先故障处理过程的时间——”能通过鼠标完成的工作，不要用键盘“
2、提前发现故障，加强监控——“技术早于业务发现问题，监控不仅是报警，还要协助故障定位”
3、完善故障应急方案——“应急方案是较新的、准确的、简单明了的”
4、长远目标：故障自愈——”能固化的操作自动化，能机器做的让机器做“
一：常见处理方法
A：确定故障现象并初判问题影响
在处理故障前，运维人员首先要知道故障现象，故障现象直接决定故障应急方案的制定，这依赖于运维人员需要对应用系统的整体功能有一定的熟悉程度。
确认了故障现象后，才能指导运维人员初判断故障影响。
B：应急恢复
运维较基本的指标就是系统可用性，应急恢复的时效性是系统可用性的关键指标。
有了上述故障现象与影响的判断后，就可以制定故障应急操作，故障应急有很多，比如：
 服务整体性能下降或异常，可以考虑重启服务；
 应用做过变更，可以考虑是否需要回切变更；
 资源不足，可以考虑应急扩容；
 应用性能问题，可以考虑调整应用参数、日志参数；
 数据库繁忙，可以考虑通过数据库快照分析，优化SQL；
 应用功能设计有误，可以考虑紧急关闭功能菜单；
C：快速定位故障原因
 1：是否为偶发性、是否可重现
故障现象是否可以重现，对于快速解决问题很重要，能重现说明总会有办法或工具帮助我们定位到问题原因，而且能重现的故障往往可能是服务异常、变更等工作导致的问题。
但，如果故障是偶发性的，是有极小概率出现的，则比较难排查，这依赖于系统是否有足够的故障期间的现场信息来决定是否可以定位到总是原因
2：是否可缩小范围
一方面应用系统提倡解耦，一支交易会流经不同的应用系统及模块；另一方面，故障可能由于应用、系统软件、硬件、网络等环节的问题。在排查故障原因时应该避免全面性的排查，建议先把问题范围缩小到一定程序后再开始协调关联团队排查。
3：关联方配合分析问题
避免同时各关联团队同时无头绪的排查的同时，对于牵头方在缩小范围后需要开放的态度去请求关联方配合定位，而对于关联方则需要有积极配合的工作态度。
4：是否有足够的日志
定位故障原因，较常用的方法就是分析应用日志，对运维人员不仅需要知道业务功能对应哪个服务进程，还要知道这个服务进程对应的哪些应用日志，并具备一些简单的应用日志异常错误的判断能力。
5：是否有core或dump等文件
故障期间的系统现场很重要，这个在故障应急前建议在有条件的情况下留下系统现场的文件，比如CORE\DUMP，或TRACE采集信息等，备份好一些可能被覆盖的日志等。
二：完善监控
1：从监控可视化上完善
完善的监控策略需要有统一的可视化操作界面，在制定完善的监控策略后，故障处理人员需要能够快速的看到相应的运行数据，比如：能够看到一段时间的趋势、故障期间的数据表现、性能分析的情况等等数据，且这些数据可以提前制定好策略直接推出分析结果给故障处理人员，这样就大大提高了故障的处理效率
交易性能数据：平均交易耗时、系统内部模块交易耗时（IVR交易耗时、接口总线交易耗时）、关联系统交易耗时（核心交易耗时、工单系统交易耗时等）
-重要交易指标数据：交易量、IVR交易量、话务量、座席通话率、核心交易笔数、工单等系统交易量
-交易异常情况数据：交易成功率、失败率、错误码较多交易
-按服务器分析交易数据：按server统计各服务交易处理笔数，交易总耗时
有了以上交易数据，并通过监控按一定频率统计，运维人员在出现故障时，通过鼠标即点击即可看到故障什么时候开始，是系统内部有问题还是关联系统有问题，较突出的交易是哪一支，各服务器交易量是否均衡等情况。
2：从监控面上完善
监控较基本的工作就是实现对负载均衡设备、网络设备、服务器、存储设备、安全设备、数据库、中间件及应用软件等IT资源的全面监控管理。在应用软件类的监控工作中，不仅需要有服务进程、端口等监控，还需要有业务、交易层的监控。
全面性的应用监控可以让故障提前预警，并保存了影响应用运行环境的数据，以缩短故障处理时间。
3：从监控告警上完善
完善的监控策略需要有清晰的监控告警提示，值班人员要以根据监控告警即可作出简单的问题定位与应急处理方案。
4：从监控分析上完善
完善的监控策略不仅需要有实时的数据告警，也要有汇总数据的分析告警,实时数据分析的告警的重要性不用多说，对于汇总分析的数据则能发现潜在风险，同时也为分析疑难杂症提供帮忙
5：从监控主动性上完善
监控不仅仅是报警，它还可以做得更多，只要我们想办法赋予它主动解决事件的规则，它便有为管理员处理故障的能力。
能知道这个服务影响什么业务，服务涉及的日志、程序、配置文件在哪里