一天，天气晴朗，云之地（一个小岛）上的所有公民（用户、开发人员和基础架构专家）都十分开心。系统运转一切正常。用户使用远程桌面控制连接他们的虚拟桌面。一旦连接成功，他们就可以访问软件即服务 (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 Babylonian Method X Method X x1 = 1.4 x1 = 1.42 x1 = 1.4 x1 = 1.42 x2 = 1.4142857... x2 = 1.41422535... x2 = 1.4016 x2 = 1.42026896 x3 = 1.414213564... x3 = 1.41421356242... x3 = 1.4028614... x3 = 1.42056... ... ... x1000000 = 1.41421... x28 = 7280.2284...
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 在数值上是不稳定的。