企业官网建设流程全解析

一、先说说这场赛事为什么通信不好搞

9 月 13 日，哈尔滨银行 2026 哈尔滨马拉松鸣枪开赛。世界田联精英标牌、中国田协 A 类认证，全马半马各 1.5 万人，总共 3 万人，四枪分批发令。起点音乐公园，全马终点太阳岛太阳石广场，半马终点世纪大道市政府广场，赛道贴着松花江两岸走。

赛事本身不多说，重点说通信。这场保障拿到手，先看清楚三个硬骨头。

赛道长，地形杂。全马 42 公里多，跨松花江。沿江开阔地、高层楼群、跨江桥、隧道口，四种地形轮着来。开阔地信号好但人散，楼群里多径衰落明显，桥上江面反射导致信号飘，隧道口直接弱覆盖。传统专网要全线布基站，42 公里的工期和成本，一次性赛事扛不住；纯公网对讲，人一多基站就拥塞，稳定性说不准。

并发峰值猛，还不均匀。开赛前半小时，起点挤了近 3 万人，同一区域几百台终端同时呼叫、上报位置、触发告警，公网基站负载瞬间拉满。赛道中段人拉散了，单点并发不高，但要求 42 公里不断线。终点又聚一次，医疗、安保、裁判、后勤全在那交汇。两头高、中间长，这种流量曲线对系统弹性要求不低。

部门多，群组不能混。公安、医疗、志愿者、后勤、裁判、环卫、媒体，七个岗位。全塞一个群组里，闲聊能把紧急指令淹了。必须各聊各的，指挥中心能跨组听、能插播、能全组广播。出事的时候也不能光靠喊，得能看到人在哪、一键告警能联动。

这三条摆清楚，方案选型就有方向了。本次保障选用 LONPTT 公专融合调度方案，由黑龙江单工科技负责现场实施和值守。下面按时间线说怎么做的。

二、赛前一周：42 公里走下来，信号数据是踩出来的

通信保障的活，七成在赛前。开赛前一周，团队沿着赛道全程走了一遍，每 500 米一个采样点，拿测试终端记三大运营商的 RSRP、SINR 和下行速率。

踩完按地形分类，数据如下：

表格

楼群区和隧道口是重灾区，最终标了 7 个盲区点位。这 7 个点的处理办法很直接：公网为主，旁边架便携专网中继补盲，单台覆盖半径大概 300 米，够把盲区填上。7 台设备，半天布完。

除了信号，还得摸清人。找组委会要了保障人员清单，按岗位统计终端数量和部署位置：

表格

总共 468 台终端。这个数字是后面压测并发规模的依据。

三、方案怎么搭：一张图说清楚的事，用文字描述

系统架构不复杂，分三层。

最上层是指挥调度平台。部署在云端，双链路接入 —— 主链路用固定宽带，备用链路走 4G 网卡，主断了备自动切。平台管所有终端的注册、群组、权限、位置、告警，调度大屏实时显示终端位置热力图和在线状态。

中间层是通信链路。公网为主，终端通过运营商 4G/5G 接入平台；7 个盲区点位架便携专网中继，终端进入盲区后自动从公网切到专网中继，出了盲区再切回去，切换过程用户基本无感知。

最下层是终端。468 台手持终端，按岗位预配置群组和权限，开机即用。普通终端只能在本群组呼叫，指挥组终端能跨组监听和广播。

分组用的是 “1+N” 两级结构。1 个指挥组在顶层，7 个业务组在下层 —— 安保、医疗、巡检、后勤、裁判、环卫、媒体，巡检组再按赛段拆 3 个子组。指挥组能听任何组、能插播、能全组广播；普通组之间互不干扰。

位置上报做了分级。平时 30 秒报一次，省电、省平台负载；触发一键告警或者进了电子围栏，自动改成 2 秒一次，指挥中心能盯着人走。

一键告警的流程是这样的：终端按报警键，平台 1 秒内弹告警窗，显示谁报的、哪个组的、在哪、周边 500 米有哪些人在线。调度员直接点周边终端的名字就能呼叫，不用翻通讯录。传统电话调度从发现到调人大概一分半，这套流程压到了 15 秒左右。

四、赛前三天：压测和故障演练，数据不过关不上场

方案定了不代表能跑，得测。开赛前三天做了两轮压测加一轮故障演练。

第一轮，并发承载测试。468 台终端全上线，堆在起点 200 米 ×300 米的区域里，模拟开赛高峰。半小时内，每台终端平均每 2 分钟呼一次，每次 30 秒，位置 30 秒一报。测出来的数据：

• 468 台全部稳定在线，没掉线
• 峰值同时呼叫 37 路，系统上限 64 路，余量够
• 语音端到端时延均值 380ms，P95 是 520ms（行业一般 800ms 以内算可接受）
• 丢包率均值 0.3%，峰值 0.8%（2% 以内可接受）
• 位置上报成功率 99.7%

第二轮，盲区切换测试。7 个盲区点位挨个走一遍，测终端从公网切专网中继的表现。7 个点全成功，切换时语音断平均 1.2 秒，最长 2.1 秒，人感知是卡了一下，不是掉线。

故障演练，主链路断了怎么办。人为把指挥平台的主宽带拔了，看 4G 备用链路多久能接上。2.8 秒切完，平台恢复。当时正在进行的 3 路呼叫，1 路断了一下自动重连，另外 2 路没感觉。双链路冗余这关算过了。

测完没问题，终端统一充电、预填群组、查按键，按岗位分装。赛前一天发设备，顺便做操作培训。用设备的人大多是公安、医护、志愿者，不是搞通信的，所以培训只讲三件事：怎么开关机、怎么切群组、报警键在哪。讲多了记不住。

五、比赛当天：6 小时值守，数据和一次真实应急

5:30 到起点，最后查一遍设备和链路。6 点平台上线，终端陆续开机，7 点前 468 台全部接入。7:30 第一枪，比赛开始。

跑了 6 小时，核心数据：

• 终端在线率 99.1%，少数没电的，备用电池顶上
• 安保组呼叫量最大，全天约 1200 次；医疗组约 350 次
• 一键告警触发 7 次，全是选手身体不适，3 分钟内都完成了就近医疗调度
• 通信链路重大故障 0 次
• 盲区终端掉线 2 次，5 秒内自动重连

说一次真实的应急处置。32 公里处，一名选手身体不舒服，旁边志愿者按了一键告警。指挥中心弹窗看到位置，直接呼了 1.2 公里外的流动救护车，同时通知该赛段医疗站准备接应。从报警到救护车到现场，4 分 12 秒。选手后来没大事，但这个响应速度是平时电话调度做不到的。

值守是两个人轮班，一个盯平台看链路和在线率，一个在现场跑终端故障和换备件。整场比赛主链路没断过，备用链路没派上用场 —— 这是好事。

六、复盘：哪些做对了，哪些下次改

公专融合这个选型，对一次性赛事是划算的。全线专网布站，42 公里的成本和工期不现实；纯公网在人堆里稳定性说不准。公网为主、便携中继补盲，7 台设备半天布完，投入比全线专网低一个数量级，效果也够用。这个思路以后同类活动可以直接复用。

群组数量有个甜区。这次 7 个业务组加 1 个指挥组，468 台终端，用下来刚好。组太多（超过 10 个），指挥中心跨组调度忙不过来；组太少（五六个以内），组里语音打架。这个规模下，7+1 是比较舒服的配置。

位置上报分级是对的。平时 30 秒、告警时 2 秒，平台负载和终端续航都扛得住。如果全程 2 秒上报，平台负载翻 15 倍，终端续航少 40%，完全没必要。

下次要改的地方。一是跨江桥段的时延，P95 虽然 520ms，但偶尔飘到 700ms 以上，下次在桥上多加一台中继应该能压下来。二是终端电量，高呼叫量的岗位（安保组）有人到后半程电量紧张，下次直接给这些岗位配充电宝，别等没电了换电池。三是培训可以再精简，现场还是有人找不到报警键，以后把报警键贴个红标，比讲十分钟管用。

七、写在最后

这场保障做下来，最大的感受是：通信保障这活，做得好的时候没人注意到你，因为一切都顺；出问题的时候所有人都找你。所以核心目标就一个 —— 别出事。

从赛前 42 公里踩点，到 468 台终端压测，再到比赛当天 6 小时值守，整套流程跑通了。数据摆在这，该改的地方也列出来了。国内城市马拉松、文旅集会这类活动越来越多，临时大型活动的通信保障需求只会增不会减。公专融合这个路子，部署快、成本可控、稳定性有保障，适合这类场景。

希望这篇复盘里的实测数据和踩过的坑，对同行有用。

素材来源：新华网、央广网 2026 哈尔滨马拉松公开赛事报道；通信保障数据来自现场实施记录。