发布策略：灰度、蓝绿、滚动、金丝雀

• 用户分桶（bucket/hash）与对照实验
• 流量路由：按用户/请求分发到不同版本
• 实验设计与指标评估

A/B 测试通过"用户分桶 + 流量路由"实现多版本对照：先按用户标识（如 user_id、cookie、匿名 ID）做一致性哈希分桶，把用户稳定划分到 A/B 两组，保证同一用户始终看到同一版本（避免体验跳变）。流量路由层（如 API 网关、Ingress、服务网格 Istio 的 VirtualService）按分桶结果把请求分发到不同的版本实例。多版本需保证数据兼容（共享同一数据库、schema 兼容），并埋点采集各组的关键指标（转化率、留存、错误率、延迟）。评估时用统计学方法（置信区间、显著性检验）判断 B 版本是否显著优于 A，才能决定是否全量放量。

A/B 测试的本质是"对照实验"：分桶保证分组随机与稳定，路由保证不同版本被正确访问，指标与显著性检验保证结论可信。答题要点是"分桶、路由、数据兼容、显著性评估"四要素。

• Kayenta 的体系结构与角色
• 指标收集与基线/对照组对比
• 统计判定与发布决策

Spinnaker 的 Kayenta 是金丝雀分析引擎，通过"基线（baseline）+ 实验（canary）"两组指标对比来判定发布成败。流程：先取金丝雀版本与基线版本在相同监控（如 Prometheus、Stackdriver）下的指标时间序列，用分组（metric group）组织指标；Kayenta 用统计方法（如 Mann-Whitney U 检验、均值/方差比对）计算两组差异的显著性，并依据配置的阈值（successful score、判断阈值）给出分数；若分数达到门槛则判定通过并全量放量，否则回滚。Kayenta 还支持错误率、延迟、饱和度等多类指标，并可与订单/业务指标结合，使判定不仅看系统健康也看业务影响。

Kayenta 的核心是"用统计对比代替拍脑袋"：基线 vs 金丝雀的指标差异 + 显著性检验 + 阈值判定，形成可自动化的发布决策。答题要点是"基线/实验两组、指标组、统计检验、阈值判定"。

• Rollout 资源与 AnalysisTemplate
• 流量策略（stable/canary 切分）
• 分析结果驱动放大/回滚

Argo Rollouts 用自定义 Rollout 资源替代原生 Deployment，支持金丝雀发布。它把发布拆成"步骤（steps）+ 分析（analysis）"：每个 step 设置金丝雀流量权重（如 10%、25%、50%），逐步放大；AnalysisTemplate 定义要采集的指标（如错误率、p99 延迟）与判定阈值，Argo Rollouts 在每步或指定 step 运行 analysis，拉取指标并评估。若分析通过，继续放量到下一 step；若失败，则自动回滚到 stable 版本。流量策略上支持基于 Ingress 的权重切分或基于服务网格（Istio）、负载均衡器的流量路由。整个过程把"流量渐进 + 指标判定 + 自动回滚"串成闭环。

Argo Rollouts 的核心是"用 Analysis 把指标判定嵌入金丝雀步骤"，让放量由数据驱动而非定时拍板。答题要点是"Rollout 步骤权重 + AnalysisTemplate 指标判定 + 自动回滚"。

• Flagger 的金丝雀 CRD 与指标 provider
• 灰度步进与稳定性判定
• 自动回滚与静默期

Flagger 通过定义 Canary 资源与 metric provider（Prometheus、Istio 等）实现金丝雀。发布时 Flagger 先创建金丝雀版本，把流量从 stable 逐步切到 canary（按设置的 step 权重，如 10%→20%→…→100%），每一步之间停留一个 interval 观察窗口。在每个 step，Flagger 拉取预先配置的指标（错误率、P95/P99 延迟、HTTP 成功率等），并与阈值比较：若指标低于阈值则继续放大；若超阈值则判定失败，自动把流量切回 stable 并结束发布。成功分析会持续到全量，失败则回滚并标记。Flagger 还支持 webhook 分析、会话粘性、蓝绿/金丝雀/AB 等策略。

Flagger 的核心是"步进 + 指标门禁 + 自动回滚"的自动灰度。答题要点是"Canary 资源、metric provider、step/interval 步进、阈值触发回滚"。

• DestinationRule：定义服务的子集（subset）
• VirtualService：按权重路由到子集
• 权重调整与最终切换

Istio 用两个资源实现金丝雀：DestinationRule 定义服务的多个 subset（如 v1、v2），每个 subset 通过 label 选择对应的 Pod 版本；VirtualService 定义路由规则，把流量按目的地权重（destinations.weight）分发到不同 subset，如 v1 90%、v2 10%。进行金丝雀时，只需调整 VirtualService 中的权重比例（90/10→70/30→50/50→100/0），流量随之渐进切换，无需重启服务。正式切换后可把 v1 从 VirtualService 移除或调整 subset。配合 VirtualService 的 HTTP 路由（按 header/cookie 分流）可进一步做基于用户的灰度。

网格金丝雀的本质是"把路由与版本解耦"：DestinationRule 声明版本子集，VirtualService 声明权重分配，改权重即改流量。答题要点是"子集定义 + 权重路由 + 渐进调整"。

• 蓝绿双环境与流量入口切换
• 数据兼容（shared data / schema 兼容）
• 版本共存期与快速回滚

蓝绿发布维护两套完整环境（蓝=当前，绿=新），新版本在绿环境完整部署并验证后，通过流量入口（LB/DNS/Service 切换）把流量整体切到绿环境，实现"一次性切换"。切换可以是 LB 权重、DNS 记录或 Service selector 变更。回滚极快：把流量切回蓝环境即可。关键约束是数据兼容：两套环境共享同一数据库或数据源，新版本 schema 必须向后兼容（新增字段、不破坏旧数据），否则切换后旧版本回滚会因数据不兼容而失败。版本共存期指蓝绿同时运行的一段时间，需考虑连接数、资源双倍占用、写操作一致性，以及切换后蓝环境的保留（用于快速回滚）与最终下线。

蓝绿的核心是"双环境 + 入口切换 + 数据兼容"。答题要点是"入口切换机制、schema 兼容是回滚的前提、共存期资源与一致性管理"。

• NGINX Ingress 属性与权重支持
• Flagger 的 NGINX 流量提供者
• 灰度权重与指标分析

Flagger 支持以 NGINX Ingress 作为流量提供者（traffic router）执行金丝雀。NGINX Ingress 支持基于权重（weight）的后端路由和 canary 注解，Flagger 通过 NGINX 的 nginx.ingress.kubernetes.io/canary-weight 等注解动态调整金丝雀版本权重。发布时 Flagger 创建金丝雀版本的 backend，通过修改 Ingress 注解把部分流量（如 10%）切到金丝雀，逐步放大，同时用 Prometheus 采集指标（成功率、延迟）分析，判定通过则继续放大，失败则回滚并还原权重。相比 Istio 的网格级流量，NGINX Ingress 是入口层（L7）权重路由，适合未引入服务网格的集群。

这一问考察 Flagger 的流量提供者抽象：NGINX Ingress 作为 L7 入口提供权重切换能力。答题要点是"Ingress canary 注解、权重调整、指标分析、回滚"。

• 版本标签（version label）注入指标
• 新旧版本流量对比的监控
• 错误率/延迟实时告警

发布期间的可观测性核心是"能区分新旧版本并对比其表现"。做法：为每个版本注入 version 标签（镜像 tag、发布版本、金丝雀维度），使指标（请求量、错误率、延迟、饱和度）可按版本拆分；用 Prometheus 等把 version 作为 label 采集，构建"按版本分组的错误率、p99 延迟"查询，实时对比新旧版本曲线。发布阶段设置分级告警：错误率突增、延迟上升、失败率超阈值即触发告警，配合流量权重变化观察版本间差异。还需关联日志与链路追踪（version 透传到 trace），便于发布期排障。核心是"版本可区分 + 指标可对比 + 告警可响应"。

发布可观测性要解决"新旧版本表现对比"：版本标签是基础，指标拆分是手段，分级告警是响应。答题要点是"version label、按版本对比、错误率/延迟告警"。

• 镜像 tag/digest 与构建号的关联
• 运行时版本暴露（Version 接口、健康检查）
• 排障时从运行实例回溯到代码

发布版本可追踪性要求"从线上运行实例能随时追溯其对应镜像、构建号与代码"。实现：镜像用不可变 tag/digest 标识，构建号与 commit 关联，并把这些信息写入镜像 label 与运行时元数据。运行时暴露版本：通过应用暴露 /version（或 /healthz 返回版本、build 信息）接口，或把版本作为 Pod label、环境变量注入，使运维能查询当前节点部署的是哪个版本。监控与日志也带上版本标识。排障时：从错误日志/指标看到版本 → 查该版本镜像 digest → 回溯构建号与 commit → 定位代码变更，形成"线上→制品→代码"的完整链路，支撑快速定位与回滚决策。

可追踪性解决"排障时不知道线上是什么版本"的痛点。答题要点是"tag/digest 不可变 + 构建号关联 + 运行时版本暴露 + 回溯链路"。

• 发布窗口与冻结期的定义
• 审批流程与分级
• 窗口外紧急发布的豁免机制

发布窗口与变更管理用于控制"何时能发布、发布需经过什么审批"。发布窗口通常限定在业务低峰期（如夜间、周末），避免高峰发布影响线上；冻结期（freeze）在重大节点（如大促、版本发布季）禁止非紧急变更，降低风险。审批流程按变更风险分级：低风险走快捷审批，高风险（生产、数据变更、核心服务）需多级审批与风险评估。窗口外紧急发布需要豁免机制：明确紧急判定标准（如线上 P1 故障、安全漏洞），由具备权限的负责人（如值班经理/审批人）审核放行，记录紧急原因与事后补审，形成"异常可应急处置、事后可审计"的闭环。核心是"可预期用窗口、不可预期用豁免"。

变更管理是"确定性"与"灵活性"的平衡：窗口/冻结期提供确定性，紧急豁免提供灵活性。答题要点是"窗口与冻结期、分级审批、紧急豁免与事后补审"。

• 三种策略的特点与风险
• 回滚复杂度与速度
• 数据兼容性约束

发布策略选型需综合业务风险、回滚复杂度与数据兼容性。滚动发布：渐进替换实例，资源占用小、兼容多数场景，但若数据不兼容会在中间态暴露问题，回滚较慢（需重新滚动）；金丝雀：先放少量流量验证，风险低、可观测，适合高流量、可精细监控的场景，但需要流量治理与指标判定能力；蓝绿：双环境整体切换，回滚极快（切回即可），适合高风险、要求快速回滚的场景，但资源双倍、要求数据/schema 兼容。选型依据：业务风险高、可用性要求严→蓝绿或金丝雀；数据不兼容、无法共存→滚动风险大，需谨慎或配合迁移；资源受限→滚动；回滚速度要求极高→蓝绿。核心是"风险与回滚能力匹配"。

选型是"风险×回滚×资源×数据"的权衡。答题要点是"三种策略的适用场景与约束 + 按风险、回滚、数据兼容性做匹配"，避免一刀切。

• 自动与手动回滚触发
• 快速回滚路径与回滚后验证
• 版本保留策略

回滚设计需覆盖触发、路径、验证与保留。触发上，自动回滚由指标判定（如错误率超阈值、健康检查失败）触发，手动回滚由人工在发现问题时触发；自动触发需设置去抖与观察窗口，避免误回滚。快速回滚路径：预先准备好回滚命令（如 kubectl rollout undo、切换镜像 tag、切回蓝绿环境），保证数分钟内完成。回滚后验证：回滚后确认服务恢复、指标正常、无残留问题，并把回滚记录到变更审计。版本保留策略：保留最近 N 个可回滚版本（镜像、配置、构建产物），设定保留期与清理规则，既保证可回滚又控制存储成本。核心是"回滚要快、要验证、要可追溯"。

回滚是发布的"应急预案"。答题要点是"自动/手动触发、快速路径、回滚后验证、版本保留"，体现回滚的完整闭环。

• 用户分桶与一致性哈希
• 会话粘性（sticky session）
• 特征开关（feature flag）与流量权重配合

基于用户的灰度让"特定用户"看到新版本：先按用户标识做一致性哈希分桶，把用户稳定划入灰度组，保证同一用户始终体验同一版本（避免跳变）。会话粘性保证一次会话内请求始终命中同一后端版本，配合 Cookie/负载均衡的 sticky 机制实现。特征开关（feature flag）与流量权重配合：可以在应用内按用户/分桶开启特定功能，也可以把特征开关与流量权重结合——流量权重决定请求分发比例，特征开关决定功能是否生效，形成"按用户 + 按功能"双维度灰度。配合指标对比（灰度用户 vs 全量用户）评估，验证通过再逐步扩大灰度范围。核心是"用户可稳定分组 + 会话不跳变 + 功能可开关"。

用户灰度是"流量权重 + 用户维度"的结合。答题要点是"一致性哈希分桶、会话粘性、特征开关与权重配合"，体现对用户稳定体验与功能控制的综合理解。

• maxSurge 与 maxUnavailable 的含义
• 组合对可用性与发布时长的权衡
• 滚动发布策略的选择

Kubernetes 滚动发布的速率由 maxSurge 与 maxUnavailable 控制。maxUnavailable 表示滚动过程中允许的最大不可用 Pod 数（相对期望副本数，百分比或绝对数），保证可用副本不低于 期望 - maxUnavailable；maxSurge 表示允许超出期望副本数的最大额外 Pod 数（百分比或绝对数），决定一次能新增多少新 Pod。两者权衡：maxSurge 大、maxUnavailable 大→发布更快、占用资源更多、瞬时可用性波动更大；反之则发布更慢、更保守、可用性更稳。典型组合：maxSurge=25%、maxUnavailable=25% 平衡速度与可用性；要求高可用时把 maxUnavailable 设小（如 0）并配合 maxSurge 保证滚动期新增 Pod 补充容量。核心是"在可用性底线与发布时长之间取平衡"。

速率控制是滚动发布的核心参数。答题要点是"maxSurge 控制新增、maxUnavailable 控制不可用上限、二者权衡可用性与时长"，并理解对资源占用与决策响应的影响。

• 关键 SLO 阈值设定
• 观察窗口与去抖
• 人工确认与自动回滚的边界

自动回滚的指标触发设计要回答"什么指标、什么阈值、观察多久、要不要人工"四个问题。指标选择：关键 SLO（错误率、p99 延迟、可用性、核心业务指标）作为触发依据，优先选与用户核心体验强相关的指标。阈值设定：基于历史基线设定，如错误率 > 0.5% 或 p99 延迟超过基线 2 倍，避免过于敏感（误回滚）或过于迟钝（漏报）。观察窗口：连续 N 个周期/持续 T 秒超阈值才触发，设置去抖与冷却，避免瞬时抖动误触发。人工确认边界：对高风险变更或自动回滚可能造成的影响，可设置为"自动回滚候选 + 人工确认"，即指标超阈值先告警、暂停放量，由人确认后回滚；对低风险可完全自动回滚。核心是"自动判定 + 安全边界 + 必要时人工兜底"。

自动回滚设计要平衡"快"与"稳"：阈值要准、窗口要去抖、人工边界要清晰。答题要点是"指标/阈值/窗口/人工确认四要素 + 防误触发的去抖机制"。

• 系统指标：错误率、p99 延迟
• 业务指标：转化率、关键业务量
• 多指标综合判定

金丝雀分析的指标选择要兼顾"系统健康"与"业务影响"。系统指标：错误率（HTTP 5xx/失败率）、p99 延迟（反映长尾体验）、可用性、饱和度，直接反映服务是否稳定；业务指标：转化率、下单成功率、关键业务量、用户活跃，反映新版本对业务结果的影响。综合判定时，把系统指标与业务指标都纳入，任一类异常都应触发判定失败或告警；例如系统指标正常但转化率显著下降，说明业务逻辑有问题。需用统计对比（金丝雀 vs 基线）判断差异显著性，并设置各自的阈值。核心是"系统与业务双维度 + 显著性判定 + 合理加权"，避免单一指标误判。

金丝雀判定不能只看系统指标，业务指标同样关键。答题要点是"系统指标（错误率/p99）+ 业务指标（转化率）+ 显著性综合判定"，体现对发布质量的全面理解。

• 权重步进（灰度阶段）
• 对比窗口（观察时长）
• 显著性判定（统计方法）

金丝雀的流量分配与判定需要设置三要素。权重步进：把灰度流量分成若干阶段（如 5%→10%→25%→50%→100%），每阶段停留一定观察时间，逐步放大，避免一步到位风险。对比窗口：每个权重的观察窗口要足够长（含覆盖业务高峰、足够样本量），保证指标稳定可比；窗口过短结论不可靠。显著性判定：用统计方法（如曼-惠特尼 U 检验、置信区间）对比金丝雀与基线指标，判断差异是否显著而非随机波动，只有显著超阈值才回滚或判定失败。权重步进与判定结合：每一步都先判定再放大，形成"渐进验证、数据驱动"的节奏。核心是"步进可控、窗口充足、判定显著"。

金丝雀是"渐进 + 判定"的迭代过程。答题要点是"权重步进、对比窗口、显著性判定"三要素的配合，体现对统计严谨性的重视。