生產環境開發環境資料庫如何更新

① 項目中的某個方法在開發和測試環境下都能查詢出數據，但是在生產環境下不行，請問一般是什麼原因

1. 版本升級的過程中，資料庫數據是否有丟失情況

2. 如果數據沒有丟失，檢查你的查詢語句是否正確

3. 如果確定查詢語句沒有問題的話，應該是資料庫緩存的問題，資料庫對象是沒有數據的，你重啟你的服務，再測試一下
   

② 如何切換開發環境和生產環境

SSL不同 開發模式：可以使用 WebLogic Server 安全服務提供的示範數字證書和示範密鑰庫。利用這些證書，可設計出在由 SSL 擔保的環境中工作的應用程序。生產模式：不應使用示範數字證書和示範密鑰庫。如果這樣做，將會顯示警告消息。要使用正式申請的數字證書部署應用程序不同 開發模式：WebLogic Server 實例可以自動部署和更新駐留在 domain_name/autodeploy 目錄中的應用程序（其中 domain_name 為域名）。生產模式：由於自動部署功能已禁用，因此必須使用 WebLogic Server 管理控制台、weblogic.Deployer 工具或 WebLogic 腳本工具 (WLST)。生產模式一般使用BEA的JDK，開發模式就無所謂了

③ 數據自動化運維應該注意哪些事項

一、基礎數據概況

CMDB中文是配置管理資料庫，存儲與管理企業IT架構中設備的各種配置信息，與未來的IT運維管理標准化和流程化緊密關聯，並且支持流程的運轉。運維管理平台創建初期或初版中的CMDB更多是偏向IT資產管理，我們在這里定義的IT資產管理，暫時拋除公司個人使用的普通PC機。

日誌主要存儲CMDB中涉及到伺服器或是其它設備的日誌信息。

DB主要是所有IT系統的資料庫信息，包括運維管理系統本身的資料庫。由於資料庫的重要性，所以在基礎數據中單獨一個模塊管理資料庫，包括生產資料庫、測試資料庫、開發資料庫。資料庫的日誌放在日誌模塊進行統一管理，監控和備份。

知識庫主要存儲日常運維管理中發生的事件、問題以及一些經典問題的解決和常用的解決方案，主要起到運維管理輔助的功能。

二、基礎數據三要素

基礎數據要求完整、准確、實時，這三個特性缺一不可。

1.完整性

完整性，要求在數據採集整理階段，要一一梳理，不能有遺漏。任何一個設備的疏漏都將會導致未來出現問題。例如最近的勒索病毒在防範上需要給伺服器升級打補丁，這個時候就是根據伺服器清單一一對照，升級。如果有遺漏落下的伺服器未及時打補丁而導致病毒入侵，後果將很嚴重。那麼，如何做到完整性呢？大致可以分為以下幾步：

文檔庫也包括一些企業或是部門的規章制度，與供應商的合同條文等。主要是涉及到IT系統文檔的一個存放和查閱的地方。

運維標准和運維流程的文檔一定是必不可少的。因為運維自動化的前提就是運維的標准化和流程化。如果沒有明確的標准和規范的流程，運維自動化就只能一直停留在測試環境的假想空間中。

總結

基礎數據在整個運維管理中起到基礎、奠基的重要作用，也是做運維管理平台的第一步和以後每一步的重要依據。一定要捨得投入時間、人力等來建立起完整、准確、實時的基礎數據。打好地基，以後運維的每一步都將有條不紊地循序漸進，終將建設成屬於運維的高樓大廈。

④ 什麼是JAVA開發環境，測試環境及生產環境，及它的過程

1、開發環境
顧名思義，開發同學開發時使用的環境，每位開發同學在自己的dev分支上幹活，提測前或者開發到一定程度，各位同學會合並代碼，進行聯調。
2、測試環境
也就是我們測試同學幹活的環境啦，一般會由測試同學自己來部署，然後在此環境進行測試。bug修復後，需要發版更新測試環境來回歸bug。
3、回歸環境
回歸bug的環境，其實就是我們的測試環境，在測試環境上測試、回歸驗證bug。
4、預發布環境
測試環境到生產環境的過渡。測試環境可能會受到一些限制，一些流程或者數據沒有測試到，就可以在預發布環境進行驗證，從而保證產品上線質量。
預發布環境和生產環境區別：
1）預發環境中新功能為最新代碼，其他功能代碼和生產環境一致。
2）預發環境和生產環境的訪問域名不同。
注意事項：
1）預發布環境一般會連接生產環境的資料庫，測試時要注意，以免產生臟數據，影響生產環境的使用。
5、生產環境
即線上環境，用戶使用的環境。由特定人員來維護，一般人沒有許可權去修改。
另外，還有個灰度發布，發生在預發布環境之後，生產環境之前。
生產環境一般會部署在多台機器上，以防某台機器出現故障，這樣其他機器可以繼續運行，不影響用戶使用。灰度發布會發布到其中的幾台機器上，驗證新功能是否正常。如果失敗，只需回滾這幾台機器即可。

⑤ 四步教你如何完善企業資料庫安全政策

隨著日益復雜的攻擊和不斷上升的內部數據盜竊，資料庫安全成為企業信息安全團隊重點關注的焦點，超越了傳統的認證、授權和訪問控制。一個私人數據入侵，如信用卡號或財務數據，可以給機構造成巨大的損失，更不用說訴訟和違規罰款等可能會帶來的持久影響。Forrester研究公司建議機構重新制定它們的資料庫安全策略，在新安全特性的應用和功能上尋找差距，這有助於幫助資料庫應對新的威脅。
1、建立一個集身份驗證、授權、訪問控制、發現、分類，以及補丁管理於一體的堅實基礎
了解哪些資料庫包含敏感數據是資料庫安全戰略的基本要求。企業應對所有的資料庫採取一個全面的庫存管理，包括生產和非生產的，並且遵循相同的安全政策給它們劃分類別。所有的資料庫，尤其是那些存有私人數據的資料庫，應該有強的認證、授權和訪問控制，即使應用層已經完成了認證和授權。缺乏這些堅實基礎會削弱審計、監察和加密等其他的安全措施。
此外，如果不能每季度給所有的關鍵資料庫打補丁，那麼至少半年一次，以消除已知的漏洞。使用滾動補丁或從資料庫管理系統(DBMS)的供應商和其他廠商那裡收集信息，以盡量減少應用補丁的停機時間。始終在測試環境下測試安全補丁，定期運行測試腳本，以確保修補程序不影響應用程序的功能或性能。
2、使用具有數據屏蔽、加密和變更管理等功能的預防措施
在建立了一個堅實和基本的資料庫安全策略後，就應該開始採取預防措施，以保護重要的資料庫。這樣就為生產和非生產資料庫提供了一個保護層。數據隱私不隨著生產系統而停止，它也需要擴展到非生產環境，包括測試、開發、質量保證(QA)、分階段和訓練，基本上所有的私有數據都可以駐留。資料庫安全專業人士應該評估在測試環境中或外包應用開發中用數據屏蔽和測試數據生成來保護私有數據的效果。
使用網路加密以防止數據暴露給在監聽網路流量或數據靜止加密的窺視者(他們關注存儲在資料庫中的數據)。當數據針對不同的威脅，這些加密方法可以實現相互獨立。通常情況下，也不會對應用程序的功能有影響。
保護關鍵資料庫的結構要按照標准化的變更管理程序來進行。在過去，對生產環境中的計劃或其它資料庫進行變更時需要關閉資料庫，但新版本的資料庫管理系統允許在聯機時進行這些更改，這就帶來了新的安全風險。一個標准化的變更管理程序能確保只有管理員在得到管理部門批准後才能改變生產資料庫並且跟蹤所有資料庫的變更。機構還應該更新自己的備份和可行性計劃，以處理數據或元數據因這些變更而發生的改變。
3、建立具有審計、監測和漏洞評估功能的資料庫入侵檢測系統
當重要數據發生意外變化或者檢測到可疑數據時，有必要進行一個快速的調查來查看發生了什麼事情。資料庫里的數據和元數據可以被訪問、更改甚至是刪除，而且這些都可以在幾秒鍾的時間內完成。通過資料庫審計，我們能夠發現是誰改變了數據和這些數據是什麼時候被改變的等問題。為了支持之前提到的管理條例標准，安全和風險管理的專業人士應該追蹤私人數據的所有訪問途徑和變化情況，這些私人數據包括：信用卡卡號、社會安全卡卡號以及重要的資料庫的名稱和地址等信息。如果私人數據在沒有授權的情況下被更改或者被訪問，機構應該追究負責人的責任。最後，可以使用漏洞評估報告來確定資料庫的安全空白地帶，諸如弱效密碼、過多的優先訪問權、增加資料庫管理員以及安全群組監測。
4、牢記安全政策、安全標准、角色分離和可用性
資料庫安全策略不僅關注審計和監測，它也是一個端到端的過程，致力於減少風險、達到管理條例的要求以及防禦來自內部和外部的各種攻擊。資料庫安全需要把注意力更多地放在填補安全空白、與其他安全政策協作以及使安全方式正式化上。在草擬你的安全策略時，要使你的資料庫安全政策與信息安全政策一致;要注意行業安全標准;要強調角色分離;要清楚描述出數據恢復和數據使用的步驟。

⑥ mysql 開發環境上生產環境後資料庫變化，有什麼好策略呢

打補丁。代碼修改表結構，掃描全表，為新欄位賦值