所以我们可能都遇到过这种情况：你调试了一些问题，却发现它是由你六个月前所做的配置更改引起的，而且你不记得你为什么这样做。所以你撤消它并解决问题，现在其他一些问题又回来了。哦，是的，现在我想起来了！然后你正确修复它。
那是因为你没有做好笔记，你这个笨蛋！但是这样做的好方法是什么？
在工程方面，我们有大量软件可以帮助我们检测和跟踪变化。源代码控制、代码审查等。跟踪每个更改，每个更改都需要对其进行注释。典型的工程部门需要良好的评论，以便在六个月内弄清楚为什么会这样破坏它时，您可以使用历史“责备”功能或二进制搜索构建来查明问题。这些工具是非常有效的交流工具和历史记录。
但是在服务器领域，我们有 500 种不同的服务，所有这些服务的配置方式都不同。而且它们并不总是具有文本格式（考虑设置文件夹的权限或更改页面文件位置），尽管它们可能具有文本表示。
在我们的环境中，我们检查了可以进入 Perforce 的配置文件，但这些文件很少。无法完全检查 Active Directory DB ..虽然可能是一个可以区分的转储......
过去，我曾尝试在我们的 wiki 中保留手动更改日志，但要保持这样做的纪律非常困难（我知道，这不是一个好借口，但确实很难）。
我的问题：您使用什么策略和工具来解决跟踪服务器配置更改的问题？
- 更新 -
注意：我不是在寻找共享笔记工具（我熟悉 OneNote 等），而是专门用于帮助跟踪服务器更改的自动化工具。没有用于跟踪服务器配置更改的综合工具，但也许有一些针对特定应用程序（如 GPO）的工具。
此外，我对您认为有用的特定策略非常感兴趣。“我们在 Sharepoint 中共享笔记”非常含糊。你如何保持纪律？您使用什么格式来跟踪您的更改？您如何组织变更数据？我真的很喜欢例子和想法。
一位朋友正在和我谈论位腐烂的问题 - 驱动器上的位随机翻转，破坏数据。非常罕见，但如果有足够的时间，它可能会成为一个问题，并且不可能被发现。
驱动器不会认为它是坏扇区，备份只会认为文件已更改。不涉及校验和来验证完整性。即使在 RAID 设置中，也会检测到差异，但无法知道哪个镜像副本是正确的。
这是一个真正的问题吗？如果是这样，可以做些什么呢？我的朋友推荐 zfs 作为解决方案，但我无法想象在工作中扁平化我们的文件服务器，安装 Solaris 和 zfs ..
我们的文件服务器刚刚开始向我们发送邮件，了解其备用电池如何耗尽以及它正在从 WB 切换到 WT 模式等等。
我查看了它的日志，发现它被配置为定期自动执行此操作。这被称为“电池再学习”。
这个是来做什么的？它多久会决定需要自动执行此操作？
我搜索了 LSI 文档，我只能找到不同重新学习状态的不同状态代码。不是很有帮助。