>许多不同的角色和责任
>受保护的环境
>数十条规则和政策
>高度专业化的工程师(DB-guy属于一个部门,tomcat-guy属于另一个部门,等等)
使用这种方法即使是微不足道的操作(重启和应用程序,获取日志等)也可能需要数小时甚至数天.可以限制或完全禁止访问日志.正如我之前所说,产品很复杂,因此在部署和初始配置阶段可能会出现一些问题.这意味着客户需要来自支持团队的一些帮助和帮助.
问题是最终用户通常属于R& D部门,并且无法访问应用程序,应用程序日志,数据库等.换句话说,最终用户根本无法提供任何有价值的信息.屏幕截图是唯一可用的反馈.
有谁知道这个问题有什么好的解决方案吗？
我们的想法是让客户满意,卸载支持团队,并在任何请求时迅速做出回应.另请注意,有一些关于敏感信息的规则等.
>使用“更多详细信息”选项显示高级别问题信息,提供已清理的异常或错误代码
>做同样的事情,但也收集一些额外的信息,日志,加密它,并允许用户下载文件
>提供隐藏的“服务”屏幕,可访问日志和其他系统信息
>介绍类似调试模式的东西,用于早期阶段
>最后,可以请求永久访问日志(我个人认为这是不安全的解决方案).
从可用性和安全性的角度来看,所有这些选项都不是那么好.
在这种情况下你会做什么？
解决方法
>使用“更多详细信息”选项显示高级别问题信息,
>提供已清理的异常或错误代码也是如此
>收集一些额外的信息,加密并允许
用户下载文件提供隐藏的“服务”屏幕和访问权限
记录日志和其他系统信息
如何将它结合起来并使其“更安全”？
修改代码,以便错误/异常也会创建一种“故障单”(尽可能多地保存额外信息),但不会向用户显示.
用户将获得一个“票号”(他们必须手动将其复制到发送给支持的邮件,或者 – 如果可能,错误消息可以自动创建一个网页或面板,以允许用户添加他们发生的事情的描述观点,截图等等).
这种方式支持将访问上下文化和更丰富的细节(他们可以分析或转移到维护组而不会将这些细节暴露给用户).我对内部和全球架构知之甚少,所以我无法判断它的实施有多复杂.理想情况下,每个操作都应自动分配一个“故障单”,以便日志具有正确的引用,但只有在发生异常时才会“显示”故障单号.
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 dio@foxmail.com 举报，一经查实，本站将立刻删除。
