回滚、变更与配置管理

• 向后兼容的字段原则（可选字段、默认值）
• 弃用（deprecation）策略
• 版本共存与平滑迁移

API 版本演进保证向后兼容的核心是"新增不破坏、删除要谨慎"。字段层面：新增字段必须是可选字段（带默认值或有默认行为），客户端不传也能正常工作；禁止修改已有字段语义、类型或移除必填字段。弃用策略：对要移除的字段/接口先标记 deprecation（文档、响应头、warning），保留一段过渡期并在日志中提示，让客户端有时间迁移，达到版本要求后才移除。版本共存：当破坏性变更不可避免时，通过版本号（path 或 header 版本）让新旧版本共存，新客户端用新版本、旧客户端继续用旧版本，配合迁移监控与到期下线，实现平滑升级。核心是"先加后减、可观测迁移、版本共存兜底"。

向后兼容是 API 演进的生命线。答题要点是"可选字段、弃用过渡、版本共存"三招，体现"渐进式迁移"而非"一刀切"的思想。

• Conventional Commits 规范（type/feat/fix/breaking）
• 语义版本号推导（major/minor/patch）
• 变更日志自动生成

Conventional Commits 规定提交信息格式为 <type>(<scope>): <description>，type 包括 feat（新功能）、fix（修复）、docs、chore 等，并在提交中标注 breaking change（如 ! 或 BREAKING CHANGE:）。语义版本号由此推导：feat 提升 minor 版本，fix 提升 patch 版本，breaking change 提升 major 版本，其余类型不提升。工具（如 semantic-release、standard-version）读取提交历史，自动计算版本号并生成变更日志（changelog），把每个 fix/feat 归类到对应章节。这使版本号、日志与提交历史强关联，支撑发布与回溯。核心是"提交规范→版本推导→日志生成"的自动化闭环。

Conventional Commits 让"提交信息成为版本与日志的事实来源"。答题要点是"type 语义、版本号推导规则、日志自动生成"，体现结构化提交的价值。

• OneFlow 的分支结构与主干理念
• 特性分支与发布分支的创建/合并
• 与 GitFlow/Trunk-based 的对比

OneFlow（简化版 GitFlow）提倡"单主干 + 少量辅助分支"，比 GitFlow 更轻。核心是主干（main/master）始终可用，特性分支从主干拉出、完成合并回主干，通过短生命周期分支支持并行开发。发布不设长期发布分支，而是从主干打 tag（或创建临时 release 分支）发布，发布后 tag 即代表版本；如需修复，从对应 tag 或主干拉短分支修复后合回主干。相比 GitFlow 的多分支（develop/feature/release/hotfix），OneFlow 用主干+tag 简化模型，降低合并成本，更适合快速迭代；与 Trunk-based 相比，OneFlow 仍允许适度特性分支。核心是"主干为主、过程简化、tag 定版本"。

OneFlow 是"主干为中心"的折中模型。答题要点是"主干始终可用、特性分支短生命周期、发布用 tag/临时分支"，体现对分支模型取舍的理解。

• 短分支与频繁合并主干
• 特性开关（feature flag）控制未完成功能
• 主干始终可发布

Trunk-based development（主干开发）的核心是"所有开发都在主干上小步快速进行"：开发者创建极短寿命的特性分支（数量级为小时/天），频繁合并回主干，避免长分支合并冲突与"合并地狱"。为让未完成功能不破坏主干，用特性开关（feature flag）把功能隐藏在配置开关后，未放量前默认关闭，代码先合入主干但不影响线上，待完成再开启。主干始终处于可发布状态，配合 CI 持续验证。相比功能分支，trunk-based 强调"小步、快合、可开关"，支持高频发布与并行开发。核心是"短分支 + 频繁合并 + 特性开关保证主干可发布"。

Trunk-based 是"主干可发布"的工程实践。答题要点是"短分支、频繁合并、特性开关"三招，尤其特性开关是"未完成功能不阻塞主干"的关键。

• pre-upgrade 与 post-upgrade 阶段划分
• 扩缩容与兼容性
• 与代码发布节奏的配合

数据库两阶段迁移把变更拆成"pre-upgrade（上线前）"与"post-upgrade（上线后）"两个阶段，与应用发布解耦。pre-upgrade：在应用新版本前完成"可向前兼容"的变更，如新增列/表、新增索引、为旧数据初始化，保证新旧代码都能正常运行；post-upgrade：在应用稳定切换后执行"需新代码才安全"的变更，如删除旧列、清理冗余数据、收紧约束。设计要点：每阶段变更都要可回滚、可观测；pre 阶段要保证旧版本不受影响，post 阶段要保证新版本已就绪。两阶段配合应用发布，形成"先兼容、再发布、后清理"的安全节奏。核心是"区分前后向兼容，避免一次性破坏性变更"。

数据库变更与代码发布是"先扩展后收缩"的关系。答题要点是"pre 向前兼容、post 向后清理、与发布节奏解耦"，体现对 expand-contract 思想的应用。

• expand 阶段：新增并行结构
• migrate 阶段：数据迁移
• contract 阶段：移除旧结构

expand-contract（并行变更）迁移分三阶段：expand（扩展）——新增新的表/列/索引等结构，与旧结构并存，此刻新旧代码都能读写；migrate（迁移）——把数据从旧结构迁移到新结构，并做双写/校验确保一致性，期间新旧代码可能同时运行；contract（收缩）——确认新结构稳定后，移除旧结构、切换代码完全指向新结构。主要风险：迁移期间数据不一致（双写失败、部分迁移）、迁移耗时长、切换失败需回滚。缓解：分阶段小步、双写校验、限流与幂等、明确的回滚点。核心是"长短迁移解耦、双写保证一致、收缩谨慎"。

expand-contract 是"无停机"的数据库演进模式。答题要点是"expand/migrate/contract 三阶段 + 双写一致性与回滚风险"，体现对复杂迁移工程的理解。

• 配置纳入版本控制与声明式管理
• 环境差异的隔离与覆盖
• 可审计变更（审批、留痕、回滚）

配置即代码（Configuration as Code）把环境配置当作代码管理：用 Git 存储配置（YAML/JSON/Helm values/Kustomize overlay），通过 PR/MR 审批变更，配置纳入版本控制后天然具备历史、审计与回滚。环境差异用分层/覆盖表达：公共基线 + 各环境 overlay（dev/staging/prod）覆盖，避免复制粘贴造成漂移。可审计变更：配置变更走分支审批、记录变更人与原因、配置部署留痕（谁在何时改了什么），并支持回滚到历史版本。配合 GitOps 或配置工具（如 Helm、Kustomize、Ansible）把配置应用到目标环境，实现"配置即代码、变更可审计、环境可复现"。核心是"配置入库 + 审批流程 + 可追溯回滚"。

配置即代码的核心价值是"可审计性与可复现性"。答题要点是"配置入库、环境覆盖、审批留痕与回滚"，体现对配置治理的理解。

• 审查范围与粒度（小 PR、聚焦逻辑）
• 自动化检查（lint、测试、静态分析）前置
• 效率与人工审查的平衡

Code review 最佳实践要点：一是小 PR——把变更拆成小、聚焦的提交，便于审查者快速理解，提高审查质量与效率；二是范围聚焦——重点关注逻辑正确性、边界条件、安全与性能，而非格式问题（格式由自动化处理）；三是自动化前置——用 lint、格式化、单元测试、静态分析、CI 检查在审查前自动拦截低级问题，让人工聚焦"机器看不懂的"判断；四是效率平衡——避免过度审查拖慢节奏，设置评审 SLA、必要时分层审查（高风险重点看、低风险简审）。核心是"机器做重复检查、人工做价值判断、小步快审"。

Code review 是把"机器检查"与"人工判断"分离。答题要点是"小 PR 聚焦、自动化前置、效率平衡"，体现工程化评审的思想。

• WebAuthn 绑定流程（注册/登录）
• 设备丢失恢复机制
• 变更审批中的强身份核验

WebAuthn 无密码认证在运维平台落地需覆盖三点。绑定流程：用户注册时生成密钥对，私钥存于安全设备（USB 密钥/平台认证器），公钥注册到平台；登录时用挑战-响应（challenge）验证私钥，实现免密码防钓鱼。设备丢失恢复：提供备用认证器、恢复码（一次性）、或走管理员引导的二次身份验证流程重新绑定，避免因设备丢失导致锁死。变更审批的身份核验：对高危变更（生产部署、权限变更、密钥轮换）要求执行"重新认证"（step-up auth），用 WebAuthn 做二次确认，防止已登录会话被冒用或劫持；审批环节记录认证器与操作者，形成强身份审计。核心是"无密码安全 + 设备丧失可恢复 + 高危操作强核验"。

WebAuthn 落地要解决"安全、恢复、强核验"三件事。答题要点是"绑定与挑战响应、恢复流程、高危变更的二次身份核验"，体现对无密码认证的工程化理解。

• 变更申请与记录
• 风险评估与分级
• 审批、实施窗口与干系人通知

变更管理标准流程形成闭环：变更申请——提交变更内容、目的、影响范围、回滚预案，形成变更工单；风险评估——按影响面、是否生产、数据变更、依赖风险对变更分级（低/中/高），高风险需更严格评估；审批——按风险等级走对应审批链（低风险自助、高风险多级+变更委员会），审批留痕；实施窗口——在预定的变更窗口（业务低峰）执行，按计划步骤实施并监控；通知干系人——实施前通知相关团队（业务、运维、值班），变更中同步状态，变更后关闭并汇报结果。闭环在于每步有记录、有验证、有回滚预案，形成"申请→评估→审批→实施→通知→复盘"的完整链路。核心是"分级审批、窗口可控、全程可追溯"。

变更管理是"规范化 + 灵活性"的平衡。答题要点是"申请、评估、审批、窗口、通知"各环节闭环，体现对变更治理的完整理解。

• 分支保护规则（required reviews）
• 状态检查（CI）强制通过
• 生产分支的保护策略

分支保护（branch protection）在 Git 平台（GitHub/GitLab）上为关键分支（如 main、release）设置强制性规则：required reviews——要求至少 N 个审批人通过才能合并；required status checks——要求 CI 状态检查（测试、lint、构建）全部通过才能合并；此外可禁用直接推送、要求线性历史、签名提交等。这样保证进主干的关键分支必须经过人工评审与自动检查，阻断未验证的变更。生产分支通常加最严格的保护（多审批 + 状态检查 + 签名），并限定可合并的角色。核心是"把评审与检查变成合并的硬性门槛"，实现分支级质量门禁。

分支保护是把"评审与检查"固化为机制。答题要点是"required reviews + required status checks + 生产分支严格保护"，体现对分支质量门禁的理解。

• FIDO2 硬件密钥的认证机制
• 审批与执行环节的强认证
• 防钓鱼（phishing）与防冒用

FIDO2 硬件密钥（如 SoloKey）用公钥密码学实现强认证：用户在高危变更审批/执行时，用硬件密钥做挑战-响应认证，私钥存在于硬件内、不离开设备，且绑定站点 origin，天然防钓鱼（伪造站点无法让密钥响应）。落地设计：把 FIDO2 作为高危变更的"二次认证/step-up auth"——审批环节要插入密钥并验证，执行环节（如重大生产变更、密钥轮换、权限授予）也要求现场强认证，防止已登录会话被劫持或冒用。可配合密钥作为"第二因素"或"唯一因素"（无密码），并做多密钥管理（备用密钥防丢失）。核心是"硬件隔离私钥 + origin 绑定防钓鱼 + 高危操作强制认证"。

FIDO2 强化高危变更的核心是"私钥在硬件、防钓鱼、强制认证"。答题要点是"硬件密钥机制、二次认证、origin 绑定防钓鱼、备用密钥"，体现对无密码强认证的理解。

• MR/PR 审批流作为变更门禁
• 分支保护与评审
• 变更审计与留痕

GitOps 用 MR/PR 审批流把"变更管理"落到 Git 层：所有期望状态变更都通过提交 MR/PR 发起，受保护分支要求评审通过、状态检查通过才能合并，从而让"变更审批"成为 Git 的强制流程。审批流提供审计：每个合并记录了变更内容、审批人、时间与关联 issue，形成不可篡改的变更历史；配合签名提交与 provider 校验，可追溯"谁改了什么、谁审批的"。审批之外，GitOps 的自动同步只执行 Git 已批准的变更，不引入额外人为操作，避免绕过审批。因此 MR/PR 审批流既是质量门禁，也是审计证据链，实现"变更可审批、可追溯、可回滚"。核心是"审批固化在 Git 层 + 全程留痕 + 同步不越权"。

GitOps 的变更管理把审批前置到 Git 层。答题要点是"MR/PR 审批门禁、分支保护、审计留痕、同步不绕审批"，体现对 GitOps 审计价值的理解。

• MAJOR.MINOR.PATCH 语义
• 兼容性声明与依赖约束
• 对 API/库用户的指导

SemVer 用 MAJOR.MINOR.PATCH 三部分表达兼容性：MAJOR 版本不兼容（破坏性变更），MINOR 向后兼容的新功能，PATCH 向后兼容的缺陷修复。它给 API 与库的发布提供了明确的兼容性契约：MAJOR 升版意味着使用者必须适配；MINOR 升版可放心升级（新增功能不破坏）；PATCH 升版最简单安全。对使用者，SemVer 支撑依赖约束（如 ^/~ 范围）与升级决策：在 MINOR/PATCH 范围内可自动升级，MAJOR 升版需人工回归。对发布者，SemVer 强制"破坏性变更必须升 MAJOR"，避免隐式破坏。核心是"用版本号表达兼容性承诺，指导 API/库的升级与回归"。

SemVer 是"版本即契约"的思想。答题要点是"三类版本语义、兼容性承诺、依赖约束与升级决策"，体现对版本兼容性管理的理解。

• 快速回滚/止损预案
• 影响通报与升级
• 复盘（postmortem）与改进

变更失败处置要形成"止损→通报→复盘"的闭环。快速回滚/止损：变更前就要准备回滚预案（回滚命令、备份、版本保留），失败时第一时间止损（回滚或隔离），把影响面控制到最小；止损优先于"定位根因"。影响通报：止损后立即向干系人（业务、值班、管理层）通报影响、进展与恢复时间，升级到对应响应层级，避免信息黑洞。复盘改进：故障恢复后做 postmortem 复盘，分析根因、梳理变更流程漏洞，提出改进项（加强门禁、完善测试、改进回滚），并跟踪落实，防止同类变更再次失败。核心是"先止损、再通报、后复盘"，把失败转化为改进机会。

变更失败处置是"应急 + 改进"的结合。答题要点是"快速回滚止损、及时通报、复盘改进"的闭环，体现对故障处置全流程的理解。

• 变更记录与审批留痕
• 审计日志与执行结果关联
• 审计链的完整性与可追溯

变更审计链要求"每次变更都能追溯到执行者、审批人、结果与影响"。设计：变更记录（变更工单）记录变更内容、影响范围、执行者、时间；审批留痕保存审批人、审批意见、审批动作；审计日志记录执行过程中的操作（命令、时间、结果、新状态），并与变更记录关联（用变更 ID 字段关联）。把这些信息关联到具体执行者与结果：通过统一日志/审计系统（如操作审计、事件日志）把变更请求、审批、执行、结果串联成一条链条，支持从"某次故障"反查到"哪次变更、谁执行的、审批了什么、结果如何"。核心是"变更全程留痕 + 字段关联 + 可反查"，保证可审计与合规。

审计链的核心是"一条变更从申请到执行到结果全程可追溯"。答题要点是"变更记录、审批留痕、审计日志的关联与反查"，体现对审计闭环的理解。

• 影响面分析（范围、流量、数据）
• 依赖梳理（上下游、数据）
• 回滚预案标准化

变更风险评估标准化包含三块。影响面分析：明确变更影响的范围（哪些服务、节点、流量、数据）、用户影响程度、是否生产/核心链路，按影响面定风险等级。依赖梳理：梳理变更涉及的上下游依赖（调用方、被调用方、数据库、缓存、消息队列），评估变更对依赖的兼容性与联动影响，识别潜在连锁故障。回滚预案：标准化编写回滚步骤（回滚命令、备份恢复、版本切换）、回滚验证方式、回滚失败的后备方案，以及回滚的触发条件与责任人。三者形成标准化的风险评估模板，让高风险变更可快速识别、依赖可预见、回滚有据可依。核心是"范围清、依赖明、回滚有预案"。

风险评估标准化是"降低变更盲目性"的手段。答题要点是"影响面、依赖、回滚预案"三要素的标准化，体现对变更风险控制的工程化理解。

• 版本回退（应用/镜像）
• 数据回滚（schema/数据）
• 配置回退

回滚策略分三类。版本回退：把应用/镜像回退到上一版本（kubectl rollout undo、切换镜像 tag、蓝绿环境切换），最快，目标是恢复服务行为；数据回滚：回退数据库 schema 或数据变更（数据库迁移的 reverse、数据恢复、PITR），较复杂，需保证 schema 兼容与数据一致性，通常与版本回退配合（先回代码再回数据）；配置回退：把 ConfigMap/Secret/配置回退到上一版本，恢复配置变更。三类回滚需区分触发与顺序：通常先版本回退恢复服务，再考虑数据回滚（高风险），配置回退按需。要点是"回滚前有备份、回滚可验证、不同类型回滚有明确的执行路径与回滚深度"。核心是"按变更类型选择回滚手段，先恢复服务再处理数据"。

回滚策略要区分"代码/数据/配置"三层。答题要点是"三类回滚的适用对象、执行方式与顺序"，体现对回滚深度的理解。

• ConfigMap/Secret 热更新与传播延迟
• 不可变（immutable）配置
• 配置回滚策略

ConfigMap/Secret 变更的热更新与回滚有几个要点。传播延迟：修改 ConfigMap/Secret 后，kubelet 周期性同步到 Pod 挂载卷有延迟（默认约 1 分钟），且已挂载卷的更新需要进程感知（监听文件/重启）才生效，环境变量方式的变更不会自动更新到已运行 Pod；因此"热更新"结合进程重载或滚动重启。不可变配置：用 immutable: true 把 ConfigMap/Secret 设为不可变，阻止运行期修改，避免传播不一致，变更需通过新建对象 + 滚动更新引用实现，提升安全与一致性。回滚策略：配置回滚可把引用切回旧 ConfigMap/Secret（或旧版本），配置做成版本化（每次变更生成新名字），便于快速回退并避免新旧配置交叉污染。核心是"理解传播时序、用不可变提升一致性、版本化配置支撑回滚"。

配置热更新与回滚的关键是"传播时序 + 不可变 + 版本化"。答题要点是"传播延迟、immutable 与滚动更新、版本化回滚"，体现对 K8s 配置机制的理解。