分公司 ERP 卡顿，先查网络还是服务器？
作者：微恩云
分公司查询库存转圈，总部却说服务器正常；网络测速也不低，谁该先处理？先做同一时段、同类操作的本地与远端对照，再把终端、网络和服务器日志放到同一时间轴上。 单次测速、一次 ping 或一张 CPU 截图，都不足以决定买更多带宽还是升级服务器。
这里的“本地”是靠近 ERP 应用部署位置的受控测试点，“远端”是出现问题的分公司。ERP 在云端时，应选择可行的近端对照或另一条已知路径，并注明环境差异，不强行把所有总部电脑视作本地。
第一步：把“卡”变成一个可重复的业务动作
记录发生时间、地点、用户、客户端或浏览器版本，以及究竟是登录、查询、保存、报表、附件还是打印慢。慢查询和大附件上传对网络的要求不同；只有打印卡，也可能涉及打印服务或外设路径。
选取不改变生产数据的查询，或由业务方批准的测试单据。固定筛选条件与数据范围，避免一边查一天订单、一边查全年订单。账号权限、缓存冷热、终端配置和并发负载也要记录，无法保持一致的条件应写进结论限制。
| 对照记录 | 本地或近端 | 分公司有线终端 | 分公司 Wi-Fi 终端 |
|---|---|---|---|
| 时间与任务编号 | 待填，标注时区 | 同一窗口 | 同一窗口 |
| 操作与数据范围 | 待填 | 尽量相同 | 尽量相同 |
| 客户端、账号权限与缓存 | 待填 | 待填差异 | 待填差异 |
| 每次完成耗时 | 多次记录，保留失败 | 多次记录，保留失败 | 多次记录，保留失败 |
| 错误码与请求编号 | 待填 | 待填 | 待填 |
| 同时在线人与其他任务 | 待填 | 待填 | 待填 |
这是一张排查模板，不含客户实测数据。应比较多次结果与异常时刻，不能用一次成功操作代表问题消失。
第二步：用现象决定先查哪一层
| 观察到的对照结果 | 优先排查 | 仍需核实的证据 |
|---|---|---|
| 单台电脑慢，其他同位置终端正常 | 终端资源、客户端、账号与本机网络 | 更换受控测试终端或相同操作对照 |
| 有线正常，Wi-Fi 慢或随位置变化 | 覆盖、干扰、漫游、无线终端能力 | 接入点日志、信号质量与重传，不只看信号格数 |
| 同时段本地与远端都慢 | 应用、数据库、存储或共同依赖 | 服务器资源、慢请求、锁等待和接口日志 |
| 本地正常，某分公司整体慢 | 该站点局域网、出口及广域网路径 | 网关、链路质量、流量、切换与应用请求对齐 |
| 各地同一操作慢，其他功能正常 | 对应查询、报表或第三方接口 | 数据范围、应用处理时间与依赖服务 |
| 查询慢但上行未满、丢包不明显 | 往返次数、时延敏感性或应用交互方式 | 经授权的调用链或抓包分析与业务方解释 |
这张表给出排查方向，不是自动归因规则。近端正常仍可能存在与特定用户、数据或接入方式相关的应用问题；多个地点都慢，也可能共享同一个出口或访问路径。
第三步：网络与应用记录要对应到同一次请求
网络侧记录到本地网关、业务路径和目标服务的时延、抖动、丢包或重传、接口使用率，以及路由或线路切换时刻。ICMP 可能被限速或不响应，某一跳不回 ping 不直接证明业务丢包；探测目标和真实 ERP 路径不一致时，也应说明。
服务器侧记录 CPU、内存、磁盘延迟与队列、连接数，并由应用方补充请求处理时间、数据库慢查询、锁等待和外部接口耗时。CPU 不高不代表数据库没有锁等待；网络流量不大也不代表应用不受往返时延影响。
浏览器版 ERP 可以在授权下记录连接、请求等待和返回耗时；传统客户端可能需要应用日志或受控抓包。抓包只收集排障所需范围，妥善处理账号、个人信息和业务内容。分析结果应由了解应用的人解释，不能仅凭看到多次请求就断言“单线程有问题”。
“网络正常”仍然慢，可能是多次往返在累积
有些操作需要前一步返回后才能发下一步。即使没有丢包，远端往返时间比局域网长，也可能把许多顺序交互累积成可感知等待。增加带宽不一定减少这些往返，更换路径也无法消除物理距离和应用交互设计的影响。
若考虑把客户端运行到靠近 ERP 的服务器，通过远程桌面或 RemoteApp 交付应用，需要另行评估应用厂商支持、Windows/RDS 等相关授权、服务器资源、并发、打印扫码外设、账号隔离和运维。它是应用交付方式的改变，不是对所有 ERP 都适用的提速开关，也不等于某个案例已证明你的系统可用。
什么时候值得试点网络或组网方案
如果异常与出口拥塞、丢包、路径波动或切换高度对应，并且存在可改善的替代路径，可以评估限速非关键任务、调整队列、增配线路或国内 SD-WAN 组网。先说明措施针对哪一段，避免在没有定位时同时换线路、设备和应用。
若同一查询在近端也慢，优先由 ERP 和数据库团队处理。若仅无线终端异常，优先改善现场无线。若应用顺序交互是主要限制，则组织应用与网络联合试点；网络与应用问题也可能同时存在。
| 试点记录 | 上线前 | 试点后 | 判断方法 |
|---|---|---|---|
| 同一关键操作 | 耗时分布、失败与样本数 | 相近时段/并发重新记录 | 是否达到业务方预先约定目标 |
| 网络路径 | 时延、重传、拥塞与出口 | 同口径记录 | 改变与业务收益是否对应 |
| 应用资源 | 请求处理、数据库及依赖 | 同口径记录 | 排除同期应用变化造成的误判 |
| 故障恢复 | 现有重连与回退方式 | 获准窗口测试 | 会话、未完成单据与恢复时间 |
| 剩余问题 | 已知限制 | 未解决事项与责任人 | 决定继续、调整或回退 |
试点应保留旧配置，不让“隧道已连通”替代业务验收；详细交付可参考SD-WAN 上线验收记录。涉及提交、库存与财务的超时，先查单据状态，再按应用流程决定是否重试。
向微恩云服务咨询入口提供系统位置、分公司城市、现有线路、典型慢操作和一组带时间的对照记录，可以更快判断是否值得做网络试点。先让证据指向问题层，再决定采购，能减少在错误环节反复投入。
案例：组网后仍然卡，最后查出是单线程查询
有客户总部 ERP 服务器在 A 城，厂区在 B 城，此前用过其他组网产品效果不理想。两端各部署一台设备组成 SD-WAN 网络后，客户反馈仍然卡。控制平面上抖动和丢包都在正常范围，抓包后发现问题不在线路：ERP 客户端查询数据库采用单线程，B 端发出查询、等 A 端返回后才进行下一步，往返串行叠加后表现为明显卡顿。改用 Windows RemoteApp 只发布单个应用（区别于远程桌面发布整个桌面），配合 SD-WAN 后问题解决。
这个案例说明：隧道连通、抖动丢包正常，不等于业务体验达标。判断顺序应该先用业务动作做对照，再决定是线路问题、应用架构问题还是终端问题。