數據庫部署的全方位靜態分析
我的大部分技術生涯都在初創公司中度過。我喜歡快節奏和學習新事物的機會，以及將一個新產品成功帶進市場的成就感。我的職業生涯始于QA。在初創公司中，開發人員與測試人員的比例不可能像大企業那樣低。作為一名初創公司的QA工程師，收件箱的郵件總是比發件箱多得多。你是新版本發布的***一道關卡，因此你總處于顯微鏡之下。在初創公司的早期階段，你很可能也從屬于“客戶支持”團隊，所以當產品出現問題時，你會成為最忙碌的一位。
和其他從事相同工作的人一樣，我總是非常關注于尋找正確的工具來減輕我的負擔，但是不能犧牲我個人對于工作質量的定位。因此我在10年前就遇到了FindBugs。我***次使用這個工具時，我將它的結果分享給團隊的開發工程師，他們感覺這個工具產生了多于真實Bug的誤報或者屬于一種“吹毛求疵”方式。但是，隨著我們不斷地根據自己的需求調整和擴展所執行的檢查，并且將FindBugs得到的數據與測試和生產中發現的實際Bug數量相關聯，FindBugs***成為每夜構建版本和按需構建版本的組成部分。這些報告是在早期預示潛在問題的好線索，也允許開發者提前修正錯誤，避免占用測試時間或運營故障故障時間。此外，對于我團隊中的開發者而言由于每天都能收到構建系統的提醒，而且這些提醒會幫他們改掉自己的壞習慣，編寫出更安全、更高效、更穩定的代碼，所以他們產生的缺陷也越來越少。發布周期縮短了，產品質量提高了，客戶滿意度也提高了，這都證明了預防確實比治療更加重要。
隨著企業IT不斷地擁抱敏捷開發實踐和采用DevOps模式，以此更快地向市場推出更優質的產品，DBA實際上也開始感覺到壓力。前面關于初創軟件公司QA工程師的介紹也一樣適用于DBA。隨著版本發布越來越頻繁，DBA接收到需要編寫、檢查、修改或優化的SQL腳本數量要遠遠多于完成的數量。DBA是數據質量、數據安全和數據平臺性能的***一道防線，因此DBA也是***批響應問題的人。
在與我們協作的財富500強公司DBA中， 他們日常工作中最耗費時間的任務是檢查SQL。有一些DBA將自己70%的時間用在人工檢查SQL腳本上。他們會像FindBugs等工具檢查Java代碼一樣去檢查SQL：預示邏輯問題的編碼模式、安全漏洞、性能問題及違反內部規定***實踐或外部法規的合規性問題。
顯然，DBA需要一種和十年前FindBugs一樣的工具。SQL靜態分析并不是新技術，但是目前可用的產品也只能做到靜態分析。通常，它們會在不考慮上下文的情況下評估SQL語句。這種局限性會影響最終的生產力和質量，因為數據庫生命周期管理的大多數時候都知道誰在何時、何地執行何種操作。例如，一個組織可能允許給一個測試環境分配權限和執行INSERT語句，但是絕不允許在生產環境的自動化任務中執行這些操作。任何SQL靜態分析工具都必須考慮環境參數。
另一個讓問題變得復雜的是數據庫“版本變化”。雖然各個版本的應用程序都會打包、設定版本和全部替代，但是支持應用程序的數據模式一直存在，并且不斷地進化。而且，外部合規性標準與內部審計要求通常規定要嚴格控制數據庫的增量修改，并且要用嚴格定義的流程來跟蹤變化。這意味著，DBA還必須（通過手工流程和檢查SQL注釋）確認能夠跟蹤到修改的原因，而且要在每一個環境中跟蹤修改的執行結果。
DaticalDB Rules Engine在設計與實現時專門考慮了SQL檢查與靜態分析所帶來的特殊挑戰。下面是Datical DB通過靜態分析安全可靠地提高效率的一些原因：
- 用于執行強大評估的模型——Datical DB將應用程序的模式抽象到一個嚴格定義和驗證的對象模型中。這些強大規則的授權過程非常快速、簡單。一旦編寫了，它們就會在生命周期中每一個數據庫執行Forecast或Deploy時生效。
- 感知環境的修改驗證—— 這個模型包含了應用程序生命周期中關于客戶端環境和各種數據庫實例的信息。你可以編寫規則使早期部署階段環境具有***靈活性，而同時讓敏感環境具有***安全性。
- 盡早確認內部與外部審計需求—— 在Datical DB中，為了遵守外部和內部審計要求，你只需要緊密綁定數據模型的各個修改。每次（或自動化框架）Forecast或Deploy時執行的自動化檢查替代了手工檢查，由它們來確認修改的可審查性。
- 自動驗證對你最重要的方面—— 提供自定義分析的功能，覆蓋自己的內部***實踐，如命名規范、允許和不允許的SQL和對象依賴管理。
- 自動化重復任務—— 和許多分析源代碼的靜態分析工具類似，一些簡單的鼠標操作就可以將Datical DB集成到構建或部署系統中。現在，每次構建或部署一個應用程序時，它就會執行驗證規則，然后生成一個供整個組織使用的報表。由于DBA緊盯屏幕的時間大大減少所以他們可以專注一些更重要的項目和問題。
- 代碼質量提高意味著Bug減少——DBA制定規則，然后將它們分享給開發人員。然后，開發人員就獲得一個關于他們所在組織接受和不接受的編碼知識庫。開發減少Bug數量將大大節點時間與金錢。
- 讓運維人員更多參與數據庫開發——這個規則引擎與Datical DB Forecast高度集成。這個特性支持模擬數據庫修改，而不需要真正修改目標數據庫。當DBA向運維人員分享他們的規則時，運維人員就可以每天晚上對STAGE或PROD環境執行Forecast，保證當前在DEV或TEST環境的修改也符合下游執行的嚴格驗證，這同樣可以在生命周期前期發現問題，因此修復問題的代碼更低、難度更小。
