云计算技术中心配置管理流程设计与实现

1、云计算技术中心配置管理（CMDB）流程设计与实现目录 HYPERLINK l _bookmark0 技术中心配置管理流程设定3 HYPERLINK l _bookmark1 配置管理（CMDB）设计的目的3 HYPERLINK l _bookmark2 关键角色、职责定义3 HYPERLINK l _bookmark3 配置控制委员会（Configuration Control Board，CCB）3 HYPERLINK l _bookmark4 项目经理（Project Manager，PM）3 HYPERLINK l _bookmark5 配置管理架构师（Configuration Man

2、agement Officer，CMO）4 HYPERLINK l _bookmark6 配置库程序管理员（Program Librarian，PL）4 HYPERLINK l _bookmark7 项目工程师（Project Engineer， PE）4 HYPERLINK l _bookmark8 配置管理执行5 HYPERLINK l _bookmark9 流程图5 HYPERLINK l _bookmark10 1.3.1流程描述6 HYPERLINK l _bookmark11 配置管理（CMDB）框架变更8 HYPERLINK l _bookmark12 变更请求的提出8 HYPE

3、RLINK l _bookmark13 变更评估8 HYPERLINK l _bookmark14 变更审核8 HYPERLINK l _bookmark15 变更实施9 HYPERLINK l _bookmark16 变更确认9 HYPERLINK l _bookmark17 L2C 配置管理（CMDB）模型设计构建10 HYPERLINK l _bookmark18 CMDB 配置框架设计图10 HYPERLINK l _bookmark19 CMDB 配置管理分层模型设计10 HYPERLINK l _bookmark20 CMDB 中的对象关系设计11 HYPERLINK l _boo

4、kmark21 CMDB 中自动录入与手动录入设计11 HYPERLINK l _bookmark22 CMDB 中面向应用的配置管理一致性设计11 HYPERLINK l _bookmark23 与其他流程的关系13 HYPERLINK l _bookmark24 和变更管理流程的关系13 HYPERLINK l _bookmark25 CMDB 中配置项变更设计13 HYPERLINK l _bookmark26 生产变更流程与回滚14 HYPERLINK l _bookmark27 和发布管理流程的关系14技术中心配置管理流程设定配置管理（CMDB）设计的目的为了更科学、规范的纳管技术中

5、心的资源，减少资源孤岛配置，关联所有有效资源对象。实现一个高效率管理信息系统，为内部，为客户提供持续可靠的运维服务关键角色、职责定义云计算技术中心配置管理流程主要分为以下几个职责/角色，分别简述如下：配置控制委员会（Configuration Control Board，CCB）责任：权利：制定和修改项目的配置管理策略；接受配置管理计划，并按相关规定贯彻与执行； 接受配置控制委员会的报告。批准、发布配置管理计划；建立、更改基线的设置，审核变更申请； 根据配置管理员的报告决定相应的对策。人员安排： 技术中心项目经理、配置管理员、客户代表、项目工程师等项目经理（Project Manager，PM

6、）责任：权利：与 CCB 协商确定项目起始基线和开发里程碑； 接受配置管理计划，并按相关规定贯彻与执行； 接受配置控制委员会的报告。 提出配置管理计划的修改要求； 提出配置管理的建议和要求。技能要求： 了解技术架构和项目环境； 较强的口头表达能力和与客户沟通技巧； 处理纠纷的能力； 深刻了解技术中心配置管理流程； 较强的领导能力。人员安排： 技术中心项目经理配置管理架构师（Configuration Management Officer，CMO）责任：权利：编制配置管理计划； 执行配置项管理方案；执行版本控制和变更控制方案； 编制配置状态报告；向 CCB 汇报有关配置管理流程中的不符合情况。技

7、能要求： 了解配置管理架构和项目环境； 深入了解技术中心的配置管理标准； 有足够的流程设计理论积累； 较强的口头表达能力与文档能力；人员安排： 配置流程设计与规划负责人。由二线工程师中的流程小组 Leader 担任配置库程序管理员（Program Librarian，PL）责任：权利：配置库的建立和权限分配；配置管理工具的日常管理与维护； 配置库的日常操作和维护；各配置项的管理与维护；对项目工程师进行相关的培训技能要求： 对配置信息技术有深入掌握； 对配置参数调整产生的影响有足够的了解人员安排： 配置流程框架执行者。由二线工程师中的流程小组成员担任项目工程师（Project Engineer，

8、 PE）责任：权利：项目的实施部署； 项目资源的录入； 文档的版本生成；按照指定的流畅，完成配置项的日常录入和更新；技能要求： 对项目有足够深入了解； 对服务器环境有深入了解； 对所有项目相关信息有足够了解人员安排： 配置流程框架执行者。由项目工程师担任1.3 配置管理执行1.3.1 流程图流程描述 配置管理的启动-CCB 的成立配置管理计划启动：技术中心 Leader 决定创建配置管理流程，发起配置管理构建MSP 项目合同签订后，项目经理可以发起配置管理构建成立配置控制委员会（CCB）配置控制委员会做为配置管理的总负责评审组，负责整个配置管理的生命周期与决策。CCB 成员人数一般为奇数，人数

9、在 37 人范围内。CCB 成员包括：项目经理 PM；配置管理员 CMO；客户代表（当为项目创建配置管理时加入）；项目工程师等。CCB 的决策机制原则上要求 CCB 成员意见达成一致。在不能达成一致情况下，可投票决策。技术部发起的配置管理需求，在无法达成一致情况下，由 CCB 成员投票确定，投票超过半数即为通过；客户项目中无法做出决策的情况下，客户代表拥有最终决策权；客户项目中，客户代表没有无法做出决策情况下，采取少数服从多数的原则，由 CCB 成员投票确定，投票超过半数即为通过。 配置需求确认CCB 成立后，由 CCB 组织会议根据项目的迁移部署计划确定各个里程碑和最终托管策略。RACI：明

10、确配置管理中关键角色和工作范围CMO：负责编制配置管理计划书，按约定的时间点设计配置框架模版配置管理员 CMO；负责配置管理的整体管控，配置实施和配置管理计划的实施配置基准确认：确定配置初始基线和配置项列表配置范围确认：明确要配置的资源范围 配置管理设计完成CMO 根据 CCB 会议决议的设计基线，开始设计配置管理计划书，包含：配置管理需求；实施配置管理的责任人及其职责；配置进度安排；标识规则配置文档更新规范特殊配置要求 BaseLine（客户要求）配置库设计；配置库分类文档类AWS 资源类配置范围项目文档（Documents）：项目规划、服务保证计划、合同信息、技术报告、交付文档、用户指导手

11、册、事故总结报告等；应用（Application）：应用描述、版本号、安装历史；工具（Tools）：自动设计工具、开发工具、测试工具、维护工具等；托管的 AWS 服务资产信息（AWS Resources）：用户账号下托管的 AWS 资源，如 EC2，ECS，EBS 等；权限分配（PL、PE）a)PL 可为每个项目的主要负责工程师分配配置库操作权限，辅助 PL 完成不同项目的配置管理工作。一般地，为了工作能更加顺利的进行，可以适当的下发 Add、 Checkin/Checkout、Download 等权限，但是绝对不能给予“删除”权限。同时保证 PL 的最高操作权限。c)PE 负责后续对配置项的

12、更新，原则上不允许拥有“删除”权限，不允许拥有配置框架修改权限配置库的创建配置管理计划审核通过之后，PL 即可着手组织建立配置库。所有项目应建立配置库，以便管理各配置项。文档库空间可由 wiki 系统创建，PL 仅创建基线文档库，仅 PL 可以对其操作。AWS 资源库可通过调用 AWS API 定时导入 Jira 系统，项目工程师帮忙玩善，仅 PL 可以对其操作。AWS 资源库和文档库由 CMO 统一管理，根据项目各阶段的实际情况定制相应的版本选取规则，来保证托管服务的正常运作。在变更发生时，应及时做好基线的推进。配置库管理操作规范；项目工程师可根据获得的授权的资源进行操作配置库的工作，例如

13、Add、Checkin/Checkout、Download 等；配置库的检出，当发生变更且变更评审通过后，或者发现错误且错误评审通过后，由 PL 或者主要负责工程师将配置库中的相关配置检出至相关项目工程师手里，让其完善配置；PL 或者主要负责工程师根据配置管理计划创建与维护基线，变更开始时，需要“冻结”配置项来控制变更；配置库的检入，当变更实施结束或错误修正和验证结束，并通过配置审核后，由 PL 或者主要项目工程师重新录入配置库中；PL 定期清除配置库里的垃圾文件；PL 定期备份配置库。 合规审核CMO 提交设计文档给 CCB 评审。如果通过评审，则进行下一步构建，如果未经过评审，则去修正配置

14、管理计划书，直至通过评审。 配置管理执行PL 拿到通过评审的配置管理计划书，按照设计规划书执行配置框架构建。配置构建：AWS 资源模版构建自定义资源创建配置文档管理构建（wiki）配置核查PL 提交最终的配置框架给 CCB 评审。如果通过评审，则进行下一步信息初始化，如果未经过评审， 则需要 CCB 判定问题，并讨论修正配置管理计划书，开始配置循环，直至配置构建通过评审。配置信息初始化PL 对初始信息进行配置PE 根据部门/项目需求开始录入配置项信息 配置管理维护配置管理完成后，最终由配置控制委员会（CCB）完成确认，进入后续配置维护环节，配置变更构建结束。PL 持续对配置管理维护PE 持续对

15、配置项进行更新 配置管理更新当前配置无法满足业务配置需求，需要修改配置框架时，由 PL 提交申请给配置控制委员会，重新启动配置变更流程1.4 配置管理（CMDB）框架变更在当前的配置管理体系无法满足技术中心新增加的配置管理需求或项目上无法满足管理需求时，需要对当前的配置管理框架进行调整，通过配置变更流程完成 CMDB 框架变更。变更请求的提出 由发起者（客户/PE）确定变更，填写变更请求/评审单，描述变更原因和变更内容，提交给 PM/中心 Leader PM/中心 Leader 进一步评估需求，认为需求合理且有必要操作，提交给 PL 初审 PL 根据当前配置管理架构，确认无法满足需求，需要修改

16、配置框架，提交给 CMO 评估框架可行性设计，需求发起变更评估 CMO 对填写的变更请求/评审单进行全面评估表，对申请表是否清晰、明确和完整性进行审查，若 CMO 发现变更不明确或不完整，应返回申请表给最初发起者。 当 CMO 认定变更请求/评审单为可执行时，针对需求出具配置变更评估报告变更评估原则：变更评估要分析每个变更对当前 AWS 资源、后期维护、成本、项目进度以及约定需求的影响，同时还要分析对服务的可靠性、可维护性、可移植性和性能的影响；配置变更评估报告应描述若实施变更必须变更的配置项、文档和资源；CMO 完成配置变更评估报告后，更新变更记录，并安排 CCB 会议日程。变更审核 CCB

17、 对提交的变更申请进行审核，并根据变更评估确定变更的影响级别；CCB 审核可能的结果有三种：接受变更；拒绝变更；延期变更。当 CCB 认为信息不足时，需要 CMO 或其它相关人员提交更多信息。 变更结果确认CCB 批准的变更，由 CMO 将变更项目发送到指定的项目工程师进行下一步的实施变更工作；CCB 拒绝的变更，由 CMO 将 CCB 拒绝变更的原因发送给发起者，并保存变更请求/评审单，更新变更记录，关闭变更活动；CCB 确认延期变更，需要进一步分析的，由 CMO 将变更项目随同 CCB 的 Question Sheet 发送给评估分析人员；对于延期的变更，由 CMO 对变更的相关文档进行归

18、档，以便在适当时机提交 CCB 审核。 CMO 负责整理 CCB 会议记录，填写变更请求/评审单中相应审核项；更新变更记录，如果是接受变更，还需将要变更的 CIs 状态改为“修改中”；将变更文档分发给相关人员。变更实施变更被批准后，PL 负责变更的实施，并详细记录变更的内容；由项目经理/中心 Leader 对变更的实施进行跟踪。 对于 AWS 资源管理方式变更，必须修改设计、持续合规、测试以及变更正确性的验证。而且与变更相关的文档必须修订，以反映变更。当变更以及测试完成后，可以正式使用。 对于项目计划、配置管理计划发生变更的，项目组人员要按照变更过的项目计划、配置管理计划提交配置项。变更确认变

19、更实施完成后，CMO 需对变更进行审核，审核的范围一般涉及以下方面：测试记录；变更请求；配置项的检入及检出；文件的命名；版本的编号。 审核完成后，生成最新的配置版本，由 PL 更新到基线库中。 PL 应重新标识所有被影响的配置项及版本。 生成新版本后，CMO 负责收集所有变更信息归档，修改变更 CIs 状态为“正式发布”，关闭变更，并将变更报告发送给发起者。框架变更完成1.5 L2C 配置管理（CMDB）模型设计构建CMDB 配置框架设计图CMDB 配置管理分层模型设计基础原则：分层构建。以 AWS 资源为核心基础构建资源模型，由 MSP 业务需求切入扩展对象。 核心模型。即资源模型，构建基于

20、 AWS 原生资源框架的资源对象定义。该模型的原生信息通过 AWS API 自动获取，动态更新。核心模型记录了 AWS 资源基本的关系信息。该模型主要是为了支持运维基础资源的依赖对象关联； 扩展模型。手动定义的模型，扩展模型是依赖核心模型的扩展。扩展模型中的对象基于应用需要找到关联的资源信息，如；基于某个应用名 ftp 找到对应的实例 EC2，通过该 EC2 的关联找到依赖它的其它资源对象信息，比如 AMI、CFN 模版、OS 版本号等等。通过不断的扩展对象模型来完善运维需求。根据分层原则，构建基于 AWS 资源核心模型的 CMDB 分类。 Resource：AWS 资源的发现与管理。与 AW

21、S Console 通过 API 保持强一致性，所有资源做为其它资源对象的基础 Maintenance: 运维配置信息管理。L2C 从运维需求入手，所有手动资源全部在此录入。此处也是 L2C 运维配置管理的起点 Document：文档管理。按照项目维护所有相关的文档信息，指向 wiki 链接CMDB 中的对象关系设计基础原则：配置关系不传递原则。所有资源在配置对象关系时仅考虑直接关联对象，所有关系不跨越对象进行传递。为减少设计复杂性，L2C 在 CMDB 模型设计中仅约定三种关系，三种关系如下： 主从关系。这种关系是一种强相关关系，当主不存在时，从一定不存在，且从无法离开主单独存在。在 L2C

22、 的配置管理平台中用从属 Belong 来表达。如 CPU、内存和宿主机 EC2 的关系，应用与代码的关系，监控报警与指标都属于该种关系 依赖关系。是一种对象属性级之间的关联关系，对象之间非强相关，可以单独存在，但是A 必须依赖 B 才能创建。比如某个 IP 对象必须依赖子网对象才能创建，某个应用程序要依赖主机实例对象才能存在，这是对象级别的关系 关联关系。一种连接关系，两者有联系，但存在本身不依赖，可以单独存在。如 EC2 与EIP 的关系，应用系统与文档的关系。CMDB 中自动录入与手动录入设计基础原则：由自动发现降低维护的成本和代价。通过手动录入应用资源并创建与资源对象的关联 涉及到 A

23、WS 资源状态的变更，全部保持自动化，维护 CMDB 与 AWS 控制台中资源的强一致性。 运维配置管理与项目文档配置按照真实情况由手动录入完成 关联关系由手动录入配置完成CMDB 中面向应用的配置管理一致性设计基础原则：保证项目中同一版本应用配置的一致性 L2C 的配置管理中以应用配置对象为运维起点，所有录入基于应用来完成 分离应用对象所涉及关联的对象，用于一致性保证软件包一致性根据 OS 不同单独维护两个分支，保证异构系统中应用软件包的一致性在独立分支的软件包对象中，包含软件包对象的常规信息。如安装包位置、日志目录、配置文件、端口号等软件包的版本：同一类软件包的不同版本单独创建对象维护软件

24、包的独立性：应用软件包在独立的对象分类 software 下维护软件包的最小单位：以应用进程/开发语言为最小单位。如：java、python、tomcat7软件包的关联：软件包可以被多个应用配置对象关联。应用对象差异偏离修正。应用配置的对象按照业务系统进行分类，当应用引用的软件包跟真实配置有差异时，在应用对象中自行修订，原则上不允许修改软件包的基础信息。如端口号，启动脚本与基础软件包不一致时，在应用对象中单独定义字段修正1.6 与其他流程的关系和变更管理流程的关系变更流程涉及到修改配置参数时，需要 pending 在 CMDB 录入阶段，必须在该节点完成 CMDB 的变更。仅当完成 CMDB

25、变更后，才可以最终关闭工单CMDB 中配置项变更设计 变更触发：当客户/内部提交工单请求 L2C 运维人员响应工单，根据 Jira 工单中的变更流程执行变更 当变更完成后，执行变更检查，有客户确认后完成工单- 工单完成后由变更流程触发 CMDB 配置项变更开始，由 PE 执行变更执行：变更前需要 pending 状态到 CMDB 的更新，防止配置不一致当修改配置项信息时，需要确认当前 Status 状态为非“updating”，如果为“update”状态，不允许修改当 Status 状态为非“In-use”时，修改“Inuse”到“updating”，锁定修改变更结束：当配置项信息修改结束后，修改状态为“In-use”，把 jira 工单号记入 comment配置变更检查：所有的更新录入起点必须从应用开始检查，核查应用对象是否为变更对象资源变更：除非确认为手动修正资源，否则不允许修改资源对象应用配置项：手动录入的变更内容，需要二次核准文档变