MogDB

墨天轮（MODB）的这套系统一直由我维护。过去，Sitemap 也主要靠人工更新：从多张业务表取数、拆分文件、更新前端仓库，再跟随发布流程上线。随着内容规模不断增长，这项工作越来越复杂。在人手有限、其他业务优先级更高的情况下，我中断了 Sitemap 的持续维护。 这不是维护意愿的问题，而是原来的维护方式已经很难靠有限人力长期坚持。Opsx 第一期完成后，我想用这个真实任务验证一件事：当 AI 能通过 Opsx 连接源码、主机、数据库和 OSS，它能不能帮我重新启动 Sitemap 维护，并把一次复杂操作变成以后可以持续运行的机制？ 这次实践的真正目标，不是一次性补齐 120 万个 URL，而是建立一套不再持续占用工程师时间、能够让原创内容稳定进入搜索发现链路的长期机制。 先说说 Sitemap 是什么 Sitemap 是网站提供给搜索引擎的一份 URL 清单。它通常由一个 sitemap.xml 索引文件和若干 URL 分片组成，用来告诉 Google、Bing 等搜索引擎：网站有哪些页面、这些页面最近何时更新。 它不能直接保证页面被收录，但对内容量大、更新频繁的网站非常重要。搜索引擎不必只靠站内链接慢慢爬，可以从 Sitemap 快速发现新内容。 搜索引擎目前还是网站流量的第一大入口，虽然AI对搜索引擎有一定的冲击，但是基础的搜索引擎SEO对网站，尤其原创内容社区是非常必要的。 MODB 正是这样的站点。文章、问答、文档、标签、专题、招聘等内容来自不同的数据表，URL 数量已经超过 120 万。随着规模增长，Sitemap 早已不是生成一个 XML 那么简单。 我一开始只是让 Opsx 回答一个问题： 看看前端源码 /static 下的 XML 文件。这些是网站的 Sitemap，最新更新时间是什么时候？ 这个尝试很快从核对更新时间扩展成一次完整的生产改造：迁移旧文件、补齐中断期间的数据、纠正数据源、重新设计存储结构、记录增量水位，再创建每周自动运行的 Shell Schedule。AI 负责解决重新启动时的复杂性，后续正常运行不再依赖 LLM，也不再消耗推理 Token。 整个过程都发生在同一个 Issue 中。Opsx 共记录了 27 次对话、888 个 Agent turns、1,761 个执行事件。Claude Code 调用 MiniMax-M3 完成本次治理，可归属到该 Issue 的已记录用量为 752,506 Token；期间还发生了 701 次 Shell 类工具调用。最终核对和处理 10 类内容、1,204,599 个 URL、45 个 Sitemap 索引条目。 ...

100 台主机、20 个数据库、30 个应用,谁在巡、谁没巡、上次检查是什么时候? 这个问题看起来简单,实际上很难持续回答。无论是专业监控平台、分散在主机上的 crontab,还是人工登录查看,它们都能发现一部分问题,但资产清单、检查规则、执行记录和后续处置往往分散在不同位置。某台机器的巡检脚本是否仍在运行、上次检查是正常还是已经告警、磁盘 92% 是今天的问题还是三个月前就存在——这些问题最终仍要靠人逐一确认。 真正困难的不是执行 df 或连接数据库,而是让检查结果成为系统可持续使用的运行事实: 发现"磁盘 92%“之后,这个状态如何进入系统认知,而不是只停留在某个终端输出? 异常出现时,如何自动关联到正确的资产、上下游关系、历史经验和可执行的处置路径? 主机、数据库、应用和云资源的健康标准完全不同,如何在统一框架下管理它们? 人工巡检的经验如何固化为可持续运行的机制,而不是每次都重新判断阈值? Opsx 接管全域资产巡检的方式,不是再增加一套"把检查结果发出来"的工具,而是把健康检查收拢到 Asset Graph: Asset 提供身份和运行拓扑 ↓ Schedule 按周期触发确定性检查 ↓ Shell 执行并计算健康状态 ↓ 结果回写 Asset metadata ↓ 异常自动进入关联资产的 Issue ↓ Agent 读取 Memory、Knowledge 和上下游关系继续诊断 巡检不再是某台机器上的孤立脚本,而是平台对真实资产持续建立运行认知的过程。本文从 MODB 和 Bethune 已经运行的主机、MogDB、应用和仓库巡检出发,说明 Opsx 如何让不同资产使用统一机制,并让健康状态成为后续诊断的确定性起点。 主机巡检:从负载、内存、磁盘到健康状态的完整链路 MODB Workspace 当前运行一条每日主机巡检 Schedule,覆盖生产环境中的关键主机资产。Schedule 配置如下: 名称: MODB Daily Host Health Check Workspace: modb 目标资产: 多个主机资产,包括 host-moapp-0002 等 Runner: shell Cron: 0 0 * * * (每日 00:00 UTC) 状态: active 每次执行时,Schedule 会为每个目标主机创建独立的执行记录,检查以下核心指标: ...