前言
前幾天在某個微信群裡看到有同學在問測試環境治理的問題，正好我在之前的公司負責過相關的技術專案，在這方面有一定的實踐經驗，就解答了她的一些疑惑。
今天看書時候突然想到了這件事，發現這幾年大家都在講測試開發、測試效能、精準測試、敏捷測試、全鏈路壓測等等很多高大上的技術實踐和理念，
但很少有人關注到測試環境穩定性的這種存在於我們日常工作中，困擾我們工作進度和心態的細節問題（至少對於測試同學來說）。
我並不是要表達上述的一些技術實踐空泛或者什麼（我自己本人就一直在寫效能測試&全鏈路壓測和穩定性保障相關的技術文章），
但業內目前確實存在一些為了證明測試價值和在技術鏈上不被鄙視而刻意為之的炫技行為。
目前能搜到或者說我個人看到的關於測試環境穩定性治理的文章，僅有阿里和滴滴在這方面的一些實踐方法論(連結見下方)。
所以呢，這篇文章我不會去講一些看起來很厲害的技術，而是和大家聊聊，我之前負責測試環境穩定性治理時候，面臨的種種問題和痛點，
我是如何梳理和分析，並嘗試去解決這些問題的過程。
附連結：
專案背景和痛點
先交代下背景吧，這樣能更好的理解做測試環境穩定性治理的出發點和治理方案為什麼要如此設計。
我會從業務需求和技術現狀兩個方面來說明當時技術團隊面臨的痛點。
業務需求
當時公司業務處在高速發展期，除了日常的版本迭代之外，同時可能還並行著好幾個獨立專案（其實就是需求排不進版本迭代，需求評審時候被PK掉了，又搞了一個獨立專案的名義進行需求交付）。
由於線上釋出和灰度的時間節點各不相同，且每個獨立專案和日常版本迭代涉及到的業務域以及背後的應用各不相同，有重疊又有新建的服務，因此每個專案都需要不同的測試環境來保證需求交付不受影響。
技術現狀
聊完了業務需求背景，再來看看整個技術團隊和體系當時面臨的問題：
1-整體的需求研發測試交付體系是從Dev-Test-Pre-Pro四個階段；
Dev：即開發環境，一般由開發自己負責日常維護；
Test：測試環境，也是本文的重點討論物件，一般由測試維護；
Pre：即預發環境或灰度環境，是線上正式釋出的最後一個驗證環節；
Pro：我們所理解的生產環境&線上環境，所有外部的使用者都可以訪問；
2-測試環境有十幾套，每套環境幾乎都有獨立的資料來源，且表結構和資料各不相同；
3-所有應用都部署在阿里雲上面，交易業務應用是ECS的虛擬機器，社群業務應用是基於Isito的容器化；
4-有跨境和國際交易業務，是單獨一個BU，但業務邏輯和應用呼叫關係上又強依賴國內的部分交易業務和應用；
5-微服務架構下各服務之間依賴關係複雜，但服務釋出都是不同的測試負責，經常出現A測試同學測試過程中報錯，結果是B同學在做服務釋出。
或測試過程發現異常，排查很久發現原因是做了DDL變更或者測試資料被使用了導致的各種問題；
6-需求越來越多，需要的測試環境越來越多，但搭建一套環境的成本太高，運維不願意聯調，測試不願意驗證，都想要現成可用的東西來完成各自的工單和任務；
面臨的痛點
出於上面的業務需求和技術現狀，對技術團隊來說，最大的痛點有下面幾點：
1-環境太多，雲資源成本和日常維護成本太高；
2-釋出流程太過隨意，訊息不及時同步導致出現各種異常；
3-需求太多導致大部分時間耗費在環境維護和異常問題排查方面；
4-需求多工緊要求更多的測試驗證和維護環境佔用了大量人力和時間資源的矛盾；
5-多套資料來源導致最終線上釋出時DDL變更頻繁，出現缺少欄位或欄位格式不正確等情況；
6-為了保證各自專案的交付，各個專案的Owner甚至開始出現“先上車後補票”搶佔環境的操作；
7-研發和測試都有測試環境的變更許可權，服務的釋出和資料庫的變更不受控制，“走心釋出”隨意而為；
上述描述的現狀和痛點，當時導致了不少的線上故障，最終避無可避的，環境穩定性治理落到了測試的頭上（這裡不討論應該運維負責環境穩定還是誰使用誰負責的話題）。
分析過程及治理規劃
針對上述的種種問題和痛點，我用了一週的時間做調研分析和評估，最終落地了環境穩定性治理規劃和方案。下面是我的分析評估和治理規劃，僅供參考。
調研分析過程
通過調研和訪談以及我自己工作過程中發現的種種問題，我抽象總結出了幾個共同點：
1-環境多成本高維護成本大；
2-造輪子和重複建設現象嚴重；
3-流程不規範且無人遵守預設的原則；
4-環境資源競爭日趨激烈，沒有較好的協調機制；
5-溝通成本大，資訊同步延時高甚至丟包現象嚴重；
6-環境問題發現定位排查手段原始，部分同學缺乏相關技能；
穩定性治理規劃
調研分析出上述幾點共性問題後，我輸出瞭如下的穩定性治理規劃：
|
專案名稱 |
測試環境穩定性治理 |
|
專案目的 |
1-降低測試環境不穩定因素，提升環境可用SLA； 2-讓測試同學有更充裕的時間做自己專業的事情； 3-快速交付穩定可用的測試環支撐業務的快速發展； |
|
專案目標 |
短期目標：規範變更流程，降低維護成本，打通底層資料，變更許可權收口； 長期目標：10分鐘拉起一套新環境，半天內交付穩定可用的測試環境並驗收通過； |
|
專案時間節點 |
整體時間節點：2021年1月1日-2021年6月30日 階段目標Deadline： 規範變更流程：2021年1月31日 降低維護成本：2021年2月28日 打通底層資料：2021年3月31日 變更許可權收口：2021年4月30日 測試環境容器化：2021年5月31日 環境資源下線回收：2021年6月30日 |
落地過程的一些典型案例
測試環境穩定性治理在落地的過程中，做了很多的技術優化以及跨團隊的協調溝通，每個階段都會遇到很多挑戰和問題。
當然，解決問題的過程中，個人也學到了很多新的技能，和不同的角色溝通協調過程中也學會了從不同的維度和角色的角度上去思考解決問題。
下面是六個不同階段中，典型的治理案例和我個人的思考收穫。
1-規範變更流程
這裡的變更除了服務釋出、引數配置的變更之外，還有測試環境的DDL變更。典型的案例有：
服務釋出沒有限制：通過釋出平臺設定服務釋出時間視窗，和各研發及測試團隊協商溝通確認（降低任意釋出帶來的服務不可用）；
任何人任何時間都可以釋出：每個應用或業務域應用合集指定服務owner，服務釋出需要在釋出平臺經過owner二次確認才可以執行釋出流程；
資訊不同步&溝通成本高：建立專項的服務釋出資訊同步群，某應用需要釋出，自動艾特對應的owner進行通知確認（可設定免打擾，但帶來的影響需要owner自己負責）；
收穫：很多時候，運維和DBA也是希望能規範釋出和變更流程的（這樣他們的工單和任務量會減少，能提效）。
但如果業務方不配合，就很難推進。如果涉及到類似的事情，可以找運維和DBA負責人一起協調推動，團結相關的利益團體，反而能提高整體的進度和效果；
2-降低維護成本
環境多維護成本高：收斂環境的數量，將重複造輪子的部分抽象成公用的部分，我當時採用的方案是搭建stable環境，抽取公用的服務和基礎設施，
版本迭代和獨立專案，只需要部署各自涉及的應用（這樣也能避免不同專案遇到公共應用時，便於部署不同分支的程式碼）；
環境資源競爭激烈：版本迭代固定佔用某個環境，獨立專案根據提測時間和上線釋出時間做資源協調。
如果有同一天釋出上線的，根據提測時間，各自拉取對應分支到同一個環境，後續的專案程式碼分支合併到最早提測的分支上進行測試（一方面降低了環境競爭的問題，另一方面測試資源和環境維護範圍更集中）；
Stable環境規劃圖（僅做示意，已脫敏）
3-打通底層資料
前面提到了多套測試環境多套資料來源，這樣會導致下面幾點有趣的現象：
1-多個測試環境的表結構變更，需要提多次DDL工單，DBA同學任務量大；
2-假設測試過程中測試環境切換，變更就要重新進行，很容易遺漏或者變更有誤；
3-即使有專門的測試資料預埋工具，但多環境多資料來源會導致資料準備更耗時，加大複雜度；
4-不同環境不同資料來源，進行自動化迴歸的時候，測試case和資料可能要進行修改適配，耗時費力；
5-即使多個專案同時進行，但最終釋出線上僅是一套環境和資料來源，這樣會導致頻繁變更帶來的線上風險概率；
針對這些現象，我是怎麼做的呢？
首先，選擇一個環境作為基準環境，所有的DDL變更都先變更到基準環境，然後自動變更到其他環境的資料來源上；
其次，stable環境落地，環境發散現象會逐漸收斂，搭建維護變更成本降低後，反而有時間資源做專門的優化工作；
然後，變更許可權和入口收斂，通過統一的工單系統進行，降低整體的變更混亂現象，所有變更有跡可循有記錄可查；
4-變更許可權收口
上面第三部分“打通底層資料”實際上已經介紹過變更許可權收口了，這裡我想分享的是之前做環境治理時候，和DBA負責人的一次聊天過程：
我：XX大佬，我要搞測試環境穩定性治理，希望減少隨意的表結構變更和讓底層資料保持一致，需要你的幫助；
DBA負責人：那可真是太好了，我一直想幹這個事情，但我去推業務那邊一直不搭理我，阻力很大。。。
我：那你看我們合作怎麼樣，我去和業務研發以及測試協調這個事情，你把底層的技術規範搞定？
DBA負責人：沒問題，許可權收口，表結構變更統一走工單，降低變更頻次，規範資料庫和SQL規範，我來搞定；
我：那行，你先準備相關的技術方案和規範，我們先挑一個環境試點，業務方我去溝通，好了我們就開始搞；
DBA負責人：可以，有啥需要我幫忙的儘管說，做這個事情對我們DBA也是個好事情。。。
分享上面這個對話過程，實際上要表達的是：很多時候我們工作中面臨的痛點，也是其他人想解決的問題，尋求利益共同體，協作達成一件事，比孤軍奮戰更輕鬆，達成的效果也會更好。
5-測試環境容器化
談到測試環境容器化，又是另一個故事了。
當時基礎架構一直想推業務線接入容器，但一直很難推下去，理由也很正當：“業務迭代需求太多，沒時間沒資源接，而且穩定性也是要考慮的”。
正好我在牽頭做測試環境治理，希望能快速拉起環境和服務（ECS虛擬機器部署服務太麻煩了，速度還慢），結果聊著聊著，一拍即合。我負責和業務方溝通，基礎架構提供技術解決方案。
這裡要補充說明下，不是我有多高的職位和權利，才能去和業務方溝通。而是測試環境的痛點已經影響到整個技術團隊的需求迭代研發交付了，大家即使不太樂意，但這個問題不解決大家都很痛。
6-環境資源下線回收
按照整體的治理規劃，完成上述步驟後，就可以開始做環境割接，即：
搭建好stable環境，測試環境以容器化搭建，給業務方交付一套可用的測試環境，就下線回收一套ECS的虛擬機器環境。
同時相關的許可權收口以及變更管理規範，溝通協調機制在不斷的落地和推進過程中，也能不斷解決環境使用過程中的種種痛點。
當然，環境割接過程中，有幾個點需要注意：
割接的時間節點需要和運維DBA以及業務方明確，不可隨意下線；
環境割接不可一刀切，建議先關機，觀察一週後再下線，避免遺漏的業務方有依賴而導致其他問題；
環境治理和技術改造方案，在開始前一定要做好調研，堅持推進，否則很容易被遇到的困難和組織架構變更導致專案流產；
7-其他優化手段
整個測試環境穩定性治理過程中，除了上述的一些案例和技術方案之外，還有下面的一些技術優化手段，比如：
1-服務不可用訂閱通知；
2-服務釋出通知功能上線；
3-環境不可用常見問題及解決方案培訓分享；
4-成立專門的虛擬小組，每個域指定負責該域的測試owner；
5-整個各個業務線的自動化測試框架和方式，提供統一的技術方案；
6-測試環境接入日誌監控告警，從服務層-DB層，監控告警做到自動化和透明化；
7-環境和服務不可用時長納入故障SLA計量維度，定時覆盤和分析，並不斷落地改進；
總結回顧
環境治理是個很複雜和碎片化的技術專案，同時也是團隊協調以及人的問題。我要向大家分享的內容總結如下：
核心：定義問題-提出規劃-制定方案-爭取資源-推動落地；
技巧：尋求利益共同體一起協作，主動向上尋求幫助，切忌單打獨鬥；
過程：流程規範-許可權收口-降低block因素-基礎技術設施建設-技術輪子整合-長期堅持演進；
最後
本文最後，為大家分享下我之前的整體規劃落地思路吧，可惜中途由於某些原因離職了，測試環境穩定性治理，沒能繼續推動下去，還是蠻遺憾的。
