生产网络承载的是连续动作
办公网络变慢可能只影响等待时间，生产网络抖动却可能打断采集、报警或设备协同。不同任务对延迟、抖动、丢包和带宽的敏感度不同。
测速结果需要绑定具体设备和任务，否则一个漂亮数字无法说明产线是否稳定。
控制与资料传输需要分层
控制指令通常要求可预测，图像、日志和模型文件则更依赖吞吐量。把它们放在同一优先级，会让大文件传输挤压关键消息。
分层后才能为不同任务设置监测与恢复方法。
异常要保留发生顺序
设备报警、网络中断和服务恢复可能先后发生，但时间接近不代表因果已确认。日志应统一时间基准，并保存最后正常动作。
只修改一个变量后复测，才能知道调整是否真正改变结果。
远程维护必须限制权限
供应商远程支持可以缩短响应，却扩大了身份与权限范围。临时账号、明确时段和操作记录，比共享长期密码更可控。
维护结束后撤销不再需要的会话，并检查配置是否回到预期状态。
恢复目标应来自业务
关键设备可能要求分钟级恢复，非关键报表可以稍后补传。先定义任务优先级，再决定冗余与备份投资。
极客云相关内容应把连接放回工作现场，而不是用“高速”替代全部工程判断。
先画设备通信关系
控制器、传感器、边缘计算机与管理平台之间的数据方向不同。画出谁向谁发送什么，才能找到中断影响的任务。
拓扑图应标出关键依赖、替代路径与负责团队，但不必暴露生产秘密。
维护窗口包含复测
更新结束后还要测试时钟同步、告警、历史补传和代表动作，不能立即把设备交回生产。
计划若只留下安装时间，现场人员往往会在生产压力下省略验证。
无线环境随现场改变
金属设备、移动车辆、人员密度和临时隔板都会改变传播，办公室覆盖经验不能直接套进车间。
测量时记录位置、时段和设备姿态，才能比较改造前后的差异。
把方法放进真实场景
假设视觉检测系统偶尔延迟，现场应同时记录相机帧率、边缘设备负载、交换机端口、任务时间和最终产线动作。若只保存互联网测速，就无法知道瓶颈发生在采集、计算、传输或应用。代表任务必须贴近异常本身。
改动后使用相同产品、设备位置与任务节拍复测，并观察多个周期。短时间没有报警只能说明当下恢复，不能证明根因消失。若生产条件无法保持一致，应明确写出差异，让下一次记录仍有比较价值。