本文主要是講如何建立有效的環境、程序、配置、SQL變更和管理平臺。

?幾天前和一個朋友聊到環境、程序的配置變更，SQL變更和整個上線流程。之前我們在這塊也做了很多，有做的好的也有做的一般的，借機都總結下來，希望對你有用。

通常情況下，我們最關注的也是最重要的部分是應用的變更，就是程序的部署上線發布這塊，因為這部分最高頻，每天上線很多次的情況都可以發生，所以我們在平臺建設的時候也是優先做好這部分，但是對于環境、程序配置和SQL變更部分，通常情況下會優先級低一些，不是這些不重要，只是暫時通過手工操作或者人力頂一下這部分的任務，最終這些問題是要通過平臺自動化來解決的。

底層物理環境配置

很久以前，計算資源成本高昂，導致機器匱乏，很難做到「開發-測試-預發-生產」物理環境配置的統一。線上用高配的物理機，線下用低配的過保機器，甚至用虛擬機，這都是很常見的做法。不同環境之間物理資源的不同加大了環境配置的管理難度。比如一個Java 程序需要 4G 的內存，這在線上沒問題，但是線下的虛擬機可能 1G 的內存都沒有。同樣的配置在兩個環境中需要小心維護否則程序就崩了，所以經常有很多文檔記錄這些「魔法」騷操作，然后在操作環境時拿出來翻一翻。

現在隨著計算資源價格下降、云計算快速普及，尤其是 k8s 的出現，大大降低了保持「開發-測試-預發-生產」環境一致性的成本，同時操作起來簡便易行。所以工作中，我們要「盡量」保持這些底層基礎設施的統一，這是做好上層很多工作的基礎。

基礎設施即代碼(Infrastructure as Code, IaC)的出現把環境配置的問題變得更簡單。IaC解決的最大問題是基礎設施配置和管理的自動化。之前通過手工操作來配置和管理的服務器、網絡等基礎設施通過 IaC 把基礎設施配置和管理自動化，大幅提升效率和可靠性。

• 1. 使用代碼管理基礎設施,大大提高效率。
• 2. 減少手工操作錯誤。
• 3. 代碼可以版本控制,具備完整的跟蹤性。
• 4. 自動化可以保證環境一致性。
• 5. 代碼即文檔,有利于團隊協作。

之前Google是把 IaC 放到代碼倉庫中，SRE管共性的配置，研發小伙伴來管理每個服務獨特的配置部分，這也是一種方法。但是鑒于國情，我還是覺得讓 SRE 或者 Ops 來管更合適，這樣也有利于劃清職責邊界。

我建議 1）梳理全公司的編譯和運行時環境需求 2）把基礎環境的固化到有版本控制的 Dockerfile中，3）然后研發效能平臺引用這些基礎鏡像，最終達到編譯和運行時受控。

編譯時配置

在編譯源代碼前,我們通常會有一些編譯時配置，要么寫到配置文件中，要么通過傳參的方式傳進去，然后在編譯時打到二進制程序里面。通常情況下編譯時配置信息放到編譯腳本中固化下來是個不錯的最佳實踐。比如我們經常遇到的 build.xml, pom.xml, build.gradle等。通常這些構建腳本是研發小伙伴會開發調試時會用到，研發管理平臺通常也會用到這些構建腳本，但是有時也會傳入一些其它的參數。此時研發效能管理平臺就會自己記錄一份當時運行的命令，以便后面排查之需，比如保障制品的可重現。

所以在這里，我們可以看到研發小伙伴會把大部分編譯時配置放到構建腳本中，存在于代碼倉庫(repo)中和源代碼一起進行版本管理；研發效能平臺部署環境時，會從平臺上傳入參數進行「干凈的」編譯，此時平臺會記錄一份編譯時的配置。這兩處的編譯時配置信息都很重要。

運行時配置

一旦我們的程序或者軟件部署完成，通常在啟動時還需要讀取配置文件或者讀取數據庫加載一些動態的配置信息，這就是運行時配置。運行時配置是可以動態調整的，無需重新打包和部署。

有的公司會把運行時配置也放到代碼倉庫中一起管理，尤其當配置信息比較少，修改比較容易時。但是一旦部署上去想要修改，就要把運行的實例(機器/容器)中的運行時配置都需要修改一遍，雖然有ansible，saltstack，puppet，但操作也會麻煩、容易出錯且會導致安全問題。通常情況下研發小伙伴是沒有手動修改生產環境配置的權限。如果想一次更改多個服務多個實例的配置，這就會是個大問題。隨著服務的增多，配置的復雜，我們就會遇到如下的問題：

• 配置文件分散：每個服務在自己倉庫下維護一套配置，無法統一配置和管理
• 多環境配置文件難維護：通常「開發-測試-預發-生產」每個環境都有自己的一套環境配置，有的配置項需要統一，有的配置項需要區分。
• 配置文件無法實時更新：配置文件修改后，必須重啟服務才能生效配置，無法實時更新，對用戶不友好。

為了解決以上問題，通常公司會引入配置中心來解決，比如apollo，disconf，nacos，SpringCloud Config等。這些都是市面上比較常見的配置中心選型。

• 首先把項目中各種配置全部都放到一個集中的地方進行統一管理，并提供一套標準的接口。
• 當各個服務需要獲取配置時，就來配置中心接口拉取自己的配置。
• 當配置中心中的各種參數有更新的時候，也能通知到各個服務實時同步最新的信息，使之動態更新

數據庫配置，數據庫變更管理

我們在上線應用的時候，通常也伴隨SQL變更，主要的需求

• SQL上線審批流：做某些關鍵變更要有人審批，比如上級、DBA等
• SQL語句檢查、審核和執行等：SQL語句要正確，執行沒有問題
• 角色和權限：只能查詢和變更自己有權限的 DB

可以試試Yearning/Themis/inceptior這三個工具，我們也是在開源工具的基礎上進行了二次開發，主要是打通了用戶、權限和應用部分。之前申請個DB 還需要在數百個DB中去尋找，現在只要登錄就會列出自己有權限的 DB。但這部分還沒有完全整合到我們的流水線/發布單/上線單體系中去，這是一個需要繼續發力的點。

統一變更流程和平臺

「生產->測試」環境之間的配置變更，通常由QA小伙伴來負責，比如把生產環境的表結構應用到測試環境。

「開發->測試->預發->生產」這樣的配置晉級流程通常由研發的小伙伴來完成。具體的情況說明，可以參考我《研發效能之環境管理》的這篇文章。做好變更風險管控就好。

我個人覺得SQL 上線，配置文件上線，前端 CDN 都應該整合到應用上線流程中去，而不是單獨有一個平臺來承載。這樣數據打通、角色和權限打通、流程打通，統一的體驗和流程，解決了各種系統間跳轉帶來的問題，提高了產研運各方的整體效能和工作體感，尤其是對于中小公司來說。

我的相關文章：

研發效能之環境管理
互聯網公司研發效能/工程效率團隊建設和規劃
DevOps｜研發效能+項目經理PMO
devops｜中小公司不要做研發效能度量
研發效能負責人/研發效能1號位｜DevOps負責人