“誰把我的環(huán)境給重新部署了？”

“我的環(huán)境里邊的數據怎么不對了？”

“誰能幫我把線上的配置同步一下到線下？”

環(huán)境管理是我們日常工作中比較復雜的一環(huán)，主要是因為涉及內容比較多，程序、配置、數據都會涉及，如果是開發(fā)、測試環(huán)境，還會涉及到測試數據造數、系統刷數據、不同的人使用、鎖定、轉讓、釋放等問題。下面我將會從環(huán)境分類、環(huán)境建設的難點，以及最后如何解決這些難點來講述研發(fā)效能之環(huán)境建設。

環(huán)境的分類

網絡類型環(huán)境

從網絡環(huán)境的可訪問性區(qū)分，研發(fā)效能涉及以下三種環(huán)境：

 

• 辦公網絡環(huán)境：公司的內部辦公網，也是管控相對比較寬松的網絡，可以訪問外網。因為部署了各種內部服務，網絡環(huán)境相對比較復雜
• 測試網絡環(huán)境：用于部署各種測試服務，包括研發(fā)測試用的環(huán)境，也包括QA的測試環(huán)境，可以進行功能測試，也會進行壓力測試等，一般都可以和辦公網相通，但不與外網互通。
• 線上網絡環(huán)境：與辦公網、測試網絡隔離，一般不能訪問辦公網絡環(huán)境和測試網絡等環(huán)境。

IT、運維和安全的小伙伴一般更愿意從網絡的可訪問性去劃分環(huán)境，因為這樣可以劃分資源、設置訪問策略、進行安全檢測等。

用途劃分環(huán)境

對于產研團隊來說，我們通常從環(huán)境的用途來劃分環(huán)境，一是和自己角色相關，研發(fā)用研發(fā)環(huán)境，測試用測試環(huán)境；二是通過用途區(qū)分好理解。至于能否打通，是否受限一般由底層基礎設施團隊來維護，大家都不太關心。對于我們研發(fā)效能團隊來說，我們一般會維護一張各個環(huán)境互聯互通、安全網絡策略的表格，讓各方心里都有數。萬一出現訪問性的問題，相關人員也能自己排查。

 

• 開發(fā)環(huán)境：一般用 dev 標識，用于開發(fā)人員編寫代碼、調試程序，配置可以比較隨意，開發(fā)調試方便為主，開啟調試模式。代碼極其不穩(wěn)定。
• 聯調環(huán)境：因為聯調環(huán)境通常是相對比較穩(wěn)定的一個開發(fā)環(huán)境，所以通常也是用 dev 標識，主要用于前后端聯調接口，通常部署接口相對穩(wěn)定下來的代碼。
• 測試環(huán)境：一般用 qa 標識，這個環(huán)境通常用于測試人員功能測試、缺陷回歸。配置盡量和線上環(huán)境保持一致。部署要驗證的相對穩(wěn)定的代碼，而不是最新的代碼。
• 預發(fā)環(huán)境：一般用 pre 標識，用于最后確認功能。一般都直接采用線上的配置和數據，但是僅限確認功能的人使用，不對用戶開放。使用時一定要注意以免臟數據產生，影響正常服務。部署經過 qa 驗證要上線的代碼。
• 驗收環(huán)境：即用戶驗收測試環(huán)境(User Acceptance Testing)，一般用 UAT 標識，通常是由最終軟件的用戶進行的測試，因此是面向最終用戶的測試，結束之后通常就可以發(fā)布生產環(huán)境了。部署經過 qa 驗證要上線的代碼。
• 生產環(huán)境：一般用 prod 標識，部署經過測試、確認的代碼，通常不用于功能測試，不開啟調試模式。AB測試一般在生產環(huán)境下，而隔離比較好的情況下，也可以做性能測試和壓力測試。

集成測試環(huán)境，有的行業(yè)也稱之為SIT 環(huán)境（system integration test），而我們更愿意稱之為 QA 環(huán)境，簡單明了且無需解釋，大家都能了解。用 SIT 有很高的解釋成本；同理預發(fā)環(huán)境，也有人用 staging 環(huán)境，但總覺得沒 pre 更加簡單，且能讓更多的人了解其用途。 另外一個角度就是，我們公司里大家建設的環(huán)境名的統計數據也支持了我們的想法，qa 環(huán)境比 SIT 環(huán)境數多，pre 環(huán)境比 staging 環(huán)境多。

環(huán)境建設的難點

環(huán)境建設主要涉及資源、負責人、建設和維護四個方面，當然難點也主要在這四個方面。

1. 缺少硬件資源

很多公司之所以沒有開發(fā)、測試環(huán)境是因為沒有硬件資源。沒有充足的資源搭建測試環(huán)境，這是環(huán)境建設的第一個難點。尤其是很多不那么「現代」的公司，比如創(chuàng)建個虛擬機還要申請，走漫長的審批流程，層層審批的。

也有的公司經常把一些配置特別低且過保的機器給開發(fā)測試環(huán)境用，三天兩頭出問題，白白浪費了開發(fā)測試人員的時間。

2. 缺少明確的負責人員

很多公司線上環(huán)境還能保證專人負責，開發(fā)環(huán)境就是員工工作筆記本，幾乎沒有QA環(huán)境。這種開發(fā)、測試環(huán)境缺失的主要問題還是在業(yè)務負責人對自己業(yè)務的理解。沒有意識到開發(fā)、測試環(huán)境建設對研發(fā)效率、生產環(huán)境質量的影響，也沒意識到需要有明確人員負責環(huán)境的建設和維護。

3. 耗時長難搭建

每次搭建都需要研發(fā)同學申請機器，然后手動在機器上一個一個服務的安裝服務，同時還要配置各種中間件，刷入對應的數據等。難搭建耗時長，對于使用方和搭建方都是一種折磨。

4. 缺少后期維護

環(huán)境搭建出來后，因為缺少后期維護，環(huán)境中的服務版本和線上有所差異，但是其他人又不知道如何更新；線上數據庫表結構變化了，也沒人同步到線下；某些線上功能，甚至在測試環(huán)境都無法回歸驗證。慢慢環(huán)境就會變成無法使用狀態(tài)，于是開啟了又一輪搭建環(huán)境的痛苦過程。

5. 缺少復用

假設一個業(yè)務有20個微服務，每個微服務一個容器，那么聯調、測試、預發(fā)、UAT四套環(huán)境都完備至少要80個容器；如果有3個QA同學并行測試，都獨占環(huán)境，那么就要240個容器。這還是微服務較少的情況。如果要是業(yè)務復雜起來，微服務數量增多，實例的副本增多，環(huán)境套數增多，那么就會占用大量的物理資源。

環(huán)境建設最佳實踐

針對以上問題，把我們的實踐分享給大家。

1. 充足的硬件資源

雖然現在硬件相對人工成本來說已經相當便宜，尤其是有各種云資源可以利用，但是不得不說有些公司依然在資源上不愿意投入?，F在一人天500人民幣，可以在某云上買一個2核2GB內存50GB的云服務器使用一年。而500人天，月薪1萬左右，一個應屆生的工資可能都比這還高。如果按照資深工程師去算，更得不償失?，F在和之前硬件價格高企的年代不同了，所以能硬件解決的就盡量不要用人去解決。

前期資源的使用可以粗糙一些，后面可以設置個資源池大家共用，再精細化一點可以針對每個人設置配額。因為每個人使用的資源是不一樣的，研發(fā)可能1-2套環(huán)境就夠了，但是并行測試任務較多的QA小伙伴就會需要更多的資源，這個時候配額的上調又需要個流程來完成。我個人總覺得加上審批流的過程是不完美的。

2. 權責清晰的團隊

想要把開發(fā)、測試環(huán)境建設好，關鍵是要有明確的環(huán)境負責人。以往經驗來看，誰需要、誰建設、誰負責。

• 開發(fā)環(huán)境的第一負責人是研發(fā)同學
• QA環(huán)境的第一負責人是QA同學
• 線上環(huán)境的負責人是團隊所有人員，第一責任人是業(yè)務負責人。我們不能要求業(yè)務的負責人時時刻刻盯著線上環(huán)境，但是我們要求業(yè)務負責人去建立相應的機制、安排合適的資源和人力去保證線上業(yè)務的穩(wěn)定。這也是業(yè)務負責人必須明確的原因之一。

為啥線上環(huán)境的第一責任人是業(yè)務負責人，因為他才能結合多種背景因素做出最恰當的判斷。

舉個例子

之前我們一般都是晚上下班以后、周五下午、周六日都可以上線。如果僅僅是前端問題，甚至中午都可以上線。那個時候，我們每個人回家都是帶著筆記本回去，晚上上完線以后，還要測試，沒問題以后才算完。大家雖然很累很趕很忙，但是有一股勁：這是「我」的產品。

后來產品成了「我們」的產品，「老板」的產品，改成了每周五上線，其它時間除非緊急缺陷修復否則不上線，要去團建不上線，老板沒審批不上線，周末上線擔心發(fā)現bug不上線?？此啤干暇€」規(guī)范了，實則跑不起來也跑不快。大家看似各司其職，實則是守著自己的領地，卻丟了整個的陣地。犧牲了業(yè)務，把業(yè)務中的問題劃歸到「流程」「制度」問題。其實這也是一種不作為。

一頭獅子占領了一個山頭，這就是它的領地，其它獅子就不能進來了，進來了就是侵犯我的領地。陣地作戰(zhàn)，大家的目標都是一致的，那就是贏。有利于目標達成的，都可以去實施都可以去干。所以團隊要強調有陣地意識，沒有領地意識。

 

3. 一鍵搭建環(huán)境

環(huán)境的搭建必須方便、快捷，這樣才能提高所有產研團隊的效率。但是很多公司在這一塊都很薄弱需要改進。很多公司生產環(huán)境都治理得不是很好，何況開發(fā)和測試環(huán)境。

一個業(yè)務的環(huán)境不能只有幾個人能搭建出來，不能手動修改很多配置才能跑，這樣做是十分危險的。這個時候我們需要一鍵可以把環(huán)境拉起來且可以使用，使用完畢后即可釋放的功能。哪怕用 Jenkins 搞定也可以，但必須要快、可重復、可重現。

我們的作法：

• 首先，我們使用 k8s 搭建了一個資源能自動伸縮的底層基礎設施
• 其次，我們自己的應用中心有環(huán)境搭建所需要的各個服務的定義
• 接著，我們還有各個服務對應的編譯、構建、部署流水線

有了上面的條件，我們就可以一鍵把涉及的所有服務代碼下載、構建后自動部署、部署后服務啟動、自動檢測、接入監(jiān)控日志告警，接入服務大盤。

說一千道一萬，光有好的規(guī)范機制是不行的，還是要落到實處，需要平臺來落實它、承載它；平臺有用、易用又能更好支持規(guī)章制度。

4. 專人維護

比環(huán)境搭建還困難的就是環(huán)境維護。環(huán)境搭建出來只是一時之功，但是要想讓一個環(huán)境能起到作用，隨時可用，日常的維護是必不可少的。比如更新應用的版本，更新配置文件，更新數據庫表結構，刷數據庫中的數據。有的人想用但是沒能力沒資源維護，有的人能維護但是業(yè)務壓力大沒時間沒動力去維護, 不出幾天環(huán)境就不能用了。如果想用，又得花費很大的工作量去修復或者重新搭建。

我們開發(fā)環(huán)境主要是研發(fā)同學維護，測試環(huán)境都是QA小伙伴維護。因為一鍵可以部署出環(huán)境，所以是誰搭建也就無所謂了。極大減少了搭建耗時，提高了工作效率。

5. 資源獨占和泳道相結合

資源復用這個問題只有環(huán)境大量的被創(chuàng)建和使用，現有的資源無法滿足需求的時候才會有環(huán)境復用的煩惱。目前大多數公司（99%）的公司還都沒有這個煩惱，因為這些公司的難點還在創(chuàng)建、維護環(huán)節(jié)；但是剩下的那1%的公司一旦有這個煩惱就是個大煩惱。

• 現在的環(huán)境已經占用了太多的資源，不能再采用獨占的策略了。
• 公司的業(yè)務太復雜了，已經很難重新搭建出一套完整的環(huán)境。
• 依賴的服務已經超出了使用者可維護的范圍，使用者已經無法維護依賴的環(huán)境了，需要交給服務所有者來維護。

小業(yè)務簡單服務獨占環(huán)境

小業(yè)務的環(huán)境好搭建且獨享，易用好用，缺點就是犧牲了一些資源，服務無法復用。我始終認為只要環(huán)境可以快速創(chuàng)建、快速驗證、用后即焚，獨占的環(huán)境是最理想的。不用過多的流程審批、協調方面的管控。

大業(yè)務復雜業(yè)務復用環(huán)境：

之所以想復用環(huán)境，是因為業(yè)務比較復雜，尤其是微服務框架下服務個數多，調用鏈路長，我們已經無法把所依賴的環(huán)境全部快速搭建出來，且配置完畢后能正確訪問，我們只能依賴于其它方來維護這些環(huán)境，而我們對其形成依賴。另外一個原因就是這些被依賴的服務本身依賴和部署做的十分糟糕，無法可以通過一種簡單的方式部署且能快速啟動，里面可能在程序部署后還需要大量的手動操作。

現在比較成熟的是泳道。阿里、美團等公司內部都有自己的內部實現。大家可以深入了解一下。

對服務鏈按需求進行分組復制，并實現邏輯、物理的隔離，使得不同需求的服務鏈運行在相隔的物理機器上，邏輯上如同游泳場中的泳道。

當然泳道也不是完美的解決方法，對業(yè)務有侵入，且中間件也需要很好的處理和配合，才能讓泳道發(fā)揮作用。

本文小結

本章主要講述了環(huán)境的分類，環(huán)境建設過程中的難點和環(huán)境建設的最佳實踐。環(huán)境建設是一個非常見功夫的事情，需要大量的人力物力長期的投入，不是一朝一夕就能完成的事情。放眼望去，國內能做到各種環(huán)境一鍵拉起即用的少之又少。這也給了我們一個很大的提示，這里有很大的空間，大有可為。

如果各位也有這方面的問題，歡迎和我們聯系，關注scmroad，大家一起交流溝通，共同進步。