研發效能之環境管理
「誰把我的環境給重新部署了？」「我的環境裡邊的資料怎麼不對了？」
「誰能幫我把線上的設定同步一下到線下？」
環境管理是我們日常工作中比較複雜的一環，主要是因為涉及內容比較多，程式、設定、資料都會涉及，如果是開發、測試環境，還會涉及到測試資料造數、系統刷資料、不同的人使用、鎖定、轉讓、釋放等問題。下面我將會從環境分類、環境建設的難點，以及最後如何解決這些難點來講述研發效能之環境建設。
環境的分類
網路型別環境
從網路環境的可存取性區分，研發效能涉及以下三種環境：
- 辦公網路環境：公司的內部辦公網，也是管控相對比較寬鬆的網路，可以存取外網。因為部署了各種內部服務，網路環境相對比較複雜
- 測試網路環境：用於部署各種測試服務，包括研發測試用的環境，也包括QA的測試環境，可以進行功能測試，也會進行壓力測試等，一般都可以和辦公網相通，但不與外網互通。
- 線上網路環境：與辦公網、測試網路隔離，一般不能存取辦公網路環境和測試網路等環境。
IT、運維和安全的小夥伴一般更願意從網路的可存取性去劃分環境，因為這樣可以劃分資源、設定存取策略、進行安全檢測等。
用途劃分環境
對於產研團隊來說，我們通常從環境的用途來劃分環境，一是和自己角色相關，研發用研發環境，測試用測試環境；二是通過用途區分好理解。至於能否打通，是否受限一般由底層基礎設施團隊來維護，大家都不太關心。對於我們研發效能團隊來說，我們一般會維護一張各個環境互聯互通、安全網路策略的表格，讓各方心裡都有數。萬一出現存取性的問題，相關人員也能自己排查。
- 開發環境：一般用 dev 標識，用於開發人員編寫程式碼、偵錯程式，設定可以比較隨意，開發偵錯方便為主，開啟偵錯模式。程式碼極其不穩定。
- 聯調環境：因為聯調環境通常是相對比較穩定的一個開發環境，所以通常也是用 dev 標識，主要用於前後端聯調介面，通常部署介面相對穩定下來的程式碼。
- 測試環境：一般用 qa 標識，這個環境通常用於測試人員功能測試、缺陷迴歸。設定儘量和線上環境保持一致。部署要驗證的相對穩定的程式碼，而不是最新的程式碼。
- 預發環境：一般用 pre 標識，用於最後確認功能。一般都直接採用線上的設定和資料，但是僅限確認功能的人使用，不對使用者開放。使用時一定要注意以免髒資料產生，影響正常服務。部署經過 qa 驗證要上線的程式碼。
- 驗收環境：即使用者驗收測試環境(User Acceptance Testing)，一般用 UAT 標識，通常是由最終軟體的使用者進行的測試，因此是面向終端使用者的測試，結束之後通常就可以釋出生產環境了。部署經過 qa 驗證要上線的程式碼。
- 生產環境：一般用 prod 標識，部署經過測試、確認的程式碼，通常不用於功能測試，不開啟偵錯模式。AB測試一般在生產環境下，而隔離比較好的情況下，也可以做效能測試和壓力測試。
整合測試環境，有的行業也稱之為SIT 環境（system integration test），而我們更願意稱之為 QA 環境，簡單明瞭且無需解釋，大家都能瞭解。用 SIT 有很高的解釋成本；同理預發環境，也有人用 staging 環境，但總覺得沒 pre 更加簡單，且能讓更多的人瞭解其用途。 另外一個角度就是，我們公司裡大家建設的環境名的統計資料也支援了我們的想法，qa 環境比 SIT 環境數多，pre 環境比 staging 環境多。
環境建設的難點
環境建設主要涉及資源、負責人、建設和維護四個方面，當然難點也主要在這四個方面。
1. 缺少硬體資源
很多公司之所以沒有開發、測試環境是因為沒有硬體資源。沒有充足的資源搭建測試環境，這是環境建設的第一個難點。尤其是很多不那麼「現代」的公司，比如建立個虛擬機器器還要申請，走漫長的審批流程，層層審批的。
也有的公司經常把一些設定特別低且過保的機器給開發測試環境用，三天兩頭出問題，白白浪費了開發測試人員的時間。
2. 缺少明確的負責人員
很多公司線上環境還能保證專人負責，開發環境就是員工工作筆電，幾乎沒有QA環境。這種開發、測試環境缺失的主要問題還是在業務負責人對自己業務的理解。沒有意識到開發、測試環境建設對研發效率、生產環境質量的影響，也沒意識到需要有明確人員負責環境的建設和維護。
3. 耗時長難搭建
每次搭建都需要研發同學申請機器，然後手動在機器上一個一個服務的安裝服務，同時還要設定各種中介軟體，刷入對應的資料等。難搭建耗時長，對於使用方和搭建方都是一種折磨。
4. 缺少後期維護
環境搭建出來後，因為缺少後期維護，環境中的服務版本和線上有所差異，但是其他人又不知道如何更新；線上資料庫表結構變化了，也沒人同步到線下；某些線上功能，甚至在測試環境都無法迴歸驗證。慢慢環境就會變成無法使用狀態，於是開啟了又一輪搭建環境的痛苦過程。
5. 缺少複用
假設一個業務有20個微服務，每個微服務一個容器，那麼聯調、測試、預發、UAT四套環境都完備至少要80個容器；如果有3個QA同學並行測試，都獨佔環境，那麼就要240個容器。這還是微服務較少的情況。如果要是業務複雜起來，微服務數量增多，範例的副本增多，環境套數增多，那麼就會佔用大量的物理資源。
環境建設最佳實踐
針對以上問題，把我們的實踐分享給大家。
1. 充足的硬體資源
雖然現在硬體相對人工成本來說已經相當便宜，尤其是有各種雲資源可以利用，但是不得不說有些公司依然在資源上不願意投入。現在一人天500人民幣，可以在某雲上買一個2核2GB記憶體50GB的雲伺服器使用一年。而500人天，月薪1萬左右，一個應屆生的工資可能都比這還高。如果按照資深工程師去算，更得不償失。現在和之前硬體價格高企的年代不同了，所以能硬體解決的就儘量不要用人去解決。
前期資源的使用可以粗糙一些，後面可以設定個資源池大家共用，再精細化一點可以針對每個人設定配額。因為每個人使用的資源是不一樣的，研發可能1-2套環境就夠了，但是並行測試任務較多的QA小夥伴就會需要更多的資源，這個時候配額的上調又需要個流程來完成。我個人總覺得加上審批流的過程是不完美的。
2. 權責清晰的團隊
想要把開發、測試環境建設好，關鍵是要有明確的環境負責人。以往經驗來看，誰需要、誰建設、誰負責。
- 開發環境的第一負責人是研發同學
- QA環境的第一負責人是QA同學
- 線上環境的負責人是團隊所有人員，第一責任人是業務負責人。我們不能要求業務的負責人時時刻刻盯著線上環境，但是我們要求業務負責人去建立相應的機制、安排合適的資源和人力去保證線上業務的穩定。這也是業務負責人必須明確的原因之一。
為啥線上環境的第一責任人是業務負責人，因為他才能結合多種背景因素做出最恰當的判斷。
舉個例子
之前我們一般都是晚上下班以後、週五下午、週六日都可以上線。如果僅僅是前端問題，甚至中午都可以上線。那個時候，我們每個人回家都是帶著筆電回去，晚上上完線以後，還要測試，沒問題以後才算完。大家雖然很累很趕很忙，但是有一股勁：這是「我」的產品。
後來產品成了「我們」的產品，「老闆」的產品，改成了每週五上線，其它時間除非緊急缺陷修復否則不上線，要去團建不上線，老闆沒審批不上線，週末上線擔心發現bug不上線。看似「上線」規範了，實則跑不起來也跑不快。大家看似各司其職，實則是守著自己的領地，卻丟了整個的陣地。犧牲了業務，把業務中的問題劃歸到「流程」「制度」問題。其實這也是一種不作為。
一頭獅子佔領了一個山頭，這就是它的領地，其它獅子就不能進來了，進來了就是侵犯我的領地。陣地作戰，大家的目標都是一致的，那就是贏。有利於目標達成的，都可以去實施都可以去幹。所以團隊要強調有陣地意識，沒有領地意識。
3. 一鍵搭建環境
環境的搭建必須方便、快捷，這樣才能提高所有產研團隊的效率。但是很多公司在這一塊都很薄弱需要改進。很多公司生產環境都治理得不是很好，何況開發和測試環境。
一個業務的環境不能只有幾個人能搭建出來，不能手動修改很多設定才能跑，這樣做是十分危險的。這個時候我們需要一鍵可以把環境拉起來且可以使用，使用完畢後即可釋放的功能。哪怕用 Jenkins 搞定也可以，但必須要快、可重複、可重現。
我們的作法：
- 首先，我們使用 k8s 搭建了一個資源能自動伸縮的底層基礎設施
- 其次，我們自己的應用中心有環境搭建所需要的各個服務的定義
- 接著，我們還有各個服務對應的編譯、構建、部署流水線
有了上面的條件，我們就可以一鍵把涉及的所有服務程式碼下載、構建後自動部署、部署後服務啟動、自動檢測、接入監控紀錄檔告警，接入服務大盤。
說一千道一萬，光有好的規範機制是不行的，還是要落到實處，需要平臺來落實它、承載它；平臺有用、易用又能更好支援規章制度。
4. 專人維護
比環境搭建還困難的就是環境維護。環境搭建出來只是一時之功，但是要想讓一個環境能起到作用，隨時可用，日常的維護是必不可少的。比如更新應用的版本，更新組態檔，更新資料庫表結構，刷資料庫中的資料。有的人想用但是沒能力沒資源維護，有的人能維護但是業務壓力大沒時間沒動力去維護, 不出幾天環境就不能用了。如果想用，又得花費很大的工作量去修復或者重新搭建。
我們開發環境主要是研發同學維護，測試環境都是QA小夥伴維護。因為一鍵可以部署出環境，所以是誰搭建也就無所謂了。極大減少了搭建耗時，提高了工作效率。
5. 資源獨佔和泳道相結合
資源複用這個問題只有環境大量的被建立和使用，現有的資源無法滿足需求的時候才會有環境複用的煩惱。目前大多數公司（99%）的公司還都沒有這個煩惱，因為這些公司的難點還在建立、維護環節；但是剩下的那1%的公司一旦有這個煩惱就是個大煩惱。
- 現在的環境已經佔用了太多的資源，不能再採用獨佔的策略了。
- 公司的業務太複雜了，已經很難重新搭建出一套完整的環境。
- 依賴的服務已經超出了使用者可維護的範圍，使用者已經無法維護依賴的環境了，需要交給服務所有者來維護。
小業務簡單服務獨佔環境
小業務的環境好搭建且獨享，易用好用，缺點就是犧牲了一些資源，服務無法複用。我始終認為只要環境可以快速建立、快速驗證、用後即焚，獨佔的環境是最理想的。不用過多的流程審批、協調方面的管控。
大業務複雜業務複用環境：
之所以想複用環境，是因為業務比較複雜，尤其是微服務架構下服務個數多，呼叫鏈路長，我們已經無法把所依賴的環境全部快速搭建出來，且設定完畢後能正確存取，我們只能依賴於其它方來維護這些環境，而我們對其形成依賴。另外一個原因就是這些被依賴的服務本身依賴和部署做的十分糟糕，無法可以通過一種簡單的方式部署且能快速啟動，裡面可能在程式部署後還需要大量的手動操作。
現在比較成熟的是泳道。阿里、美團等公司內部都有自己的內部實現。大家可以深入瞭解一下。
對服務鏈按需求進行分組複製，並實現邏輯、物理的隔離，使得不同需求的服務鏈執行在相隔的物理機器上，邏輯上如同游泳場中的泳道。
當然泳道也不是完美的解決方法，對業務有侵入，且中介軟體也需要很好的處理和配合，才能讓泳道發揮作用。
本文小結
本章主要講述了環境的分類，環境建設過程中的難點和環境建設的最佳實踐。環境建設是一個非常見功夫的事情，需要大量的人力物力長期的投入，不是一朝一夕就能完成的事情。放眼望去，國內能做到各種環境一鍵拉起即用的少之又少。這也給了我們一個很大的提示，這裡有很大的空間，大有可為。
如果各位也有這方面的問題，歡迎和我們聯絡，關注scmroad，大家一起交流溝通，共同進步。