什么情况下需要回滚？

镜像更新、版本发布、配置推送、数据修改、上下游发布、多模块发布导致线上出现数据异常、服务异常，影响到了正常的服务提供，这个时候需要进行回滚。

什么情况下可以重试？

比如数据修改导致的异常，我们可以重刷数据。

非核心业务如果第一时间知道是哪里的问题，可以考虑快速修改发布恢复服务，反之快速回滚。

回滚的时候需要考虑是不是上下游都进行了发布，可能需要链路回滚，甚至于拓扑回滚。

回滚什么？

镜像回滚

现在容器技术非常火，所以很多时候我们都会采用镜像打包，容器部署，我们需要给镜像打上版本，可以在出现问题时，快速回滚到稳定的镜像版本。

发布回滚

通过发布系统，我们可能发布了一个新版本，可以快速回滚到上一个版本，当然发布系统里我们一般备份最近的20-30个版本的安装包，可以通过回滚功能快速的进行回滚到我们想要的稳定版本。

配置回滚

很多时候我们会将动态配置存放在配置中心，如果因为我们更改配置导致业务出现问题，我们就需要通过配置中心进行配置回滚。因此我们的配置中心需要支持版本历史和快速回滚功能。

数据回滚

很多时候我们会通过接口、任务、脚本进行数据修复，但是这种修改还是存在很多弊端的，我们需要记录下来数据变更的历史，方便我们快速回滚。

这里考虑实现一个数据镜像的功能，可以通过实现mybatis插件，或者aop方式实现数据拦截，进行数据备份，记录修改前后的数据，该功能也可以借鉴seata，当然我们不需要事务操作，仅仅是记录链路变更日志，可以方便整体数据的回滚。

如果是通过脚本或者SQL修改的数据，我们也可以考虑通过binlog的方式进行数据的备份，出现问题，搜索历史生成回滚SQL，快速回滚数据。

链路回滚

链路，一般是一条上下游的完整链路，有相关的依赖，如果出现故障，我们需要分析是自己上线导致的，还是上下游哪个服务上线导致的，如果回滚自己不行，查看是否上下游都进行了发版，需要按顺序依次回滚。

拓扑回滚

拓扑回滚简单来说就是回滚到上一个稳定的版本，最近的所有发布都回到当时的稳定版本。需要定期进行拓扑备份，知道各个模块的稳定版本。这里有一个前提，就是数据相关没有涉及到重大修改，否则我们是无法进行这种方式回滚的，只能硬着头皮顶上去，修复问题。

灰度的重要性

配置灰度、灰度发布在我们生产环境是非常重要的，以配置灰度为例，我们可以先让新配置在一台机器进行生效，确认没有问题，我们再全量推送，防止大范围的业务故障。

把问题扼杀在摇篮

自动化测试流程、增量测试、覆盖测试等等都要有。

发布的时候要有代码审核、功能审核等多层审核机制。

发版的时候进行IM消息推送，上下游依赖方进行周知，推送消息可以包括

什么服务，

更改了什么，

影响范围是什么，

回滚方案是什么，

紧急联系人是谁。