技術支援
文件
登錄
聯繫我們
基礎設施即代碼：一把雙刃劍
若昂·科雷亞
2023年6月27 日 - 技術佈道師
在不斷發展的技術環境中，處理複雜的環境遠非在公園裡散步。從更大、更昂貴的運營團隊到更嚴格的硬體和軟體標準化，許多策略都經過了考驗。自動化和當下的流行語都成為人們關注的焦點。
一段時間以來，我們一直在接受“基礎設施即代碼”（IaC）的範式。這種方法擴展性好，需要的資源更少，與其他工具和流程（如原始程式碼控制和更改跟蹤）無縫集成，是管理當今數位世界不斷增長的需求的更有效方法。
但是，與其他任何事情一樣，IaC並非沒有缺陷。我們擁有數十年管理基礎設施方面的經驗，但 IaC 的「代碼」部分是出現問題的地方。如果錯誤、補丁、漏洞利用、漏洞賞金和其他相關活動的數量有任何跡象，那麼很明顯我們還有提高編碼能力的空間。
有趣的是，當比較不同的軟體包不是因為性能或可靠性，而是與其他軟體包或版本一樣有缺陷時，將基礎設施視為代碼不可避免地會將這些相同的錯誤和問題引入基礎設施本身。一個恰當的例子是最近在Azure發生的事件。
Azure 中斷：IaC 中的案例研究
幾天前，Azure的一次事故影響了巴西南部的客戶。作為主要的雲供應商，Azure 遵循「一切都是代碼」的座右銘，允許將服務、伺服器、資料庫、終結點、備份等的配置作為代碼進行處理。這種理念延伸到 Azure 的管理方面，而不僅僅是面向客戶的雲，在雲中，系統管理員將所有內容視為代碼，從而實現每個操作的自動化。
幾天前，Azure 正在測試管理元件中的更改。目標是將一些較舊的元件替換為較新的元件，這涉及刪除一些 NuGet 包並安裝新包。作為更改 NuGet 包的一部分，引用它們的代碼也必須稍作更改 - 包名稱不同，並且某些調用約定已更改。它不完全是一個直接的替代品。
更改經過腳本編寫、提交、評審、測試，然後部署在 Azure-land 上稱為「環 0」的測試環境中，類似於具有最高特權的模式的名稱。在環 0 中一切順利后，更改將推廣到環 1，即客戶可見的生產環境。
但是，與許多實驗室或測試環境非常相似，Ring 0 是生產環境的縮小版本，沒有相同的負載、使用者群或複雜的系統交互。
有趣的是，Azure 系統管理員在生產環境中執行的一項相對例行的任務是創建正在運行的資料庫的快照以進行調試，而不會影響實際工作負荷或客戶。由於無需在沒有實際生產資料庫和問題的實驗室環境中創建快照，因此 Ring 0 沒有快照。
NuGet 包中的更改之一是處理快照的函數的更改。
在內部，Azure 運行後台作業以定期刪除舊快照。由於環 0 中沒有快照，因此在測試階段從未嘗試刪除任何快照。但是，在存在快照的生產環境中，後台作業隨 NuGet 包更改一起運行，並且曾經用於刪除資料庫快照的調用演變為用於刪除資料庫伺服器的調用。
就像一場緩慢移動的車禍一樣，當作業運行時，每個具有足夠舊快照的資料庫伺服器都會被刪除，而一個接一個的服務變得無回應。
Azure 中斷的後果
伺服器刪除觸發了一系列切向相關事件：
- 在 Azure 中，客戶無法自行還原已刪除的伺服器。這必須由Azure的支持團隊完成。
- 並非所有受影響的伺服器都具有相同類型的備份，從而導致還原速度的差異。有些存儲在同一個區域（讀取：數據中心），而另一些則在地理位置上是冗餘的，這意味著它們存儲在不同的 Azure 區域中。數據必須在恢復之前傳輸。這增加了恢復時間。
- 已發現某些依賴於已刪除資料庫伺服器的 Web 伺服器在啟動時運行測試，以確定哪些資料庫可用且可訪問。這些請求是針對所有資料庫伺服器的，並具有干擾資料庫伺服器恢復過程的意外副作用。此外，當測試失敗時，Web 伺服器將立即觸發重新啟動。這發生了。它又發生了。同樣，由於這些資料庫在很長一段時間內不可用。
- 作為預防措施，當測試失敗時，會採用一種稱為退避的技術。這基本上意味著，當嘗試測試失敗時，下一次重試之前的時間段會不斷增加。這種增加可以是線性的，也可以是指數級的，這個想法是給另一方足夠的時間從它所經歷的任何情況中恢復過來，而不必處理這樣的測試請求。在這種特定情況下，它產生了意想不到的後果，即導致重新啟動需要一小時以上，而重新啟動通常需要幾秒鐘。
- 由於基礎架構被請求淹沒，恢復備份的速度很慢。
- 幾台伺服器一重新上線，他們很快就被客戶流量淹沒了。
為了允許所有伺服器重新連線，必須中斷所有流量，直到所有伺服器都恢復為止。此流量峰值使中斷（對於受影響的 Azure 租戶的客戶）比其他情況下更長。
結果呢？大約 10 小時的停機時間、業務中斷和大量沮喪的客戶。
總結和經驗教訓
強大的測試環境至關重要，能夠盡可能接近地模擬生產。精確副本很難實現，很容易變得不同步，並且難以維護。但是，過於簡單的測試環境本質上毫無價值，因為它們缺乏生產環境所面臨的必要挑戰。
有效的備份和還原策略至關重要。備份不僅應可用，還應已在即時還原方案中試用。
人為錯誤是代碼開發中持續存在的挑戰。我們必須承認在非常複雜的系統中忽視關鍵交互和潛在錯誤的可能性。事實上，這些系統甚至不必那麼複雜，人類就缺乏掌握所有複雜性和相互作用的能力。在這種情況下編碼不可避免地會導致問題。
雲雖然是革命性的，但也不能倖免於失敗。人為錯誤、軟體故障和硬體故障可能而且確實會發生。反覆且出乎意料。如果 墨菲對此有任何發言權，那也是在最糟糕的時刻。
更光明的是，這一事件展示了Azure的支持和運營團隊的堅韌不拔，他們設法在相對較短的時間內恢復已刪除的資源而不會丟失數據。它強調，雖然管理大型基礎設施（尤其是作為代碼）具有挑戰性，但服務的真正衡量標準是它在出錯後回應和糾正問題的速度。
總之，盡可能實現自動化始終是明智的，確保測試環境盡可能接近生產。此類事件可作為有價值的提醒，在導致故障之前考慮環境中的潛在漏洞。
同樣重要的是，首先自動化瑣碎的任務 - 例如， 自動補丁部署 - 允許將重點放在需要更高關注的更複雜的操作上。這有助於釋放雲無法擴展的唯一資源（腦力）用於更重要的任務。
