回滚的能力一般是由发布系统提供，当发布系统不具备回滚能力或者发布场景很复杂时，需要额外增加回滚方案的设计。
无论是系统自带的回滚能力，还是额外增加回滚方案，往往都不在整个上线发布的主流程中，不容易引起研发或者测试同学的重视。
如果在发布过程中遇到了问题，而没有经过验证的回滚方案，往往会导致原本应该很快通过回滚解决的问题，因为回滚不能及时执行造成问题升级，或者回滚的逻辑错误引起了更大的问题。
比如系统自带的回滚能力，如果平时没有实际使用过，在实际执行回滚操作的时候，发现回滚操作的执行逻辑和自己预期的逻辑不一致，或者缺少权限，导致回滚不能及时执行下去。或者理解错误了回滚的逻辑，以为系统执行的是全量回滚，但实际只回滚了增量部分，而增量部分的回滚，不能解决问题。
如果是未验证的回滚方案，在执行回滚的时候，会出现回滚逻辑并不是发布逻辑的逆操作，或者有的回滚方案，不能简单的逆操作能够解决，反而引起更大的线上问题。
【最佳实践】
研发同学在首次使用发布系统正式发布之前，需要先熟悉整个发布系统的功能，包括回滚的操作。
通过对测试版本的回滚操作，熟悉整个回滚流程，回滚逻辑。如果有相应的权限，需要提前申请好对应的权限，从而做到在真正需要执行回滚操作的时候，能够快速正确的完成版本回滚，及时止损。
复杂业务发布上线，需要把回滚方案纳入技术方案评审，功能测试的范畴。在正式发布上线前，需要对回滚也做一次预演，以确保回滚方案是正确的。
如果发布系统做了较大的改动，需要把回滚功能纳入测试范畴，回滚逻辑要具备连续性，特使是在权限控制上，要和原来保持一致。避免发布系统的改版，引起原来可以正操操作的回滚变更不可执行，延误问题的修复时间。