在“即服務”世界中,DBA的角色發生了什么變化?
過去的十年中企業對于管理和運行數據庫的需求發生了巨大的變化,這樣進而影響到了負責運行企業數據庫的數據庫管理員(DBA)工作重心的轉移,相比于保證可訪問性和可用性,現在DBA更側重于開發滿足業務需求和目標的架構、設計和可擴展性策略。
為什么會DBA工作重心會發生這樣的變化呢?大部分是始于互聯網公司以及新的收入模式的誕生。互聯網公司要求網站可靠性工程師(SRE)和DBA不僅要保證主要收入引擎(通常指應用程序和網頁)的穩定,而且還要保證業務的隨時擴展。這遠遠超出了DBA之前的職責,之前DBA只需保證數據庫的正常運行、備份,當問題發生時及時作出反應。
新的收入模式,新的挑戰
如今,企業在互聯網上開展業務變得越來越普遍,如果想要保持自身的競爭力,那么一定要找到跟得上技術和架構變化的新部署模式,例如云和“即服務”等等。軟件、數據庫、平臺甚至是基礎設施都可以通過基于云的模型轉變成為“即服務”。
基于云的數據庫和基于DBaaS的數據庫環境的管理也隨著這一轉變而發生了變化。例如,在SaaS領域,應用程序中斷就意味著收入損失。除了直接收入的損失(以及解決危機的費用),服務和應用程序的癱瘓還意味著客戶流失。為了避免這種損失,公司關鍵SaaS數據庫基礎架構的每個部分都需要進行規劃,包括內置冗余和面向未來的架構以及如何擴展來適應未來的增長。
增長就意味著擴大服務或進入新市場,這往往會需要新的業務關鍵型應用程序。在如今“即服務”的大環境中,有很多方法開發部署,例如在本地或云端、作為服務或組合,容器還是虛擬環境等等。
最成功的滿足客戶需求的方式應該是滿足企業業務目標。企業都希望應用程序和網頁能夠快速無縫的工作。而想要做到這種即時性,企業必須能夠敏捷快速部署新服務和應用程序,以滿足新功能的需求或把握未開發市場中的新機會。
企業數據庫需求正在不斷發展
在部署服務、應用程序或網站時,一定要把擴展計劃在其中。影響數據的***件事就是數據庫工作負載的變化,引起這種變化的原因可能是存儲和訪問數據的變化,也可能是流量的變化。
數據庫環境的靈活性也很重要。如果業務增長需要橫向擴展,那么需要增加多少硬件呢?如果是在云中,增加使用量會產生哪些成本?
以電子商務網站為例,有許多應用程序協同工作來收集電商數據:購物車內容、已完成的訂單、庫存信息和重新進貨訂單等。如果要是把所有信息存儲在單個數據庫中,可能需要額外的工作和開銷才能將數據轉換為特定應用程序的可用格式。但如果你選擇把信息存儲在合適該數據類型的數據庫中,這時數據庫要是處理它未設計的工作負載時就會降低性能或者導致其它問題。
在產品或服務推出之前,你考慮的問題越全面,那么未來發生災難的可能性就越小,所以應用程序開發還需要DBA和數據庫工程師構建一個輕松擴展且延遲幾近于零的數據庫。如果企業選擇把數據庫遷移上云,那么云運營商會自動化接管大部分運維。
這時還需要DBA嗎?答案當然是肯定的,因為不斷變化的數據庫環境并沒有消除對數據庫專業知識的需求,DBA的工作重心更向應用程序的設計和開發傾斜,不僅要設計和調整數據庫來支持應用程序,而且還要了解云中可用的模塊化部件。通過DBA高效的數據庫專業知識能為企業帶來更高和更清晰的ROI。
DBA到底需要做些什么?
隨著數據庫格局的發展,DBA的價值漸漸從修復解決方案轉移到規劃解決方案和制定解決方案戰略,數據庫如何為公司的整體業務目標做出貢獻以及有哪些解決方案可幫助實現這些目標。
借助于云和容器化這些新技術,DBA可以不斷監控或評估應用程序使用數據庫的情況,并對如何提升性能以及在不影響性能的情況下整合新功能、新需求。
隨著越來越多的公司根據不同的應用程序和場景來選擇不同的數據庫,DBA也需要不斷的學習***的數據庫技術。
事實上以上這些轉變并不是紙上談兵,我們Percona都經歷過。現在Percona中超過50%的客戶委托都是與應用程序設計問題、查詢性能或數據庫基礎結構設計有關。而在5年前,圍繞這些問題的幫助僅占不到20%。
在數據庫選型時,一定要考慮MySQL,MongoDB,MariaDB和PostgreSQL等開源數據庫的成熟度以及其未來發展的相關技術。如果再加上自行研發的自動化或基于云基礎架構的技術,這樣就可以降低核心數據庫軟件崩潰錯誤的可能性。如今發生系統中斷的大部分原因就是設計決策失誤、錯誤代碼以及在初始規劃中未考慮極端情況。
總而言之,DBA的角色正在從之前的簡單“運維數據庫”轉變成更具戰略性的地位:DBA是幫助企業實現其戰略業務目標的專家之一。