MisakaNet 是 dpharness.com 收录的失败经验库插件，作者 Ikalus1988，Apache 2.0 许可，官网 misakanet.org，GitHub 仓库 493 star。它的知识主体是 393 条去重后的 canonical lessons，覆盖 RAG、DevOps、Feishu、Fanuc、Network、Claude、MCP 等领域，已有 333 个节点参与贡献。
装到阿里云 ECS 上跑通只要半天，难的是三个月后它还愿意正常工作。上游合并了新 lesson 而你机器上那份还是旧的；磁盘被日志写满，仓库对象读不出来；出口策略被谁改过，检索脚本报出来的却是连接错误。这篇不讲怎么装，只讲日常该盯哪几个点、指标怎么取、出事先看哪里。
一、先承认运维对象只有两样
一份 Git 仓库，一个检索入口。这就是全部。
没有数据库，所以不会有慢查询、连接数打满、索引重建这几类事。没有常驻进程，所以不需要进程守护、不需要探活、不用考虑 OOM 重启。零依赖把复杂度从基础设施挪走了，同时也把稳定性压到三个变量上：磁盘是否可写、网络是否可达、Python 解释器是否还在。
监控设计围着这三件事做，就不会跑偏。
二、同步节奏跟着上游提交走，别手动
上游最近一次提交是 2026/9/19，属于持续在更新的项目。只读节点建议用定时任务每天拉一次，而不是想起来才手动 git pull。
cd /opt/MisakaNet && git pull --ff-only # 只接受快进，避免自动产出合并提交
git rev-parse --short HEAD # 记下当前版本，便于事后对账
--ff-only 值得加上：它保证本机不会因为上游变基或分叉而悄悄生成一个合并提交，一旦无法快进就立刻非零退出，正好能拿退出码做告警。
写入型节点（会跑 queue_lesson.py 提交的机器）别走定时快进，要先提交本地改动再拉取，顺序颠倒会把自己还没提交的经验盖掉。
三、冲突处理先判断是谁在写
只读实例理论上不该出现冲突。如果 git pull 真的报错，第一件事不是埋头解冲突，而是弄清楚谁在这台机器上直接改了文件。常见两种来路：有人 SSH 上来手工编辑了 lesson，或者这台「只读」机器被拿去跑了贡献脚本。
处理顺序固定成三步：先收起本机改动，再同步远端，最后看被收起来的东西是什么。
git stash push -m "本地临时改动" # 先把工作区清干净
git pull --ff-only # 再同步远端
git stash show -p # 检查被收起来的改动到底改了什么
真正的解法在制度层面：只读节点就只读，别在它上面写。
四、仓库完整性巡检靠 git fsck
Git 仓库并不是不会坏。磁盘写满、异常断电、存储层抖动，都可能留下悬空对象或丢失的 blob，而日常 git pull 多数情况下不会主动告诉你。
建议每周跑一次完整性检查。
cd /opt/MisakaNet && git fsck --full --no-progress # 扫描对象库，报 missing 或 dangling
关注两类输出。missing blob 意味着对象真的没了，只能从远端重新 git clone 一份，把旧目录挪走而不是就地修补；dangling 一般无害，是历史提交留下的孤立对象，不影响检索。
顺带看一眼 .git 的体积变化。lessons 是纯 Markdown 文本，增长应当很慢，某个时间点突然暴涨，通常是你往仓库里误放了产物文件。
五、可用性探针分三层，只探端口没用
很多人监控只做 ping 或端口探测，对这套架构没有意义：仓库在、端口通，检索照样可能是坏的。要按依赖链分三层取指标。
仓库层，看版本与洁净度。
git -C /opt/MisakaNet rev-parse HEAD # 长期不变，说明同步卡住了
git -C /opt/MisakaNet status --porcelain | wc -l # 非 0 说明有未提交改动
检索层，这是最关键的一层。检索由纯 Python 标准库实现 BM25，全程不走网络，所以它能干净地区分出解释器或仓库本身的问题。固定一个必然有结果的词去搜，把退出码和结果条数一起记下来。
cd /opt/MisakaNet && python3 search_knowledge.py "pip install timeout" # 退出码非 0 即检索不可用
远端层，只有走 Remote MCP 的实例才需要。探测 https://misakanet.org/mcp 的可达性时注意，这里验的是「网络能否到」，不是「Token 是否有效」——后者必须发起一次带鉴权的调用才能判断，探针不要混用这两个结论。
六、告警分三档，别什么都推
告警的价值在于分级，全都推等于没推。建议就三档。
第一档是检索层探针非零退出。这是硬故障，Agent 已经查不到失败经验，应当立刻通知到人。
第二档是连续两次定时拉取失败，或版本号连续三天没变化。可能是出网被拦、仓库被锁、系统盘写满，需要人看一眼，但不必半夜爬起来。
第三档是探针耗时明显变长、.git 体积异常增长。这类趋势型信号适合进周报，不适合即时打扰。
实现上不需要引入监控系统：定时任务里判断退出码，非零就往站内信或群机器人推一条文本。先把「坏没坏」这件事自动化，比一上来就追漂亮的看板划算得多。
七、底座这层，别忘了 ECS 自己的事
上面的探针全建立在云主机正常的前提下，所以 ECS 侧还得单独配一遍。
规格上，只跑检索脚本和定时任务，1 vCPU 2 GiB 绰绰有余；如果这台机器同时还要跑 Agent、dsh Web 和 Node 工具链，建议 2 vCPU 4 GiB 起，系统盘 40 GiB 足够，lessons 是文本，占不了多少空间。镜像选 Ubuntu 22.04 或 24.04 LTS，Python 3 与 Node 的软件源最省事。
网络上有三件事必须做对。安全组入方向只放行你自己的来源 IP，不要出现 0.0.0.0/0；SSH 端口同样填你的出口公网 IP。DSH Web 默认监听 127.0.0.1:3080，本来就不对外，运维巡检时用一条 SSH 隧道在本地看即可，别为了「方便」把它开到公网。
ssh -L 3080:127.0.0.1:3080 -N root@ # 本地端口转发，比开公网端口稳得多
出网方向要留够：走 npm 形态安装需要能到 npm registry，走 Remote MCP 需要能到 misakanet.org，这两个目标在自定义 NAT 或收窄过的出方向策略下都可能被拦，表现在探针上只是很笼统的连接超时。排障时先分别验证这两个域名，再回头改策略。
运行时前置两项：Python 3 必须在位（零依赖指的是只用标准库，不是不用解释器）；Node 要求 >=20.0.0，dsh 的验证基线是 Node 22.19，装完用 node -v 复核一遍。
结语
运维这套东西的诀窍是接受它很简单：没有数据库要调优，没有守护进程要保活。你真正要盯的只有同步有没有跟上、仓库有没有坏、检索还能不能用，以及云主机这层（安全组规则、出网策略）有没有被人改动过。把这些做成每天自动跑一遍的探针，剩下的时间就能拿去看新的 lesson 了。
想对照看看还有哪些插件同样适合长期放在云上运行：link
