不少线上事故的原因並不复杂：本地調试用的配置忘了改回去、临时注释掉的缓存開關没有恢复、為了排查問题加的白名單一直留在线上。這些問题通常不會立刻报错，而是過几天有人反馈“這個頁面怎么不對”，才被翻出来。
把發布從“记得就好”變成一張固定清單，是站点运营里投入产出比較高的一件事。下面的清單不复杂，中小站点可以直接抄下来用。
先给發布分級，不要每次都全量检查
如果每次改一個错別字也走完整流程，清單很快就會没人执行。更現實的做法是按影响面分三档：
- 轻量改動：文案修改、图片替換、單篇文章發布。只需要確認發布环境和回滚方式。
- 常規發布：模板調整、栏目结构變化、新增功能模块。需要走完整清單。
- 高風險發布：域名、證书、服務器迁移、資料库结构變更、缓存或 CDN 策略調整。需要額外安排观察時間和明确的回滚决策人。
發布前：配置與环境
- 調试開關是否全部關閉？包括详细的错誤輸出、SQL 慢查询打印、模板調试信息、前端 sourcemap 是否對外可訪問。
- 配置文件里的域名、接口地址、回調地址是否指向正式环境，而不是測試域名或内網 IP。
- 临时加的訪問白名單、绕過登入的開關、測試帳號是否清理干净。
- 新增的第三方密钥、推送渠道、統計代碼是否換成正式帳號。
- robots 相關設定是否有變化。如果這次發布了新栏目，確認它應该被訪問還是暂时不對外。
發布前：資料與回滚
- 這次改動是否涉及資料库结构？如果有，確認變更脚本可以重复执行，並且知道怎么撤销。
- 發布前是否有一個可用的备份，而且驗證過能恢复。只生成备份文件、從不測試恢复，是常见的心理安慰。
- 回滚方案是否具体到操作步骤？是切回上一個版本、還原配置，還是回滚資料库。含糊的“有問题就回滚”在紧急时刻帮不上忙。
- 參與發布的人是否都知道谁有權决定回滚，避免事發时互相等對方拍板。
發布中：顺序和节奏
- 先發布不依赖新資料的部分，再發布依赖部分。涉及前端和後端同时改動时，先让後端兼容舊前端。
- 一次只改一個變量。同时上线模板改版和缓存策略調整，出問题时很难判断是哪一個引起的。
- 如果站点有多個节点，采用逐台發布，確認第一台正常後再繼續。
- 發布完成後立刻手動訪問几個關键頁面，包括首頁、一個栏目頁、一篇詳情頁和一個需要登入或提交的頁面。
發布後：第一小时看什么
- 服務器错誤日誌里是否出現新的报错類型，而不是只看错誤總數。
- 首屏响應時間和错誤率相比發布前是否明顯變化。小幅波動正常，翻倍就值得查。
- 是否有異常的 404 或 500 集中在某個路径上，這通常指向漏传的文件或寫错的路径。
- 抓取行為是否正常。如果發布後短時間内大量抓取集中在某個無效路径上，可能是新生成的連結有問题。
- 表單、搜尋、登入這類交互入口是否真的能提交成功，而不是只看頁面能打開。
把清單落到流程里
清單寫了不执行等于没寫。比較有效的做法是把它挂在發布入口旁邊，比如提交發布申請时附上一個勾選表，没勾完就不進入發布环节。清單本身也要定期复盘：每次出現問题後，問一句“如果清單里多加哪一項，這次就能提前發現”，然後加進去；長期没人踩的條目，可以考虑删掉，保持清單简短才有人愿意用。
發布流程的目标不是让發布變慢，而是让可预期的問题在發布前暴露，让不可预期的問题在發布後能快速回退。清單越短、越具体，越可能被真正执行。