Spiceworks 与 Request Tracker 相比如何?

Spiceworks 与 Request Tracker 相比如何?

我们目前使用 Request Tracker 进行服务台票务处理,使用 Spiceworks 进行资产清点。我正在考虑是否值得将服务台从 RT 转移到 Spiceworks。有没有人使用过这两个系统,可以对这两个系统的优点/问题提供一些见解?或者有一般的哲学原因,为什么应该使用一个解决方案而不是另一个?当然,RT 是开源的,而 Spiceworks 不是 - 通常这对我来说是一件大事 - 但由于 Spiceworks 是免费的,并且非常积极地参与社区活动,所以对我来说这并不是什么大问题(就我个人而言)。

答案1

Spiceworks 运行良好,但有时也会出现问题。只要您了解其性能限制,就可以放心使用它。

我的组织目前正在尝试在 1000 多个用户的环境中推出 Spiceworks。我们遇到了严重的性能限制,因为它无法使用超过两个核心,依赖于缓慢的 SQLite 后端,并且消耗大量磁盘 I/O。在解决这些问题时,他们的支持简直是一场噩梦,到目前为止,他们唯一的解决方案是让我们将我们的安装从具有强大 FC SAN 后端的生产 VMware 集群上的虚拟服务器移动到具有粗糙的消费级 SSD 的物理机器。可以预见的是,他们推荐的配置的性能比我们已经使用的配置更差。

不过,就功能而言,它是一款很棒的产品,绝对值得使用。它非常易于定制,并且拥有非常强大的第三方开发人员生态系统。不过,就目前而言,它根本不适合大型环境。

答案2

多年来,我一直在我们的生产环境中使用 Spiceworks。我们完全依赖它来进行帮助台操作,以进行票证跟踪、资产管理和监控。它是我们部门使用过的最好的产品之一,并且它还在不断发展,为我们提供新功能。

答案3

我要对你们说的话和对所有必须在产品之间进行选择的人说的话是一样的。

什么对你有用?我使用 RT,它可以完成我需要它做的事情。我个人更喜欢使用能很好地完成工作的小工具,而不是一个大工具,它可以完成工作,也许需要一些蛮力,才能很好地完成工作!原因是,该系统的一个部分坏了,整个系统都会坏掉。

使用 RT 来实现它的设计目的,使用 SPICEWORKS 来实现它的设计目的:)

高血压

相关内容