作为一名专业的系统管理员，您认为跟踪哪些配置项对于执行正确的配置或变更管理至关重要？
例如，在 Windows 中，除了硬件或软件之外，您是否还跟踪注册表更改？在 Linux 中，您是否比较配置文件的差异？
编辑：为了澄清起见，我正在寻找具体要跟踪（或不跟踪）的内容 - 如果你想推荐工具此外对于您认为值得追踪的项目，请继续。
答案1
[主要偏向 Unix/Linux，我不使用 Windows 系统:-)]
任何修改后会改变正在运行的系统状态的内容都需要进行跟踪。配置必须存储在支持完整更改历史记录的存储库中，例如 Git 或 Subversion，并且必须以自动化方式进行部署，例如使用Opscode 的厨师或者还原实验室的傀儡。
改变系统状态的几个示例：
- 已安装的软件包/补丁版本。
- 已部署的应用程序、应用程序库。
- 管理和应用程序用户。
- 硬件配置和设备驱动程序/模块。
- 计划维护工作（Unix/Linux 上的 cron）。
- 由外部工具监控的服务和组件。
此类跟踪需要使用自动化工具来完成，这些工具可提供足够的日志记录来审计更改。软件存储库历史记录将显示存储在该存储库中的配置文件的更改历史记录。在 Chef 或 Puppet 等声明式配置工具中，每个配置文件代表一组资源，例如用户、包或服务，存储库历史记录将显示这些资源的更改。
答案2
从应用角度来看，记录
- 操作系统和补丁级别
- 安装了哪些分层产品以及应用了哪些补丁
- 安装了哪些自定义和/或第三方产品和库，包括版本
- 在哪里可以找到上述自定义/第三方项目的安装源
- 以上所有产品的产品密钥/SN
- 应用程序级服务器配置（即网络、邮件等）
- 如果有单独的开发团队负责应用程序级别，则提供联系人列表
- 备份配置
注意 - 在回答 romandas 在问题中的评论时，我知道这不完全是一个项目，但在这种情况下，我认为整个文件是一个项目
答案3
对于 Windows，您不需要“跟踪”操作系统的补丁级别，因为可以随时通过 WMI 进行查询。如果您遵循变更管理，您可以在变更前后进行全局查询以验证操作系统补丁的结果。（确保已安装 MSI 提供程序）
应该跟踪驱动程序更新（可以使用 wmi 来查询它们，但不值得花费精力去尝试捕获所有更新）软件应用程序更新应该保存在 CMDB 中，但（最初除外）应该来自变更管理如果您确实想跟踪注册表更改，请设置组策略以启用文件和对象访问并选择要审核的键（http://support.microsoft.com/kb/324739)。这不适用于 CMDB，但可以让您跟踪谁在进行更改。
因此，这就是人们通常希望在 CMDB 中跟踪的内容，也是为什么有时这不是一个好主意，那么应该将哪些内容放入 CMDB 中。答案是视情况而定。ITIL 定义的 CMDB 可能会或可能不会关心机器配置，除非该特定机器配置与服务有关。ACMDB 可能还包含资产跟踪解决方案（用于硬件配置位置和保修信息等内容），但更多地涉及特定配置项与其他 CI 的关系。关系包括“负责”、“连接到”、“依赖于”和（更困难但在许多情况下更重要）“SLA 层级所需”。简而言之，记录重新创建服务所需的内容 - 而不是服务器。
例如。如果电子邮件是服务，我会列出以下内容：
硬件：64 位 CPU、3GB RAM（基于@today 上的用户数）、7GB 服务器安装空间、100GB 存储空间用于交换数据库和恢复（基于@today 的使用情况）、DVD-ROM 驱动器。
软件：Server 2003 R2、Exchange 2007 SP2、SAN 的 MPIO 驱动程序
ETC...
CMDB 通常不供服务器管理员使用。管理员如果使用资产管理解决方案会更开心。
答案4
对于 UNIX/Linux，我将配置文件分为两组：由操作系统提供的配置文件和作为我们自定义应用程序的一部分的配置文件。
所有应用程序配置文件都保存在我们的源存储库中。我为每个安装（开发、QA、生产、预生产、演示……）准备了不同的标准副本。当我们确定需要对其中任何一个进行更改时，更改首先发生在源存储库副本中，然后部署到必要的服务器。我们还会在问题跟踪器中打开相应的更改请求。
对于操作系统类型的配置文件，我们可能在源存储库中拥有它们，也可能没有。如果是，则我们使用上述流程。如果没有，则当更改数量达到某个任意阈值时，我们会将它们放入存储库中。在此之前，我们至少会在问题跟踪器中打开一张票来跟踪该更改。
此外，我们的问题跟踪器的一个很棒的功能是能够索引源存储库提交。它可以将您的票证与您的配置更改很好地联系起来。