上周五在北京，原本約了優諾的傲寒想找他去聊聊，然後再回家，因為臨時有事未能前往。每次和傲寒聊聊都會有很多收獲，這回沒能見面聊一聊，覺得有些遺憾。不過在機場的時候看到了天旦的CEO Vader的《運維的意義》，看了以後深有同感，立即就轉發到朋友圈了。文中談到有些感悟也是和傲寒交流後有所悟。我想看到這篇文章，也可以彌補一些缺憾了吧。我也是做了二十多年運維的人，對運維是什麼也常有所思考，但是這些思考都是碎片化的，并沒有真正的去了解與認知運維的意義。今天仔細想想發現我隻是做了二十多年的運維“工作”，而做實際工作的人隻是做慣某些事情，僅僅是做習慣了，并不會去深究你做這些工作的意義。是以雖然你在行業裡很資深，很多問題還是看不明白的。就像前幾天很熱的《你怎麼還在招聘DBA？》，正反方讨論的很熱烈，看誰的觀點似乎都有點道理，不過似乎都存在一定的偏見和執念，似乎在為某些事情代言。運維的意義到底是什麼呢？不管企業的體系如何，管理制度如何，運維的意義應該是確定系統能夠在滿足SLA的前提下，以比較經濟的成本運作。如果不是如此，那麼運維工作和運維部門的存在意義就不大了。有很多制造業企業，規模很大，但是IT運維并不是主業，是以很可能不常設運維人員，系統出了問題，花點錢找人搞定。如果這樣成本低于常設運維部門，那麼這種模式也未嘗不可。有些企業從來不做資料備份和容災，出問題花點錢折騰幾下，實在不行重建資料庫，丢失已有的資料。如果企業經營者認為這樣更省錢，也是沒有關系的。IT運維的最核心的價值應該就是輔助企業的生産與核心業務。
我們回過頭來再來看運維的意義，而不過多的糾纏“資訊化、數字化的意義”。最近我在寫文章時候喜歡問問ChatGPT,這回它的回答和我的想法是基本一緻的。運維的意義并不在于更快地發現問題，防患于未然等我們原本認為的事實。這些我們原本認為是運維的意義的東西實際上都是達成“運維的意義”所采取的手段。實際上達成運維意義的手段不僅僅是運維人員所認知的那些，從業務部門優化業務開始，到系統設計，開發，IT基礎設施建設，傳遞，運維，下線，整個過程中，在多個方面都可以確定運維意義的達成。不同的企業會在不同的階段投入更大，而在某個階段投入較少。如果你不想招聘DBA，那麼大規模上雲，并且在開發前期更多的減少運維的需求，花大價錢錢買RDS的各種運維服務，那麼不招聘DBA也不是不可以的。企業經營者根據自己的業務特點與IT系統的特點來算一算，哪種更劃算就可以了。很多企業認為上雲是最便宜的，不過也有一些上雲的企業算了算下雲更劃算一些。我在MEDIUM上經常看到上雲降本增效的例子，也能看到下雲節約40%成本的真實故事。這些事情都是與企業的特點以及企業業務的特點相關的，并不能從一家企業的成功來否定别人的選擇。企業的IT運維有輕研發重運維、重研發輕運維和運維研發平衡等多種模式，不同模式的企業來看是否還需要招聘DBA的問題，有不同的看法那就很正常了，是以一些觀點無所謂對錯。我十分認同Vader的觀點，運維存在的原因是因為各種錯誤和故障的存在。我們總是為了系統能夠更少故障的運作而在設計建設階段付出了很多卓越的工作，總是希望能夠研發出一套可以很好的運作的系統，但是我們想研發出完全不需要運維的系統的追求就像追求永動機一樣希望飄渺。無論如何，運維總是存在的，哪怕我們不需要專門的運維部門而是由研發人員來做運維。再好的資料庫也還有成筐的BUG呢，何況一群不那麼優秀的碼農寫就的程式。号稱堅固無比的公有雲平台還架不住挖掘機來兩下，設計再優秀的系統也無法避免理想模型與現實的差異。從另一端來看，我們想通過運維來解決所有問題的目标也很難實作，就像陽明心學中所說的物本身和表象一樣，如果運維部門總想看透系統的本質，并從根本上解決系統的問題，也是無法做到的。物本身是十分複雜的，連設計研發系統的人都無法預料到系統可能發生的一切，通過表象去運維系統的人就更無法讓系統完全在自己預設好的場景中運作了。我們要想運維系統，就隻能通過對表象的觀察為基礎來進行。以資料庫為例，我們監控資料庫的時候，最初級的隻能通過現象來發現問題。而随着我們對資料庫的認知加深，我們可以通過名額資料和日志等來發現并定位資料庫的問題，故障的發現可以更早了，不需要現場出現就可以了。不過還是不夠，我們還需要更高的運維能力，是以我們通過各種數學模型來發現與預測資料庫可能發生的故障，了解資料庫運作的現狀與趨勢。實際上這些年我們做系統運維與優化的過程也正是這麼一點點進步起來的，最初我們運維的時候，隻能從現象去比對已有的故障案例，進而找到類似的案例來照貓畫虎的處置。随着能力的提升，我們可以建立各種運作基線，通過專家經驗與名額基線來輔助分析，進而能從故障中發現更為細微的差别，更好地進行運維與優化。這樣的模式我們使用了十多年，經驗越來越豐富，處置的效率也越來越高，不過我們發現具有這樣能力的專家數量太少，而IT系統越來越複雜，越來越多，是以我們又開始通過更易用的模型來解決這些問題。為了讓使用模型的門檻越來越低，我們總是在追求通過更優秀的模型與算法來實作對資料庫運作的更精準的掌控，但是模型可以越來越精準，但是無法達到發現一切問題的層次，這是因為我們的一切判斷的依據來自于數學模型，而數學模型可以很好的逼近事實，但是無法達到物本身。實際上很多企業在IT管理上并沒有真正的了解“運維的意義”，在需求、設計、研發、運作方面并沒有考慮到成本最優的問題，是以在投資上的決策也偏離了本心，不過最終的決策是否合理，從不同的立場上看，可能也會有偏差。最後舉個泛IT的案例，與運維不直接相關，不過也可以看出我這段話要表達的意思。一個企業要替換ORACLE，他們有很多系統都是基于Oracle研發的，使用了大量的存儲過程。在資料庫選擇上，我建議使用與Oracle文法相容度較高的資料庫去替代，比如達夢等國産資料庫，應用幾乎不需要做修改就可以遷移過去了。不過上司不同意，他認為達夢還要購買，他們的運維能力也不足，MySQL是開源的，不用花錢買許可證，自己的運維團隊也有一定的經驗，還是遷移到MySQL更劃算。我給他算了筆賬，買國産資料庫隻需要十來萬 ，而把應用從Oracle存儲過程遷移為MySQL要花上百萬，遷移時間也要多花半年多，明顯算着不劃算啊。上司一笑，遷移雖然花錢更多，但是開發商是我們下屬的三産公司，哪個更劃算呢？