上周三凌晨两点被电话拽起来的时候，我正梦到在南京新街口排队买盐水鸭。是苏州那个做智慧园区的老周，说他们部署在十几个园区的边缘节点集体抽风，摄像头的人流统计数据全卡成了静态图，甲方的运营总监已经在业主群里骂了二十分钟。
我套上拖鞋坐在电脑前登进运维平台的时候，第一反应是专线断了。毕竟之前碰到过太多次，运营商的施工队挖断光缆，整片区的节点直接失联。结果翻了五分钟监控列表才发现，所有节点的网络链路都是通的，甚至还能正常ping通，就是上层的统计进程全僵死了。
远场节点的常见坑根本不是网络
顺着进程的日志往下查，没十分钟就找到了问题根源——三个部署在园区地下弱电间的节点，连续三周的温度监控曲线一直飘在42度以上。夏天地下弱电间没有装独立空调，物业平时只在白天上班的时候开公共通风，晚上和周末整个空间就是个密闭的烤箱。节点的风扇因为积灰早就卡停了，硬盘在高温下跑出了坏道，写不进去临时数据，整个进程直接卡死。
谁能想到。
说实话，这种坑我见了没有十次也有八次。很多团队上边缘计算项目的时候，把所有精力都放在了算法模型的部署、业务功能的跑通上，觉得只要节点能把数据算出来回传中心，就算项目交付了，根本没把远场节点的物理环境当成运维的核心部分。
边缘节点的运维优先级，首先要压在物理环境的监控上，而不是上层的应用日志。温度、湿度、磁盘健康度、电源输入稳定性，这些指标的告警优先级必须比业务进程的异常告警更高——毕竟一个跑在40度环境里的节点，迟早要出问题，等应用进程崩了再去救火，黄花菜都凉了。
别拿中心云的运维思路硬套
老周后来跟我吐槽，说之前团队的运维全是从做公有云项目转过来的，上来就把中心云的那套运维策略原封不动搬到了边缘节点上。比如每天凌晨自动拉取所有节点的全量运行日志，统一存到中心的日志平台里做分析。
我当时听到就头大。边缘节点的上行带宽很多都是按流量计费的，本来带宽就不高，拉个几十G的日志直接把上行通道占满，本来要传的业务数据全堵在路上。上次有个靠近高架的园区节点，因为施工震动触发了几万条震动传感器的重复告警，一次拉日志就耗了8个G的流量，直接把当月的流量套餐干超了，多花了两千多的超额费用。
真的，我每次看到有人把中心云的日志采集策略原封不动搬到边缘节点上，都想上去拍他的键盘。
日志采集必须做分层设计，边缘节点本地留存7天的完整运行日志，只有出现异常的时候才把关键片段回传到中心，绝对不要做全量无差别的日志回传。还有系统升级的策略也不能照搬中心云的灰度逻辑，中心云挂了有弹性容量兜底，边缘节点挂了就是真的挂了——旁边连个备用机都没有。升级窗口必须和业务节奏绑定，比如零售场景就锁死下午1点到晚上9点的客流高峰不能升级，园区场景就避开早高峰的上班时段，别为了赶版本上线，把正在跑的业务搞崩了。
真正省力气的运维从来不是靠人肉盯屏
老周之前的运维模式说出来都好笑：安排两个运维专员轮班盯着仪表盘，看到哪个节点亮红灯了，就翻通讯录找当地的物业对接人，打电话请人家开门去现场看情况。上次无锡产业园的一个节点电源松了，从告警出现到物业上门拧好插头，整整花了三天。这三天的数据全断了，甲方直接扣了他们10%的项目款，算下来小十万没了。
其实根本没必要把所有运维的事都揽在自己团队身上。边缘节点的告警要做分级分类，把温度过高、电源松动、网络接头松了这种不需要技术背景就能处理的简单告警，直接推给当地对接的物业人员，配上一步一步的图文操作指引，根本不用总部的运维大老远跑过去。现在主流的边缘节点都带远程电源控制模块，碰到系统僵死的情况，直接远程断电重启就行，连现场的人都不用等。
不过话说回来，也别把运维全交给系统就完事了。我见过最靠谱的一个做智慧交通的团队，每季度给每个路口的边缘节点拍一张现场照片，存在专门的共享文件夹里。万一哪天节点被施工队挪了位置，或者机柜里被塞了别的无关设备，翻照片一对比就能发现，比啥远程监控都管用。
上个月帮老周把所有节点的监控策略调完，他请我去苏州吃了顿藏书羊肉。
汤很鲜。
我看着他手机上跳出来的告警，是某园区节点的温度超过了35度，自动给物业发了消息提醒去开空调。没有凌晨的夺命连环call，也没有算不清的超额流量费。其实边缘计算的运维哪有那么多玄乎的概念，说白了就是把每个散在外面的小节点，当成你自己放在出租屋的旧电脑来照顾——别等开不了机了才想起来它还在那跑着你的业务。