容器运维代码评审该盯住哪些细节容器里的程序最终要面对的是调度、网络、资源限制和终止信号。一次业务功能改动可能因为探针写法、连接关闭顺序或配置默认值在滚动发布时放大成可用性问题。评审不能只读业务函数还要沿着进程从启动到退出的路径检查。启动与健康状态要分开启动探针解决“应用还在初始化暂时不要判死”的问题就绪探针表示“现在可以接新流量”存活探针用于判断进程是否卡死。它们不应互相替代。就绪检查最好快速、稳定避免每次都做昂贵的全量依赖检查。是否把数据库等依赖纳入就绪条件要按服务在依赖不可用时是否仍能安全接流量决定。var accepting atomic.Bool func ready(w http.ResponseWriter, _ *http.Request) { if !accepting.Load() { http.Error(w, draining, http.StatusServiceUnavailable); return } w.WriteHeader(http.StatusOK) }这只表示服务自己的接流量状态。外部依赖故障应通过独立指标和请求错误来观测不能轻易让所有副本同时被摘除。探针路径也应避免认证重定向、缓存污染和大量日志。终止时先停止接入再处理在途请求收到SIGTERM后应用应立刻把就绪状态切换为失败停止消费新任务或接收新连接再在 Kubernetes 的宽限期内完成已有请求。HTTP 服务器需要设置读取、写入和关闭超时后台 goroutine 要监听 context 取消并退出。不要只捕捉信号然后无限等待也不要假设 Endpoint 更新会在同一时刻完成。队列消费者还要考虑消息确认顺序任务真正成功后才确认退出时停止拉取新消息并把来不及处理的工作交还队列或记录为可恢复状态。用一次真实的滚动升级演练来验证而不是仅依赖单元测试。资源限制和配置需要可解释为 CPU 和内存设置 requests 与 limits并根据运行时语言选择合适的并发、堆内存和连接池配置。Go 运行时版本不同对 cgroup 的识别与内存行为也不同不要把某个环境变量当成所有镜像通用的修复。监控 OOM、GC、线程数、文件描述符、连接池等待和 throttling才能判断限制是不是合理。评审时还要检查镜像是否以非 root 用户运行、临时目录是否可写、配置和密钥是否从受控来源读取、日志是否包含敏感信息。最后把失败路径列出来探针失败、优雅退出超时、依赖变慢、节点驱逐时系统分别怎样表现。容器化不替应用处理这些边界代码必须自己说清楚。对于多副本服务评审还应看会话、定时任务和缓存是否依赖单实例假设。滚动更新时旧新版本会短暂共存任何共享锁、leader 选举或后台清理逻辑都要能安全度过这段时间。把验证场景写进自动化测试或演练脚本才能避免经验只留在某个人脑中。