11 KiB
11 KiB
优化清单可行性评估
对 OPTIMIZATION_PLAN.md 逐项评审，结论：可行但有水分，需要砍掉/合并部分项
标记：✅可直接做 ⚠️需要架构调整 ❌过度设计建议砍掉
总体结论
| 维度 | 评估 |
|---|---|
| 方向正确性 | ✅ 6 个方向都是真实的运维痛点 |
| 工作量估算 | ⚠️ 偏乐观，56 人天实际可能 80+，因为很多项需要改 audit 方法签名（目前不接受 DB 连接） |
| 架构瓶颈 | ⚠️ 审核引擎是纯静态分析（只看 SQL 文本），要加 EXPLAIN/影响分析需要大改 |
| 过度设计项 | ❌ 约 8 项（见下文），属于「有了更好但不是刚需」 |
| 实际建议 | 砍到 18 项，分 3 阶段，约 35 人天 |
逐项评审
一、假阳性/假阴性治理
| # | 评估 | 理由 |
|---|---|---|
| 1.1 审核结果反馈机制 | ⚠️ 可做但优先级降低 | 需要新表 + 前端改动，但价值在「长期优化」，前期没有足够数据量来统计误报率。建议后期做 |
| 1.2 上下文感知规则 | ✅ 核心价值 | 同一条 ALTER TABLE，小表 WARNING 大表 ERROR，这才是减少假阳性的关键。但实现难点：审核引擎目前没有 DB 连接，需要改 audit() 方法签名，加 instance_id 参数 → 查表行数 |
| 1.3 规则分组白名单 | ⚠️ 合理但可简化 | 不需要 instance_rule_override 表，直接在现有 audit_rules 表加 scope 字段（instance_id NULL=全局，非 NULL=实例级覆盖） |
| 1.4 PG 审核规则补全 | ⚠️ 可以做 | 但 PG 用户量通常远小于 MySQL，优先级可以降低。先补 10 条核心规则就够 |
| 1.5 MongoDB 审核规则 | ❌ 砍掉或极简 | MongoDB 工单场景极少（大部分是 Redis + MySQL），先只做 dropDatabase 拦截一条就够 |
| 1.6 规则测试基准 | ⚠️ 有价值但量大 | 117 条 × 3 case = 351 个测试。建议只给 ERROR 级别规则写测试（约 20 条 × 3 = 60 个） |
二、大 SQL / 复杂语句处理
| # | 评估 | 理由 |
|---|---|---|
| 2.1 SQL 复杂度评分 | ⚠️ 有一定价值 | 但 JOIN 数/子查询层数对 DBA 审批帮助有限。简化版：只算 SQL 长度 + 语句条数就够了 |
| 2.2 审核超时保护 | ✅ 必须做 | 正则/解析卡死会拖垮整个审核。asyncio.wait_for(audit(), timeout=5) 即可，半天工作量 |
| 2.3 审核缓存 | ❌ 砍掉 | 同一 SQL 重复审核的场景极少（工单每次 SQL 都不同），LRU 缓存是过度优化 |
| 2.4 MongoDB Pipeline 复杂度 | ❌ 砍掉 | 同 1.5，MongoDB 工单场景少 |
| 2.5 SQL 格式化展示 | ⚠️ 可做但不是 P0 | 前端已有 CodeMirror，高亮问题位置需要额外 parser 工作。放 P2 |
三、事务一致性
| # | 评估 | 理由 |
|---|---|---|
| 3.1 执行进度透明 | ✅ 核心价值 | 多条 SQL 逐条记录状态，审批人能看清哪条成功哪条失败。现有 _split_statements 已有框架，改动不大 |
| 3.2 部分失败处理策略 | ✅ 必须做 | 3 种模式（遇错停止/跳过继续/整体回滚）覆盖所有场景。MySQL 已有 transaction，PG 已有 transaction()，加上策略枚举即可 |
| 3.3 自动回滚 SQL 生成 | ❌ 砍掉 | INSERT→反向 DELETE 看似简单，但 UPDATE 的反向需要 SELECT 旧值，DDL 不可逆。业界 Yearning/Archery 也只做了 INSERT 回滚，做了半吊子反而危险。不如做成「执行前手动填写回滚 SQL」 |
| 3.4 Redis MULTI/EXEC | ⚠️ 可做但简化 | Redis Pipeline（非事务）已经能批量执行，MULTI/EXEC 在跨 slot 时会失败。用 pipeline 就够 |
| 3.5 跨库事务标记 | ✅ 简单有效 | 前端/通知加一个警告标签，半天工作量 |
四、锁表与业务影响分析
| # | 评估 | 理由 |
|---|---|---|
| 4.1 EXPLAIN 预检 | ⚠️ 核心价值但实现复杂 | 最大难点：审核引擎是纯静态分析，audit(sql, db_type) 没有 DB 连接。要跑 EXPLAIN 需要：(1) 改 audit 方法签名加 instance_id (2) 审核时建临时连接 (3) 执行 EXPLAIN (4) 解析结果。涉及连接池管理、超时处理、权限控制，实际工作量 5d 起步 |
| 4.2 大表 ALTER 检测 | ⚠️ 同 4.1 的前置问题 | 需要查 information_schema，同样需要 DB 连接。但可以做成「创建工单时」而非「审核时」查询，利用 ticket endpoint 已有的 db session |
| 4.3 影响行数预估 | ⚠️ 与 4.1 合并 | SELECT COUNT(*) WHERE <condition> 就是 EXPLAIN 的简化版，不需要分开做 |
| 4.4 执行时间预估 | ❌ 砍掉 | EXPLAIN 的 rows × 历史耗时 = 极不准，给用户错误预期反而有害。不如只给「快/慢」二分 |
| 4.5 执行超时强杀 | ✅ 已部分实现 | asyncio.wait_for(cur.execute(stmt), timeout=xxx) 已有。补充 MySQL 的 max_execution_time hint 和 PG 的 statement_timeout SET 即可 |
| 4.6 维护窗口控制 | ⚠️ 简单有效 | 配置项 + 中间件检查，1d 工作量 |
五、敏感操作审核强化
| # | 评估 | 理由 |
|---|---|---|
| 5.1 工单风险等级 | ✅ 基础能力，必须先做 | Ticket 模型已有 priority 字段，直接复用或加 risk_level。根据 SQL 类型 + 操作对象自动计算，是后续多级审批的基础 |
| 5.2 多级审批流 | ⚠️ 架构已有但逻辑未通 | WorkflowStep 已有 step_type=serial/parallel/any_one/condition，但 ticket 创建时没有关联 workflow_id。需要补上：ticket 绑定 workflow → 按 risk_level 匹配不同审批流 |
| 5.3 高危操作二次确认 | ✅ 简单有效 | 前端弹框要求输入工单编号，半天工作量 |
| 5.4 敏感表保护 | ⚠️ 可以做但配置繁琐 | 需要维护「保护表清单」，DBA 愿意配置才行。先做成全局配置（protected_tables: ["user","password","order","pay"]） |
| 5.5 执行前备份 | ❌ 砍掉 | CREATE TABLE xxx_backup AS SELECT * 对大表会锁表 + 占空间，与要解决的问题矛盾。改成建议提示「请手动备份」更实际 |
| 5.6 MongoDB 危险操作 | ❌ 合并到 5.1 | dropDatabase 在风险等级计算里处理即可，不需要单独做 |
六、数据脱敏与审计
| # | 评估 | 理由 |
|---|---|---|
| 6.1 通知脱敏 | ✅ 简单有效 | 模板里 {sql_preview} 已经是截断的（取前 100 字符），但需要确认 error 字段有没有泄露数据。1d 工作量 |
| 6.2 审计日志不可篡改 | ❌ 砍掉 | checksum 方案在更新/删除场景下无法自洽，需要区块链/WORM 才能真正防篡改。对内部系统来说，DB 权限控制 + 操作审计就够了 |
| 6.3 操作导出 | ✅ 实用 | AuditLog + QueryHistory CSV 导出，API 加个 endpoint 即可 |
| 6.4 审核详情脱敏 | ⚠️ 理想但实现困难 | 对 SQL 中的字面值做脱敏需要 SQL parser 精确定位值位置，正则方案容易误伤。简化版：对审批人隐藏 WHERE phone='13812341234' 中的值 |
| 6.5 会话级脱敏策略 | ❌ 砍掉 | 过度设计，现有 MaskingRule 已够用 |
| 6.6 SQL 注入检测 | ⚠️ 有价值但非 P0 | 与审核引擎结合，检测 UNION SELECT、OR 1=1、hex 编码等模式。放 P2 |
修订后实施计划（18 项 / ~35 人天）
第一阶段：安全基线（~10d）
| # | 项目 | 工作量 | 核心改动 |
|---|---|---|---|
| 1 | 5.1 工单风险等级 | 2d | Ticket 加 risk_level 字段 + 自动计算逻辑（后端） |
| 2 | 5.2 多级审批流打通 | 3d | Ticket 绑定 workflow_id → 按 risk_level 匹配 → 多步审批 |
| 3 | 2.2 审核超时保护 | 0.5d | wait_for(audit(), timeout=5) |
| 4 | 3.1 执行进度透明 | 2d | ticket_sql_items 表 + 逐条执行 + 前端实时状态 |
| 5 | 6.1 通知脱敏 | 1d | 模板中截断 SQL + 隐藏 WHERE 值 |
| 6 | 5.3 高危二次确认 | 0.5d | 前端输入工单编号确认框 |
| 7 | 4.6 维护窗口控制 | 1d | system_settings 配置 + 中间件检查 |
第二阶段：影响分析（~12d）
| # | 项目 | 工作量 | 核心改动 |
|---|---|---|---|
| 8 | 4.1+4.3 EXPLAIN + 影响行数 | 5d | 改 audit 签名 + DB 连接 + EXPLAIN 解析 + 前端展示 |
| 9 | 4.2 大表 ALTER 检测 | 2d | 创建工单时查 information_schema + 风险提示 |
| 10 | 3.2 部分失败策略 | 2d | stop_on_error / continue / transaction 三模式 |
| 11 | 1.2 上下文感知规则 | 3d | ALTER 规则查表行数动态调 severity |
第三阶段：体验完善（~13d）
| # | 项目 | 工作量 | 核心改动 |
|---|---|---|---|
| 12 | 1.4 PG 审核规则 | 3d | 补 10 条核心规则 |
| 13 | 1.3 规则白名单（简化版） | 2d | audit_rules 加 scope 字段 |
| 14 | 4.5 执行超时强杀 | 1d | MySQL SET max_execution_time + PG SET statement_timeout |
| 15 | 6.3 审计日志导出 | 2d | CSV/Excel 导出 API |
| 16 | 3.5 跨库事务标记 | 0.5d | 前端/通知警告标签 |
| 17 | 5.4 敏感表保护 | 2d | 全局 protected_tables 配置 |
| 18 | 2.1 SQL 复杂度（简化版） | 1d | 只算长度 + 语句条数 |
砍掉的 12 项
| # | 砍掉原因 |
|---|---|
| 1.1 审核结果反馈 | 数据量不够，后期做 |
| 1.5 MongoDB 审核规则 | 场景少，dropDatabase 合并到风险等级 |
| 1.6 规则测试基准 | 工作量大，改为只给 ERROR 规则写测试 |
| 2.3 审核缓存 | 同 SQL 重复审核场景极少 |
| 2.4 MongoDB Pipeline 复杂度 | 场景少 |
| 2.5 SQL 格式化展示 | 前端 CodeMirror 够用 |
| 3.3 自动回滚 SQL 生成 | 做半吊子反而危险 |
| 4.4 执行时间预估 | 不准，给错误预期 |
| 5.5 执行前备份 | 大表备份本身锁表 |
| 5.6 MongoDB 危险操作 | 合并到风险等级 |
| 6.2 审计日志不可篡改 | 内部系统不需要区块链 |
| 6.5 会话级脱敏策略 | 现有 MaskingRule 够用 |
关键架构决策（实施前需确认）
-
审核引擎签名改造 —
audit(sql, db_type)→audit(sql, db_type, instance_id=None, db_session=None)，加了 DB 连接才能跑 EXPLAIN。这是一个破坏性变更，需要评估影响面 -
多级审批路由 — ticket 创建时如何匹配 workflow？方案：(A) 按 instance 关联的 workflow_id (B) 按 risk_level 查默认 workflow。建议用 (A)，instance 已有
workflow_id字段 -
执行进度存储 — 是新建
ticket_sql_items表还是复用execute_resultJSON？建议新建表，便于查询和展示