數據庫上云就可以 解雇 DBA ，來說說數據庫上云那些 “有意思” 的事情

　　隨著問問題的同學越來越多，公眾號內部私信回答問題已經很困難了，所以建立了一個群，關于各種數據庫的問題都可以，目前主要是

　　POSTGRESQL, MYSQL ,MONGODB ,POLARDB ,REDIS 等，期待你的加入，另外針對云的問題，我們可以多多交流互相學習，加群請添加微信liuaustin3.

　　————————————————————————

　　正文

　　之前和某個同仁探討問題，得知某金融類的大型xx,在轉型上云，并且在上云后，第一件事情就是解雇了幾個DBA ，美其名曰，體現上云后的成本節約。

　　聽完是又好笑又好X，那本期就來說說，數據庫上云后會遇到的那些事情，讓那些成本節約的 BIG POTATO 了解一下他們節約成本之后，可能會發生的一些有意思的事情。

　　(寫在前面，任何方式方法都有他的利弊，在說有意思的事情的同時，我們也應該思考，云，云數據庫給我們帶來的變革，以及我們怎么更專業的擁抱云數據庫，更加有效的使用云數據庫，提高自我水平，才是更主要，一味的指著并不能提高自己。)

　　1 硬件配置讓你下降頭

　　說到這個問題，那我們是非常有發言權的，你在裸金屬上的數據庫做的所有的優化基于數據庫參數的和性能的優化，在你數據庫上云后，統統的打回原形，為什么，因為你的硬件變化了，明明之前你的裸金屬 4C 16 G SSD 能完成的任務，到了云上哪就不大好說了，可能你的進行測試，測試，在測試，基于我們的經驗，一個系統上云后，一般都會性能低于裸金屬，當然這是很正常的事情，從CPU 內存 磁盤緊密的通過物理的電路方式連接， 而到了云上，通過網絡的方式來進行連接，那么延遲是必然的，所以云數據庫最高的要求，或者目前云廠商一直在想達到的性能，就是和你本地機一樣的性能，這也是云廠商本身硬件架構調整后，在成本，服務，和性能三者間的博弈。

　　基于以上問題提高配置來讓你的數據庫在云上運行，一般是必然的，不是偶然的。

　　2 各種消費陷阱 割韭菜和服務 “嘍“

　　現在各個云的價格都偏低，（實際上也不低），而怎么去挖掘潛在的money 拿方法是一套一套的。

　?。▽懺谇懊?，實際上我個人也認為某些收費的項目是合理的因為使用者層次不同，有些功能可能就是開放了，對有些使用者也不是很優化，集中整合然后售賣，提供雙贏的方式也是好事）

　　方法1 ， 屏蔽+消費

　　一般來說開源數據庫中的一些功能尤其是監控的系統表，都是DB獲得數據庫核心信息的窗口，那么上云后，如果你還通過窗口來獲得數據，那么必然是一件不怎么美好的事情，所以云廠商會通過手段，將你的一些“窗口” 關掉，禁止掉，設置各種障礙來讓你變成瞎子， 然后讓你通過他們的某些 洞察的功能，在撤去你眼前的障礙物。我們與這個問題，PK 了很長之間，一個一個數據庫PK ，有些云的數據庫的負責人比較 “良心”，默認持續優化，并且將功能做的越來越完善，好的咱們的說說，就是某云的 PG 數據庫，做的是越來越好，功能是越來越多，讓用戶少花錢，多辦事，尤其一些 如index_advisor 的功能引入，和 EDB 的功能看齊，PG 的小伙伴都應該知道我在說什么。

　　但是還是這個云的 the world of popular database 可就沒有這么美好了，能關的參數，那是一個勁的關，設置了重重障礙，讓performance_schema 成為一個 “失蹤者”。我們費了九牛二虎之力，才打開了一些參數，但后面又玩消失，要不“洞察” 功能賣誰去。同時客服也是有意思，只要問問題，問的深入一點就給你推薦 洞察功能。

　　方法 2， 不懂技術，就割

　　一般來說，上云的數據庫的甲方，很少有DBA ，有也都讓云給忽悠“走了”，然后人家云就可以“動手” 割肉了，配置參數按照“最優” 的配置給你，曾經有一個 MYSQL 業內的人士，在10年前講了一個笑話，某云，MYSQL 開了32G 的內存，但innodb_buffer_pool 的參數一直是 128MB， 并且那個公司的IT 也沒有DBA, 數據庫系統經常是瓶頸，問云就是內存不足，在擴充內存，最后擴充到 64G ，然后 innodb_buffer_pool 還是128MB, 最后公司老板扛不住了，請了那個 大仙去看，最后把問題解決了，大仙留下一句話， 沒有專業的技術人員盯著你的數據庫， 云廠商不 “割死”你那就沒有什么天理了。

　　提高技術壁壘也是相對說，如果你單位有懂行的，能和云廠商相較長短，那么你可能會少吃虧， 知識就是力量，不尊重知識的老板被割肉，這就叫大梨?賺財迷！

　　方法 3 ，老湯 裝新瓶

　　這個是常見的功能，因為上云的企業，要節省成本，可能初期都砍的價格比較狠，而后期如果還是老功能，老東西，怎么讓客戶掏錢，所以將一些原本可以提供的復雜功能，組合，“創新”，打包，讓你買單，尤其一些云提出的 智能化，AI ， 管理，使用了就可以 裁人了，這樣的想法深入某些老板的內心，但造成的問題是

　　1 讓管理數據庫的人員變傻，或層次變低，因為圖形界面使用慣了，信息在不提供，那么你只能在他的界面里面 ，鼠標點擊，出了問題，你就看人家的監控，人家的監控，有沒有問題不是人家說了算。

　　2 既然你已經變得不重要，那么公司也就覺得，DB被 AI 替代不是很正常的嗎，你的工作就被 AI 管理替代了，公司覺得省錢了，但該出問題還的出問題，因為每個單位的數據庫問題就是一堆，“多維空間的組合”，云廠商知道你開發的問題嗎，了解你業務的問題嗎，出問題是早晚的事情。（累計效應），AI 在給你分析出一堆 可以花錢解決的問題，讓你掏錢，掏的 那叫一個舒坦。

　　方法 4 能拖就拖，你投訴，態度好

　　這個問題，可以去一些大型云看看他們的服務的方式和人員是怎樣的就知道了，我們一個MYSQL 的問題，重啟了服務器 25分鐘起不來，我們實際上是在一個工單里面提出參數的問題，并且可能是參數引起的數據庫起不來，我們就在工單追加了，服務器起不來，你信嗎，他讓我在開一個工單。

　　我服務器起不來了，業務終止了，然后讓我在開一個工單，我也是醉了，給我的原因是，怕亂了。OMG ，首先這樣的服務其實就不大專業，一般的服務流程是，第三方外包的服務人員來分單，然后來和你攪和，問東答西， 貼文字，貼鏈接，貼貼貼 ，然后你要不著急能和你攪和一天，你要是投訴了，馬上就升級，加速，實際上也沒加速多少，不過道歉倒是馬上到位，可道歉有用嗎，我業務完蛋了，我還的給我的客戶道歉去，哎。

　　所以真應該讓那些解雇DBA 的領導 和這些客服來幾次深層次的溝通，不把你氣個半身不遂，那老板的身體是真好。

　　方法 5 技術問題避重就輕

　　這個問題也是時長發生，系統出了問題只要你不懂，客服他就敢胡謅，胡解釋，你問 特斯拉剎車的問題， 他回你 馬斯克今天解雇了推特的員工，只要你沒有懂行的技術人員，那么必然你得不到真正的答案，和實際的問題解決。問急了，就是，這是內部 XX 不便于告知。哎，我幾百上千萬買你的服務，我對你的系統有質疑，你告訴我，云沒有問題，問怎么證明，在告訴你內部保密 不便于告訴你。

　　這就讓我想起，羅永浩和某XX 的世紀對決了， 羅永浩問，我說你有 6個私生子，你生活不檢點，然后你問，誰說的， 我告訴你我知道誰，但我保密，這不就是赤裸裸的耍流氓嗎？ 但你有招嗎，沒有，技術都讓你解雇了，到最后就 割 割 割 ，割韭菜。

　　綜上所述，奉勸那些要節省成本的老板們，成本節省一時爽，人家割你韭菜一世牛，明里聰明，實則SM！

　　后續：和云打交道時間還是短，我們會總結經驗，后續可能會出一篇，八卦連環推云掌 24式 ，和小伙伴們分享，鍛煉身體，增強筋骨。