Day36-10｜17.4.1 网络需求分析：从业务目标到可验证的网络架构约束

对应教材：第 17 章 通信系统架构设计理论与实践——17.4.1 网络需求分析
学习定位：掌握网络需求分析的对象、过程、指标、约束和输出物，能够把业务目标转化为带宽、时延、可靠性、安全性、可扩展性和运维方面的可验证要求，为后续网络技术选型与架构设计提供依据。

一、为什么网络需求分析是架构设计的起点

很多网络项目失败，并不是因为交换机、路由器或防火墙性能不够，而是因为一开始没有把“业务需要什么网络能力”说清楚。项目团队常见的表达是“建设一张高性能、高可靠、先进的网络”，但这些词没有明确的测量边界：高性能到底是吞吐量高，还是应用响应时间短？高可靠是设备双机，还是端到端业务在故障时能够继续？先进是使用最新协议，还是能够适应未来租户和业务增长？

网络需求分析的任务，就是把模糊的目标转换为可以验证、可以排序、可以追踪的需求。它不等于简单统计终端数量，也不等于先选定某个厂商再反推参数。网络架构师需要先理解业务、数据流和组织边界，再决定哪些指标重要、哪些约束不可违反、哪些能力可以分阶段建设。

网络需求分析的核心链条可以概括为：

业务目标 → 业务场景 → 用户与流量对象 → 数据流与通信关系 → 质量属性 → 可量化指标 → 技术约束 → 设计验收标准

如果这条链条中间缺少环节，后续方案就容易出现“设备参数很好，但业务仍然不可用”的情况。例如，电商系统关心的是高峰期下单成功率、支付链路时延和数据库连接稳定性；视频会议系统关心的是端到端时延、抖动、丢包和优先级；工业控制系统关心的是确定性时延、隔离、时间同步和故障安全。三者都使用网络，但需求完全不同。

二、网络需求分析的主要对象

2.1 业务需求

业务需求描述网络要支撑什么业务以及业务价值。常见内容包括办公访问、互联网出口、数据中心业务、生产控制、视频会议、物联网采集、远程运维、灾备复制和多云互联等。

分析业务需求时要进一步询问：业务的服务对象是谁？业务是否全年连续运行？是否存在明显峰值？业务中断的影响是什么？哪些业务属于核心业务？哪些业务允许降级？哪些数据允许异步传输？

不同业务的优先级不能只由网络部门决定。应当与业务负责人确认服务等级，并将业务等级映射到网络的带宽保障、路由优先级、隔离策略和故障恢复目标中。

2.2 用户与终端需求

用户需求包括用户数量、位置分布、接入方式、终端类型、访问模式和移动性。终端需求则包括服务器、虚拟机、容器、传感器、摄像头、工业控制器、办公终端、无线设备和第三方设备等。

需要注意“用户数”不等于“并发连接数”，“终端数量”也不等于“网络端口数”。一个用户可能使用多个终端，一个终端可能建立多个连接；无线终端还会随着位置变化产生漫游和接入点切换。网络规划必须关注忙时并发、连接建立速率、广播域规模、地址数量以及终端认证频率。

2.3 应用与数据流需求

应用需求要落到通信关系上。建议为核心业务建立数据流矩阵，记录源区域、目的区域、协议、端口、流量方向、峰值带宽、平均带宽、时延要求、可靠性要求和安全等级。

一个简化的数据流矩阵可以包含：

数据流矩阵的价值在于让架构师看到“通信关系”，而不是只看到一批设备数量。它可以直接支撑 VLAN 或 VRF 划分、路由域设计、QoS 队列、安全边界、链路容量和灾备线路选择。

2.4 管理与运维需求

网络不仅要能运行，还要能被监控、变更、审计和恢复。运维需求包括统一认证、配置备份、版本管理、拓扑发现、链路监控、流量分析、日志留存、告警分级、自动化发布和应急回滚等。

对于大型网络，要特别关注多团队协作和权限边界。例如，网络团队可以维护链路，安全团队维护访问策略，云平台团队申请虚拟网络，业务团队查看应用流量，但不同角色不应拥有超出职责的修改权限。需求分析阶段应确定管理域、责任边界和审计要求。

三、网络需求分析的基本过程

3.1 识别利益相关者

利益相关者包括业务负责人、系统架构师、网络管理员、安全管理员、应用开发团队、机房与基础设施团队、供应商以及最终用户。不同角色对网络的关注点不同：业务关注可用性和体验，安全关注边界和审计，运维关注可管理性，财务关注成本，用户关注访问速度。

架构师要避免只向网络管理员收集需求，因为网络管理员容易从现有设备和技术能力出发描述问题，而忽略业务真正的服务目标。更合理的方式是通过访谈、问卷、现网监控、故障记录、应用清单和业务连续性文档交叉验证。

3.2 盘点现状与基线

现状分析要回答：现有网络拓扑是什么？设备和链路的利用率如何？地址和 VLAN 是否足够？路由协议和安全边界如何划分？核心设备是否存在单点？历史故障集中在哪些位置？现有网络能否支撑新业务？

现状数据不能只依赖拓扑图，因为文档可能已经过期。应结合设备配置、流量采集、链路监控、路由表、ARP 或邻居信息、日志和变更记录建立基线。基线至少应包含忙时带宽利用率、接口错误率、丢包率、往返时延、抖动、CPU 和内存、连接数、广播量以及故障恢复时间。

3.3 提取场景并建立通信模型

按场景描述比按设备描述更容易发现需求。典型场景包括：工作日早高峰登录、月末批量处理、视频会议并发、生产设备大规模上报、数据中心跨区域复制、主链路故障、机房断电、恶意访问和临时扩容。

每个场景都应描述触发条件、参与者、数据流、性能指标、异常处理和恢复目标。例如“主链路中断”不是一句“要高可靠”，而应进一步明确：检测时间不超过多少秒？切换是否允许连接重建？关键业务最大中断多久？备链路带宽是否足够？切换后是否需要人工确认？

3.4 量化质量属性

质量属性必须转化成指标和验证方法。常见指标如下：

指标应尽量包含对象、条件、阈值和测量方法。例如“核心链路性能良好”不可验收；“忙时 95 分位端到端时延不超过 20 ms、丢包率不超过 0.1%，持续 30 分钟”才可以成为设计约束。

3.5 分析约束并确定优先级

网络需求之间可能冲突。安全隔离会增加跳转和检查，可能影响时延；高可靠可能需要增加设备和链路，带来成本；统一协议可能无法覆盖所有遗留设备；低成本线路可能无法满足关键业务时延。

可以将需求分为必须满足、应该满足、可以优化和暂不建设四类。对于必须满足的约束，应明确违反后的后果和替代方案。优先级排序不能凭感觉，建议结合业务损失、合规要求、用户影响、实现难度和建设成本进行评估。

四、网络需求中的关键技术指标

4.1 带宽与容量

带宽规划要区分平均流量、忙时流量、峰值突发和未来增长。简单地把所有应用峰值相加，可能造成过度建设；只按平均值规划，又可能在峰值时拥塞。通常需要结合业务并发、流量相关性、突发系数和服务等级计算。

一个基础估算可以写成：

规划带宽 = 现有忙时带宽 × 增长系数 × 峰值系数 ÷ 目标利用率

例如现有忙时流量为 600 Mbps，预计增长 1.5 倍，峰值系数取 1.3，链路目标利用率为 70%，则规划带宽约为 600 × 1.5 × 1.3 ÷ 0.7 ≈ 1671 Mbps。这个公式不是所有场景的最终模型，但可以帮助架构师避免只按照端口速率拍脑袋。

4.2 时延、抖动与丢包

网络时延通常要分解为处理时延、排队时延、传输时延和传播时延。对于交互应用，平均时延还不够，还要看尾部时延；对于语音、视频和工业控制，抖动及丢包更关键。

需求分析应明确测量位置，是主机到主机、应用到应用，还是某一段链路到另一段链路。不同测量口径不能直接比较。对于跨地域网络，还要考虑距离、运营商路由、专线质量和故障绕行路径。

4.3 可用性与恢复目标

网络可用性可以从设备、链路、路径、区域和业务端到端多个层级描述。双设备不等于业务高可用，如果两台设备共享同一电源、同一机柜、同一上联链路，仍然存在共同故障域。

需求中要明确故障恢复时间目标 RTO、可接受数据丢失目标 RPO 或等价的业务恢复要求。网络侧还要定义故障检测时间、路由收敛时间、连接重建时间和人工介入时间。

4.4 安全性与合规

安全需求包括身份认证、访问控制、网络隔离、加密传输、密钥管理、入侵检测、日志审计、数据完整性和应急响应。不能只写“部署防火墙”，因为防火墙是一种技术手段，不是完整安全需求。

需求分析还要明确哪些数据不能跨区域传输、哪些系统必须单向访问、哪些管理操作需要双人审批、日志需要保存多久，以及发生安全事件后多长时间内必须完成定位和报告。

五、网络需求分析的输出物

完整的网络需求分析通常应形成以下成果：

1. 业务与用户清单：记录业务、用户、位置、终端和服务等级。
2. 现网基线报告：记录拓扑、设备、链路、流量、故障和容量。
3. 数据流矩阵：记录核心通信关系和质量要求。
4. 需求规格说明书：记录功能性需求、质量属性、约束和优先级。
5. 地址、命名和路由需求：记录地址空间、域名、路由域和自治边界。
6. 安全域与访问矩阵：记录区域划分、允许关系、认证和审计要求。
7. 容量与增长模型：记录当前容量、预测增长、扩容节点和预留比例。
8. 验收指标清单：记录每项需求的验证方法、环境、阈值和责任人。

需求与设计之间应建立追踪关系。一个需求可以对应多个设计决策，一个设计决策也可能满足多个需求。若后续修改架构，却无法说明哪些需求受到影响，项目就容易出现“设计完成但需求遗漏”的问题。

六、常见错误与改进方法

6.1 先买设备，再找需求

这种做法会使需求分析变成设备参数填表，最终方案可能被某个厂商的产品能力牵着走。改进方法是先描述业务场景和指标，再建立技术候选和设备能力矩阵。

6.2 只写平均值，不写峰值和尾部

平均时延、平均带宽和平均连接数可能掩盖高峰期问题。应补充忙时、峰值、95 分位或 99 分位指标，并说明采样周期和测量位置。

6.3 只统计数量，不分析关系

统计多少台服务器、多少个端口不能替代数据流分析。网络架构的复杂度往往来自区域之间的访问关系、策略数量和变化频率，而不是设备数量本身。

6.4 把高可靠等同于双机

高可靠是端到端能力。要识别设备、链路、电源、机房、运营商、控制器、配置中心和人员操作等共同故障点，并通过故障域拆分、路径冗余、快速检测、自动切换和演练验证实现目标。

6.5 忽略非功能需求

网络架构不仅要承载流量，还要满足安全、运维、合规、扩展和成本要求。需求文档至少应覆盖质量属性，并为每项质量属性给出可测量指标。

七、案例分析：制造企业园区网络需求

某制造企业准备建设新园区网络，包含办公区、生产车间、实验室、视频监控、访客接入和两地灾备。业务方提出“生产不能中断、办公体验流畅、视频不能卡顿、未来五年可扩展”。

第一步，识别业务等级。生产控制和安全监测属于一级业务，要求高可靠、强隔离和确定性时延；订单、仓储和办公属于二级业务，要求较高可用性和稳定体验；访客和普通互联网访问属于三级业务，可以限速和降级。

第二步，建立区域模型。生产控制区、服务器区、办公区、视频区、访客区和管理区分离。跨区访问必须通过明确的安全策略，管理区使用独立管理网络，避免业务流量和设备管理共用同一平面。

第三步，建立流量模型。记录生产控制报文、视频上传、办公访问、灾备复制和互联网访问的平均与峰值带宽，并确定时延、抖动、丢包、加密和审计要求。

第四步，确定故障目标。生产核心设备、核心链路和供电采用不同故障域；生产区的故障检测和切换时间要通过演练验证；灾备复制可采用异步方式，但必须明确最大可接受数据丢失窗口。

第五步，定义扩展需求。接入终端和摄像头按五年增长预测规划，核心链路保留扩容能力，地址空间和 VLAN、VRF 或隧道标识不能按当前数量刚好分配。

第六步，形成验收标准。包括高峰期带宽利用率、生产链路时延和丢包、故障切换时间、跨区访问审计完整性、配置备份恢复时间以及新增区域上线时间。

这个案例说明，网络需求分析的最终产物不是“买什么设备”，而是一组能够指导架构、评审和验收的约束。

八、今日必背清单

1. 网络需求分析的起点是业务目标，终点是可验证的设计和验收约束。
2. 需求分析对象包括业务、用户、终端、应用、数据流、运维、安全和合规。
3. 数据流矩阵是连接业务需求与网络架构的重要工具。
4. 性能需求要描述带宽、时延、抖动、丢包、并发和尾部指标。
5. 高可靠需求要落实到故障域、检测时间、切换时间、恢复时间和演练方式。
6. “采用双机”“部署防火墙”“使用 SDN”都是设计手段，不是完整需求。
7. 需求应分级排序，并建立需求—设计—测试的追踪关系。
8. 验收指标必须包含对象、条件、阈值和测量方法。

九、课后练习

练习一：单项选择

下列哪一项最适合作为网络需求分析的输出？

A. 某厂商交换机型号清单
B. “建设先进网络”的口号
C. 核心业务在忙时的时延、丢包率和切换时间验收指标
D. 网络管理员个人经验总结

练习二：判断题

网络需求分析只需要统计终端数量和端口数量，不需要建立业务数据流矩阵。（ ）

练习三：简答题

请说明为什么“网络高可靠”不能简单等同于“核心设备双机部署”，并列举至少四个需要分析的故障因素。

练习四：案例题

某在线交易系统在工作日高峰期出现响应变慢，现网平均带宽利用率只有 45%，但用户仍然投诉严重。请从网络需求分析角度说明还需要收集哪些数据，才能判断问题是否属于网络容量不足。

十、参考答案

练习一答案

答案：C。

解析：网络需求必须能够验证。C 明确了业务对象、场景和可测量指标，可以直接指导设计与测试。设备型号是方案阶段的内容，“先进网络”没有可验证含义，个人经验不能替代需求基线。

练习二答案

答案：错误。

解析：终端数量只反映规模的一部分，不能说明通信关系、方向、峰值、时延、安全等级和故障影响。数据流矩阵能够帮助架构师设计区域、路由、链路容量、QoS 和访问控制。

练习三答案

参考答案：双机只解决某一类设备实例故障，不能覆盖链路、电源、机房、运营商、路由协议、控制器、配置错误和人员操作等故障。至少应分析设备故障、链路故障、电源或机房故障、上联或运营商故障、路由收敛失败、配置变更错误和安全事件。还要明确故障检测时间、切换时间、业务中断时间、状态同步和恢复验证方式。

练习四答案

参考要点：

1. 收集应用端到端时延、连接建立时间、DNS 时间、TCP 重传、TLS 握手和服务端响应时间，避免把应用处理慢误判成网络慢。
2. 收集链路利用率的忙时峰值和 95/99 分位，而不是只看平均值；同时查看突发流量、队列长度和丢包。
3. 分析不同区域、不同运营商、不同用户群的时延和丢包，定位是否存在局部链路拥塞。
4. 检查设备 CPU、内存、转发表、NAT 会话数、防火墙连接数、负载均衡连接数和端口错误。
5. 检查路由变化、链路抖动、MTU、DNS、认证服务和安全设备策略，识别非带宽瓶颈。
6. 根据业务并发、请求大小、响应大小和峰值时间建立流量模型，再与实测数据对比，最后才能判断是否需要扩容。

十一、今日复盘

请尝试用一句完整的话说明：网络需求分析不是“列设备参数”，而是“把什么内容转化为什么内容”。推荐答案是：把业务场景、通信关系和质量目标转化为带宽、时延、可靠性、安全性、扩展性和运维方面的可验证约束，并建立从需求到设计、再到测试验收的追踪关系。

下一篇进入 17.4.2「网络技术选型及设计」，将基于今天形成的需求约束，比较不同网络技术和架构方案的适用边界。