有人在帖子里提到过这件事。
它最终没有被提交为工单。

内部工具的使用者离你足够近，近到可以顺口跟你说起一个毛病——而正是这份近，让它从来没有被正式提交过。等它被提起时，他们早已绕过了它，而这个绕法已经变成了流程本身。

问题

内部软件的故障往往被提及而非报告。它们可能以通话结束时的附和、频道里的消息、或是某人演示工作时耸耸肩的方式出现——而且每次都是由已经不再受其困扰的人提出的。这些故障很少会记录在你的看板上，即使记录下来，也往往是经过三次转述后细节模糊不清才出现的。最终导致积压的故障列表是由熟悉程度决定的：那些习惯于提交工单的团队占比过高，而那些最令人头疼的界面问题往往来自那些最不可能登录过你的跟踪系统的部门。与此同时，真正能够有效报告问题的人数与公司员工总数相当，而对于一款本身不产生任何收入的软件来说，按人头付费显然成本过高。

Snag如何提供帮助

提交这件事搬进了工具里，就在出问题的那一刻、那一屏上。正看着那个不听话的表格的人直接从该页面打开捕获——不用第二个标签页，不用学一套跟踪系统，也不用一个他们从来没有过的登录——他们发出去的是会话本身，而不是对会话的回忆。这去掉了真正拦住内部故障被提出来的两件事：上下文切换，以及“写这份报告是别人的活”的感觉。因为提交不需要任何许可，覆盖面就扩大到了你平时听不到的人——仓库、财务、外勤，以及来顶两周班的那位——而读这些进来的内容也不花钱，因为所有套餐的成员数量都不限。小部件出现在哪一屏由你逐屏决定，它也可以完全不渲染，直到你自己的某个控件调用它。

你得到的回报

一个由人们真正卡住的那些界面组成的队列，每一条下面都带着录制好的会话，于是排优先级变成了观看，而不是访谈。如果订阅了修复套餐，改动会以拉取请求的形式回到你连接的那个代码仓库，并附上它据以工作的证据。有一条边界要说清楚：这并不会让那些从来没人提起的绕法浮出水面——你听到的仍然只是有人选择说出来的部分。它改变的是这个选择对他们来说有多贵，而对内部软件来说，这基本上就是这个选择往往倒向另一边的原因。

人们实际会问的问题

我们的工具采用单点登录机制。这会使操作复杂化吗？

其实不然——这段代码片段是应用程序的一部分，所以提交报告的用户已经通过您的账号登录，并且已经进入了相关页面。捕获过程由他们发起，并在他们提交时结束。真正需要注意的是地址：记录只会在您已验证的域名上进行，而验证是通过发布 DNS 记录完成的，因此该工具必须运行在您组织拥有的域名上，而不是仅存在于网络内部的主机名上。

我们的管理界面会显示客户记录。最终会被录制下来的是什么？

人们打进去的内容不会：输入值在浏览器里就被遮蔽，敏感请求头被剥离，明显的密钥被抹去，全都发生在任何东西上传之前。页面显示出来的内容则是另一个问题，老实的答案是：回放会重建页面，所以屏幕上渲染出来的文字也在里面。今天没有可配置的分区排除。如果你工具里的某一屏显示了不该被录下来的记录，请在把代码片段放上去之前，先看一次那一屏的捕获。

我们能否在某些屏幕上显示，而在其他屏幕上不显示？

是的，有两种方式。代码片段仅在您包含它的页面上生效，其静默模式完全不显示任何内容，直到您自己的控件将其打开——因此，一个复杂的流程屏幕可以显示一个可见的“报告问题”项，而设置页面则什么也不显示。

这些细节的来源

本页面不涉及任何其他产品——所有信息均为Snag原创。如有信息过时，请发送邮件至 admin@dvcllc.io，我们将予以更正。