所以我们可能都遇到过这样的情况：你调试了一些问题，却发现它是由你六个月前所做的配置更改引起的，你不记得为什么这样做了。因此，您撤消它并解决问题，现在又出现了其他问题。哦，是的，现在我想起来了！然后你正确地修复它。
那是因为你没有做正确的笔记，你这个笨蛋！但是有什么好的方法可以做到这一点？
在工程领域，我们拥有大量旨在帮助我们检测和跟踪变化的软件。源代码控制、代码审查等。每一个变化都被跟踪，每一个变化都需要一个关于它是什么的评论。典型的工程部门需要良好的评论，因此当您在六个月内弄清楚为什么会这样破坏它时，您可以使用历史“责备”功能或二进制搜索构建来查明问题。这些工具是非常有效的沟通工具和历史记录。
但是在服务器领域，我们有 500 种不同的服务，它们都有不同的配置方式。尽管它们可能具有文本表示，但它们并不总是具有文本格式（考虑在文件夹上设置权限或更改页面文件位置）。
在我们的环境中，我们可以将哪些配置文件检查到 Perforce 中，但这些配置文件很少。无法准确地检查 Active Directory DB..虽然可能是一个可能有差异的转储......
过去我曾尝试在我们的 wiki 中保留手动更改日志，但要保持纪律这样做非常困难（我知道，这不是一个好的借口，但这确实很难）。
我的问题：您使用什么策略和工具来解决跟踪服务器配置更改的问题？
- 更新 -
注意：我不是在寻找共享笔记工具（我熟悉 OneNote 等），而是专门用于帮助跟踪服务器更改的自动化工具。没有用于跟踪服务器配置更改的综合工具，但可能有一些针对特定应用程序（如 GPO）的工具。
此外，我对您发现有用的特定策略非常感兴趣。“我们在 Sharepoint 中共享笔记”非常含糊。你如何保持纪律？您使用什么格式来跟踪您的更改？您如何组织变更数据？我真的很喜欢例子和想法。
在 Linux 领域，人们追求几种不同的策略：
这种情况下的问题之一是，实际上，它是业务流程/技术问题的组合。它绝对比仅仅跟踪管理员所做的更改更大。您还需要注意意外更改，以及管理员或单位之间的良好协调，以便 AD 控制器上的更改不会破坏某些部门服务器上的数据库权限设置。即，你的问题是一大罐蠕虫:)
在我的组织中，我们大约需要一年的时间来推出流程和系统来解决这个问题。在业务流程方面，我们组建了一个变更管理团队。根据 SOP，对生产环境的所有更改都通过它们进行协调。他们编译所有更改，以及范围、受影响的系统、受影响的服务等。强制执行有关更改的良好文档，以及推出和回滚计划。主持每周（公开）会议以讨论即将发生的环境变化，然后发送电子邮件详细说明所有这些变化。这个过程的最终目标是，实际上，IT 中的每个人都知道正在发生的一切。这有助于解决问题，例如，系统管理员安装内核补丁并重新启动将关闭时钟数据库的系统。
至于技术方面，我只能说 Unix/Linux 的家伙，因为我不处理 Windows。他们一直在推出 Reducing Labs 的 Puppet，用于所有这些系统的配置管理。简单地说，是一个客户端/服务器系统，其中定义了服务器上的机器配置，并且客户端每隔一段时间（默认为 30 分钟）就会抓住这些机会。此外，如果有任何机会在本地管理文件，那么它们也会在那时恢复。我们使用它来管理正在运行的服务、防火墙配置、用户授权等。
我还建议研究像 TippingPoint 这样的东西。它是一个监视系统配置并发送更改警报的客户端服务。这让我们安全人员最高兴。它主要用于跟踪恶意或未发布的更改。
我已经在 4 或 5 家公司工作过，我不太记得了。
我们都有这个问题。我们没有人能 100% 解决这个问题，但在我现在所在的公司，我们拥有我认为是迄今为止最好的策略。
Sharepoint/Wiki/Evernote/PIN
其中一些可能有更好的工具，但这是我们使用的：
对于 Windows，请查看 Microsoft 的 System Center 系列或该平台的配置和服务管理方面的任何其他竞争对手。
更改需要通过一个体面的更改管理例程进行路由，该例程本身会在它们实际完成之前批准并记录它们。对于初学者来说，这可以是 100% 的手动操作。使用一些更好的集成工具，您可以要求该工具进行实际更改并“自动”将其注销到中央配置数据库 - 而不是徒手进入单个服务器的控制台，手动挖掘设置以尝试解决问题牛仔风格。
您绝对应该有一个变更管理流程，特别是如果有多个人能够/访问在您的环境中的系统级别上进行更改。这也为管理层提供了一种批准潜在更改的方法，但是如果您不能即时进行更改，它确实会导致更改过程中的延迟。
跟踪更改的一些方法可能包括验证您的 SEM 中的事件（假设您有一个安全事件管理器）或 Nessus 等工具（通过大量工作可以审核您的环境以发现更改）。
这是一个更加本地化的、基于 *nix 的答案。我还没有找到任何好的工具来在 Windows 下模拟它。
有几种方法可以实现这一点......并在你忘记时抓住它。
诸如 subversion、git、cvs 或 RCS 之类的修订控制系统是跟踪配置文件历史的好方法。如果您不想在生产服务器上安装修订控制系统，则使用rsnapshot之类的本地或远程存储配置文件目录将为您提供 RCS 的大部分好处，但您失去了审核或退出提交的可能性日志（尽管这可以通过文件本身的注释来解决）。
为了帮助您记住记录更改，通过每晚的 cron'ed tripwire运行自动报告配置更改是一个好的开始。在构建了tripwire 文件当前状态的数据库后，对它们的任何更改都将在下次运行期间发送一封电子邮件。在数据库更新之前，您将继续收到此邮件，从而“重置”tripwire。
我会使用问题跟踪系统，例如 flyspray（任何都可以，但我喜欢 flyspray 用于非编程的东西）。在任何人接触配置之前，应该记录改进/问题。当您修复/实施它时，更改会出现在票证中。
一个 wiki 可以很好地记录当前的设置，但它很容易过时 - 而且更新 IMO 似乎需要更多的努力。
您不会找到自动执行此操作的东西 - 尽管您可能可以设置它，因此如果您愿意，对某些配置文件的更改会自动通过电子邮件发送到问题跟踪器。
我认为这只是一个好的政策、低门槛的工具和纪律的问题。
我们创建了一些本土的东西来在我们的环境中进行更改日志跟踪；这不是什么超级复杂的事情，而且效果很好。
正如我所说，没什么特别的。它使用 PERL CGI（写于 10 亿年前）和用于索引的 Google 搜索设备。
缺点：
无论如何，如果您毕竟对代码感兴趣，请告诉我，我可能会抓住它来分享。
如前所述，这通常是一个文化问题——毕竟，一些开发商店不再理会评论（自我记录代码是当今流行的流行语！）还有一些使用版本控制系统作为历史记录的圣杯。显然，这些并不完美。
因此，解决它的唯一真正方法是使其成为一种文化解决方案。确保所有更改原因都记录在错误跟踪器（或知识库或 wiki）中，并确保所有更改都记录在更改控制系统中。
我们有紧急服务客户，他们的系统发生的每一个变化都会被记录下来，每次我们登录他们的系统时，我们都必须记录下来。对于其中一些人，我们必须先打电话征求许可（我猜他们也会记录下来！）。每次更改都会被记录，如果不记录就更改客户系统将构成违纪行为。
这听起来很繁琐，但事实并非如此。您很快就会养成将自己添加到访问日志和更改日志的习惯——这并不比在签入代码更改时写评论更糟糕。
我推荐一个 bugtracker 作为变更控制原因日志，因为它们通常很容易更新（我使用 Mantis）。