分散式程式如何進行線上灰度自動化驗收?
前言
前面在ofollow,noindex" target="_blank">如何負責一個專案的質量保證工作 一文中，筆者將質量保障劃分為三個階段，研發質量，上線質量和線上質量。其中針對上線流程，特別提到灰度階段，QA應該提供相應的驗收機制。今天來具體說說
，針對分散式程式如何打造一個方便好用的灰度驗收工具。
我們知道，絕大多數分散式程式天然的支援灰度迭代，通過有序的, 分批次的迭代上線，能夠有效的控制故障規模，起到釋出中驗收的效果。但即使這樣，如果基礎設施不夠完善，還是沒辦法做到無損灰度的。出了問題，實際仍然是有使用者感知，只不過範圍較小而已。
線上釋出，多數是SRE運維同學操作，他們很有可能不清楚業務細節，比較欠缺驗收手段。多數情況下，釋出部署的同學主要依靠檢視日誌和監控告警手段來驗收發布。但其實這樣非常的被動, 如果是監控告警觸發報障，情況可能還好，運維同學會很快感知，快速止損。但如果是客戶報障，一來一去時間上就會很長，如果稍微影響的客戶多些，就是一例事故。
舉個極端例子，比如一個面向使用者的介面，因為bug導致使用者正常請求在特定場合會返回4xx。如果帶著這種bug去灰度，很有可能監控告警層面不會感知，因為4xx在HTTP協議中屬於客戶端問題，運維同學一般會排除此類code的告警。而客戶遇到此類問題，也有可能會首先懷疑自己的行為是否正確，所以到爆發時，影響面可能就比較大。
然而針對這種使用者場景的測試，QA是有驗收手段的。
在實際業務迭代中，QA一般都會產出自動化測試，所以就可以通過這些自動化用例，單獨對灰度的例項進行驗收，確保釋出符合預期。
然而理想很豐滿，現實卻骨感。實際上多數自動化測試用例並不是那麼方便的，去交付別人去使用。它有其複雜性，比如：
- 服務端的產品，測試框架多數是基於配置檔案來適配不同的測試環境，不同的測試賬號。日記月累下，測試配置有可能會比較複雜。而讓不懂這塊的人去改這些配置，心智成本較高。
- 測試框架為滿足多樣性的需求，會越做越複雜，比如golang領域的ginkgo，功能很豐富，支援併發的跑用例，focus or skip的組合，遞迴遍歷等，對不熟悉的使用者來講會造成困擾。
- QA的測試用例可能包含多種層次型別，比如整合，e2e，或者破壞性的。而破壞性的用例，必須確保不能在線上執行，這點很重要。
- 測試資料如何方便的快捷準備，也是需要考量的.
除了測試用例本身的複雜性之外，還需要考慮用例的更新機制，以及分發機制。
所以若想將測試用例交付部署人員來使用，必須解決其易用性,安全性問題,降低使用者的心智負擔。
Interface for Tests Execution
一個可行的方案就是構建一個interface程式，專門用於執行測試用例，將所有的複雜性問題都封裝起來，做到對使用者友好：
- 比如可以內建所有配置到二進位制程式中，並能讓使用者方便的選擇使用範圍
- 還要能提供簡單方式，其使用者指定灰度服務的IP地址，做到針對性測試
- 一鍵準備測試資料，最好讓使用者無感知
- 固定使用姿勢，不給使用者犯錯的機會
- 工具要有清晰的help文件，隨用隨學
至於分發問題，就可以將程式託管在公有云儲存上，通過shell指令碼，一鍵下載。這種方案會極大的降低使用者的心智負擔，對測試服務的推廣非常有益。
kubernetes test infra中的Kubetest也是這種思想的的典型代表。
Test as a Service
業界，大家一直在探尋QA的轉型之路，不管是左移還是右移，或者是工程效率層面，測試服務的輸出都是其中非常有價值的topic。筆者認為，QA不光要擁有業務質量的全域性視角，還要能發現業務痛點，然後圍繞質量方向，打造高價值產品或平臺，以此來輸出質量保障服務。測試不在於人，而在於服務。測試服務不是測試同學的玩物，應該是圍繞解決如何保證業務質量的難題。同時，單個人，或者單個組織來做質量保證必有其侷限性，質量全員建設才是王道。
提供這種灰度驗收的工具，其實也是對QA的測試用例提出了更高要求，只有持續保障其穩定，高效，才能不斷產生價值。