云服务停运事件果真发生时，通常会激活故障切换机制，以便从运行不畅的服务器切换到正常运行的服务器。那样，云服务在故障切换过程中可以正常运行，不会带来任何破坏或干扰。
不过，故障切换算法并不总是丝毫没有任何问题。比如说，算法并不总是事先告诉你有没有足够的资源让算法运行。一旦计算资源在故障切换过程中耗尽，最终结果就是云服务停运（比如亚马逊服务停运）。
在停运期间，平台即服务（PaaS）开发人员和软件即服务（SaaS）用户大声喊着无法按时完成工作。为了迫切希望让云服务尽快恢复正常，他们会不断打电话给信息即服务（IaaS）提供商的技术支持部门。最终，IaaS提供商解决问题。
编写故障切换算法时要留意的问题
如果你遇到了云服务停运事件，对IaaS提供商的故障切换算法又不满意，那你可以决定编写自定义的故障切换算法。你需要在不同的场景下测试算法，确保算法运行起来无误。一旦所有测试返回了正面的结果，你应该征得IaaS提供商的同意：要是提供商的故障切换算法失效，可以在下一轮云服务停运时在生产环境中激活算法。
你在编写故障切换算法时，需要避免以下三大陷阱。
1. 闰年日期
上一个闰年日期是2012年2月29日。有人忘了检查微软Azure中颁发安全证书的那台服务器是否能识别这个日期。一旦时钟滴答滴答地报出那个日期的头几分钟，一个虚拟机无法启动。管理员想找到并解决这个问题并非易事。
下一个闰年是2016年2月29日，所以你有的是大把时间来避免同样的不幸事故。你应该在PaaS上测试几种闰年识别算法；这可以帮助你确保安全证书会识别闰年日期。
2. 不稳定的数值算法
你发现自己编写的一种数值算法不稳定，可惜发现得太晚。该算法引起了耗费计算机资源的无限循环。由于可供使用的资源越来越少，云服务性能越来越低下。等到一点资源都没剩下时，云服务就停止运行。
下面这个简单的场景可以帮助你更清楚地了解数值算法会如何变得不稳定。
为了解2的平方根，你先让算法从1.4这个初始近似值开始处理。你设定了一个很小的值，算法应该会向该值收敛。达到这个值后，算法给出近似的答案：1.41421（正如预期）。这时候，算法停止运行；它很稳定，因为它释放了资源，供其他计算任务使用。
你在新算法中建立略有不同的逻辑。你从1.42、而不是1.4这个初始近似值开始处理。你发现，结果并不向预期的值收敛――它与***个数值算法得到的近似答案偏差很大。
答案越来越长。该算法继续陷入无限循环，不断消耗资源。等到一点资源都没剩下时，算法才停止运行，这表明它不稳定。
为了避免这个陷阱，你需要事先做好功课，确定该算法能不能向预期的值收敛。
3. 虚拟机管理程序失效
所有PaaS（无论开源还是闭源）都位于在IaaS下面的虚拟机之上。所有虚拟机的创建和运行由虚拟机管理程序统一负责。物理服务器能托管运行多少个虚拟机，取决于物理服务器的能力/容量。
一旦虚拟机管理程序失效，所有虚拟机停止运行。导致失效的一个根源是，IaaS基础设施专业公司无法确定一台物理服务器能托管运行多少个虚拟机。提供商未能精确核实服务器的能力/容量。他试图添加超出这台物理服务器资源极限范围的虚拟机。如果极限范围是顶多2个虚拟机，提供商又添加一个虚拟机，那么物理服务器托管的所有虚拟机就会停止运行。
为了避免这个陷阱，你需要弄清楚一台物理服务器能托管运行多少个新的虚拟机。将弄清楚的结果与IaaS提供商或IaaS基础设施专业公司对比一下。确保你备份了所有虚拟机，这是一项日常任务。
结束语
别一味依赖IaaS提供商的故障切换算法。你可以编写自己的故障切换算法，不过记得在你运行这些算法之前事先征得IaaS提供商的同意。
