我们需要收集的系统故障数据汇总

我刚从剑桥回来，是去参加微软研究院达姆施塔特工业大学组织的“系统故障数据的可靠性分析”会议。

微软研究院在剑桥大学附近有一个很棒的实验室。这是我第一次去剑桥，我沉醉在当地的地方特色中。我去了叫做“Eagle”的酒馆，曾在那里，沃森和克里克猛然顿悟，从而发现了DNA双螺旋结构。我还去参观了女王学院旁边叫做“Anchor”的酒馆，那是Pink Floyd乐队的Syd Barrett曾经经常去的酒馆。

当然，不只是逛酒馆喝酒，我们在会议上还有一些很严肃的事情要处理。这次会议的目标是以学术和工业之合力来解决可靠性分析领域的问题。这个问题如今在工业界（以Sun，Cisco，IBM，当然还有Microsoft为代表）来说 ，是已经得到故障数据，但是没有能解决问题的模型和技术。而对于学术界，是有模型和技术，却没有解决全部问题所需要的故障数据。所以这次会议就是尝试能结合这两方，来找出一个解决这个问题的办法。

在我们呈出了我们的意见书（我们实验室的意见书在here）之后，我们就把问题划分为三个步骤：数据收集，数据仓库建立，数据分析。

在数据收集阶段，存在一些争议。我们试图寻找可靠的理由来说明要由最终用户来负责收集数据（而不是像Microsoft，Sun或者IBM这样的软件制作商）。那么让一个IT部门实现一种机制来收集故障数据，这么做的理由是什么呢？

最初，理由似乎看起来很明显――是为了监测故障，同时改正错误。但是一个软件制作商的代表马上站起来说，他们做了收集故障数据的工作，而且为了改正软件错误也正确地使用了这些数据。来自Microsoft的Vince Orgovan在他的论文中提到，差不多4亿的计算机会给Microsoft提供数据。不只是可用数据，还有Windows XP所支持的企业错误报告和其他错误报告，这些都会反馈给Microsoft。它只需要改变一个新的注册码来做这件事情。Windows调试器“！analyze”可以在内部用来处理这些错误数据。

这种做法偏离了我们的想法。如果所有软件都提供这样的机制，那么我们接下来还怎么证明我们的想法？大多数公司都希望把改正错误的问题留给软件制作商（不管是专利软件还是开源软件）！因为软件制作者能够更容易理解软件的部署，从而改正错误。

那么我们为什么还坚持要由最终用户来建立故障数据收集机制，我们所能想到的唯一的有力的理由，就是从用户的角度考虑，这样可以帮助他们更好地部署软件。数据收集机制可以在初期测试的时候就收集错误数据。然后，这些数据反馈到一个模型，用来判断这种软件部署的完备水平。这个模型类似于CMM可靠性模型。我们甚至建议在这周围会有一个ITIL管理。这样，允许ITIL模型不只是测量软件的性能，同时还能测量软件部署的可靠性。

这个原因就本身来说是非常有力的，但是我也不认为这是由最终用户收集故障数据的唯一理由。如果你有什么其他想法，希望能与我们沟通。

开源软件同样存在这类问题。但事实上，并没有一个集中的组织来收集所有的故障数据。开源项目这种情况正好是一个反例，这时候故障数据的收集是分散在各个IT部门，而不是在开发者中心集中。究竟这些故障数据将导致怎样的代码修改？我想，或者是预先分析然后发送一个反馈错误或是用户自己在源代码中添加实例。但我的观点就是，最终开源软件系统将会建立一个故障数据中心仓库，就像商业软件卖主建立的一样。

原文链接： [url]http://port25.technet.com/archive/2007/03/07/who-really-needs-to-gather-crash-information-and-what-do-they-need-to-do-with-it.aspx[/url]