灰度发布
Canary Release也常被叫作：金丝雀发布小流量上线分批上线
「怕一上线就全崩，能不能先让一小部分人用，没问题再放开？」
灰度发布 Canary Release
先把新版本放给一小部分用户，观察没问题再逐步扩大到全部。
灰度发布的做法：新版本先只服务一小部分用户（比如 5%），盯着监控和错误率，确认没事再逐步放大到 100%。它的本质是把「上线失败」从「全体用户一起遭遇」变成「一小部分用户先遭遇，且你能立刻收回」。
它和「直接全量上线」的差别不在流程，而在失败半径。全量上线出问题，影响面是 100%；灰度出问题，你最多只让 5% 的人受影响，而且切回去也快。
三个容易做错的地方。第一，灰度的前提是能观测：没有监控、没有错误率数据，灰度就只是「分批上线」，你不知道该不该继续放量。第二，用户分配要随机：让前 5% 注册的人先用，样本就偏了。第三，回退要快：灰度期间发现异常，应该一键切回旧版本，而不是慢慢改。
长什么样 真实可交互，不是截图
一键切回旧版本
所有人一起遭遇白屏
同样的 bug，灰度让你花几分钟收回，全量让你花几小时救火。差的就是失败半径。
拆开看，里面有这几块
-
1
分配 Traffic split
怎么把一小部分用户导向新版本。要随机，不要挑前 N 个。
-
2
观测 Observability
错误率、延迟、崩溃率。没有数据，灰度就失去了判断依据。
-
3
放量节奏 Ramp-up
5% → 25% → 100% 的步骤和每步的观察时间。
-
4
回退 Rollback
异常时一键切回旧版本。灰度的安全性一大半靠它。
容易搞混？这样区分
蓝绿是两套环境瞬间切换流量，要么全旧要么全新；灰度是渐进放量。蓝绿适合「要么回滚要么前进」，灰度适合「先观察再决定」。
什么时候用得上
前端大改、后端重构，先 5% 灰度观察半天到一天。
支付、价格、积分规则，灰度到 1% 先盯着错误率和退款。
先别灰度——没有观测手段的灰度只是分批赌博。
你可以这样跟 AI 说
直接复制下面这段，把【】里的换成你的情况。它比一句「帮我加个 X」多说清楚了：改哪里、不许动啥、做完交什么。
【任务】为 [这个改动] 安排灰度发布 【要求】 1. 设计放量节奏：先 [5%] 用户，观察 [1 小时] 正常后再放大到 [25%]，再 [100%] 2. 灰度期间我要盯的数据：错误率、接口延迟、崩溃率——告诉我这几个数据从哪看 3. 明确回退方案：如果灰度期间异常，具体怎么一键切回旧版本，多久能生效 【边界】灰度分配要随机，不要只给前 N 个注册用户；不要影响非灰度用户的使用 【交付】 1. 灰度是怎么实现的（配置在哪，我确认后才执行） 2. 放量的每个阶段，我怎么自己看到比例和当前数据 3. 回退的具体操作步骤
「灰度分配要随机」这条容易漏：用注册顺序分桶会让样本严重偏差，看起来正常的灰度可能只是没分到会出问题的用户。
它说「做好了」，你怎么自己验
这是本站的重头戏。AI 最会的不是写代码，是说「已完成」。这一条，它通常最多做到「生产」这层：线上真实环境有效，有回滚和观测。
要亲眼看到这些，才算数
- 确认灰度真的只影响设定的比例：用两个不同账号访问，一个应该看到新版本、另一个看到旧版本（或按设定）。
- 灰度期间盯着错误率数据看，而不是只等用户来报问题。
- 确认回退是一键操作且路径明确——不是「改个配置重新部署」这种慢慢来。
- 放量每一步之间留了观察时间，没有 5% → 100% 一步到位（那就不是灰度了）。
- 确认分桶是随机的，不是按注册顺序或固定地区。
它常这么糊弄你
- 「已灰度到 5%」——但实际是前 5% 的用户，样本偏到等于没测。
- 「灰度通过，可以全量」——但灰度期间根本没看错误率，只是没用户骂。
- 「出问题能回退」——但回退需要改代码重新发布，不是切换。要问清回退具体怎么做。
- 灰度从 5% 直接跳到 100%，美其名曰「用户反馈不错」。那就不叫灰度，叫心理安慰。
灰度发布本身就在「生产」层运行——它是对真实用户的生产操作，所以验收也在真实环境里做。
考考你 选一个你觉得对的
灰度发布最关键的前提条件是什么？
灰度的每一步决策（继续放量还是收回）都依赖观测数据。B 只是让灰度更必要，不是前提；C 是好事但测试永远测不全真实环境；D 是团队安排，不是前提。