你的數據庫危機四伏
英文原文：Your Database: The Threat That Lies Within
我們已經給予了數據庫充分的關注，因此它們不應成為 IT 風險因素。但即便為 DRP（災難恢復計劃）準備預算、備份機制并且擁有一流的 DBA，數據庫仍然造成了重大威脅。這是為什么呢？
變得敏捷
在快速發展、充滿競爭的市場中，如果你的競爭對手能夠更快更好地發布相關產品，那就意味著你終將失去市場份額。這也就是為什么公司需要變得敏 捷。公司需要更好地掌控信息、更快地制定決策、加快軟件交付以及優化質量控制。敏捷生來就是處理這些挑戰的。它一方面使組織能夠更快地發展，并處理不斷變 化的需求，另一方面又能確保最佳質量。把敏捷概念帶入產品（產品環境、客戶站點等）當中，并使得開發和運營緊密相連，這樣的需求導致了 DevOps 的誕生。
敏捷和 DevOps 的出現并未使軟件開發生命周期（SDLC）的最佳實踐發生徹底的改變。因為它們是軟件開發演進的步驟，而不是一次徹頭徹尾的變革。然而，如果你正行駛在敏 捷世界的快車道上的話，如何貫徹執行這些最佳實踐將顯得更為重要。此外，自動化是極其重要的，它既提升了總體效率，又減少了頻繁變更和發布的固有風險。
流程的自動化、持續集成、持續交付以及持續部署的實現，這些實踐已經被反復證明過了。它們確保了總體流程的高效和可靠性。
對數據庫需要特別關注
基于自動化的可重復性和可持續性流程共同驅動著更安全和更少出錯的部署工作。要想在頻繁變更中立于不敗之地，那就不能依賴于個人能力去記住所有已完成的步驟，也不能依賴于群體能力去識別出可能受到當前變更影響的所有范圍。關鍵在于要盡可能減少人工操作。
但不同于其他軟件組件和代碼（或者是編譯過的代碼），數據庫可不只是一堆文件。數據庫是你最有價值的資產，它包含了需要妥善保管的業務數據。因 此我們不能將它從開發環境拷貝粘貼到測試環境再到產品環境。大多數情況下，數據庫的開發與應用代碼（.Net 或者 Java 開發）顯得截然不同：開發人員和 DBA 訪問并更改共享資源，即一個中央數據庫，而不是工作站上的一個本地拷貝。
數據庫開發和普通應用代碼開發是如此不同，最終導致了孤島的產生。
應用開發人員正勇往直前，他們采用優秀的新開發工具、實踐敏捷方法、自動化以及持續交付。相比之下，數據庫開發采用的卻是一個相對不受控制的流 程。數據庫開發與其說是工程實踐，倒更像是一門與整個 SDLC 流程相隔絕的藝術。在這里，人們從未共享過開發工具、流程和最佳實踐。
數據庫作為有價值的資產，極易成為搖晃的車輪從而破壞了整車的平衡（即成為短板）。
數據庫變更應如何進行處理？
我們不應該僅僅因為數據庫構造的不同而視它為特別的事物。我們應該確保所有團隊、代碼開發人員、DBA 和數據庫開發人員都采用相同的流程。如同在代碼開發中做的那樣，我們應當遵循這些已得到證明的軟件開發最佳實踐，并將其應用到數據庫開發當中去。
在整個開發周期中，為了將數據庫造成的風險最小化，我們需要按照以下方式解決問題：
- 敏捷開發——實行短小的開發周期，同時將數據庫變更作為基于任務的開發工作的一部分進行管理。這樣做能夠確保代碼變更和數據庫變更同時完成，并在之后能夠基于變更請求一同部署。
—— 像 Jira 這樣的任務管理解決方案能夠將任務（task）、問題（issue）、變更需求（change requirements）或者問題記錄（trouble ticket）與實際需要完成的工作對應起來。它能幫助并引導你朝著明確定義的可交付成果方向進行努力，并在之后采用以任務為中心的視角來部署這些變更。 - 像 Chef、Puppet 和 Jenkins 這樣的工具使得軟件開發環境的配置變得更加高效。但是數據庫方面又是如何呢？你如何配置大型數據庫環境？即便是配置小型數據庫環境？數據庫仍然是敏捷跨不過去的檻。
——使用 Delphix 可以方便地創建虛擬數據庫分支。創建開發環境將變得輕而易舉，并行開發也變得觸手可及。生產環境的虛擬拷貝允許你使用最新產品環境的真實數據來測試產品部署，而無需處理存儲問題或是真實的產品風險。 - 假如你嘗試去構造一個良好的開發、測試、UAT（用戶接受性測試）或是產品預發布環境，那么內容屏蔽確確實實是一個挑戰。測試數據越真實，你對質 量保障也就越充滿自信。但是如果開發人員可以不加約束的訪問產品拷貝，那會怎樣呢？你的信用卡號碼是否有可能正好留在其中一臺筆記本上？它會泄露出去嗎？ 另一方面，如果采用模擬數據或是根本不用任何數據，那將無法營造一個良好的測試環境，同時性能測試也會不準確。
——像 DMsuite 這樣的解決方案能夠用逼真、但也是虛構的數據來替換機密數據，而不需要任何編碼。如果為了達到某種目的（健康保健亦或是財務方面的內容）或者正好存在一些敏感信息而使得你需要這樣做的時候，它會通過在非產品環境中替換機密數據的方式從而減少你的“可侵入的足跡”。 - 數據庫變更管理——運用數據庫工具以確保數據庫變更能夠作為 SDLC 的一部分妥善管理，而不是隔絕在主要開發流程之外。另外，確保每一次變更都和一個變更請求關聯起來。這有助于將數據庫管理工作作為通用開發或變更工作的一部分。 <
>- 通過使用 DBmaestro 可以加強版本控制并同時追蹤所有變更。一切盡在你掌控之中：誰在做什么事，在哪里，為什么這樣做。它將消除流程外的變更。一旦開發周期結束，DBmaestro 會將相關的變更自動部署到集成環境中去，識別出變更沖突并且合并它們，如果沒有沖突則直接推送到產品環境中去。 - 測試自動化——建立合適的自動化測試需要巨大的投資。你需要將之視為長遠目標，而非一次性項目，并開始為每次新的開發活動或是主要變更創建并積累自動化測試。
單元測試：建立堅固的安全網絡需要采用以變更為重點的測試方法，同時確保那些變更沒有造成破壞。
——通過采用 Oracle SQL Developer 或者 Microsoft 平臺的 tSQLt 這樣的單元測試工具就可以引進數據庫單元測試，而無須任何花費。
回歸測試：另一種測試方法，它將數據庫和應用代碼作為一個整體來進行測試。
——使用 TestComplete 驗證那些常見的場景，之后也可以加入對不太常見的場景的驗證，這將使你自信滿滿地交付發布。 - 發布自動化——緩解風險的關鍵角色。自動化的部分越多，你就越能做到精確掌控：重現開發中引入的變更，并在測試環境中測試，最終安全地應用到產品 環境中去。一旦你自動化了 SDLC 的流程并且成功解決日常工作中的挑戰，那么一個健康的 SDLC 就水到渠成了，它能同時兼顧最小風險和最高效率。
——使用 IBM Urbancode 部署工具能夠幫助你管理發布活動和配置，并精心策劃總體流程。
最好的消息是，這些不同類型的解決方案完全可以合作無間。因而可以使用 Delphix 創建虛擬開發分支，使用 DMsuite 屏蔽機密內容，使用 Jira 管理開發任務，使用 DBmaestro 對變更和發布進行版本控制，使用 tSQLt 或者 SQL Developer 進行自動化測試發布，以及使用 uDeploy 來策劃發布流程，以上所有都能匯總成一個精巧的、自動化的并且安全的流程。
總結
當著手采用最佳實踐的時候，數據庫才展現出真正的挑戰。這也正說明了孤島是如何產生的。開發部門或許會采用不同的流程來分別對待代碼開發和數據庫開發，或僅在部分變更工作中采用最佳實踐。
消除主要風險的最佳方法是，不要以技術眼光去看待這些差異，同時找到解決方法——流程或者工具——去采用并實施最佳實踐和自動化。
作為一份具有如此高價值的資產，數據庫不應成為你的業務的短板。
關于作者
Yaniv Yehuda 是 DBmaestro 公司的聯合創始人兼 CTO。DBmaestro 是一家以數據庫開發和部署技術為重點的企業級軟件開發公司。Yaniv 同時也是 Extreme Technology 公司的聯合創始人兼開發部主管。Extreme Technology 是一家面向以色列市場的 IT 服務供應商。Yaniv 曾是以色列國防軍隊計算機中心的上尉。他在那里擔任軟件工程經理。
<span id="shareA4" class="fl">
</span>