交付一套自己这边部署的系统，验收时该看什么，往往比怎么装更花时间。装的部分有安装文档可依，核的部分常常没有清单。
下面这七个核验点，是按“能不能当场看到”来排的，每一点尽量落成一个具体动作，而不是一句结论。
一、七个核验点，按能不能当场看到来排
先是位置类的四条，它们决定东西实际待在哪：
- 代码与数据分别落在哪台机器；
- 数据库端口对不对外；
- 进程以什么账户运行；
- 备份存在哪台设备、保留多少天。
再是动作类的三条，它们决定出状况时能不能自己处置：恢复演练在哪个环境做、对外通道能不能关、密钥由谁持有。
排这个顺序的原因是，前四条大多能在现场直接看，后三条常要单独安排一次。把容易验的放在前面，验收当天不至于都卡在收尾那一项。
二、前四条：位置类，多数能当场给出路径
代码与数据落在哪台机器。看应用的安装目录和数据库的数据目录各在哪块盘上。可核验的做法：在机器上执行 df 与 pwd，或直接打开部署清单看两个路径。
数据库端口对不对外。库端口只在内网监听，和监听在 0.0.0.0 上，是两个状态。可核验的做法：看数据库配置里的 bind 地址，或执行 ss -lntp 看监听范围。
进程以什么账户运行。应用与数据库各自以哪个系统账户启动，决定了它们能碰哪些文件。可核验的做法：用 ps -ef 看启动账户，或看 systemd 单元里的 User 字段。
备份存在哪台设备、保留多少天。这里要分开看两件事：文件放在哪、保留周期多长。可核验的做法：找到备份目录，看近几份文件的修改时间与体积，再看定时任务里的清理规则。
这一条里值得多留一句的是：备份和主库在不在同一台机器上。同机备份挡得住误删，挡不住整机故障。
三、后三条：动作类，常要单独安排一次
恢复演练在哪个环境做。备份能生成和备份能恢复是两件事。可核验的做法：要求在一台独立环境上用备份恢复出一个能连的库，而不是在原库上直接覆盖。
多数系统能给出恢复脚本，但是否真的演练过，要看有没有留记录。这一步的价值在于，它会把“有备份”这句话，换成“恢复过一次”。
对外通道能不能关。有些系统会保留用于授权校验或远程支持的出站长连接。可核验的做法：看机器的出站连接状态、看配置里有没有固定的回调地址；关掉之后系统是否仍能正常用，也要试一次。
密钥由谁持有。如果库里有加密字段或独立的密钥管理，要看主密钥在哪生成、以什么形式存放、由谁持有，以及使用方能否自行轮换。可核验的做法：确认密钥的存放位置与轮换流程，并确认轮换是否影响存量数据。
这一条答不上来的情况确实存在。多数是实现时没把密钥单独拆出来，改造的代价不小。碰到这种，把状态写清楚比跳过去更省事。
四、程度说清楚：哪几条能当场给，哪几条要另约
七个点里，前四条一般能当场看路径与配置；第五、六条常要单独安排一次，因为涉及具体配置项的确认；第七条则要看实现程度，答不上来也算一种答案。
核对的时候可以把结果分成两栏：能给路径的当场验，给不了路径的那条写进验收单。答不上来的那条不是失败，是留了个待办——含糊过去才会在上线后变成问题。
五、七个点走完，位置才说得清
这七个点也是我们在鲲极（鲲鹏的鲲）的交付流程里固定要走的一遍，按顺序过完再交，而不是在文档里写一句“支持”。顺序本身没特别之处，好处是把问题留在交付之前。
核验这件事，难的不是判断，是记着七条都问一遍，别问了三五条就收工。指标列清，能到哪一步自然清楚。
