跳转到主要内容
SEO Title
IT configuration management

什么是配置管理

配置管理(CM)是一个系统工程过程,用于建立和维护产品性能、功能和物理属性与其整个生命周期内的需求、设计和操作信息的一致性。CM管理过程被军事工程组织广泛用于管理复杂系统(如武器系统、军用车辆和信息系统)整个系统生命周期内的变更。在军队以外,构型管理流程还用于ITIL定义的IT服务管理,以及土木工程和其他工业工程领域的其他领域模型,如道路、桥梁、运河、水坝和建筑物。

介绍

在系统生命周期中应用的CM提供了对其性能、功能和物理属性的可见性和控制。CM 验证系统是否按预期运行,并被识别和详细记录以支持其预计的生命周期。CM过程有助于有序管理系统信息和系统变更,以达到修改能力等有利目的;提高性能、可靠性或可维护性;延长寿命;降低成本;减少风险和责任;或纠正缺陷。实施CM的相对最低成本在避免成本方面返回了许多倍。缺乏CM或其无效实施可能非常昂贵,有时可能会造成灾难性后果,如设备故障或生命损失。

CM强调零件、子系统和系统之间的功能关系,以有效控制系统变更。它有助于验证是否系统地考虑了提议的变更,以尽量减少不利影响。使用标准化、系统化的方法提出、评估和实施系统变更,以确保一致性,并根据拟定变更对整个系统的预期影响对其进行评估。构型管理验证变更是否按照规定执行,项目和系统的文件是否反映其真实配置。完整的构型管理计划包括存储、跟踪和更新组件、子系统和系统的所有系统信息。

结构化构型管理计划确保项目的文件(如要求、设计、测试和验收文件)准确且与项目的实际物理设计一致。在许多情况下,如果没有CM,文档是存在的,但与项目本身不一致。因此,工程师、承包商和管理层经常被迫在进行变更前编制反映项目实际状态的文件。这种逆向工程过程在人力和其他资源方面是浪费的,可以使用CM最小化或消除。

历史

配置管理起源于20世纪50年代的美国国防部,作为硬件材料项目的技术管理规程,现在几乎在每个行业都是标准做法。20世纪60年代末,国防部制定了一系列军事标准,称为“480系列”(即MIL-STD-480、MIL-STD-481和MIL-STD-483),随后于20世纪70年代发布,构型管理过程成为了自己的技术规程。1991年,“480系列”被合并为一个称为MIL–STD–973的单一标准,然后根据国防部的一个总体目标,即减少军事标准的数量,以支持由标准开发组织(SDO)支持的行业技术标准,由MIL–HDBK–61取代。[7] 这标志着现在已经发展成为最广泛分发和接受的CM标准ANSI-EIA-649-1998的开始。CM学科的概念现在被许多组织和机构广泛采用,包括系统工程(SE)、集成后勤支持(ILS)、能力成熟度模型集成(CMMI)、ISO 9000、Prince2项目管理方法、COBIT、ITIL、产品生命周期管理和应用生命周期管理。许多这些功能和模型已经从传统的整体技术管理方法中重新定义了CM。一些人将CM视为类似于图书馆员的活动,并将变更控制或变更管理作为一个单独或独立的学科。

 

概述


CM 是系统地处理变更的实践,以便系统随着时间的推移保持其完整性。 CM 实施策略、程序、技术和工具,用于管理、评估提议的变更、跟踪变更状态并在系统变更时维护系统和支持文档的清单。 CM 计划和计划为成功开发和支持复杂系统所需的程序、功能、服务、工具、流程和资源的开发和实施提供技术和管理指导。在系统开发期间,CM 允许项目管理人员在整个生命周期中通过验收、操作和维护跟踪需求。由于需求和设计中不可避免地会发生更改,因此必须对其进行批准和记录,以创建系统状态的准确记录。理想情况下,CM 过程应用于整个系统生命周期。大多数专业人士与资产管理(AM,另见 ISO/IEC 19770)混淆或混淆,资产管理在其中盘点手头资产。 CM 和 AM 之间的主要区别在于,前者不管理财务会计方面,而是管理系统支持的服务,或者换句话说,后者 (AM) 试图从 IT 资产中实现价值。

硬件和软件配置项目的 CM 过程包括五个不同的学科,如 MIL-HDBK-61A[12] 和 ANSI/EIA-649 中所建立。这些纪律[由谁?] 执行,作为建立基线和执行标准变更管理过程的政策和程序。 IEEE 12207 流程 IEEE 12207.2 也有这些活动并添加了“发布管理和交付”。这五个学科是:

  • CM 计划和管理:指导 CM 计划的正式文件和计划,包括以下项目:
    • 人员
    • 职责和资源
    • 培训要求
    • 行政会议指南,包括程序和工具的定义
    • 基线流程
    • 配置控制和配置状态计费
    • 命名约定
    • 审计和审查
    • 分包商/供应商 CM 要求
  • 配置标识 (CI):包括设置和维护基线,这些基线定义了系统或子系统架构、组件以及任何时间点的任何开发。它是对系统任何部分的更改进行识别、记录并随后通过设计、开发、测试和最终交付进行跟踪的基础。 CI 在系统及其配置项 (CI) 的整个生命周期(开发、生产、部署和运营支持)中逐步建立和维护系统的配置状态核算 (CSA) 的当前确定性基础,直至处置。
  • 配置控制:包括对所有变更请求和变更建议的评估,以及它们随后的批准或不批准。它涵盖了控制对系统设计、硬件、固件、软件和文档进行修改的过程。
  • 配置状态核算:包括记录和报告配置项描述(例如,硬件、软件、固件等)以及设计和生产期间所有偏离基线的过程。如果出现疑似问题,可以快速确定基线配置的验证和批准的修改。
  • 配置验证和审计:对硬件和软件的独立审查,目的是评估是否符合既定的性能要求、商业和适当的军事标准,以及功能、分配和产品基线。配置审核验证系统和子系统配置文档是否符合功能和物理性能特征,然后再纳入架构基线。

软件


主条目:软件配置管理
软件配置管理 (SCM) 过程被从业者视为处理软件项目变更的最佳解决方案。它在各个时间点标识软件的功能和物理属性,并对标识的属性的更改进行系统控制,以在整个软件开发生命周期中保持软件的完整性和可追溯性。

SCM 过程进一步定义了跟踪更改的需求,以及验证最终交付的软件是否具有应该包含在发布中的所有计划增强功能的能力。它确定了必须为每个软件项目定义的四个过程,以确保实现一个健全的 SCM 过程。他们是:

  • 配置标识
  • 配置控制
  • 配置状态记账
  • 配置审计

这些术语和定义因标准而异,但本质上是相同的。

  • 配置识别是识别定义配置项每个方面的属性的过程。配置项是具有最终用户用途的产品(硬件和/或软件)。这些属性记录在配置文档中并建立基线。在这些属性发生更改的情况下,对属性进行基线化会强制实施正式的配置更改控制过程。
  • 配置更改控制是更改配置项的属性和重新设置它们的基线所需的一组流程和批准阶段。
  • 配置状态核算是在任何时间记录和报告与每个配置项关联的配置基线的能力。
  • 配置审计分为功能和物理配置审计。它们要么发生在交付时,要么发生在改变生效的那一刻。功能配置审计确保实现配置项的功能和性能属性,而物理配置审计确保配置项按照其详细设计文档的要求进行安装。

配置管理数据库(CMDB)


ITIL 指定使用配置管理系统 (CMS) 或配置管理数据库 (CMDB) 作为实现配置管理行业最佳实践的手段。 CMDB 用于跟踪配置项 (CI) 及其之间的依赖关系,其中 CI 代表企业中值得跟踪和管理的事物,例如但不限于计算机、软件、软件许可证、机架、网络设备、存储,甚至此类项目中的组件。

CMS/CMDB 的好处包括能够执行诸如根本原因分析、影响分析、变更管理和当前状态评估等功能,以用于未来状态战略的制定。示例系统通常将自己标识为 IT 服务管理 (ITSM) 系统,包括 FreshService、ServiceNow 和 Samanage。

信息保障


对于信息保障,CM 可以定义为通过控制在信息系统的整个生命周期中对硬件、软件、固件、文档、测试、测试装置和测试文档所做的更改来管理安全特性和保证。 [13] [需要更好的来源] 用于信息保证的 CM,有时也称为安全配置管理,它依赖于 IT 平台和产品及其环境的性能、功能和物理属性来确定用于衡量系统的适当安全特性和保证配置状态。例如,作为组织 Internet 边界一部分的网络防火墙与作为内部本地网络防火墙的网络防火墙的配置要求可能不同。

维护系统


配置管理用于保持对复杂资产状态的理解,以期以最低成本保持最高水平的可服务性。具体而言,它旨在确保运营不会因资产(或资产的一部分)超出计划寿命限制或低于质量水平而中断。

在军队中,这种类型的活动通常被归类为“任务准备”,旨在确定哪些资产可用以及用于哪种类型的任务;一个典型的例子是航空母舰上的飞机是否配备了用于地面支持的炸弹或用于防御的导弹

操作系统配置管理


配置管理可用于维护操作系统配置文件。 [14]示例系统包括 Ansible、Bcfg2、CFEngine、Chef、Nix、Otter、Puppet、Quattor、SaltStack、Terraform、Pulumi 和 Vagrant。其中许多系统利用基础设施即代码来定义和维护配置。

配置维护的 Promise 理论是由 Mark Burgess 开发的,在当今的计算机系统中,CFEngine 软件能够执行实时修复和预防性维护,并在计算机系统上进行了实际实施。

预防性的维护


主条目:预防性维护
了解资产及其主要组件的“原样”状态是维护、修理和检修以及企业资产管理系统中使用的预防性维护的基本要素。

复杂的资产,如飞机、船舶、工业机械等,取决于许多不同的部件是否可用。这种适用性通常根据组件自新、自安装、自维修以来的使用量、它在其整个生命周期中的使用量以及其他几个限制因素来定义。了解这些组件中的每一个如何接近使用寿命一直是一项涉及劳动密集型记录保存的重大任务,直到软件的最新发展为止。

预测性维护


主条目:预测性维护
许多类型的组件使用电子传感器来捕获提供实时状态监控的数据。计算机在船上或远程位置对这些数据进行分析,以评估其当前的适用性,并越来越多地使用算法来评估其可能的未来状态,这些算法基于先前的故障示例通过现场经验和建模来预测潜在的未来故障。这是“预测性维护”的基础。

准确及时的数据可用性对于 CM 提供运营价值至关重要,而缺乏这一点通常会成为一个限制因素。捕获运营数据并将其传播给各种支持组织本身正在成为一个行业。

随着原始设备制造商 (OEM) 提供的程序的增长,这些数据的消费者变得越来越多、越来越复杂。这些旨在为运营商提供有保障的可用性,并使运营商管理资产的情况变得更加复杂,但 OEM 承担确保其可服务性的责任。

标准


许多标准支持或包括配置管理,[19] 包括:

  • ANSI/EIA-649-1998 国家配置管理共识标准
  • EIA-649-A 2004 国家配置管理共识标准
  • ANSI EIA-649-C 2019 配置管理标准
  • ISO 10007 质量管理体系 – 配置管理指南
  • 联邦标准 1037C
  • GEIA 标准 836–2002 配置管理数据交换和互操作性
  • IEEE 829 软件测试文档标准
  • 828-2012 IEEE 系统和软件工程配置管理标准。 2012. doi:10.1109/IEEESTD.2012.6170935。 ISBN 978-0-7381-7232-3。
  • MIL-STD-973 配置管理(2000 年 9 月 20 日取消)[20]
  • NATO STANAG 4427 系统生命周期管理中的配置管理,包括
  • NATO ACMP 2000 配置管理政策
  • NATO ACMP 2009 配置管理指南[21]
  • NATO ACMP 2100 配置管理合同要求
  • CMMI 用于开发的 CMMI,版本 1.2 配置管理
  • CMII-100E CMII 企业配置管理标准[22]
  • 配置管理及相关标准的扩展列表[23]
  • ITIL 服务资产和配置管理
  • ISO 20000:1 2011 & 2018 服务管理体系。
  • ECSS-M-ST-40C Rev.1 配置和信息管理[24]


指南

 

  • IEEE 828-2012 系统和软件工程配置管理标准,[25] 发布日期:2012-03-16
  • ISO 10007:2017 质量管理——配置管理指南[26]
  • NATO ACMP-2009 – 配置管理指南[21]
  • ANSI/EIA-632-1998 系统工程流程
  • ANSI/EIA-649-1998 国家配置管理共识标准
  • GEIA-HB-649 – 配置管理实施指南
  • EIA-836 配置管理数据交换和互操作性共识标准
  • MIL-HDBK-61B 配置管理指南,[27] 2020 年 4 月 7 日
  • MIL-STD-3046 配置管理,[28] 2013 年 3 月 6 日,2015 年 6 月 1 日取消
  • 国防采办指南,[29] 4.3.7 SE 流程中的 CM 元素,5.1.7 生命周期支持中的 CM 属性
  • 系统工程基础,第 10 章配置管理[30]
  • 配置管理计划美国国防部采购文件[31]

建造


最近[何时?] 配置管理已应用于大型建设项目,这些项目通常非常复杂,并且需要记录大量细节和更改。联邦公路管理局等建筑机构已将配置管理用于其基础设施项目。 [32]有一些基于施工的配置管理工具,旨在记录变更单和 RFI,以确保项目按计划和预算进行。这些程序还可以存储信息,以在基础设施完成时帮助维护和修改基础设施。一个这样的应用程序 ccsNet 在由联邦运输管理局 (FTA) 资助的案例研究中进行了测试,其中首先通过比较洛杉矶县大都会交通局 (LACMTA) 大约 80% 的完整建设来衡量配置管理的有效性红线的第二段,一个耗资 53 亿美元的铁路建设项目。这项研究的结果表明在这种性质的项目上使用配置管理是有益的。 

CM

原文:https://en.wikipedia.org/wiki/Configuration_Management_(ITSM)

 

配置管理(ITSM)

什么是配置管理(ITSM)?

配置管理 (CM) 是 ITIL 版本 2 和 IT 服务管理 (ITSM) 流程,用于跟踪 IT 系统中的所有单个配置项 (CI),该系统可能像单个服务器一样简单,也可能像整个系统一样复杂 IT部门。 在大型组织中,可能会任命一名配置经理来监督和管理 CM 过程。 在 ITIL 版本 3 中,此流程已重命名为服务资产和配置管理。

配置项

 

配置项(CI)是可能依赖于其他IT流程和/或与其他IT流程有关系的IT资产或IT资产的组合。CI将具有可能是分层的属性和将由配置管理器在CM数据库中分配的关系。

属性

  • 技术–描述CI功能的数据,包括软件版本和型号、硬件和制造商规格以及其他技术细节,如网络速度和数据存储大小。键盘、鼠标和电缆被视为耗材。
  • 所有权–金融资产管理的一部分,所有权属性记录CI的购买日期、保修、地点和负责人。条形码和类型等标识号,如软件、硬件和文档也是所有权属性。
  • 关系–硬件项目(如打印机)、软件(如驱动程序)和用户(如Alice)之间的关系。

配置管理数据库(CMDB)

CM 的基本组件是 CM 数据库 (CMDB),它包含 CI 信息,用于了解 CI 关系并跟踪其配置等.

活动


CMDB 中的信息用于五项基本活动:

  • 计划:CM 计划详细涵盖了接下来的三到六个月,以及接下来的十二个月的大纲。每年至少审查两次,将包括战略、政策、范围、目标、角色和职责、CM 流程、活动和程序、CMDB、与其他流程和第三方的关系,以及工具和数量要在 CMDB 中跟踪的 CI 类别决定了范围。 CI信息的细节是深度。
  • 标识:所有 CI 的选择、标识和标记,它创建系统中每个 CI 的部件列表。这涵盖了有关 CI 信息的记录,包括硬件和软件版本、文档、所有权和其他唯一标识符。 CI 应该按照业务需要的详细程度进行记录,通常达到“独立更改”的级别。这包括定义系统中 CI 的关系。
  • 控制:这可确保从接收到处置只接受和记录经授权和可识别的 CI。它确保在没有适当控制文档的情况下不会添加、修改、替换或删除 CI。已批准的 CI 更改请求、更新的规范。所有 CI 都将受变更管理 (ITSM) 控制。
  • 监控:关注每个 CI 的整个生命周期。它支持更改 CI 并通过各种状态跟踪其记录,例如订购、接收、测试、使用、维修、撤回或处置。
  • 验证:审查和审计验证 CI 的物理存在,并检查它们是否正确记录在 CMDB 和部件列表中。它包括在对实时环境进行更改之前验证发布管理 (ITSM) 和 CM 文档的过程。

原文:https://en.wikipedia.org/wiki/Configuration_Management_(ITSM)

Tags