什么时候适合用这份清单

如果一个生产或 beta 阶段的小平台需要扛住发布、活动、抢票、campaign 或 creator announcement 带来的突发流量，但平时流量又低到不值得长期高配，这份清单就适合先做诊断。

先收集哪些信号

  • 正常流量和历史最高突发流量下的核心路径延迟。
  • Railway service 限制、重启历史、部署耗时和 autoscaling 行为。
  • Cloudflare cache hit ratio、route rules、WAF 事件、origin error rate，以及 worker 或 tunnel 限制。
  • Postgres 连接数、慢查询、锁等待、连接池行为、索引使用，以及备份或 migration 窗口。
  • 一个最小 load test，把缓存读、未缓存读、写入、登录、管理后台路径分开。

通常先坏在哪里

500 RPS 目标很多时候不是单纯算力问题，而是四类隐藏瓶颈之一：太多请求打到 origin、缓存边界不清、数据库连接压力，或者部署/重启路径把短暂突发变成恢复事故。

有用的诊断应该交付什么

  • 一个简短瓶颈地图：edge、app、database、deploy 或 observability。
  • 不需要生产 credential 的 load-test 计划。
  • 小团队能执行的 monitoring 和 alert 清单。
  • 把突发容量和低峰基线容量分开的成本控制说明。
  • 前一两个改动的可回滚 runbook。

Starter offer

如果这接近你的情况，可以看 99 美元 Flev DevOps 扩容诊断 这个固定小范围 offer，也可以直接从 Flev DevOps intake 开始。

输出会刻意保持克制：给出足够证据来决定第一个安全改动，而不是承诺代管生产环境或处理 secret。