PDF自动化软件故障报告
我们只能修复我们知道的错误。
Brendan Murphy，微软研究院
在软件发布前后，有很多方法可以衡量质量。对于商业和仅供内部使用的产品，最重要的衡量标准是用户对产品质量的感知。不幸的是，感知难以衡量，因此公司尝试通过客户满意度调查和从其客户群收集的故障/行为数据来量化它。本文重点关注从客户现场捕获故障数据的问题。为了探讨相关问题，我借鉴了从 Windows XP 系统收集故障数据中获得的经验，但您在开发内部（非商业）软件时可能面临的问题应该不会有太大差异。
一点历史视角
传统上，计算机公司通过其客户或其自己的服务部门收集故障数据，手动提交错误报告。早在 1970 年代和 1980 年代，许多计算机公司（IBM、Tandem、Digital 等）开始通过电子通信（通常是安全的电话线路）为其客户的计算机提供服务。自动化故障数据收集是一个自然而然的进步：每当计算机/应用程序崩溃时，其故障数据都会被自动收集并发送回制造商，制造商再将其转发给工程部门进行分析。
这些流程最初的重点是解决由于产品未执行其“宣传”功能而发生的故障（即，软件错误导致的系统崩溃）。然而，正如现任微软湾区研究中心主管 Jim Gray 在其对 Tandem 系统上发生的故障的分析中发现的那样，很大一部分客户故障是由于用户操作造成的，通常归类为 HCI（人机交互）故障（1985 年至 1990 年间 Tandem 系统可用性普查，《IEEE Transactions on Reliability》39,4: 409-418）。尽管 Tandem 系统由训练有素的人员管理和服务，但情况仍然如此。HCI 和复杂故障（例如由系统错误重新配置引起的故障）的根本原因很难诊断，尤其是在收集过程主要关注崩溃转储等故障数据时。因此，这些流程（以及内部故障管理系统）必须不断发展，以提高工程师诊断所有系统故障原因的能力。
在 1990 年代后期之前，收集故障数据的传统方法依赖于公司拥有自己的服务部门，并开发和维护与用户沟通的方式。今天，互联网为任何规模的软件生产商提供了一种经济实惠的与用户沟通的方法。
似乎所有公司都应该开发一个流程来收集客户故障数据并分发补丁以修复任何问题，这似乎是显而易见的。这样的流程对软件生产商和最终用户都有利。不幸的是，考虑不周的流程可能会产生大量无法分析的数据，同时还会疏远客户群。以下故事就是一个很好的例子，说明事情可能会出错。
DEC（数字设备公司）希望更好地了解系统管理员为何重启（对于每次崩溃，系统将重启 10 次）。在系统重启期间，“为何重启”进程会询问系统管理员重启的原因。响应被捕获在 DEC 随后收集的系统事件日志中。当该流程推广到少数几个站点时，问题变得显而易见。
DEC 的大多数客户将其服务器设置为自动重启；尽管这并不完美，但它通常确实可以解决问题（如果故障是由于系统因软件泄漏或老化而耗尽资源而发生的，那么重启将释放这些资源——至少在短时间内，从而允许使用计算机）。当系统管理员无法 24/7 全天候工作时，自动重启尤其有用。“为何重启”进程阻止了系统重启，因为它需要系统管理员的输入。这导致了长时间的中断。即使系统管理员在场，“为何重启”仍然会造成问题。在集群上安装新应用程序可能需要按顺序重启多台计算机。在每次重启期间，系统管理员都必须在控制台前等待以回答“为何重启”问题。自然，系统管理员不愿意非常准确地回答这个问题（通常该字段为空，或者填充了神秘或不太礼貌的评论）。
“为何重启”程序虽然由经验丰富的计算机制造商开发，但它是一个流程的示例，该流程开发和部署成本高昂，收集了无法操作的数据，并且惹恼了客户。因此问题是：需要考虑哪些问题以避免此类灾难？
了解您的用户群和使用情况概况
务必确保从客户群收集的任何数据都是公正的，或者至少要了解任何偏差。有些用户非常擅长填写错误报告；他们通常技术能力强，并且愿意经历有时繁琐且耗时的填写报告过程。尽管这些用户非常宝贵，但他们不一定代表用户群（产品针对家庭用户的程度越高，这些用户的代表性就越差）。因此，为了确保获得公正的数据集，任何流程的用户界面都必须面向普通用户，并应确保
• 用户界面应尽可能简单；对于普通用户来说，单击一下按钮是最大可接受程度。
• 数据收集请求必须在不会惹恼用户的时间发生。
• 用户将看到每个数据请求；否则，他们可能会对该流程产生不信任感，可能将其视为间谍软件的一种形式，并将其关闭。
• 该流程必须尊重用户隐私；否则，用户将不愿提供任何信息。
只有在充分了解您的产品的使用情况概况后，才能实现这些目标。如果产品在商业和家庭环境中使用，那么您的流程可能需要适应不同的市场。此外，如果产品可以在客户端或服务器环境中使用，则界面应根据使用情况的上下文而变化。对于客户端环境中发生的故障，数据请求应向当前用户发出；对于服务器，请求必须重定向到系统管理员，并且收集的数据必须通过授权路径。
定义故障概况
当产品不符合其规范时，就会发生故障。这种正式的故障分类并不真正适用于商业产品——用户通常不阅读规范。客户对故障的定义是产品未完成客户期望完成的任务。虽然这种故障分类似乎是无限的，但大多数客户在定义故障时确实会运用常识。因此，崩溃可能不是客户不满的主要原因。用户可能对产品行为（例如需要重启才能纠正操作）、性能故障或令人困惑的行为更加沮丧。
了解产品包在定义故障时也很重要。从工程角度来看，产品受其自身软件的约束。用户可能会以不同的方式看待问题。例如，如果产品无法打印，那么即使缺陷存在于第三方打印驱动程序或操作系统设置中，用户也可能将其视为产品缺陷。如果计算机上的所有其他产品都能成功打印，则尤其如此。
典型的间接产品故障包括
• 由不合逻辑的输入或以非预期方式使用软件引起的用户界面故障。
• 将软件与不同于建议配置的组件一起使用。
• 损坏存储的硬件故障。
• 驱动程序或从属第三方应用程序中发生的软件故障。
此外，产品的故障概况很少是静态的。修复已知错误的新的补丁以及系统配置和硬件的更改都可能改变环境。对 Windows XP 故障的分析突出了可能的系统配置范围；目前，客户站点上有超过 800,000 种不同类型的即插即用设备，每天新增 1,500 种设备。此外，还有 31,000 个独特的驱动程序，每天新增 9 个（每个驱动程序在现场大约有 3.5 个版本，每天发布 88 个新驱动程序版本）。雪上加霜的是，普通客户系统不断变化——平均速度每周增加约 5 兆赫兹。
捕获故障信息
预测诊断故障所需的信息非常困难。您应该假设初始数据集不足以诊断所有可能的故障。因此，该流程应设计为在分发给客户后不断发展。
以下通用数据集有助于诊断大多数产品故障。不幸的是，在实施此列表时，工程师还必须意识到可以从客户站点收集的数据量存在实际限制（本文稍后将讨论）。
在产品转储文件中捕获并在故障点生成的崩溃数据。由于转储文件可能包含系统内存的全部内容，因此通常需要处理转储文件以仅提取最相关的数据。
系统概况，包括产品版本和补丁。产品所依赖的硬件和其他应用程序的版本也很有用。
故障历史记录。这是帮助诊断产品故障的重要因素，特别是系统在故障发生前刚刚发生了什么。许多产品故障是由外部事件引起的（例如，配置更改、系统其他部分的故障等）。
用户输入。一般来说，您应该避免任何手动输入，因为它可能会导致数据倾斜或没有数据（用户可能会对这些请求感到恼火），但是，如果非常偶尔需要其他信息，用户通常很乐意提供。
隐私
确定需要捕获的数据不仅仅是一个技术问题；另一个重要因素是隐私。世界各地的隐私法差异很大，但您应该假设在未经用户许可的情况下收集个人数据是非法的。即使您请求许可，法律问题仍然适用于个人数据的存储和管理方式。因此，对于通用数据收集，任何数据都不应可追溯到最终用户。如果需要将故障数据与用户配置文件相关联，则必须开发不同的数据收集流程，并针对理解和接受该流程的客户。
虽然应避免收集个人数据，但区分多个系统上发生的多个故障和单个系统上发生的多个故障至关重要。这可以通过基于计算机配置构建签名来实现。虽然不完美，因为配置更改会改变签名，但这似乎是最佳的实用解决方案。
处理和收集故障数据
收集故障数据需要一个驻留在客户计算机上的流程，该流程检测进程并传输数据。这可以通过多种方式完成，并且取决于产品的客户群。对于 Windows，此流程通过在安装过程中与用户的对话框启用。系统管理员首次登录系统（在系统重启后）时，操作系统会自动检查系统中断的原因是否是系统崩溃。如果是，它会处理系统转储文件，生成迷你转储和一个 XML 文件，其中包含系统上所有驱动程序的版本。此数据随后被压缩。
然后，屏幕上会出现一个提示，请求用户允许将此数据发送给 Microsoft。如果用户同意，则通过 HTTP POST 发送数据。此方法还允许该流程通过将 http 请求重定向到包含可能解决方案的网页来向用户发送响应（这将在下一节中讨论）。
一些公司可能会限制内部计算机向公司外部发送数据。这使数据收集变得复杂，并且通常需要两阶段流程：一个流程自动将故障数据路由到公司内部的中央系统；第二个流程将此数据发送到场外。在后一种情况下，可能需要第二种类型的报告。此报告将定义建议在所有公司系统上安装的补丁列表。
分析引擎
从客户站点收集的故障数据被馈送到一个流程中，该流程分析、存储数据，并在可能的情况下将信息反馈给最终客户。收集和分析过程必须完全自动化。处理收集的数据，分析引擎应使用一组规则来诊断故障原因。分析引擎由分配用于调试故障的服务和开发工程师不断更新。通过对收集的故障进行分类和存储，可以将工程工作重点放在最常发生的错误上。
在大多数产品中，一小部分缺陷会导致大多数故障。因此，分析最初侧重于这些故障，既要找到解决缺陷的方案（通常是补丁），又要识别此类未来的故障。如果崩溃是由已知缺陷引起的，则报告系统应告知用户补丁的可用性。这种反馈机制鼓励用户提交故障信息。
在 Windows XP 发布后不久，故障严重倾斜。极少数错误导致了大多数客户故障。分析引擎根据系统崩溃的具体位置以及系统上加载的驱动程序识别这些崩溃。最初的重点是生成补丁，并假设这将导致 Windows XP 崩溃总数显着减少。实际上，由这些错误引起的故障率继续增长，迫使我们重新思考我们的补丁分发机制（这将在下一节中讨论）。
然后，Windows 工程师开始遇到不易解决的崩溃类别，并且随着时间的推移，他们开发了几种策略来帮助调试这些故障，具体来说
提高从客户站点收集的数据的质量。例如，Windows XP SP2 将收集更多信息，重点关注硬件（例如，BIOS 版本、ECC 状态和处理器时钟速度以识别超频）。由于 Microsoft 与合作伙伴共享故障数据，因此许多公司现在将制造信息存储在系统中，这些信息作为转储过程的一部分收集（例如，一些制造商存储每个产品的制造日期和安装日期）。
用于识别硬件故障的特殊测试。已编写测试来识别与硬件相关的故障。例如，作为崩溃转储的一部分，捕获了几个包含操作系统代码的内存页。验证这些页面以查看它们是否已损坏。如果已损坏，则可以识别可能的原因并向客户推荐解决方案（例如，如果损坏与硬件相关，则将客户指向硬件内存检查器）。
开发数据挖掘工具以协助故障诊断。工程师被分配到分析引擎认为具有单一原因的一组崩溃。除了崩溃转储中的数据外，工程师还可以使用工具挖掘崩溃数据库以获取其他相关信息（例如，识别其他崩溃分组中特定驱动程序组合的频率）。
随着工程师解决崩溃的原因，分析规则会更新，以识别所有未来此类类型的崩溃。可以通过分析引擎自动解决的 Windows XP 崩溃百分比不断波动。虽然发布补丁是为了解决当前问题，但各种质量的新驱动程序和外围设备不断出现。确定理想的诊断率很困难；诊断高百分比的错误可能只是表明补丁分发过程已中断。
在当前诊断出的 Windows XP 故障中，5% 是 Microsoft 软件错误，12% 是硬件故障造成的，83% 是第三方故障。
图 1 中的饼图提供了硬件和驱动程序崩溃原因的细分。
硬件故障的百分比似乎正在增加，这可能是由于运行 Windows XP 的系统的老化概况造成的（XP 发布时购买的新系统现在已经三年了）。如前所述，第三方驱动程序的故障率随时间变化，因为新版本的流行驱动程序的发布可能会导致故障率增加或减少。
有时，这些问题的解决方案可能令人尴尬。例如，对许多驱动程序崩溃的分析表明，根本原因是驱动程序未检查系统调用后的错误条件。在与开发人员的讨论中，他们说代码是从 Microsoft 驱动程序开发工具包和 MSDN 在线文档的帮助文件中复制的。最初的文档旨在提供如何使用系统调用的简洁示例，因此缺乏错误处理。修复：文档已重写为包含错误条件检查。
补丁分发
Microsoft 分析引擎旨在通过在崩溃签名匹配时提供补丁工具来纠正常见崩溃。一个重要的问题是，是否应通过通用补丁分发流程将补丁分发给所有客户，从而防止其他系统崩溃。开发有效的补丁分发流程非常复杂。以下是在开发成功流程时需要解决的几个因素
补丁质量。即使倾向于尽快发布补丁，尤其是在补丁解决安全缺陷时，也应在分发之前在尽可能多的用户环境中彻底测试补丁。如果补丁随后引起问题，那么客户将不太愿意安装未来的补丁。
版本控制。这是验证哪些补丁已应用于系统所必需的。版本控制在补丁依赖于其他补丁的情况下非常重要，因为版本信息是解决这些依赖关系所必需的。
补丁大小。补丁越小，下载补丁给服务器带来的负载就越小——最终用户下载和安装补丁所需的时间就越少。一个好的测试是补丁是否可以实际由使用 28k 调制解调器的用户下载。
每年补丁数量。为所有已知故障发布尽可能多的补丁似乎是合乎逻辑的，但这可能会给最终用户带来很大的负担。公司必须在发布每个补丁之前对其进行测试和暂存。该流程应仅针对影响明显百分比用户的问题发布补丁。
安装。补丁应通过单击一下按钮进行安装，并尽可能减少对最终用户的影响。
家庭用户的自动部署。对于 Windows，Microsoft 通过自动拉取流程分发补丁（该流程检查 Microsoft 站点以确定是否有关键补丁可用，如果是，则在后台进程中下载它们）。这被认为是将安全补丁部署到尽可能多的用户所必需的。对于非关键应用程序的错误部署，可能更倾向于侵入性较小的补丁分发。
分发方法。补丁可以通过分析引擎或其他流程分发。如果用户运行 Windows 更新，那么他们将看到关键补丁集以及基于系统配置推荐的补丁集。
企业用户的分阶段部署。为了便于管理，一些企业希望其员工运行一组通用的软件，并使用通用版本。为了控制环境，公司可能更喜欢自行分发补丁。作为此过程的一部分，他们将在自己的环境中暂存和测试补丁，然后再进行分发。
补丁分发流程可能是整个流程中最重要的部分，因为如果没有客户随后安装补丁，则生成补丁几乎毫无意义。确保补丁在客户站点安装的一种可能方法是鼓励计算机制造商在其构建过程中预安装所有补丁。
错误报告系统始终在变化
成功的错误报告系统对软件生产商和用户都非常有益。它可以让人们很好地了解公司产品的质量，同时为客户提供更好的用户体验。然而，开发这样的流程很复杂，如果做得不正确，可能会对客户满意度造成更大的损害。
开发故障报告系统需要了解产品的客户群以及使用情况概况。同样重要的是，您要了解产品的故障概况，以便您可以专注于最让客户烦恼的事件。尽管产品属性是独一无二的，但如果收集到一组通用数据，将有助于诊断故障。但是，在收集客户数据时，您必须在推出流程之前解决所有隐私问题。除了故障收集系统之外，您还需要一个可以分发补丁以解决这些故障的流程。
在 Microsoft，我们的经验使我们开发了一种通用方法来处理、传输、分析和响应客户故障数据。此流程的实施方式存在差异；它通常取决于产品类型及其故障概况。
虽然此系统的开发对我们的组织非常有益，但计算机的使用情况概况随着其配置的不断发展而不断变化。因此，它们的故障概况永远不会是静态的。因此，无论自动软件故障报告流程多么成功，它始终需要进一步开发。
喜欢还是讨厌？请告诉我们
[email protected] 或 www.acmqueue.com/forums
BRENDAN MURPHY 是英国剑桥微软研究院的研究员，他专门研究系统可靠性，包括故障预测、系统故障管理架构、应用程序可用性以及集群可靠性和可用性。在加入 Microsoft 之前，Murphy 曾在 Compaq 和 Digital 工作。他是纽卡斯尔大学的毕业生。
© 2004 1542-7730/04/1100 $5.00
最初发表于 Queue vol. 2, no. 8—
在 数字图书馆 中评论本文
更多相关文章
Phil Vachon - 王国之钥
一次不幸的手指误操作引发了当前的危机：客户不小心删除了签署新固件更新所需的私钥。他们有一些令人兴奋的新功能要发布，以及通常的一系列可靠性改进。他们的客户越来越不耐烦，但当被问及发布日期时，我的客户不得不拖延。他们如何才能提出一个有意义的日期？他们已经失去了签署新固件版本的能力。
Peter Alvaro, Severine Tymon - 将天才从故障测试中解放出来
本文呼吁分布式系统研究界改进容错测试的最新技术。普通用户需要工具来自动选择要注入的定制故障。我们推测，超级用户选择实验的过程可以在软件中有效地建模。本文描述了一个验证此推测的原型，介绍了来自实验室和现场的早期结果，并确定了可以使这一愿景成为现实的新研究方向。
Pat Helland, Simon Weaver, Ed Harris - 大到不能倒
Web 规模的基础设施意味着大量服务器协同工作，通常是成千上万台服务器都朝着同一个目标努力。如何管理这些环境的复杂性？如何引入通用性和简洁性？
Steve Chessin - 注入错误以获得乐趣和利润
不幸的是，任何带有活动部件的东西最终都会磨损和发生故障，而电子电路也不例外。在这种情况下，当然，活动部件是电子。除了电迁移的磨损机制（移动的电子逐渐将金属原子推离位置，导致导线变细，从而增加其电阻并最终产生开路）和树枝状生长（相邻导线之间的电压差导致位移的金属原子相互迁移，就像磁铁会相互吸引一样，最终导致短路）之外，电子电路也容易受到背景辐射的影响。
© 保留所有权利。