docs: 优化清单可行性评估 — 30项砍到18项，35人天
This commit is contained in:
logan committed
1 parent
204dbbc66d
commit
030f3f2339
1 file changed
+149
@@ -0,0 +1,149 @@
|
|||||||
|
# 优化清单可行性评估
|
||||||
|
|
||||||
|
> 对 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 够用 |
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 关键架构决策（实施前需确认）
|
||||||
|
|
||||||
|
1. **审核引擎签名改造** — `audit(sql, db_type)` → `audit(sql, db_type, instance_id=None, db_session=None)`，加了 DB 连接才能跑 EXPLAIN。这是一个破坏性变更，需要评估影响面
|
||||||
|
|
||||||
|
2. **多级审批路由** — ticket 创建时如何匹配 workflow？方案：(A) 按 instance 关联的 workflow_id (B) 按 risk_level 查默认 workflow。建议用 (A)，instance 已有 `workflow_id` 字段
|
||||||
|
|
||||||
|
3. **执行进度存储** — 是新建 `ticket_sql_items` 表还是复用 `execute_result` JSON？建议新建表，便于查询和展示
|
||||||
Reference in new issue
Block a user