江西206网络稳定性现场测试执行手册

版本：2026-08-22
执行状态：待现场确认和执行
目标：定位消费机、绑盘机、称重台到智慧餐厅服务端HTTP通信不稳定的具体故障区段

1. 最终要回答的问题

本次测试必须形成以下结论之一，不能只给出“网络不好”或“服务器正常”：

1. 故障位于餐厅设备接入段、本地交换链路、跨地区链路、服务器接入段、HTTP服务端还是数据库。
2. 问题是否只在就餐高峰出现，触发条件是吞吐、连接数、持续时间还是某个业务接口。
3. 客户端秒级等待发生在请求到达服务器前、服务端处理期间，还是响应回程阶段。
4. 更换或重启单个设备后，同负载、同脚本下指标是否可重复改善。

2. 人员分工

未经现场负责人、网络负责人和应用负责人共同确认，不进行主动负载测试。

3. 电脑、系统与放置点

3.1 标准配置

准备4台电脑：3台Linux测试电脑，1台Windows控制电脑。

最低配置为A、C两台Linux电脑加D控制电脑，但无法精确区分A到B与B到C两个区段。

3.2 每台Linux电脑要求

• 千兆或以上有线网卡，禁用Wi-Fi。
• 8 GB以上内存、20 GB以上空闲磁盘。
• 安装：openssh-server、tmux、curl、ping、mtr、iperf3、tcpdump、sysstat、ethtool。
• 现场无法联网时，提前准备与操作系统版本和CPU架构一致的离线安装包。

3.3 远程控制方式

1. 给A/B/C配置现场允许的固定测试IP或DHCP保留地址。
2. D电脑通过SSH登录三台Linux电脑。
3. 每个长任务在tmux中运行，避免远程窗口断开导致任务停止。
4. 使用scp从A/B/C收集证据到D电脑。
5. 不使用远程工具修改生产网关、路由、VLAN、ACL或服务器网卡配置。

Windows控制端示例：

ssh tester@A_IP
ssh tester@B_IP
ssh tester@C_IP
scp -r tester@A_IP:/tmp/jx206-net-* D:\jx206-net-evidence\A\

4. 执行前填写的拓扑表

没有填完本表，不开始测试。

5. 测试参数文件

在A/B/C分别建立相同的参数文件，仅填写实际地址，不写账号密码或业务请求体：

export TEST_ID=jx206-net-20260822
export SERVER_IP=192.168.0.11
export SERVER_PORT=8080
export GATEWAY_IP=待填写
export A_IP=待填写
export B_IP=待填写
export C_IP=待填写
export DEVICE_IP=待填写
export IFACE=待填写
export HEARTBEAT_PAYLOAD=/受控路径/heartbeat-test.json
export OUT=/tmp/$TEST_ID-$(hostname)-$(date +%Y%m%d-%H%M%S)
mkdir -p "$OUT"

heartbeat-test.json由应用工程师使用测试设备编号生成并受控保管，例如只包含接口必需的测试参数。不要把真实设备凭据写入本文档或公共仓库。

6. 执行顺序总览

7. 第0步：预检

7.1 三台Linux电脑执行

date; timedatectl status | sed -n '1,12p'; chronyc tracking 2>/dev/null || true
ip -br addr; ip route; ip route get "$SERVER_IP"
ethtool "$IFACE" 2>/dev/null | grep -E 'Speed|Duplex|Link detected'
ss -s

要求：

• A/B/C与服务器时间误差不超过1秒。
• 路由实际出口与拓扑记录一致。
• 网卡链路为预期速率、全双工，且Link detected: yes。
• 测试前记录交换机相关端口计数，测试后使用相同命令再次记录增量。

7.2 端口可达性

timeout 5 bash -c "</dev/tcp/$SERVER_IP/$SERVER_PORT" && echo TCP_OK || echo TCP_FAIL
curl -sS -o /dev/null --connect-timeout 3 -w 'code=%{http_code} connect=%{time_connect} start=%{time_starttransfer} total=%{time_total}\n' "http://$SERVER_IP:$SERVER_PORT/"

TCP失败时先排查路由、ACL、防火墙、监听和端口，不进入业务压测。

8. 第1步：服务端L0回环基线

在应用服务器执行，接口选择只读或测试接口：

for i in $(seq 1 100); do date '+%F %T.%3N'; curl -sS -o /dev/null --connect-timeout 2 --max-time 5 -w 'code=%{http_code} connect=%{time_connect} start=%{time_starttransfer} total=%{time_total}\n' -X POST "http://127.0.0.1:$SERVER_PORT/p/api/heartbeat" -H 'Content-Type: application/json' --data-binary @"$HEARTBEAT_PAYLOAD"; sleep 0.2; done | tee "$OUT/l0-heartbeat.log"

同步采集服务器：

sar -u -r -n DEV,EDEV,TCP,ETCP 1 600 > "$OUT/server-sar.log" &
vmstat 1 600 > "$OUT/server-vmstat.log" &
iostat -xz 1 600 > "$OUT/server-iostat.log" &
ss -s > "$OUT/server-ss-before.log"

判定：L0已经慢或失败，优先查应用、PHP-FPM、数据库和本机依赖，暂不下网络容量结论。

9. 第2步：C到服务端L1基线

在C执行：

ping -D -i 0.2 -c 300 "$SERVER_IP" | tee "$OUT/c-to-server-ping.log"
mtr -n -rwzc 300 "$SERVER_IP" | tee "$OUT/c-to-server-mtr.log"
mtr -n -T -P "$SERVER_PORT" -rwzc 300 "$SERVER_IP" | tee "$OUT/c-to-server-mtr-tcp.log"

判定：L0正常但L1异常，优先检查C本机网卡、服务器NIC、双方交换机端口及直连交换机。

10. 第3步：A/B/C分段网络测试

依次执行并保存结果：

ping -D -i 0.2 -c 600 "$GATEWAY_IP" | tee "$OUT/to-gateway-ping.log"
ping -D -i 0.2 -c 600 "$SERVER_IP" | tee "$OUT/to-server-ping.log"
mtr -n -rwzc 600 "$SERVER_IP" | tee "$OUT/to-server-mtr.log"
mtr -n -T -P "$SERVER_PORT" -rwzc 600 "$SERVER_IP" | tee "$OUT/to-server-mtr-tcp.log"

再分别测试A到B、B到C、A到C。根据结果判断：

• A到网关异常：问题已在餐厅本地接入段出现。
• A到B异常而B到C正常：问题集中在A至B之间。
• A到B正常而B到C异常：问题集中在跨地区或网络边界。
• C到服务端异常：问题集中在服务器接入段。

注意：mtr中间节点不回复ICMP不等于该节点丢包，只有后续节点和目标端也同步丢包才可作为路径证据。

11. 第4步：长时间稳定性探测

在A/B/C的tmux中同步运行30至60分钟；需要观察偶发故障时可延长到24小时：

tmux new -s jx206-net
ping -D -i 0.2 "$SERVER_IP" | tee "$OUT/long-ping-server.log"

另开窗口低频测试HTTP：

while true; do date '+%F %T.%3N'; curl -sS -o /dev/null --connect-timeout 2 --max-time 5 -w 'code=%{http_code} connect=%{time_connect} start=%{time_starttransfer} total=%{time_total}\n' -X POST "http://$SERVER_IP:$SERVER_PORT/p/api/heartbeat" -H 'Content-Type: application/json' --data-binary @"$HEARTBEAT_PAYLOAD"; sleep 5; done | tee "$OUT/long-http-heartbeat.log"

该步骤用于寻找时延尖峰、连续丢包和HTTP连接异常，不代表业务接口性能。

12. 第5步：闭餐时段iperf3吞吐测试

先确认C到服务器侧允许临时监听5201端口。若不能在服务器启动，可在C启动，A/B作为客户端。

C执行：

iperf3 -s -p 5201

A和B依次执行：

iperf3 -c "$C_IP" -p 5201 -t 120 -i 1 -P 1 | tee "$OUT/iperf-p1-forward.log"
iperf3 -c "$C_IP" -p 5201 -t 120 -i 1 -P 1 -R | tee "$OUT/iperf-p1-reverse.log"
iperf3 -c "$C_IP" -p 5201 -t 120 -i 1 -P 4 | tee "$OUT/iperf-p4-forward.log"
iperf3 -c "$C_IP" -p 5201 -t 120 -i 1 -P 4 -R | tee "$OUT/iperf-p4-reverse.log"
iperf3 -c "$C_IP" -p 5201 -u -b 10M -t 120 -i 1 | tee "$OUT/iperf-udp-10m.log"

先执行单流，再执行4流；UDP从10 Mbit/s开始，只有网络负责人确认后才提高。生产高峰禁止执行满带宽和高并发iperf3。

判定：

• 正向正常、反向异常：重点查回程路径和单向队列。
• 单流稳定、多流抖动：重点查队列、拥塞和转发能力。
• 吞吐下降同时交换机drop增加：链路或网络设备证据成立。

13. 第6步：同脚本HTTP业务测试

13.1 安全要求

• 由应用工程师准备测试人员、测试卡、测试餐盘、测试菜品和测试设备编号。
• 请求体不得写入本文档或公共仓库。
• 每个请求保留客户端开始时间、结束时间、HTTP状态、响应体中的trace_id。
• 每个接口先单请求验证，再按真实峰值RPS的1.0x、1.2x、1.5x执行。

13.2 接口顺序

1. /p/api/heartbeat
2. /api/weigh/pushWeight
3. /p/api/bindPlateInfo
4. /p/api/zhctPushMeal
5. /api/consume/orderPay，最后执行且必须使用可回滚测试账户

通用curl计时模板：

curl -sS --connect-timeout 2 --max-time 10 -o "$OUT/response-$(date +%s%N).json" -w 'code=%{http_code} connect=%{time_connect} start=%{time_starttransfer} total=%{time_total}\n' -X POST "http://$SERVER_IP:$SERVER_PORT/接口路径" -H 'Content-Type: application/json' --data-binary @/受控路径/test-payload.json

每个trace_id在服务端查找对应日志，记录：

若客户端耗时13秒、服务端runtime仅0.1秒，说明这13秒不能算作后端执行时间，应继续定位请求到达前、回包、客户端队列或重试。

14. 第7步：就餐高峰被动观察

高峰期间只运行以下低风险任务：

• A/B/C低频ping和每5秒一次heartbeat。
• 服务端sar/vmstat/iostat/ss和应用日志采集。
• 网络工程师观察交换机端口、路由器/防火墙会话、丢弃和CPU。
• 记录真实设备编号、业务动作、界面卡顿开始/恢复时间及trace_id。

不得在高峰运行大流量iperf3、固定大并发接口压测或批量真实订单。

15. 第8步：异常出现后的10分钟动作

先采证，后重启。按以下顺序执行：

1. 记录统一时间、设备编号、接口、用户动作和现象。
2. A/B/C截取故障前后ping、HTTP和路由结果。
3. 服务端保存资源、TCP重传、连接数、Nginx/PHP-FPM及应用日志。
4. 网络工程师保存相关端口和网关的CPU、会话、drop、CRC、STP、MAC move和flap计数。
5. 经批准后进行10分钟受控抓包。

抓包示例：

timeout 600 tcpdump -i any -nn -s 256 "host $DEVICE_IP and tcp port $SERVER_PORT" -w "$OUT/device-$DEVICE_IP-8080.pcap"

抓包文件可能含业务数据，按受限证据保管，不上传公共文档。

16. 第9步：单设备变更对照

证据采集完成后，只允许一次改变一个对象：

1. 保持同一测试点、同一脚本、同一负载。
2. 只重启或替换一个交换机、路由器或服务进程。
3. 重复相同测试并记录前后指标。
4. 若多个设备同时重启，结果只能说明“全链路重置后恢复”，不能归因到某一台设备。

17. 停止条件

出现以下任一情况立即停止主动测试：

• 生产接口错误率、超时或用户投诉明显增加。
• 测试链路持续超过80%利用率并影响业务。
• 交换机drop、CRC或端口flap快速增长。
• 服务器或数据库出现资源危险、锁等待或连接池耗尽。
• 产生非预期真实扣款、订单、通知或设备状态变更。
• 现场负责人或网络负责人要求停止。

停止后终止测试进程，不修改生产网络配置：

pkill -f 'iperf3 -c' || true
pkill -f 'ping -D' || true
pkill -f 'curl.*heartbeat' || true

18. 现场记录表

18.1 测试运行记录

18.2 异常记录

18.3 交换机端口前后对照

19. 最终报告模板

测试结束必须输出以下内容：

1. 已确认拓扑和实际业务路径。
2. 每个测试ID的脚本、负载、时间和证据路径。
3. L0至L4对比结果。
4. 客户端总耗时与服务端runtime对照。
5. 故障区段、证据、置信度和仍未排除的方向。
6. 单设备变更前后对照。
7. 后续整改、复测和业务验收计划。

结论示例应写为：“在测试ID X中，A到B出现2.1%丢包且交换机端口output drop增加，B到C及C到服务器正常；更换A侧上联后同负载复测无丢包。因此故障优先定位于A至B接入链路。”不能只写“网络问题”或“重启后正常”。