本文根據白鱔老師在〖2016 DAMS中國資料資產管理峰會〗現場演講內容整理而成。

大家好，今天想跟大家談談關於DBA怎麼去考慮哲學化的問題。前段時間和朋友聚在一起時也說到，十多年前的很多DBA現在都不再幹這行了，很多後面都變成哲學家了。為什麼這麼說呢？因為很多DBA後面都轉去做架構師了。

其實在十幾年前，曾有人用這樣一句話來形容DBA：“你們DBA做優化就是盲人摸象”，當時我覺得這句話很不舒服，因為作為一個DBA來說，我認為這個職位在系統優化中間的價值是很大的。但隨著這些年我更多地接觸到一些架構的問題，慢慢從架構方面去考慮問題時，我發現，盲人摸象這種說法確實不為過。懷著這樣一些想法，今天跟大家分享《運維中的哲學問題》。

首先，我想說的是——不想做哲學家的DBA不是好架構師！這也相當於前面我所提到的，為什麼做DBA做到最後會變成哲學家呢？

就拿考慮系統的問題來說，可能剛剛入行的人，他會就著某一個東西去考慮，比如說，DBA的話可以就著資料庫去著手。但隨著我們的接觸面越來越廣，處理的問題越來越複雜時，我們就可能慢慢會從系統本身去考慮，這種情況下，有時候我們認為很多理所當然、正確的東西進入哲學範圍後會發現它不對，或者不一定對，甚至是完全錯誤的。

包括像我，大概在十年前寫的《Oracle RAC日記》這本書，前段時間我又重新把這本書翻了一下，發現裡面很多的案例和關聯都是錯的，甚至有些案例當時的處理模式、方法是不對的。但真的不對嗎？其實不一定。因為在當時它確實解決了問題，而且很多解決方法現在大家也在學。但是呢，如果轉而從架構的角度去考慮，有可能當時我們的處理模式不是最好的，並沒有把根本的問題解決掉。就像我們得了感冒，醫生給你掛一針水，馬上好了，但是如果說這個人總是感冒，總是隔三差五地去掛水，這肯定不好，必須要找到感冒的根源：是體質的問題還是其他什麼問題，偏寒還是偏熱，要用中醫的療法。

以前我們在內部也經常開玩笑，說當某個人考慮問題已經考慮得比較玄了，那他就已步入哲學家的行列了。如果你現在也開始學會辯證地看待問題，那麼恭喜你，你已提升了一個檔次，併成功晉級了。由此看來，不管作為DBA也好，還是運維人員也好，我們做系統運維，運維能力的提升都是分階段的。

我初步地把它總結為四個階段。

第一個階段為精益化，即我們把一件事情做到更好，這也是一個專業化的問題，爭取在這個領域把事情做到最牛逼。

但是，光有精益化是不夠的，還需要把它標準化。比如說，以前我們給使用者做巡檢（這是DBA接的最多的活），不同的人去做巡檢，效果是不一樣的，因為不一樣水平的人，能夠發現的問題不盡相同。後來我也一直在考慮，硬體、小機、儲存這些環節的巡檢都已經標準化了， 甚至可以用軟體來實現。但是資料庫的巡檢能不能標準化呢？

從這件事情我們可以窺見到標準化的重要性。

一旦能夠標準化了，下一步我們就可以考慮自動化了。現在，我們很多企業都在談做運維自動化，但如果你企業運維的各種工具、知識體系都不標準化，你怎麼做自動化？這種情況下做出來的自動化也是虛的。在這個過程中，企業採集了大量指標，做了大量的監控告警，但每天幾百上千個告警跳出來，根本解決不完。這種不是在做自動化，而是給我們的運維人員添亂、添堵。所以說，我們想做自動化之前，一定要考慮運維標準化，當我們能把運維的一系列工作包括採集、分析、監控、操作等全部標準化，自動化的問題也會迎刃而解。

自動化完了下一步還需要做視覺化，為什麼呢？這是做完自動化以後必須做的一個環節，它既可以把採集到的大量資料通過用一種視覺化的方式表現出來，也可以很好地把一些指標向運維人員展示，可以一定程度解放運維人員，降低運維的成本。但是在做視覺化的過程中，我們不能再走以前的老路。

以前我們用到的運維自動化工具，都是一些商業軟體，並且這些商業軟體通常是基於網管式的去做，這些網管軟體面面俱到，什麼都能幹，能夠採集大量的資訊，但是它不夠專業。我舉個例子，比如說現在我對一個系統，這個系統裡面有12個網路裝置，20來個伺服器，不同的人看這些東西，他的關注點是不一樣的，但是專業的網管軟體只能採集一套資料。因此這裡面就涉及到在引入視覺化的時候，不單單要把資料展示出來，還要做到場景化的運維。對於哪怕同一個拓撲圖，網管人員、安全人員和業務人員會根據自身關注的指標體系，看到不一樣的東西，即不同的人關注不同的場景。

最後，當我們把前面所有步驟都完成了，後續就可以做智慧化了，也就是引入大資料分析。通過大資料分析，我們能夠發現以前很多關注不到的問題，一些以前我們知識能力達不到的分析層面。就像前段時間的阿爾法狗，有很多我們不知道的定式它也能走，阿爾法狗的出現可能會對未來下圍棋的定式產生很大的影響。同時，自動化的分析對我們的IT經驗、運維經驗來說也是很好的補充。

那麼，作為運維來說，運維裡面的重點是什麼？其實很樸素，我把它總結了幾點：

1. 以服務目錄為工作核心

   什麼叫服務目錄？很多企業可能連服務目錄都不存在，一個IT部門要幹什麼活，是圍繞著服務目錄去展開的。哪些最重要，哪些不重要。如果你說任何業務我認為都是最重要的，這確實，但不現實。

2. 以服務級別協議為服務依據

   區別好哪個系統是四個九，哪個系統是五個九。一定要跟業務簽訂服務級別協議。

3. 以保障業務為工作目標

   不能為了運維而去運維，甚至通過運維去催發出一些新的事，這是不可取的。

4. 以標準化工藝為指導

   標準化工藝是相當重要的。以前我們也經常會碰到，同樣一套系統，有多個伺服器，裡面配置的引數都不一樣，這些都是不規範的做法。

5. 以執行基線為判斷依據

   隨著運維的規模越來越大，場景越來越複雜，我們一定要用一些自動化工具作為輔助手段，光靠人力是愈來愈難滿足企業的需求。另外，在進行分析的時候，系統到底健不健康、存不存在問題，要以執行基線作為依據。

6. 以事件跟蹤為工作方法

   當出現問題時，通過疑點跟蹤，發現有價值的問題。

7. 以閉環管理為考核策略

   任何一個疑點，都必須閉環，這也可以作為管理的一個目標。

不同階段的運維人員，分析方法、思路是不一樣的。

首先，剛入行的，往往會根據現象去分析問題，可是如果碰到一些“超自然”現象就束手無策了。其實不存在詭異的“超自然”現象，任何現象都是有根源的，只是能力認知範圍上的不足。

隨著能力的提升，我們可以通過抓到系統運營的一些指標、基線去分析問題。但是，光是有指標和基線也仍然不夠，假設我們判斷一個系統是不是已經達到它的負載極限，是需要根據系統容量來判斷的，比如說這個儲存能提供多大的IOPS，超過多少額度顏色會上升，運維人對於這些容量指標體系必須有所瞭解。

另外，如果再往架構師方向發展，就會從整體角度來思考，辯證地看待問題。達到這一地步的話，我們可戲稱這人“成精”啦，因為他已經超脫了普通的一種運維範疇。

舉幾個比較典型的點：

1. 沒有絕對的對錯。以前DBA圈特別在意對和錯的問題，這是不對的，有些網站上就常常有人為了某個處理方法天天打架。但是隨著個人能力的提升，對錯這個觀念可能就越來越淡。
2. 過猶不及。我們總是希望把事情做到最好，講究“工匠精神”，但實際來說，有時候過了還不如不過。
3. 與過猶不及類似的，最佳方案也許是最壞的。在前些年阿里的Oracle資料庫架構中就有個遠端維度的問題，當時圈裡也做了很多的探討。就說這個維度會對我的運維帶來多大的負擔，有沒有必要。前段時間我剛好碰到這樣一個使用者，他也想用這個方案來實現他的效能高可用，但他的使用方法是存在問題的，因為他沒有掌握阿里當時使用這個時的精神，簡單地去操作這個方案，結果資料庫打不開。
4. 眼見不一定為實。即可能有更深層的東西，以前我們碰到的稱之為“靈異的問題”，也是因為這裡面有你目前能力所不及的、看不透的東西。
5. 能力越提升，對技能的依賴越小。學會通過綜合的方式去解決，而不是簡單靠技能來解決，有時有些東西可能會比技能更好。

下面進入本次分享的重點，運維中的哲學問題，到底包括哪些問題？

• 敢於保證沒問題是能力的體現。

就像客戶經常會問，這個東西到底有沒有問題，能不能100%地保證。這個其實很難保證，對運維人員來說，我想應該沒有人敢這麼講。敢於承認有問題也是對自身能力的一種認可。

• 不怕有問題

不怕有問題，這是一個更高的層面。即在系統架構上，哪怕出了問題，也可以頂起來。不怕有問題是對系統架構上的自信。

• 人力終有窮盡，架構可有效補充能力不足

對於運維人員來說，最怕的是什麼呢，莫過於總是想通過我的能力去確保系統不出問題。一個人再有能力，始終是有限的，而架構的保障正是彌補人力不足的一種最好手段，而且很多時候架構優化的投入成本並不大，在這種條件下，我們沒有理由去放棄架構而選擇人力。就算整個團隊24小時輪流值班，早晚也撐不住。

• 問題又來了，能力不行，架構也設計不好

最後又繞回來了，有些東西不是絕對的，能力當然重要，架構也很重要。

在這裡，我講一個跟這有關的問題。我們可能會經常出現誤操作，導致資料被刪、資料丟失，這說起來不是一件很Low的事情了。像前段時間Salesforce系統丟了5小時資料，就是因為操作人員的低階失誤，所以說誤操作是不可避免的，我們只能儘量採取一些措施來減少發生。

對於DBA來說，最好的防禦就是一方面提升自己的能力，養成良好習慣，通過工具防誤操作，另一方面在一些關鍵操作上，實行雙人稽核。

對於架構師來說，設計合理的架構則是最好的防禦。當資料誤操作時可以快速地恢復。

什麼情況下我們能做到0丟失？不同人有不同的答案。

領導可能會說，最好能做到不丟失資料。一些解決方案廠家，他們可能會說：用了我的系統、我的產品就能做到資料不丟失。那麼作為DBA，我們可能希望通過自己的技能或方案來做到0丟失，但是架構師考慮的角度就不一樣了，他首先考慮到我要做到資料0丟失，成本是什麼？我的系統需不需要做到0丟失？大家可能認為，對銀行來說很需要資料研究師，但我和很多商業銀行的IT主管交流時，他們認為丟一點資料沒關係，只要不錯就行了。

首先，我們必須明確運維自動化的目的是把運維人員從繁瑣的運維監控工作中解放出來，但實際上“運維自動化程度越高運維人員越忙”卻是現在的普遍認知。正如前面所說，自動化運維平臺能夠發現更多的事件，呈現更多的資料給運維人員，可這些問題是不是值得我們馬上去處理，這需要一些分析和篩選。

另外，我們在做基線分析的時候，如果定了一些不合理的基線指標，就會導致告警資料越來越多，上述狀況都會導致我們的運維人員越來越疲於奔命。比方說，我們定義CPU超過90%就會報警，但其實超過90%是不是就是一個必須解決的問題呢？不一定，需要根據各自的實際應用場景去分析。

所以在這一塊，我們的運維自動化平臺不只是簡單監控就行了，還需要大量運維經驗的人才。沒有運維經驗的自動化平臺就是個虛的東西，沒有任何價值。

創造力是企業競爭力提升的源泉，但是反過來，標準化是企業長期生存的依靠。光有創造力、天天有新點子，卻不能沉澱到企業裡面來，無法成為企業的血液，這個企業也沒辦法把自己的創造力轉化為生命力。

對於運維而言，創新和標準化是螺旋上升的關係，既要有創造力，又要標準化，這兩個相輔相成，不能脫節。

再者，我們在企業裡是一個團隊，創造力再強的人也必須遵循標準化的管理要求，反過來標準化不能束縛死了，阻礙運維創新。因此，從企業選擇運維人員的角度看，穩健型IT更需要標準化，創新型IT更需要創造力。

對DBA來說，一般發現問題可能會慣性地去找一些SQL的問題，通過SQL優化可以很快把難題解決掉。SQL優化的作用很明顯，但是反過來，我們也常常發現SQL優化會引起更深入的問題。

從運維的角度，我們再看回前面“DBA做優化是盲人摸象”這句話，會覺得不無道理。因此，我們在做優化的時候必須通盤考慮整個基礎架構，而不僅僅是一個面。

那麼，一個優化專案必須具備哪些成功要素？

在我看來，必須囊括紮實的客戶調研、深入全面的分析和對IT基礎架構的充分了解這三個要素。尤其是對整個架構的把握，如果你不了IT系統架構，你就只能從SQL層面去優化，永遠是治標不治本。

最後，我們總結一下本次分享：對運維來說，沒有絕對的最好，但不妨礙你去追求最好；沒有絕對的正確，但不妨礙你探索正確的道路。人才是智慧的源泉，再強的自動化運維平臺都需要高智商的運維人員。

講師介紹 白鱔

• 徐戟，網名白鱔，DBAplus社群聯合發起人。20多年應用開發、運維管理、系統優化、IT隊伍管理工作經驗。著有《Oracle RAC日記》、《Oracle DBA優化日記》等技術專著。
• 曾主持開發了國內首套電信級聯機實時計費系統、國內第一套三檢合一的檢驗檢疫綜合管理系統、國內第一套公路口岸快速通關係統以及銀行大前置平臺（IPP）。資訊無障礙研究會專職顧問，Oracle ACE。

文章出處：DBAplus社群