应用部署、监控和自动测试

变更的恐惧

当线上的发布开始，或许运维人员只是轻点了一下鼠标，然而过了几十秒，突然的交易下跌伴随着客服电话疯狂涌入。

然而，即使收到异常通知，不论是监控报警还是不幸的客户投诉，运维人员惊讶地发现，软件回滚完全没有效果。

究竟是什么出了问题？

• 发布平台的回滚功能异常？

• 回滚方案中的脚本错误？

• 数据库、缓存中的错误数据无法恢复？

• 是什么导致了新部署的软件无法正常工作，明明已经测试过了啊！！！

隐患

很多时候，管理者认为把开发和运维分离，由不同团队负责是有好处的:

• 权限被掌握在少数运维操作者手中，容易查出是谁操作或怎么操作错误

• 由于变更人员有限，实际上无形中使得变更无法频繁进行，或许也是保证线上稳定的一种方式

然而，运维人员没有实际的开发代码，很多时候疲于救火，也没有精力和动力去仔细推敲每个参数。这是很多故障隐患的开始。

没有预演过升级发布，直接拿线上系统”一把梭”，那是在赌”代码质量和线上的坑”。或许平台还有兜底，运气好还能回滚。然而，运气不会每次都站在你这边。

持续集成和持续测试

应用在部署到生产环境之前，应该持续自动化测试，同时应该经过多重部署环节：

• 开发环境

• 测试环境

• 金丝雀环境

• 灰度环境

• 生产环境

在每个部署环境下，都要实现自动的测试，来实现发现和预期不同的异常，进一步分析和排除故障。

在金丝雀之后的环境，需要部署严密的监控，不仅仅是简单的服务运行监控，而是要结合到业务逻辑，能够自动发现业务异常。

在发布的多个步骤中，每个环节都要有自动化的监控和自动测试，以便发现某个步骤引发的异常。越是早发现异常，损失越小，也更容易恢复。

线上变更需要有自动执行的方案，以及每一步能够无损的回滚方案。

更多的残酷现实

然而现实世界真的很残酷：

• 软件缺陷

  • 代码缺陷导致应用重启有一定概率启动失败。

  • 程序启动后，加载参数和实际服务正常需要一定时间，此时不能有业务流量进入，否则报错。也许会更糟，程序甚至会奔溃。

  • 多个服务之间有依赖，当应用A更新时，应用B的数据需要重新刷新；然而推送到数据中心的参数，应用B不会自动更新，需要重启B才会下载。诸如此类的意大利面式的依赖运维人员知道么？即使明确了关系，然而没有自动化工具，依赖人工操作，错误的可能性非常高。

待续

想到一点我会更新一点…