服务器故障排除是一门精细的工艺，但也有一些方法和技巧可以把这件事情变得简单和快速。ITIL方法深入研究如何解决服务器故障或相关问题，但总的主旨是尽可能快速和有效地缩小问题范围。退一步想想如何从逻辑上解决中断期间的问题。例如，如果有用户抱怨不能访问一些东西，看看其他用户有没有相同的问题，这样可以消除本地某个具体终端用户设备问题的可能性。以下全方面指南旨在帮助考虑故障诊断流程和过程。请结合自己的指导原则和技术优势使用。[1]
问题普遍存在吗？
需要的第一条信息是停机或效率变慢发生的范围以及产生了什么样的影响。就像是网络问题可能是因为踩线而影响了一台PC或小的群集。
如果同一问题影响到了多位用户，可以排除环境变量，比如本地PC上的软件误操作或硬件问题。
如果有多个网站，它们全部受影响吗？这样可以确定问题是否在于本地服务器。
是服务器引起的问题吗？
不同的部门之间倾向于相互指责。系统管理员会将服务前台缓慢的应用程序响应归咎于网络；网络管理员抱怨存储区域网络（SAN）；存储管理员指责软件部门。如果正在解决一个问题——尤其是像应用程序变慢这类无法确定原因所在的问题——那么，确定数据中心里哪些区域的基础设施受到了影响。当多个服务器和应用程序发生故障，通常可以排除服务器问题，真正的问题可能来自网络或存储阵列。虚拟化环境中，检查所有受影响的虚拟机的物理主机位置，确保它们没有共享受损的硬件。通过排除，结果最终通常会指向某个明确的罪魁祸首，但并非总是如此。发现问题的共性，尝试不同的因素组合，以缩小可能性。例如，问题可能源于文件共享时复制时间过长。如果在相同站点上，从一台服务器复制到另一台服务器时，是否也很缓慢？如果是的话，可排除广域网络的嫌疑。在服务器上的本地磁盘之间复制过程是否缓慢？如果是的话，可排除SAN或局域网的嫌疑。如果你不得不使用数据包捕获或输入/输出（I/O）速度测试，故障排除可能需要很长时间。[1]
文档
文档是一个非常有价值的故障诊断工具，可轻松访问环境的拓扑，并了解应用程序是如何工作的，使得能够迅速排除服务器问题。
需要有扎实的数据中心操作知识，并拷问自己几个重要的问题：每个应用程序涉及多少台服务器？基本的网络设置是什么？当前是什么基础设施？这些问题很有价值。例如，如果有两台应用服务器供客户端通过循环DNS访问，同时一半用户反馈有问题。从一开始就知道一半的用户连接到各自的服务器，因此不会将时间浪费到另外一台服务器上并试图解决问题。
沟通
沟通是诊断服务器故障的关键。例如同事昨晚更改了服务器设置，结果第二天一些东西无法使用。那么需要了解做了哪些更改，因为这可能就是原因所在。大型企业有正式的改革形势，涉及到每个人，但并不是所有的IT小组都会享受（或者阻碍，这得看你怎么看待这件事了）的。
当一个新的应用程序或其他项目改变投入生产时，沟通可以帮助数据中心团队做好准备并积极地检查环境。否则当终端用户开始抱怨应用无法正常工作的时候，不得不询问新应用程序的部署和资源需求等情况。
监控
在对服务器进行故障排除时，对正在进行的操作进行完整的描述可以帮助节省时间。
市场上有很多监控工具用于不同规模和架构的数据中心。正确配置之后，它们会跟踪关键指标，如延迟和I/O速度等。监控工具还会提醒你潜在的有用的信息，例如一个只剩1%磁盘空间的驱动器将要导致服务器问题。
很多产品还会对服务进行监控，因此如果某个关键服务崩溃或中断，监控工具会发出警告或自动按照已设置的规则尝试重启。
检查日志
令人惊讶的是，服务器和相关的日志常常被忽视。
当出现问题时，技术人员认为他们知道问题出自哪里，并且会花好几个小时来证明他们的正确性。但是如果他们花上几分钟的时间检查一下日志，会发现已记录下来的确切的问题。例如，如果知道正在交互的两件事情以及它们的账户，就能够很容易解决许可问题。
查看微软Windows中的Event Viewer日志或Unix/Linux服务器上的系统记录，这上面显示了警告和错误。应用程序日志也值得一看，因为它们通常包含错误的数据，指向正确的根本方向。
支持
有些管理员调用供应商和日志记录，但最好不要这样做。检查基础事项之后，花几分钟调用日志，而不是直到停机几个小时后再这样做。
在解决事情之前不要着急，检查数据中心供应商支持的服务水平协议。如果供应商直到第二个工作日都没主动联系你，记录问题可以尽早避免一个令人沮丧的夜晚。
许多供应商网上有具体说明如何解决服务器问题。从知识库和在线论坛中检查供应商的资源。
不能排除服务器问题并且在前五分钟内解决问题着实会令人沮丧，但是不要害怕寻求帮助。充足的准备、沟通和对环境的理解是拯救错误的有利工具。[1]
