简介这份技术规范是中国移动通信集团公司发布的企业标准用于指导和规范综合网络资源管理系统的建设与运营适合电信行业网络资源管理、系统建设及运维人员参考。标准覆盖了系统定位与总体目标、业务需求背景、建设原则以及通用功能架构包括系统基础维护、资源存量管理、资源应用功能和资源数据共享服务等核心内容。其中基础维护涵盖资源模型管理、命名管理、数据质量管理、批量导入导出与系统管理存量管理涉及空间、物理、逻辑、业务资源及拓扑管理应用功能包括调配、分析、展现和其他类应用为网络资源的高效配置、优化调度和决策支持提供了明确的规范指引。资源包为单个doc文档大小约1.03MB内容版式清晰、目录完整便于按章节查阅。目前已有303人浏览学习适合需要系统了解中国移动网络资源管理标准体系的技术人员研读。1. 综合网络资源管理系统通用功能分册到底在规范什么这个标题看着像一份归档文档实际上它比很多源码都值得先读。综合网络资源管理系统负责把核心网、传送网、接入网、无线网等多个专业的资源统一管起来而通用功能分册刻意把专业差异拿掉只回答一个问题不管资源是哪一类的系统都应该具备哪些能力。资源建模、状态变更、拓扑呈现、数据同步、权限控制这些功能放在哪个专业都能复用所以它才叫“通用”。我见过不少团队把这个分册当成验收后入库的合订本等二期需要扩展新资源类型时才回来翻结果模型已经写死只能推翻重来。正确做法是把它当成需求源头从第一天就把每个功能点对到数据表、状态机、接口字段上。适合做系统设计的研发、写测试用例的QA、控需求范围的产品经理。分册篇幅通常不短但它隐含的抽象层很薄读的时候抓住“资源对象 状态 关联关系”三条线后面所有功能都是在这三条线上做组合。2. 从功能分册到资源模型先把“网络资源”翻译成数据结构一份通用功能分册不会像专业分册那样讲“SDH的VC4如何交叉连接”它只会写“支持资源查询、资源新增、资源变更、资源删除”。想落地就得先确定系统里的资源到底长什么样。我一般会把网络资源先切成三类再决定模型怎么建。2.1 资源对象分类物理资源、逻辑资源与业务资源把资源分为物理、逻辑、业务三层是为了避免不同专业开发各自建表最后数据对不上。物理资源是能摸到的比如机房、机架、板卡、端口、电源端子逻辑资源是在物理资源上衍生出来的比如VLAN、IP地址、伪线、隧道、SR转发实例业务资源是直接对客户交付的比如专线、宽带接入、云专线。同一个端口在物理层是一条记录在逻辑层可能绑定了多个VLAN在业务层又有对应的客户订单号。资源分类典型对象通用功能分册对应能力物理资源机房、机架、设备、板卡、端口资源入库、位置管理、生命周期变更逻辑资源VLAN、IP、MPLS隧道、路由协议资源分配、占用与释放、连通性关系业务资源专线、互联网专线、云连接业务编排、客户视图、故障定位影响分析分册里只要有“资源查询”就必须有一个能容纳这三种对象的查询入口。如果一开始只建了“物理设备表”后面加逻辑资源时就要再造一张表功能分册里的统一查询就做不到了。我通常建一张资源主表用product_type字段区分类别。CREATE TABLE resource_instance ( resource_id VARCHAR(64) PRIMARY KEY, product_type VARCHAR(16) NOT NULL COMMENT PHYSICAL / LOGICAL / BUSINESS, resource_type VARCHAR(64) NOT NULL COMMENT EQUIPMENT、PORT、VLAN、CIRCUIT 等, parent_id VARCHAR(64) COMMENT 父资源ID用于层级关系, status VARCHAR(16) NOT NULL DEFAULT PLAN, owner_system VARCHAR(32) COMMENT 来源网管或手工维护, biz_code VARCHAR(64) COMMENT 业务编码关联订单或客户, extend_attrs JSON COMMENT 扩展属性不同资源差异很大, created_time DATETIME DEFAULT CURRENT_TIMESTAMP, updated_time DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, KEY idx_resource_type (product_type, resource_type), KEY idx_parent (parent_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;这张主表有两个容易忽略的点。parent_id是层级关系的核心物理设备到机架、端口到板卡都靠它形成树extend_attrs用JSON承载各专业差异不需要为每种设备类型建字段。业务上如果要求“资源编码唯一”需要在应用层先确定编码规则数据库唯一键建议用resource_id加上owner_system组合避免多个网管系统上报时ID互相冲突。2.2 资源关系表与“资源详情”功能的支撑通用功能分册里经常出现“查一个端口要能看到它所在设备、绑定的VLAN、经过的物理路由”。这是典型的关系查询但很多系统用一张resource_instance的parent_id很难表达“端口关联VLAN”这种非父子关系。我的做法是单独建资源关系表把“连接”“绑定”“依赖”“承载”全部抽象成relation_type。CREATE TABLE resource_relation ( relation_id BIGINT PRIMARY KEY AUTO_INCREMENT, src_id VARCHAR(64) NOT NULL, dst_id VARCHAR(64) NOT NULL, relation_type VARCHAR(32) NOT NULL COMMENT PARENT / CONNECT / BIND / CARRY, effective_time DATETIME DEFAULT CURRENT_TIMESTAMP, expire_time DATETIME NULL, source_system VARCHAR(32) COMMENT 关系发现来源手工、LLDP、网管, KEY idx_src (src_id), KEY idx_dst (dst_id), KEY idx_relation (relation_type) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;这里最需要想清楚的是relation_type。PARENT表示树形父子比如机架属于机房CONNECT表示物理端口之间的跳线连接BIND表示逻辑资源绑定到物理端口CARRY表示业务路由经过某个隧道。分册里“资源详情”“资源影响分析”本质都是查这张关系表。查询一个端口影响了多少业务时先查端口绑定的VLAN再顺着VLAN查承载的隧道最后找到业务。这个链路不能靠写死SQL应该做成配置化查询后续新增资源类型时只要注册新的relation_type就行不需要改功能菜单。2.3 把功能分册的功能点映射到数据字典拿到通用功能分册后第一件事不是设计前端页面而是做“功能点—数据对象—数据项”的映射。比如分册写“支持资源的组合查询”你就要问按哪些字段查专业、区域、资源状态、维护状态、供应商。我把这组字段称为“查询字典”。在资源表里没有的字段要么加到extend_attrs要么拆成扩展表不能允许“这个需求我们页面里手动过滤”这种临时方案。功能分册描述涉及资源对象需要的数据字段系统动作按区域查询资源所有资源所属区域、纬度信息从资源主表按区域维度过滤查看资源使用情况端口、IP、VLAN状态、占用订单、更新时间关联业务表和占用记录资源影响分析端口、电路、业务关系类型、路径顺序遍历resource_relation映射完成后写一个数据字典校验SQL能很快找出“规范要求了但表里还没有”的字段。比如检查资源实例里是否出现了未注册的resource_type避免各专业自行造类型。SELECT product_type, resource_type, COUNT(*) AS cnt FROM resource_instance GROUP BY product_type, resource_type HAVING cnt 0 AND (product_type, resource_type) NOT IN ( SELECT product_type, resource_type FROM sys_resource_type_config );这个SQL的作用是发现没有登记的资源类型。resource_type是字典项必须先由模型管理员在sys_resource_type_config里注册各专业才能使用。否则维表越来越大通用查询下拉框会被塞入几十种彼此重叠的类型。参数说明product_type限定大类resource_type是细分类型HAVING子句负责把“有数据但无配置”的组合筛出来。日常可以用定时任务跑一遍输出结果进工单。3. 通用功能落到代码资源生命周期与拓扑管理怎么做分册里的“资源新增”“资源变更”“资源退网”如果只是做成页面按钮系统一定失控。核心是先把生命周期状态机定清楚再让所有操作都通过状态机校验。否则一个退网设备上的端口仍可能被分配出去功能分册验收时一条用例就会打回。3.1 状态机先于数据库逻辑生命周期状态流转我经验证综合网络资源管理系统最容易出错的就是状态字段的过渡。新资源录入后直接置为“在用”会导致后续发起退网时不知道它是否已被业务占用。通用功能分册里通常隐含了这样一条状态链计划 → 库存 → 预留 → 在用 → 退网中间还有故障、维修等扩展状态。状态编码含义允许的操作PLAN计划新建尚未物理入库修改信息、取消归档IN_STOCK已入库可用分配、预留、退网RESERVED已预留暂不分配释放为库存、分配为在用IN_USE被业务占用加故障、退网FAULT故障维修修复后回到在用RETIRED已退网不可用仅可查看不可分配这个状态机必须在后端校验不能只在前端做下拉框。我一般用Python写一个严格的转移表接口调用时先执行这个函数不通过直接报错。from enum import Enum class ResourceStatus(Enum): PLAN PLAN IN_STOCK IN_STOCK RESERVED RESERVED IN_USE IN_USE FAULT FAULT RETIRED RETIRED ALLOWED_TRANSITIONS { ResourceStatus.PLAN: {ResourceStatus.IN_STOCK, ResourceStatus.RETIRED}, ResourceStatus.IN_STOCK: {ResourceStatus.RESERVED, ResourceStatus.IN_USE, ResourceStatus.RETIRED}, ResourceStatus.RESERVED: {ResourceStatus.IN_STOCK, ResourceStatus.IN_USE}, ResourceStatus.IN_USE: {ResourceStatus.FAULT, ResourceStatus.RETIRED}, ResourceStatus.FAULT: {ResourceStatus.IN_USE, ResourceStatus.RETIRED}, ResourceStatus.RETIRED: set(), } def can_transit(current: ResourceStatus, target: ResourceStatus) - bool: return target in ALLOWED_TRANSITIONS[current]这段代码把状态转移集中到了一个字典里。can_transit接收当前状态和目标状态返回是否允许。好处是资源变更接口、分配接口、退网接口共用同一套校验逻辑不会出现“创建接口允许跳级退网接口又拦一道”的偏差。实际项目中再把current和target换成proposed_time、operator_id写入变更流水表就满足分册的审计要求了。3.2 资源导航与拓扑自动发现的数据结构支撑通用功能分册会要求“支持按专业、局向、区域逐级查看资源”这个功能最直观的实现就是递归查询。依赖关系表后用一条递归CTE就能把指定资源的所有下级资源查出来。WITH RECURSIVE resource_tree AS ( SELECT resource_id, resource_type, status, 0 AS depth FROM resource_instance WHERE resource_id RES-PORT-0001 UNION ALL SELECT c.resource_id, c.resource_type, c.status, t.depth 1 FROM resource_instance c JOIN resource_relation r ON c.resource_id r.dst_id JOIN resource_tree t ON r.src_id t.resource_id WHERE r.relation_type PARENT AND t.depth 20 ) SELECT * FROM resource_tree;这个查询先定位起点资源再沿PARENT关系向下钻取最多20层防止环路死循环。参数说明RES-PORT-0001是起点资源IDdepth是层级深度relation_typePARENT决定了只沿着树形关系走。如果分册里的“拓扑视图”还要显示端口直连关系就把relation_type条件改成CONNECT并把JOIN方向调整一下。这样一套接口就能同时支撑资源导航和拓扑展示。自动发现关系的部分我常用的方案是从网管系统采集LLDP或物理连线表解析出源端口和目的端口然后批量写入resource_relationrelation_type为CONNECT。写入前要先去重防止两边网管各自上报同一条关系产生重复记录。INSERT INTO resource_relation (src_id, dst_id, relation_type, source_system) SELECT DISTINCT src.resource_id, dst.resource_id, CONNECT, LLDP-AGENT FROM raw_lldp_link l JOIN resource_instance src ON src.external_id l.local_port_id JOIN resource_instance dst ON dst.external_id l.remote_port_id LEFT JOIN resource_relation r ON r.src_id src.resource_id AND r.dst_id dst.resource_id WHERE r.relation_id IS NULL;这段SQL的关键是LEFT JOIN后取空值只插入此前没有的关系避免每次采集都产生脏数据。字段说明external_id是各网管系统里设备的自有编码在resource_instance中必须建立唯一索引否则接不上。3.3 数据同步接口的增量与幂等设计分册对“数据同步功能”的标准描述往往是“支持多系统间资源增量同步”。这里最重要的是幂等。网管接口重试后同一批数据重复上报不能造成资源重复或状态回退。def sync_resources(source_data, db_session): changed_count 0 for item in source_data: res db_session.query(Resource).filter_by(resource_iditem[resource_id]).first() if res is None: db_session.add(Resource(**item)) changed_count 1 continue if item.get(updated_at) and res.updated_time item[updated_at]: continue for key, value in item.items(): setattr(res, key, value) changed_count 1 db_session.commit() return changed_count这段逻辑先按resource_id查出已有记录没有就直接新增有则比较时间戳如果上报数据的updated_at不新就跳过。这样即使消息队列重复投递也不会把旧数据覆盖新数据。注意参数source_data每条都要包含resource_id、updated_at和业务字段db_session可以是SQLAlchemy的会话对象。生产环境需要在resource_id上加唯一索引并且源系统要保证同一条资源上报到同一个分区。同步方式触发时机适合场景失败处理全量同步每日凌晨资源总量少允许短时偏差失败重跑全量重建索引增量同步变更后实时资源量大需要准实时幂等合并失败进入重试队列定时对账每30分钟校验两系统间差异输出差异报告人工仲裁实际项目里三种方式会同时存在。全量用来保证基线增量用来保证时效对账用来发现漏采和错采。分册中的“一致性”功能要求你可以在对账任务里对相同resource_id的资源比较状态、所属区域、设备型号这三个关键字段只把差异行输出。4. 按功能分册做验收覆盖度分析与自动化测试分册写得很全但开发完成后怎么证明“我做了”不能靠一个截图。需要把功能分册的每一条描述拆成功能点再用接口测试去验证。拆解的过程本身也会暴露需求理解不一致的问题。4.1 建立功能追溯矩阵先回答“做没做”追溯矩阵是测试和验收的基本盘。纵向是分册中的功能点横向是系统模块、接口地址、测试用例、状态。梳理时我习惯用表格但正式交付时会落到项目管理系统的字段里。分册描述功能点ID系统模块接口用例状态资源新增支持校验编码唯一F-1001资源维护POST /api/resourcesTC-1001已通过资源状态支持预留与释放F-1002生命周期PUT /api/resources/{id}/statusTC-1002已通过资源查询支持组合条件F-1003资源查询GET /api/resourcesTC-1003已通过如果功能点ID和分册章节号对不上后期追查会很痛苦。比如F-1001就是分册第二章第三节第一条这样线上出了bug能直接定位到规范条目。建议代码提交信息里也带上功能点ID例如“feat: F-1001 resource create unique validation”这样评审时可以直接看到需求来源。4.2 用 pytest 把关键功能固化成接口测试手动验收只能证明测试当天可用接口测试才能防止回归。我通常挑状态机、资源查询、生命周期三个最核心的能力写pytest用例。下面是一个创建资源的用例。import pytest import requests BASE_URL http://127.0.0.1:8000 def test_create_resource_should_return_plan(): payload { product_type: LOGICAL, resource_type: VLAN, parent_id: None, extend_attrs: {vlan_id: 100} } response requests.post(f{BASE_URL}/api/resources, jsonpayload) assert response.status_code 201 body response.json() assert body[status] PLAN detail requests.get(f{BASE_URL}/api/resources/{body[resource_id]}) assert detail.json()[resource_type] VLAN这个用例有两个断言。第一是创建接口返回201并且新资源的状态是PLAN不是直接用。第二是查询详情能查到刚才创建的资源。如果分册里写了“新资源应处于计划状态”这个用例就能拦住“开发直接置为在用”的简化实现。参数说明product_type和resource_type必传extend_attrs里的vlan_id是业务扩展项。实际工程中还需要在teardown里调用删除接口或使用数据库事务回滚避免用例之间相互影响。状态流转的测试更值得写。比如退网接口只能接受IN_USE或FAULT状态的资源如果传PLAN状态应该返回400。这类用例能保护状态机的约束不被后续改动破坏。4.3 性能压测的参数与判断阈值通用功能分册不会给出性能数字但实际验收时业务方会问“同时多少人用会不会卡”。我一般把资源查询接口的响应时间作为核心观测对象。压测工具用JMeter命令行执行方便集成到流水线。jmeter -n -t resource_query.jmx -l result.jtl -e -o report/ \ -Jthreads50 -Jrampup10 -Jduration300参数说明-Jthreads50表示50个并发用户-Jrampup10表示10秒内陆续启动-Jduration300表示持续压测300秒。-n表示非GUI模式-e和-o是生成HTML报告。resource_query.jmx里需要预先定义一个HTTP请求路径是GET /api/resources并添加随机查询参数避免命中缓存导致结果失真。接口压测场景目标值GET /api/resources?typePORT在线人员查询TP95 1秒POST /api/resources批量录入TP95 2秒PUT /api/resources/{id}/status状态变更TP95 1秒如果TP95超过目标值先看SQL执行计划再看是否缺少索引。资源查询最常慢在parent_id和relation_type上没有索引检查resource_instance的idx_parent和resource_relation的idx_relation是否被使用。5. 把通用功能分册变成版本计划的三个技巧第一个技巧是拆用户故事不要按页面拆按“资源对象 状态 动作”拆。评价标准很直接读完这个用户故事开发能说出改哪张表、动哪个状态、调哪个接口。比如“作为网络管理员我要对PLAN状态的逻辑资源执行归档使该资源从可用列表中消失且不能再次分配”这句话已把status和API路径都限定死了。第二个技巧是让分册里的每条功能点都对应到一个接口契约。交付之前先给测试一份接口文档不用写太多但要标明每个字段是否必填、状态流转的约束、错误码。我习惯直接在项目里维护openapi.yaml每次评审分册需求时同步更新这个文件避免功能做完了文档还是旧版。第三个技巧是上线前用资源一致性SQL打一次分。综合网络资源管理系统最容易积累脏数据比如内存中的配置和数据库不一致、已退网资源还挂在业务上。我会在割接前跑下面这段SQL快速找出“在用但没关联任何业务”的资源。SELECT r.resource_id, r.resource_type, r.status, r.updated_time FROM resource_instance r WHERE r.status IN_USE AND NOT EXISTS ( SELECT 1 FROM resource_relation rr WHERE rr.src_id r.resource_id AND rr.relation_type IN (CARRY, BIND) ) LIMIT 100;这段SQL列出所有状态为在用但没有绑定关系、也没有承载业务的资源。如果是端口说明可能漏录了关联如果是业务资源说明已退订但状态没变更。把这些数据导出工单让对应专业负责人处理后再放量能避免上线后出现“明明已退网还在客户拓扑里显示”的争议。核查周期定在每周一和周四比月末突击对账更可靠。本文还有配套的精品资源点击获取
