对于我们的环境（AsciiDoc格式），我们有相当不错的文档，最近允许另一个人在30分钟内从头重新创build整个设置。
不过，我注意到在初始设置之后，很容易发生对系统做的小改动（比如：inetd被打乱了，我的IMAP服务器在一个额外的端口上侦听ManageSieve连接，一个新的路由器被添加到eximconfiguration中）不要马上写在文档里（如果有的话）。
我的想法是通过（部分地）从configuration文件和其中的注释中生成文档来避免这个问题 – 实现这一点的一种方式可能是将/etc和/usr/local/etc放入某个源代码pipe理系统说 – 混帐），然后运行一个脚本，每个提交重新生成文档。 但是，我不确定这是否是矫枉过正和/或太难以正确（毕竟，我不想在我的文档中完整复制源文件，而只是比较差异）。
其他人如何避免服务器文档过时 – 是否有自动同步的好方法，还是在修改系统的同时更新文档？
你永远不会摆脱一些文档，但是如你所暗示的那样，有些系统可以集成到你的变更过程中来覆盖很多。
通过这种方式，通过将configuration项或代码中的部署信息存储为您所做的更改的系统的一部分，可以强制执行我们通常错过（或不用打扰）的底层文档。 这也有一个额外的奖励过程将变得更加可重复。
外部文档仍然需要更新，但是指向“部署x”或“部署y”而不是长命令/文件列表的指针会变得非常高。 这另外使得文档更改不那么频繁和更容易，这也意味着更容易完成。
同样在你回家之前，用傀儡酿造一个人可能已经写了一些东西来pipe理你想要的东西。
如果你只pipe理一个或两个小系统，build立一个像木偶或厨师这样的大型configurationpipe理系统似乎是过度杀伤性的。 （但是，如果你打算将来有更多的系统，现在就做！）
对于像这样的小设置，我build议使用像etckeeper的程序，它将/etc放入git存储库，并提供一些有用的function，比如在安装，升级或删除软件包时进行自动提交。
每次在系统上进行更改时，都必须更新文档。 AKA Change Management 。
事实上，大多数公司以荒谬的方式实施变革pipe理，使其变得糟糕，不应该减损基本概念的效用，也不会妨碍您做正确的事情。
我曾经使用html或某种wiki来跟踪我所有的configuration。 现在，我在一家使用（ 不寒而栗 ）SharePoint的Windows商店工作，所以现在我使用我创build的Word文档“模板”来跟踪每个系统和每个configuration更改，这并不像听起来那么糟糕，系统只不过是其他人的复制品，可以将它们集中在一起。 （我把所有的东西都保存在我的硬盘上，除了将它们扔到任何人的SharePoint站点的无组织堆中外，其实都是以一种明智的方式进行组织的。）
最大的挑战是真正花时间logging文件，我通过将文件时间作为进行变更的一部分来做到这一点。 所以，不是那么难，特别是如果你有点屁股，不介意告诉人们拧紧排队，因为你现在太忙了，他们的问题。