DevOps ｜研發效能之環境、程式、設定、SQL變更管理

本文主要是講如何建立有效的環境、程式、設定、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 都應該整合到應用上線流程中去，而不是單獨有一個平臺來承載。這樣資料打通、角色和許可權打通、流程打通，統一的體驗和流程，解決了各種系統間跳轉帶來的問題，提高了產研運各方的整體效能和工作體感，尤其是對於中小公司來說。