作者｜趙旻
在撰寫本章的時候，我偶然間看到了陳皓（左耳朵耗子）先生的一篇雜文——《拖累開發團隊效率的困局與解決之道》。文章言語犀利、有話直說的風格是我所喜歡的。雖然我並不是專業的程序員，文章中所提到的一些觀點和我竟有些不謀而合。其實運維和開發之間有很多地方都是相通的。文中所論之痛點，令同道中人會心一笑。尤其是那犀利的批判性言論，待到戳中問題要害之處，卻也有一番快意恩仇的感覺。
本章為大家介紹運維平臺中最為重要的兩大系統 CMDB 和 Workflow。本章旨在談論構建這兩個系統的重要性，以及在構建過程中需要考慮的一些重要因素，並且通過一些故事或實際案例為讀者分析構建過程中的一些誤區。
當然，在剖析分析問題之前，我們還是老規矩——先講兩個小故事做藥引子。
運維故事 1：審計總動員
今年是 Foo 公司創業的第三年。由於業務發展迅速，數據中心的服務器數量已經由原來的 300 臺增長到了現在的 5000 臺。這段期間，公司也發生了很多變化，組織架構調整了多次，人員變動也比較頻繁。這不，今年剛剛走馬上任的審計主管找到審計員小胖，要他負責檢查公司的資產情況。結果這一查，卻惹出了很多麻煩。
小胖到現場一檢查就發現了問題——有 200 臺服務器和資產提交的信息列表對不上。資產信息列表是在服務器入庫時建立的，當時記錄在案的信息都是正常的。而且，資產管理員茜茜很負責，每次設備入庫時，她都對入庫設備的信息進行核對和記錄。然而，小胖在這次檢查的過程中發現，資產信息列表上標明的部分主機現在已經不在當初記錄的位置上了。出現這個問題是由於設備遷移導致的。遷移工作由業務需求方發起，每次遷移工作的內容都是通過電子郵件來傳遞，相關干係人也不是固定的。當遷移工作完成後，有些比較負責的人會把遷移信息通過郵件抄送給茜茜，讓她完成信息的同步更新。但也有一些人沒有這麼做，所以導致一些設備做了遷移，但資產管理員這邊根本不知道。
經核查，數據中心服務器的總數是對的。但是這種說法不符合審計的要求。所以，現在所有被查出問題的服務器，都必須一臺一臺地核對清楚。由於涉及到服務器的查找，茜茜先聯繫了 SE 協助核查。SE 根據問題地址進行核對時發現，有些地址根本 ping 不通。SE 聯繫了監控團隊幫助確認，監控團隊說這些問題地址已經不在線上運行了。於是 SE 又去找 PE 幫忙查詢，PE 說這些問題地址的系統都已經下線了，而且服務器也已經退還了。
不過，他們不記錄 SN 號，所以光憑 SN 沒法找到新的地址。沒辦法，SE 只好抓取了所有能登錄的服務器的 SN 號出來，整理了一張全新的數據給茜茜。但是根據 SN 號，SE 也只能找到新的業務 IP 地址和管理地址而已，並不能據此知曉解服務器的具體位置。查詢歷史郵件電子也很困難，有些郵件隨著人員離職早就不知道哪裡去了。沒辦法，茜茜還得聯繫 IDC 的人，通過帶外管理地址（好在服務器都有可以看到帶外管理地址的液晶顯示屏）去核對機架的信息。一項審計工作，前後牽動了審計、資產、監控、SE、PE、IDC 六方共計十多個人。
誰拖了運維的後腿
故事講完了，我們來看問題出在哪裡？
首先，對於數據信息的存儲和維護，完全依賴於 Excel 表格，而不是建立在數據庫之上。
其次，業務變更通過郵件發起，涉及到的數據變更，是否會通知茜茜進行同步更新，全憑發起人的高度自覺性。沒有數據庫支持、沒有標準規範、工作流程混亂、缺乏約束條件等各種因素導致了最終的悲劇。
雖然，這只是一個虛擬的故事。但是，這種場景對於讀者朋友們來說，想必並不陌生，大家或多或少地都能感覺到一絲熟悉的味道。實際上，類似的問題一直在我們身邊不斷地發生著。
在企業生產經營當中，最為重要的就是數據信息。它為管理者在決策過程中提供了重要的參考依據，而數據缺失和數據失準又會給決策帶來巨大的風險。管理者對於數據的價值與重要性非常清楚，但是從實際執行的表現來看，卻並不盡如人意。就像一個人購買了一輛新車，車主很愛惜的貼了車膜，還購置了腳墊、座椅套等一大堆配件回來。可是，車卻一直停在車庫裡，既不拿來開，也不去保養。等到真正需要用車的時候卻發現——車，開不了了。
傳統的 IT 辦公系統多是面向單一業務的，沒有過多考慮業務之間的聯動關係。報銷系統就只負責報銷，打印系統就只負責打印。然而不幸的是，很多業務處理恰恰不是孤立的。一個業務的執行往往與其他部門、其他人或者其他事務有著很多關聯，這就構成了一個複雜的業務流程。由於各個 IT 系統都是孤立的，當業務從一個環節流轉到另外一個環節的時候，發現在 IT 系統層面上根本無路可走。業務流程在這種缺乏有效管理的情況下，各個系統之間的信息交換不得不依靠人工離線來完成。而在這個過程中，產生了大量的郵件、表格、會議和溝通等遊離於系統之外的副產品，使得工作效率大打折扣。
運維故事 2：叢林野人
話說在一片古老而廣闊的叢林中住著一群野人。在這片叢林最深處有一口清泉，這是叢林中唯一的飲水場所。幸運的是，他們居住的洞穴恰好位於這口清泉的旁邊。喝水是不成問題的，野人們還需要填飽肚子。好在叢林裡到處都長滿了可以食用的野果，野人們就靠採集這些野果來充飢。
日子過得很幸福，野人族群漸漸興旺發達了起來。慢慢地，大家發現，洞穴周邊的野果子都被吃光了。於是他們不得不到更遠的地方去找尋食物。隨著時間的推移，探索的路越走越遠，很多出去搜尋食物的人再也沒有回來。倒不是他們貪玩迷失了方向，而是因為路途太遠又沒有水喝而渴死了。這就陷入了一個兩難的境地，附近沒有食物，遠方又沒有水。這該如何是好呢？身強力壯的野人們開始加強身體的鍛鍊，希望藉此可以讓自己走得更遠一些。只有一個聰明的野人與眾不同，他在空閒的日子裡，藉助原始工具去嘗試著做一個木製的水壺。
又過了些日子，終於方圓五十里內的野果子都採光了，這已是野人們體力的極限了。這時候，那個聰明的野人已經成地完成了自己的作品。他背上一壺水，踏上了探索的征途，當徒步走了三天之後，他驚訝地發現，自己已經站在了叢林的邊緣。而不遠處是一片新的天地，那裡有著豐富的食物和水。原來這片叢林並不像傳說中的那麼廣闊，但是沒人能在缺水的情況下，在叢林裡熬過三天。
運維的困境就在於，沒有提前做好面對質變的準備。團隊疲於應付基於故障處理、基於業務需求的工作，完全沒有時間，甚至沒有意識就產品價值和用戶價值去思考問題。一個開發項目成立的背景，大多是出於需要，而不是項目本身的價值。工作的目標過於功利，往往急於去解決某個具體問題，缺乏解決共性問題的意識。
忙，成為了一切拖延症的最佳理由。團隊在事務優先排序上選錯了度量工具，不用價值來衡量，卻非要去和時間賽跑。不論是傳統運維，還是互聯網運維，錯誤的驅動原力都會讓你的團隊陷入一個明日復明日的怪圈。
注：本文節選自《IT 基礎架構：系統運維實踐》。
趙旻 ，《IT 基礎架構：系統運維實踐》作者，獲得 RHCA/RHCSS/MCITP 認證，十年以上互聯網金融、電信、政府等多領域背景的從業資歷，曾參與中國國家電子政務多項重點工程的安全信任體系的建設工作，為中國移動、中國航空等大型企業提供技術支持。熟悉 x86 平臺基礎架構系統的建設、管理及運維工作，並醉心於運維產品的設計與體驗。樂於在工作實踐中分析問題、總結經驗，具有持續優化的能力，屬於主動管理型的工作者。資深面試官，產品設計評論人，《運維前線》聯合作者，現專注於管理學、產品設計、基礎架構運維等領域。
閱讀更多 InfoQ 的文章
