共享而非暴露:測試雲端正在被重新定義

裝置雲的演進:從公有雲到私有雲再到共享雲

身為產品經理,負責在公司內部交付管理功能 Digital.ai 在測試平台方面,我以一個特定的視角看待基礎設施:可用性和控制力之間的平衡。我扮演的角色是雲端管理員,也就是把關人。管理員負責分配資源、管理使用者權限,最重要的是確保測試團隊在需要時能夠獲得所需的資源。

多年來,我們的產業發生了翻天覆地的變化。我們從完全掌控實體硬體轉向了公有雲的極致靈活性。但這兩種極端都未能解決根本問題。如今,我們正在探索一條不同的道路,挑戰產業長期以來所奉行的二元對立的錯誤觀念。

未來並非要在「封鎖」與「全面開放」之間做出選擇,而是存在第三種狀態: 共享實例

讓我來告訴你我們是如何走到這一步的,以及為什麼這種差異比大多數商家願意承認的更重要。

第一階段:「硬體擁抱」時代(企業內部與本地部署)

我們都記得傳統的模式:公司內部的設備實驗室。 USB 線蜿蜒在桌上。行動裝置的電池鼓脹,每六個月就得更換一次。手動更新作業系統往往要耗費整個下午的時間。還有那台在其他所有裝置都淘汰之後還能用的 iPhone 6。

這種切實可控的感覺確實令人滿足,你可以直接走過去拿起故障設備進行排查。但操作上的負擔卻極為沉重。

對於我們那些注重安全性的客戶,特別是銀行和國防產業的客戶,我們最終採用了正式的本地部署和實體隔離解決方案。在這些方案中,基礎設施完全隔離,因此資料始終處於完全控制之下。

設備絕不會連接到公共互聯網。測試資料絕不會離開建築物。

為什麼會出現這種情況

處理金融數據的銀行應用程式、管理患者記錄的醫療保健應用程式、包含機密資訊的政府應用程序,這些都無法在幾個小時前其他公司可能使用過同一設備進行測試的基礎設施上運行。

業界給出的答案很簡單:“這些設備完全屬於你,獨立放置在你的環境中。其他人不會接觸它們。”

這解決了實際需求。

  • 對處理受監管或機密資訊的應用進行設備和資料的完全隔離
  • 根據內部安全、網路和合規性要求客製化基礎架構配置
  • 保證資料駐留和主權,不依賴共享的公共資源
  • 適用於完全無法連接到公共互聯網的環境的實體隔離部署

由此產生的問題

但我在管理這些環境的過程中觀察到:這解決了安全問題,但卻產生了一個新的問題——經濟問題。

  • 總成本高各組織花費大量時間、資源和金錢來維護基礎建設。
  • 取得新設備的速度慢我親眼目睹客戶在iPhone 15發布後苦等三個月才得以進行測試。購買需要管理層批准,採購部門下單,IT人員配置並添加到實驗室。同時,他們的用戶已經在最新的iPhone上下載他們的應用程式了。

本地部署為企業提供了所需的安全性,但成本無法隨著設備覆蓋範圍的擴大而擴展,也無法跟上市場碎片化的步伐。

然而,對於真正敏感的工作負載,這種觀點仍然成立。實體隔離和本地部署解決方案不會消失,它們對於機密資料和受法律限制的場景來說是必不可少的。但它們不應該成為滿足所有測試需求的預設選擇。

第二階段:SaaS 分岔(公有雲與專用雲)

隨著市場轉型為SaaS轉型,它分裂成兩種非此即彼的選擇。這兩種選擇都無法完全滿足現代企業雲端管理員的需求,他們需要在安全性、覆蓋範圍和成本之間取得平衡。

方案一:公有雲

公共設備雲的出現是為了解決一個在經濟上變得不可能解決的問題:開發者買不起用戶擁有的每一台設備。

設備以先到先得的方式動態分配,控制有限,平台所有客戶共享。

為什麼會出現這種情況

2010年代初期,行動平台碎片化問題急遽惡化。安卓系統每季都會推出數十款新設備,而iOS系統每年都會推出新款機型。對於除規模最大的企業之外的所有企業來說,在實體設備上手動測試應用程式的成本已經高得令人難以承受。

公有雲帶來了一項突破:無需購買硬體即可即時存取數百台裝置。

按需付費,無需設置,只需點擊即可測試。

對於新創公司和快速發展的開發團隊來說,這具有變革性意義。

這解決了實際需求。

  • 無需購買和維護實體設備實驗室
  • 無需設置或基礎設施規劃,即可快速、按需驗證。
  • 即使預算有限,也能經濟實惠地獲得廣泛的設備覆蓋範圍

出現的局限性

但隨著企業採用這些平台,有些問題也隨之出現,我在與客戶的對話中反覆聽到這些問題:

  • 有限的控制“我們的應用程式需要特定的 VPN 和網路配置才能連接到內部環境。公有雲設備依賴標準化的網路設置,而這些設置不支援這種配置。”
  • 可用性問題“蘋果發布新款iPhone時,需求會立即激增。在關鍵的測試窗口期,我們最終都得排隊等候。”
  • 合規差距“我們的安全團隊審查了該架構並予以否決。對於處理敏感財務數據的應用程式而言,多租戶公共基礎設施是不可接受的。”

公有雲使行動測試普及化,但它們並非為滿足企業安全和控制要求而建置。

方案二:專用雲

為了解決安全漏洞,業界將專用(私有)雲端服務標準化。這種單一租戶環境的設備僅供單一客戶使用。

專為單一客戶預留的設備,提供完全控制,無需管理實驗室基礎架構。

這解決了實際需求。

  • 存取專為您的組織提供的私人單一租戶雲端環境。
  • 透過完全隔離滿足安全和監管要求。
  • 完全掌控設備和配置,以優化測試方案。
  • 降低與實驗室維護、升級和IT管理相關的營運成本。
  • 這為企業提供了所需的安全態勢,但也繼承了本地部署解決方案的一些經濟問題。

出現的局限性

  • 專用設備的持續高成本導致設備多樣性有限,測試覆蓋範圍不完整。
  • 設備分配限制,尤其是在發布前測試或設備特定調試等高峰期,會降低測試靈活性,並可能導致發布延遲。

脫節之處:客戶真正需要的是什麼

到那時,我們只剩下兩個極端選擇:

  • 公共價格實惠、易於取得、設備覆蓋範圍廣—但有安全隱患和控制有限。
  • 專注安全、可控、合規性-但價格昂貴且設備種類有限。

但當我與客戶坐下來詢問他們實際的測試工作流程時,他們所描述的需求既不屬於上述任何一種極端情況:

「我們的 CI/CD 管線每小時在 50 台設備上運行功能測試。我們需要這些測試在我們的私有網路和 VPN 配置下運行,快速執行,並在不同的測試套件中復用設備配置。公有雲不支援這些要求,而專用設備的成本又太高,難以擴展。」

“我們使用專用設備,利用真實客戶數據進行生產測試。但到了開發階段,我們的團隊只需要在各種設備上快速驗證錯誤修復即可。他們不需要專用資源,只需要覆蓋範圍。”

模式很明顯: 客戶需要介於公共和專用之間的服務。.

他們需要:

  • 共享基礎設施經濟模式,按需存取設備
  • 廣泛的設備和作業系統覆蓋範圍,可與公有雲媲美
  • 企業級安全性和隔離性,無需獨佔設備所有權
  • 完整的網路控制,包括 VPN 和站點到站點配置
  • 可靠地執行大規模測試套件,無需在運行之間進行中斷性的設定或拆卸。

業界一直把這個問題看成是非此即彼的選擇。這種看法是錯誤的,而我們也正是從這裡開始建立不同的解決方案。

第三階段:私有雲中的共享裝置-第三條道路

這是哪裡 Digital.ai 測試XXXXXXX 過去幾年,我們一直專注於創新。這並非為了標新立異而標新立異,而是因為我們傾聽了客戶的實際需求,並致力於解決真正的問題。

這意味著什麼

設備以先到先得的原則動態分配,但與公共設備相比,具有更高的控制性和靈活性。適用於執行大型測試套件、需要特定配置(例如,使用與專用設備相同的 VPN 配置)以及需要不間斷使用的場景。

既能享受共享環境的經濟效益,又能獲得私有環境的安全保障。

為什麼會出現這種情況

三種因素共同作用,使得這種模式既成為可能又成為必要:

1. 雲端安全技術已成熟

私有雲架構發展到一定程度,我們能夠在多租戶基礎架構中實現真正的隔離。即使底層雲端基礎架構是共用的,您的裝置、網路配置和資料也與其他客戶完全隔離。

這種程度的隔離在 2015 年還無法可靠地實現。但現在,它已成為企業雲端架構的標準配置。

2. 成本壓力加劇

團隊希望在獲得同等安全保障的同時,也能實現更經濟高效的部署。以往「因為安全需要」的回答已經無法令人滿意了。

3. 測試需求多樣化

如今的團隊不再只有一種類型的測試,而是有多種工作負載,每種工作負載都有不同的要求:

  • 使用真實客戶資料進行高安全性生產環境測試(需要專用資源)
  • 使用合成資料進行大規模 CI/CD 功能測試(優先考慮規模和覆蓋範圍,而非排他性)
  • 對數百種設備和作業系統組合進行廣泛的兼容性測試(僅在專用設備上進行測試在經濟上不可行)
  • 日常開發中對錯誤修復進行驗證(需要快速存取和多樣化,不保證可用性)

無論是公共的還是專用的,一刀切的基礎設施都無法反映當今實際的測試方式。

這對您的測試策略意味著什麼

如果你現在正在評估設備雲方案,我建議你完全拋棄「公有雲 vs. 私有雲」這種二元對立的框架。這種框架已經過時,無法反映現代測試的實際運作方式。

相反,決策應該基於團隊的實際運作方式。為了幫助你找到答案,以下是一些值得思考的問題:

1. 您實際的工作量需求是什麼?

  • 所有工作負載都處理敏感或受監管的資料嗎?還是只有部分工作負載處理敏感或受監管的資料?
  • 您是否需要保證設備始終可用,還是僅在特定時間內可用?
  • 你們的測試依賴持久的設備配置,還是每次運行都需要乾淨的環境?

大多數團隊在真正制定計劃時,都會發現他們的情況比較複雜。

2. 能否依安全要求對工作負載進行劃分?

  • 高安全性 → 專用 SaaS 或本地部署(生產資料、受監管或受限應用程式)
  • 中等安全級別 → 私有實例中的共用裝置(功能測試、CI/CD、相容性)
  • 低安全性 → 私有實例中的公用或共用裝置(早期開發、非敏感驗證)

關鍵要點:並非所有測試工作負載都需要最高安全等級。

結論:演進而非革命

從公有雲到私有雲再到共享雲的演變並非廠商為了創新而創新所驅動,而是由產業無法忽視的客戶需求和市場力量所驅動:

在私有 SaaS 環境中共享設備的出現,是因為企業需要在不可忽視的經濟因素、不可或缺的設備多樣性測試以及不可犧牲的安全性之間取得平衡。

At Digital.ai 透過測試,我們了解到,設備雲端基礎架構的未來不在於選擇單一的部署模型,而是建構足夠靈活的架構,以便將不同的工作負載匹配到合適的層級,而這一切都在一個安全合規且雲端管理員能夠真正管理的環境中進行。

真正的問題從來都不是“公立還是私立?”

真正的問題是:“我們如何在不洩露數據或超出預算的情況下,為測試團隊提供他們所需的測試覆蓋範圍?”

這就是「共享而非暴露」的意思。而這正是我們正在建構的未來。

你可能還喜歡