包括以下幾個方面：
- 測試基礎環境，相當于測試環境的運維：
a. 測試硬件資源的申請，變更，釋放等流程及具體工作的受理和實施。
b. 基礎應用的部署和維護，如應用服務器、數據庫等，及相關的問題處理、備份恢復等，可參考運維的問題處理流程。
c. 可覆蓋當前所有類型的測試環境。（包括sit，uat，性能，投產驗證等） - 測試環境之上的，發布管理，需理清和開發版控系統的接口，投產的接口，可實現的自動化的自動化掉。
a. 覆蓋納入管控的sit測試環境，uat測試環境等，（理清準入條件，符合要求的再納入）
b. 實現效果，版本清晰，變更清晰，狀態可視化。
c. 包括：批量，數據等。 - 關于納入管控的，全部只有一套環境，明確準入需求，不符合在不納入管控。
- 管控的原則，有能力承接，就承接一個。沒有能力承接的，由開發自己管理。（需要對應用系統有深入的認識，包括業務和架構，自動化的前期是深入理解流程，手工可以做的基礎上用自動化替代，并根據不同系統的情況推進相關的自動化的動作，如測試、部署等，需持續改進。。。）
- 相關流程和平臺：
a. 測試環境申請，變更，釋放流程；
b. 問題處理流程，類似運維的工單流程；
c. 相關的測試環境的可視化，包括主機，ip，應用版本，狀態，數據等。 - 人員角色：
a. 流程中的相關審批類角色；
b. 具體的環境管理角色，類似運維層面；
c. 發布管理：需要深入理解應用系統。在項目組外的角色難以做好。
d. 數據和批量相關：也需要深入理解應用系統。
我個人更加傾向于：
更好的方式是把c、d交給項目組，通過一套體系來評估各個系統的成熟度，鼓勵項目組內的持續改進、推動項目組自身的devops。需要把開發和運維都帶進來。
金融行業有其特殊性：
1：風險控制、監管層的要求；
2：金融行業大部分系統的耦合性太強。
所以對于devops的推動不宜太激進，不要為了做而做，一切要基于項目組，分項目組而治，鼓勵項目組內加強開發、測試、運維的溝通（全部對效率和質量負責），一切以減少線上bug，加速業務需求發布為目的。對于互相響應較大的系統變更，做好協調工作。
對于nb研發管理部：負責相關的基礎環境建設，相關的流程建設、及相關的可視化平臺的統一建設等。具體的devops，不用出具詳細的流程方案，但應該鼓勵項目組加強內部溝通，鼓勵內部的持續改進。通過一套體系來評估各個系統的成熟度，鼓勵項目組內的持續改進、推動項目組自身的devops。
