ITIL实施记实之配置管理经验谈(1)(3)

2) CI关系

如果建立我们公司的所有运维对象地图，会发现某种意义上，配置项之间的关系类似电路图，因而引入数字电路的基本逻辑概念，从应用的视角构建新型的组件之间的关系，将组件的结构与关系独立出来，分而治之。在逻辑电路的基本逻辑的类型如下：

与门(当一个事件由两个以上的条件决定时，只有全部条件为真时，条件才能成立)

现实中，如果一道门有两把锁，只有这两把锁全部打开时，门才能打开，这就是一种与的关系。

或门(当一个事件由两个以上的条件决定时，只要任一条件为真时，条件就能成立)

或的关系，在IT环境中就很多了，比如将一台编号为A001的电脑这个CI，与其子节点的，CPU、内存、硬盘、操作系统等就是一个或的关系，即只有CPU、内存、硬盘、操作系统这其中任何一个CI出现问题，都会导致A001这个CI出现问题。

非门(当一个事件的条件为假时，对象才为真)

非的关系，我们暂时不考虑加以引用，本来的是考虑利用此非的关系将CI的备件等进行关系构建(备用设备，或维修备件)，但想到一些现实问题，备件用其它的方式进行管理，不直接引用关系，以免过于复杂。

这里面还需要说明几个比较重要的概念：

关系的视角：

我们构建CI的关系，是从被影响的角度出发的，这一点非常重要，因为事实上中关系总是双向的，一号CI会影响别的 CI，别的CI也会影响一号CI，这时如果双向构建很可能会导致重复构建或错误构建，由于我们的关系只需要用来分析当故障出现时会导致的结果，所以我们只用单流向的关系，即可满足需求(这个道理类似以面介绍的，用简单的逻辑组装成一个复杂的事物)，因为当所有CI从被影响的角度出来后，网状关系即已形成。这一点需要很好思考一下，不然理解会出问题。下图是一个应用方面的示意，我的想法利用关系，届时可以图形化推演故障路线，这样可以直观的采用紧急预案切断故障路线(红色为故障组件)。

关系构建原则：

在逻辑上，可参一个CI会直接与间接与所有CI有关系影响，但很显然，我们无法将一个CI直接与其它所有CI去构建关系，那需要找到一个机制去解决这个问题，说到这儿要说一下我的爱好，我一直喜欢看DISCOVERY的节目，大家在看到一些自然记录片时，会看到一大群鸟或蝗虫在天空飞行时，是聚集在一起的，象一团乌云一般，再或者我们在看海底时，那些鱼群在水中游动时，总是保持一个集合，不管它们往哪个方向游动，总是非常有效的保持一个群的形态，这些东西看起来很有美感，并感到有些不可思议，其实在这个下面，只是一个简单的原则，当鱼群游动时，每一条鱼只需要与邻近的鱼保持适当的距离，这样最终就会群。我把这个叫鱼群原则，在CI的关系构建时，我当时也碰到如何去有效构建关系的问题，最近我发现利用这个原理，可以解决，即一个CI只与结构相邻或直接影响的CI构建关系，这样构建关系就会简单很多，当每一个CI用这样的机制去构建完成后，也会形成一个庞大的群，会把所有的CI有机制的串联在一起。

在用与、或的关系构建关系，我发现一个原理，如果IT环境的与关系越多这个IT环境是会相对稳定的，不易被故障将环境瓦解，同时故障的影响度也会较低，因为一个点发生故障，不会马上导致业务应用出现问题。或的关系越多，运维将变成更为吃力，因为每一点的影响都会导致后果发生。这也某程度上指导了我们日后的方案设计与运维管理。

是不是我们现在的这种关系构建是完美无缺的?它到底存在什么问题，有什么局限性，这一点真正深入思考的人，应该会发现关键所在的，在我所构想的整个配置模型中，有两个比较大的局限，我不打算独自一个人去挑战这两个最难的命题，因为我很清楚对于当前的业务而言，这个模型可以满足他们很多年，我再深入去挖掘，对于业务需要而言，过于超前了，同时我个人不太希望在这个方面走得太过深入，也因为志不在此，如果真正投入精力去研究，我觉得是有可能找到一个终极模型的，因为我已知道方向在哪儿，局限何在。想到这些我就对现在的这些理论传播者或那些顾问公司有意见，这些东西是不应该由我们这样的公司，或者我这样的人去研究的。就象我写的这些文字，我相信那些ITIL的制定者、传播者是没有告诉过我们的，我在项目初期在在百度与 GOOGLE上流浪N久，就是想找到我现在写的这些文字，但一无所获，有的只是那些大而空的理论，听起很有道理，但是你根本无法将它与现实业务去结合起来思考。不扯了，继续往下!