[[280745]]

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

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

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

為什么要在生產環(huán)境進行測試？  

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

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

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

• 寫測試用例的時間
• 維護測試用例的時間
• 運行測試用例的時間

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

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

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

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

真實案例  

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

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

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

• 一個漸進式的發(fā)布流程
• 一種在好的基礎設施之上進行重試的方法
• 積極主動的問題檢測

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

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

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

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

當我們把新版本代碼部署到第一個節(jié)點上時，對于那些標準化之后長度會增加的請求，它馬上就停止了響應。幸虧我們的客戶端 API 有重試的功能，所以客戶沒有受到影響，沒有用戶注意到這一點。而在后臺，我們的監(jiān)控系統(tǒng)則發(fā)出了告警，所以我們馬上對發(fā)布進行了回滾，以保持整個集群的穩(wěn)定。通過這種辦法，我們?yōu)樽约籂幦〉搅俗銐虻臅r間來理解問題和完成代碼修復，并進行相應的測試。

一種合適的部署方案  

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

• 可復制的基礎設施；
• 彈性的軟件；
• 安全的部署策略；
• 可復制的基礎設施

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

彈性的軟件  

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

安全的部署策略  

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

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

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

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

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

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

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

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

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

好比完美更勝一籌  

初創(chuàng)公司的生態(tài)環(huán)境是相當嚴峻的。小團隊要找到高效的方法，打造出比大公司的大團隊更好的產品。

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

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

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