怎么样做Troubleshooting(Root Cause)

      通常开发一个软件后，上线没多长时间，就会一大堆问题。这个时候，如果这个软件你也没有参与开发很深，没有经验，没有相关知识，常常就是一头雾水，不知道从哪下手。更让人郁闷的是，通常这些问题还不一定是软件问题，还包括硬件，环境参数等，这个时必须沿着一定的思路，也就是必须按照一定方法论进行排错，才有可能找到最终的Root Cause.

      讲方法论，有些人就会说我不想听这种假大空的理论。相信很多人特别是支持团队的哥们在工作中经常需要进行troubleshooting，很多人可能会说，经验是非常重要的。没有经验，Knowledge也是重要的,当然也有不少的例子是天马行空的试一试，然后反过来进行推理出root cause. 但是不管这个issue的表象多么复杂，它最终都是在一种或者多种因素作用的结果。它不是化学反应的结果，也不是物理反应的结果，它一定是数学计算的结果。为什么这么说呢，因为目前我们的计算机原理使用的还是数学推理逻辑。而数学逻辑原则通常都是固定的。有固定的数学推理规则，就必然可以用一定的方法得出期望的结果当然也可能得不到期望的结果。也就说通常需要去做troubleshooting的，都是你使用了一定的方法，但是得到不想要的结果。这个时候，你来进行分析，那肯定是要研究这些方法是否满足这些方法适用的规则的。那有些人肯定会问，现在的软件多么的复杂，当中使用的你所说的软件方法或者规则那是五花八门，怎么去一一检查呢。但是现代软件经过这么长时间的发展，目前也开始出现一些共性，基于这些共性，也就是我所说的方法论一定能够在troubleshooting事半功倍。

     现代软件有哪些共性呢？一个软件，开发者开发完代码，拿到客户进行安装配置，就开始工作了。这其中开发者通常都是只负责一小部分，而且让开发者直接去客户现场解决问题也是完全不现实的。因此需要大量的支持人员或者使用人员去解决软件问题。那么对使用者来说，出现问题的第一表象是什么呢？可能主要有以下两种：

1）GUI，图形界面显示出错结果，现在比较好软件通常都会给出一定的错误提示，这些提示可能会直接帮助你进行修正，但是也有一些只是一些错误代码，需要你去查相关的使用手册。

2）CML, 没有图形界面操作，比喻命令行返回一个错误，屏幕打印出一堆文本告诉。正在运行的某个服务或者进程突然不工作了，现代软件通常都有日志记录功能，将错误记录下来。