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 該具備的軟硬技能，請參閱： Software QA 的職能條件

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

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

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

認知差異

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

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

測試種類、策略介紹參閱：淺談軟體測試的階段與策略

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

Deploy 之前要有 Artifact、Provisioning、Config
Build 之後不是 Test，而是 Deploy
沒有 Deploy 的測試，請問是誰 Deploy？
這個 Deploy 的人知道測試的目的與策略？
能獨立 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 呢？根本不用插手，前面就爛了。

結論

莫名其妙就寫了一大堆，重點以下：

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

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

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

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

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

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

左環的問題

測試前的準備工作

認知差異

誤區與問題

系統性測試

專業之死

結論

相關文章 (站內)

延伸閱讀

Comments

About

著作

演講

Facebook

AWS Certifications