那三年，我作DBA的心酸事兒

文章經受權轉自簡書做者：董澤潤

1、前言

2012年初入職趕集，當時處在流量訊猛增加的階段，3年 DBA 生涯收穫坡多，其實坑更多(淚… ) 後來在作開發時，慢慢體會到 」運維「 和 「開發」 確實存在溝通問題：知識不對稱

如何解決呢？先總結下這三年吧

2、DBA職責

市面上招聘 JD 一大堆，隨變找幾個，立刻能找出共性

• 數據庫系統的規劃、設計、管理、遷移

• 數據庫的平常維護、備份、優化及恢復

• Master-Slave架構搭建、維護

• 業務系統上線支持，數據庫設計評審，提供架構方案

數據庫不侷限於 MySQL、Oracle，若是分的不細，還會有 Redis、 MongoDB 等一系列 NoSQL。

工做內容都同樣，首先是高可用穩定性，不能今天抖動明天宕機，涉及工做不少。

第二個是數據安全，好比備份及恢復，14年趕集審計，移動端的活躍用戶數就是從備份中恢復來的，可見備份的有效性是重中之重。

最後一個固然是爲業務服務，對接業務需求，不能因我的生活被打斷就罷工，有一次剛看電影就被叫回去處理 DB 報警，罵孃的心都有了。

3、悲慘案例

先舉一些悲慘案例，讓看官們高興一下~ 因爲公司早就不在了，這裏沒有顧忌。

1. delete 刪全表

二手車同窗的鍋，SQL 拼錯不帶 where 條件，編寫線下腳本時出錯… 最後DBA根據 row binlog 恢復。（至少2次）

反思：rd 新手一茬又一茬，規範講再多也沒用。最完全的解決方式只有一個，接入 proxy, 限制一切非法 sql。另外 rd 上線驗證也不到位，代碼 review 確定有缺失。

2. 大賣家問題

房產在14年開通免費端口，短短几個月時間房產商業表爆漲到 100G，個別中介賬號發貼超過10W，致使數據庫異常抖動，威哥臨時清理過多發貼記錄解決。最後耗時三個月對這張表進行瘦身，拆分 text 字段。

反思：DBA 對大表監控不足

3. 大量子查詢打跨主庫

主站主庫有一次被子查詢打跨，過後排查，因爲 RD 大量子查詢致使。此類問題不是個案，有不少 RD 把本本該讀 slave 的請求寫到 master 上，只不過沒有引發事故而已

反思：趕集 DB 典型 1 主 N 從，沒有 proxy 保護的懷況下，常常出現此類問題，只靠規範制度基本解決不了。

4. 報表 olap 庫問題

RP 庫我和文武背鍋，年末的績效墊底。文武接手前的 RD 一我的開發中介商家報表系統，全部計算都是基於 DB，當免費端口開放後數據量爆漲，MyISAM 讀寫鎖致使大量請求阻塞，據說公司由於報表連續問題賠商家300W。

反思：這個事故得站在高處去看，免費端口開放太忽然，項目技術負責人考濾不全。報表系統沒有通過設計，徹底由一個新人 RD 去搞，也就大學畢生水平，回頭再看，hadoop spark 徹底搞定。最後 DBA 沒有及時對大表進行跟蹤，沒有提早發現。

5. 50G的Redis

房產業務 Redis 眼看從 20G 爆漲到 50G，我離開後也一直沒優化掉。據說，後來某次故障，數據清空了？

4、個人工做

大部份時間和開發溝通感情聊人生，後來 automan 上線不多有人找我了~ 每一個階段都有成長，都有感謝的人和事，趕集讓我有平臺去作感興趣的事，很開心。

剛到趕集時，SQL 上線還走的 jira，半自動化由運維開發同窗作的，常常在技術大羣裏被艾特，很簡單的建表或是 DML 都要由 DBA 人工介入，很煩索。

另外不少建表語句不規範，打回讓 RD 修改，他們對此頗有意見，認爲無所謂的修改，這就在 RD 和 DBA 之間產生了溝通成本，詩展在的時候還會按期作數據庫開發培訓，而後就沒有而後了。

14年中着手 automan 平臺開發，從前臺頁面到後端消息隊列，到 sql parser 解析，從無到有，在劉軍先河同窗的幫助下最終上線完成。由平臺去審覈開發的 SQL，通過 sim 模擬環境，再到線上自動執行備份，比人工高效的多。

這個系統原理和市面上其它工具差很少，仍有很大改進的地方。後來在數據庫大會分享了一次，坐臥不安沒有被噴。

5、DBA心得

• 夯實基礎：DB 的基礎天然是穩定，穩定，再穩定。實例數一多，基本天天都會遇到各類故障。主掛了就用 MHA 切換(最新的有 gtid)，slave 掛掉就由 lvs 自動摘掉讀流量。還有一個就是備份，全量增量，按期備份有效性檢測，每一塊都須要人力的投入。

• 硬件優先：DB 擴容有 scale up 和 scale out 兩種，通常優先堆硬件。buffer 不夠加內存，128G 不夠就 192G，磁盤陣列卡性能不行就上 SSD，再不行就上 flash 板卡。總之優先考濾硬件，爭取架構優化的時間。

• 未雨綢繆：慢 SQL 優化，按期出報表讓 RD 調優，通常出問題都是索引沒加，99%的大 SQL 都是這樣，少部份由於表設計不合理(沒有自增主鍵，或是頻煩修改)。大表監控，該瘦身的瘦身，字段該拆的拆，橫豎兩刀，過時數據按期歸檔，基本上就這些事。

• 結合業務：有些優化 DBA 累的半死，不如 RD 修改一行代碼。DBA 也要多和業務接觸，瞭解業務實現，不求給業務貢獻多少，不背鍋就好… 開玩笑。瞭解業務，就能站在更高的角度去思考，頗有意義。

• 學會拒絕：這個拒毫不是罷工不幹活，而是要分清哪些需求的合理性與緊急性，不合理也不緊急的直接幹掉，緊急但不合理的能夠臨時經過，快速解決問題，過後再確掉也能夠。好比 olap 跑在了線上庫，count(*) 計數 SQL 徹底能夠異步走計數器，Redis 是好東西。

• 學會溝通：工做也有些年頭了，這一點仍然在學習，也犯過很多錯。溝通好權責，定下時間表。

• 踏實學習：回頭看當年 DBA 作的不夠好，有些緣由在於沒有開發能力，不少想法止步於此。運維人員必定要有開發功力，而且要比業務 RD 更精，才能作好運維。

6、運維與RD的矛與盾

KPI 不一樣，關注點天然也不一樣，一線的同窗經驗也都有欠缺，特別是剛工做1~2年的，形成了信息與知識的不對稱。解決這個問題也不難：

• 新人要有導師帶，對新人放手無論最不負責。這方面感受 nice 作的不錯。該誇仍是要誇的。

• 支撐團隊要有足夠的 wiki 業務文檔說明。

• 自動化用技術來約束，而不是人工。同比業務接口強約束，如今服務化都用 thrift 了。