OCP 参数审计与修正脚本 ocp_params.py（附 4 个 OCP 实测）-尧图网络科技

「勇敢 DBA 不怕困难」· 数据库爱好者，顺手折腾 AI 和工具。

ocp_params.py 是一个 OCP 参数审计与修正工具。单文件、纯 Python3 标准库、零依赖，扔到任何装了 python3 的机器上就能跑，不用 pip install。

干三件事：把 OCP 里集群、租户、OBProxy 的参数捞出来跟标准值比对（查询审计），把不符合的批量改回标准（修正），改完还能一键退回原值（回滚）。

适用哪些场景

接手一套老库，想快速摸清参数现状，对照公司标准看哪些偏了
公司有参数标准规范，要批量核查、批量整改（参数标准化治理）
定期巡检或节后复查，要出一份参数合规报告（甲方、审计会要）
多个 OCP、几十上百个租户，手动一个个点开查、改、核对，根本排不过来
升级、迁移之前，先把参数现状摸一遍，心里有底

用法

脚本自带帮助，-h 看全貌：

python3 ocp_params.py -h
OCP 参数审计与修正工具(集群 / 租户 / OBProxy 参数  查询 + 修正)用法:python3 ocp_params.py init           生成默认 config.py(首次使用)python3 ocp_params.py                查询参数, 输出 CSV(标 ✓/✗) + summary.log(失败归类)python3 ocp_params.py -v             详细模式: 屏幕显示并发自适应/每租户详情python3 ocp_params.py fix            dry-run: 显示修改计划python3 ocp_params.py fix --apply    执行修改(交互确认)python3 ocp_params.py fix --force    跳过 CSV 校验(手动编辑过 CSV 时用; preflight 仍复核)python3 ocp_params.py fix --dir <目录>   指定用哪个审计目录的 CSVpython3 ocp_params.py rollback [fix目录]   回滚: 把参数改回原值python3 ocp_params.py -h | --help    显示本帮助

首次使用没有 config.py，直接跑查询会自动生成一个默认配置，编辑里面的 OCP 地址/密码和参数清单后再跑。

参数清单在 config.py 里自己配，一行一条，作用域|参数名|标准值：

集群|system_memory|30G
集群|data_disk_usage_limit_percentage|100
租户|ob_query_timeout|1800000000
租户|open_cursors|300
obproxy|proxy_mem_limited|16G

脚本不写死任何参数，标准值换成你们公司自己的就行。

实测效果（4 个 OCP）

下面是一次真实生产的执行记录。

查询——一条命令，4 个 OCP 同时跑，15.2 秒扫完 3003 个参数点（集群 75 + 租户 2898 + OBProxy 30）。终端汇总：

[INFO] 集群参数:  符合 ✓ 55    不符合 ✗ 20
[INFO] 租户参数:  符合 ✓ 2084    不符合 ✗ 814   (失败 99: 缺密码 59 / 连接 40)
[INFO] OBProxy :  符合 ✓ 22    不符合 ✗ 7
✅ 完成  集群参数 75 行 / 租户参数 2898 行 / OBProxy 30 行
⏱ 执行了 15.2 秒

不符合合计 841 个，不符率约 28%。另有 99 个租户没拉到值，脚本自动归类（缺密码 59、连接失败 40），单独列在 failed_tenants.csv，不混进"不符"也不算"成功"。

修正——fix --apply，手打 yes 确认后改 841 个动态参数。提交阶段撞了一批可重试错误（脚本把这类"非备库只读、能再试"的失败统一标成 COM20003），自动多遍重试：

[====] 第 1 遍提交完成: 成功 663 / COM20003 重试 178 / 其他失败 0
[====] 第 2 遍提交完成: 成功 167 / COM20003 重试 11 / 其他失败 0
[====] 第 3 遍提交完成: 成功 11 / COM20003 重试 0 / 其他失败 0
[====] 提交阶段完成: 共提交成功 841 个(集群/租户 831 + OBProxy 7 已验证), 耗时 389.8 秒

三遍累计 663 + 167 + 11 = 841，全部提交成功。校验阶段 436 个桶回读全过（5.8 秒），真成功 841、静默失败 0、PUT 失败 0，零失败。全程约 405.5 秒，不到 7 分钟；需重启参数 0（全在线改，不停业务）。

改之前，每个参数的原值会 fsync 落盘到 rollback.csv，还会重新连一次 OCP 复核当前值没被别人动过；不满意，一条 rollback 退回去，退完还能再退回来。

几个关键设计

最想说的是改动双重留痕：

OCP 侧留痕——所有修改走 OCP 的 API（不直连库改），OCP 的变更历史会记录每一笔：几点几分、谁、从什么值改成什么值。事后在 OCP 后台查得到，出合规报告、做审计，直接拉变更历史就行。
脚本侧留痕——脚本这边也会把每次改动的原值、新值、生效方式、时间记下来（原值在改之前就落盘），全量修改日志也留着。两边各记一份，互相对得上。

每一次改动都可追溯、可复盘：谁改的、什么时候改的、原来是什么、改成了什么，查得清楚。对要交付合规报告的场景，这一条很关键。

还有几个设计：

改之前，原值 fsync 落盘（断电都不丢），改之前还会重新连一次 OCP 复核当前值没被别人动过（防陈旧覆盖）
一键 rollback 回滚，退完还能再退回来
自适应并发：撞 429/5xx 自动降、跑顺升，同一个集群同一个租户的参数打包成一个请求批量改，不打架也不打挂 OCP
参数清单在 config.py 里配，不写死；零依赖，一个文件直接跑

输出文件

查询：ocp_params_<时间戳>/ —— cluster_params.csv / tenant_params.csv / obproxy_params.csv / failed_tenants.csv / raw/（原始 JSON）/ run.log（全量日志）/ summary.log（简化）
修正：fix_<时间戳>/ —— rollback.csv（原值记录）/ fix.log / fix_summary.log / fix_failed.csv
回滚：rollback_<时间戳>/ —— rollback_again.csv / rollback.log

CSV 里每个参数后面标 ✓ 或 ✗，对得上、对不上一目了然，可直接当合规报告交。