防止云计算程序“卡壳”的十二个建议

云程序之间的关联通常都比较松散，程序本身通常都不大，非常简单而且各自独立。但在实际的云计算项目部署中，全城大堵车式的云计算停滞和卡壳依然可能会发生。

在科幻电影中，未来的城市交通工具在天上地下的三维空间运行，似乎人类终将会解决城市堵车问题。在云计算的科幻小说中，云应用的部署将异常平滑和舒爽，简单到只需要按下按钮。对于不依赖外部系统或第三方应用的单一程序部署来说是可信的，但是对于复杂的云部署来说，要想防止云停滞和卡壳，你最好还是参考以下十二条建议。

1. 检查人员资质。要想避免“云卡壳”和“云事故”，云计算管理人员的认证非常重要（大多数情况下甚至比开发认证更重要）。
2. 让你的scrum团队对变更采取流程化的架构评估。一些看上去非常“无辜”的改变，例如访问控制、生效规则，甚至Picklist值的改变都可能会导致严重的反应。尤其当你有多个scrum团队并行工作的时候，这些改变会导致麻烦。
3. 尽量使用在其他云技术项目中使用过的配置管理工具，如果没有，那就是用可管理版本的文档服务来跟踪变更。谷歌文档其实很不错，尤其适合用静态文件存档，而且每周更新一次的情况。
4. 为所有的模块进行单元测试，测试率要在90%以上，主要的验证和反正测试要进行Assertion test。对于核心的业务逻辑，考虑采用test-driven开发模式。
5. 每天都进行单元测试并记录结果。因为你的SaaS平台或者第三方软件有可能发生了改变而你并没有察觉到。如果任何单元测试失败，立刻找scrum团队作为最高优先级处理。
6. 使用ANT或类似的脚本引擎，试着遵循Agile的连续集成（Continuous Integration）最佳实践。
7. 运行系统级测试，用样本数据调用所有外部接口，对数据库进行统计检查。
8. 至少每周全部运行一次系统测试，即使代码没有改变。因为不仅平台和第三方软件可能发生变化，你的系统数据的扩张或变动也可能触发新的代码路径。所有失败的测试都应当返回scrum团队做最高优先级处理。
9. 运行多个沙盒，并经常同步和刷新，这应当成为scrum团队日常工作表的规定任务。
10. 建立系统管理配置实践规则，防止实验性的改动在试验后依然存在。
11. 进行控制，防止对沙盒和生产系统（production system）进行没有文档记录的改变。
12. 设立控制规则，防止变更直接作用于生产系统。

Via CIO