這個問題能出現，讓我百思不得其解。

通常一套系統上線，從開發到上線最低要經歷dev，ut，sit，uat（越往後重要級越高）最低四套環境，且每套環境都是邏輯隔離的，這是最保守的要求，真實開發中環境保守量只多不少。

需求變更，迭代涉及到的生產環境需要變動，都是歸納到新的版本升級中。在迭代過程中軟體會在開發環境中完成，依次移植到ut冒煙，冒煙透過進sit，sit透過上uat，基本上uat環境展現的東西就已經是生產看到的最終樣子了。

然後我們在說說這個需求變更產生對資料庫的操作上的流程，就知道為啥我覺得會產生這樣的後果是多不可思議了。首先，我們在dev環境上根據需求的變更會把對資料庫的操作都已增量sql指令碼的形式提現出來，並且在版本管理中都可以回嗍上一個版本。其中，對錶結構的增刪改操作基本都是以指令碼呈現，且這都是可以重複執行。對錶資料的增刪改會從新增加指令碼檔案，或者增量到已有指令碼後。然後提交到ut測試環境的有該需求變更所涉及到的指令碼檔案以及對應的新需求的程式碼包，通常會新打包程式碼而不是替換檔案的形式。最後會提交變更需求清單，羅列變更項和涉及到的新版本的各項檔案，以及版本管理地址，開發人員列表，上線風險注意事項等等一堆細節。以上都是開發人員的事。

ut環境理論上由測試來搭建部署的方便黑盒操作，ut，sit沒啥好說的的，冒煙，測試（有各種指標），測試透過會演練上uat環境過程。

測試階段完結生成測試報告，最終部署運維人員拿到交付包之後按照開發人員提供的部署安裝手冊依步驟依次安裝，部署過程會指定一名開發人員協助過程中遇到的問題，通常是開發同個床刷刷微博完事。。

好了說說部署的過程，以及好奇怎麼會產生這類刪庫操作的，因為部署過程中完全用不著連結gui，給到你運維部署的都是一堆指令碼，程式碼包。執行完畢基本就完事了。按過程部署出問題也好甩鍋給測試或者開發，和運維沒關係。實在想不到運維的人怎麼會有操作資料的舉動。而且是怎麼會有刪庫的許可權。而且還是圖形化刪除，早知道，為了規範化流程化，我們開發人員都已經做成了指令碼模式啊。。一個imp就完了。

刪庫這些操作在dev，sit，ut環境上都是可以隨便玩的，躺著玩睡著玩蹲著玩都沒問題，玩壞了也其實沒有，從新執行全量指令碼，幾分鐘就搞定了。但是在uat環境或者正式的生產庫上操作，不好意思不給你許可權。生產資料高於一切理論上運維是沒任何許可權操作的，甚至包括select許可權。

綜上這事是我覺得不可思議的地方，這內部管理得是有多混亂。