要在生产中使用的错误处理策略

Question

假设我们有一个好的但稍微复杂的产品。产品疯了。客户是中等规模且相对较大的公司。客户官僚程度很高：

• 许多不同的角色和责任
• 受保护的环境
• 数十条规则和政策
• 高度专业化的工程师（DB-guy属于一个部门，tomcat-guy属于另一个部门等）

使用这种方法即使是微不足道的操作（重启和app，获取日志等）也可能需要数小时甚至数天。可以限制或完全禁止访问日志。正如我之前所说，产品很复杂，因此在部署和初始配置阶段可能会出现一些问题。这意味着客户需要得到支持团队的一些帮助和帮助。

问题是最终用户通常属于R＆amp; D部门，无法访问应用程序，应用程序日志，数据库等。换句话说，最终用户无法提供任何有价值的信息一点都不屏幕截图是唯一可用的反馈。

有人知道这个问题的任何好方法吗？

我们的想法是让客户满意，卸载支持团队，并在任何请求时迅速做出回应。另请注意，有一些关于敏感信息的规则等。

我看到应用程序处理错误的几种可能方式：

• 使用“更多详细信息”选项显示高级别问题信息，提供已清理的异常或错误代码
• 做同样的事情，但也收集一些额外的信息，日志，加密并允许用户下载文件
• 提供隐藏的“服务”屏幕，可访问日志和其他系统信息
• 介绍类似调试模式的内容，以便在早期阶段使用
• 最后，可以请求永久访问日志（我个人认为这是不安全的解决方案）。

从可用性和安全性的角度来看，所有这些选项都不是很好。

在这种情况下你会做什么？

Answer 1

在使用灵活的在线“服务目录”时，我解决了类似问题。解决方案非常简单，但在异构系统中技术实现很复杂。

我必须指出，这种错误检测和跟踪是您主要业务领域的独立交叉问题。因此，如果可以在不改变现有源代码的情况下应用它，那将会好得多。

1. 为系统中的每个请求/事务/操作引入逻辑引用或关联 ID。
   • GUID将是完美的
   • 最终用户将参考此ID
   • 在截图
   上捕获此ID应该很容易
   • 确保每个屏幕都以页面标题
   显示此ID
2. 使用AOP框架（根据您的SO配置文件AspectJ或Spring AOP将是开始的好地方）来定义跟踪/日志记录方面。 Aspect将记录有关具有相关引用ID的Web应用程序/业务逻辑/数据访问层的每个调用的信息
   • 拦截调用使用方面，而重用日志系统将保留信息
   • 只要您使用AOP框架，就可以配置跟踪/记录发生的位置，在一个地方收集哪些详细信息
   • 由于现在所有跟踪/记录都封装在一个地方，因此可以使用配置轻松控制它
   • 可以使用方面通过电子邮件等方式立即升级某些问题
3. 最后，你将面对最复杂的部分。如何让开发人员和运营人员不要忽视信息？此类组织问题超出了stackoverflow的范围。在最坏的情况下，如果对错误做出反应需要很多天，您可以从日志记录系统获取生产环境和大量详细信息

Answer 2

总结并提供更多详情。

毫无疑问，如果出现错误，应通知用户。通知应提供有关问题的高级信息。最好不仅要描述问题，还要提供一些解决方案或解决方法（如果有的话）。

错误对话框还应提供获取有关问题的更多信息的方法。

最简单的方法是提供清理的堆栈跟踪，相关的日志消息等。用户的常见方案是获取可用的详细信息并通知支持人员或开发人员。显然，由于大小，敏感信息等原因，这种解决方案不能用于提供所有必需的数据。

作为一种选择，系统可以将该信息直接发送到支持/错误收集工具。安全通道可用于保护数据。如果需要，收集工具可能驻留在客户网络中，因此敏感信息永远不会消失。

如果此选项不可用，系统可以让用户下载包含所有必需信息的存档。存档可以加密，以确保普通用户（面临问题）无法检查潜在的敏感数据。

当然，最好不要使用硬编码密码，因此可以使用更高级的方法。场景如下：

1. 系统显示错误消息
2. 系统生成错误ID并使用它生成一些唯一值（哈希）
3. 用户联系人支持并告知唯一值
4. 支持使用该值生成代码
5. 用户收到支持
的代码
6. 用户下载包含所有详细信息（加密）的存档
7. 用户将下载的信息传递给支持



看起来像一个偏执的解决方案，但允许控制对潜在敏感信息的访问。

完成结论

应该很好地开发记录策略。不应记录敏感信息。

有用的链接

• Effective logging practices ease enterprise development
• Strategies to Mitigate Targeted Cyber Intrusions Part-1
• Strategies to Mitigate Targeted Cyber Intrusions Part-2