數據庫管理工作如何適應DevOps實踐

North：DBA這一角色通常會接觸多種產品環境、開發團隊、技術以及業務干系人。也許他們在上一分鐘還在進行數據庫調優，下一分鐘就要安裝某個安全補丁，以及對于生產環境中遇到的問題進行響應，或是回答開發者們的問題。他們需要確保備份與分發的正確配置，系統與用戶對于相應的數據庫（并且僅限于這些數據庫！）有著適當的訪問權限，并且還要實際參與異常的系統行為的診斷工作。

DBA的實際價值體現在對于數據庫本身、運行時特性與配置等機制和細節的理解上，并在編寫查詢功能的開發者與負責各種作業的運行的運維人員之間起到橋梁的作用。熟練的DBA能夠指出如何加快運行較慢的查詢的方法，包括改變查詢邏輯、調整數據庫schema、或是更改數據庫運行時的參數。例如改變連接的次序、引入索引（有些情況下還需要刪除某個索引！）、對數據庫的查詢執行計劃器給出提示、或是更新數據庫的啟發式特性，這些工作對于性能可能會帶來極大的影響。

North：這方面有一個不幸的事實，只有極少數的開發者能夠真正了解關系型數據庫背后的運行機制。Hibernate或微軟的Entity Framework這樣的框架提供了一種映射層，它向普通的企業開發者掩蓋了內部的運行機制，因為對于這些開發者來說最重要的技能在于C#或Java的編程，這種做法顯然是一把雙刃劍。一方面，這種映射層能夠在數據庫schema與對應的面向對象數據結構之間生成映射關系，從而簡化開發普通應用程序的過程。但如果你所期望的領域模型與數據庫schema之間產生了較大的分歧，或者是對于性能、可用性與可伸縮性有較高需求的情況下，這種方式很快就會讓應用變得復雜起來。在這種情況下，如果在開發團隊中能夠加入一位DBA以提供幫助，這種做法的價值是無可估量的。

從運維的角度來說，DBA通常需要負責實現業務上的分發或可用性的策略。監控系統、診斷問題及“保持系統始終正常運轉”等工作屬于運維人員的職責，但DBA也需要深入參與與數據庫相關的監控工作與問題診斷。他們還需要為運維團隊定義數據庫管理與維護的流程。

North：通常來說，DBA這一角色的工作主要來自于請求或工單系統，這形成了另一種技術壁壘。這種方式意味著DBA往往接觸不到宏觀的業務或技術方面的需求與限制的上下文，他們往往只能在信息的真空中盡力把工作做好。從我的經驗來來看，DBA經常會扮演一種隨時提供支持服務的角色，因此如果某個開發者的查詢超過了閥值，那么DBA很可能在半夜里被電話吵醒。也正因如此，DBA對于來自開發者的數據庫變更往往選擇謹慎的、甚至是非常質疑的態度。

有時候，DBA可能會分為“生產環境DBA”與“開發DBA”這兩種不同的角色。前者通常都坐在一起，進行我之前所描述的各種生產環境的維護工作。而后者將幫助開發團隊進行schema的設計與查詢，讓他們能夠以正確的方式與數據庫進行交互。這種方式可以帶來很好的效果，尤其是生產環境DBA與開發DBA之間已經建立了一種信任關系的前提下。生產環境DBA知道開發DBA會確保schema的設計與數據庫的查詢具有一定程度的質量與合理性，而開發DBA也相信生產環境DBA會以正確的方式對各種數據庫實例進行配置與維護。

North：在許多組織中，他們之間確實是無法適應的。無論是將數據庫變更通過一個獨立于應用代碼變更的額外流程進行發布，還是將數據庫與應用的變更統一發布至生產環境中，兩者都面臨著很多困難。

某些組織會采取“數據庫即代碼”的策略，通過某些自動化流程，利用變更腳本將變更部署至數據庫中。這些腳本與應用代碼一起在源代碼控制系統中進行管理，這可以簡化變更的追蹤與分析工作。這些變更腳本通常叫做遷移腳本，或者就直接叫做遷移，他們已經是最近于“數據庫即代碼”這種策略的形態了，但仍然包含大量不必要的復雜性。

North：對于DBA來說，最理想的模式是讓他們成為開發及運維團隊這個整體中的一分子。DevOps的目標是將敏捷開發中的各種技術優勢，例如持續集成、自動化以及版本控制整合到一個運維的上下文中，同時依舊保持讓系統持續運轉的各種嚴格的紀律。

我希望未來的數據庫變更能夠像代碼變更一樣簡單。我不希望手動編寫遷移腳本，或者不斷記錄有哪些腳本已經運行過了、哪些還沒有運行等等。我應當能夠選擇在某個開發數據庫上進行的任何變更，然后像代碼一樣進行“簽入”。我不需要在版本控制系統中手動進行差異比較操作，而是可以在軟件中直接操作，讓VCS來找出這些變更。

數據庫工具應當能夠指出自上個“版本”以來，數據庫一共產生了哪些變化，并生成相應的遷移腳本。像Red Gate等幾家軟件商在這方面已經取得了一些進展，但前方的路似乎還很漫長。目前大多數的“敏捷型”數據庫工具主要作用還是創建、應用以及管理遷移腳本，而不是真正將數據庫視為代碼進行處理。