DBA不僅僅是管理資料庫--也要管理好需求

看到這個標題可能覺得我在亂說，其實只管資料庫其實管不好的，樹欲靜而風不止。

 

有很多時候我被問能不能保證資料庫穩定？這真不好說。我說如果能按照開發規範（我制定過一個資料庫設計開發規範）做是可以的。請注意我這個不是說資料庫開發規範。資料庫開發規範是告訴開發人員如何寫SQL的。而我的這個規範還有設計規範。先設計再開發。我多年經驗告訴我，在設計一塌糊塗的前提下，最佳化顯得蒼白無力。

 

這種情況下SQL改寫可以做一些，但是收效有限。只能期盼類似Exadata這種大殺器來解決問題了。只是我比較窮買不起這種。只能看別人羨慕。多年前聽我老師說用上這個就是“咖啡運維”。我問什麼是“咖啡運維”？答：喝著咖啡就（行了）運維了。言下之意是基本不用你管。後來我瞭解過得出結論。一般的企業除非遇到事務完成就是不提交這種以外，基本他都不用DBA或者運維人員操什麼心。基本（我說的是差不多沒說100%不要揪著這個不放）做到了“咖啡運維”。

 

那麼那種事務完成不提交怎麼辦？基本都是設計或者業務上有問題導致的。所以回到今天主題就是這種必須管啊。否則就是什麼硬體和架構都解決不了。其實我後來想過一個問題。如果應用程式update一張表，沒帶where條件怎麼辦？必然就出事了。而且是立竿見影的就馬上保障。不同的資料庫有不同的處理方式，不少資料庫都有自己的解決方案。這裡可能類似Oracle閃回這種對業務影響最小。但是應該也是多少會影響到。

 

這種只能保證說影響程度最小，解決最快。但是不能保證不出問題。還是那句話什麼架構和硬體都無法避免這種問題。不少領導希望由架構或者運維兜底保證。實際上這種根本兜不住。

 

曾經有一個笑話擺在我面前。（我把這個笑話加工以及擴充套件了一下）。古代一支部隊駐紮在村莊附近。將軍嚴格規定士兵不許拿老百姓東西，比如說偷雞。這對我們現在的人民子弟兵來說這是基本要求，三大紀律八項注意中有不拿群眾一針一線。但是以前的部隊未必能做得到。儘管將軍還是說了不允許偷雞。但是還是有士兵去偷雞了。估計讀到這裡的朋友大部分都應該說是士兵問題吧。但是可能會有人說，你怎麼把扎個籬笆防止士兵去偷雞？對，馬上扎籬笆。但是偷雞的情況還是有。籬笆都紮了呀。有人會說，這個籬笆不夠高，如果足夠高他就翻不出去了。故事到這裡差不多結束了。我想說就是如果砌的牆比紫禁城還高，但是就是有人就是要去偷雞，他可以挖地道。

 

將軍可以理解為DBA等維持規範的人。而士兵指的是不靠譜的業務或者按照這種不靠譜的業務照單全收的開發人員。

 

所以我覺得正確的做法要麼是有懲罰，而且夠重。比如有人酒駕了，入獄半年。現在酒駕的人少多了，但是依然有。你看這樣都不能杜絕。

 

還有一種做法就是從源頭管理起來。比如不是什麼人都能提需求，那種不靠譜或者不著調的人提的不靠譜、不著調的需求就要扼殺在搖籃裡。比如笛卡爾積或者任性的全表查詢。這些都是規矩。

 

你去理髮時候，理髮師說請坐正。你不能說，爺我就找站著或者說姑奶奶我就要躺著。如果業務就是這麼任性，那麼代價就是用各種技術投入。增加儲存計算資源用最好的軟硬體。比如曾經有個使用者結算很長時間，最後換了Exadata，快了10幾倍。這裡我不確定這個使用者是不是合理。但是軟硬體提升的情況下，業務和SQL什麼都不改，問題就解決了。所以有錢有有錢的做法，有些都惹不起的情況下，就用錢來解決吧。話說回來，協調各方解決的代價估計比買Exadata的成本要高。因為在toB業務場景中，你和業務講技術講道理。業務教你怎麼做人。