TT Lab
开始
学习 学习路径 课程

FDE综合实战:仓库收到了三次相同订单

安装成功了,端口却早已被别人占用

在 TT Lab 中继续学习

一句话总结

预检(preflight)是在安装之前,只读地判定客户主机是否满足要求,并把结果留成报告和退出码,供下一步的自动化(而不是人)来读取。

为什么需要它

客户现场的安装窗口通常只有一次。周四晚上 22 点基础设施团队开门,到午夜就关。在这种场合,安装脚本以“完成”结束这件事,几乎什么也保证不了。文件虽然复制到了位置,但代理打算使用的端口可能已经被内部代理占用,一启动就会挂掉;客户交来的证书也可能在安装三周前就已过期。这两件事都得在安装之后翻日志才能知道,但在安装之前只要 5 分钟就能知道。

FDE 交付给客户的不是代码,而是能正常运行的结果。所以在安装步骤前面,单独设一个步骤来问“这台主机上,安装成功的条件是否具备”。如果把这一步做成人工的检查清单,每次都会有人漏掉。做成脚本并把结果留成文件,就能拿出依据对客户说:“阻止安装的是这两项,其余都是警告。”

工作原理

检查器以需求规格为输入,每项检查给出 pass、warn、fail 之一以及观测值。观测值很重要。只写着“端口失败”的报告无法反驳,也无法验证。只有同时给出 observed: in_use,以及所测的路径、剩余 MiB 和 notAfter 时刻,客户负责人才能亲眼再确认一遍。

退出码借用监控插件的惯例就容易解释。Monitoring Plugins 开发指南使用 0 OK、1 Warning、2 Critical、3 Unknown,并把 3 限定为参数错误或检查器自身无法运行的情形。值得注意的是,其中写明:名称解析失败或套接字超时之类的上层错误不要升级为 Unknown。主机名解析不了不是“不知道”,而是阻止安装的事实。

每一项检查都有常见的陷阱。

명세(spec.json) ──▶ preflight.py ──▶ report.json   (점검마다 status + observed)
                          │
                          └──▶ 종료 코드 0 · 1 · 2  (명세를 못 읽으면 3, 보고서 없음)

在现场相遇的样子

最常见的错误是检查器顺手修复。数据目录不存在就创建,把占用端口的进程杀掉,把过期证书换成自签名证书。那一刻,检查结果就丢掉了“这台主机原本是什么样”。而且目录的所有权、占着端口的内部代理、证书签发流程,全都是客户组织的决定。预检只揭示事实,修复则按负责人商定的流程进行。这次的客户备忘录里也写着,工作目录由基础设施团队来创建。

第二个错误是把警告和失败混在一起。剩余空间超过供应商的最低值、但少于运维团队的标准,安装是可以进行的。如果把这也升级为失败,就会白白错过安装窗口;如果完全不通知,两个月后磁盘就会写满。这就是要单独设置警告等级的原因。

实际工作中真正重要的事

下一项实验要做什么

把客户备忘录转写成规格,依次实现端口、TIME_WAIT、磁盘、证书、文件、主机、写入检查。评分器每次都会用不同的端口和基准值、以及自己生成的即将到期和已过期的证书来运行你的检查器,并核对判定和观测值。最后,用客户规格做出实际判定,并留下 go / no-go 记录。