4

假设我们有一个很好但稍微复杂的产品。该产品变得疯狂。客户是中型和相对较大的公司。客户官僚主义程度相当高：

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

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

在此处输入图像描述

问题是最终用户通常属于研发部门，无法访问应用程序、应用程序日志、数据库等。换句话说，最终用户根本无法提供任何有价值的信息。屏幕截图是唯一可用的反馈。

有人知道这个问题有什么好的解决方案吗？

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

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

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

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

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

4

3 回答 3

3

通过阅读您正在考虑的一些事情，特别是：

  • 使用“更多详细信息”选项呈现高级问题信息，
  • 提供经过清理的异常或错误代码也是如此，但也
  • 收集一些附加信息、日志、对其进行加密并允许用户下载文件 提供隐藏的“服务”屏幕以访问日志和附加系统信息

将它结合起来并使其“更安全”怎么样？

修改代码，以便错误/异常也会创建一种“故障单”（尽可能多地保存额外信息），但不会向用户显示。用户将获得一个“票号”（他们必须手动将其复制到发送给支持人员的邮件中，或者 - 如果可能，错误消息可以自动创建一个网页或面板，以允许用户从他们的观点、截图等等）。

通过这种方式，支持人员将可以访问上下文化和更丰富的详细信息（他们可以分析这些信息或将其转移到维护组，而无需将这些信息暴露给用户）。我对内部结构和全局架构了解不够，所以我无法判断这将是多么复杂。理想情况下，每个操作都应该自动获得分配的“故障票”，以便日志具有正确的参考，但只有在异常情况下才会“公开”票号。

于 2013-01-07T08:16:50.667 回答
1

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

我必须指出，这种错误检测和跟踪是您主要业务领域的独立横切关注点。因此，如果可以在不更改现有源代码的情况下应用它会好得多。

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

只是为了总结并提供更多细节。

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

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

在此处输入图像描述

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

在此处输入图像描述

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

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

在此处输入图像描述

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

  1. 系统显示错误信息
  2. 系统生成错误 id 并使用它来生成一些唯一值（哈希）
  3. 用户联系支持并讲述独特的价值
  4. 支持使用该值生成代码
  5. 用户从支持部门收到代码
  6. 用户下载包含所有详细信息的存档（加密）
  7. 用户将下载的信息传递给支持

在此处输入图像描述

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

最终结论

日志记录策略应该是完善的。不应记录敏感信息。

有用的链接

于 2013-01-11T17:10:14.280 回答