回滚过程要迅速、禁得起考验
  这个怎么讲?是我随时都可以轻松地回滚到某个版本。这里有这么几点要把握。
  · 任性。只要我发现有问题可以回滚。哪怕是在上线途中都可以终止上线。然后进行回滚。
  · 轻松。首先心态要平和。回滚应该是一个轻松的过程,至少有种我们避免了更严重的线上事故,把问题消灭在萌芽中的感觉。而不是一听说要回滚版本想到了扣工资。其次是过程要轻松。上线是点几个按钮完成了,那么回滚也应该是点几个按钮完成的事。这要求我们的上线系统、上线过程、甚至上线代码都要达到一定的标准。比如如果上线还要手动去改个字段,那么回滚呢?是不是还要手动去删个字段?如果删字段的时候手抖了怎么办?这都是上线之前应该考虑好的事情。我们一定要避免只能自动上线不能自动回滚的场景。
  · 迅速。尽量降低上线和回滚的时间。把上线和回滚的过程都保证在一定的时间内完成。这是很有意义也很有必要的。如果时间很长,要考虑系统拆分和更好的部署方案。
  · 无损。尽量降低上线和回滚对线上服务的负面影响。上了一次线,把线上几百万用户都踢出去了,或者回滚一次把用户的钱给弄丢了几百万,这都是不能接受的。
  · 标准化。所有的服务或者站点都有一致的回滚体验。尽量的把项目的上线和回滚标准化。每个项目都可以找出 N+1 个理由来说自己的项目与其它的项目多么的不同,是多么的特殊。这不重要,重要的是项目做的时候要做成高内聚低耦合的。在完成项目功能的同时完成上线脚本与回滚脚本。
  灰度发布很有必要
  灰度发布也叫金丝雀部署,因为经常与A/B测试仪器使用,有的时候也叫A/B发布。这在业界已经是相当成熟的做法,很多公司都在使用。这里不累述了。可以参考这篇文章。
  《微服务部署:蓝绿部署、滚动部署、灰度发布等部署方案对比与总结》
  部署和回滚过程都要有相应的操作记录和日志文件
  我们相信所有的人员都是善意的,所有人都是想把自己的事情做好,但是难免有得时候犯2出现错误。有详细的记录不是为了追责,而是为了让我可以事后复盘,事后分析到底错误出现在哪里,以后怎么避免类似的错误发生。如果同样的事情可以自动化来避免,那么可以做到发布平台里,那我们改进系统;如果系统都已经做的很好,只是有的点不太熟悉,那么我们要完善知识的管理和传播,相应的知识点和注意事项文档化、例行化。让熟悉的人来讲这块的内容,大家都明白了背后的原理、来龙去脉,以后照着wiki 去做可以了。