SH

Soloharness

概念 · 辨析 · Agent

← 返回概念辨析

Concept Contrast Fable

先上一小批和逐步放量给用户

金丝雀部署和金丝雀发布,名字几乎一样,但在工程实践中指向不同环节。金丝雀部署关注把新版本先部署到少量实例上运行,金丝雀发布关注把新版本先开放给一小部分用户流量。前者验证运行稳定性,后者验证用户体验——两者经常串在一条发布管线里,但监控重点和回滚触发条件不同。

寓言

酒庄尝第一口和客人尝第一壶

城南有一家百年酒庄,酿酒师傅有一道祖传规矩:新酒出窖,先倒一小盅放在灶台边,过两炷香的时间,闻一闻有没有酸味、看看有没有沉淀物。这叫灶前验。灶前验没出问题,才敢开坛装壶。

开了分号以后,庄主加了一道规矩:装好壶的酒,先送五壶到分号最熟的老客人桌上,不收钱,让客人喝。喝完问三句:口感对不对、后劲大不大、隔天头疼不疼。这叫桌前试。桌前试全部满意,第二天才往酒单上挂新酒的牌子。

有一年出了岔子。新酒通过了灶前验——站在灶台边看,颜色清亮、没有酸味。直接跳过了桌前试就挂了牌子,第二天全城上架。第一天的客人都说好。第三天开始有客人来退酒——这批酒喝了隔天头疼,还口干。灶台两炷香验不出来的东西,客人喝完睡一觉验出来了。

庄主关了三天门,把灶前验和桌前试拆开写成了两条线。灶前验查的是酒本身的稳定性——会不会变质、有没有杂质、酒精度对不对。桌前试查的是客人喝完之后的体验——口感、后劲、隔天的身体反应。两炷香的窗口和睡一晚的窗口,测的是完全不同的东西。

后来越做越大,庄主发现还有一个边界需要管:灶前验应该覆盖多少坛酒?只验一坛,其他九十九坛可能是同一个毛病。桌前试应该覆盖多少客人?只送五壶给老熟人,他们口味固定,喝不出新问题。庄主把灶前验从一坛加到抽验五坛,把桌前试从五壶加到三十壶,送到不同类型的客人桌上。覆盖面和采样策略也得分着管。

外地酒商来取经,庄主在招待宴上画了张图:灶前验查的是能不能跑——酒装坛后放不坏。桌前试查的是能不能喝——客人真喝之后满不满意。先跑才能喝,跑了不一定能喝。两件事不能减成一件。

酒庄后来把这张图挂在了出货间:新酒上架看两关,灶前一关、桌前一关。哪关跳过,哪关补钱。

金丝雀部署

将新版本先部署到少量实例上,验证应用本身能否正常启动、运行、响应健康检查。关注基础设施和运行时稳定性,通常先于用户流量接入。

金丝雀发布

将一小部分用户流量路由到新版本,验证用户体验、功能正确性和业务指标。关注用户侧行为和业务数据,在部署验证通过后进行。

故事对应

  • 灶前验:金丝雀部署,验证新版本在运行时环境中是否稳定
  • 桌前试:金丝雀发布,验证真实用户流量的体验和业务指标
  • 跳过桌前试直接上架:只做金丝雀部署不做金丝雀发布的典型事故
  • 两炷香和睡一晚:部署验证窗口短,发布验证窗口需要覆盖完整的用户行为周期
  • 抽验五坛和三十壶:部署的采样覆盖实例数,发布的采样覆盖用户流量比例

落到发布流程设计

金丝雀部署和金丝雀发布应该作为两个独立阶段串在发布管线里。第一阶段部署到金丝雀实例上,监控 CPU、内存、错误率和启动时间——异常时回滚不接入流量。第二阶段把一定比例的流量切到金丝雀实例上,监控用户侧指标——业务错误率、延迟分布、关键转化率——异常时切回流量的同时保留实例做问题排查。两个阶段需要不同的监控面板和不同触发条件的回滚机制。