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