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