作者 | Xavier Grand

譯者 | 足下

策劃 | 趙鈺瑩

作為一家初創公司，構建軟件要堅持創新，要有吸引力和競爭力。因為，市場在不斷變化，新的需求也在不斷出現。

從軟件角度來說，要保持這樣的優勢就意味著必須盡可能縮短文檔和開發階段所占的時間。當然，保持軟件的彈性也很重要，提供優秀的服務是 Algolia 的重要目標之一。我們有許多高端用戶，搜索功能對業務有非常重要的影響，所以不能接受宕機時間，尤其是在黑色星期五之類的特殊時間段。

因此，開發者 必須在軟件的彈性與創新之間找到合適的平衡點。 這兩方面是相互牽制的：要讓軟件具有彈性，就要進行詳盡的測試，這會消耗大量精力，占用我們進行創新的時間。因此，一個比較好的折衷方案就是在生產環境進行測試。

為什么要在生產環境進行測試？??

在生產環境進行測試就是把新代碼發布到生產環境中，直接用真實的生產數據和流量進行“測試”的過程。與之形成對比的就是運行全面的測試用例集。這個風險很大，開發者的第一直覺肯定不要這么做。但隨著軟件規模的發展，你會發現進行詳盡的測試越來越不可能了。

讓我們看看 Algolia 引擎。我們有二十多個查詢參數。假設它們全是 Boolean 類型，那么要運行的用例總數就會達到一百萬個，二十個參數，每個有兩個可能值，那就是 2^20 種可能的場景。

談到與測試相關的工作所要消耗的時間，有三方面要考慮：

• 寫測試用例的時間

• 維護測試用例的時間

• 運行測試用例的時間

寫出一百萬個測試用例來，這個工作量已經很驚人了。一旦寫出來，它們就成了項目內容的一部分。就像維護別的源代碼一樣，也要花精力去維護它們，所以每次軟件迭代所要做的事情就更多了。

假設你的團隊足夠大，有充足的人力可以編寫和維護這些測試用例，但運行它們一樣需要不少時間。假設運行每個測試用例只需要 10 毫秒，那全運行一遍就需要 2 小時 45 分鐘。不管代碼中有什么更新，都需要花 2 小時 45 分鐘才能驗證完。

客戶購買我們的產品不止是看中了當前已經具備的功能，更是看中了未來將會發布的功能。他們希望我們可以定期發布新功能，幫助他們成長，變得更容易創新和更具有彈性。因此，我們必須提升自己的效率。

在開發新功能時，我們只會寫些簡單的用例來驗證功能，并對明顯的邊界條件進行測試。要對功能進行全面驗證，我們會采取灰度發布的方式，直接在生產環境中進行測試。這樣即使代碼中有缺陷，也可以把對客戶的影響控制得盡量小。通過這樣的方法，我們就可以按時發布新功能了。

真實案例??

以我們最近重寫的一個 Algolia 的核心功能做具體例子。如果要對它進行充分測試，就要用所有可能的 Unicode 字符（超過一百萬個）對這二十幾個參數組合成的一百萬個用例進行測試。這樣算起來總數會超過十億次。假設運行一個測試要用 10 毫秒，那完成全部測試內容就要 11 天。

我們不得不尋找更好的解決方案。因此我們放棄了這十億次測試。不能因為這件事而顯著地拖慢我們的發布流程，我們決定在生產環境進行測試。

我們最大的顧慮就是可能對用戶造成的影響，因此我們定義了要把它部署出去所必須要做的事：

• 一個漸進式的發布流程

• 一種在好的基礎設施之上進行重試的方法

• 積極主動的問題檢測

所有通過我們的網站發往 Algolia 的請求，最終都是由一個集群來提供服務的，集群由三個節點組成。每個節點中都包含 100% 的數據，可以獨立響應請求，因此可以提供健壯的部署方案。假設普通的服務器平均可用率為 95%，那這種方案可以提供 99.987% 的可用性。只有當所有服務器全部宕機的時候，你的服務才會真的宕機。所以這種可能性是 5% x 5% x 5%，即可能會有 0.0125% 的宕機時間。

但即使是在這樣的架構下，軟件的缺陷仍然可能造成服務中斷。因此，我們采取了漸進式的灰度發布方案。新的軟件全部發布完成需要三天的時間。這樣的部署策略給了我們足夠的時間來發現問題。

另外還有一點很重要的，就是我們的客戶端 API 會采用重試的策略。假如它正好把請求發往了一個有問題的節點，那么在請求失敗之后，它會自動尋找另一個節點進行重試，直到取得成功的響應為止。因此最終用戶對這個問題是沒有感知的。

在我們部署新版本的高亮功能時，曾經發生過一個標準化問題。我們的目標是把所有文本都轉化成標準化的格式，這樣就可以方便地對不同的輸入進行對比。一般來說，標準化后的內容長度不會比輸入的原文更長，這也是高亮功能的前提。結果，我們卻發現有些字符在標準化之后長度會增加：字母?（德語）就會被標準化成了“ss”。在重寫的時候，我們增加了運行時前置條件檢查，以確保標準化后的長度比原來長度更小，或者相等。這段代碼發揮了作用，把這個問題暴露出來了。

當我們把新版本代碼部署到第一個節點上時，對于那些標準化之后長度會增加的請求，它馬上就停止了響應。幸虧我們的客戶端 API 有重試的功能，所以客戶沒有受到影響，沒有用戶注意到這一點。而在后臺，我們的監控系統則發出了告警，所以我們馬上對發布進行了回滾，以保持整個集群的穩定。通過這種辦法，我們為自己爭取到了足夠的時間來理解問題和完成代碼修復，并進行相應的測試。

一種合適的部署方案??

如果你也想在生產環境進行測試的話，有三個至關重要的前提條件：

• 可復制的基礎設施；

• 彈性的軟件；

• 安全的部署策略；

• 可復制的基礎設施

在現在這個時代，配置一套可復制的基礎設施是非常容易的：所有云服務商都可以在多個虛擬機的前面提供負載均衡。就我們公司的架構來說，我們在整個集群的級別復制搜索引擎的數據，每個節點都 100% 地擁有全量數據。通過這種方式，每個節點都可以獨立完成對請求的響應。

彈性的軟件??

這一部分就要看你是怎樣構建軟件的了。在 Algolia 引擎的代碼中，有許多關于健康狀態的檢查，會校驗函數的前置條件是否滿足，以及是否處于期望的狀態等。當運行到非正常的狀態時，引擎就會停止處理，以避免返回有問題的數據。它會強制 API 客戶端在別的節點上透明地進行重試。

安全的部署策略??

這一點被最后提到，但它也一樣非常重要。這里提到的部署策略的主要目標，就是要在逐步發布新版本軟件的過程同時，注意控制風險。

Algolia 的基礎設施主要包括四個環境：測試環境、準生產環境、生產環境和安全環境。每個環境都有不同的 SLA：

測試環境只包含供內部使用的集群。出故障時只影響公司內部員工。準生產環境包含面向外部大眾用戶項目的搜索集群。生產環境包含我們客戶的集群。安全環境包含我們最重要的 SLA 客戶的集群。根據部署策略，我們通過使用多個不同的環境來降低風險。也就是說，我們會先在對客戶影響最小的集群上進行部署。

除了不同的環境，我們還利用了三份復制這個特性，制定了如下的 12 步部署流程：

先部署到測試環境的所有三個節點上；部署到準生產環境的第一個節點上，再部署到生產環境的第一個節點，再部署到安全環境的第一個節點上；觀察一天；部署到準生產環境的第二個節點上，再部署到生產環境的第二個節點，再部署到安全環境的第二個節點上；再觀察一天；部署到準生產環境的第三個節點上，再部署到生產環境的第三個節點，再部署到安全環境的第三個節點上；第一步可以幫我們發現分布式系統內部的處理集群里，節點之間交互的代碼問題。

接下來一個節點一個節點的部署，可以幫我們確認集群內部是否可以同時支持兩個不同的版本，以及代碼是否足夠穩定。

為什么在部署節點的過程之中有兩次要觀察一天呢？因為這樣可以讓我們有充足的時間發現性能問題、數據問題或需要長時間運行才能發現的問題。到這一步時，我們就已經解決掉大部分問題了。接下來的部署步驟只是幫助我們發現一些可能的未知缺陷。

每當發現新問題時，我們都會立刻將新版本代碼回滾。這樣我們提供的服務就可以恢復到一個穩定的狀態，我們也可以有充足的時間去修復問題，并增加相應的測試用例。

使用了這樣的方法，我們的測試用例集就是客戶的真實使用場景。這樣效率就非常高了，我們可以每周都發布新版本，滿足客戶的需求。盡管我們的代碼量已經非常龐大，我們仍然做到了這一點。

好比完美更勝一籌??

初創公司的生態環境是相當嚴峻的。小團隊要找到高效的方法，打造出比大公司的大團隊更好的產品。

定期發布新功能的重要性，不亞于有著良好用戶體驗，可以滿足用戶需求的穩定產品。選擇做足夠的測試還是選擇有足夠的測試覆蓋率并可以定期發布？對效率的需求逼著我們在這兩者之間找到了一個中間的平衡點。

在增加新測試用例時你必須特別小心，因為要消耗的時間太多了：要花時間去寫、去維護和運行。那你知道什么時候該寫測試嗎？90-90 法則適用于這種情況：測試一個功能 90% 的內容是非常容易而直接的，再測試剩下的 10% 會花費相同的時間。所以根據客戶的使用情況來處理這剩下的 10% 非常重要，不應該追求完全的覆蓋率。

為了降低風險，請多花些時間對軟件和基礎設施進行設計，讓它們可以支持在生產環境進行測試，并把對客戶的影響限制到最小。

原文鏈接：

https://blog.algolia.com/tech-startup-dilemmas-resilient-deployment-vs-exhaustive-tests/

總結

以上是生活随笔為你收集整理的初创公司技术困境：弹性部署与详尽测试的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。