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

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

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

1. Deploy 之前要有Artifact、Provisioning、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 設計不良、架構沒彈性、效能不佳 … 等。

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

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

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