定义
故障排查（Fault Troubleshooting）指当设备或系统发生故障时，通过系统化方法定位故障原因、确定解决方案并实施修复的过程。故障排查是物联网运维的关键环节，通常由故障告警或事件触发上报触发，运维人员结合设备状态、日志、远程诊断等手段进行排查。与故障预测的事前预警不同，故障排查侧重事后定位与修复。
故障排查可借助远程指令（如重启、参数下发）、远程锁机、日志拉取、自检等功能，减少现场派工。跨境场景下，设备分布多国，远程排查能力尤为重要，需通过国际物联网卡实现远程连接与指令下发。
技术特点与架构
故障排查流程通常包括：故障接收——从故障告警、工单、用户反馈获取故障信息；信息收集——查询设备状态、历史数据、日志、环境信息；原因分析——按故障树、经验库、规则引擎分析可能原因；处置执行——远程重启、参数调整、固件升级或现场维修；闭环验证——确认故障消除并记录。
技术特点：支持远程与现场结合；支持知识库与案例积累；支持与监控平台、工单系统集成；支持多角色协作。跨境场景下，需考虑当地语言、时区、备件与现场支持能力。
在物联网与跨境场景中的应用
故障排查广泛应用于：充电运营——充电桩无法充电、通信异常、支付失败等问题的远程与现场排查，跨境充电网络需支持多国远程运维；工业设备——产线停机、传感器异常、通信中断的排查；物流与资产——物流追踪器离线、定位异常、电量耗尽的排查。达希物联为跨境物联网设备提供稳定连接，支持远程指令下发与状态查询，助力故障排查效率提升。
从告警到原因定位的步骤
远程信息与现场现象
故障排查的技术含义，是把“不能用了”拆成可以检验的原因，并在修复后证明现象消失。起点通常是告警、用户描述或巡检发现的偏差。收集的信息应包括最后状态、故障码、信号与注册情况、近期配置和固件版本、以及已经下发过的指令。现场现象包括指示灯、异味、机械卡滞、线缆和供电。远程看到的离线和现场看到的损坏不一定是同一层问题，要先分清是卡、天线、电源、传感器还是业务参数。
可远程处置的范围
使用条件是设备还留有一条能接收指令或至少能读出日志的路径。能远程做的通常是读取诊断、重启通信模块、修正参数、触发自检或安排升级。不能远程做的是更换损坏的接触器、天线或电池。跨境现场若没有备件和具备资质的人员，排查单应停在“已定位到需要更换的部件”，而不是反复重启指望恢复。每一步操作要记录时间和结果，方便下一个人接着做。修复验证要回到原始现象：不能充电的，要用一笔测试会话证明；不能定位的，要看到新的有效位置，而不是只看到设备重新在线。
未保留日志就恢复出厂
容易出错的是一上来恢复出厂或换卡，日志和故障码一起消失，之后无法判断是软件缺陷还是施工问题。另一类错误是只看当前在线，不看故障发生前的最后几条事件，间歇故障会在重启后暂时消失，被当成已修复。多个可能原因并行时没有排除顺序，电源、卡、服务器地址一起改，最后不知道是哪一项起了作用。远程指令超时仍显示成功，现场其实没执行。排查笔记只写在个人聊天里，系统工单没有结论，同类设备还会重复踩坑。与固件升级相关的缺陷，应先导出版本和日志，再决定是否升级，升级本身也会改变现场。
排除顺序要先留证再改动。先导出故障码、版本和最近指令，再考虑重启或换卡。一次同时更换电源、卡和服务器地址，事后无法知道哪一项真正生效。间歇故障在重启后消失，只能记成待观察，不能关闭成已修复。远程超时却显示成功时，要有现场或回读确认。跨境现场没有备件时，排查停在已定位的可更换部件，而不是反复下发重启。验证回到原始现象：不能充电就做一笔测试会话，不能定位就看到新的有效点。结论写进工单，而不是只留在个人聊天里，同类设备才不会重复排查。
关闭工单前对照原始告警码是否清除，以及清除时间是否晚于最后一次修复动作。若告警先消失、修复后发生，说明不是这次操作解决的，结论应改成自行恢复或原因未明，留给下一次同类事件继续查。