使用服務等級協定和其他前瞻性工具避免雲停機

一天，天氣晴朗，雲之地（一個小島）上的所有公民（使用者、開發人員和基礎架構專家）都十分開心。 系統運轉一切正常。 使用者使用遠端桌面控制連接他們的虛擬桌面。 一旦連接成功，他們就可以訪問軟體即服務 (SaaS) 應用程式並接收快速回應。 所有虛擬桌面都是使用部署到運行虛擬機器管理程式的伺服器上的物理桌面映射進行創建。

開發人員擁有開發平臺即服務 (PaaS) 應用程式所需的全部資源。 他們使用虛擬桌面訪問平臺。 基礎架構專家訪問基礎架構即服務 (IaaS) 以通過相同物理主機管理虛擬機器。

後來有一天，島上的居民看到遠處地平線上烏雲密佈。 緩慢移動的烏雲在接近該島時變得越來越大。 烏雲抵達小島後，便完全遮住了該島上方的天空。 難過的島上居民看到的下一個事情就是雲停機將所有雲服務資源一點一點地消耗掉，直到再無資源供島上居民使用。 烏雲離開小島後，島上居民由於對雲服務停機未做好準備而不斷抱怨。 雲服務性能大大低於服務等級協定 (SLA) 中規定的服務可用性保證水準。

雲停機風險

當面臨威脅的代理利用雲漏洞時，最有可能出現雲停機風險。 由於資源枯竭，所有組織都容易受到雲停機的影響。 觸發停機的故障類型包括：

閏年故障

Microsoft 的 Azure 雲中的安全證書發佈伺服器既沒有實現飛躍，也無法識別 2012 年 2 月 29 日這個日期，於是就產生了雲停機。 由於憑證服務器無法發佈適當的證書從而使虛擬機器無法啟動。 伺服器的主機代理將其解讀為一個可能發生的硬體問題，於是將其報告給雲的集群控制器以便將虛擬機器移到其他硬體。 然後，彈性措施將無法啟動的虛擬機器移動到其他健康硬體上，主機再一次發送相同的錯誤硬體故障報告，並在導致雲服務停機前將可能已限定並改正的弊端進行了擴展。

數值不穩定的演算法

數值不穩定演算法在試圖解決數值問題時將會導致資源消耗無限迴圈，直到再無資源可消耗。 隨著資源的減少，雲性能將繼續降低直到產生雲停機。

在過分簡化的場景中，計算 2 的平方根（大約是 1.41421）是一個適定問題。 許多演算法通過將初始近似值 x1 設為 1.4（有時將 x1 設為 1.42）來解決這個問題，然後計算改進的猜想 x2、x3 等。 設定的數值運演算法會影響該方法產生的結果如何快速收斂。 第一個演算法會產生比第二個演算法更快的反覆運算收斂結果。

如果反覆運算法產生的結果可以快速收斂到初始近似值，那麼它在數值上就是穩定的。 如果第二個反覆運算法對初始近似值而言收斂緩慢並大大地偏離了另一個初始近似值，那麼它在數值上就是不穩定的，而且需要消耗額外資源。

考慮兩種反覆運算法：Babylonian 法和 Method X，如表 1 所示。

表 1. 兩種反覆運算法

Babylonian 方法規定 xk+1 = xk/2 + 1/xk。 Method X 方法規定 xk + 1 = (xk2-2)2 + xk。 我用初始猜測 x1 = 1.4 和 x1 = 1.42 計算表中每個方案的一些反覆運算。

我們注意到，不管初始猜測如何，Babylonian 法都可以快速收斂，而 Method X 則極其緩慢地收斂初始猜測 1.4 並偏離為初始猜測 1.42（即，7280.2284...）。 因此，Babylonian 法在數值上是穩定的，而 Method X 在數值上是不穩定的。