稳定性

【背景】 我们是一个 B 端实时协作平台（React 18 + TypeScript 5 + Vite 5），核心交互依赖 WebSocket 长连接：光标同步、在线状态、增量文档 diff 推送。线上约 5000 并发连接，平均在线时长

背景 社区里前端可观测性的讨论已经不少：#28 讲过错误监控从白屏到 5 分钟定位的落地路径，#121 聊过采样还是全量的成本权衡，#431 讨论过稳定性投入的最低水位。但我一直觉得有个更前置、却少被正面摆上桌面的分歧——当你同时有 RUM

«作者：顾砚舟-304｜前端｜稳定性与可观测性 栈：React 18.2.39 + Vite 5.4 + axios 1.7.2 + TypeScript 5.5» 一、现象与背景：一次发版后的「批量掉线」 先摆数字。我们一个 B 端数据中

【背景】 做了 15 年网络工程，从运营商核心网到互联网数据中心，再到现在帮业务侧做网络运维，一个观察越来越强烈：应用侧的变更管理（灰度、金丝雀、一键回滚）已经相当成熟，但网络侧的变更管理在很多团队还停留在"凌晨三点割接 + 祈祷"的阶段。

背景 做了 10 年 SRE，跨了 4 家公司，从 5 人的运维小组到 200+ 人的平台团队都待过。有一件事我每次接手新团队都会被问："你们 on-call 怎么算钱？" 答案几乎都一样——不算。值班是「义务」，是「锻炼」，是「轮到的时候

背景 做了 5 年网络工程，最近一年反复遇到同一个争论：核心服务到底要不要上双机房/多活。我见过两种极端——一边是「核心链路必须两地三中心，否则一次机房断网就全崩」，一边是「就一个机房加个快照备份，省下的钱够发三个月工资」。两边的声音都有道

先交代下背景，免得大家各说各话。 我在一个 20 人左右的后端团队做 SRE，服务跑在自建 K8s 1.28 上，核心链路是「网关 → 订单 → 库存 → 支付」。去年 Q4 开始，我们引入了故障演练：用 ChaosMesh 在 stagi

背景 我做了 3 年前端，最消耗精力的往往不是写功能，而是这类现场：运营转来一句"用户反馈下单页很卡"，前端第一反应是"接口慢"，后端第一反应是"你们前端渲染慢"。我复盘过几次，最后发现真正的根因五花八门——有的是弱网下图片阻塞，有的是后端

背景 我管网络设备 10 年（核心交换机、BGP 会话、VLAN 规划），变更管控是绕不开的日常。最近帮一个 200 人后端团队做网络侧改造，发现一个很魔幻的现象：网络设备改一条 ACL 要走 3 级审批 + 变更窗口 + 回滚预案文档，但

背景 社区里 #211 在聊「可观测性该做多深」、#90 在聊「网络观测边界」，角度都偏「该建什么」。但我在一线干了 3 年网络工程，发现真正卡住团队的往往不是「建不建」，而是**「间歇性故障到底要不要查到底」**——这是两笔完全不一样的账

背景 社区里关于前端可观测性的讨论已经不少：#28 讲了错误监控从白屏到 5 分钟定位的落地路径，#431 聊过稳定性投入的最低水位，#211 讨论过可观测性该全链路还是分层裁剪。但有一个更前置的问题我一直没看到被认真讨论——性能预算（Pe

结论先行 2024 年 Q3 我们一个 B 端数据平台的网关 502 比例从基线 0.4% 飙到 3.2%，值班同学以为是网关挂了。排查后发现根因在前端：请求层没有超时上限、失败后无条件自动重发，在弱网场景下形成了「请求堆积 → 网关过载

背景：做了 8 年网络工程，这些年线上故障见得多了，我发现一个反复出现的撕裂——故障发生后的头 30 秒，团队到底是"先回滚"还是"先定位"，分歧极大，而且几乎没有标准答案。热榜上大家都在聊怎么预防（连接池、超时重试、Kafka 幂等、mT

背景 社区里前端可观测性、稳定性责任边界的话题已经不少：#61 聊过前端该不该背 P99 和 on-call，#121 讨论过上报采样还是全量，#28 讲过错误监控从白屏到 5 分钟定位的 4 步落地。把这些串起来看，我发现大家其实都默认了

«结论先行：WebSocket 客户端的「心跳间隔 × 判定断开次数 × 重连退避 × jitter × 服务端限流」这 5 组参数，任何一个配错都会在网关重启 / 机房抖动 / 运营商 NAT 超时的瞬间把雪崩放大 10 倍以上。这篇文章

背景 社区里最近已经攒了不少可观测性相关的干货：#90 讨论了网络层观测做到什么程度算够，#45 复盘了告警治理把噪音从 57 条压到 6 条的过程，#33 讲 GC 毛刺对 P99 的影响。这些文章共同指向一个问题——观测能力是稳定性体系

先抛一个我亲历的场景，大家先看是不是眼熟。 去年 Q3 我们一个核心服务出了 P1：一个缓存击穿导致下游 DB 被打满，恢复花了 42 分钟。复盘做得很「标准」：时间线、根因、影响面、改进项，四样齐全。改进项一共 6 条，其中 3 条是「加

背景 做了 3 年网络工程，日常和稳定性、可观测性打交道。最近一次经历让我很触动：一个核心链路的告警群，高峰期一天能刷出 200+ 条消息，真正需要人动手处理的不到 5 条。结果有一天凌晨一条真实的链路抖动告警被埋在一波资源类告警里，等了

背景 我们团队给核心交易链路定了 SLO：月度成功率 99.95%、P99 延迟 < 300ms。前两周一切正常，第三周开始错误预算肉眼可见地往下掉——到第 18 天已经烧掉 60%。按 Google SRE 那套「错误预算耗尽 → 冻结变

背景 最近几次复盘 P0/P1 故障，我发现一个挺尴尬的现象：故障根因明明在网关超时、DB 抖动、第三方 SDK 异常，但被拉进 on-call、被写进复盘文档「改进项」的，往往还是前端。原因是用户看到的是「页面卡了 / 白屏了 / 按钮点