清单要解决什么问题

上线前的检查经常流于形式：项目赶进度，检查被压缩成点几下页面，看功能有没有报错。真正的隐患往往藏在不容易被注意的位置，比如一个可以被直接访问的后台地址，一个返回了完整错误信息的接口。

一份有用的清单，重点不是列得越多越好，而是每一项都能被验证。写清楚检查什么、怎么判断通过，谁来做都不会有太大差别。

清单还要跟着项目的实际情况调整。用到的框架、涉及的功能、对接的第三方不一样，需要重点检查的位置也不一样。

上线前值得逐一确认的内容

先说最容易出问题的公开入口：有没有遗留的测试页面、示例脚本、后台路径可以被匿名访问；有没有可以直接下载的备份文件、配置文件、日志文件。这几项花几分钟就能查完，出问题的概率却不低。

再看输入的地方。所有接收输入的位置是否都做了校验，尤其是文件上传和查询参数；错误提示会不会把内部结构暴露出来；接口返回的数据有没有超出必要范围。

然后是账号与权限。默认账号是否已经改掉，测试账号是否已经禁用，管理入口有没有额外的访问限制，不同角色的权限范围是不是真的区分开了。

最后是配置与环境。调试模式是否关闭，日志级别是否合适，敏感配置是否放在代码之外，定时任务和外部回调是否已经就位。这几项直接关系到上线之后能否稳定运行。

用什么方式检查

自动化的扫描工具适合用来快速发现常见问题，几分钟就能给出线索。但扫描结果需要人工确认，误报和漏报都存在，不能把它当成结论。

手工检查不可替代。特别是业务流程相关的部分，比如能不能重复领优惠、能不能修改不属于自己的数据，这些只能靠理解业务之后设计测试用例来验证。

复核的方式是换一个人来做。开发自己检查自己的功能，容易跳过熟悉的地方，换一个人按清单走一遍，往往能发现被忽略的细节。

检查之后要留下什么

检查结果要形成记录：发现的问题、严重程度、处理状态和负责人。没有记录的话，问题很容易在交接中被丢掉。

处理完的项要有验证，不能只看代码改没改。能用请求复现一次确认问题消失，才算真正闭环。

上线之后还不算结束。观察一两天的日志，看看有没有异常的请求模式，确认新功能没有带来意想不到的暴露面。

把这套清单沉淀成模板，下一个项目直接在此基础上调整，检查的成本会一次比一次低。

清单怎么维护

清单写出来之后放在哪里，决定了它会不会被用到。放在项目文档里、上线流程的模板里，让它成为发布的一个环节，比存在某个人的笔记里可靠。

每次检查完记录一下实际发现的问题，过一段时间回头看，能发现自己的项目总是在同一类地方出问题。把这些问题补充成更具体的检查项，清单会越来越贴合实际。

清单也不需要一次写全。先把能稳定执行的十几项定下来，用的过程中再补充，比列一份长到没人愿意读的表格要好。

依赖第三方时的注意点

如果项目用到了外部的服务或者组件，检查时要多确认几项：用的是不是还在维护的版本、默认配置有没有改过、对外暴露的地址是否必要。

第三方的回调地址、密钥、白名单这类配置，上线前要确认已经按正式环境设置好，不要留着测试环境的参数。

上线之后再花一点时间观察相关的日志，确认第三方的调用正常，避免出现功能能打开、后台数据却对不上的情况。

上线之后的头两天，建议再回头看一次日志和监控，确认没有异常请求模式，也确认新功能没带来新的暴露面。

上线之后的观察期

检测清单只能覆盖上线前能想到的部分，运行中的问题还是要靠观察。上线之后的头几天，建议每天看一眼访问日志和错误日志，确认没有异常的请求模式，尤其是那些在测试阶段没有出现过的路径。

发现异常时先记录下来，等观察到规律再处理，急于下结论容易把正常行为当成问题。