【文章內(nèi)容簡介】 而引入數(shù)字電路的基本邏輯概念，從應(yīng)用的視角構(gòu)建新型的組件之間的關(guān)系，將組件的結(jié)構(gòu)與關(guān)系獨立出來，分而治之。在邏輯電路的基本邏輯的類型如下：u 與門（當(dāng)一個事件由兩個以上的條件決定時，只有全部條件為真時，條件才能成立）現(xiàn)實中，如果一道門有兩把鎖，只有這兩把鎖全部打開時，門才能打開，這就是一種與的關(guān)系。u 或門（當(dāng)一個事件由兩個以上的條件決定時，只要任一條件為真時，條件就能成立）或的關(guān)系，在IT環(huán)境中就很多了，比如將一臺編號為A001的電腦這個CI，與其子節(jié)點的，CPU、內(nèi)存、硬盤、操作系統(tǒng)等就是一個或的關(guān)系，即只有CPU、內(nèi)存、硬盤、操作系統(tǒng)這其中任何一個CI出現(xiàn)問題，都會導(dǎo)致A001這個CI出現(xiàn)問題。u 非門（當(dāng)一個事件的條件為假時，對象才為真）非的關(guān)系，我們暫時不考慮加以引用，本來的是考慮利用此非的關(guān)系將CI的備件等進行關(guān)系構(gòu)建（備用設(shè)備，或維修備件），但想到一些現(xiàn)實問題，備件用其它的方式進行管理，不直接引用關(guān)系，以免過于復(fù)雜。這里面還需要說明幾個比較重要的概念：關(guān)系的視角：我們構(gòu)建CI的關(guān)系，是從被影響的角度出發(fā)的，這一點非常重要，因為事實上中關(guān)系總是雙向的，一號CI會影響別的CI，別的CI也會影響一號CI，這時如果雙向構(gòu)建很可能會導(dǎo)致重復(fù)構(gòu)建或錯誤構(gòu)建，由于我們的關(guān)系只需要用來分析當(dāng)故障出現(xiàn)時會導(dǎo)致的結(jié)果，所以我們只用單流向的關(guān)系，即可滿足需求（這個道理類似以面介紹的，用簡單的邏輯組裝成一個復(fù)雜的事物），因為當(dāng)所有CI從被影響的角度出來后，網(wǎng)狀關(guān)系即已形成。這一點需要很好思考一下，不然理解會出問題。下圖是一個應(yīng)用方面的示意，我的想法利用關(guān)系，屆時可以圖形化推演故障路線，這樣可以直觀的采用緊急預(yù)案切斷故障路線（紅色為故障組件）。關(guān)系構(gòu)建原則：在邏輯上，可參一個CI會直接與間接與所有CI有關(guān)系影響，但很顯然，我們無法將一個CI直接與其它所有CI去構(gòu)建關(guān)系，那需要找到一個機制去解決這個問題，說到這兒要說一下我的愛好，我一直喜歡看DISCOVERY的節(jié)目，大家在看到一些自然記錄片時，會看到一大群鳥或蝗蟲在天空飛行時，是聚集在一起的，象一團烏云一般，再或者我們在看海底時，那些魚群在水中游動時，總是保持一個集合，不管它們往哪個方向游動，總是非常有效的保持一個群的形態(tài)，這些東西看起來很有美感，并感到有些不可思議，其實在這個下面，只是一個簡單的原則，當(dāng)魚群游動時，每一條魚只需要與鄰近的魚保持適當(dāng)?shù)木嚯x，這樣最終就會群。我把這個叫魚群原則，在CI的關(guān)系構(gòu)建時，我當(dāng)時也碰到如何去有效構(gòu)建關(guān)系的問題，最近我發(fā)現(xiàn)利用這個原理，可以解決，即一個CI只與結(jié)構(gòu)相鄰或直接影響的CI構(gòu)建關(guān)系，這樣構(gòu)建關(guān)系就會簡單很多，當(dāng)每一個CI用這樣的機制去構(gòu)建完成后，也會形成一個龐大的群，會把所有的CI有機制的串聯(lián)在一起。在用與、或的關(guān)系構(gòu)建關(guān)系，我發(fā)現(xiàn)一個原理，如果IT環(huán)境的與關(guān)系越多這個IT環(huán)境是會相對穩(wěn)定的，不易被故障將環(huán)境瓦解，同時故障的影響度也會較低，因為一個點發(fā)生故障，不會馬上導(dǎo)致業(yè)務(wù)應(yīng)用出現(xiàn)問題?；虻年P(guān)系越多，運維將變成更為吃力，因為每一點的影響都會導(dǎo)致后果發(fā)生。這也某程度上指導(dǎo)了我們?nèi)蘸蟮姆桨冈O(shè)計與運維管理。是不是我們現(xiàn)在的這種關(guān)系構(gòu)建是完美無缺的？它到底存在什么問題，有什么局限性，這一點真正深入思考的人，應(yīng)該會發(fā)現(xiàn)關(guān)鍵所在的，在我所構(gòu)想的整個配置模型中，有兩個比較大的局限，我不打算獨自一個人去挑戰(zhàn)這兩個最難的命題，因為我很清楚對于當(dāng)前的業(yè)務(wù)而言，這個模型可以滿足他們很多年，我再深入去挖掘，對于業(yè)務(wù)需要而言，過于超前了，同時我個人不太希望在這個方面走得太過深入，也因為志不在此，如果真正投入精力去研究，我覺得是有可能找到一個終極模型的，因為我已知道方向在哪兒，局限何在。想到這些我就對現(xiàn)在的這些理論傳播者或那些顧問公司有意見，這些東西是不應(yīng)該由我們這樣的公司，或者我這樣的人去研究的。就象我寫的這些文字，我相信那些ITIL的制定者、傳播者是沒有告訴過我們的，我在項目初期在在百度與GOOGLE上流浪N久，就是想找到我現(xiàn)在寫的這些文字，但一無所獲，有的只是那些大而空的理論，聽起很有道理，但是你根本無法將它與現(xiàn)實業(yè)務(wù)去結(jié)合起來思考。不扯了，繼續(xù)往下！3) CI分類 本來按正常的邏輯，CI分類應(yīng)該放在第一位去思的，而不是先去說結(jié)構(gòu)談關(guān)系，這樣做一是因為我們的確是先把結(jié)構(gòu)與關(guān)系理清后，才去做CI分類的，二是覺得在結(jié)構(gòu)關(guān)系沒有做一交待前，可能先談后面的東西，會不利于了解，這也是因為社會上沒有把CI的結(jié)構(gòu)與關(guān)系跟我們做一些規(guī)范或定義，才造成的，正常來說，我們真正開始做具體的配置工作時，CI分類應(yīng)該是第一步，這個過程會非常重要，在沒有真正開始做前，我還沒有意識到它的影響會這么大。再說明一下項目的情況，配置的結(jié)構(gòu)、配置的關(guān)系，基本上我一個人去完成思考的，沒有動用到公司的管理資源，當(dāng)這些定下來后，開始做CI分類時，這就需要走出辦公室，調(diào)動管理資源了，因為這不是一個人思考就可以決定的，這一點很重要，日后各位從事這樣的活動時，也需要把管理資源拉上，能抓到多少資源就要去抓，這是一個很好的洗腦的過程也是一個很好的互動過程，讓具體的業(yè)務(wù)領(lǐng)域及高層管理者開始真正參與進來。 記住一句話：CI的一級分類決定了配置管理的范圍，CI的最底層分類決定了配置管理的顆粒度。這句話是后面真正領(lǐng)悟總結(jié)出來，一開始也沒有意識。CI分類我們的做法是這樣的，我們先找一些對業(yè)務(wù)領(lǐng)域比較熟的專家或管理者，首先談CI的一級分類，我們談著談著，發(fā)現(xiàn)談不下去了，因為沒有具體的數(shù)據(jù)支持，我們根本無法確定一級分類，于是我們轉(zhuǎn)變策略，先發(fā)模版，讓公司的各個業(yè)務(wù)領(lǐng)域把自已所有的運維對象全部羅列出來，最終收集上來是五花八門的清單，這就是我們最初的數(shù)據(jù)，然后我們再組織人員討