我想了解更多关于如何执行根本原因分析。 更多的时候,我们的部门告诉用户尝试重新启动(他们的Windows XP系统),这实际上“修复”了很多问题。 当我匆忙(有时每小时付钱都会对此有所贡献)时,我可能会尝试find解决方法,以便快速解决问题,而不是实际执行根本原因分析。
大部分时间我正在查看日志文件或事件查看器中的这些信息。 有时我会使用Sysinternals工具或者偶尔运行一个数据包嗅探器。 我可能不会像我应该那样使用Sysinternals程序。 关于如何使用这些工具的具体见解,何时以及为什么也会有所帮助。
我知道这是一个悬而未决的问题,但请您简要介绍一下您使用的方法,工具等。 看起来很多SF上的pipe理员使用更深入的过程,我想了解更多。 如果这有助于缩小问题的范围,那么我会对与AD环境中的Windows服务器和客户端相关的工具,提示,技巧等问题感兴趣。
找出问题的根本原因取决于问题 – 你最初的本能去查看日志文件/ sysinternals工具/数据包嗅探器通常是正确的。
我会添加在Windows系统上运行MS恶意软件删除工具和良好的AV程序(并确保他们没有像CyberDefender或其他AV木马恶意软件的东西。
Stack Exchange的人们是“5 Whys”方法的支持者( http://en.wikipedia.org/wiki/5_Whys ,也是这个很好的简短的PDF文件 )。 这是做根本原因分析的一个非常有价值的工具。
除此之外,我会画两大类和我经常问的一些问题/我检查的东西:
神秘的行为与networking无关
例如“Word一直在崩溃”
基本问题要问:
与networking有关的问题
很多是类似的,但有一些更具体的指导。
除了迄今为止的出色答复之外,我还要补充:
确定问题发生的date/时间。 这看起来很明显,但是我看到太多的问题没有logging,后来又做出了不正确的假设。 这与“改变了什么”的步骤很相关。
问题是可重现的还是间歇性的? 这是至关重要的,因为可重复的症状要比那些间歇性的症状更容易和更快解决。 如果它是可重复的,确保步骤被logging。
确定症状。 请注意,我们区分作为根本原因performance的“症状”和实际问题/根本原因。
将问题本地化为可能出现故障的function组件。 如果Web应用程序中存在错误,是应用程序代码,Web服务器,托pipeWeb服务器的操作系统,networking还是远程端? 在这一点上,这是最好的猜测,所以资源集中在可能的原因,所以确保其他人知道这是理论/猜想。
质疑你的假设,并试图收集经验数据来支持假设和结论。 告诉某人x不存在问题的感觉真是不好,后来才发现它确实存在。 通常当有不正确的解决scheme时,可能有数据支持正确的解决scheme。
这听起来像你要求一般的故障排除帮助,如您的故障排除规则,解决方法? 而不是如何做一个特定types的RCA( http://en.wikipedia.org/wiki/Root_cause_analysis )。