PDF错误信息：问题出在哪里？
现实世界中的困境故事揭示了一些问题
Paul P. Maglio 和 Eser Kandogan，IBM 研究院
计算机用户花费大量时间追查错误——沿着从错误信息开始的线索，有时会找到解决方案，有时会感到沮丧。对于系统管理员（sysadmins）来说，错误信息的问题尤其严重——他们负责配置、安装、管理和维护现代世界的计算基础设施——他们花费大量精力来保持计算机在错误和故障中运行。
在过去的几年里，我们花时间观察了系统管理员的问题和实践，发现他们经常因错误信息而感到沮丧或被误导。事实上，我们的数据表明，系统管理员多达 25% 的时间可能花费在追随由结构不良和不清晰的信息提示的死胡同上。1 我们希望，一旦开发人员了解最终用户（如系统管理员）花费多少时间处理错误信息，以及错误信息如何塑造解决问题的行为，他们将花费更多时间来精心设计信息，以努力提高整体生产力。
在本文中，我们详细介绍了系统管理员寻找特定错误原因的两个例子。在一个案例中，错误和信息状态消息误导了我们的系统管理员，而在另一个案例中，这些消息可能有所帮助，但只是偶然地。由于系统如此庞大而复杂，个别错误的报告地点通常远离其初始原因。错误报告和错误根源之间缺乏协调常常导致人们对根本原因做出不正确的推理。对系统管理员（和其他用户）的一个简单帮助是在上下文中报告错误。
系统管理
系统管理员设计、配置、排除故障和维护复杂的计算机系统，这些系统由数十个组件（例如，数据库管理系统、Web 服务器、应用服务器和负载均衡器）和数百台分布在多个网络和操作系统平台上的服务器组成。由于现代生活的计算基础设施依赖于系统管理员几乎完美地完成他们的工作，因此在大型系统的背景下研究人为错误和问题解决非常重要。虽然人们经常因系统故障而受到责备，2 但我们必须认识到，系统管理员的工作对其从业者提出了很高的认知要求——他们必须排除系统故障，通过控制数千个配置设置并执行数百个步骤的任务，来理解数百万条日志条目（包含错误、警告和信息状态消息）。系统管理员的工作也对其从业者提出了很高的社交要求，他们需要人际交往能力才能有效地沟通，从而快速解决问题。
尽管系统管理员非常重要，但很少有研究报告他们的具体活动和实践。3 由于缺乏对这个关键用户群体的深入研究，我们在大型企业数据中心进行了实地研究，观察了各种系统管理员的组织、工作实践、工具和问题解决策略。4 就我们的目的而言，实地研究提供了对工作的深入了解，这些了解无法仅在焦点小组、实验室研究或调查中找到，因为它们可以向我们展示在孤立的实验室环境中看不到的日常人际互动，尤其是在问题解决方面。
我们在大型工业服务交付中心对数据库和 Web 系统管理员进行了七项实地研究。每次访问都有两名研究人员参与，持续三到五天。通常，我们每天跟踪一名系统管理员，观察他们在办公室工作、参加会议等等。一名研究人员做笔记并偶尔提问，另一名研究人员则录制系统管理员与计算机、其他人以及信息来源互动的视频。我们要求参与者在工作时大声说出他们的想法，他们经常这样做。我们收集了物理和电子材料，并拍摄了工作环境中人工制品的照片。我们记录、回顾和分析了大约 200 小时的视频。
现在，我们转向两个问题解决示例，这些示例说明了系统管理员在使用错误和其他系统消息方面的经验。（产品、客户和系统管理员的详细信息已被模糊处理，以删除任何识别信息。）
示例 1：“我有点困惑”
在第一个示例中，客户安装了用于提供安全数据交付的软件。该软件包含两个部分：在一个服务器上运行的播放器实例和在另一个服务器上运行的指挥家实例。通过播放器实例，可以建立到后端数据服务器的“连接点”，这些服务器为应用程序提供数据。服务器之间的通信通过防火墙控制的端口进行。客户要求添加第二个播放器以提高性能。5 这项工作包括创建新的播放器实例，配置防火墙以允许指挥家和新播放器实例之间进行通信，以及为后端服务器设置连接点。
我们的系统管理员 George 开始工作时，首先确认网络团队已配置防火墙以打开端口（从播放器实例到指挥家实例的 7137 端口，以及反方向的 7236 端口）。然后，他从文档中复制了创建新播放器实例的命令，并将其粘贴到命令行中
m_web create inst2 –m 7137
该命令没有返回错误，因此 George 启动了指挥家的命令处理器，然后请求播放器实例列表
m_admin> server task mplayer list
…
mplayer_inst2
…
确信新播放器实例在列表中后，他为 IP 地址为 1.2.3.4 的后端服务器添加了一个连接点 (/jump)
m_admin> server mplayer_inst2 add –t tcp –h 1.2.3.4 –I –s –b ignore /jump
此命令失败
Could not perform the administration request.
Error: Could not connect to server (status: 0x1234A123)
在多次尝试解决错误但未成功后，George 需要帮助。通过他的经理，他联系了客户解决方案的架构师 Adam。他通过电话向 Adam 描述了问题
我在与原始实例相同的服务器中创建了第二个播放器实例。那里没有问题。当我尝试从该实例创建到后端服务器的连接点时，它给了我一条消息，类似于“找不到服务器”或“无法连接到服务器”。我确保它正在运行。我不确定为什么它不接受连接点。这不是服务器的问题。这是附加实例的问题。
然后 George 在网上搜索了有关该错误的更多信息，并向 Adam 朗读了他找到的内容
Error: 0x1234A123 (305439011) Could not connect to server
Action: Make sure the server is running and accepting connections.
Name: m_s_socket_connectnot
注意到这表明套接字存在问题，Adam 告诉 George 这可能是连接问题。George 同意了
没错，但我不明白为什么。我执行服务器列表，它显示它在那里。我执行 m_status，它显示它正在运行。我对服务器执行 grep，可以看到该进程。所以我知道它正在运行。
George 认为实例创建是成功的，因为 m_web create 命令已成功，并且服务器列表命令显示了服务器。实例创建的表面成功以及原始错误消息的歧义导致 George 认为连接问题可能与他在各种消息中看到的新播放器实例的不同引用有关。
在 m_web create 命令中，他将 inst2 指定为新实例的名称。然而，服务器列表命令的输出显示 mplayer_inst2 作为实例名称。当他运行 m_status 时，服务器名称显示为 workplace_mplayer_inst2。在检查配置文件时，他看到了播放器实例名称的另一个变体。George 向 Adam 提出了他对这些差异的担忧
我有点困惑。我认为问题可能在于命名约定中的差异。你知道，我在不同的地方看到不同的名称。
Adam 建议他尝试另一个命令来创建实例。然而，这一次，George 替换了他看到的服务器名称的变体，并且他收到了不同的错误消息
Could not perform the administration request.
Error: Server not found (status: 0x1256A123)
起初，George 认为这是相同的错误消息，并将其报告给 Adam。然而，几秒钟后，George 意识到该消息是立即报告的，而之前，这需要一段时间。他告诉 Adam
这个立即返回——几乎是立即，所以它根本不喜欢这样。另一个会停顿一会儿，然后再返回。
Adam 和 George 决定查看日志文件。Adam 注意到一些错误并询问 George。George 说
恢复失败，恢复失败。我们在我们环境中的所有播放器实例中都看到了这一点。这与防火墙超时有关。但这并不是导致此问题的原因。
George 和 Adam 都没有注意到的是日志文件中以隐晦的方式报告的套接字故障（gsk_secure_soc_write failed），它混杂在数千条其他消息中。这些错误与 George 习惯看到的典型“恢复失败”错误混在一起，这可能导致他忽略了套接字消息。
问题最终由 George 的同事解决，他发现指挥家试图在 7137 端口上与播放器通信——但防火墙仅在该端口的相反方向（播放器到指挥家）打开。George（和其他人）花了将近三个小时来设置第二个播放器实例，这项工作本应只需几分钟。
许多因素对 George 不利：首先，问题没有立即被检测到（当创建播放器实例时），而是在稍后才显现出来（当创建后端连接点时）。其次，错误消息没有指定哪个系统无法与哪个其他系统通信（只是简单地说“无法连接到服务器”）。第三，系统的不同部分使用不同的名称（包括 inst2、mplayer_inst2 和 workplace_mplayer_inst2）来引用播放器实例。第四，日志中充斥着“正常错误”，这使得 George 和 Adam 难以识别可能有所帮助的特定消息（关于套接字故障）。最后，从错误消息提供的线索中发现配置错误的端口和防火墙非常困难。
示例 2：“我正式放弃”
在我们的第二个示例中，一位客户升级了他们的 webmonitor 应用程序，但随后抱怨无法通过该应用程序查看对象空间。我们的系统管理员 John 开始尝试验证客户的投诉。为了访问远程机器 olympus 上的 webmonitor 应用程序，John 首先必须连接到中间机器 liaison，从中他可以通过基于 Web 的界面或直接在控制台中键入的命令行命令查看对象空间。John 可以使用两个登录帐户中的任何一个连接到 liaison，每个帐户都具有不同的访问权限。起初，John 只知道一个登录帐户。为了尝试查看对象空间，John 首先通过 Web 界面登录到 webmonitor，但这导致了一个错误
操作未授权
为了解决这个问题，John 尝试 telnet 到 olympus，以通过命令行查询直接检查对象空间。然而，当他尝试使用 telnet 客户端时，他发现 olympus 没有连接设置，并且他无法创建新连接——多次尝试都无声地失败了。
然后，他尝试通过重启应用程序来验证 webmonitor 是否正常运行。重启可以解决许多计算机问题，因为停止会消除损坏的状态，而重启会创建已知的、工作状态。然而，在尝试重启时，John 遇到了另一个问题：webmonitor 的设置需要有关系统的特定信息，例如数据库设置，而 John 不知道这些信息。为了找到这些信息，他必须从 olympus 执行命令行查询。John 再次尝试 telnet 到服务器，但仍然无法创建连接。
所有这些问题都阻止 John 验证对象空间是否存在——这使他难以确定问题是在前端 webmonitor 界面还是在后端对象空间中。此外，由于 John 无法访问重启 webmonitor 所需的数据库设置，他无法知道简单的重启是否能解决问题。
后来，John 在一封旧电子邮件消息中发现，他的团队有两个登录帐户可以连接到 liaison。他使用另一个帐户重新连接到 liaison，这次 telnet 客户端列出了到 olympus 的可能连接。连接到 olympus 后，John 运行数据库查询以检索重新配置 webmonitor 所需的数据库设置，并确认对象空间确实存在于 olympus 上。
在登录以执行命令行查询时，John 错误地输入了他的登录名，这导致了以下错误
Login failed. You have used an invalid username, login, or client certificate.
这条消息使 John 怀疑无效的证书可能是客户问题的原因。他启用了 webmonitor 以自动下载所有必需的证书。重启后，行为没有改变。为了验证证书是否是查看 olympus 上的应用程序对象空间所必需的，John 重命名了 olympus 证书，并通过命令行查询了对象空间。名称更改没有影响对象空间，因此 John 将证书恢复为其原始名称。根据同事的建议，John 随后从类似的服务器复制了证书，并将它们添加到 olympus 上现有的证书中。他再次检查这是否解决了问题，但没有。
再次重启 webmonitor 后，John 在网上搜索了更多信息。由于找不到任何有用的信息，他开始比较 olympus 和类似的、工作正常的服务器之间的配置设置。发现比较的设置相同后，John 说：“我正式放弃了”，并请他的同事查看问题。
实际上，我们的数据没有向我们展示最终问题是什么。但我们确实知道，在 John 花费的两个半多小时的故障排除中，大约 20% 的时间浪费在徒劳地追随错误和系统消息上。有时，缺少消息阻碍了 John（当到 olympus 的连接无声地失败时）。在其他时候，这些消息包含的细节很少，无法让他跟进（例如，“操作未授权”）。最后，他只能抓住救命稻草——他知道有些地方出了问题，但他不知道问题是什么，也不知道在哪里可以找到问题。
消息发挥着至关重要的作用
错误、警告、状态和其他信息消息在人们推理计算机故障的方式中发挥着至关重要的作用。通过检查计算机用户的真实行为方式，我们发现消息实际上决定了用户在遇到问题时的想法和做法。也就是说，消息不仅仅是提醒用户注意问题，它们还指导解决问题的行为。
在第一个示例中，George 观察到播放器实例在不同命令的输出中似乎有不同的名称。考虑到这些差异，他（合理地）认为名称存在问题。但是状态消息之间的这些不一致性只是误导了 George。这只是糟糕的设计。一个设计缺陷是，问题的第一个迹象出现在问题实际发生后的几个命令之后。指示配置错误的错误消息本可以在创建新播放器实例后立即出现。
在不同时间和地点出现的事件之间建立联系尤其困难。6 该错误不仅报告得晚得多，而且还包含很少关于问题上下文的具体信息。“无法连接到服务器”消息特别无用，因为至少有三台服务器处于直接问题上下文中。哪个服务器无法连接到哪个其他服务器？
更重要的是，错误消息不仅含糊不清，而且与其他消息相似。当 George 尝试另一个命令时，他收到了错误消息“找不到服务器”，这实际上与原始错误（“无法连接到服务器”）不同，但由于它看起来非常相似，因此几乎没有引起注意。这在日志输出的情况下可能尤其严重，因为日志通常包含大量消息。在 George 的案例中，我们看到两个人都无法识别日志中的新消息，因为它们隐藏在数百条“典型”错误消息的后面。
在第二个示例中也存在类似的设计缺陷。为什么到 olympus 服务器的连接会无声地失败？如果 John 得到一些提示，表明他的登录名无效，他可能会花更少的时间尝试登录，并更快地找到备用登录名。即使是由于错误输入登录名而产生的错误消息——“登录失败。您使用了无效的用户名、登录名或客户端证书”——也毫无帮助。到底是用户名、登录名还是证书？事实上，这条消息让 John 开始怀疑客户端证书，但这几乎没有安慰作用，因为这条消息是由简单的登录拼写错误引起的，而不是由正在考虑的实际问题引起的。
所有这些观察都表明，消息通常与问题没有很好地协调。一个简单的解决方案是建立一种机制，在错误发生时捕获错误，并将错误以及从错误通过的系统部分收集的上下文信息向上层传递给用户。这里概述的两个例子是典型的，因为系统的不同部分来自不同的供应商，这表明，如果错误消息要真正帮助人们在现实世界中找到并解决问题，那么任何此类错误报告方案都必须成为行业标准。问
致谢
非常感谢 Eben Haber 在示例 1 分析方面的帮助，以及 Madhu Prabaker 在示例 2 分析方面的帮助。
参考文献
1. Barrett, R., Haber, E., Kandogan, E., Maglio, P. P., Prabaker, M., 和 Takayama, L. A. 2004. 计算机系统管理员的实地研究：系统管理工具和实践分析。即将发表于 CSCW 2004（计算机支持的协同工作）。
2. Oppenheimer, D. 2003. 理解分布式系统配置的重要性。载于《系统管理员也是用户：为管理互联网规模系统设计工作空间》。R. Barrett, M. Chen 和 P. P. Maglio 编辑。CHI 2003 工作坊。
3. Barrett, R., Chen, M., 和 Maglio, P. P. 2003. 系统管理员也是用户：为管理互联网规模系统设计工作空间。CHI 2003 工作坊。
4. Barrett, R., Maglio, P. P., Kandogan, E., 和 Bailey, J. 2004. 可用的自主计算系统：管理员的视角。载于《国际自主计算会议 (ICAC) 论文集》。
5. Maglio, P. P., Kandogan, E., 和 Haber, E. 2003. 分布式认知和协同活动在协作问题解决中的作用。载于《第二十五届认知科学学会年会论文集》。波士顿。
6. Decortis, F., de Keyser, V., Cacciabue, P. C., 和 Volta, G. 1991. 人机交互的时间维度。载于《人机交互与复杂系统》。G. R. S. Weir 和 J. L. Alty 编辑，51-72 页。圣地亚哥：Academic Press。
喜欢还是讨厌？请告诉我们
[email protected] 或 www.acmqueue.com/forums
PAUL P. MAGLIO 在 IBM 阿尔马登研究中心的 USER（用户系统工效学研究）小组管理人机系统研究。他拥有加州大学圣地亚哥分校的认知科学博士学位。他的本科学位是麻省理工学院的计算机科学与工程学士学位。
ESER KANDOGAN 是 IBM 阿尔马登研究中心 USER 小组的研究人员。
© 2004 1542-7730/04/1100 $5.00
最初发表于 Queue 第 2 卷，第 8 期—
在 数字图书馆 中评论本文
更多相关文章
Phil Vachon - 王国的钥匙
一次不幸的误操作引发了当前的危机：客户不小心删除了签署新固件更新所需的私钥。他们有一些令人兴奋的新功能要发布，以及通常的一系列可靠性改进。他们的客户越来越不耐烦，但当被问及发布日期时，我的客户不得不拖延。他们如何才能提出一个有意义的日期？他们已经失去了签署新固件发布的能力。
Peter Alvaro, Severine Tymon - 将天才从故障测试中解放出来
本文向分布式系统研究社区发出号召，以提高容错测试的最新水平。普通用户需要工具来自动化选择要注入的定制故障。我们推测，超级用户选择实验的过程可以在软件中有效地建模。本文描述了一个验证这一推测的原型，展示了来自实验室和现场的早期结果，并确定了可以使这一愿景成为现实的新研究方向。
Pat Helland, Simon Weaver, Ed Harris - 大到不能倒
Web 规模的基础设施意味着大量服务器协同工作，通常是成千上万的服务器都朝着相同的目标努力。如何管理这些环境的复杂性？如何引入通用性和简易性？
Steve Chessin - 注入错误以获得乐趣和利润
拥有移动部件的任何东西最终都会磨损和发生故障，这是一个不幸的事实，电子电路也不例外。在这种情况下，当然，移动部件是电子。除了电迁移（移动的电子逐渐将金属原子推出位置，导致导线变细，从而增加其电阻并最终产生开路）和树枝状生长（相邻导线之间的电压差导致位移的金属原子相互迁移，就像磁铁会相互吸引一样，最终导致短路）的磨损机制外，电子电路也容易受到背景辐射的影响。
© 版权所有。