我為什麼要把退休前的這段時間都用在和運維知識自動化系統死磕上

         

我的團隊做系統最佳化是從2003年開始的。應HP SERVICE的邀請，2003年我加入了他們的海爾系統最佳化組，負責Oracle資料庫的最佳化工作。這是我第一次參加大型系統的最佳化工作，甚至那時候我還不知道一個大型售後服務系統的最佳化該從何處入手。我是帶著李維斯的一本書出發去青島參加這個最佳化專案的，透過這個專案，我對Oracle資料庫的最佳化有了初步的認識。後來我又幫助HP完成了對華為SCM系統所採用的CAF平臺的效能評估，並對決策者建議及時中止這個專案，避免更大的資金浪費，因為這個專案已經無法最佳化了。後來HP採納了我的建議，關閉了基於CAF平臺的專案，華為也重新選擇了Oracle EBS作為SCM系統和ERP系統的基礎。從那以後，我們的團隊規模越來越大，做的最佳化專案也越來越多，也鍛煉出了一批做系統最佳化的專家。

2011年，我們開始幫助國家電網做系統最佳化，剛開始的幾個專案在專家的帶隊下，效果都特別好。客戶希望我們擴大最佳化範圍，制訂了一個需要近百名DBA的大型最佳化專案。我們從很多合作伙伴處招募了數十名DBA共同參與這個專案，為了確保專案的質量，我們對整個團隊進行了多次集中培訓。不過最後這個專案做下來效果很不理想，最主要的原因就是DBA的能力參差不齊，大多數沒有參加過大型最佳化專案。從那個專案開始，我也在思考傳統的依靠人和專家的運維模式存在的問題，希望找到一條道路，能夠讓專家的經驗發揮更大的作用。這是我開發D-SMART，一個運維知識自動化系統的初衷。要想構建一個知識自動化系統，必須提高運中的數字化程度。不過傳統行業IT運維的數字化程度很低。其主要原因有幾個方面。

資源有限：很多企業可能沒有足夠的資源去投入研發和實施智慧化運維繫統，或者可能認為將資源投入其他方面更有回報。

文化因素：一些企業可能更願意依靠人工經驗而不是自動化系統，可能是因為他們缺乏對自動化系統的信任，或者他們可能認為在緊急情況下專家的判斷比機器更可靠。

技術限制：一些企業可能缺乏必要的技術基礎設施來支援智慧化運維繫統，這可能需要較高的成本投入來升級裝置和系統。

意識不足：一些企業可能沒有意識到數字化運維的潛在優勢，或者可能沒有足夠的知識和了解數字化運維的實施方法。

雖然傳統行業在運維數字化上存在各種認知的不足，但隨著技術的發展和數字化的日益重要，智慧化運維將成為未來資訊系統運維的一個趨勢，也是一個必然的方向。

反思我們這些年做系統最佳化與運維的工作經歷，經驗不足的技術人員是導致最佳化工作效果不佳的重要因素。最佳化工作需要專業知識和技能，而不是僅僅依靠經驗。可能需要更加系統化的培訓來確保所有參與最佳化工作的人員具備必要的技能和知識。此外，最佳化工作的效果也受到多個因素的影響，如系統設計，資料質量和最佳化工作的過程等。

隨著技術的不斷髮展，現在已經有許多智慧化的演算法與方法可供使用，可以大大提高運維效率和減少人為錯誤。透過運維知識自動化工具可以提供智慧化分析和自動化操作，以幫助DBA更好地管理和最佳化系統。如果企業有足夠的資源，可以考慮引入這些工具和系統來改善運維效率。“運維知識自動化系統”結合了大資料分析、人工智慧等技術，以及專家經驗和工作積累，構建了一個全面的運維知識體系，可以幫助提高運維工作的效率和質量。透過監控指標體系、健康模型、運維知識圖譜、異常檢測演算法等技術，“運維知識自動化系統”可以自動化地分析和解決系統效能問題，同時還能提供智慧化的最佳化建議和決策支援，為企業的運維工作提供了強有力的支援。

實際上D-SMART系統開發的最重要的目的是對我們這個團隊這二十多年在IT運維與系統最佳化上的經驗的總結，讓團隊中的專家把這些年積累的經驗變成可自動化執行的數字化知識庫。並透過不斷的迭代知識庫，讓運維知識不斷的能夠在平臺中沉澱與積累，從而不斷提升自動化分析的能力。

這個系統的研發不僅僅依賴於研發團隊，知識工具的研發完全由DBA完成，而沒有藉助於普通的運維人員。這是因為普通的研發人員並不瞭解IT運維，不瞭解資料庫，不瞭解效能最佳化。只有做過運維工作的DBA才能夠更加準確的把專家的思路變成自動化的工具。

D-SMART系統的起點是指標體系，我認為指標是專家經驗的一部分，而且是十分重要的一部分，專家認知後的指標才是可以完全解讀的指標。而目前很多資料庫監控軟體提供的很多指標，運維人員無法正確解讀，哪怕這些指標出現了異常，可能也無法被發現，或者說發現了指標異常也無法感知到系統哪個地方出現了問題。而專家梳理出來的指標資料都是單一可被專家解讀的，因此每個指標都會被專家進行標註，打上特定的標籤。

D-SMART的第二步是完成指標的準確採集，準確的採集到每個指標的資料對於智慧化運維繫統來說十分關鍵。要確保每個資料都能夠準確的反映出資料庫的真實狀態十分關鍵。很多資料被採集回來後，需要經過加工才能變成可被使用的指標，這些加工演算法裡也體現了專家的經驗。透過這個步驟，D-SMART系統在不斷的獲取資料庫執行狀態的數字化模型。

第三步是對採集回來的指標、日誌資料進行自動化的建模分析。我們透過健康模型判斷資料庫的執行狀態是否正常，是否存在風險；透過效能模型瞭解資料庫的總體效能狀態；透過負載模型瞭解資料庫當前的負載情況；透過故障模型發現資料庫可能存在的隱患，並及時報警。

第四步是利用這些被採集回來的資料自動完成各種巡檢工作。比如日檢，每天半夜系統會自動對前一天採集的資料做分析，發現其中的風險與隱患，並生成日檢報告。每個月或者每個星期，可以定製任務對最近採集的資料進行自動化分析，生成巡檢報告。這種巡檢能夠分析全面的資料，比傳統的靠人工採集資料，人工進行分析的方式擁有更為豐富的資料。透過自動化分析的演算法也更加高效。

利用這些資料，還可以做很多有價值的分析工作，比如容量預測、效能最佳化、專項審計等。同時利用標準化的指標體系，我們還可以構建一線運維與二三線運維的數字化溝通，透過完善的指標集，可以儘可能全面的為三線運維提供資料庫執行的全景檢視，真正做到不用到現場，專家可以盡知天下事。

前陣子80多歲的母親一定要給我過個生日，這些年在外面跑，已經有十多年沒有過生日了。插蠟燭的時候才發現，過完生日已經54歲，離退休已經時日無多了。我想在現在還能做點事情的時候，儘可能的能夠把這些年積累的經驗都數字化了，能夠留下來，這樣也就沒有遺憾了。