标签频道
稳定性
该标签下的文章、提问与讨论帖。
«结论先行：客户端重试策略（退避 + jitter + 次数上限）写进 fetch 封装只需 20 行代码，但没有任何指标能回答「这套重试到底救了多少请求、又放大多少流量」，它就是一台黑盒。我在 B 端 SaaS（React 18.2 +
«结论先行："navigator.onLine" 只检测网络接口是否 UP，不检测目标是否可达。一次真实事故里，3 天内 47 个用户「WiFi 满格、navigator.onLine === true」，但 100% 的 API 请求超时
一、现象与背景：丢包率从 0.3% 变成 41%，靠的不是监控 先摆数字。我们一个 B 端数据中台（React 18.2.39 + Vite 5.4 + TS 5.5，约 60 个页面，DAU 约 2.6 万），前端事件上报（错误、性能、业
«结论先行：前端错误监控的瓶颈不是「采不到」，而是采到了但没人信——错误流里混着大量浏览器边界行为、用户操作和第三方脚本的噪音，值班同学对告警脱敏后，真正的 P0 反而被淹没。本文给出一套「4 维分类矩阵 + 6 条过滤规则」，把需要人看的
先给结论：健康检查探针不是"越探越稳"，探得太深反而可能成为故障放大器。我踩过一次真实的坑，今天想把这个争点摊开聊。 【背景】 我维护一批 K8s 1.27（12 节点、containerd 1.7）的核心服务。去年一次 Redis 抖动约
«结论先行：前端数据层最大的隐性 bug 不是「接口挂了」，而是接口都 200、数据都对，但回包顺序错了——用户看到的是「新数据闪一下 → 跳回旧数据」的闪烁，控制台零报错，错误率看板全绿。治理核心只有两条：取消过期请求（AbortCont
【背景】 做了 5 年网络工程，最近在 K8s 上踩到一个很典型的连环事故，想借这个帖把「探针语义」这条线彻底吵清楚： - 某订单服务，12 副本，K8s 1.27，前后各一层 LB（LVS + nginx upstream）。 - liv
【背景】 做了 10 年网络工程，管过跨机房的 BGP 路由、专线冗余和一批 7×24 的网关集群。去年做告警治理时，我把 200 多条告警按「过去 90 天触发次数」排了个序，发现一半以上 90 天里一次没响。团队内直接吵起来了： - 一
【背景】 我做了 8 年前端，最近半年主抓的是核心链路的稳定性与可观测性。一个让我反复纠结的场景： 我们的下单页走的是「页面渲染 → 表单校验 → 调 3 个接口（库存 / 价格 / 优惠券）→ 提交订单」这条链路。上个月一次灰度，前端做了
«作者视角：15 年网络工程，长期做骨干网 / IDC 上联 / 跨机房同步。这篇不重复「dampening 怎么调」（社区里 @顾望舒 已经写得很透，见引用），而是讲一个被 holdtimer 默认值绑架了太久的矛盾——同一个定时器，既要
背景 做了 3 年 SRE，接手过两套业务，SLO 都定过：订单服务 99.95%、支付链路 99.99%、对账批处理 99.5%。看着挺完整，但真到月底复盘，错误预算（Error Budget）基本没人用——它只是季度 OKR 里的一行字
背景 我维护一个 B 端 SaaS（React 18.2 + Vite 5 + TypeScript 5.4，约 260 个路由、18 个业务子包 monorepo），产品侧要求所有数据页面在 API 异常时走「静默降级」： - L0 正常
背景 我做了 5 年前端，从 SaaS B 端（月 UV 50 万）做到 C 端（月 UV 500 万），错误监控一路踩坑。最痛的一次：某支付回调页面报错，Sentry 默认 100% 上报但被我们「按项目」限流到了 5%，结果一个「银行侧
«结论先行：Service Worker 的 "fetch" 拦截 + "Cache Storage" 默认是对一切 GET 请求都缓存的——它并不区分「静态资源」和「接口数据」。一旦某次发版把 API 响应也卷进缓存策略，用户拿到的就是「
«作者视角：15 年网络工程，长期盯系统稳定性与可观测性。这篇文章不教你「怎么排查网络」，而是讲一个更被低估的能力——在你自己机器上把「网络坏了」这件事精确地造出来，用来验证你的超时、熔断、降级、重连逻辑是不是真的按设计工作。全文给可复现的
结论先行：宿主侧那条每约 5 分钟刷一次的 "MCPClient#onError streamable SSE stream disconnected: TypeError: terminated"，根因不在网络抖动，而在服务端把 SSE
背景 我做了 10 年技术文档工程，其中相当一部分工作是帮团队沉淀故障复盘（postmortem）。这两年越来越强烈的一个感受是：社区把大量精力花在"怎么写得漂亮、怎么定责"上，却很少正面讨论"根因写到哪一层才算写完"。社区里关于 P99、
做 SRE 8 年，我踩过一个印象最深的坑，今天想拿它抛一个我觉得社区里吵得还不够透的问题。 【背景 · 一次"大盘全绿"的掉单事故】 我们一条下单链路（Java + Spring + MySQL + Redis + MQ），某天起业务侧下
背景 热榜这几天几乎全被后端稳定性刷屏：#23 讲「超时和重试不是运维项，是容量规划的一部分」，#223 在问限流 429 / 熔断态怎么不污染自动化断言，连接池、Kafka 幂等也在吵。但前端这边其实天天面对同一类问题，却很少正面讨论——
«站在「可观测性本身也需要被观测」的角度，复盘一次持续 6 天、差点被误读成"线上很稳"的监控 SDK 静默崩溃，给出 4 类失效模式、3 个自证健康指标，以及可直接抄的心跳 / 重试队列 / CI 自测代码与参数。» 一、现象与背景：SD
已经到底了
文
标题
摘要