MinIO AIops 运维

要解决什么问题

MinIO 集群一满盘，备份和写入就开始失败；桶策略是否对公网可读、生命周期是否形同虚设、纠删集还能再坏几块盘——这些问题往往散落在控制台、API 和运维笔记里，Agent 若直接调写接口又缺少统一审计与回滚依据。本技能面向 MinIO 对象存储（社区维护，与 MinIO, Inc. 无隶属关系），把日常排障与受控变更收敛到同一套 MCP/CLI 能力上。

技能如何工作

共 48 个 MCP 工具（28 读、18 写、2 个 undo），每个调用都经过内置 @governed_tool 治理：本地统一审计（默认 ~/.minio-aiops/）、token/失控预算防护、undo token 记录，以及每条审计行上的 risk tier 描述。Access Key 的 Secret 以 Fernet + scrypt 写入 secrets.enc，不在磁盘明文落盘。

读侧除 health_*、cluster_status、fleet_overview 等健康与概览外，有六类「人话结论 + 建议动作」的旗舰分析：

• capacity_rca：容量根因（近满、离线盘/节点、热点等）
• bucket_exposure_audit：暴露面排序（公读/公写、缺加密、未开版本、无生命周期等）
• lifecycle_gap_analysis：可回收空间估算（无界非当前版本、遗留 multipart 等）
• healing_health：纠删集在线盘 vs 写 quorum、 heal 积压
• diagnose_retention_gaps / diagnose_iam_exposure：WORM 保留与 IAM 暴露

写操作（策略、生命周期、配额、空桶删除、IAM、Object Lock 等）支持 --dry-run；不可逆操作另有二次确认。变更前配置会被捕获，可通过 undo_list / undo_apply 回放（部分合规保留类写入 deliberately 无 undo）。

常见路径示例：空间告警 → capacity_rca + usage_by_bucket → lifecycle_gap_analysis → 治理化清理上传/设 lifecycle；疑似公网可读 → bucket_exposure_audit → bucket_info → set_bucket_policy 并审计确认；盘故障 → healing_health 看 failureToleranceRemaining，近写 quorum 边缘时先换盘再动数据。

适用边界

• 只针对 MinIO；Ceph/RGW 用 ceph-aiops，TrueNAS 用 truenas-aiops，其它基础设施选对应 AIops-tools 技能。
• 本工具不负责授权决策：能否写入取决于 Agent 判断或所连 Access Key 的 IAM；只读策略会在服务端拒绝写。保证的是 每次调用都有审计，而非内置只读开关或审批门。
• 容量根因若是 DRIVES_OFFLINE 而非真实数据增长，应先恢复纠删集健康，不要在降级状态下 purge 数据。
• Object Lock 未在创桶时开启则无法原地启用 WORM；需新桶迁移。COMPLIANCE 保留为真不可逆，set_object_retention 会拒绝缩短已生效保留。