NEXT-11 503 原因调查
区分 Edge 门禁拒绝、Core HTTP 错误与外层探针超时
本轮已自然复现503，确认直接触发原因是：Edge等待Core就绪检查响应超过1秒，关闭准入门禁并向新请求返回503。 两个失败探针均未收到HTTP响应，不能表述为Core主动返回HTTP503。
用户已明确本项只确定503原因，暂停并发扩量。沿用oceanway隔离环境、128并发、120秒合成流、300秒稳态、Core共享10连接业务池、1秒探针预算；不调用UUMI或付费模型。
已确定的直接原因
历史失败响应是Edge在账务准入前返回的 503 EDGE_NOT_READY。run3/run4采到的就绪缓存为 core_billing_not_ready，说明后台Core检查失败后关闭了准入门禁；它不是上游模型返回的503，也不是每个被拒请求分别调用Core失败。
这个reason不等于Core实际返回HTTP 503。 Edge将Core探针的网络错误、外层超时、非200状态及响应契约错误折叠成同一个reason。历史日志未保留这些分支，不能从这个字符串唯一判定底层原因。
仍需区分的原因
Edge的1秒预算从连接前开始，包含TCP、TLS、代理、Core检查和响应读取；Core在收到请求后才开始自己的1秒检查。两者不是同一截止时刻。Core出现取消甚至记录成功时，Edge仍可能已超时。
失败轮观测到数据库锁等待和池争用；但成功轮也出现过19个锁等待及10个业务连接全部占用。因此这些现象是相关证据，不能单独证明根因。整池WaitCount/WaitDuration增量也不是单次探针的等待时间。
对齐首53次请求后，失败轮与成功轮客户端发起节奏基本一致，而失败轮到达合成网关执行点前出现明显延迟与成团。这将调查范围收窄至网关执行前链路，仍不能据此区分网络/TLS、鉴权或Core账务排队。
本轮验证
执行记录位于 coordination/next11-503-rootcause/。先在原共享池配置下重复观察，新增只读cgroup CPU限额计数与压力采样；再使用默认关闭的Edge诊断，记录后台探针实际HTTP状态、固定错误分类和连接/TLS/首字节时序。诊断不增加探针频率、不重试、不修改超时或业务行为，也不记录客户数据、凭据、地址和原始错误正文。
第一轮已完成424次请求、零失败及逐笔账务核对，799个Core探针事件无失败；1708份资源采样中，测试应用、PG与Redis均未出现CPU限额节流计数增量。这只说明当前成功轮的情况。
收尾时一份旧Edge日志因SCP连接中断未取回，原始控制器结果保留为失败；其余Core、PG、资源和账务证据已取得。独立核验确认测试服务、容器、凭据及目录已清理，原有业务容器未重启。该轮不能标记为完整诊断证据验收通过。没有复现的成功轮也不能写成历史故障已修复。
第二轮使用诊断Edge和相同Core共享池：128路配置、300秒稳态、424次请求全部成功，账务与归档逐笔一致、预占为零，采集和清理完成。保留827条Edge成功事件、801条Core成功事件，以及1721份资源/就绪采样，无观测到的失败或CPU限额节流增量。日志在服务尚运行时顺序复制，两个服务事件总数不要求一一相等，也不能据此任意配对。
该轮最慢Edge探针约808毫秒，约4.8毫秒已完成连接、TLS和请求发送，首字节约807.8毫秒到达，主要延迟处于请求发送之后。这是成功样本的阶段证据，不能直接当作失败归因。
最后一组将Core换回历史失败时的原始冻结制品 7a89bafe…，保持同一诊断Edge和128/300秒配置，自然复现5次503。实际仅完成约3.15秒稳态就停止新增，118条流峰值；不能称为128/300秒容量通过。133次请求中128次实际执行成功，5次为完全一致的114字节 EDGE_NOT_READY，没有上游执行ID。
两个Edge探针分别在UTC 07:20:29.531780504 和 07:20:29.567186541 开始，耗时约1000.3与1001.2毫秒，均记录 deadline_exceeded、http_status=0、CORE_UNAVAILABLE。TCP/TLS和发送完成分别只用了8.897与5.791毫秒，此后直到截止都没有首字节。故本次失败发生在请求发出后等待Core路径的响应，不是连接握手失败，也不是收到HTTP200后解析契约失败。
逐笔账务核对通过：两个合成账户各64次成功，准确扣款640/320 microcredits，预占均为0，5次拒绝没有扣费。旧Core未实现内部诊断，具体耗时落在借连接、SQL执行还是代理等待，不能由Edge时序单独拆分。PG在失败探针附近持续有17–19个锁等待，峰值包括18个账户锁等待和1个catalog锁等待；阻塞根节点在短事务间变化。它支持共享连接池/事务争用解释，但没有该探针逐次借连接或SQL阶段记录，不能把全部等待时间精确归给某一层。
703份资源采样显示应用与Redis没有CPU限额节流增量；PG全轮有一次36,484微秒的累计节流增量，发生于UTC 07:20:25.219–25.474，早于失败探针窗口。失败同窗没有观测到三组自身cgroup限额节流，不等于排除宿主机调度或IO延迟。测试服务、容器、凭据和目录全部清理，原有三个业务容器启动时间保持不变。
验收边界
本项完成了自然复现和直接触发链确认；Core内部等待的精确分解及所有历史503是否同因仍未证实。只有失败探针的Edge分类、Core阶段和同窗资源证据能相互支持时，才进一步确认底层原因。受控占池、延迟或坏响应测试只证明相应机制，不能回填为历史失败证据。调查完成度与容量验收分开记录；本项不放行2000并发或生产切换。
后续修复方向
用户已授权执行，限定修复已验收，详见探针与账务争用修复。本页保留调查时的证据和结论边界。
继续围绕就绪检查与业务数据库争用收敛：已有批量检查与专用探针池是候选措施，但批量版也曾发生过历史失败，不能宣称批量化单独解决了问题。下一次修复验收应保留双端诊断和原失败负载，验证探针延迟、实际准入/结算、全量账务与恢复行为，再决定是否扩量。本轮未改变1秒预算、失败关闭规则或计费逻辑，也未修改生产环境。