成功率在网格语境下的真实含义

成功率最容易被简单化成错误响应的比例，但在服务网格里它有更细的切面。Sidecar 代理会按目的地服务、目的地子集、响应状态码统计请求数，因此 reviews 不同版本的子集成功率可以独立算出，不需要在 reviews 进程里加任何计数器。

这里的成功通常指非错误的响应，即正常响应和重定向都算成功。但要注意 bookinfo 的特殊性：reviews 调用 ratings 时如果 ratings 慢或出错，reviews 自身可能返回正常响应但页面里写评分暂不可用，这种业务层降级在 HTTP 语义上是成功，在用户体验层却不是。因此单纯看 HTTP 成功率会掩盖问题，需要把 ratings 的下游成功率一并拉出来交叉看。

另一个切面是网关入口成功率与服务间成功率的区别。用户从公网进入产品页面的成功率，会叠加产品页面到评论服务再到评分服务三段链路的错误；而单独看评论服务子集的成功率，只反映评论服务这一跳。金丝雀对比时应当固定对比层级，只对比评论服务不同版本这一跳的成功率，避免把产品页面的偶发错误算到评论服务头上。

响应时间的统计口径：均值陷阱与长尾优先

响应时间在网格遥测里通常以直方图形式采集，分桶记录请求耗时分布。直接看算术平均值是危险的，因为少量超时请求会把均值拉高，而大量正常请求的真实体验被稀释。

工程上更看重分位数。典型分位数反映多数用户能接受的边界，最慢分位数反映最慢那批用户的遭遇。bookinfo 场景下，评论服务的新版本因为调用评分服务且渲染不同颜色的星星，若评分服务偶发慢查询，最慢分位数可能比旧版本明显抬高，但典型分位数几乎一样。如果只看均值，会得出两版差不多的错误结论；看最慢分位数才能暴露新版本引入的下游依赖风险。

响应时间的起止点也要统一。网格侧统计的响应时间通常是 Sidecar 收到请求到 Sidecar 收到完整响应的时间，包含同 Pod 内业务进程处理时间，但不包含客户端浏览器渲染时间。对比不同版本时必须用同一统计点，不能一端用网关响应时间一端用 Sidecar 响应时间拼在一起比。

同观测窗口下的对比方法

金丝雀流量占比小，如果拿过去一段时间旧版本的全部流量和新版本的少量流量直接比，样本量和分布都不对齐。正确做法是切同窗：取最近若干分钟，分别过滤子集为旧版本和新版本的时序，按相同步长算成功率和响应时间分位数，再画两条线。

天翼云网格的可观测面板通常已经按服务子集预聚合好这类时序，开发工程师要做的只是选对过滤维度：服务名、命名空间、子集、时间窗对齐。若自己用查询语言算，核心逻辑就是按子集分组的请求成功率和按子集分组的直方图分位数，两组时序放一张图里看偏离度。

同窗对比还要排除外部变量：比如放量期间正好跑了压测脚本、或者评分服务后端在做维护、或者某边缘节点网络抖动。这些都会让新版本的响应时间突然飙高，但不是新版本代码的问题。因此对比时建议叠加评分服务的成功率曲线和节点级网络指标，做多重交叉验证。

长尾与均值的组合判断

一个成熟的金丝雀判断不是成功率达标就过，而是成功率与响应时间的组合门禁。

成功率门禁要求新版本的非错误响应成功率不低于旧版本基线减去微小容差，且绝对错误数在统计上有意义——流量太小时不轻易判失败。响应时间门禁要求新版本的最慢分位数不高于旧版本基线加约定增量，典型分位数允许基本持平或略高。

错误形态也要关注。如果错误是新出现的类型，即使总量低于门禁也要人工介入；如果是下游偶发超时透传，则与旧版本历史表现对照判断是否可接受。

bookinfo 里新版本调用评分服务这一事实决定了它的响应时间分布天然比旧版本有更长的右尾——旧版本不调下游，新版本多一跳。所以灰度前就要把这个架构差异写进门禁：允许新版本最慢分位数比旧版本高，但不允许高过某个绝对上限，也不允许新版本成功率因为评分服务错误而掉出基线。忽略这个前提，会把正常的架构代价误判成新版本回归。

下游耦合：响应时间不是独占的

新版本的响应时间里有一部分时间是花在调用评分服务上的。如果灰度期间评分服务后端发生连接池耗尽或某 Pod 被驱逐，新版本的响应时间和错误率会同步恶化，但旧版本不受影响。这时候若只盯评论服务两个子集的对比，会得出新版本不行的结论，真实原因是共享下游抖动。

解决思路是把评分服务的成功率和响应时间作为协变量同屏展示。天翼云网格的调用拓扑图里，产品页面到评论服务到评分服务的每条边都有独立指标，金丝雀分析时应同时盯三条边的同窗曲线：若新版本的响应时间上涨伴随评分服务边响应时间同步骤涨，则暂停放量、先稳住评分服务；若评分服务边平稳而新版本边独自恶化，才是评论服务新版本自身的问题。

这也是为什么权重灰度不能放得太小也不能一步到位——流量太小时评分服务边的波动在新版本样本里被放大成剧烈百分比变化，流量太大时问题已波及真实用户。中间档配合同窗对比，是统计意义与风险控制的折中。

阈值设定与决策边界

手动金丝雀靠人盯面板，自动金丝雀把上述门禁写成分析规则：每隔一段时间查一次新旧版本的成功率差和响应时间差，连续若干次达标才把权重推进一步，连续若干次超标就回滚。

阈值不是拍脑袋定的。先取旧版本稳定期的历史基线：成功率中位、最慢分位数中位、波动标准差。成功率门禁设在基线下方一定范围内，既不让正常波动误触发回滚，也能抓住真实退化。响应时间门禁设绝对上限而非相对百分比，因为响应时间的绝对值用户体验敏感，相对比旧版本高百分之多少在旧版本本身慢时会放过问题。

bookinfo 演示里常忽略的一点是：旧版本不调评分服务所以响应时间稳定，新版本调评分服务所以响应时间受全局影响。若把新版本的响应时间门禁设成不比旧版本差，新版本永远过不了；正确门禁是新版本最慢分位数不超过绝对上限且评分服务正常时与旧版本架构差一致。这条业务语义必须写进门禁注释里，否则后来者改阈值会踩坑。

常见误读与排障视角

开发工程师看 bookinfo 金丝雀对比时容易踩几个坑。

其一，拿总成功率比子集成功率。总成功率是旧版本和新版本按流量加权后的混合值，新版本占比小的时候总曲线几乎不动，会误以为新版本没问题。必须按子集拆开。

其二，用平均响应时间代替最慢分位数。新版本引入下游偶发慢查询时均值可能只高一点点，最慢分位数已翻倍，看均值会放过长尾恶化。

其三，忽略采样窗口对齐。左边取长时间聚合，右边取短时间聚合，两条线相位错开，看起来新版本总是慢半拍其实是聚合粒度不同。

其四，把评分服务的错算成评论服务新版本的错。排查时一定顺着调用链往下看一层，确认错误源在哪一跳。

其五，流量太小时把噪声当信号。新版本权重很小时每分钟请求数很少，一个下游超时就能让新版本成功率掉几个百分点，这时应延长观察窗或临时提升权重再判断。

结语

bookinfo 的 reviews 金丝雀对比，表面是两张曲线——成功率曲线和响应时间曲线——背后是对新版本是否等同于旧版本可靠的连续证伪。成功率管错误回归，响应时间管体验回归，两者都必须按子集拆、按同窗比、按最慢分位数看长尾、按下游耦合做交叉解读。在天翼云网格托管能力上跑这套对比，开发工程师不需要自己接埋点，但要理解 Sidecar 统计的边界：它忠实地告诉你每一跳的成败与耗时，但不会替你解释为什么——为什么是评分服务慢了、为什么新版本的响应时间天然比旧版本长、为什么低流量下的波动该忽略。把统计口径、架构差异、门禁阈值这三件事在灰度前写清楚，金丝雀就从看星星颜色猜好坏升级成看曲线偏移做决策的工程动作。