3. 版本管理核心概念

在保险费率系统中，一次费率调整往往牵动核保、报价、出单、续保等多个环节。如果团队对版本管理术语理解不一致，就会出现“说的是同一个词，做的却是两件事”的协作事故。本节把费率版本管理中最常用的八个术语放在同一张认知地图上，帮助你在评审、发布和复盘时使用统一语言。

一、核心原理：版本管理是“状态可追溯”的工程能力

费率版本管理的本质，是让每一次费率变更都具备可标识、可复现、可回退、可审计四个属性。版本号解决“是哪一版”，基线解决“以什么为基准”，分支解决“并行怎么改”，合并解决“改动怎么汇”，快照解决“当时是什么样”，回滚解决“出错怎么退”，灰度与蓝绿解决“新版本怎么安全放量”。它们不是孤立概念，而是一条从变更到上线的完整链路。

二、方法流程：从版本号到上线的标准动作

费率版本号建议采用语义化三段式：主版本.次版本.修订号，必要时追加环境或渠道后缀。主版本表示费率结构或定价模型发生不兼容变更；次版本表示新增险种、因子或规则；修订号表示参数微调、文案修正。例如：

rate-2.3.1          # 主版本2，次版本3，修订1
rate-2.3.1-uat      # UAT环境验证版本
rate-2.3.1-prod-sh  # 上海渠道生产版本

基线是经过评审并冻结的版本集合，通常对应一次监管报备或季度定价发布。分支用于并行开发，例如“车险费率优化分支”和“健康险因子调整分支”互不干扰。合并时需执行差异比对与冲突解决，确保因子表、系数表、条款映射一致。快照是某一时刻全量配置的只读副本，回滚则基于快照恢复。灰度按用户、渠道或保额区间逐步放量，蓝绿通过双环境切换实现秒级回退。

三、案例/场景：一次车险费率调整的版本旅程

某保险公司计划调整车险自主定价系数。团队从rate-2.3.1基线拉出feature-auto-coef分支，完成因子表修改后合并回主干，生成rate-2.4.0。上线前创建快照snap-20240612-01，先在灰度环境对5%续保客户放量，监控出单成功率与赔付预估偏差。确认稳定后扩量至100%，蓝环境保留旧版本一周以备回切。若发现异常，可依据快照在分钟级回滚至rate-2.3.1。

四、误区/复盘：术语混用带来的真实代价

• 把“回滚”等同于“重新发布旧包”。若旧包依赖的数据库结构已变更，直接重发可能失败，正确做法是基于快照恢复配置与数据。
• 把“分支”当“基线”。分支是动态开发线，基线是冻结基准；用分支直接上线会导致版本不可追溯。
• 灰度只看技术指标，不看业务指标。费率灰度必须同时监控保费收入、赔付率预估和渠道转化，否则可能“系统正常、业务失控”。
• 蓝绿切换后立即销毁旧环境。应保留旧环境至少一个观察周期，确保可快速回切。