我的大部分技術(shù)生涯都在初創(chuàng)公司中度過。我喜歡快節(jié)奏和學習新事物的機會，以及將一個新產(chǎn)品成功帶進市場的成就感。我的職業(yè)生涯始于QA。在初創(chuàng)公司中，開發(fā)人員與測試人員的比例不可能像大企業(yè)那樣低。作為一名初創(chuàng)公司的QA工程師，收件箱的郵件總是比發(fā)件箱多得多。你是新版本發(fā)布的最后一道關(guān)卡，因此你總處于顯微鏡之下。在初創(chuàng)公司的早期階段，你很可能也從屬于“客戶支持”團隊，所以當產(chǎn)品出現(xiàn)問題時，你會成為最忙碌的一位。

　　和其他從事相同工作的人一樣，我總是非常關(guān)注于尋找正確的工具來減輕我的負擔，但是不能犧牲我個人對于工作質(zhì)量的定位。因此我在10年前就遇到了FindBugs。我第一次使用這個工具時，我將它的結(jié)果分享給團隊的開發(fā)工程師，他們感覺這個工具產(chǎn)生了多于真實Bug的誤報或者屬于一種“吹毛求疵”方式。但是，隨著我們不斷地根據(jù)自己的需求調(diào)整和擴展所執(zhí)行的檢查，并且將FindBugs得到的數(shù)據(jù)與測試和生產(chǎn)中發(fā)現(xiàn)的實際Bug數(shù)量相關(guān)聯(lián)，F(xiàn)indBugs最后成為每夜構(gòu)建版本和按需構(gòu)建版本的組成部分。這些報告是在早期預示潛在問題的好線索，也允許開發(fā)者提前修正錯誤，避免占用測試時間或運營故障故障時間。此外，對于我團隊中的開發(fā)者而言由于每天都能收到構(gòu)建系統(tǒng)的提醒，而且這些提醒會幫他們改掉自己的壞習慣，編寫出更安全、更高效、更穩(wěn)定的代碼，所以他們產(chǎn)生的缺陷也越來越少。發(fā)布周期縮短了，產(chǎn)品質(zhì)量提高了，客戶滿意度也提高了，這都證明了預防確實比治療更加重要。

　　隨著企業(yè)IT不斷地擁抱敏捷開發(fā)實踐和采用DevOps模式，以此更快地向市場推出更優(yōu)質(zhì)的產(chǎn)品，DBA實際上也開始感覺到壓力。前面關(guān)于初創(chuàng)軟件公司QA工程師的介紹也一樣適用于DBA。隨著版本發(fā)布越來越頻繁，DBA接收到需要編寫、檢查、修改或優(yōu)化的SQL腳本數(shù)量要遠遠多于完成的數(shù)量。DBA是數(shù)據(jù)質(zhì)量、數(shù)據(jù)安全和數(shù)據(jù)平臺性能的最后一道防線，因此DBA也是第一批響應問題的人。

　　在與我們協(xié)作的財富500強公司DBA中， 他們?nèi)粘９ぷ髦凶詈馁M時間的任務是檢查SQL。有一些DBA將自己70%的時間用在人工檢查SQL腳本上。他們會像FindBugs等工具檢查Java代碼一樣去檢查SQL：預示邏輯問題的編碼模式、安全漏洞、性能問題及違反內(nèi)部規(guī)定最佳實踐或外部法規(guī)的合規(guī)性問題。

　　顯然，DBA需要一種和十年前FindBugs一樣的工具。SQL靜態(tài)分析并不是新技術(shù)，但是目前可用的產(chǎn)品也只能做到靜態(tài)分析。通常，它們會在不考慮上下文的情況下評估SQL語句。這種局限性會影響最終的生產(chǎn)力和質(zhì)量，因為數(shù)據(jù)庫生命周期管理的大多數(shù)時候都知道誰在何時、何地執(zhí)行何種操作。例如，一個組織可能允許給一個測試環(huán)境分配權(quán)限和執(zhí)行INSERT語句，但是絕不允許在生產(chǎn)環(huán)境的自動化任務中執(zhí)行這些操作。任何SQL靜態(tài)分析工具都必須考慮環(huán)境參數(shù)。

　　另一個讓問題變得復雜的是數(shù)據(jù)庫“版本變化”。雖然各個版本的應用程序都會打包、設定版本和全部替代，但是支持應用程序的數(shù)據(jù)模式一直存在，并且不斷地進化。而且，外部合規(guī)性標準與內(nèi)部審計要求通常規(guī)定要嚴格控制數(shù)據(jù)庫的增量修改，并且要用嚴格定義的流程來跟蹤變化。這意味著，DBA還必須（通過手工流程和檢查SQL注釋）確認能夠跟蹤到修改的原因，而且要在每一個環(huán)境中跟蹤修改的執(zhí)行結(jié)果。

　　DaticalDB Rules Engine在設計與實現(xiàn)時專門考慮了SQL檢查與靜態(tài)分析所帶來的特殊挑戰(zhàn)。下面是Datical DB通過靜態(tài)分析安全可靠地提高效率的一些原因：

　　用于執(zhí)行強大評估的模型——Datical DB將應用程序的模式抽象到一個嚴格定義和驗證的對象模型中。這些強大規(guī)則的授權(quán)過程非常快速、簡單。一旦編寫了，它們就會在生命周期中每一個數(shù)據(jù)庫執(zhí)行Forecast或Deploy時生效。

　　感知環(huán)境的修改驗證—— 這個模型包含了應用程序生命周期中關(guān)于客戶端環(huán)境和各種數(shù)據(jù)庫實例的信息。你可以編寫規(guī)則使早期部署階段環(huán)境具有最大靈活性，而同時讓敏感環(huán)境具有最大安全性。

　　盡早確認內(nèi)部與外部審計需求—— 在Datical DB中，為了遵守外部和內(nèi)部審計要求，你只需要緊密綁定數(shù)據(jù)模型的各個修改。每次（或自動化框架）Forecast或Deploy時執(zhí)行的自動化檢查替代了手工檢查，由它們來確認修改的可審查性。

　　自動驗證對你最重要的方面—— 提供自定義分析的功能，覆蓋自己的內(nèi)部最佳實踐，如命名規(guī)范、允許和不允許的SQL和對象依賴管理。

　　自動化重復任務—— 和許多分析源代碼的靜態(tài)分析工具類似，一些簡單的鼠標操作就可以將Datical DB集成到構(gòu)建或部署系統(tǒng)中。現(xiàn)在，每次構(gòu)建或部署一個應用程序時，它就會執(zhí)行驗證規(guī)則，然后生成一個供整個組織使用的報表。由于DBA緊盯屏幕的時間大大減少所以他們可以專注一些更重要的項目和問題。

　　代碼質(zhì)量提高意味著Bug減少——DBA制定規(guī)則，然后將它們分享給開發(fā)人員。然后，開發(fā)人員就獲得一個關(guān)于他們所在組織接受和不接受的編碼知識庫。開發(fā)減少Bug數(shù)量將大大節(jié)點時間與金錢。

　　讓運維人員更多參與數(shù)據(jù)庫開發(fā)——這個規(guī)則引擎與Datical DB Forecast高度集成。這個特性支持模擬數(shù)據(jù)庫修改，而不需要真正修改目標數(shù)據(jù)庫。當DBA向運維人員分享他們的規(guī)則時，運維人員就可以每天晚上對STAGE或PROD環(huán)境執(zhí)行Forecast，保證當前在DEV或TEST環(huán)境的修改也符合下游執(zhí)行的嚴格驗證，這同樣可以在生命周期前期發(fā)現(xiàn)問題，因此修復問題的代碼更低、難度更小。  

核心關(guān)注：拓步ERP系統(tǒng)平臺是覆蓋了眾多的業(yè)務領(lǐng)域、行業(yè)應用，蘊涵了豐富的ERP管理思想，集成了ERP軟件業(yè)務管理理念，功能涉及供應鏈、成本、制造、CRM、HR等眾多業(yè)務領(lǐng)域的管理，全面涵蓋了企業(yè)關(guān)注ERP管理系統(tǒng)的核心領(lǐng)域，是眾多中小企業(yè)信息化建設首選的ERP管理軟件信賴品牌。

轉(zhuǎn)載請注明出處：拓步ERP資訊網(wǎng)http://www.guhuozai8.cn/

本文標題：數(shù)據(jù)庫部署的全方位靜態(tài)分析

本文網(wǎng)址：http://www.guhuozai8.cn/html/consultation/10839317808.html