OPS / PRODUCTION HARDENING · INCIDENT · CAPACITY
本页是 reits-knowledge 431 / 432 / 433 号文档的同步副本，不是独立结论。所有数字都来自 2026-07-30 在生产机 EC2 54.206.197.2 上的实测与主动演练。事实源以 reits-knowledge 为准；本页与之不一致时，以 reits-knowledge 为准。
门户仓不保存原始结论，只保存 content/knowledge/ 下的逐字节副本与一份 INDEX.json；副本由 npm run knowledge:sync 生成。两道门禁分别守两件事：npm run knowledge:verify（内部为 --check --require-source）比对镜像与源仓的 sha256，源仓缺失即硬失败，它需要一份并排检出的 reits-knowledge，因此在开 PR 前于本地运行； npm run knowledge:selfcheck 比对镜像与 INDEX.json 自身（每份副本的 sha256 / 字节数 / 行数、有无孤儿文件、白名单是否与脚本一致），不需要源仓，因此 .gitea/workflows/ci.yml 里跑的是这一道。CI 的 job 只检出本仓，跨仓比对在那里无法成立，所以本页不声称 CI 做了跨仓比对。
ERRATA · 2026-07-31 文档审计
源文档在 2026-07-31 各自加了顶部勘误章，做法是不删原文、另起一章逐条裁决。本页照办：本节逐条写「原结论 → 裁决 → 依据」，下文正文保留 2026-07-30 的原始快照并在被推翻处挂标记，而不是静默改掉数字。凡本节与本页其余部分冲突，以本节为准。
原结论「零个 upstream 块、零 keepalive」是本轮实测发现的最重大缺陷，也是流量上来时第一个会炸的地方（临时端口与 TIME_WAIT 耗尽）。
2026-07-31 实测依据缺陷已修复。sudo nginx -T | grep -cE '^\s*upstream ' → 12；sudo nginx -T | grep -cE '^\s+keepalive [0-9]+;' → 12（12 个 upstream 各一条 keepalive 32）。修复落在 /etc/nginx/conf.d/00-upstreams.conf，该文件首行自述 added 2026-07-30 (nginx layer, batch 2)，即在 433 取数之后的同日批次。proxy_http_version 1.1 由 24 处升至 26 处。新的最近瓶颈改为 im-core-postgres-1 容器 memory.max=268435456（256MiB）而 shared_buffers=128MB 占掉一半，max_connections=100 是假保护。
原结论「零个 conf 使用 map $http_upgrade 标准写法」，据此判定边缘未就绪。
2026-07-31 实测依据实为 1 个，在 /etc/nginx/nginx.conf 第 39–42 行（default upgrade; "" "";），$connection_upgrade 全配置树 29 处引用。同批次的 434 号 §2.1 在同一天就已把它记录在案，两份同日文档自相矛盾；原因是 433 只检索了 conf.d/。取数口径已写死：凡「nginx 有没有 X」必须用 nginx -T 展开全部 include 取数。
原结论compose 里 memswap_limit == mem_limit 即代表该容器禁用 swap，且 docker inspect 可作为取证依据。
2026-07-31 实测依据两条取证准则同时被证伪。14/14 运行中容器 docker inspect -f '{{.HostConfig.MemorySwap}}' 全部等于 Memory（都声明禁 swap），而内核 /sys/fs/cgroup/system.slice/docker-<id>.scope/memory.swap.max 只有 3 个是 0（im-core-110 / im-worker / im-ws-gateway），8 个是 max（完全不限 swap：postgres、redis、info-portal-web、nodebb、grafana、nodebb-mongo、nodebb-redis、gitea），3 个是有限非零值（alloy 512MiB、loki 768MiB、docker-socket-proxy 64MiB）。11/14 不一致，因此「读 inspect 等价于读内核」也不成立。alloy 的真实天花板是 512MiB RSS + 512MiB swap = 1GiB。
原结论告警体系为零：Grafana + Loki + Alloy 在跑，但零条告警规则。
2026-07-31 实测依据实现已落地，闭环判据未全部满足，因此记「部分闭环」而非「已完成」。Grafana 已 provision 12 条规则（/etc/grafana/provisioning/alerting/rules-reits-rc5.yaml）；reits-alert-watch.timer（2 分钟）与 reits-alert-probe.timer（5 分钟）均 active；nginx / postgresql / mariadb 的 OnFailure 均已指向 reits-alert-notify@*。未满足：其中 1 条 systemd-unit-failed 规则被该文件首行注释自述为已证伪的死规则、gen_rules.py 与手工修补不同步、站外探活装在一台会休眠的本地工作站上、且「人为制造故障能收到通知」无留证。
原结论「18 个容器逐个内存封顶」仍是待办，容器无内存上限。
2026-07-31 实测依据逐容器封顶已落地：14/14 运行中容器均有非零 HostConfig.Memory。但该项自己写死的完成态是「上限之和 + 两个数据库的 MemoryLow + build.slice 硬上限不超过物理内存」：14 个上限之和 7680MiB + postgres MemoryLow 2048MiB + mariadb MemoryMin 256MiB + build.slice MemoryMax 1500MiB = 11484MiB，而物理内存 7783MiB，超配约 47%。总量约束未满足，不得记为已完成。
原结论环境基线为 17 个 docker 容器；MinIO 是事故当日的幸存者之一。
2026-07-31 实测依据docker ps -q | wc -l → 14。minio 与 nats 两个容器均已不存在，凡以它们存在为前提的记载只在事故当日成立。生效 nginx conf 数同时由 16 升至 18（ls /etc/nginx/conf.d/*.conf | wc -l）。
原结论消息总线是 NATS；MinIO 是切片 origin；把 noop publisher 换成 NATS 发布是路线图条目。
2026-07-31 实测依据im-core 仓 go.mod 无任何 NATS 依赖；internal/config/config.go:32-33 只有 RealtimeBusLocal = "local" 与 RealtimeBusRedis = "redis"，:953-955 其余取值一律 unsupported REALTIME_BUS；internal/config/config_test.go:452 把 REALTIME_BUS=nats 列为必须被拒绝的用例。outbox publisher 合法取值只有 disabled / noop / webhook / webhook-push（config.go:19-22），不存在 NATS publisher。
原结论可靠性层已补齐：这台机器已从「被杀就死、无人知晓」变成会自愈、会告警。
2026-07-31 实测依据原文未错，但只覆盖宿主进程存活，不覆盖容器内数据库的启动期正确性。docker logs im-core-postgres-1 | grep -c 'deadlock detected' → 5，全部发生在 2026-07-30（11:18:01 pid21 / 11:18:02 pid20 / 11:19:18 pid20 / 11:19:18 pid21 / 11:19:18.735 pid23），三个进程互等，两次带 at character 2210；而 show log_lock_waits 当前为 off，这类等锁事件默认不留痕。N=3 单机就足以触发，不需要多实例。归属 435 号。
原结论proxy_read_timeout 分布 = 120s×13 / 30s×4 / 300s×3 / 1h×1，共 21 处。
2026-07-31 实测依据按值计数实测为 120s×12 / 30s×4 / 300s×3 / 3600s×2，共 21 处。「四档并存、无统一口径」这一判读仍然成立，具体分布已变。
原结论WebSocket 就绪度判定为「后端就绪、边缘未就绪」。
2026-07-31 实测依据只审了边缘。服务端侧复核：im-core 全仓 WS 层 Ping / SetReadDeadline / ReadDeadline 零命中，internal/httpapi/realtime_handlers.go:63 是空 websocket.AcceptOptions{}，心跳纯被动。nginx /websock/ 的 proxy_read_timeout 3600s 与服务端零心跳叠加，半开连接最长挂 1 小时。这是服务端设计缺口，不是边缘配置债。归属 435 号。
原结论（433 未覆盖）新品牌域的边缘可观测性。
2026-07-31 实测依据map $host $reits_edge_service_name 零条 probatlas.com 表项，而 log_format reits_edge_json 用 $reits_edge_service_name 作 service_name 字段。实测已有 12 个 probatlas.com 别名可服务，但其访问日志 service_name 全部落到 default "nginx-edge"。后果：按 service_name 分服务的 Loki 查询与 Grafana 告警对新品牌域全部静默失效。
逐条列出，避免把「有勘误」读成「全文作废」。
reits-knowledge/docs/ecosystem/434-nginx-cve-2026-42533-exposure-analysis-2026-07-30.md
sha256 dbba8830f22f5a1e8eda7f7deceffca2… · 170 行 · 同步时间 2026-08-03 08:53 UTC
reits-knowledge/docs/ecosystem/435-im-core-multi-instance-foundation-landing-plan-2026-07-31.md
sha256 373ad8aefbb557abb56206b06e83a267… · 1093 行 · 同步时间 2026-08-03 08:53 UTC
A · OPS HARDENING LEDGER · 431
逐层状态。「已完成」一律附演练验收证据；拿不出演练证据的只进待办，不进已完成。
nginx 被杀后能自己起来，有 kill -9 真杀演练证据
nginx / postgres / mariadb 三个单元全部脱离 OOMScoreAdjust=0 裸奔态
slice 内申请 3G 被节流在 1046MB、oom_kill=0
postgres 只绑 127.0.0.1 导致 gitea 连不上库的根因已消除，不再依赖过渡性等待脚本
机器人集群残留移除、nginx 配置 342 → 16，全部内容已打包备份
Grafana + Loki + Alloy 在跑，但零条告警规则
6 类数据存储无统一备份口径，无 DLM 快照策略
构建已进 slice，容器仍无内存上限
在另一刀 knife/ops-config-converge 中
一句话结论：这台机器已经从「被杀就死、无人知晓」变成「被杀会自己起来、构建再也杀不死它」，但它仍然是一台「出事没人知道、坏了没备份可回」的机器。存活性（P0）已经补齐并有演练证据；可观测性与可恢复性（告警、备份、快照）仍然是零。
| 实测事实 | 它决定了什么 |
|---|---|
| cgroup v2 + PSI 均可用 | 可以用 MemoryHigh 软节流而不是只有 MemoryMax 硬杀，这是构建隔离能做到「节流 102736 次、oom_kill=0」的前提。若只有 cgroup v1，构建超限只能被硬杀。 |
| systemd 版本是 252 | RestartSteps / RestartMaxDelaySec 要 systemd 254+ 才存在，252 上写了会被解析为未知键。因此 nginx 采用固定间隔 RestartSec=5 并用 StartLimitBurst 兜住无限重启。 |
A · P0 REMEDIATIONS WITH DRILL EVIDENCE
全部为 2026-07-30 在生产机上直接执行的实测与主动演练，含 kill -9 真杀进程、cgroup 内真申请 3G 内存。不是纸面推演，也不是 --dry-run。
问题：nginx 单元原为 Restart=no。被内核 OOM killer 杀掉后永久不自愈，13 个域名全部不可达（432 号 RC-3）。
判定 主进程被 kill -9 后 8 秒内自动重启，站点恢复 200。自愈成立。
问题：OOMScoreAdjust 原为 -1000，语义是完全豁免。当内存耗尽而所有大户都被豁免时，内核找不到可杀目标，故障形态从「杀掉一个进程」退化为「整机 hang」。
判定 -900（保护但可杀）优于 -1000（完全豁免）。
问题：OOMScoreAdjust 为 0（裸奔），而同机 dockerd 官方单元自带 -500 → 内核在内存竞争时结构性地优先杀 nginx 和 mariadb（432 号 RC-4）。
判定 档位原则：恢复代价越高、影响面越广，越靠负。
问题：事故的触发动作是在生产机上直接运行前端构建（npm ci 509 个包 + vinext build），未设任何资源上限，内存被吃爆（432 号 Trigger）。
判定 事故触发路径已被封死：同样的构建动作现在只会把自己拖慢，杀不到 nginx。
问题：listen_addresses 为 'localhost,172.17.0.1'。开机时序实测 postgres 11:19:06 启动、docker 11:19:23 启动，postgres 启动时 docker0 网卡尚不存在；PostgreSQL 只要能绑上一个地址就照常启动，故只绑了 127.0.0.1，且该参数只能在启动时设定 → 永不自愈，容器内 gitea 每次重启都要人工救。
判定 listen_addresses 是「绑定哪些本机地址」，不是「允许谁连」。用 '*' 换掉枚举网卡地址，消灭的是「网卡出现晚于数据库」这一整类竞态。
直接裸跑构建等同于重放本次事故。
| 项 | 结果 | 核查与备份 |
|---|---|---|
| 机器人集群 universe 残留 | 移除 3 个 systemd 单元 + 95M 目录 | 删前核查：21 个未提交文件全部为运行时产物（pid / heartbeat / lock / .bak）与一份进度文档，无任何源码改动 |
| nginx 配置目录瘦身 | 342 → 16 个纯生效 .conf | 清除 326 个手改遗留的 .bak 类文件；nginx -t 通过。真实价值不是省磁盘，是消除「哪一份是生效的」这一歧义 |
| 备份 | cleanup-backup-20260730T113014Z | 3 个 tar.gz，位于 /home/ec2-user/ |
A · OPEN ITEMS
下列每一项都还没做。它们不是「已规划所以等于安全」——存活性已补齐，可观测性与可恢复性仍为零，本节就是那个零的明细。
现状：Grafana + Loki + Alloy 三件套都在跑，但零条告警规则
缺口：本次全站中断 10 分钟，发现方式是人工 curl。观测栈部署完毕却一条规则都没配，等于装了摄像头没接监视器
现状：全部 systemd 单元均未配置
缺口：nginx 现在会自愈了，但自愈事件本身无人知晓。若进入反复重启，除了翻 NRestarts 没有任何主动信号
现状：无
缺口：所有观测手段都在这台机器上。机器整体不可达时，观测栈跟着一起不可达——这正是最需要告警的场景
现状：无
缺口：已有 PSI 可直接做饱和度信号，433 号已给出延迟基线；数据齐了，规则是空的
现状：无统一备份口径
缺口：宿主 PostgreSQL、宿主 MariaDB 与容器侧存储共 6 类，周期 / 保留期 / 恢复演练全部未定义。本次「无数据损坏」属于运气
现状：无
缺口：256G 盘已用 67%，无自动快照。实例级故障目前无任何恢复点
现状：当前 2G
缺口：7.8G 内存 + 2G swap 对 17 容器 + 2 个数据库偏紧。构建已被 slice 限住，容器侧仍无上限
现状：容器无内存上限
缺口：构建路径已封死，但任何一个容器内存泄漏仍可复现同一场景。受害者会换成别的容器，且档位保护不等于容量保证
现状：无
缺口：已修好一个已知竞态，但没有任何机制能发现下一个同类竞态。演练必须真重启，不是 systemctl restart 单个服务
现状：在另一刀 knife/ops-config-converge
缺口：前置条件（配置目录 342 → 16）已由本刀完成
reits-knowledge/docs/ecosystem/431-production-ops-hardening-ledger-2026-07-30.md
sha256 c92fcf64439a839c91235e82d2fba7c9… · 519 行 · 同步时间 2026-08-03 08:53 UTC
B · BLAMELESS POSTMORTEM · 432
Google SRE blameless postmortem。不点名个人、不追究「谁按了回车」，只追究「为什么系统允许这个动作造成全站中断」。单一负责人：生产基础设施值班（Production Infrastructure On-call）。
Trigger 不是根因。一台承载 13 个域名的生产机，不应该存在「一条普通运维命令就能让全站中断 10 分钟」的路径。
| ID | 根因 | 类型 | 为什么它是根因 | 闭环 |
|---|---|---|---|---|
| RC-1 | 构建无隔离 | 缺失的约束 | 生产机上不存在任何资源隔离机制。因此任何重内存批处理任务——构建、数据回填、镜像构建——都能耗尽整机内存。触发动作恰好是构建，换成任何一种都会得到同样结果 | 部分闭环 |
| RC-2 | OOM killer 选中 nginx | 错误的默认档位 | 内核按 oom_score 选目标，nginx 的 OOMScoreAdjust=0 让它成为合法候选。在内核视角下，没有任何信息表明 nginx 比构建进程更重要 | 已闭环 |
| RC-3 | nginx 单元为 Restart=no，被杀后永久不自愈 | 缺失的自愈 | 这是把「毫秒级进程终止」放大成「10 分钟全站中断」的决定性一环。若配置为 Restart=always，同一次 OOM kill 的对外影响会是数秒级抖动 | 已闭环 |
| RC-4 | OOM 保护档位在同机内结构性不均衡 | 结构性缺陷 | dockerd 官方单元自带 -500，nginx 与 mariadb 为 0。内存竞争的受害者被系统性地固定为最关键的边缘入口与数据面。RC-2 说「nginx 可以被杀」，RC-4 说「nginx 会被优先杀」 | 已闭环 |
| RC-5 | 无任何告警规则 | 缺失的可观测性 | 观测栈已部署但零条规则，且无 OnFailure= 通知、无站外探活。「全站已挂」没有任何自动传播路径。这一条决定了中断时长的下界不是由技术恢复速度决定，而是由「有没有人恰好在看」决定 | 未闭环 |
| RC-6 | 宿主 PostgreSQL 只绑定 127.0.0.1，容器内 gitea 永远连不上数据库 | 恢复过程中发现的独立潜伏缺陷（非本次中断的原因） | 开机时序竞态：postgres 早于 docker 启动，docker0 网卡尚不存在，绑定失败只发 warning；listen_addresses 不可 reload → 该状态永不自愈，每次服务器重启都埋着一次「全生态代码托管不可用」 | 部分闭环 |
根因链的形状说明整改优先级：链条的形状说明了整改的优先级：RC-3 的修复收益最高（一行 Restart=always 就能把 10 分钟压到数秒），RC-1 的修复最彻底（封死整个触发类别），RC-5 未修则任何未来事故的时长仍不可控。
B · TIMELINE
时刻全部来自生产机实测（单元启动时间、进程 PID、恢复动作时刻），不是事后回忆。灰底行为窗口内事件，无独立时刻证据。
生产机开机
系统启动时间宿主 PostgreSQL 启动。docker 尚未启动，docker0 网卡不存在 → 172.17.0.1 绑定失败仅发 warning，postgres 照常 active，只绑 127.0.0.1（RC-6 成立的瞬间）
单元启动时间dockerd 启动，docker0 网卡出现。比 postgres 晚 17 秒——而 postgres 的绑定决策已在 11:19:06 冻结且不可 reload 更改
单元启动时间在生产机上直接运行前端构建（npm ci 509 个包 + vinext build），未设资源上限 → 内存逐步耗尽（Trigger）
事故动作内核 OOM killer 触发，选中 nginx（OOMScoreAdjust=0，而 dockerd 为 -500）→ nginx 进程被终止
RC-2 / RC-4nginx 单元 Restart=no → 不自愈。旧域 13 个 + 新域全部不可达。无告警触发
RC-3 / RC-5通过人工 curl 发现全站不可达（唯一的发现渠道）
RC-5人工恢复窗口：重启 nginx 恢复站点；处置 gitea → PostgreSQL 连接问题（gitea 一度 502），并由此定位到 RC-6
恢复动作时刻P0 整改逐项落地并完成演练验收（见本页第一块）
431 号第 2 章17 秒：时间线里最值得注意的一点：11:19:06 与 11:19:23 之间的 17 秒决定了 gitea 在这台机器上每次重启后能否连上数据库。这 17 秒不是异常，是这台机器的正常开机时序——缺陷在于配置假设了 docker0 已存在。
B · ACTION ITEMS
每条含单一 owner 与可度量完成态。「已完成」的完成态一律是实测值，不是「已配置」。未完成即未完成，不在此处粉饰。
| ID | 动作 | 对应根因 / 教训 | 可度量完成态 | 状态 | 锚点 |
|---|---|---|---|---|---|
| AI-01 | nginx 单元加 Restart=always / RestartSec=5 / OOMScoreAdjust=-900 / OOMPolicy=continue / MemoryAccounting=yes / MemoryMin=64M / MemoryLow=256M | RC-3、RC-2 | 实测：kill -9 后 8 秒内重启（7603 → 57189），NRestarts=1，站点 200 | 已完成 | 431 · 2.1 |
| AI-02 | 构建隔离：build.slice（MemoryHigh=1G / MemoryMax=1500M / MemorySwapMax=512M / CPUWeight=20 / IOWeight=20）与包装器 safe-build | RC-1 | 实测：memory.events 显示 high 102736、oom_kill 0，占用压在约 1046MB，17 容器正常，6 个受测域名全部 200 | 已完成 | 431 · 2.4 |
| AI-03 | 统一同机 OOM 保护档位：postgres -1000 → -900 并加 PG_OOM_ADJUST_*；mariadb 0 → -800；两者均加 Restart=on-failure / RestartSec=10 / StartLimitBurst=3 与 MemoryMin | RC-4 | 同机档位满足 nginx=-900、postgres=-900、mariadb=-800、dockerd=-500，且无任何单元为 -1000 | 已完成 | 431 · 2.2 / 2.3 |
| AI-04 | RC-6 根因修复：listen_addresses 改为 '*'；pg_hba.conf 追加 reject 兜底；移除等待 docker0 的过渡 drop-in | RC-6 | 三层同时成立：5432 公网不可达、pg_hba_file_rules 错误 0 条、gitea 容器内 172.17.0.1:5432 open | 已完成 | 431 · 2.5 |
| AI-05 | 清理故障处置阻力：nginx 配置目录 342 → 16 个纯生效 .conf；移除机器人集群残留三单元与 95M 目录 | 「做错了什么」第 7 条 | nginx -t 通过，配置目录内无 .bak 类文件；清理内容已打包备份（3 个 tar.gz） | 已完成 | 431 · 3.1 / 3.2 |
| AI-06 | 配置告警规则（黄金信号：延迟 / 流量 / 错误 / 饱和度） | RC-5 | Grafana 中告警规则数 > 0 且至少覆盖四个黄金信号各一条；人为制造一次故障能收到通知 | 待办 | 431 · TODO-01 / TODO-04 |
| AI-07 | 为关键 systemd 单元配置 OnFailure= 通知 | RC-5、「运气好」第 1 条 | nginx / postgresql / mariadb / 5 个业务单元均有 OnFailure=；故意失败能收到通知 | 待办 | 431 · TODO-02 |
| AI-08 | 建立站外黑盒探活（不在本机） | RC-5、「运气好」第 1 条 | 探活点部署在本机之外；整机断电场景下仍能告警。本条是 AI-06 无法替代的 | 待办 | 431 · TODO-03 |
| AI-09 | 定义 6 类数据存储的备份策略（周期 / 保留期 / 恢复演练） | 「运气好」第 3 条 | 6 类存储各有成文口径，且每类至少完成一次恢复演练并留存证据。仅有备份、未验证恢复的不计完成 | 待办 | 431 · TODO-05 |
| AI-10 | 配置 EBS 快照 DLM 策略 | 「运气好」第 3 条 | DLM 策略生效，能查到至少一个自动生成的快照，且 RPO 成文 | 待办 | 431 · TODO-06 |
| AI-11 | 18 个容器逐个内存封顶 | RC-1（残余面）、「运气好」第 5 条 | 18/18 容器均有内存上限；上限之和 + 两个数据库的 MemoryLow + build.slice 硬上限不超过物理内存 | 待办 | 431 · TODO-08 |
| AI-12 | swap 扩容 | RC-1（缓冲面） | swap 容量与 AI-11 的封顶方案配套成文并生效 | 待办 | 431 · TODO-07 |
| AI-13 | 建立月度重启演练（真重启整机） | RC-6、「做错了什么」第 6 条 | 每月一次真重启，重启后全部服务无需人工介入即恢复；每次留存证据。这是唯一能发现「下一个 RC-6」的机制 | 待办 | 431 · TODO-09 |
| AI-14 | nginx 配置进 git + 漂移检测 | 「做错了什么」第 7 条 | 配置在 git 中，且漂移检测能发现机上手改。前置条件（342 → 16）已由 AI-05 完成 | 进行中 | 431 · WIP-01 |
| 根因 | 已被覆盖的动作 | 是否已闭环 | 说明 |
|---|---|---|---|
| RC-1 构建无隔离 | AI-02 已完成；AI-11 / AI-12 待办 | 部分闭环 | 触发路径已封死，容器侧同类风险仍在 |
| RC-2 OOM 选中 nginx | AI-01 已完成 | 已闭环 | — |
| RC-3 nginx 不自愈 | AI-01 已完成 | 已闭环 | — |
| RC-4 档位不均衡 | AI-03 已完成 | 已闭环 | — |
| RC-5 零告警 | AI-06 / AI-07 / AI-08 全部待办 | 未闭环 | 未闭环。这是本次事故留下的最大风险：下一次事故的时长仍然由「有没有人恰好在看」决定 |
| RC-6 postgres 绑定竞态 | AI-04 已完成；AI-13 待办 | 部分闭环 | 本实例已修，同类竞态无发现机制 |
reits-knowledge/docs/ecosystem/432-full-site-outage-postmortem-2026-07-30.md
sha256 3e4626dbdccc85b1e6e980eaab3cfa7c… · 233 行 · 同步时间 2026-08-03 08:53 UTC
C · CAPACITY BASELINE · 433
本节是基线快照，不是恒定事实；引用时必须连同测量日期 2026-07-30 一起引用。并发与配置类为机上实测，延迟类为外部跨太平洋客户端实测（RTT 110–160ms（外部跨太平洋客户端，复测必须记录发起位置））。
极大富余。配置上限 4096 连接，实测 established 33 个、约 2.8 QPS → 利用率约 0.8%
不是容量，是连接复用：零个 upstream 块、零 keepalive，却有 24 处 proxy_http_version 1.1 → 每个反代请求都与后端新建 TCP 连接
首字节 1.9s 的主要成分是跨太平洋 RTT + TLS 握手，不是后端处理（developer 后端仅 0.19s、bbs 仅 0.14s）
静态资源正确（immutable 一年），公开资讯首页完全不可缓存（private, no-store）——方向恰好反了
网关容器已在跑，但 nginx 侧零个 conf 使用 map $http_upgrade 标准写法，仅 3 个 conf 硬编码 Upgrade 头
worker_connections 1024 是人为设置的低天花板（进程实际 fd limit 为 65535，worker_rlimit_nofile 未声明）
一句话结论：这台机器的资源是富余的，问题全在配置形态上。0.8% 的并发利用率意味着容量扩容在当前阶段是伪需求；真正会在流量上来时先炸的是「零 keepalive 导致的临时端口与 TIME_WAIT 消耗」和「公开首页不可缓存导致的后端放大」。
C · CONCURRENCY & CONNECTION REUSE
这两件事同时为真，所以「扩容」与「修复」不是同一件事：前者在当前基线下是伪需求，后者是流量增长时第一个会炸的地方。
| 项 | 实测值 | 测量方法 | 说明 |
|---|---|---|---|
| worker_processes | auto（→ 4） | nginx -T | 与 CPU 核数一致，正确 |
| worker_connections | 1024 | nginx -T | 人为设置的低天花板 |
| 理论总连接上限 | 4096 | 4 × 1024 | 反代场景每请求占 2 个连接，实际可服务并发约为该值一半 |
| worker_rlimit_nofile | 未声明 | nginx -T | grep | 系统层已给到 65535，配置侧没用 |
| nginx 进程 fd limit | 65535 | /proc/<pid>/limits | 1024 不是被系统逼出来的值 |
| established 连接数 | 33 | ss -tan state established | wc -l | — |
| 请求速率 | 约 2.8 QPS | 访问日志行数 ÷ 采样秒数 | — |
| load average | 约 1.0 | /proc/loadavg | 4 核机器，1.0 ≈ 25% 单核饱和度，仍有 3 倍余量 |
| 并发利用率 | 约 0.8% | 33 ÷ 4096 | 当前阶段的容量瓶颈不存在 |
proxy_http_version 1.1 的唯一实际收益就是能复用上游连接，而复用必须由 upstream 块中的 keepalive N 开启。当前是「声明了协议版本却没有开启它带来的唯一好处」。
每一个经过反代的请求都要与后端新建一次 TCP 连接，随后进入 TIME_WAIT。在 2.8 QPS 下没有任何可观察症状（这正是它长期未被发现的原因），但它随流量线性放大——临时端口约 2.8 万、TIME_WAIT 默认驻留 60 秒，粗算的端口耗尽点在数百 QPS 量级。
已被推翻433 E-1 / E-5该缺陷已在 2026-07-30 的 nginx layer batch 2 中修复。2026-07-31 实测 sudo nginx -T 得 12 个 upstream，各带一条 keepalive 32，proxy_http_version 1.1 升至 26 处。上方是 2026-07-30 取数当时的快照，「最重大缺陷」与「流量上来时第一个会炸的地方」两项判定均已不再成立。
C · WEBSOCKET READINESS
硬编码写法对该 location 下的所有请求都声明 upgrade 语义，包括普通 HTTP 请求。标准写法让 Connection 头随请求是否携带 Upgrade 而变化。当前形态下任何新增 WS 端点都需要复制一份硬编码块——这是会随端点数量线性增长的配置债。
| 参数 | 实测值 | 判读 |
|---|---|---|
| net.core.somaxconn | 4096 | 与 nginx 总连接上限同量级，当前不构成瓶颈 |
| net.ipv4.tcp_max_syn_backlog | 512 | 明显小于 somaxconn。突发建连场景下先于 somaxconn 触顶 |
| net.ipv4.ip_local_port_range | 32768-60999 | 约 2.8 万端口，这是「零 keepalive」的耗尽面 |
| net.ipv4.tcp_tw_reuse | 2 | 仅对回环之外启用 TIME_WAIT 复用，缓解但不消除端口消耗 |
| net.core.netdev_max_backlog | 1000 | 网卡收包队列，当前 2.8 QPS 下无压力 |
C · LATENCY & CACHE
外部跨太平洋客户端 curl -w 五段耗时。RTT 110–160ms（外部跨太平洋客户端，复测必须记录发起位置），RTT 是所有数字的固有底噪，必须与数字一同记录。
| 站点 | DNS | 连接（TCP） | TLS | 首字节 | 总 | 后端处理 |
|---|---|---|---|---|---|---|
| www.reits.tech | 0.003s | 0.128s | 0.889s | 1.928s | 3.324s | — |
| developer（门户） | — | — | — | — | 1.401s | 0.19s |
| bbs | — | — | — | — | 1.347s | 0.14s |
| order | — | 0.497s | — | — | 1.545s | — |
DNS 不是问题：0.003s。
TLS 是最大的单项成本：连接 0.128s → TLS 完成 0.889s，握手净耗约 0.76s，约等于 5 个 RTT。ssl_session_cache 对复用连接的客户端生效，对首次访问无效。
后端处理不是瓶颈：developer 总 1.401s 而后端仅 0.19s；bbs 总 1.347s 而后端仅 0.14s。约 86%–90% 的用户感知时延发生在网络与握手层，任何以「优化后端代码」为手段的提速收益上限只有 10%–14%。
order 的 TCP 连接 0.497s 是异常项，约为 RTT 量级的 4 倍，指向连接建立路径上的额外开销，是唯一需要单独排查的延迟异常。
www.reits.tech 首字节 1.928s 中 TLS 完成于 0.889s，故服务端首字节生成 + 传输约 1.04s；结合首页 no-store，这 1.04s 是每一次访问都要重新付出的。
| 站点 / 资源 | 实测响应头 | 判读 |
|---|---|---|
| www.reits.tech / www.probatlas.com 首页 | private, no-cache, no-store, max-age=0, must-revalidate | 公开资讯首页被声明为完全不可缓存。private + no-store 同时出现，等于禁止 CDN、禁止浏览器、禁止中间缓存 |
| bbs | 无 cache-control 头 | 交给下游启发式判断，行为不确定 |
| developer（本站） | 无 cache-control 头 | 同上，属策略缺失而非策略错误 |
| 静态资源 | public, max-age=31536000, immutable | 正确。一年 + immutable，配合内容哈希文件名是标准做法 |
判读写死：缓存策略的方向恰好反了。静态资源（可缓存性最强）配置正确；而公开资讯首页（最该被 CDN 与浏览器缓存）被打上 private, no-store。结合服务端首字节约 1.04s，这意味着每一次首页访问都完整重跑一遍服务端渲染并重传 72 KB，且 CDN 无法分担任何一部分。这是当前形态下投入产出比最高的可优化项。
C · KNOWN DEBT
每项含实测证据、影响与处置口径。第 9 章另有 14 项复测清单，逐项列出命令与本次基线值，下次容量评估可直接照此执行。
| ID | 技术债 | 实测证据 | 影响 | 处置口径 | 优先级 |
|---|---|---|---|---|---|
| DEBT-01 | 零 upstream / 零 keepalive，却有 24 处 proxy_http_version 1.1 | 433 第 2 章 | 每个反代请求新建 TCP 连接，消耗临时端口（约 2.8 万）与 TIME_WAIT 槽位；随流量线性放大 | 引入 upstream 块 + keepalive N | 最高 |
| DEBT-02 | 公开资讯首页 private, no-store 完全不可缓存 | 433 第 6.2 章 | 每次访问重跑服务端渲染 + 重传 72 KB，CDN 无法分担；同时放大 DEBT-01 | 首页应改为可公开缓存 | 高 |
| DEBT-03 | 未声明 default_server | nginx -T 无 default_server | 未匹配 Host 的请求落到首个 80 监听块（developer），行为是隐式的 | 显式声明一个 default_server（返回明确的 404/444） | 中 |
| DEBT-04 | media 子域本机无 server 块 | media.reits.tech 与 media.probatlas.com 均返回 000（TLS 握手阶段即失败） | 媒体资产走 CloudFront + us-east-1 ACM，不在本机 nginx 迁移范围 | 明确判定为不属于本机 nginx 范围，000 是预期结果 | 范围外 |
| DEBT-05 | worker_connections 1024 是人为低天花板 | worker_rlimit_nofile 未声明，进程 fd limit 实为 65535 | 当前利用率 0.8%，不构成瓶颈；但抬高时必须与 worker_rlimit_nofile、tcp_max_syn_backlog 一起调 | 低优先（无实际压力），调整时按联动口径执行 | 低 |
| DEBT-06 | tcp_max_syn_backlog=512 与 somaxconn=4096 失配 | 433 第 4 章 | 突发建连场景下半连接队列先于 somaxconn 触顶 | 与 DEBT-05 同批处理 | 低 |
| DEBT-07 | 零个 conf 使用 map $http_upgrade；proxy_read_timeout 四档并存（120s×13 / 30s×4 / 300s×3 / 1h×1） | 433 第 3 章 | 新增 WS 端点需复制硬编码块；同一 WS 客户端连不同子域断连行为不一致 | 统一为 map $http_upgrade 标准写法，并统一 WS location 的 proxy_read_timeout 口径 | 中 |
| DEBT-08 | bbs 与 developer 无 cache-control 头 | 433 第 6.2 章 | 下游启发式缓存，行为不确定 | 显式声明，与 DEBT-02 同批 | 中 |
| DEBT-09 | brotli / open_file_cache / proxy_cache 三项均未开启 | 433 第 6.1 章 | 压缩率与静态文件元数据缓存均有余量未用；proxy_cache 缺失使 DEBT-02 无法在边缘层兜底 | brotli 需换包或动态模块，成本高于另两项，评估时分开计价 | 中 |
gitea 与全生态 Go module path 锚定该域。域名过期等同于全生态依赖解析失效。它不是「旧域、迟早可以放弃」，而是物理锚点。
11 张 certbot lineage 覆盖 12 个新域名，统一到期 2026-10-28，验证方式已由 manual 改为 webroot（可自动续期）
reits-knowledge/docs/ecosystem/433-platform-capacity-baseline-2026-07-30.md
sha256 625692aee446b18e695f79fd2b040c19… · 285 行 · 同步时间 2026-08-03 08:53 UTC