前脚阿里云崩了，还在收拾战场，后脚这二天滴滴也崩了，目前崩了的原因大家众说纷纭，有说大厂“降本增效”，把真正干活的老实人给裁了，留下一群只会做PPT的员工，有说是因为被攻击了，有说是因为更新导致的。所以对这件事情，我思考了一下，主要从发布计划和回滚计划来简单聊聊。
咱们聊聊看啊，一个完美无瑕的发布计划，都得考虑到哪些乱七八糟的变化（比如代码的改动呀，配置的扩充咧，还有那啥，数据的来回摆弄啊，各种玩意儿呢）、这些变动带来啥样的影响、咱家有没有真正做到数据和接口的平稳过渡、咱需不需要搞点啥灰度（是不是看起来很高级的样子）、灰度策略又是怎么回事儿？正常的发布流程，是不是得先干掉DDL那个讨厌鬼，然后再去兴师动众地建立MQ呢，等等等等，这里头可都是学问哦！有时候呢，变更本身可能不像开发那么费事儿，但难处就在于发布的那最后一哆嗦。所以呢，咱们开发技术方案的时候，就要提前把这些事情规划进去啦。比方说，假如开发小哥觉得某个方法名实在是不够高大上，于是乎就给人家换了个名字，这样的改变理论上不会出现编译出错的状况，但是一旦被搬到了线上，那就可能会引发在线崩溃啦，毕竟这方法可能还是别人家的插件儿呢，一下子发布出去，可能调用方就找不着北了，立刻变成了线上危机了哦。有的变更嘛，可是涉及到底层数据结构的调整呢，这个时候，有没有办法做到发布过程的平稳兼容呢，还要考虑历史数据该不该移位过去。那这个新发布的功能，到底是要用在哪种场景呢，有没有能力承受流量的冲击，是否需要极高的一致性呢。
下面呀，咱们来说说在项目回滚这档事上，需要格外留意的几点：
- 首先得明白啥叫回滚目标吧：在咱们开始动手回滚之前，最好能明确回滚的目标，保证目标跟实际情况能对号入座，别一不小心搞错了，回头发现没法补救，那就尴尬了。
- 数据这东西可得保护好：在开始回滚之前，得抓住时机，把现在手上项目的所有数据都备份下来，这样就算回滚过后出幺蛾子，还能及时恢复正常状态呢，那才是真正的稳如泰山。
- 检查代码质量，谁也不能掉链子：回滚过程中难免要动脑筋修改几段代码，所以啊，代码审查这活儿得勤快点儿干，确保编写出来的代码质量跟预期要求相符，尤其是那些可能跟业务判断紧密相关的异常处理方法，更是千万不能马虎大意。
- 回滚之后还得测试！：回滚完了之后呀，对系统进行测试这事儿可不能落下，得看看恢复之后的系统功能、性能之类的，是否真的达到了预期效果，而且还不能有任何一丁点儿问题，这才算是大功告成。
- 遇事沉着冷静：回滚过程中，那可是小菜一碟呢，说不定就会遇到各种各样的意外情况，比方说程序崩溃，数据丢失啥的，遇到这种事儿得保持淡定，妥善处理，防止他们扩大化，影响到整个系统的稳定性。
- 回滚完了，版本管理得做好：回滚完之后啊，每个版本都要有个地方落脚，方便将来需要的时候能随时把他们请回来。平时咱们一般采用分叉功能或者利用 revert 和 reset 指令等手段来搞定版本管理任务。
- 回滚过程中的每一步，都得有记录：回滚的过程中，所有的操作和数据变化都得留档备查哦，这样碰到啥疑难杂症，回头随时就能拿出来翻阅查看，作为参考依据啦。
总而言之啊，为了保证项目回滚的顺利进行，取得圆满成功，增强日后项目开发的驱动力，我们在进行项目回滚的过程中，必须得小心翼翼，明确目标，做好数据备份工作，保证代码质量，对回滚后的系统进行全面测试，紧盯各种异常情况，做好回滚后的版本管理工作，同时还要将回滚过程详细记录下来。只有这样，才能让我们的项目回滚之路倍感顺畅，成就辉煌呀！
