自动化运维

墨天轮（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 索引条目。 ...

生成式 AI 普及以后，技术用户获取答案的方式正在发生变化。一部分原本需要访问社区、搜索历史问答或发布新问题的需求，被 AI 对话直接承接。对技术社区而言，真实用户访问和 UGC 活跃度承受压力并不意外。Stack Overflow 也曾在官方流量分析中披露，GPT-4 发布后的 2023 年 4 月出现过约 14% 的超常流量下降。 墨天轮的数据一度呈现出相反现象：在行业真实流量承压的背景下，网站访问指标没有下降，反而增长了数倍。按照过去以日活、月活为核心的运营口径，这原本应该是一个非常好的结果；但同期 UGC 产出，以及用户登录、签到等能够确认的互动数据并没有同步增长，部分指标反而在下降。 继续核对 CDN、NGINX 和应用日志后，指标之间的矛盾才得到解释。传统搜索引擎蜘蛛的流量变化很小，对这轮指标增长的影响可以忽略；真正抬高访问量的是大量伪装成普通浏览器的程序化抓取请求。它们的目的无法从访问日志直接证明：可能是搬运网站内容，可能是构建本地知识库，也可能用于大模型训练。能够确认的是，这些请求没有带来相应的登录、签到或内容互动，却被计入了原有的流量、日活和月活指标。 第一阶段，我先用 User-Agent 黑名单处理能够明确识别的低价值抓取请求。当前实际规则如下，Googlebot 和 Bingbot 没有进入名单，因此不会在这一层被拦截。下面为了阅读做了换行，CDN 中保存的实际配置仍是一条连续规则： *YisouSpider*|*Baiduspider*|*python-requests*|*Go-http-client*|*okhttp*|*Apache-HttpClient*|*Sogou*|*Firefox/3.0*|*Windows NT 5.1*|*360Spider*|*AhrefsBot*|*Windows NT 6.1*|pc|axios/1.7.7|*Bytespider* 这份名单不只包含一搜、百度、搜狗、360、Ahrefs 和 Bytespider 等已知蜘蛛，也覆盖 python-requests、Go-http-client、okhttp、Apache-HttpClient、axios 等常见程序化客户端，以及根据当前业务访问特征确认不再需要的旧客户端标识。规则生效后，CDN 侧流量下降约 30%，说明这一层简单、确定且几乎没有运行成本的过滤已经处理了相当比例的非用户请求。 但这一步很快遇到边界。剩余 Bot 不再使用固定的爬虫 User-Agent，而是伪装成 Chrome 等普通浏览器；有些还使用 IP 池轮换来源，把请求分散到同一网段的多个地址。单看某一个 IP，请求量可能并不突出；聚合到 /24 网段后，持续抓取的特征才会显现。只依赖 User-Agent 或单 IP 黑名单，已经无法继续识别这部分流量。 问题因此不再只是“访问量太大”。爬虫流量一方面污染运营指标，使表面增长与登录、签到、UGC 等互动指标发生背离；另一方面持续消耗 CDN、源站服务器和 OSS 资源。对于以原创技术内容为核心的网站，它还带来内容被批量获取的风险： CDN、源站服务器和 OSS 都在为它们消耗流量、连接和计算资源； 原创内容被外部平台批量抓取和搬运，墨天轮承担内容生产与分发成本，内容价值却被外部平台直接复用。 云 WAF 和 Cloudflare 都是可以考虑的方案，但并不适合直接套用到当前场景。WAF 的 Bot 识别与定制能力难以完整覆盖内容型网站的业务规则，整体费用也比较高；Cloudflare 在中国大陆的接入还有额外条件，其官方 China Network 文档要求先使用 Enterprise Plan，再单独订阅中国网络，并由合作方审核域名。 ...