配置管理：从ITIL，CMMI到DevOps的实践与思考

作为DevOps的实践者，这么多年经历了很多持续交付有关的工作，似乎在我的印象中“软件配置管理（SCM）”这个概念大概是很多年前流行的，后面很少关注甚至提到这个概念。 最近碰到了一些有关“配置管理”的人和事情，让我重新回顾并思考“配置管理”和组织架构，和DevOps体系建设的关系。

配置管理是什么？

老实说，不同的工作经历的人，对配置管理的理解和定位也各不相同。下面我从几个不同领域，大概阐述下我的理解。

ITIL中关于配置管理的定义

在ITIL（IT Infrastructure Library，IT基础架构标准库）中，配置管理（Configuration Management）是一个关键组成部分，其定义涉及对IT服务中的配置项（Configuration Items, CI）进行识别、记录、控制和审核的过程。

具体来说，配置管理旨在确保配置项（如计算机系统、服务器和其他资产）的准确性和可靠性，以及在整个生命周期内与其需求、设计和操作信息保持一致。这是一个系统工程，用于建立和维护产品性能、功能和物理属性。配置管理的目标主要包括两个方面：

• 一是维持配置管理数据库（Configuration Management Database, CMDB）中每个IT基础建设的配置记录；
• 二是提供配置项（CI）的报表，包含问题记录、变动记录、版本信息、状态信息、关系信息等管理信息。

具体来说，配置管理是对基础结构和系统的所有实体（例如服务器，应用程序，存储，网络和所有托管服务）进行配置，监视，管理和维护的自动化

为了使配置管理系统运行，它需要某种形式的机制来存储其管理的信息。最初，这称为 配置管理数据库（CMDB）；ITIL V3引入了配置管理系统（CMS）的概念来代替CMDB。CMDB提倡单个整体存储库的概念，而CMS提供了CMDB的概念化系统，这些系统共同作用以支持此治理过程的需求。

image.png

DevOps中关于配置管理的定义

在DevOps实践中，配置管理通常与持续集成（CI）和持续部署（CD）等自动化流程相结合，以实现从代码提交到生产环境的快速、可靠和一致的部署。此外，自动化配置管理还促进了环境之间的一致性，无论是开发环境、测试环境还是生产环境，都能保持一致的设置。具体实践包括以下几个方面：

• 代码版本控制
• 自动化部署（如Ansible、Puppet、Chef等，它们经常会被视作自动化配置管理工具）
• 依赖管理
• 基础设施模板（如Terraform，ARM等）
• ...

CMMI中关于配置管理的介绍

在CMMI（Capability Maturity Model Integration，能力成熟度模型集成）中，配置管理是一个重要的组成部分，用于确保软件产品及其开发过程和生命周期的完整性、一致性和可追溯性。

CMMI中的配置管理主要通过以下几个关键活动来实现：

image.png

1. 配置标识：对软件产品及其开发过程中的各类配置项（如文档、源代码、规范、bug等）进行标识，以便在后续的开发和维护过程中能够准确地识别和引用这些配置项。
2. 版本控制：通过版本控制系统（如Git、SVN等）来管理配置项的变更历史，确保每个配置项都有清晰的版本信息和变更记录。这有助于在出现问题时能够迅速定位到问题的根源，并采取相应的修复措施。
3. 基线管理：基线是经过正式评审和批准的配置项集合，作为后续开发的基础。在CMMI中，基线管理涉及到基线的建立、变更和验证等过程，以确保软件产品在不同阶段都能够满足预定的质量标准和需求。
4. 配置审计：通过配置审计来检查基线中的配置项版本是否正确一致、位置是否正确、是否与其功能说明一致等。这有助于确保软件产品的完整性和一致性，并减少潜在的风险和问题。

CMMI中的配置管理强调了对软件产品及其开发过程的全面控制和管理，通过技术手段和行政手段来确保软件产品的质量和可维护性。

不同的“配置管理”解决不同的问题

ITIL领域的配置管理-对IT资产进行管理，控制日常变更

配置管理主要解决以下问题：

• 配置管理工具可以改善组织的变更影响分析，减少由生产变更引起的停机。
• 配置管理结合了有效的服务模型，配置项相互依赖关系映射以及配置项与更改请求之间进行的关联，以帮助在中断期间更快地恢复服务。
• 配置管理系统在设备的历史操作记帐及其使用和修改中提供审核和合规性支持。

image.png

CMMI领域的配置管理-对软件研发过程变更进行管控

CMMI更多还是从宏观上，定义了如何更规范地开展研发活动，项目立项了，建立基线，代码仓库如何分配，代码/文档/问题如何管理，变更如何审批，怎么记录等等。不是CMMI专业人士，只是粗浅理解。

下图，是在网上找个某个项目管理软件关于配置管理的截图。现实中，估计会有很多组织，在用类型excel表格的形式，通过一些流程制度来管理这个活动。

DevOps领域的配置管理 -从自动化工具层面跟踪变更，一切皆代码

CMMI是从宏观上提出了规范要求，但是似乎并没有告诉组织如何落地？另外，CMMI关于配置管理的思想还是建立在“集中式代码管理”基础上的，对于git为代表的“分布式代码管理”好像并不涉及，那么在实际执行中偏差就更大了。关于这一点，欢迎留言讨论。

在DevOps体系中，软件配置管理是“一切自动化”的基石（PS: 更接地气，直面问题）。总结概括就是：将一切纳入配置管理，遵循软件配置管理的 3 个基本原则：一切皆有版本；共享唯一受信源；标准化与自动化。

1）一切皆有版本，指的是：当需要更快地发布软件时，就需要对生产软件过程中的相关内容进行管理，这些内容不仅仅是源代码，配置文件，运行数据，还包括：测试工具包或测试用类库，测试相关的代码，测试数据，测试脚本等。

2）共享唯一受信源，指的是：整个组织需要管理研发团队的所有仓库：需求仓库，代码仓库，软件包仓库，所有团队成员都应该以这些仓库中的内容为基准，相互协作，以确保所有成员所获取的信息都是一致的。其中的软件包仓库，包括 3 种类型：临时产物仓库，正式发布包仓库，外部软件包私服仓库。

3）标准化与自动化，指的是：软件配置管理应该制订相应的标准与规范，例如：分支策略，分支命名，分支Tag命名，产品特性命名以及存放位置，源代码目录结构等。当研发团队成员都了解并遵守这些标准与规范后，不仅仅能够减少不必要的沟通成本，还能够将更多的日常事务性操作自动化，从而释放更多的人力资源，并大大降低手工操作带来的种种失误。

版本.jpg

总之，通过DevOps工具和实践，正确使用和实施配置管理可以保证控制，准确性，可追溯性，可恢复性，一致性，效率和版本控制。

检验研发团队是否做好了配置管理

可以用下面5个问题来验证检查研发团队是否对一切都做了版本管理：

• Q-1：产品源代码和测试代码是否放入了版本控制系统？
• Q-2：软件应用的配置信息是否放入了版本控制系统？
• Q-3：各种运行环境的系统配置是否放入了版本控制系统？
• Q-4：自动化的构建和部署脚本是否放入了版本控制系统？
• Q-5：软件包是否进行了版本管理？

研发团队也可以尝试挑战一下，检验软件配置管理是否做得足够好：

• Q-S1：只要从源代码仓库中检出产品源代码，就可以一键自动化构建出完整的应用软件包吗？
• Q-S2：在没有他人的帮助下，任何研发团队成员都可以一键自动化构建出一套应用软件系统，用于体验产品新功能吗？

对于软件配置管理落地的思考

上面从各个维度介绍了配置管理的定义和实践，那么落地呢？这个是我写这篇文章的起因。我找了两个招聘启事，来阐述这个问题

”配置管理“靠流程（人）还是靠工具？

传统的配置管理(CMMI)，更多还是依赖于【人】去【守护】流程、规则。如果组织/团队规模不大，或者技术架构统一的一套，如果不具备平台自动化能力的情况下，靠【人】来通过【守护】还好说（PS: 前提是，大家都尊重流程和约定）。

如果团队众多，技术栈众多，靠人几乎是不可能了，即使借助一些工具，那真要看“配置管理工程师”的水平了。

“配置管理”与组织架构

估计也只有大点的公司，才有所谓的“配置管理工程师”这样的角色。那么这个角色放在哪个部门合适？

• 分配到组织级管理部门：居庙堂之高，基本是个监督者的角色，对实际项目研发活动控制力很弱。如果是业务/团队众多，基本就没啥用。
• 分配到研发团队：如果团队很大（比如超过100人以上），并且业务单一，这个基本就融进研发团队了，更熟悉业务。

“配置管理”的未来还是团队自治

作为DevOps的实践者，我更倾向于弱化“配置管理”这个流程本身。往大了说，“配置管理”不就是你的研发全过程吗？从issue到代码，再到制品、环境，哪个环节离开了“变更”，配置管理的核心其实就是“控制变更”。

所以，围绕变更做文章（建规则，建工具）。简单说，我告诉团队某个issue需要回滚，能在短时间内（5分钟内）找个上个稳定版本（或者快速生成上个稳定版本），并快速部署到某个指定环境，基本“配置管理”就算做好了。否认，配置管理计划/变更都是一纸空文。

通过建立issue-code-artifact-environment 之间的关联规则，团队完全可以通过自动化手动实现“配置管理”的自我管理。

参考

• https://www.cmcrossroads.com/article/seven-lessons-you-learn-when-growing-your-configuration-management