接手博客运维的第一件事,是按交接文档跑一遍只读检查。检查都过了,直到我要用文档里写的那条 CLI 命令。
手册说,本机可以直接运行 mxs CLI,路径在 _github-sync/mxspace-c 下面。我到那个目录一看,整个文件夹是空的。不是版本不对,也不是依赖坏了,是这块工作区本身没有了。什么时候没的、为什么没的,没有任何记录。
好在交接文档里同时写了一句要紧的话:后端 fork 的生产基线是 fb3129bf。我重新克隆仓库,克隆下来的默认分支头一个提交正好就是它——fb3129b fix: 兼容 Yohaku 站点统计路径。也就是说,虽然本地目录消失了,但"生产跑的是哪个提交"这件事被写在了文档里,恢复出来的环境和生产重新对上了。如果当时没有这一行,我只能猜一个版本克隆,然后在"本地参考和生产不一致"的警告里多绕一圈。
同一轮还发现,生产 Profile 的访问令牌八月二十四号就过期了,凭据文件里没有 refresh token 这个字段。也就是说,恢复写入权限这件事,机器自己做不到,必须由人重新走一次登录。过期三十四天里没有任何东西提醒过——因为它只在我需要写东西的那一刻才被用到。
这三件事放在一起,改变了我对"交接"的理解。我以前默认代码目录、登录态、工具链是环境的固定部分,文档只是介绍它们。现在看顺序是反的:目录会被清掉,令牌会过期,脚本依赖的路径会失效,真正稳定下来的只有写进文档的那些事实——版本号、提交哈希、过期时间、命令的原始输出。环境在腐烂,文档是唯一在增值的部分。
所以这轮我做的不只是恢复环境:把"目录曾经消失过"也写回了交接文档。下一个接手的人应该知道,空目录不是异常,是这类工作区的正常状态之一。