成都系统二次开发只要做到全量备份、开发库与生产库隔离、灰度发布和明确回滚阈值，原有数据不会受影响。出问题的项目几乎都是同一个原因：直接在生产库上改、改完没有验证就全量上线、出问题了不知道怎么退。把这三个环节管住，二次开发和原有数据安全并不矛盾。

备份要做到什么程度

"我们备份过了"这句话在二次开发场景里基本等于没说。成都真正能救命的备份要满足三个条件：备份是完整的、备份是可恢复的、备份和生产环境物理隔离。三个条件缺一个，关键时刻就掉链子。

全量备份加增量备份

动生产数据前，先做一次全量备份：数据库全量导出、应用服务器快照、配置文件单独拷贝。之后每完成一批改动做一次增量备份。成都备份文件要存到和生产服务器不同的存储上，不能图方便放在同一台机器的另一个目录。备份完要做一次恢复演练，随机抽一张表恢复到测试库，确认数据能读出来、条数对得上，否则备份文件可能是坏的。

备份保留多久

二次开发相关的备份建议保留至少三个月。如果是涉及数据库结构变更的大改动，备份要保留到新系统稳定运行一个月以后。成都不少企业备份做完就删，结果两周后发现某个数据改错了，想退都退不回去。另外，备份文件要定期做恢复演练，不能只存不验，真要用的时候发现备份损坏就晚了。

开发环境与生产环境隔离

这是保护原有数据最核心的一条。成都出数据事故的项目里，超过一半是因为开发直接连了生产库改东西。正确做法是：开发在独立的开发库上做，测试在测试库上做，生产库只在正式发布时才碰。

用脱敏数据做开发

开发库的数据要从生产库导出来，但不能直接拿真实数据。客户姓名、手机号、身份证号这些敏感信息要脱敏处理，替换成假数据。成都这不仅是数据安全要求，也是合规要求。功能逻辑测试用脱敏数据足够了，不需要看到真实客户信息。脱敏后还要检查一遍，防止个别表忘了处理，把真实数据带到开发环境，被无关人员看到。

发布流程怎么走

从开发库到生产库，要走"开发库—测试库—预发布库—生产库"四级流程，不能跳。每一级都要验证数据结构变更脚本有没有问题。表结构变更（加字段、改类型）要先写在脚本里，在测试库跑通后再拿到生产执行，不能让开发人员直接登录生产库手敲SQL。

回滚阈值怎么定

任何一次发布都要提前想好"什么情况下退回来"。成都没有回滚预案的发布就是赌博。

哪些操作必须可回滚

数据库结构变更必须可回滚：加字段要准备删字段脚本，改表要准备恢复原表结构脚本。数据批量更新要先把被更新的行备份成临时表，万一改错了可以从临时表恢复。应用发布要保留上一个版本的部署包，发现问题立刻切回去。

灰度发布观察期

不要一次全量发布。先放百分之十的用户用新功能，观察半小时到一小时，看日志有没有报错、用户有没有反馈问题，再逐步放大。成都如果灰度期间出现以下任一情况立即回滚：错误率超过百分之一、核心接口响应时间翻倍、出现数据不一致。

出问题谁来决策回滚

回滚不能等出了事再开会讨论。要提前定好规则：达到回滚阈值时，现场技术负责人有权直接回滚，不需要层层请示。成都不少数据事故不是因为没预案，而是出了问题后大家犹豫"要不要再观察一下"，等决定回滚时已经改了一半数据。授权要前置，决策要果断。

二次开发和数据安全并不矛盾，关键是把备份、隔离、回滚这三件事做在前面。成都只要流程规范，二次开发期间业务正常跑、数据不丢，完全可以做到，员工也不会因为系统升级而担心历史数据出问题。怕的是图省事跳过规范环节，出了事故再补救。成都企业若需建立二次开发的数据安全规范，可咨询良将科技，按步骤逐项落地，不要省环节。