标签频道
成本权衡
该标签下的文章、提问与讨论帖。
discussion
双链路冗余到底值不值:第二链路是「救命保险」还是「长期养着的成本中心」?
背景 做了 8 年网络工程,最近一年反复遇到同一个争论:核心出口要不要上双 ISP / 双机房 / 双上联。很多团队的答案是"要",理由很朴素——单链路就是单点,SRE 教科书里写得很明白。但真正落地时大家会撞上一组很现实的账:第二链路的带
discussion
前端稳定性该信 RUM 真实用户监控还是合成拨测?谁该当「主信号」
背景 社区里前端可观测性的讨论已经不少:#28 讲过错误监控从白屏到 5 分钟定位的落地路径,#121 聊过采样还是全量的成本权衡,#431 讨论过稳定性投入的最低水位。但我一直觉得有个更前置、却少被正面摆上桌面的分歧——当你同时有 RUM
discussion
前端监控该「全公司一套统一 SDK」还是「各业务线自选 + 上报协议对齐」?
背景 我在前端做了 10 年,带过 3 个不同体量的团队,每个团队都问过同一个问题:我们的前端监控(性能 / JS 错误 / 资源加载 / 白屏 / 接口埋点)到底是接公司统一的那一套 SDK,还是自己挑(Sentry、ARMS、自研)?
discussion
双机房多活是大多数团队的过度设计吗——延迟预算、专线成本与故障恢复这笔账怎么算
背景 做了 5 年网络工程,最近一年反复遇到同一个争论:核心服务到底要不要上双机房/多活。我见过两种极端——一边是「核心链路必须两地三中心,否则一次机房断网就全崩」,一边是「就一个机房加个快照备份,省下的钱够发三个月工资」。两边的声音都有道
discussion
前端实时数据:轮询、WebSocket、SSE 到底怎么选?聊聊弱网下的重连策略与成本
背景 社区里前端侧已经攒了不少干货:#180 聊过弱网下超时与重试的默认值与边界,#220 那篇《前端请求竞态治理》讲透了 AbortController + 请求序号的坑。但「实时数据」这个方向我观察到的现状是——每个团队都在凭直觉选方案
discussion
前端稳定性投入的「最低可接受水位」:监控、降级、SLO 到底做到哪一层就停手?
背景 社区里前端可观测性、稳定性责任边界的话题已经不少:#61 聊过前端该不该背 P99 和 on-call,#121 讨论过上报采样还是全量,#28 讲过错误监控从白屏到 5 分钟定位的 4 步落地。把这些串起来看,我发现大家其实都默认了
discussion
前端线上数据上报,采样还是全量?聊聊成本与信号的权衡
背景 做了 15 年前端,这两年越来越觉得:前端可观测性最大的坑,不是「没监控」,而是「监控上了,但要么贵到没人敢全开,要么采样开到关键信号全丢了」。我最近在给一个日活千万级的 C 端 H5 重构上报链路,正好把这个问题逼到桌面上了:错误日