運維平臺的建設思考-後設資料管理（五）

關於運維平臺的建設，後設資料一直是一個很重要的環節，之前在聽了ITIL方面的一些講解之後，發現其實早已經是體系之中的，想必是很多公司很多人還沒有重視起來而已。
而要說運維平臺和後設資料，其實我也一直比較糾結，因為我不是專業的，只是在工作中越來越意識到它的重要性，很多時候不是口上說說，提提而已，而要落到實處，更不能圖形式。
    我們先來說說工作之中的溝通，其實我有時候也蠻偷懶的。用一個基本的溝通方式來說，能當面就不電話，能電話就不用lync，能用lync就不用郵件。這個是一個方向，實際做起來就很難，我之前的公司的很多領導都會這麼提倡，也是提高工作效率的一種方式，相比於現在的敏捷運維而言，不就是類似的思路方法嘛。
工作之中的郵件本身只是一種工作形式，我們無法根據郵件數來考核KPI,無法根據郵件的回覆情況來判斷每個人工作的情況，我也看到過很多工作中郵件踢皮球，郵件中的辦公室政治（有時候都分不清情況，不好站隊)，郵件中的各種推諉。算了先不提這些，我們要說的是，郵件也可以提高工作效率，就是一種正式的，資訊量比較多的時候，前提還是要透過基本的溝通清楚明白了之後。
    就比如我們處理日常工單，有些工單開發同學都不用發郵件，電話，lync告訴我，我一看到工單就知道他要做什麼，在什麼環境等等，都一目瞭然。而有些同學開的工單就讓人比較糾結。我看了工單看不明白，裡面也沒有任何環境描述，每次發郵件回覆就非常費勁，來來回回可能一上午就過去了。而且不一定馬上能得到我希望的結果。有時候在lync上能幾句話說清楚的，也還好，不過我就想為啥一次不說清楚呢。那些郵件，lync都搞不定的，趕緊電話吧，很多時候問題聽起來很緊急，很嚴重，其實明白了問題就很容易處理了。比如之前有個開發同學聯絡我，說有個問題非常緊急，但是工單裡也沒有提供環境，沒有更多的輔助資訊。最後確認發現他所說的環境就不是我負責的。還有個開發同學在我坐地鐵的時候打電話，說有個任務非常緊急，希望馬上處理，當時訊號不好，大體聽明白了問題，其實就不是資料庫的問題；還有些問題聽起來很緊急，好像是交到我手上開始就很緊急，結果一看工單，又是個三無工單（沒有環境，沒有描述，描述指令碼)，你說讓我怎麼快速處理，好容易要來指令碼，發現指令碼又有問題，我這個時候就會認真的告訴他們，這是線上環境，這一點上標準和規範優先順序要更高。
    所以我引申出一個觀點，制度和規範也是後設資料的一部分。
    就拿最近的一件事情為例。我們有一個基本的退換伺服器的流程，群發郵件大家都收到了。但是後面應該是發現直接關閉防火牆有一些風險，所以又收到了一封郵件，裡面的描述就是這個流程中需要注意，不要直接關閉防火牆。而我在處理這個問題的時候，郵件實在太多了，於是就搜尋關鍵字，找到的郵件就是第一封，因為裡面的步驟最全，而且其中就有一條是可以新增主機信任，或者直接關閉防火牆，我也是為了圖省事，直接就關閉了防火牆，做了伺服器退還，當然退還之前我在現有系統做了遮蔽和登出，所以我們沒有收到任何的異常報警，但是系統組反饋說他們收到了大量的報警簡訊，於是這個問題就最終變為了開通防火牆的事情了。然後又收到一封郵件，如果退還伺服器關閉防火牆算是人為故障，你說這種事情你找誰說去。當然我選擇了沉默，這種事情糾纏起來也很費勁，但是我的總結如下。第一個是報警的劃分，如果不是具體負責的同事和組，報警資訊都他們是無效的，發與不發有什麼意義，這個需要明辨，而一種方式就是在資產和監控系統對接起來。第二個就是規章制度類的資訊也是後設資料，這類資訊很重要，透過郵件又很容易出現資訊不同步不一致的情況，為何不透過統一的portal或者公共頁來顯示，如果有什麼變更情況，也很容易同步過來，新來的同事可以馬上了解到這個流程。就可以避免更多的問題，資訊不共享，不同步是主要根源，而不是透過加重懲罰力度來實現。
    所以後設資料的責任還是意義重大，我們希望更加這些資訊來組織得到一個完整全面的資訊鏈，這個意義更為重大。