六．问题管理

　　问题管理处理逻辑其实是类似事件的，它的许多信息是继承事件，比如等级与类型等。在规划问题管理时，要想清楚问题的分类等级等信息跟事件是什么关系，问题管理的大概作业界面有哪一些，在系统流程上有哪几个步骤，如何留下问题的处理时长与工作量等等。

　　还要想清楚问题与事件在程序处理上的区别，比如问题的创建后需要有一个审批的动作，问题不服从SLA，问题有知名错误的概念，这一部份的设计如果你的事件规划好后，问题管理是相对简单的，它的难不在于程序，而在于日后的应用。

　　问题的统计报表，基本上与事件的纬度类似。

　　七．变更管理

　　在ITIL中，变更与发布是两个独立的流程，我们把这个流程合并为一个。发布的控制在程序中可以实现的控制点是很少的，而且它与变更是如此紧密。在我理解中，变更的实施就是发布流程，即发布可以理解为是变更的一个子流程。发布不仅仅是针对软件的，硬件一样也会有发布的概念，比如将一台新设备布署到生产环境中。

　　对CMDB的控制，在业务层面全部需要通过变更来实现，CMDB精确度如何，很大程度上取决于变更的执行情况。我们考虑到一点，如果让CMDB的信息更新得到有效控制，当工程师在填写变更申请时，在界面上就提列出变更前后的具体信息；审批时，不光是审批变更的行为，更重要的是要审批变更的内容；如果审批通过，执行后，根据这些信息把CMDB做更新。这样可以相对减少没有约束的对CMDB更新的行为。

　　变更管理为什么而存在，在业务上起到什么作用？这些我觉得很多人没有想清楚，很多时候变成变更管理，主要目的是为了实现对CMDB的维护控制，这是对变更管理的曲解。这点上我也犯过这种毛病。

　　变更的主要目的是授权与控制对基础架构或其它服务的改变，这里说的更新是指现实的服务或物理上的基础架构，而不是系统中数据的更新。100条变更请求并不会都落入到CMDB的更新中，可能有5条是对SLA的变更，所以变更与CMDB不是划等号的。

　　当你的工程师对具体设备做维护时，事实上你已赋予他改变基础架构的权利了，如果他把生产环境中的CI做了改变，那他再走变更管理的意义是什么？是为了控制他对CMDB的更新吗，这种控制反而起到负作用；如果无法控制别人对生产环境的变更行为，或者你是默认授权的，最后给予一个通道让他直接维护CMDB，比如一名桌面工程师，在修电脑的过程中，把一台电脑的操作系统升级了，这时他要走变更管理流程吗？

　　我的回答是不应该，除非他不得到批准就不能对操作系统做升级，这时变更才具有意义，不然这种控制是完全负面的。如果这个工程师在修电脑的过程中，发现硬盘彻底坏掉了，需要更换硬盘，可能超出了他的权限范围（这也需要考虑到具体业务定义），这时他不走变更流程根本无法得到硬盘，变更才具有一定意义。

　　但上述情况并不是最具代表性的，这样的业务情形最具有变更管理的代表性：要对一段网络做调整，但可能会影响到几个系统项目，这时需要发起变更申请，由涉及到的几个项目负责人与网络领域的主管一同做变更的评估。如果认为有方法对应，可以进行此次变更的话，需要制作一个变更的实施方案，安排人员实施调整操作。实施完成，把CMDB中的信息更新。

　　变更管理的统计报表，可以从发起源统计，可以从CMDB的角度发起统计，也可以从变更本身的信息进行统计，比如变更的状态、变更的分类、变更的人员等。

　　八．配置管理

　　配置管理模块，核心的就是CMDB，这一点我就不再毒品啰嗦了，把配置管理的流程层面的一些点再说明一下。

　　CMDB的审计：CMDB审计是需要规划好的，应该可以根据各种条件审计，比如根据某一类的组件，某一个项目的组件，还可以确定一定的数量进行审计（随机抽取），也可以决定一定的比率（随机抽取）。审计的目的是为了检查CMDB的数据正确情况，找出问题并修正。

　　CMDB的锁定：CI在某些情况需要进锁定，比如变更时，比如审计时。为什么要这样呢？如果你对一个CI变更时，不锁定这个CI的信息，会发生几个地方同时对这个CI做信息更新，由于时间差，很可能把错误信息更新到CMDB中了；同时用户在变更过程中调用CI信息的话，也会发生误导。所以需要控制单线程对CI进行维护，在同一时间只能有一个对CI维护的动作进行。审计也是一样，如果你审计开始时，这个CI信息一直在动态变化，不锁定CI的话，审计无法进行，同时会审计出一个错误的结果。

　　配置管理的信息可以被许多模块调用，需要规划到CI查询的画面，然后置入到事件、问题、变更、操作等模块中。CMDB的人机界面相当关键，要尽可能方便调用、查询、操作。