IT部门那些头疼的边缘计算问题，怎么破？摸着石头过河吧

“IT部门那些头疼的边缘计算问题，怎么破？摸着石头过河吧”

（根据“51CTO”网站上一篇文章的核心观点整理）

说起来，现在很多公司的IT部门都在琢磨边缘计算这事儿，感觉就像大家都听说河对岸有宝藏，但怎么过这条河，谁心里都没底，只能摸着石头慢慢试探，为啥这么难呢？因为边缘计算带来的麻烦,跟以前在数据中心里摆弄服务器完全是两码事。

第一个头疼点：设备太“散装”了，管起来像在玩“大家来找茬”

以前，服务器都乖乖待在机房，空调吹着，管理员看着，出点啥问题，走几步路就能到现场，可边缘设备呢？可能是在偏远的工厂车间里，在高速路的摄像头杆子上，甚至在茫茫大海的风力发电机里，用一位IT运维工程师的话说就是：“这些设备分布得七零八落，管理起来简直是一场噩梦。”（引自一位匿名的制造业IT经理在社区论坛的分享）你没法随时跑过去重启一下，网络信号时好时坏，设备要是死机了，可能得等上好几天维修人员才能赶到，这就像你养了一群孩子，大部分还都在外地寄宿，他们是不是饿了、病了，你都不能第一时间知道,干着急。

第二个头疼点：安全成了“打地鼠”游戏，防不胜防

数据中心的安全，好比给城堡修了高高的围墙和护城河，重点防守就行，但边缘计算把计算能力推到了最前线，等于在城堡外的每个村庄都设了一个小据点，每个据点都可能成为黑客攻击的目标，这些边缘设备往往硬件资源有限，没法安装庞大的安全软件，自身防护能力很弱，更可怕的是，攻击者只要攻破其中一个不起眼的小设备，就可能把它当作跳板，一步步摸进你的核心网络，安全团队抱怨道：“安全边界变得模糊不清，攻击面呈指数级扩大，我们每天都在疲于奔命。”（观点综合自安全专家在“FreeBuf”安全媒体上的分析）这活脱脱就是一个“打地鼠”游戏,你不知道下一个安全漏洞会从哪个角落冒出来。

第三个头疼点：数据和应用像“分开炒的菜”，怎么端上一张桌？

边缘设备会产生海量的数据，但不可能把所有数据都传回云端，那样网络会瘫痪，成本也受不了，所以就得在边缘侧先进行初步处理和分析，只把有价值的结果发回去，这就带来了数据一致性和应用协同的大问题，一个智能工厂的边缘网关，它本地判断设备运行正常，但中央云平台根据历史数据模型可能认为需要预警，听谁的？应用的一部分在边缘跑，另一部分在云端跑，就像一道菜分两个锅炒，最后怎么保证味道统一？这种复杂的协同管理,对传统的IT应用开发和部署模式提出了巨大的挑战。

这些问题到底怎么“破”呢？现实是，确实没有标准答案，大家真的都在“摸着石头过河”，从一些先行者的实践中，还是能摸到几块有用的“石头”：

第一块“石头”：用统一的“遥控器”来管理分散的设备。 既然设备管不过来，那就上一个强大的边缘管理平台，这个平台要能像个万能遥控器一样，不管设备在天南海北，都能实现远程监控、软件更新、配置下发和故障告警，哪怕设备离线了，平台也能记录状态，等它一上线就立刻执行预设的指令，这相当于给那些“在外寄宿的孩子”每人配了个智能手环,让你能随时知道他们的状况。

第二块“石头”：把安全理念从“修围墙”变成“信验证”。 面对分散的攻击点，不能再只靠边界防御了，得推行“零信任”安全架构，简单说就是“从不信任，永远验证”，每个设备、每次访问请求，不管来自内部还是外部，都必须经过严格的身份认证和权限检查，要给边缘设备本身“瘦身”，只安装最必要的软件，减少被攻击的可能，这就像给每个村庄的据点都配上严格的通行证检查站,而不是只指望外围的城墙。

第三块“石头”：设计应用时就想着“两地分居”的情况。 为了解决应用协同问题，需要在开发之初就采用“云原生”的思想来设计应用，刻意地把应用做成能灵活拆分的微服务架构，明确哪些服务必须在边缘端运行（要求低延迟的），哪些适合放在云端（需要大数据分析的），并选择合适的技术工具，来保证边缘和云之间数据同步和任务调度的顺畅，这就像是事先规划好菜谱，哪一步在哪个灶台完成，最后如何拼盘,都安排得明明白白。

边缘计算这条路肯定得走，但路上的坑也不少，对于IT部门来说，别指望能一步到位找到完美方案，最实际的做法就是：从小范围的试点项目开始，选择最迫切的业务场景，比如一个车间的质量检测或者一条生产线的预测性维护，先用小成本去试错，在实践中一块石头一块石头地摸，慢慢积累经验，总结出适合自己企业的那套打法，这个过程虽然慢，但最稳妥，毕竟，过河心急不得，摸稳了再下脚,才能避免掉进深坑里。