安全漏洞爆出来那一刻，运维人的血压就上来了。补丁要打，业务不能停，老板问你能不能不停机更新——你总不能说“不行”吧？
停机打补丁到底痛在哪
传统做法是选凌晨维护窗口，停服务、装补丁、重启、验证、恢复。整个过程少说半小时，遇到依赖库升级可能要两三个小时。对于电商类客户，大促期间半小时停机就是真金白银的损失。金融行业的客户更严格，监管要求99.95%以上的可用性，每月停机预算不到22分钟。
问题核心在于：单机架构下，补丁更新和业务运行是互斥的。你没法在同一个进程上同时干这两件事。
两种不停机更新方案
方案一：蓝绿部署。准备两套完全相同的环境，蓝环境跑当前版本，绿环境部署新版本。先把绿环境更新好、测试通过，然后切流量到绿环境，再更新蓝环境。整个过程业务零感知。这个方案适合有冗余资源的企业，需要至少双倍服务器资源。
方案二：滚动更新。把服务器分成多个批次，比如三台为一组。先摘掉第一批的流量，打补丁、验证通过后加回集群，再处理下一批。K8s环境里这个操作是原生的，传统环境可以用Nginx的drain功能实现优雅摘除。这个方案资源开销小，但滚动过程中存在新旧版本并存的时间窗口，需要确保补丁的向后兼容性。
漏洞修复的优先级怎么排
不是所有漏洞都需要立即修。按CVSS评分分级：7分以上的高危漏洞48小时内必须修，4-7分的中危漏洞一周内修复，4分以下的低危漏洞可以在下次维护窗口统一处理。但有个例外：如果漏洞的EXP已经公开，不管多少分都要立刻修。
另一个建议是建立补丁测试环境。直接在生产环境打补丁是赌博，先在测试环境验证补丁不影响业务逻辑，再推到生产。这个测试环境不需要和生产完全一致，但核心服务版本、依赖库版本必须对齐。