边缘计算节点运维管理实操手记

凌晨三点的电话，没人喜欢接。

上周苏州工业园的项目组找过来，说园区地下车库的17个边缘节点全挂了，连着车库的车牌识别、车位引导、充电桩计费一起停了。早高峰业主堵在车库入口，保安的对讲机喊得快没电了。我赶过去的时候，运维的小哥蹲在车库门口抽烟，眼睛红得像兔子——前一天晚上他刚对着监控仪表盘核对完所有指标，CPU使用率27%，内存占用41%，磁盘剩余空间62%，一切看起来完美得像教科书。

别把边缘节点当缩小版云服务器管

很多团队刚上边缘计算的时候，都是直接把中心云的运维方案抄过来用。

觉得不就是把服务器从大机房挪到离用户近的地方吗？参数监控、告警规则、巡检流程，照搬就行。

真不是。

中心云的服务器待在恒温恒湿的机柜里，有专门的人定期打扫，供电是双路冗余，网络是万兆专线，连灰尘都进不去。边缘节点在哪？在小区的弱电井里，在高速路的监控杆机箱里，在地下车库的墙角机柜里，夏天机箱被太阳直晒，内部温度能飙到65度，雨季机箱缝里往里面渗水，飞虫能顺着散热孔钻到主板上筑巢，偶尔还有物业的保洁阿姨擦柜子的时候，不小心把电源线碰松。

这次车库里的节点为什么挂？根本不是系统崩了。是车库里的机箱通风孔被灰尘堵了，风扇转不动，CPU温度超过阈值自动触发硬件保护，整批机器直接断电了。之前的监控方案里，根本就没接机箱内部的温度传感器，光盯着CPU和内存的数值看，当然觉得一切正常。

说穿了，你用管核心机房的思路去管散在各个角落的边缘节点，从根上就错了。

真正要盯的指标根本不是你背的那套SRE手册

我见过太多团队的边缘监控大屏，列了几十项指标，从进程存活到磁盘IO，看着专业得不行，真遇到故障的时候，没有一个告警能提前预警。

边缘场景下，你得把那些在中心云里根本不算事的指标，提到最高优先级。

比如机箱内部环境温度，这个必须设两级告警，60度的时候给片区运维发个提醒，找个时间过去清下灰，检查下风扇；到70度直接触发远程脚本，把风扇转速拉满，同时给附近的运维人员派单，别等机器烧了再补救。

再比如离网时长统计。边缘节点大多靠4G/5G回传数据，信号弱的时候断个几十秒太正常了，以前大家觉得断网不算故障，等信号恢复了数据自动传上去就行。去年有个城市的路口监控边缘节点，因为运营商基站检修断了42分钟，后台没告警，交警的实时流量平台看不到路口的排队长度，早高峰直接堵了三公里，最后还是路过的市民打122报的警。

说实话，这些指标在中心云的运维体系里，根本排不上号。但放到边缘场景里，每一个都能直接影响业务能不能跑通。

别不信。之前有个做智慧校园的团队，给每个教室装了边缘节点做课堂行为分析，一开始只监控服务有没有跑，结果有个节点的机箱被学生碰开了，蟑螂爬进去把网线咬断，整整一周的课堂数据全没存上，最后被教务处追着要数据的时候，运维团队才想起来，要给机箱加个开盖告警。

别等节点挂了才想起做预案

很多团队的故障预案，写得比论文还好看。什么“节点故障时流量自动切至中心云”“就近节点承接故障流量”，真遇到事的时候，全是纸上谈兵。

就说那个就近承接的规则。我之前参与过的一个智慧社区项目，两个相邻的边缘节点装在同一个单元楼的弱电井里，上次物业检修把弱电井的电源拉了，两个节点一起断电，门禁系统直接停了，业主进出全靠保安手动开门，从早上7点堵到9点，物业经理的电话被业主打爆了。

还有那个流量切中心云的预案，真遇到片区基站故障，整个区域的移动网络全断了，你切到中心云？连不上网切个啥啊。

这时候就得靠本地兜底缓存机制。比如视频分析的节点，就算断网了，本地也得存够72小时的录像和分析结果，等网络恢复了再自动同步到中心平台，不能一断网就啥也干不了。就像上次车库的车牌识别节点，要是之前做了本地缓存，就算断网了，车牌数据也能存在节点本地，道闸照样能抬杆，业主根本不会被堵在入口。

其实哪有那么多复杂的技术啊。

边缘节点的运维，从来不是要你搞出多少领先业界的技术方案，就是得走到现场去看看——你装在楼顶的机箱有没有做防晒，你放在地下车库的机柜有没有做防水，你接的供电有没有被隔壁的装修队剪过线。

你坐在写字楼的办公室里，对着大屏上飘着的CPU曲线做推演，永远管不好这些散在城市各个角落的机器。

毕竟，这些节点不会像机房里的服务器那样，安安稳稳待在恒温的机柜里等你维护。它们天天在风吹日晒的地方替你跑业务，你多替它们操点心，它们才不会在你最忙的时候掉链子。