防止云计算程序“卡壳”的十二个建议
云程序之间的关联通常都比较松散,程序本身通常都不大,非常简单而且各自独立。但在实际的云计算项目部署中,全城大堵车式的云计算停滞和卡壳依然可能会发生。
在科幻电影中,未来的城市交通工具在天上地下的三维空间运行,似乎人类终将会解决城市堵车问题。在云计算的科幻小说中,云应用的部署将异常平滑和舒爽,简单到只需要按下按钮。对于不依赖外部系统或第三方应用的单一程序部署来说是可信的,但是对于复杂的云部署来说,要想防止云停滞和卡壳,你最好还是参考以下十二条建议。
- 检查人员资质。要想避免“云卡壳”和“云事故”,云计算管理人员的认证非常重要(大多数情况下甚至比开发认证更重要)。
- 让你的scrum团队对变更采取流程化的架构评估。一些看上去非常“无辜”的改变,例如访问控制、生效规则,甚至Picklist值的改变都可能会导致严重的反应。尤其当你有多个scrum团队并行工作的时候,这些改变会导致麻烦。
- 尽量使用在其他云技术项目中使用过的配置管理工具,如果没有,那就是用可管理版本的文档服务来跟踪变更。谷歌文档其实很不错,尤其适合用静态文件存档,而且每周更新一次的情况。
- 为所有的模块进行单元测试,测试率要在90%以上,主要的验证和反正测试要进行Assertion test。对于核心的业务逻辑,考虑采用test-driven开发模式。
- 每天都进行单元测试并记录结果。因为你的SaaS平台或者第三方软件有可能发生了改变而你并没有察觉到。如果任何单元测试失败,立刻找scrum团队作为最高优先级处理。
- 使用ANT或类似的脚本引擎,试着遵循Agile的连续集成(Continuous Integration)最佳实践。
- 运行系统级测试,用样本数据调用所有外部接口,对数据库进行统计检查。
- 至少每周全部运行一次系统测试,即使代码没有改变。因为不仅平台和第三方软件可能发生变化,你的系统数据的扩张或变动也可能触发新的代码路径。所有失败的测试都应当返回scrum团队做最高优先级处理。
- 运行多个沙盒,并经常同步和刷新,这应当成为scrum团队日常工作表的规定任务。
- 建立系统管理配置实践规则,防止实验性的改动在试验后依然存在。
- 进行控制,防止对沙盒和生产系统(production system)进行没有文档记录的改变。
- 设立控制规则,防止变更直接作用于生产系统。
Via CIO
第一时间获取面向IT决策者的独家深度资讯,敬请关注IT经理网微信号:ctociocom
除非注明,本站文章均为原创或编译,未经许可严禁转载。
相关文章: