平台/SRE面试考你是不是真发过版、不只是看过博客。
滚动：K8s默认。一批N个pod替换。便宜，不要额外容量。回滚=重新部署旧版本。
蓝绿：双环境并存切路由。秒回滚（切回去），但双倍基础设施成本。
金丝雀：小比例流量先上新版，看指标再扩。风险厌恶的变更首选。
Feature flag：暗部署，翻flag启用。把release和deploy解耦，适合按用户/地区渐进。
有状态服务（DB、队列）迁移单独做——蓝绿解决不了schema变更。
支付服务我叠金丝雀+feature flag在滚动上面。基础滚动发二进制，按阶段金丝雀（1%→10%→50%→100%），错误率/时延超guardrail自动回滚。feature flag给单个新行为独立开关，出问题不用重发版就能关。蓝绿对支付"秒回滚"听着好，但有状态变更（schema、长事务）它也没有更优解——还要付双倍基础设施只为"以防万一"难正当化。支付的真保护是：(1)每次写幂等、(2)每次发版小爆炸半径、(3)自动回滚触发器、(4)runbook级回滚流程。策略是一根杠杆；卫生是三根。
guardrail告警自动回滚 > 人工介入——告警响起来时已经在丢钱。
进程内feature flag（LaunchDarkly、growthbook）的默认要安全——取不到flag不能把系统搞挂。
即答侠有四策略对照表——答得结构化不绕。
只有配合迁移策略（双写、expand-contract）才行。蓝绿只搞服务端切换——schema它不能变魔术。
部分升级会把客户端搞坏（比如客户端被混版API搞晕）。这时蓝绿给原子切换。