数据订正，是指为保证软件正常运行而直接修改数据的运维方式。它像英雄，在千疮百孔的软件系统中救各方于水火，却又像恶魔，在系统恢复后不愿被所有人提及。数据订正如同与魔鬼签订契约，它越好用，我们对它的代价就越讳莫如深。

数据订正分为功能订正和Bug订正。功能订正是指弥补因系统缺失的功能而做的订正，比如基础数据配置、异常流程处理等。Bug订正是指修复因系统bug导致的错误数据而做的订正。

数据订正在运维时挺身而出，但是在项目整个周期中，它的身影就在每个干系人的脑海中频频闪现。当需求对某个“微不足道”的业务场景怎么也理不清楚时，当项目经理为工期而焦头烂额时，当开发拿着大刀站在需求列表前讨价还价时，当业务发现有笔数据无论如何也跑不通时，数据订正便如同沙漠枯井里的一瓶毒药，饥民面前的一抔观音土，让所有人都眼冒绿光，咽了咽口水。

订正原因分类

数据订正优点

1. 功能订正，可以让代码在缺失部分业务功能的情况下上线。这里有两种情况：
   1. 业务或产品对于部分异常业务流程未想好怎么处理。比如：退款、审核回退等
   2. 非核心流程来不及开发。比如运管端各种配置页面等
2. Bug订正，能够快速解决线上的问题，甚至无需查到问题原因

   数据订正缺点

3. 引发数据订正依赖症
   1. 因自带“逻辑拖延”属性，业务和产品很容易产生依赖
   2. 因自带“时间拖延”属性，开发经理和项目经理也容易产生依赖
   3. 因自带“排错和纠错拖延”属性，部分开发在运维时也容易产生依赖
4. 数据安全问题
   1. 直接操作数据库，信息安全和合规受到挑战
   2. SQL 脚本可读性不强，错误不易发现，导致错误的脚本被执行
   3. 绕过了业务校验逻辑，很容易多订或者错订，导致数据不一致
5. 订正过的数据往往缺失标记，给代码排错增加障碍
6. 订正弱化了问题根源排查的必要性，为故障扩大埋下隐患
7. 因订正的成本几乎由一线开发全部承担，因此其他各方容易忽略订正带来的工作量，大大伤害了开发的感情
8. 除了订正前的问题确认，订正中的SQL编写和流程审批，订正后的完结跟踪，对于开发工程师来说均属于毫无意义的工作内容，白白消耗精力

   解决方案

   流程规范

9. 因涉及数据安全，发起订正需要审批流程。开发应拒绝无流程的订正
10. 订正发起时要填写订正原因：功能缺失、系统Bug
11. 功能缺失流程：
    1. 建议发起人是产品或者需求
    2. 流程审批信息中需要填写需求单号
12. 系统bug：
    1. 建议发起人是测试
    2. 流程审批信息中需要填写 Bug 单号
13. 订正后要观察订正脚本是否如期运行，以及问题是否修复
14. 问题修复后，各方统计订正工作量计入工时

订正脚本规范

订正脚本中须包含备注字段：订正时间，订正申请审批单号，需求或Bug编号，原因，大致订正方法，订正人。比如：

update order_audit_info set status='WAIT_AUDIT', 
db_remark = '20220602 审批单号 XXX，需求单号 XXX，用户误操作，需要审核回退，现将审核状态由审核通过变为待审核； 张三' 
where order_no='OD202206020001'

订正提效

1. 对于简单的场景，数据库审计系统可以增加一键生成订正sql的功能
2. 代码替代sql
   1. 编写能生成订正sql的代码脚本，便于走查
   2. 开发远程执行组件，通过注入代码脚本的方式代替sql（当然要做好权限控制与审核流程）

      总结

      我们应该认识到，订正是问题的开始而非结束，是遮羞布而非万金油，订正越多，质量越差。

订正前明确问题责任，订正时尽量提高准确率和执行效率，订正后定期复盘，该加功能加功能，该修bug修bug。将其作为项目质量的一个重要指标去对待，在以后的项目中尽量避免订正的发生。

愿系统再无订正，愿世界和平。