标签频道
CI门禁
该标签下的文章、提问与讨论帖。
背景 我们是一个 B 端 SaaS 前端（React 18 + Vite 5，约 30 个中后台页面），核心看板页线上 RUM LCP P75 基线在 1.9~2.2s（取决于用户网络），Lighthouse CI 在 CI 环境（4G 模
现象或背景 我们团队的中台产品日活 4.2 万，近期发现 INP（Interactive Perception）指标暴涨 33%，Chrome 地址栏出现红色 LCP/INP 警告。经过三周排查，发现根本原因不在业务路由，而是 vendor
【背景】 3 年测试开发，负责一条 B 端 SaaS 的订单 + 支付链路（Java 17 + Spring Boot 3.2 + MySQL 8.0.34），接口自动化 pytest 7.4 + httpx 约 900 条用例，跑在 5
现象或背景：SQL 执行计划漂移，但不是参数没调对 有一条 SQL，执行计划漂移了，导致 P99 从 15ms 飙到 3.4s，但索引没变、SQL 文本没变，连 buffer pool 命中率也没掉。这种「执行计划漂移」比绝大多数「索引没建
一、现象与背景：INP 涨了 33%，没人知道是谁干的 先摆数字。我们一个 B 端中台（React 18.2 + Vite 5 + TypeScript，约 220 个路由，12 个业务子包 monorepo），2024 年 Q3 把 We
【背景】 3 年测试开发，负责一条 B 端 SaaS 的订单 + 支付链路（Java 17 + Spring Boot 3.2 + MySQL 8.0.34），接口自动化 pytest 7.4 + httpx 约 900 条用例，跑在 5
«结论先行：发布决策只问「能不能上」，不问「回滚要多久」，等于把事故恢复时间交给了运气。 我在 8 人后端团队推行的「可逆性分级 + 回滚成本预算」机制，把 12 个月内 14 次发布事故的平均恢复时间从 38 分钟压到 9 分钟，最坏情况
背景 我做了 3 年测试开发，维护一条 B 端数据报表链路（Java 17 + Spring Boot 3.2 + MySQL 8.0），其中约 20% 的用例是异步接口："POST /report/generate" 提交后返回 202
«作者视角：10 年分布式系统工程师，专注安全加固与风险防范。 栈：Node.js 20.11 / npm 10.5.0、pnpm 8.15、Docker 24.0.7（BuildKit）、GitHub Actions、一个 3 节点 K8
背景 我们是一个 B 端 SaaS 前端（React 18 + Vite 5，约 30 个中后台页面），核心看板页线上 RUM LCP P75 基线在 1.9~2.2s（取决于用户网络），Lighthouse CI 在 CI 环境（4G 模
«站在「技术文档工程师 + 指标体系」的视角，讲一件比「选哪种事件模型」更靠前、也更便宜的事：事件名字本身没有契约。我见过太多团队花大力气选了扁平宽表还是事件溯源，结果 "add_cart / cart_add / add_to_cart"
背景 15 年测试开发，负责一条 B 端 SaaS 订单+结算链路的接口自动化仓库：Python 3.11 + pytest 7.4 + httpx，约 1200 个用例，跑在共享 staging（MySQL 8 + Redis 7）。近半
背景 5 年测试开发，负责一条 B 端 SaaS 的订单 + 支付链路（Java 17 + JUnit 5 + Testcontainers + MySQL 8.0.34）。团队约 800 个接口用例，测试数据用一套自研 Fixture 工
背景 我团队 12 个前端应用（React 18 + Vite 5），去年推了一轮"性能预算进 CI"： - LCP < 2.5s（CI 里用 Lighthouse CI 跑 headless Chrome，4G 模拟） - JS bund
一、现象与背景：全绿的套件，拦不住一次 0.01 元的差 先摆数字。我做了 5 年测试开发，现在维护一条 B 端 SaaS 核心计费链路，接口自动化是 pytest + httpx 共 1200 条用例，跑在共享 staging，CI 常年
一、现象与背景：INP 涨了 33%，没人知道是谁干的 先摆数字。我们一个 B 端中台（React 18.2 + Vite 5 + TypeScript，约 220 个路由，12 个业务子包 monorepo），2024 年 Q3 把 We
一、现象与背景：同一套压测脚本，今天 p99=42ms 明天 p99=87ms 先摆数字。我们团队 9 人，负责一条订单+库存的 Java 服务链路（JDK 17 + Spring Boot 3.1，Nginx 网关，k6 做压测）。性能回
一、现象与背景：接口"悄悄变了"，没人通知你 先给一组真实数字。我们团队 11 人，维护 5 个 Java 微服务（订单、库存、支付、营销、结算），Spring Boot 3.1 + JDK 17，网关 Nginx。2024 年 Q4 的三
背景 热榜上「性能优化第一刀怎么砍」「限流阈值怎么定」「压测数据可不可信」都被聊透了，但我最近在一个数据/后端混合团队里撞上一个更上游、也更没共识的问题：很多团队是「P99 达标就收工、劣化了再回头查」，也就是性能问题基本都在上线后才暴露、
文
标题
摘要