持續(xù)測(cè)試基礎(chǔ)設(shè)施
作者 | 趙志佳
持續(xù)測(cè)試基礎(chǔ)設(shè)施的必要性
基礎(chǔ)設(shè)施作為應(yīng)用程序的支柱，為之提供關(guān)鍵的運(yùn)行環(huán)境、網(wǎng)絡(luò)連接和資源調(diào)度等支持。一旦基礎(chǔ)設(shè)施出現(xiàn)故障，整個(gè)應(yīng)用生態(tài)系統(tǒng)都可能面臨嚴(yán)重的連鎖反應(yīng)，如性能降低、數(shù)據(jù)丟失乃至系統(tǒng)崩潰。因此，基礎(chǔ)設(shè)施的穩(wěn)定性和可靠性對(duì)于運(yùn)行在其上的應(yīng)用程序至關(guān)重要。
持續(xù)測(cè)試可以在基礎(chǔ)設(shè)施的整個(gè)生命周期中進(jìn)行檢查，確保一切運(yùn)行正常，盡早發(fā)現(xiàn)并解決潛在問題，減少影響擴(kuò)散。此外，持續(xù)測(cè)試通過為團(tuán)隊(duì)提供即時(shí)的狀態(tài)反饋，有助于提高基礎(chǔ)設(shè)施的可維護(hù)性和可擴(kuò)展性，進(jìn)而支持業(yè)務(wù)持續(xù)增長和變化的需求。
因此，持續(xù)測(cè)試不僅是持續(xù)交付高質(zhì)量軟件的必要保障，對(duì)于基礎(chǔ)設(shè)施而言，其價(jià)值和影響更為深遠(yuǎn)。
本文來分享一下我們團(tuán)隊(duì)是如何對(duì)基礎(chǔ)設(shè)施進(jìn)行測(cè)試的。
測(cè)試的范圍
首先我們要識(shí)別出需要測(cè)什么。在 IaC（基礎(chǔ)設(shè)施即代碼）的實(shí)踐中，我們以測(cè)試金字塔和敏捷測(cè)試四象限為指導(dǎo)原則，適用的測(cè)試方案包括：
- 單元測(cè)試：對(duì)實(shí)現(xiàn)中的特殊邏輯，比如環(huán)境差異、批量處理等進(jìn)行部署前的驗(yàn)證。
- 組件測(cè)試：對(duì)部署的獨(dú)立組件進(jìn)行驗(yàn)證，部署結(jié)果與預(yù)期一致。比如 S3 bucket 部署配置。
- 功能測(cè)試：對(duì)多個(gè)需要串聯(lián)合作使用才能達(dá)成實(shí)現(xiàn)一個(gè)功能的組件進(jìn)行驗(yàn)證，保證組件間配置的正確性。比如通過公網(wǎng)域名可以訪問到 app。
- 冒煙測(cè)試：在服務(wù)、組件部署完成之后進(jìn)行端到端驗(yàn)證，確保服務(wù)基本可用和出入口配置的正確性。
- 安全性測(cè)試：驗(yàn)證各項(xiàng)安全配置是否已經(jīng)啟用。比如數(shù)據(jù)庫、域名是否采取了 TLS 且無法在不加密情況下進(jìn)行連接。其它的如權(quán)限控制、代碼漏洞等。
- 可靠性測(cè)試：基礎(chǔ)設(shè)施的容災(zāi)耐力、數(shù)據(jù)，混沌工程等。
- 部署測(cè)試：確保應(yīng)用在發(fā)布的過程中，平臺(tái)提供了正確可用的部署能力。
- 性能、可用性測(cè)試：服務(wù)的響應(yīng)時(shí)間、吞吐量、并發(fā)用戶數(shù)等指標(biāo)。由于平臺(tái)在服務(wù)間添加了一些基礎(chǔ)設(shè)施級(jí)組件和服務(wù)，如 Service Mesh、Styra，所以也會(huì)受到影響。因此，平臺(tái)團(tuán)隊(duì)可以構(gòu)建一個(gè)覆蓋了影響范圍的簡(jiǎn)單應(yīng)用，對(duì)其進(jìn)行驗(yàn)證。
明確了測(cè)試方案，我們就需要識(shí)別測(cè)試優(yōu)先級(jí)，在不同階段開展相應(yīng)的測(cè)試：
- 首先覆蓋關(guān)鍵路徑和高價(jià)值，如單元測(cè)試、組件測(cè)試、功能測(cè)試。這些代碼變化而引發(fā)的測(cè)試在代碼變化時(shí)都應(yīng)該進(jìn)行。
- 其次是覆蓋代碼變化之外由我們可控因素導(dǎo)致的問題，如證書到期、磁盤空間滿、token 失效等，保證運(yùn)行時(shí)環(huán)境相關(guān)組件和功能。如冒煙測(cè)試、部署測(cè)試、可用性測(cè)試等?？梢栽谄脚_(tái)功能上了生產(chǎn)環(huán)境后，核心功能交付無壓力時(shí)進(jìn)行。
- 最后是在平臺(tái)相較穩(wěn)定后（即被測(cè)功能不會(huì)有大的變動(dòng)時(shí)），以提高平臺(tái)可靠性為目的的測(cè)試。用來驗(yàn)證在面對(duì)代碼之外，不可控的因素導(dǎo)致的問題發(fā)生時(shí)我們的應(yīng)對(duì)能力。如外部依賴變化、數(shù)據(jù)恢復(fù)能力、容災(zāi)重建能力等。通常在平臺(tái)上的應(yīng)用服務(wù)在生產(chǎn)環(huán)境已有真實(shí)用戶投入使用后進(jìn)行。
測(cè)試工具的選擇
市面上有很多可以測(cè)試工具可以選擇：
- 最基礎(chǔ)和單一的是 Shell 腳本語言，典型如 Bash。
- 之后是應(yīng)用開發(fā)語言的測(cè)試框架，如 Bash 的 bats、Ruby 的 RSpec 和 JavaScript 的 Jest。
- 最后是在語言提供的能力上對(duì)三方 cli 和 API 進(jìn)行封裝的測(cè)試庫，如 Ruby 的 AWSpec，Go 的 Terratest 等。
比較來看，shell 優(yōu)點(diǎn)是原生，直接調(diào)用服務(wù)方提供的 CLI，如 AWS CLI, Kubectl；缺點(diǎn)是面對(duì)復(fù)雜場(chǎng)景編寫起來費(fèi)心費(fèi)力；
使用封裝起來的測(cè)試庫看起來很簡(jiǎn)單，但開發(fā)者日常就要使用 CLI/Curl 命令來進(jìn)行基礎(chǔ)驗(yàn)證，而用封裝庫進(jìn)行開發(fā)就需要多學(xué)習(xí)一套知識(shí)；而且在被測(cè)服務(wù)發(fā)布新功能后，平臺(tái)想跟進(jìn)卻發(fā)現(xiàn)測(cè)試庫沒能跟進(jìn)，導(dǎo)致最后還得用原生方式來寫。比如 AWSpec 支持 RDS，但是很長時(shí)間都沒有支持 Aurora。如果已經(jīng)寫了很多測(cè)試，就只能在 Aurora 這里使用其它方式驗(yàn)證，最后導(dǎo)致各處驗(yàn)證方式不統(tǒng)一。
所以我推薦選擇團(tuán)隊(duì)熟悉的應(yīng)用開發(fā)語言的測(cè)試框架，優(yōu)點(diǎn)如下：
- 可以直接通過系統(tǒng)命令調(diào)用 CLI，開發(fā)者平常工作怎么驗(yàn)證，測(cè)試代碼就怎么寫，拷貝過來能用。
- 相較 shell 來說，良好的測(cè)試框架支持。比如在多級(jí) JSON 中驗(yàn)證部分內(nèi)容，jq 驗(yàn)證起來就很麻煩。
- 各種驗(yàn)證場(chǎng)景統(tǒng)一實(shí)現(xiàn)，不用學(xué)習(xí)多框架或多語言。比如 Terratest 只適合驗(yàn)證 infra，如果需要想做冒煙測(cè)試，還要另起爐灶。
- 如果確實(shí)有必要集成測(cè)試庫，也可以按需集成。
我的選擇則是 Ruby/RSpec，因?yàn)?Ruby 簡(jiǎn)潔自然的語法和 RSpec 的強(qiáng)大驗(yàn)證器，讓測(cè)試代碼中很少出現(xiàn)語言自身導(dǎo)致的難懂和多余的代碼。
如何測(cè)
組件測(cè)試加上人工驗(yàn)證是交付環(huán)境能夠成功部署的主要信心來源，而在有邏輯分支的時(shí)候，單元測(cè)試可以用來成為對(duì)組件測(cè)試的補(bǔ)充：組件測(cè)試驗(yàn)證代碼的主干，單元測(cè)試在部署前來驗(yàn)證分支，以實(shí)現(xiàn)對(duì)代碼的測(cè)試全覆蓋。
下面我們基于 Terraform 實(shí)現(xiàn)，以單元測(cè)試和組件測(cè)試為例進(jìn)行測(cè)試。其它 IaC 實(shí)現(xiàn)和不依賴外部工具的測(cè)試都可以參考來實(shí)現(xiàn)。
注意這些由代碼變化產(chǎn)生的測(cè)試都應(yīng)在 Pipeline 的流水線中，而不是手動(dòng)觸發(fā)。任何不攔截在上線必經(jīng)之路的測(cè)試，最終都將無人理睬。
部署前
(1) 單元測(cè)試
在 Terraform 中，通常需要人工來驗(yàn)證 terraform plan 的結(jié)果，但是它只能覆蓋當(dāng)前 state 和配置參數(shù)下的結(jié)果。當(dāng)我們代碼中包含邏輯時(shí)，我們就需要通過配置 local backend、不同配置和 state 文件來本地驗(yàn)證對(duì)應(yīng)的 plan 結(jié)果。示例：
(2) 檢查 plan 結(jié)果
在部署流水線中，通過 terraform plan 加人工驗(yàn)證。在測(cè)試環(huán)境中 apply 后，人工測(cè)試來保證正確性。驗(yàn)證完成后，對(duì)于后續(xù)環(huán)境來說在測(cè)試環(huán)境的 plan 結(jié)果就是其它環(huán)境的參考輸入，由人工核對(duì)確認(rèn)后進(jìn)行 apply。
部署后
在資源生成后，我們便可以通過測(cè)試腳本調(diào)用 CLI/API 請(qǐng)求目標(biāo)資源，來驗(yàn)證產(chǎn)生的結(jié)果與預(yù)期一致。比如服務(wù)可以被成功訪問、數(shù)據(jù)庫確實(shí)被創(chuàng)建出來并配有正確的參數(shù)，密鑰管理器中被保存下來的數(shù)據(jù)庫密鑰我們可以成功連接到數(shù)據(jù)庫等等。與應(yīng)用測(cè)試一樣，任何一條失敗的測(cè)試都應(yīng)讓我們的 Pipeline 變紅，向團(tuán)隊(duì)告警。并確保只有在前一個(gè)環(huán)境被驗(yàn)證通過后，我們才向下一個(gè)環(huán)境前進(jìn)。
一個(gè)測(cè)試的范例
我們以 Ruby/RSpec 為例。在一個(gè)代碼庫中，以生成的目標(biāo)資源上下文劃分測(cè)試文件。
比如對(duì)于 RDS 數(shù)據(jù)庫的創(chuàng)建，我們可以組織這三個(gè)文件：
- rds_spec.rb: 用來驗(yàn)證 AWS RDS 生成的資源，如 cluster、db parameter。
- db_spec.rb: 用來驗(yàn)證在 DB 中進(jìn)行的設(shè)置，比如支持動(dòng)態(tài)數(shù)據(jù)庫憑證所在 DB 中創(chuàng)建的資源，DB 的 extension 被正確啟用。
- vault_spec.rb：用來驗(yàn)證 Vault 中創(chuàng)建的資源、比如 master 憑證的存儲(chǔ)、支持動(dòng)態(tài)數(shù)據(jù)庫憑證所需的資源。
一個(gè)文件中的組織結(jié)構(gòu)如下：
下面是一個(gè)驗(yàn)證 RDS 的 DB parameter 按預(yù)期被創(chuàng)建的例子：
可以看出測(cè)試代碼非常的語義化，沒有額外的數(shù)據(jù)結(jié)構(gòu)定義和難懂的語法?？疵靼琢诉@個(gè)測(cè)試，其它命令行相關(guān)的測(cè)試也就全都會(huì)寫了。平臺(tái)開發(fā)者們可以專注于業(yè)務(wù)驗(yàn)證，而不會(huì)因?yàn)闇y(cè)試框架帶來額外的負(fù)擔(dān)。
IaC 可以測(cè)試驅(qū)動(dòng)開發(fā)嗎？
當(dāng)然，只需要我們能在編寫功能代碼之前被測(cè)內(nèi)容是什么。我們可以通過各種文檔來識(shí)別出被測(cè)內(nèi)容，比如 Kubectl、AWS、Vault 等 CLI，或各種服務(wù)的 API。如果我們無法識(shí)別出被測(cè)內(nèi)容時(shí)，那就需要通過拆解步驟、手動(dòng)部署資源等方式分析出來。像在其它語言進(jìn)行測(cè)試驅(qū)動(dòng)開發(fā)時(shí)一樣，小步驗(yàn)證，紅綠重構(gòu)。
進(jìn)行測(cè)試驅(qū)動(dòng)在其它語言中帶來的優(yōu)點(diǎn)，在 IaC 也一樣大部分適用：
- 促進(jìn)模塊化設(shè)計(jì)和提交
- 簡(jiǎn)化調(diào)試過程
- 更快地反饋循環(huán)
- 更好地設(shè)計(jì)決策
- 易于重構(gòu)
- 減少過度工程
- 保障測(cè)試覆蓋率：這點(diǎn)需要單獨(dú)提一下，目前還沒有什么好的方案可以檢查 IaC 代碼的測(cè)試覆蓋率，所以在測(cè)試驅(qū)動(dòng)中「只實(shí)現(xiàn)剛好可以通過測(cè)試的代碼」對(duì)保障覆蓋率很重要。
總結(jié)
自動(dòng)化測(cè)試是高代碼質(zhì)量和穩(wěn)定開發(fā)效率的重要保障，應(yīng)用服務(wù)開發(fā)如是，基礎(chǔ)設(shè)施因?yàn)閾?dān)負(fù)著更大的使命和責(zé)任更是如此。測(cè)試驅(qū)動(dòng)能幫助開發(fā)者更好的設(shè)計(jì)和實(shí)現(xiàn)。在 IaC 開發(fā)過程也同樣適用。在工具選型上，避免選擇編寫成本過高和太復(fù)雜的語言和工具，大部分 Ops 們更習(xí)慣編寫動(dòng)態(tài)語言的腳本，方便和順手更重要。
希望本文能對(duì)你的工程實(shí)踐帶來啟發(fā)，從下一個(gè) IaC feature 開始測(cè)試驅(qū)動(dòng)開發(fā)。
