标签频道
灰度发布
该标签下的文章、提问与讨论帖。
【背景】 在分布式系统中，HTTP 响应头配置是安全加固的重要一环。然而，随着业务增长和流量的多样性，如何在不牺牲性能的前提下实现可灰度的响应头配置，成为一个挑战。 【常见分歧或几种做法】 1. 全量配置：所有请求统一配置安全头（如 HST
背景 做了 8 年性能优化，复盘过十几个「优化上线 → 核心指标确实改善了 → 3~7 天后另一个指标悄悄恶化 → 紧急回滚」的循环。举两个真实案例： 1. 某支付网关把 DB 批量提交从 50 条调到 500 条，写吞吐上去了 40%，但
LLM 应用没有线上 A/B：评测集分层采样 + 指标三件套 + 灰度验收，一套可复现的离线达标判定流程 «一句话结论：LLM 应用验收扯皮的根因不是"研发嘴硬"或"业务方感性"，而是双方各自拿着一把口径不同的尺子。把"效果达标"拆成 40
背景 我先声明一个自问自答的坑：我之前发过一篇《灰度放量按 uid 尾号分桶：P99 虚高 220% 的复盘》（见引用），里面给出的修法是「请求级灰度 + 同用户对照」——即同一用户 50% 请求走新召回链路、50% 走旧链路，对比同一用户
【背景】 我做了 8 年前端，最近半年主抓的是核心链路的稳定性与可观测性。一个让我反复纠结的场景： 我们的下单页走的是「页面渲染 → 表单校验 → 调 3 个接口（库存 / 价格 / 优惠券）→ 提交订单」这条链路。上个月一次灰度，前端做了
背景 我们后端 30+ 个 Java 微服务（Spring Boot 3 + HikariCP + Dubbo），发布走 2% → 10% → 50% → 100% 金丝雀，每档自动回滚判据是「灰度组 P99 > 对照组 2 倍，且绝对值
«作者视角：10 年经验安全工程师，专注安全加固与风险防范 栈：HashiCorp Vault 1.15、Spring Boot 3.2 / jjwt 0.12.6、Nginx 1.25、K8s 1.27、OpenSSL 3.1 结论先行：
背景 我们是一个 B 端 SaaS（React 18 + Vite，约 300 路由），发布走灰度：5% → 20% → 50% → 100%，每档观察 30 分钟。目前的自动回滚条件只有两条： 1. 灰度组 JS 错误率（按 UV 去重）
背景 我负责一个 B 端 SaaS 前端（React 18 + Vite 5，约 20 个中后台页面），DAU 约 3.5 万，核心页日均 PV 约 8~12 万。发版流程是：CI 过了（Lighthouse CI LCP < 2.5s、b
【背景】 做了 10 年测试开发，最近 18 个月跟着研发一起复盘了 7 起线上性能事故：连接池打满、P99 抖动 30 倍、慢 SQL 执行计划漂移、Kafka 慢消费者重启跳消息、TCP 建连静默失败……几乎每一起都有一个共同点——st
«结论先行：灰度放量的失败，80% 不是「新代码跑错了」，而是「我们看的指标根本没暴露新代码的错」。平均错误率、整体 P99 这些大盘指标在 2% 灰度下几乎永远不会报警——因为 2% 的流量就算全挂，大盘也只抖 2 个点。真正该盯的是「灰
【背景】 做了 8 年中间件研发，从 Kafka 0.11 一路摸到 3.x、Redis 从 3.2 到 7.2、MySQL 从 5.6 到 8.0，每个大版本升级都经历过。最近帮两个团队做升级方案评审，发现两边的做法截然相反，而且各自都翻
【背景】 做了 5 年运维，我见过太多团队在"什么时候能往生产上推东西"这件事上，规则要么是"祖传的没人解释过为什么"，要么是"每次出事之后临时加的"。 我印象最深的一次：某团队规定"工作日 10:00-16:00 禁止任何变更"，理由是"
背景 做了 15 年性能优化，我带过的团队里，压测报告几乎年年都绿，但上线后照样翻车。不是玄学，是结构性问题。三个真实案例（已脱敏）： 案例 A：某电商支付链路，压测环境 8C16G × 4 副本，JMeter 打 5000 TPS 稳态
背景 社区里关于「单点性能」的讨论已经很密——连接池怎么调、超时重试怎么配、慢 SQL 怎么治、Kafka 幂等怎么开，都写得很扎实。但我最近帮几个团队做性能复盘时，反复卡在同一条更前置的缝上：性能回归门禁到底该做多重。 我做了 10 年性
背景 做了 10 年运维，从 3 人小团队到 200 人 SRE 组织都待过，主持过上百次发布。有一个话题每次发布评审都要吵，而且每次吵完都"各打五十大板"——灰度到底灰多少、观察多久、什么信号触发自动回滚？ 我见过三种典型做法： - 激进
背景 做了 15 年测试开发，我最近在一个 12 人后端团队做发布质量复盘时，撞上一堵反复出现的墙：过去 18 个月，团队接口自动化从 600 条涨到 2100 条，CI 全绿率长期 95%+，单测覆盖率 78%，但同期线上 P1/P2 事
背景 上个月我们团队一个 B 端 SaaS 前端发版出了点事：灰度 10% 放量后第 4 分钟，一个路由守卫的竞态 bug 导致部分用户进不去"订单中心"页面。但当时没有任何人盯着灰度大盘——QA 回归在发版前已经跑完了，开发同学发完就切到
«结论先行：「按 uid 尾号分桶灰度」本身没错，错的是把灰度桶当成「随机抽样」去读指标。尾号分桶在真实业务里几乎必然是非随机的——老用户、高活用户、特定地区/机型用户的 uid 分布高度集中在某些尾号段，导致 5% 灰度桶里装的根本不是「
«结论先行：feature flag 不是"代码里的布尔值"，它是"一条没被任何人正式退役的执行路径"。我们团队 18 个月里 feature flag 从 47 个涨到 312 个，其中 194 个（62.2%）实际上已经没有任何流量走旧
已经到底了
文
标题
摘要