我在一个协调维护活动和我们公司的一些服务器的其他活动的团队。 现在团队中有更多的人，我们关心的服务器越来越多，跟踪与某些服务器维护相关的问题或提示越来越难。
我想知道是否有任何工具或方法，使这种types的信息协调更容易？ 我已经尝试了一些错误跟踪工具，但这些工具对于问题和错误非常具体。 现在我们在每个活动之后都会发送电子邮件摘要，但是如果有新的人join了这个团队，他们就不会有这个历史。 我也想过一个维基，但这种logging看起来很尴尬。
例如，对于服务器a，b和c，我想跟踪一个事实，即在重新引导之前，需要在重新引导之前closures服务1,2和3。 如果升级发生在服务器b和c上，我想要一种方法来跟踪升级过程中出现的问题。 这样，一段时间后，如果团队中的另一个人将参与服务器“b”的一些维护活动，他们可以看到与该服务器相关的所有历史logging。
任何提示或解决scheme将不胜感激。
我有两种方法：
1）Wiki我们是一个谷歌应用程序的企业用户，我们使用“网站”function作为我们的维基。 locking，以便只有域用户可以看到它，当然（如果需要，你可以得到更具体的）。
每个服务器在维基中有两个页面。 一个页面的规格，用法和关键便笺和一页是活动日志。 日志是date，时间，任务和重新启动指标的表格。 理想情况下，没有任何反应，没有得到logging！
附注：谷歌的“网站”的事情使logging页面很容易创build使用他们的“名单”模板。
2）WhatsUp Pro
我使用WhatsUp来监视我的服务器和设备。 在有用的情况下，我在设备的自由格式备注字段中添加了关键信息（“记得启动服务x”或“确保界面A出现”）。 然后，当待命的人（通过短信）得到分页时，文本包括那些笔记。 非常方便有。
我所发现的最好的东西就是每个人都知道的文档的中心位置。 我个人比较喜欢维基，因为它很快捷。 其他选项可能是Subversion ， GIT或CVS等版本控制系统。 Sharepoint及其文档pipe理function也可能适用于您，但这对于这个问题将是一个相当重要的解决scheme。
我会使用SharePoint，特别是Windows SharePoint Services。 它相对轻量级，不会花费任何东西，并可以做一些很好的多维数据视图。 在最简单的情况下，它可能只是一个单独的列表，按照服务器名称和angular色分组，第二个视图也按照angular色和服务器名称进行分组。 您还可以使用其他列表types的function，如共享日历（这是30日，胡思乱想的旧盒子需要重新启动），联系人等
这听起来像是你需要一个内部的票务系统，也可以作为一个知识库来search/链接在同一类别下提交的过去和相关票据。
我们使用“Track-It！” 在我的公司跟踪所有维护，包括操作请求。 我确信有一些更好的和/或更便宜的解决scheme。
国际海事组织实施票务系统很容易，难的部分是让所有pipe理员/技术人员都遵循创build票据并正确填写的stream程，以便以后可以search和参考。
只是抛出另一个选项。 我已经使用tiddlywiki很长一段时间，但它是一个客户端唯一的wiki。 有一些窍门让它与服务器同步，但我还没有发现这很容易。
我现在正在使用的想法是使用tiddlywiki跟踪我们团队的活动与服务器，并使用Subversion保持tiddlywiki彼此同步。 这样我们就有一个总是只读的日志副本，如果我们做了修改，我们可以提交到Subversion版本库。
我正在玩弄它，但现在这似乎是最便宜，最容易实施的解决scheme。
许多支持众多服务器的人与在全国范围内支持相同数量的服务器的人相同。
一个人的错误跟踪系统是另一个人的“服务器维护历史”:)
根据您select的系统，应该有一个地方来保存每个项目（服务器）上的信息，并在每个服务器的附加案例（维护事件）下进行保存。
没有什么比在笔记本和笔（在我的书中）logging笔记以更连贯和可能有组织的方式进入系统之前logging下来的事情（有时写作速度更快）。
第一步是认识到需要一个“系统”，并让人来付钱。
至于一个错误跟踪系统，我会避免做出明显的build议尝试:)
我们使用Spiceworks跟踪所有服务器/工作站信息以及通过帮助台票据发送的请求。 最好的部分是它是免费的。