企業如何做好運維管理？

最近這二十多年時間做了不少專案，也接觸過大量的使用者。二十多年前，IT管理方面相對比較粗獷，到使用者現場時候也沒太多流程和管控措施，早期甚至把自己的膝上型電腦連到使用者的網路上就開展工作了。自己帶的各種工具用起來很方便。這種管理模式漏洞很多，不利於企業IT的安全管控，因此很快堡壘機、運維專區等紛紛建立。再去使用者現場幹活的時候只能用客戶提供的運維終端了。

經過十多年的發展，一些大企業的IT管理都完善了不少，從安全的角度上看，確實很有必要。不過我手頭的一些不錯的工具和指令碼都沒法用了，做事情麻煩了一些。雖然對我們這種做第三方服務的人來說不夠友好，我還是比較認可企業在安全管控上的這些升級的 。真正讓我覺得有些不解的是，在提升安全管控的同時，很多企業IT運維管理方面的官氣大了不少。

今年有個使用者的系統出現比較嚴重的效能問題，心急火燎的讓我派人去現場幫忙看看。我們的工程師到了現場三天沒能摸到系統，都在走各種流程。還沒等流程走完，系統真的出大問題了，我們那哥們還在酒店等待，突然晚上被叫到現場。這回啥流程都不用走了，因為系統已經無法使用了。於是直接上系統操作，十分鐘幫使用者搞定了問題。無獨有偶，在另外一個最佳化專案裡，我們的一個專家到了現場，因為他沒有參加過安規考試，因此沒有資格連線系統操作，因此他只能坐在一邊請一個不太懂資料庫的哥們幫他敲指令查資料用於分析問題，工作效率之低，令人髮指。後來實在受不了了，就希望讓現場的人放寬一下限制，通融一下，讓他直接操作幾下。現場的人也十分委屈，說這地方到處都是攝像頭，如果期間出了什麼問題，那麼這個不合規的操作將會讓他揹負十分嚴重的責任，甚至可能會因此丟了飯碗。

事後和客戶的DBA聊天，談到這個問題，他也十分無奈。他說IT部門這些年在不斷提升管理，不過總結其主要特點，最主要的特點是權力上收，責任下放。權力上收是指一些決策權都上收了，原來上系統做診斷、監控、分析、最佳化都是一線的標準權利，他這個層面就可以決策了，現在在他們這裡，這些權利都上收到部門級別，甚至更高的級別了。這些操作都必須審批才可以做的，如果沒有經過審批，都屬於違規，一旦出了問題，責任相當大。按理說權力上收了，職責應該也同時上收，系統出問題就應該由上級領導承擔最大的責任了。不過事實上並非如此，現在職責反而是下放了，出問題後要出來承擔責任都是沒啥權力的一線部門。

加強管理後責任劃分十分明確，而且績效和收入、升職等直接掛鉤，因此一線人員不得不考慮一些自保的手段。以往大家都是主動運維，平時也經常會自己對系統的執行狀態、效能問題做一些分析，並主動提出一些最佳化方案。在現在的這種管理模式下，DBA只能透過那些簡單的監控系統和APM去運維資料庫，到資料庫上去採集資料與分析問題都必須提交操作申請，一旦正好你在操作時系統有了點問題，那麼你想澄清是很困難的，因此主動運維和主動找死沒啥區別。

上面有政策，下面也必然有對策。目前他們平時很少直接登入資料庫做運維操作，只是透過監控系統看看資料庫的狀態與日誌告警，或者透過APM系統定期匯出一批慢SQL，作為成果上報到運維繫統，交由開發商去整改最佳化。每年系統都會購買原廠的巡檢服務，原廠巡檢服務中主要提及的也是慢SQL和補丁問題。慢SQL往往只是APM採集的一個子集，補丁要不要打是上級部門決定的事情，他們只需要把報告交上去就行了。

執行模式這麼轉變一下，上級領導感覺管理都閉環了，上報的問題似乎也少了一些。正好趕上這幾年剛剛升級了系統，更換了硬體，因此除了應用問題以外，似乎其他問題也少了不少。應用最佳化是個常態化工作，每年也有相應的經費在支撐，業務部門有啥問題都是研發在應對，IT運營似乎執行良好。

看似風平浪靜的海面下其實暗流湧動，這種模式下，管理制度雖然嚴格了，不太容易出現管理問題了，但是一線運維只剩下了一張皮了，系統中存在的一些亞健康狀態大多被掩蓋住了，一線的運維分析能力也大大退化了，一些水平較高的DBA紛紛離職，目前在一線的DBA都是一些經驗呢不足的新手。再加上系統隱藏的小問題沒有被及時發現，積累下來時間長了，就會積累出大問題，某個時間點上集中爆發出來，就是大問題。事實上，這個客戶這兩年出現過幾次比較大的生產故障，我也幫助分析過。事實上那幾次故障都是一些不難分析的問題觸發的，按照幾年前他們的運維能力，應該都是能夠在一個小時內解決問題的，不過那幾次故障都持續了半天以上。

權力上收，責任下放現在在很多企業裡都已經成為慣例，從管理角度看，似乎嚴謹了許多。甚至在一些不太懂IT技術的高層領導眼裡，這是很好的管理模式，不過在以技術為核心的運維領域，這其實不是一種高明的管理手段，而是取亂之道。

注：原文題目《權力上收責任下放是取亂之道》