如何记录服务器更改？

因此，我们所有人都可能遇到这种情况：您调试了一个问题，却意识到这是六个月前所做的配置更改引起的，并且您不记得为什么这样做了。因此，您撤消它并解决问题，现在又出现了其他问题。哦，是的，现在我记得了！然后您正确地修复它。

这是因为您没有记下正确的笔记，您这傻瓜！但是，执行此操作的好方法是什么？

在工程领域，我们拥有大量旨在帮助我们检测和跟踪变化的软件。源代码管理，代码审查等。跟踪每个更改，每个更改都需要对其内容进行评论。典型的工程部门需要很好的评论，以便在六个月后弄清为什么要破坏它的原因时，您可以使用历史记录的“怪状”功能或二进制搜索构建来找出问题所在。这些工具是非常有效的通讯工具和历史记录。

但是在服务器领域，我们有500种不同的服务，所有这些服务都有不同的配置方式。尽管它们可能具有文本表示形式，但它们并不总是具有文本格式（考虑对文件夹设置权限或更改页面文件位置）。

在我们的环境中，我们将可以进入Perforce的配置文件签入，但是其中很少。无法完全检入Active Directory数据库。尽管可能存在差异，但转储可能有所不同...

过去，我曾尝试在Wiki中保留手动更改日志，但是要保持纪律来做到这一点非常困难（我知道，这不是一个很好的借口，但这确实很难）。

我的问题：您使用什么策略和工具来应对跟踪服务器配置更改的问题？

-更新-

注意：我并不是在寻找共享笔记记录工具（我对OneNote较为熟悉），而是在寻找专门用于帮助跟踪服务器更改的自动化工具。没有跟踪服务器配置更改的综合工具，但是也许有一些针对特定应用程序的工具，例如GPO。

我对您发现有用的特定策略也非常感兴趣。“我们在Sharepoint中共享笔记”非常模糊。您如何保持纪律？您使用什么格式来跟踪您的更改？您如何组织变更数据？我真的很想要例子和想法。

在Linux领域，人们正在追求两种不同的策略：

• 配置约束系统，例如cfengine或puppet或Chef。这些类似于Windows GPO。重要的是，所有服务器配置都被有意记录在一个地方，并且您知道该策略是在什么粒度（服务器机房，组，特定服务器）上制定的。这不会完全使您摆脱“六个月前到底有什么不同？” 但是，它确实允许您仅对服务器配置进行核对并从头开始重建。您可以将cfengine和puppet策略置于版本控制下以回答该问题。
• 修订控制的/ etc。通常，Linux程序将其配置存储在一个地方，即/ etc。大胆地开始编写脚本以将/ etc置于修订控制中。我知道的一个这样的程序是etckeeper：

说明：将/ etc存储在git，mercurial，bzr或darcs中
 etckeeper程序是一种工具，用于将/ etc存储在git中，
 bzr或darcs存储库。它挂接到APT以自动提交更改
 在软件包升级过程中对/ etc进行了更改。它跟踪该版本的文件元数据
 控制系统通常不支持，但这对/ etc很重要，例如
 作为/ etc / shadow的权限。它是相当模块化和可配置的，而
 如果您了解使用版本的基础知识，也可以轻松使用
 控制。

这种情况下的问题之一是，实际上，这是业务流程/技术问题的组合。它绝对比跟踪管理员所做的更改大得多。您还需要注意意外更改，以及管理员或部门之间的良好协调，以便AD控制器上的更改不会破坏某些部门服务器上的数据库权限设置。即，您的问题是一大堆蠕虫:)

在我的组织中，我们大约需要一年时间来部署流程和系统来解决此问题。在业务流程方面，我们成立了变更管理团队。根据SOP，对生产环境的所有更改都可以通过它们进行协调。他们会编译所有变更，以及范围，受影响的系统，受影响的服务等。对变更进行有效的文档记录，以及推出和回滚计划。每周主持一次（公开会议）以讨论即将发生的环境变化，然后发送电子邮件详细说明所有这些变化。此过程的最终目标是有效地使IT部门的每个人都知道发生的所有其他事情。例如，这有助于解决SysAdmin安装内核补丁并重新启动将关闭时钟数据库的系统的问题。

至于技术方面，由于我不涉及Windows，因此我只能说Unix / Linux专家。他们已经推出了Reduction Labs的Puppet，用于所有这些系统的配置管理。简而言之，是一种客户机/服务器系统，其中一个在服务器上定义了机器配置，客户机如此频繁地拉动这些机会（默认为30分钟）。此外，如果在本地对托管文件进行了任何机会，那么它们也将在那时还原。我们使用它来管理运行中的服务，防火墙配置，用户授权等。

我也建议您研究诸如TippingPoint之类的东西。它是一种客户端服务，可以监视系统配置并发送有关更改的警报。它使我们的安全人员最高兴。它主要用于跟踪恶意或未发布的更改。

我现在不记得有4到5家公司。

我们都有这个问题。我们中没有一个人能100％地解决它，但是在我现在的公司中，我拥有迄今为止认为最好的策略。

Sharepoint / Wiki / Evernote / PINs

• 共享点
  • an吟所有...它具有一些非常好的列表功能。
  • IP地址列表
  • 库存
  • 服务帐户和使用
  • 更改通知日志
• 维基
  • 怎么做
  • 远程任务列表
• 印象笔记
  • 我的伴侣，我用它把我们不需要的所有东西都放到Wiki中
  • 本质上更多的方法
  • 我们都需要看的便笺
  • 一周的任务核算
  • 承包商任务清单
  • Evernote Clipper使屏幕截图广告/权限设置变得容易
  • 随处可见
• 密码
  • 密码库

其中一些可能有更好的工具，但这是我们使用的工具：

• 在私有Wiki中按服务器跟踪配置更改和升级/补丁
• 还要在Wiki中保留指导和问题/解决方案的记录
• 使用Sharepoint或Google文档来保留诸如静态IP列表之类的内容的权威副本
• 使用Subversion跟踪对配置文件的更改

对于Windows，请查看Microsoft的System Center系列或该平台在配置和服务管理方面的任何其他竞争对手。

更改需要通过一个体面的更改管理例程进行路由，该例程本身会在实际完成之前批准并记录它们。对于初学者，这可以是100％手动的。使用某些更好的集成工具，您可以要求该工具进行实际更改并将其“自动”注销到中央配置数据库中-而不是徒劳地进入单个服务器的控制台中，手动浏览设置以尝试解决牛仔风格的问题。

您绝对应该有一个变更管理流程，尤其是当有多个人有能力/可以在您的环境中的系统级进行变更时，尤其如此。这也为管理层提供了一种签发潜在变更的方法，但是，如果您不能即时进行变更，它的缺点是会在变更过程中引起延迟。

跟踪更改的某些方法可能包括验证SEM中的事件（假设您具有安全事件管理器）或诸如Nessus之类的工具（通过大量工作可以审计您的环境以查找更改）。

这是一个更加本地化的基于* nix的答案。我没有找到任何好的工具可以在Windows下模拟它。

有几种方法可以实现此目标……并在您忘记时加以捕获。

诸如Subversion，git，cvs或RCS之类的版本控制系统是跟踪配置文件历史的好方法。如果您不想在生产服务器上安装版本控制系统，则使用rsnapshot之类的东西在本地或远程存储配置文件目录将为您带来RCS的大部分好处，但是您失去了审计或保留提交的可能性日志（尽管可以通过文件本身内部的注释来解决）。

为了帮助您记住更改记录，通过夜间，定期的绊线运行自动报告配置更改是一个不错的开始。在建立了Tripwire当前文件状态的数据库之后，对文件的任何更改将在下次运行期间生成电子邮件。您将继续收到此邮件，直到更新数据库为止，从而“重置”绊网。

我会使用问题跟踪系统，例如flyspray（可以使用，但我喜欢将flyspray用于非编程性的东西）。在任何人接触配置之前，应该记录改进/问题。当您修复/实施它时，更改会记录在工单中。

Wiki可以很好地记录当前的设置，但是很容易过时-似乎需要更多的精力来更新IMO。

您不会找到自动化的方法来执行此操作-尽管您可能会进行设置，所以如果需要的话，对某些配置文件的更改会自动通过电子邮件发送给问题跟踪器。

我认为这只是一个好的政策，低障碍的工具和纪律性的问题。

我们创建了自己的东西来在环境中进行更改日志跟踪；它并没有什么复杂的东西，而且效果很好。

• 设置了自我监管策略，以使您估计中的任何更改都偏离现成的设置或可能导致问题，这些更改应记录在变更日志系统中。
  • “硬币”的反面是，如果您要解决问题，请搜索最新的或相关的变更日志条目。
• 登录系统并选择要更改的服务器，服务或硬件组件
  • 这些组件之前已与基本的“人口统计”信息（位置，供应商，序列号，负责部门）一起输入到同一系统中
• 从基本类别的下拉菜单中选择
  • 计划外停机
  • 打补丁
  • 硬件维修
  • 软件安装
• 详细说明您所做的，看到的，观察到的
• 副本将发送给责任方，并存储为Search Appliance编制索引的XML文件。
• 利润

正如我所说，没什么好看的。它使用PERL CGI（写于十亿年前）和Google Search Appliance进行索引。

缺点：

• 服务组很难使用，例如，您刚刚向所有25个域控制器添加了相同的补丁程序；我们没有“域控制器”组，因此我们必须手动选择所有
• 不与硬件，软件或事件日志错误报告集成，以帮助进行故障排除
• 相关地，如上所述，所有“人口统计”数据都需要人工输入

无论如何，如果毕竟您对代码感兴趣，请告诉我，我很可能可以将其分享。

如前所述，这通常是一个文化问题-毕竟，一些开发商店不再为注释所困扰（如今，自记录代码是一个时髦的流行语！），而一些使用版本控制系统作为历史记录的圣杯。显然，这些都不是完美的。

因此，修复它的唯一真实方法是使其成为一种文化解决方案。确保将所有更改原因记录在错误跟踪器（或知识库或Wiki）中，并确保所有更改都记录在更改控制系统中。

我们有紧急服务客户，他们的系统发生的每一次更改都会记录下来，并且每次我们登录他们的系统时都必须记录下来。对于其中一些人，我们必须先致电获得许可（我想他们也要登录！）。每次更改都会记录下来，如果不记录就更改客户系统，将构成违纪行为。

听起来很麻烦，但事实并非如此。您很快就会养成将自己添加到访问日志和更改日志的习惯-这不比签入代码更改时必须写注释更糟。

我建议将Bugtracker作为更改控制原因日志，因为它们通常很容易更新（我使用Mantis）。

如果您正在寻找“企业解决方案”（即，您比上帝有更多的钱，并且想要拥有一个非常酷的工具），那么我用来支持并提供现场工作的工具就是其众多功能之一。

不知道基本价格是多少，但是在惠普购买Opsware之前，价格约为350,000美元（没有支持，请相信我-当我开始使用Opsware时，您需要支持）。

在我在那里工作时，我们有几个客户将应用程序配置和快照功能与Tripwire结合使用。

当然，如果您没有预算-这是一个Bad Choice™：）

而且，再次，当我重新加载时出现在此页面顶部的广告是针对spiceworks的。看起来很像HPSA :)

如果您只想跟踪更改而不管理整个过程（例如，通过Chef或Puppet），则只需rsync将etc目录（无论位于何处）都放入本地git repo。

for HOST in alpha bravo charlie delta ...; do

    rsync -avz --exclude-from=exclusions -e ssh admin@$HOST:/opt/local/etc/ ./$HOST

done

当然，您可以根据需要添加其他来源。