最近整體的風向都朝著不好的方向在走，或許到底了就好了，根據一些專家和經濟學家判斷，我們還能壞到哪里去。當然今天說的不是經濟，而是DBA到底應不應該當背鍋俠，或者誰是DBA當背鍋俠的幕后黑手。
最近有幾個朋友和我私下訴說工作的一些不順心，大部分可以總結出幾點：
1 工作中的數據庫使用的太單一，導致技術能力提升慢，尤其金融領域中部分抑郁的DBA2 工作中遇到口諭就是圣旨的領導，工作根本沒法開展，天天郁悶之極的DBA3 工作中因為整體的項目架構設計有重大的問題，最終由數據庫DBA買單的正在掉頭發的DBA
4 工作流程有問題，導致DBA的工作過程不暢，導致的各種溝通成本太高的問題，導致DBA有苦說不出，苦瓜臉DBA
最終總結出來一句話，不懂裝懂的人，害死個人呀下面我們就用傳統相聲八扇屏來說說， 想當初
我說說你聽聽，在想當初 ！話說在一個大型項目初始的時候，有一群“專家” ，架構師，高級開發，項目經理等一大堆。1 外鍵，必須有外鍵，否則如何通過程序來標定，表和表之間的關系，約束數據，保證兩個表之間數據的關系2 必須大量使用存儲過程，通過存儲過程來削減，程序和數據庫之間的交互，提高整體應用的系統的效率3 項目必須使用三范式，嚴格要求表中不會有重復的字段，通過嚴格遵守三范式保證數據庫表設計的正確性4 DBA負責數據庫的，運行維護的穩定性，正確性，出現數據庫問題，都是DBA 的責任
這個大項目的一些海內外專家，項目管理專家一致的意見下，項目轟隆隆的開工了。此間DBA小嘍啰們，提出了各種建議，如這個項目并發高，要不要使用物理分庫的方式，同時基于數據經常頻繁更改，項目里面也沒有設計redis等緩存式數據庫，全部用傳統的單體數據庫來進行支撐，后期可能會陷入垂直硬件升級的陷阱，同時存儲過程將限制整體項目的擴展性和靈活性，以及項目在高并發 ，高訪問量下使用存儲過程的不可控的問題，可能會導致性能瓶頸出現在數據庫層面，導致整體系統CRASH的可能性增加的問題。當然在基于整體項目由海龜博士作為系統架構師總負責項目和有著多年大型國有項目管理經驗的項目管理專家的把持下，DBA的言語，輕如鴻毛，在大師的眼里，DBA就是一個打雜的小蝦米。項目啟動后，進展順利，此時只有DBA在項目里面天天擔心，杞人憂天。最終項目上線順利，架構師，項目管理，開發小哥哥，都得到大大的贊賞，并和領導表示，我們設計的系統萬無一失，后面就看運維和DBA的工作情況了，希望這些人，能好好守護好，24K純金打造的偉岸系統。系統上線前，DBA就之初一些問題，如這個系統日志系統使用了BLOB數據類型，并且每天產生的系統日志都存在業務數據庫里面，傳統數據庫作為唯一的項目的數據庫，為什么就不能與時俱進，用mongodb來進行存儲和解耦， 得到的答復是，你在教我做事咯 ！同時在系統運行一段時間，經常有因為前端數據控制輸入不規范，導致頻繁數據庫對于數據進行，主鍵沖突，鍵值沖突，唯一索引沖突，check值沖突，以及主外鍵約束級聯等方面的工作，導致數據庫只要并發一大，就出現性能問題，而架構師和項目管理者，不以為然，提出這就是硬件的問題，提高硬件內存到2個T ，CPU加到200核的，問題就解決了，這不是系統設計的問題，這是我們業務訪問量大的問題，仔細一問，每天并發訪問不足50。最后，沒有辦法，領導只能責問DBA ，你們怎么干的活，人家架構，開發和項目經理都投訴你們1 OXXX數據庫沒有維護好，為什么每天業務數據量才1G ，日志就100G，讓系統運行的性能都耗費在日志的插入上，你們要優化，你們必須整改
2 項目工作中，表設計索引為什么不早添加，當然SQL語句沒有給你們，表設計邏輯說明文檔也沒有給你們，你們怎么就這么沒有主動性嗎，非要人家都給你這些你們才能干活 ，不會猜嗎 ？3 系統備份要恢復幾條數據，讓你們用全備50多個T的備份恢復，找這幾條日志數據，有那么難嗎，為什么推脫，雖然項目我們都花在了研發上，硬件是差了點，磁盤是不夠，但是你們不能拿出主人翁的精神？不要和我說，巧婦難為無米之炊，你們是DBA不是巧婦，天天給我在這里打嘴仗，不會恢復一點，看看有沒有，刪除在恢復一點，在看看嗎 ？有那么難嗎？你們要學會溝通，學會檢討，學會反思，提高服務意識，提高技術水平，我作為這個項目的領導對你們很不滿意
