分散式程式如何進行線上灰度自動化驗收?
前言
前面在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的測試用例提出了更高要求,只有持續保障其穩定,高效,才能不斷產生價值。