一次失败的插件安装，到底要付多少代价

一次失败的插件安装，代价不在移除它那五分钟。真正的代价是团队一整个下午没法构建、发布延后一天，以及花一小时向工程部门之外的人解释发生了什么。本文把 plugin failure cost 按时间真正花在哪拆开，补上多数团队从没写进工单的 bad install impact，给出一套能撑住最初十分钟的 plugin incident response 顺序，最后是一份二十分钟就能写完、而不是在故障中临时拼凑的 plugin rollback plan。

时间到底花在哪

团队只会给"移除"这一步做预算，忘了它周围的所有事情。而移除是最小的一项。

没人记账的那部分影响

上面几行是会出现在工单里的。另外三项成本真实存在，却几乎从不落纸面。

• 上下文损耗。最熟悉这套环境的工程师把整个下午给了故障，原本在做的事推后一天。
• 信任成本。出过一次事之后，团队不再快速批准插件。原本十分钟的评审变成一周，这个延迟比事故本身更贵。
• 审计欠账。如果插件接触过凭据或构建产物，就得有人说明它可能够到什么。这个说法几个月后要经得起查，所以它依赖事故中收集的证据，而不是事后的回忆。证据格式见 /blog/plugin-supply-chain-security-team-enforcement。

能撑住压力的处置顺序

压力下人会直接跳到修。但把修复放在第二位整体更快，因为还原一个还没检查过的环境，可能把问题一起还原回来。

• 先冻结影响面：禁用插件、隔离机器、吊销插件能读到的凭据。哪怕只怀疑其中一项，三项都做。
• 恢复前先留证据：复制插件目录、安装日志和插件清单。恢复会覆盖掉唯一一份现场记录。
• 确定它能够到什么：文件路径、环境变量、网络目标、子进程。写成清单，不要写成叙述。
• 然后再恢复，从已知可用状态恢复，而不是删掉插件然后指望它自己好了。
• 最后补一份决定记录：发生了什么、它够到过什么、你改了什么、什么时候复审。模板在 /blog/plugin-supply-chain-security-team-enforcement。

顺序比速度重要。还原一台还没检查过的机器，会同时把问题还原回来、把证据抹掉。

先把回滚计划写好

回滚计划是二十分钟的工作，只在事故中才见效，所以永远没人写。四行能覆盖大多数插件。

• 插件写在哪里：配置路径、缓存路径，以及它在自己目录之外创建的任何文件。
• 它能读什么：凭据、环境变量、仓库内容。
• 如何彻底禁用，包括它注册的 service 或 hook，不只是卸载命令。
• 最近的已知可用状态是什么，恢复要多久。没掐过表的话，你脑子里那个数字是错的。

把这份计划放在批准记录旁边。出事时读它的人不是写它的人，而且是在掐着表读的。

预防的价签

这里的预防措施大多便宜，贵的那部分可以不做。

• 运行前先读安装钩子，五分钟。机制说明见 /blog/how-install-script-scanning-works。
• 批准前看评分和维护信号，两分钟；分数怎么算出来的在 /blog/dsh-quality-score-decoded。
• 核验包是谁发布的，再来五分钟。流程在 /blog/how-to-verify-dsh-plugin-authenticity。
• 给接触凭据的插件准备一个沙箱，一次性一小时。这大约是单次"发现"阶段的十分之一。

常见问题

• 小插件的代价也这么高吗？代价取决于插件能够到什么，而不是它有多少行代码。一个能碰凭据的五十行插件，比一个只会格式化文本的大插件更值得担心。
• 还没搞清它做了什么，就该先移除吗？不该。先禁用隔离，复制日志和插件目录，再恢复。先移除会毁掉写报告要用的证据。
• 事故记录要保留多久？遵循插件所接触系统的保留期要求，并且至少保留到它支撑的那个决定失效为止。
• 评分高就能跳过回滚计划吗？不能。评分覆盖维护、文档、生态健康和安装行为，不描述这个插件在你的机器上能够到什么。
• 决定记录该由谁负责？批准插件的那个人。批准和回滚应该归同一个人，否则两件事都会被一直往后推。

从 dshquality.com 的实时插件索引开始，每个插件页都写清了检查过什么、没检查什么。为什么这里的评分坚持独立于自报数据，见 /blog/why-independent-plugin-scoring-beats-self-reported-ratings，站内全部文章在 /blog。