DevOps 8 字環的誤區:左環問題


本文整理 2018/12/07 我寫的一篇論述:DevOps 8 字環的誤區。


左環的問題

這張 DevOps 很有名的 8 字圖,我不只一次說過這張圖有問題 (因為出處是某些大神),但很少人可以了解有問題在哪。

先講結論,我認為的問題在於:

Build 的下一個不是 Test

當然我知道這只是圖示,為了方便表示,可能因此 省略 很多細節。但是就是這個省略,透過網路的傳播,以後都真的省略了。

測試前的準備工作

在開始說明圖中的誤區之前,整理測試前要知道的事情。

在我的觀念裡,Deploy (or Installation) 是測試人員的第一個 必備硬技能 (軟技能則是:溝通技巧與問題分析能力)。不管是 backend, frontend, desktop application。不包含 Deploy Strategy (Blue/Green, Canary, A/B …) ,這段通常會跟 Dev / Ops 合作,或者整個團隊一起來。

測試或者 QA 該具備的軟硬技能,請參閱: How to be an SQA?

以現代服務導向的架構來看,至少會有 Web/App + Backend 三大部分,所以測試前要準備些什麼?我覺得要完成以下必要的條件:

  • 確認準備測試的 版本編號 (SemVer)
  • 確認可以 Build 出 Artifact 位置
    • Build 的依賴有沒有需要調整或者刪減
    • Artifact 存放的位置與資訊
    • App Build 的方式
  • 確認環境是否可以重新 Provisioning
    • 有沒有新增角色、如何部署
  • 確認 Config 的必要依賴資源、資訊是否完整
    • 確認相關服務的 endpoint
    • Funciton 有沒有新增參數、第三方依賴
    • 參數的預設值與邊界值

這些資訊,通常是由 PM / Tech Lead / QA Manager 一起確認,如果有使用第三方資源,甚至要先去採購。最後這些資訊都要被統籌管理,屬於企業資產的一部分。

認知差異

關於測試,後來發現一個認知上的差異在於:

  1. 大部分 (> 95%) 的人認為:測試只有測 商業功能,不包含系統 (或稱非功能)
  2. 我認為的測試:不只是測試功能,還包含非功能、系統、效能
    • 其中非功有幾件很重要的任務叫做:ArtifactProvisioning、Deployment
    • 在用 Open Source 的時候 (Redis, Kafka …),文件裡有很多效能指標、部署策略,這些東西怎麼來的?
  3. 測試種類以及目的會隨產品特性以及開發方法有關係,所以必須要搭配 測試執行策略 做選擇以及調整

測試種類、策略介紹參閱:Stages in Software Testing

回到八字環,我認為的誤區、有問題的第一個點是左環 Dev 裡 Build -> Test 的部分,缺少的補充如下:

  1. Deploy 之前要有 ArtifactProvisioning、Config
  2. Build 之後不是 Test,而是 Deploy
  3. 沒有 Deploy 的測試,請問是誰 Deploy?
  4. 這個 Deploy 的人知道測試的目的與策略?
  5. 能獨立 Deploy,就知道 Artifact、Config,然後才有 Testable 可言,才有測試策略

換言之,測試者無法自行部署的應用程式、自行配置 Config,等於無法了解應用程式在系統的狀況,狀況包含系統架構、版本資訊、資料庫 DDL、Init Data、第三方倚賴,無法自行建立測試資料,這種測試,等於沒有測,或者沒有意義。產品上線後,隨著時間越久,這種問題會越來越嚴重,最後 QA 會越來越沒價值,然後上面就會說:請工讀生就好。

這張 8 字循環,表達的大方向沒有錯,但是卻因此弱化了測試該要有的資訊,間接誤導很多人。

誤區與問題

因為觀察到普遍的團隊 (> 90%) 認為,測試只有商業功能需要測試與驗證 (Functional Verification Test),而非功能性是維運團隊、或者是開發人員的任務。所以在開發過程,很多團隊 (>80%) 的做法是:

測試環境的部署都是透過 Pipeline (e.g., Jenkins, Gitlab CI) 部署

而 Jenkins 的 Job 是由開發 or 維運團隊負責,換言之測試者完全沒這方面的能力或者主控權。或者部署 DB Schema 權限都在 Dev 手上,最後問題就是 Dev 聲音很大,QA 沒聲音。測試環境的 Baseline 紊亂,或者沒有 Baseline。Baseline 就可以以從無到有建置的標準方法。

恩,這件事對我來說是不可思議的,而我這樣的想法,對很多人來講是不可思議的。所以導致大部分測試工作 在一般人心裡會覺得取代性很高、沒有價值。

系統性測試

很多問題,不管是商業需求的問題、還是系統架構面的問題,都是可以再上線前探索的。聽過很多人會說,很多問題要上線後才能知道,或者模擬。實際的問題在於規劃不清楚,上線後錯誤的資料造成 連鎖效應 (SRE CH22) 導致。這段只要 Unit Test、整合測試、系統測試有執行,是有辦法找的。而線上問題,要可以搬回線下驗證,特別是 Priority 不高,但是 Severity 很高的問題,這種情境有沒有?有,很多,特別是產品上線 兩年後 會爆多,簡單講:重要不急的問題。

測試是產品開發出來後,第一個完整的使用者,特別是這年代所謂的功能是要:Web/APP + Backend 才算功能,IoT 還要加 Devices 共三方。

底下截圖是我在 社群的分享,核心概念就是可測性依賴環境建置與部署的標準化:

更多系統測試參閱:輕鬆聊:系統測試 (SVT) 的三兩事

專業之死

另外這年代強調團隊,弱化個別職能,很多人會說:這就找 Dev 來一起弄就好,QA 幹嘛搞這個。問題就來了,沒 Sense 的 Dev,不會把架構弄好,不會設計 Config or 做 Artifact,做出緊耦合、強依賴的 Pipeline,最後只會讓整個服務卡死在 Dev 手上。而 QA 開的 Defect 不是只有商業功能的問題,還包含 Config 設計不良、架構沒彈性、效能不佳 … 等。Ops 呢?根本不用插手,前面就爛了。

結論

莫名其妙就寫了一大堆,重點以下:

  1. Build 之後不是 Test,而是 Provsioning -> Deploy
  2. 測試種類很多,他們有不同的策略與考量
  3. 線上重要不急的問題,要可以線下驗證以及改善,特別是嚴重、不緊急的問題
  4. 環境建置 是一個工程團隊該有的基本素養
  5. 建置環境的前提是架構要清楚
  6. QA 開的 Defect 不只有功能的問題,還包含 Config 設計不良、架構沒彈性、效能不佳 … 等。

在地表上,除了太空船,沒有不能測的。

因為看過太多錯誤的認知與觀念,因為某某大神照本宣科,大肆宣揚此圖,加上沒有深度的思考,錯誤的觀念在網路上廣為流傳,一錯再錯。

用 『持續交付 2.0 讀書心得 』的探索環來說明,我想強調 部署測試 的重要性。換言之,怎麼部署,不應該再八字環右邊才發現。

所以這張圖不只左環有問題,右環也有問題:Deploy 前後也不是那樣的。


相關文章 (站內)

延伸閱讀


Comments