工作中经常被吐槽:“不就执行一个删除字段的SQL的自动化工单吗？搞起来有这么复杂？”
那就来梳理梳理这样的一个工单的执行需要什么的流程:
简要流程步骤:
1. 申请权限管控
2. 工单发起流程
3. 接口校验流程
4. 审核流程
5. 执行流程
6. 回滚流程
下面就顺着这个流程梳理一下:
- 权限管控
要确定什么样的同事有发起这样变更的权限，比如数据库负责人，数据库开发者或者被数据库管理员(开发团队)赋予变更权限的其他权限类成员角色。
- 工单发起流程
确定在这个申请工单里，需要开发同事填写什么样的内容，并且尽可能少的填写，减少不必要的填写，以免引起工单申请的耗时。基本可以确定填写要素有数据库名，需要执行的删除SQL，删除原由。
- 接口数据校验流程
针对开发填写的内容需要根据数据库权限接口获取申请者是否有该库的权限，没有权限需要提示申请相关的权限；填写的SQL需要对SQL做合法性校验，如:是否符合SQL语法，是否该字段存在。
另外,还有需要一个监控数据的接口:
DBA通过全量SQL的监控，确认待删除的字段没有被使用到，否则不能直接删除，需要提醒申请者存在使用并重新确认是否需继续删除。
- 审核流程
根据核心库表和表数据量大小确定需要的审核流，如:一些不重要的小表等只需要申请者直属领导或者业务开发线管理员指定有审核权限的同事审核即可。对于一些核心表的变更，可能需要审核流程再多一层高级领导审核。
- 执行流程
这是一个比较重要的流程。
如何执行
删除字段操作，可以直接使用数据库的原生执行方式进行变更。也可以使用第三方的工具进行变更，如:GHOST工具、PERCONA的PT工具的PT-OSC执行删除命令。
何时执行
执行的时候要考虑当前集群的一些状态数据，如:剩余磁盘空间、threading_running、锁等。
- 回滚流程
虽说通过监控已经确定没有字段级别的使用，但是保不准会有反悔的情况存在。
对于不同的删除方式，回滚的手段和时效也不一样。
直接删除字段需要回滚，通过重新新增字段，在使用各类恢复数据的手段，数据的恢复时间会和表的大小相关。
使用先将字段改名的方式，可以快速的回滚变更。在自动化的运行过程中，这种操作可以先将字段修改，并存入一个任务队列(表存储)，等一周或者约定的时间之后还没有回滚需求，在通过JOB轮训该队列，将改名后的字段进行删除，达到实际删除。这种操作方式需要确定线上不能使用select *等SQL语句使用。
一个删除操作，说简单也简单说复杂也复杂，还是需要运维小伙伴、系统设计者能想到方方面面，对开发的使用能有个好的指导，同时也可以释放运维小伙伴的时间。
