我的團隊做系統優化是從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歲，離退休已經時日無多了。我想在現在還能做點事情的時候，盡可能的能夠把這些年累積的經驗都數字化了，能夠留下來，這樣也就沒有遺憾了。
#以上是我為什麼要把退休前的這段時間都用在和維運知識自動化系統死磕上的詳細內容。更多資訊請關注PHP中文網其他相關文章！
