一线排障与发布前检查清单#

这章解决什么问题#

前两章已经把 observability、trace、dump / replay、扩展点与维护路径讲清楚了，但对很多读者来说，最后仍然缺一件东西：当问题真的发生在生产或交付节点时，应该按什么顺序检查，才能避免在大量路径之间来回切换。

这一章就是把前面所有理解压成更像“值班清单”或“发布清单”的形式。它不替代前文原理，而是把原理收束成可执行顺序。

一个更像一线排障的最小顺序#

1. 先判断是整体退化、个别请求异常，还是结构化输出/协议行为异常
2. 整体退化：先看 metrics 与 scheduler / cache 路径
3. 个别请求异常：先看 trace，再看 request lifecycle 闭环
4. 结构化输出或 tool call 异常：先看 SamplingParams / parser / API surface
5. 无法稳定复现：打开 request dump / crash dump，转 replay

这条顺序的价值，在于它把整本书真正串了起来。你不是重新发明排障方法，而是在把 overview、lifecycle、runtime、scheduler、execution、structured generation 和 observability 这些章节的结论拿来组合成动作顺序。

发布前检查为什么也应该收在书里#

对维护者来说，发布前检查不是“写完书以后的事”，而是系统理解的一部分。因为一旦你真的准备上线、合并或做一次大规模改动，最重要的问题就变成：哪些章节对应的检查点必须重新过一遍，才算没有把系统理解停留在纸面。

这也是为什么技术书里的最后一章常常要承担“把知识转成 checklist”这件事。否则读者离开书页之后，知道很多原理，却还是不知道下一步具体该检查什么。

一个针对当前主线的发布前检查框架#

Request lifecycle:
- 入口路由是否仍然回到统一 runtime path
- streaming / 回包路径是否完整闭环

Runtime architecture:
- 进程边界与 IPC 关系是否仍成立
- managers / executor / cache / observability 边界是否被新改动打穿

Scheduling & memory:
- batch 形成是否正常
- reuse / eviction / memory pressure 是否有异常迹象

Execution model:
- sampling / logits / speculative mode 是否和预期一致

Structured generation & APIs:
- schema / regex / parser / API surface 是否仍对齐

Code walkthrough / extension:
- docs / examples / tests / benchmark 是否仍能支撑当前理解

这份框架的意义，不在于面面俱到，而在于它让读者看到：发布前检查本质上就是把前面章节各自的“关键判断”重新走一遍。

本章对应哪些代码路径#

这一章不新增很多源码锚点，它主要回指前文已经建立好的锚点：launch_server.py、http_server.py、TokenizerManager、Scheduler、DetokenizerManager、ForwardBatch、SamplingParams、req_time_stats.py、相关 docs / examples / test / benchmark 路径。

小结#

真正成熟的技术书，最后往往会把“理解系统”压缩成“如何稳定操作系统”。这一章做的就是这件事：把全书前面的主线转成一组值班和发布前可执行的检查顺序。到这里，整本书才真正从“导读”变成“可带走的方法”。