1.概述

　　曾幾何時，開發測試是雲平臺切入企業市場的第一個應用場景 ，主要的原因是：一方面，這個場景下對高可用的要求不高（說白了就是，那時企業還不相信雲平臺能挑大樑、跑生產系統）；另一方面，開發測試工作中環境變化比較頻繁，雲平臺的“模板”能力正好可以有效降低運維部門的重複勞動。

　　而實際上，對於管理成熟度高的企業來講，IT系統在正式上線前需要經過，開發、測試、QA、UAT等多個環節，而這些環節的效率將直接影響業務上線時間和後續的質量，可以說與業務成功密切相關。

　　近年來，隨著網際網路產品快速迭代模式對傳統企業研發的影響，一些新型有效的理念思想被引入，如：敏捷開發、微服務、持續繼承／交付／部署等，這些思想的背後理念和採用的新技術，也對開發測試這項工作本身提出了更高的要求。

　　通過對品高雲客戶的開發測試需求場景的梳理，發現客戶的主要需求集中在：快速環境獲取、模擬生產環境、運維自動化、更低成本以及對新技術的支撐等5方面。

2. 快速獲取環境

2.1.經典場景

• 開發/測試人員（威逼利誘）：系統已經開發完了，請儘快提供測試裝置呀，不然業務上線晚了，領導該不高興了。要不你先把暫時不用的裝置給我用下？很快就還給你，到時請你吃飯。

• 運維人員（心若止水）：半天后回覆……，這個已經被其他專案組佔用了真沒空閒資源了，再說專案都是平等的，我優先給你了，別人也不高興。

• 開發/測試人員：我需要的環境是4CPU的伺服器2臺、裡面是RedhatLinux、Websphere7.0以及Oracle11g。

• 運維人員：硬體資源是現成的，但標準模板中沒有11g，如果要我們安裝要等2天。

2.2.需求分析

• 企業測試資源有限，但並沒有合理分配

• 資源有空閒，但沒有被及時回收

• 運維人員真忙，不可能事事快速響應

• 硬體/VM模板固化，不可能軟硬體按需搭配

2.3.雲平臺的應對策略

• 資源統一管理，通過配額（雲中的虛擬貨幣）平衡資源分配，避免惡意佔用。

• 專案模式管理，設定資源週期和SLA，定期回收和存檔。

• vm硬體和軟體模板分離，開發/測試按需選擇。

（圖：雲平臺中專案化的配額管理）

（圖：常用軟體模板管理）

3.模擬生產網路環境

3.1.經典場景

• 運維人員：你這個系統打不開頁面，到底有沒有認真測試呀？

• 開發/測試人員：在測試環境中明明好好的。

• 運維人員： 跟蹤了下錯誤，發現程式碼中連線資料庫的地方，沒有從測試改為生產IP。

• 開發/測試人員：抱歉抱歉……馬上改。

3.2.需求分析

• 為了統一管理和網路隔離，生產與測試環境的IP和子網不同

• 由於子網不同，應用不能配置一套搞定

3.3.雲平臺的應對策略

• 通過實施SDN架構，讓網路和網路功能可以“虛擬化”，並按需編排

• 之後通過VPC功能（虛擬出多個相同的網路），讓開發測試也用生產環境的IP配置。

（圖：用SDN架構構建多的虛擬網路VPC）

4.運維自動化（持續部署）

4.1.經典場景

• 運維人員：你們測試怎麼需要8臺伺服器這麼多？

• 開發人員：系統有負載均衡、前端、中介軟體、資料庫等多個模組需要組成叢集，短期千萬別剷掉，好不容易搭建起來的。

• 測試人員：版本有大bug需要重新部署。

• 開發人員：啊？那要再多等幾天……。

• 開發人員：測試伺服器藍屏了，我覺得是你提供裝置或網路的問題

• 運維人員：你舉出證據來？

• 開發人員：我發現你沒有給OS打最新的驅動補丁

• 運維人員：我只是按照你要求給環境，你又沒提這個需求

4.2.需求分析

• 多機環境軟體多樣複雜，難以自動化保證效率

• 人工操作出問題後，權責和問題難以界定

4.3.雲平臺的應對策略

• 提供雲資源編排和應用自動化交付技術，讓“大”環境部署自動化

• 顯性化交付步驟每個指令環節，讓“自動化”更透明。

（圖：通過部署藍圖實現自動化運維）

5.更低成本

5.1.經典場景

• 運維人員：領導，我們的業務欣欣向榮，明年預算需要多買一些伺服器，尤其是SAN儲存要擴容了，vm佔用空間太大了！

• 領導：SAN這麼貴，開發測試就用單機硬碟吧

• 運維人員：單機磁碟容易壞，測試環境出如果硬碟出問題也很麻煩

• 領導：哦，那就用SAN吧

• 運維人員：現在的SAN都沒空間了呀

• 領導：賣賣賣

5.2.需求分析

• SAN儲存可靠性高，但昂貴

• 物理伺服器本地硬碟多便宜，但可靠性不高

• 虛擬化之後，vm數量增多，佔用空間線性變化快，儲存成本直線上升

5.3.雲平臺的應對策略

• 實施計算儲存一體化（超融合）架構，充分利用分散式計算+分散式儲存的價效比高的優勢

• 實施二級儲存架構，讓SAN作為高效能業務專享、分散式作為普通業務使用，互為備份

(圖：在雲節點中構建分散式儲存，並且支援多類儲存並存)

6.新技術的挑戰

6.1.經典場景

• 開發人員：現在微服務挺流行，我們要引入這種模式，並且基於docker來做持續整合

• 運維人員：別，我們以前沒做過這方面運維，出了問題找誰問？

• 開發人員：docker廠商說需要新環境來部署環境

• 運維人員：又要採購伺服器？

6.2.需求分析

• 新技術和新思維，受限運維技能堆疊，無法敏捷響應

• 新技術不一定能夠保證自身的安全、可靠性

• 新架構可能需要“新環境” ，原有資產難以保護

6.3.雲平臺的應對策略

• 雲平臺自身提供針對docker等新技術的圖形化、自動化功能，降低運維人員上手難度。

• 可利用已有的雲基礎設施，交付新型PaaS技術。這樣底層網路、安全和彈效能力可以複用。

• 需提供開放的API和元件架構，可以快速接入新技術

（圖：雲平臺提供ECS容器服務）

7.收益總結

　　隨著敏捷開發、微服務等“網際網路＋”思維方式和技術的引入，企業的開發測試工作，勢必對運維技術在成本（降低）、效率（提升）、可用性（增加）和效果（顯性化）等方面提出更高的要求。而開發測試雲的引入，也通過快速的環境獲取、能夠模擬生產網路環境、運維自動化、更低的成本以及從容面對新技術的挑戰等方面，更好的輔助企業完成這一生產執行前的最後一道關鍵工序。

　　當雲平臺有效支撐企業完成開發測試這一工作後，企業也開始對於雲端計算所帶來的“效率”提升建立了信心，同時由於“持續交付和繼續整合”的需要，測試階段都自動化了，那麼下一步，自然是生產執行的自動化支撐。而實際情況下，企業對雲端計算在這一場景下的需求，不僅僅是“效率”這麼簡單，而是另有更高、更苛刻的要求。