|
发布与部署管理(Release and Deployment Management):以下简称 RM
变更管理(Change Management):以下简称 CM
到底 CM/RM 还是 CM+RM,关键点在于现在面对的变更的对象的性质与复杂度。
环境:
1. Oracle 数据库(总部 * 1 / 分公司 * 1)
2. 数据库类型:开发数据库、测试数据库、生产数据库
职能与角色:业务架构师、数据治理委员会、数据架构师、数据建模师、DBA、应用架构师、程序员、基础设施架构师、网络管理员、变更项目经理
变更项目经理发起一个 CM:
变更评估:
业务架构师:
1. 需要为每个客户记录“客户信用评级”
2. 由于涉及客户隐私,后续设计与实施务必高度考量合规问题。
应用架构师:
1. 评估变更没有问题,请数据架构师提供相应数据与表结构变更。
数据架构师:
1. 需要在客户基本档(Entity)上多记录一个属性(Attribute):客户信用评级
2. 与业务架构师沟通后发现,属性(客户信用评级)应当参照(Reference)总部某个数据库中的已经定义好的参照数据,该参照表已经定义了十个客户信用评级。
3. 由于参照表在异地的总部的数据库中,需要在分公司数据库中建立“数据库连接”(DB-LINK)。
4. 请基础设施架构师提供网络支持。
基础设施架构师:
1. 防火墙需要开通 1521 端口,经评估没有安全疑虑可以执行。
变更管理 Part 1:
1. 数据架构师 - 为新的业务属性变更数据字典,经数据治理委员会评审并核准变更(变更评审),根据IT治理章程数据建模师或数据架构师经过适当的审批后准予对元数据库实施立即变更。(在这个变更中只有 CM 没有 RM)
2. 数据建模师 - 为新的业务实体变更数据模型,经数据治理委员会评审并核准变更(变更评审),根据IT治理章程数据建模师或数据架构师对数据库的权限仅到开发阶段(就是不能自己去改数据库的任何东西),操作阶段由DBA负责。
3. DBA - 接手数据建模师,将新的数据库结构变更到"测试数据库"(请注意我这里用“变更”而不是“发布”),会同数据建模师与架构师验证变更是否成功、是否产生任何错误或风险。并且制定相应的回退机制(重要)。
4. 数据架构师 - 会同业务架构师、应用架构师、程序员测试该项变更是否已经达到要求(对测试数据库)(变更评审)。
--- 至此 CM 结束了吗?并没有哦~~ 刚刚都是前菜,大菜现在上场,生产环境进来了。
变更发布:
5. 网络管理员 - 根据CM,发起一个 RM(编号:01),对“生产环境”的防火墙“发布”这个“变更”。就是改防火墙的权限啦~
6. 网络管理员 - telnet 目标服务器 1521 端口,确认配置生效。(RM 阶段的测试与评审)
7. DBA - 根据CM,发起一个 RM(编号:02),对“生产环境”数据库 - 建立DB-Link,建立数据表,外键参照 ...
8. DBA - 并测试所有修改是否生效(RM 阶段的测试与评审)
变更管理 Part 2:
9. 数据架构师 - 会同业务架构师、应用架构师、程序员测试该项变更是否已经达到要求(对生产数据库)(变更验收)。
10.变更项目经理 - 最终确认所有的变更的前因后果、过程,都已经正确的、清楚描述的保存到 CMDB 中,所有与数据相关的变化都已经更新到元数据库中。
11.向参与者与IT治理章程中规定的权责人、利益相关者提交结案报告(通常是月报或者季报)。
12.结案
从以上案例可以看出“发布”是与生产环境有关,“变更”从策略、需求、设计阶段就开始了,涵盖“发布”阶段,但某些情况不需要这么麻烦“变更”“发布”其实是一回事,然后直到项目收尾,变更才算结束。
|
|