★ FEATURED ARTICLE 1. 先把通信业务这门科目拆开看它到底考什么、工作中用在哪初级通信工程师的考试里通信业务这一块是最容易被低估的部分。很多人复习的时候把它当成背诵科目觉得无非是业务分类、名词解释、几个指标翻两遍就过。真到了岗位上才发现业务知识是整个通信系统的翻译层——网络侧的一堆参数最终都要翻译成用户能不能打电话、能不能上网、一个月扣多少钱、出了问题找谁。你要是只会看设备告警不会看业务链路排查问题永远只能停在半路。通信业务这门内容的核心说白了就三件事业务怎么分类、业务怎么跑通、业务跑得好不好怎么衡量。分类解决这东西归谁管、走什么流程、占不占公共资源跑通解决从用户下单到出账中间要经过多少个系统、多少个环节衡量解决出问题时用哪个数字定位、拿什么跟用户解释。这三件事串起来就是一名初级通信工程师日常要打交道的全部底盘。这篇文章适合两类人看一类是正在备考初级通信工程师、想把业务部分从背了会忘变成理解了就忘不掉的同行另一类是刚入行做运维、客服支撑、装维、政企交付的新人手里有工单但看不懂工单背后的逻辑。我会按我自己带新人时的讲法来写尽量少用定义、多用场景能算的地方把算式摊开给你看踩过的坑也一并交代。提醒业务知识最忌讳只记结论不记边界。同一个名词在不同系统里的含义可能不一样比如开通在 CRM 里是订单状态在网管里是数据配置完成在用户眼里是能用了吗。后面我会专门列一张混淆清单。2. 业务分类把满屏的名词装进一个筐里2.1 基础业务和增值业务的划分逻辑别背条文要背逻辑刚接触分类的人最容易犯的错是拿着一张长清单硬背背完第二天就混。我的建议是先抓住一条主线这项业务是否直接占用公共网络资源、是否构成其他业务运行的底座。基础电信业务本质是修路——提供公共网络基础设施、公共数据传送、基本语音通信能力。固定电话、蜂窝移动通信、卫星通信、数据通信这些都属于这一类。增值电信业务本质是在路上跑运输或者开服务——它依托已有的网络能力往上叠加处理、存储、内容、呼叫等功能。呼叫中心、在线数据处理与交易处理、多方通信、信息服务这一类属于增值。这条主线为什么重要因为它直接决定了三件事的办理路径资费怎么报、码号怎么申请、互联互通义务怎么界定。基础业务因为占用公共资源进入门槛高、审批环节多增值业务相对灵活但一旦涉及到向用户收费、涉及到号码资源照样绕不开规范流程。我在实际工作里见过不少新人接到一个要自己做个小平台对外提供短信通知的需求第一反应是找个服务器部署完就上线完全没考虑这属于信息服务类业务、需要走相应流程最后返工。第一类增值和第二类增值的区分抓的是技术门槛和资源占用程度。第一类偏平台能力比如在线数据处理与交易处理、多方通信、呼叫中心这类业务往往要自建或租用相当的平台资源要跟基础网络做对接第二类偏内容与信息加工比如信息服务、存储转发类、编码和规程转换。考试里经常在这里出选择题给你四个业务名让你挑哪个属于第一类。我的记法是能自己搭一套系统对外提供通信处理能力的多半是第一类只是把信息加工转发给用户的多半是第二类。2.2 固定、移动、卫星、数据四类业务的边界与产品形态这四类的边界很多人背得出来但串不起来。我用一张表把它和产品形态、计费单元、关键指标对应上你会发现分类其实是为后面的计费和运维服务的。业务大类典型产品形态主要计费单元关键质量指标固定通信业务本地电话、国内长途、国际长途、IP 电话时长分钟/秒、按次接通率、串话/杂音投诉率、故障修复时长蜂窝移动通信业务语音、短信、移动数据、物联网卡时长、条数、流量MB/GB无线接通率、掉话率、上下行速率、短信成功率卫星通信业务卫星移动电话、卫星固定站、转发器出租时长、带宽×时长、按年租链路可用度、时延、雨衰余量数据通信业务互联网接入、点到点专线、MPLS 承载、IDC 托管带宽Mbps、流量、端口费时延、抖动、丢包率、可用率看这张表能发现一个规律计费单元基本跟着稀缺资源走。语音时代稀缺的是电路时长所以按时长计费数据时代稀缺的是带宽和流量所以按流量或带宽计费卫星时代稀缺的是转发器功率和频段所以按带宽租用。你把这层想通看到任何一个新业务都能大致猜出它怎么收费。固定通信业务里有个容易被忽略的点本地电话、长途、IP 电话在计费系统里是三条不同的费率链路虽然现在资费结构演进之后语音的国内长途和漫游附加费早已退出但计费系统的费率表里这些字段还留着做存量数据核对、历史账单追溯的时候一定会遇到。新人接手老系统看到一堆长途费漫游费字段先别急着删那些是历史数据的解释依据。数据通信业务这块初级岗位接触最多的是专线。专线和普通宽带最本质的区别不在速率而在服务承诺专线有可用率承诺、有故障修复时限承诺、有带宽保障不收敛或者收敛比写进合同宽带是尽力而为。你在工单里看到某客户投诉晚上网速慢如果是宽带通常解释为共享带宽高峰拥塞如果是专线那就是违约风险处理级别完全不同。2.3 编号与码号业务落地的最小抓手我特别喜欢拿号码当切入点讲业务因为号码是唯一一个既在课本里又在工单里、既能考又能摸的东西。国际通用的号码结构里一个完整号码最大长度是 15 位我国的移动用户号码是 11 位结构上可以拆成网号 HLR 标识 用户号。固定电话是区号 本地用户号区号前面加国际前缀和国家码。特服号码是短号码比如各类紧急呼叫和客服热线长度短、便于记忆但短号码的路由配置比长号码更麻烦因为它需要做号码翻译把短号翻译成真实的路由地址。号码分析的核心规则是最长匹配优先。举个实际场景系统里同时存在138这个号段路由和1381234这个更细的路由一通呼叫进来必须按更细的那条走否则就串到别的局向去了。这条规则听起来简单实际配置时出问题最多的就是路由表里有重叠前缀、优先级没设对表现为某个号段打不通或者打通了但接错地方。号码资源还是稀缺资源业务开通的第一步往往是问号码从哪来。固定电话要区号和号段移动业务要号段物联网卡有专门的号段客服热线要申请短号码。我在支撑一个政企项目时遇到过这种情况客户要求给我一批连号的号码方便对外统一宣传结果申请下来发现连号段已经分配完了最后只能用不连号的方案 号码映射做对外呈现。这类事情在课本上不会写但它是业务落地时真实存在的约束。还有一类是号码可携带也就是用户换服务方但保留原号码。技术上是靠一套集中的号码数据库加上呼叫路由查询实现的呼叫落地前先查一下这个号码当前归属哪个网络再按查询结果路由。这套机制对计费也有影响因为主叫侧的费率判定不能再单纯依赖号段得看查询结果。考试里如果考到记住关键词是集中数据库 路由查询。3. 业务流程一条业务从受理到计费出账要走多少环节3.1 受理与开通订单系统和网管系统各管一段用户看到的是我今天办了个宽带明天师傅上门背后其实是两条流水线在跑业务支撑系统管订单和账务运营支撑系统管资源和施工。这两条线的交界处是新人最容易糊涂的地方。完整链路大概是这样前台受理 → 生成订单 → 订单分解成若干服务订单 → 资源核查有没有端口、有没有号码、有没有光纤→ 派施工单 → 现场施工 → 数据配置激活 → 回单 → 通知用户 → 开始计费。这条链上任何一环卡住用户感知就是办了没反应。我给新人讲这段时一定会强调计费起始时间点和业务激活时间点必须对齐。行业里有一条通行原则业务开通后开始计费故障期间按规定减免。听起来天经地义实操中经常出错——施工完成了但回单晚了两天系统按回单时间起算用户少扣两天反过来数据配置完成了但用户实际不会用设备已经通了系统开始计费用户投诉我一天没用就扣钱。这类争议的根子都在时间戳不一致。下面这张表是我整理的常见业务开通时限参考具体数值各地各运营商口径不同这里只给量级方便你建立感觉业务类型常见开通时限量级卡单高发环节住宅宽带新装1 至 3 个工作日资源核查无空闲端口宽带移机1 至 3 个工作日跨区域派单、地址库匹配政企点到点专线5 至 15 个工作日跨地市电路协调、入楼施工许可固定电话新装1 至 3 个工作日号码资源、线路入户物联网卡批量开通当日批量处理实名信息核验、卡状态同步政企专线的开通是最能体现业务知识值钱的场景。它的流程不是简单派单而是勘查、设计、施工、测试、交付五段先看客户机房有没有位置、楼里有没有管道、两端之间怎么走再出方案定带宽、定保护方式然后施工敷缆、装设备最后打环测试、测时延丢包、出测试报告交付时还要跟客户确认维护界面和故障联系人。整个链条里最容易出问题的是两端资源不对等——一端在资源充足的城市另一端在偏远区域中间要跨多个段落协调时限会被拉长。你如果只会说系统显示在处理中客户一定不满意能说清卡在 A 段到 B 段的电路协调预计还需要 X 天这才是专业。3.2 计费链路从话单采集到出账的五个环节计费是通信业务里技术含量最高、也最容易出事故的部分。我把整条链路拆成五段你可以按这个顺序去理解任何一个计费问题。第一段采集。语音业务的话单从交换机侧产生移动数据的话单从分组域网元产生短信有短信中心的话单在线计费系统还有实时的信用控制消息。采集环节的关键指标是完整性和时延话单丢了就是漏计费话单晚了就是出账延迟。第二段预处理。原始话单格式五花八门要先做格式化、去重、补全、合法性校验。去重是因为网络侧可能重传同一通电话产生两条记录补全是因为有些字段网络侧不填比如号码归属地、费率组得靠查表补上。这一步的坑在于去重键选错把两通正常的短呼叫当成重复话单删掉用户就会投诉我明明打了电话账单里没有——虽然方向反了但同样是事故。第三段批价。按费率表把用量换算成金额这是计费的核心。批价要处理的东西特别多时段优惠、节假日优惠、亲情号、集团优惠、封顶规则、阶梯规则、免费资源抵扣。批价出错的典型表现是金额对不上而不是没有金额。第四段累账出账。把批价结果按用户归集生成账单。出账有周期月初出账是最常见的模式出账期间系统压力大经常出问题。第五段销账与结算。用户缴费后销账跨网业务还要跟对方结算。跨网结算的依据是双方的话单核对这里涉及标准化的话单交换文件拜访地网络把用户产生的用量记录打包成标准格式回传给归属地归属地完成批价和出账双方再按周期对账。国际漫游场景下这套流程最典型文件格式、字段定义、传输周期都有约定任何一个字段解析错都会导致整批结算差异。真实话单长什么样简化之后大概是这样主叫号码 被叫号码 起始时间 时长(秒) 流量(字节) 位置区 结束原因 138xxxxxxxx 010xxxxxxxx 2024-03-12 21:58:33 187 0 4600xxxx 正常释放 138xxxxxxxx 8613xxxxxxxx 2024-03-12 23:59:12 46 0 4600xxxx 正常释放第二条话单就很有意思起始时间是 23:59:12结束时间跨过了零点。这通电话该按哪个时段的费率算这就引出批价里一个必须明确的规则——是按起始时间归属还是按跨时段分段计费。不同系统、不同产品的配置可能不一样做资费核对时必须把这个规则问清楚否则你会算出一个跟系统永远差几分钱的结果然后陷进去出不来。提示做计费核对时第一件事永远是确认规则而不是重算一遍。规则没确认就动手算通常是在用错误的前提验证错误的结果。3.3 计费方式和套餐设计里的坑比公式复杂得多计费方式本身不复杂按时长、按次、按流量、包月、阶梯、封顶几种基本形态的组合。但组合起来之后坑就多了。我挑几个最常遇到的讲。按分钟进位的问题。假设某资费是 0.15 元/分钟不足一分钟按一分钟计。一通电话打了 3 分 20 秒怎么算进位到 4 分钟4 × 0.15 0.60 元。如果是按秒计费则是 200 秒 ÷ 60 × 0.15 0.50 元。同一个通话两种规则差 0.1 元单看不多乘以用户规模就是大事。这就是为什么资费规则里计费单位必须写死在系统配置里不能靠人工理解。流量阶梯封顶的问题。常见的流量套餐外规则是0.29 元/MB满 5 元可用至 1GB。这个规则怎么执行用户用了 100MB按单价算是 100 × 0.29 29 元但触发了封顶实际只收 5 元同时获得 1GB 的可用额度。用户继续用用到 1GB 之后再重新进入下一轮0.29 元/MB满 5 元可用至 1GB。这个规则的技术实现是双计数器一个记金额一个记用量两个条件互相触发。系统里如果只配了金额封顶没配用量重置就会出现扣了 5 元但额度只给了一部分的诡异现象。共享池的问题。一张主卡带几张副卡共享 20GB或者一个企业几百张物联网卡共享一个大流量池。规则要写清楚三件事共享的顺序谁先用、超出的单价池子用完后按什么价、单卡的封顶防止一张卡把整个池子耗光。我见过一个物联网项目池子用完后的单价没配结果池子一超系统按默认价批价账单金额直接翻了几倍客户拿着账单来对双方花了两周才核清楚。免费资源的抵扣顺序。用户手里可能有多种免费资源套餐内流量、赠送流量、活动流量、定向流量。抵扣顺序不同用户的实际支出就不同。通常的原则是先扣有效期短的、再扣定向的、最后扣通用的但这个顺序必须在产品配置里明确否则系统按默认顺序走跟宣传口径不一致就是投诉。退订和变更的当月处理。用户月中退订套餐当月费用退不退、按天折算还是全额收这是产品规则问题但系统实现上要区分立即生效和次月生效两种模式。做支撑的时候用户问我这个月退了为什么还扣钱你得先确认是哪种模式再解释别一上来就说系统没问题。4. 业务质量与指标怎么用数字说话4.1 常见指标的计算方式和适用场景业务知识里最能拉开差距的是能不能用一个指标定位问题。用户说网不好这是感受你回复下行速率 12Mbps、时延 38ms、丢包 0.3%这是专业。下面这张表是我常用的指标速查。指标计算方式说明什么采集位置呼叫接通率接通次数 ÷ 呼叫总次数 × 100%网络能不能把电话接起来交换机/核心网掉话率异常释放次数 ÷ 接通次数 × 100%接起来之后稳不稳无线侧统计短信发送成功率成功条数 ÷ 提交条数 × 100%短信链路是否通畅短信中心数据业务建立成功率成功建立次数 ÷ 请求次数 × 100%上网能不能连上分组域时延报文往返时间响应快不快探针/拨测抖动时延变化的离散程度语音视频卡不卡探针/拨测丢包率丢失报文数 ÷ 发送报文数 × 100%传输质量探针/拨测装移机及时率时限内完成单量 ÷ 总单量 × 100%服务履约能力订单系统故障修复及时率时限内修复数 ÷ 故障总数 × 100%维护响应能力工单系统计费差错率差错话单数 ÷ 总话单数计费准确性计费系统这里特别说一下话务量和信道数的关系因为考试喜欢考工作实际也用得上。话务量的单位是爱尔兰Erl算法是呼叫次数 × 平均通话时长 ÷ 3600。举个例子某区域有 500 个用户忙时平均每人发起 1.5 次呼叫平均通话时长 90 秒。忙时话务量 500 × 1.5 × 90 ÷ 3600 18.75 Erl。这个数字的含义是平均同时有 18.75 条通话在占用信道。接下来要按目标呼损率反推需要多少条信道。用爱尔兰公式递归计算取呼损 1%推到第 28 条信道时呼损约 1.06%推到第 29 条信道时呼损约 0.68%所以取 29 条话音信道即可满足 1% 的呼损目标。这个推导过程建议你自己动手按公式算一遍比背结论有用得多。实际工程里还要留冗余因为忙时话务量是波动的且要考虑节假日和突发事件。再补一个常考的单位换算流量的计费单位在系统内部通常按 1GB 1024MB、1MB 1024KB 换算而对外宣传口径有时用 1000 进制。这个差异在核对账单时必须先确认口径否则你算出来的数和系统差 2% 到 5%永远对不上。4.2 投诉与工单从用户感知倒推技术问题用户投诉是最真实的业务测试。我习惯把投诉分成四层来定位终端层、无线层、承载层、业务平台层。这个分层不是理论是我实际排查时用的顺序。用户说上不了网先看终端飞行模式、SIM 卡状态、APN 配置、欠费停机。再看无线信号强度、接入成功率、是否在覆盖边缘。再看承载能不能拿到地址、DNS 能不能解析、路由通不通。最后看平台认证鉴权是否通过、计费状态是否正常、内容源是否可达。这个顺序的价值在于从成本最低的检查开始避免一上来就怀疑核心网。用户说话费不对顺序反过来先看账单明细拆解再对用量话单再看资费配置最后才怀疑批价程序。绝大多数的话费不对其实是用户对套餐规则理解有偏差比如免费资源用完了没注意、定向流量只对特定应用生效、副卡共享池被主卡用光了。你要做的是把明细一条条摊开讲而不是甩一句系统没问题。工单管理上有几个指标值得盯一次解决率、重复投诉率、超时工单占比。重复投诉率是最能反映问题质量的指标——同一用户同一问题反复投诉说明第一次没解决根因。我在支撑岗位时养成的习惯是处理完工单必看这个问题会不会再发生如果会就把临时处置写进知识库让下一个人能直接复用。5. 备考与实操的复现路径5.1 六周复习节奏重点放在串而不是背我不建议把业务部分放到最后两周突击。它的知识点密度不算高但相互关联强突击只能记住碎片。我给自己和带过的新人安排过这样一个六周节奏每天 1 到 1.5 小时周次主线任务具体动作第 1 周业务分类画一张分类树每个类别写 2 个产品名和 1 个计费单元第 2 周号码与路由抄 10 个号码做结构拆分整理最长匹配的 3 个案例第 3 周开通流程按受理到激活画流程图标注每个环节的系统和单据第 4 周计费链路把五段链路各自的关键动作和典型故障写成一页纸第 5 周指标与计算手算 10 道题话务量、信道数、接通率、费用第 6 周真题复盘只做错题每道错题写一句我为什么会错这张表里最关键的是第 5 周和第 6 周。业务部分的计算题不难但单位、进位、分母口径这三处极易出错必须手算不能看答案点头。5.2 计算题的拿分模板和三个易错点我总结的答题模板是四步写公式 → 代数据 → 算结果 → 带单位写结论。少任何一步都可能被扣分尤其是单位。举个完整的例子题目某交换机覆盖区域忙时共有 800 次呼叫平均通话时长 120 秒求忙时话务量。 解话务量 A 呼叫次数 × 平均通话时长 ÷ 3600 800 × 120 ÷ 3600 26.67 Erl。 答忙时话务量约为 26.67 Erl。三个易错点记牢通话时长的单位是秒公式里的 3600 是秒不能写成 60。接通率的分母是呼叫总次数不是接通次数很多人习惯性拿接通数当分母结果算出大于 100% 的数。流量换算先统一进制题目里给的是 MB 还是 MiB用的是 1000 还是 1024一定要在第一步就写清楚。6. 常见问题速查与踩坑记录6.1 概念混淆清单考试和工作都会坑你容易混的两组概念区别在哪实际影响基础业务 / 增值业务是否直接占用公共网络资源决定办理路径和资源申请方式第一类增值 / 第二类增值是否自建平台提供通信处理能力决定技术门槛和审批要求批价 / 计费批价是单条算钱计费是整条链路说计费错了往往其实是批价错出账 / 销账出账是生成账单销账是收到钱后核销用户说我交了钱还欠费多是销账未同步呼损 / 掉话呼损是没接起来掉话是接起来后断了定位方向完全不同一个是容量一个是覆盖专线 / 宽带是否有服务承诺和带宽保障决定投诉等级和赔付风险开通 / 激活开通是流程状态激活是数据生效时间戳不一致就是计费争议源头6.2 排查思路五个高频故障的定位路径话单缺失。先确认网络侧有没有产生话单再看采集任务是否正常再看预处理有没有被误删。三步走不要跳。我遇到过最隐蔽的一次是采集正常、预处理正常最后发现是网元侧的时间同步漂移话单时间戳跑到了前一天被归到上一批次里去了。批价错误。先确认资费配置的生效时间再确认用户订购关系的生效时间最后才怀疑程序。很多批价错误其实是用户改套餐的生效时间和资费配置的生效时间对不上中间有个空档期系统按默认资费批了价。重复计费。先看是不是真的两条话单还是同一条话单在展示层被重复渲染。前者是去重键问题后者是查询逻辑问题。这个区分很重要前者要修数据后者只改展示。开通卡单。按订单状态 → 服务订单状态 → 资源核查结果 → 施工单状态逐层下钻。九成卡单在资源核查尤其是端口满、地址库匹配不上、跨区域派单权限不足这三类。号码冲突。表现为打过去是别人接的或者呼入不进来。先查号码路由表有没有重叠前缀、优先级是否最长匹配再查号码是不是被重复分配。这类问题一旦发生用户感知极差处理要快先做路由隔离再找根因。6.3 几条只有干过才知道的经验第一条任何资费规则都要落到系统能不能配。产品经理写出来的规则再漂亮系统配不了就是空话。做支撑的时候我习惯拿到规则先问一句这个封顶是金额封顶还是用量封顶两个计数器怎么联动问完通常能提前发现一半的配置风险。第二条做核对先做小样本。不要一上来就跑全量对比先挑 100 条话单人工算一遍确认规则理解一致再放大到全量。全量跑出来的差异如果规则没对齐你根本分不清是数据问题还是规则问题。第三条工单里的用户描述只能当线索不能当结论。用户说我手机没信号可能实际是欠费停机用户说网速慢可能实际是路由器太老。先看数据再下判断这是基本功。第四条把每一次异常都变成一条可复用的判断规则。我在自己的笔记里维护一份现象—原因—验证方法的对照表现在有几十条了。这份表比任何教材都好用因为每一条都是真金白银踩出来的。最后分享一个我自己一直在用的笨办法每学完一块业务就假装要给一个完全不懂通信的朋友解释清楚讲不明白的地方就是没学透的地方回去补。业务知识不是靠背出来的是靠讲出来、算出来、排查出来的。你在工单里多问一句为什么会这样比刷十套题都管用。
阅读完成 · 觉得有帮助？
