構建雲規模軟體的10項基本實踐

規模是複雜軟體系統最常見的壓力源之一。只要“預期”與“實際”(每天的使用者數、每個使用者的事務數、每個事務的大小、每個事務保留時間等)有顯著差異，它就會導致大量返工。公共雲服務最令人印象深刻、最有價值的貢獻之一是其看似無限的規模(網路、處理、儲存等)。同樣，最具可模仿性的實踐之一是那些將“雲規模”開發團隊與“常規”軟體開發團隊區分開來的實踐。

那麼公共雲服務公司是如何做到的呢?而且，即使在開發不需要“雲規模”的解決方案時，我們也可以從他們的工具包中應用哪些差異化實踐?

改進軟體的10種方法

在探索雲端計算所需的實踐之前，為任何高效能軟體團隊設定基線是很重要的。DevOps Research Assessment(DORA)中概述的實踐是一個很好的起點。DORA中的技術實踐、精益產品開發、精益管理以及文化和工作環境方法適用於任何軟體系統的預期規模。但也必須有一些新的或不同的東西來支援這些實踐，以實現雲規模。

這些實踐將常規軟體與雲規模軟體區分開來，分為四類：

知識——團隊成員知道什麼

運維——團隊成員如何處理運維

開發——團隊成員如何構建軟體

幫助他人——團隊成員如何分享以上所有內容

這些類別和其中的實踐結合在一起，使軟體團隊能夠加快開發新功能的速度，提高所交付軟體的質量，並提高實現所需規模的可能性。

“風險來自於不知道自己在做什麼。”對於複雜的軟體系統來說尤其如此。雖然DORA中列出了有助於培養學習文化的實踐，但從直接經驗中獲取知識沒有捷徑。

實踐1——僱傭或發展分散式系統專業知識

深入理解分散式系統及其解決方案的常見缺陷，對於構建雲規模的軟體團隊至關重要。閱讀這些陷阱是積累知識的良好開端，但處理失敗的經驗會帶來理解力。同樣，要想在短時間內找到創造性的方法來解決這些挑戰，通常需要利用以前的成功和失敗經驗。

例如，分散式系統專業知識允許團隊在與提供“至少一次”通知傳遞的系統互動時保持冪等性。雖然對於某些通知服務來說，“僅一次”傳遞是一個可能的選項，但該選項通常會帶來嚴重的效能損失。憑藉深厚的知識，團隊認識到在保持等冪性的同時解決“至少一次”交付的模式，與選擇“僅一次”通知方法以避免複雜性的團隊相比，其效能提高了幾個數量級。

在常規開發團隊中，分散式系統的專業知識往往很集中，這限制了團隊的效率和有效性。而在雲規模團隊中，分散式系統專業知識非常普遍。

實踐2——非常熟悉所使用的庫和雲服務

你可能聽過這樣一句格言：“一個業餘愛好者練習直到能做對一件事，一個專業人士練習直到不做錯一件事。”這同樣適用於軟體依賴關係選擇，“一個業餘愛好者整合一個庫，直到它們開始工作;一個專業人士整合一個庫，直到它永遠工作。”

花適當的時間選擇合適的庫，一個可以正常工作但也會失敗的庫，這是DORA團隊試驗實踐的一個很好的實現。同樣的選擇嚴格性也適用於公共雲服務。必須充分了解其固有限制和故障模式，以便正確設計和構建這些潛在故障。程式碼審查有助於確認故障模式已得到處理，但只有深入瞭解與之互動的庫或雲服務，才能瞭解要處理的故障。

在常規開發團隊中，庫和雲服務的選擇是基於什麼是流行的，什麼對簡單的案例最有效。這可能導致故障場景。而在雲規模團隊中，雲服務和庫選擇涉及對原始碼(如果可用)、文件的深入探索，以及對實驗、基準測試和原型(包括故障模式)的大量關注。

DORA廣泛涵蓋運維，包括其測量能力。雲規模團隊在運維領域的不同之處不是實踐本身，而是應用的複雜程度和完整性。

實踐3——提供深入完整的運維可視性

監控和可觀察性已經是公認的必要條件。DORA指南概述了幾個重點領域，包括檢測和關聯。檢測意味著必須將程式碼新增到系統以公開其內部狀態。關聯意味著可以使用從應用程式及其底層系統收集的指標來解釋行為。

團隊經常發現，由於檢測不足或關聯不足或不準確，運維可見性不可能實現。隨著軟體系統變得更加分散式和複雜，這一點變得尤其具有挑戰性。有越來越多的優秀工具可用於跨應用程式、區域和雲進行分散式跟蹤。雖然這些工具處理關聯，但它們仍然需要開發團隊在檢測上花費時間。與其他工程任務一樣，在正確的時間、以正確的方式、使用正確的後設資料(以便與其他資料關聯)公開應用程式的正確內部狀態也同樣重要，甚至可能更重要。如果沒有正確的檢測和關聯，很可能會發生一些意外的事情，但不會被注意到。

在常規開發團隊中，運維可見性沒有得到與功能開發相同的時間和關注，功能開發縮短了檢測，並且常常依賴於不充分的工具來跨複雜的分散式系統進行度量關聯。而云規模團隊明白，卓越的運維需要深入完整的運維可視性。

實踐4——建立強大的運維自動化和工具

自動化部署和測試也是公認的持續交付實踐。自動化背後的目的是減少工作量，增加成功的可能性，並使重要但痛苦的過程變得簡單、可靠，從而更頻繁地執行。

自動化的應用程度對一些團隊來說仍然是難以理解的，他們認為這是一種主要用於持續交付的技術。考慮一個團隊正在構建由API閘道器、API實現和支援API的資料儲存組成的API解決方案。他們可以(正確地)自動化API解決方案的構建、部署、測試和釋出過程。但他們可能會忽視(錯誤地)基於單個模式檔案完全自動化API設計、實現、支援資料儲存和前置API閘道器的機會。

工具是另一個經常有選擇地應用的領域，但沒有達到它可能達到的程度。當工具是“進入生產的途徑”時，它們會得到必要的時間和關注。同樣，當優秀的工具是開源的時，他們會以擁有所有權為榮，並關注團隊內部工具可能缺乏的細節。

常規團隊在知道其他人使用自動化的地方使用自動化。他們在內部工具上花費了時間和精力，但在設計和程式碼質量上並沒有像新特性開發那樣嚴格。而云規模團隊明白，自動化應該應用於存在可重複流程的任何地方，包括軟體開發。他們花在審查內部工具的設計和實現上的時間和審查外部功能上的時間一樣多。

實踐5——嚴格進行on-call審查

反思是持續改進思維的核心，而(各種風格的)回顧是敏捷軟體開發的核心。雖然回顧在今天很常見，但根據計劃和執行的質量，其有效性可能會有很大差異。正如運維工具在常規開發團隊中經常短缺一樣，運維on-call評審也是如此。就像許多DORA實踐一樣，僅僅“做”是不夠的，要做得特別好。

特別好是什麼樣子?有幾個突出的特點：

格式是一致的——這提供了一種涉及所有必要主題的結構化方法(沒有忽略任何內容)。

這些材料來自於深入的運維可視性——對話是非常資料驅動的，依賴並顯示了運維可視性和自動化工具投資的價值。

快速跟蹤和關閉行動項——許多行動項作為on-call輪換的一部分進行處理。那些沒有被優先考慮的通常是下週的事。

動態是協作的——每個團隊成員的心態都是關於如何彌合導致運維問題的任何差距。問題不容忽視，需要解決。

方法是嚴格的——團隊成員相互負責，從會議持續時間到內容結構，再到確定的行動專案。

常規團隊將績效反思限制在回顧中，如果沒有捕捉到行動項並迅速結束(如果沒有應用所學知識)，回顧可能會成為死記硬背的做法。處理執行事件並進行表面糾正，但往往缺少真正的根本原因分析和糾正，這需要投入資金。

雲規模團隊知道，運維可見性提供了豐富的資料，可以收集這些資料來改進設計、實施和團隊績效，前提是提供了足夠的時間和精力來檢查和學習這些資料。

實踐6——永遠金絲雀(ABC)

雲規模團隊在自動化測試和部署方面投入了大量資金。金絲雀釋出技術是團隊逐步釋出新特性的方法，避免了大爆炸式的運維事件。這項技術符合DORA關於小批次工作的指導。

一旦新軟體釋出，重要的是要有主動/合成/黑盒和被動/真實使用者/白盒監控，並結合主動通知故障。軟體即服務(SaaS)產品的理想釋出順序如下：

新發布——新軟體的首次釋出，理想的目標是已知非生產環境的小型使用者和環境(沙盒賬戶)。

主動監控序列——綜合驅動流量到共享服務(控制平面)，以確認釋出是否按預期工作。

被動監控結果——檢查真實使用者活動(資料平面)，以確認釋出是否按預期工作。

第二波釋出——假設2和3(經過一段足夠的時間)都沒問題，繼續到第二波，然後重複相同的過程。

常規開發團隊可能會選擇藍色/綠色部署策略，因為它比金絲雀釋出更容易機械化。他們也可能不會投資大量的主動和被動監測，因為前者需要實施實踐4，而後者需要實施實踐3。

雲規模團隊以小批次工作，並利用領先的運維實踐。他們明白，組合是一個大於其各部分的總和。