2. 需求调研与业务对齐
网络项目失败最常见的原因，不是设备选型错误，也不是配置命令写错，而是一开始就没有把客户的真实业务需求问清楚。很多工程师拿到一张拓扑图就开始设计，结果交付时客户说“我们财务系统不能断超过30秒”“生产网和办公网必须物理隔离”“审计要求所有访问日志留存180天”——这些要求如果没在需求阶段固化，后期返工代价极高。本节要解决的就是：如何通过结构化访谈把模糊的业务诉求转化为可设计、可验证、可验收的技术需求，并最终形成一份双方签字确认的《需求规格说明书》。
一、访谈客户：从“想要什么”问到“为什么需要”
访谈不是聊天，更不是让客户自己写需求。客户通常只会说“网要快”“要稳定”“要安全”，这些都不是需求，而是愿望。工程师的任务是用业务语言提问，用技术语言记录。建议按四类对象分层访谈：业务负责人、IT运维负责人、安全合规负责人、最终用户代表。每类人关注点不同，问法也不同。
对业务负责人，重点问业务过程与中断容忍度：这个系统支撑哪些岗位？每天什么时段使用最集中？如果中断10分钟、1小时、4小时，分别会造成什么后果？对IT运维负责人，重点问现状与痛点：现有网络哪里经常出问题？哪些区域覆盖差？有没有已经规划但未实施的改造？对安全合规负责人，重点问约束条件：有没有等保、行业监管、集团制度要求？哪些数据不能出园区？日志要留存多久？对最终用户代表，重点问使用体验：哪些应用最常用？卡顿发生在什么位置、什么时间？
访谈中要特别警惕三类“伪需求”：一是把方案当需求，例如客户说“我要上SD-WAN”，其实真实需求可能是“分支访问总部ERP延迟高”；二是把个别现象当普遍需求，例如某次视频会议卡顿就要求全网上行扩容；三是把技术指标当业务指标，例如“要万兆到桌面”，但实际业务峰值只有几百兆。遇到这类表述，要用“5Why追问法”还原真实业务目标。
二、识别业务流量模型：把业务画成流，而不是画成点
需求调研的核心产出之一，是业务流量模型。它描述的是“谁、在什么时间、访问什么系统、走什么路径、产生多大流量、对时延和丢包有多敏感”。没有流量模型，QoS、带宽、链路选型、安全策略都只能拍脑袋。
建议按“业务系统—用户群体—访问关系—流量特征”四要素梳理。以某制造企业园区网为例，可整理出如下典型流量模型（示例参数为教学假设，非实测值）：
| 业务系统 | 主要用户群 | 访问关系 | 峰值带宽 | 时延敏感度 | 中断容忍 |
|---|---|---|---|---|---|
| ERP/MES | 生产、计划、财务 | 园区终端→数据中心 | 约300 Mbps | 高（<50 ms） | <5 min |
| 视频会议 | 全员 | 终端↔云会议平台 | 约200 Mbps | 很高（<30 ms，抖动<10 ms） | <1 min |
| 办公OA/邮件 | 全员 | 终端→互联网/数据中心 | 约150 Mbps | 中（<200 ms） | <30 min |
| 安防视频回传 | 安保 | 摄像头→NVR/监控中心 | 约400 Mbps | 中（<150 ms） | <10 min |
| 访客Wi-Fi | 访客 | 终端→互联网 | 约100 Mbps | 低 | 可容忍 |
这张表就是后续QoS策略、VLAN划分、链路带宽设计和SLA谈判的直接依据。例如视频会议抖动要求<10 ms，就决定了它必须进入优先队列，且不能与安防视频回传争抢同一拥塞链路。
三、确定SLA：把“稳定”翻译成可测量指标
SLA（服务等级协议）不是一句“保证网络稳定”，而是一组可测量、可验证、有责任边界的指标。企业网络项目常见的SLA维度包括：可用性、时延、抖动、丢包率、故障响应时间、故障恢复时间、变更窗口、性能容量。每个指标都要明确“测什么、在哪测、怎么测、达不到怎么办”。
以可用性为例，99.9%和99.99%看似只差0.09%，但年度允许中断时间从约8.76小时骤降到约52.6分钟，对设备冗余、链路备份、切换机制的要求完全不同。因此SLA必须与业务中断容忍度对齐，而不是越高越好。建议在需求规格说明书中采用如下结构记录SLA（示例）：
SLA-01 核心业务可用性
指标：ERP/MES 系统网络可达性 ≥ 99.9%
测量点：核心交换机上联端口 + 服务器网关
测量方法：每5分钟 ICMP + TCP 端口探测，按月统计
统计口径：不可用定义为连续3个探测周期失败
未达标处理：按合同约定扣减服务费或延长维保
SLA-02 视频会议质量
指标：端到端时延 ≤ 30 ms，抖动 ≤ 10 ms，丢包率 ≤ 0.1%
测量点：会议终端接入交换机端口
测量方法：IP SLA / TWAMP 主动探测，每1分钟采样
未达标处理：触发QoS策略复核与链路扩容评估四、合规要求：先问“谁在管我们”，再问“要留什么证据”
合规要求往往比技术需求更刚性。常见来源包括：《网络安全法》、等级保护2.0、行业监管（金融、医疗、制造）、集团内控、客户合同中的安全条款。调研时要明确四件事：哪些区域必须隔离、哪些数据不能出园区、哪些操作必须留日志、日志留存多久。
例如等保2.0三级要求中，网络架构需满足“重要区域边界隔离”“通信传输完整性与保密性”“安全审计覆盖到每个用户”。落到设计上，可能意味着：生产网与办公网之间部署防火墙并默认拒绝；核心链路启用IPSec或MACsec；所有网络设备日志统一送日志服务器，留存不少于180天。这些要求必须写入需求规格说明书，并在验收测试中逐条验证。
五、输出需求规格说明书：让需求可追溯、可验收
需求规格说明书（RSN）不是访谈记录堆砌，而是经过整理、分类、编号、确认的正式文档。建议包含以下部分：项目背景与范围、业务目标、现状与痛点、业务流量模型、功能需求、性能与SLA需求、安全与合规需求、约束与假设、验收标准、待确认项。每条需求都要有唯一编号，便于后续设计、测试和变更追溯。
以下是一份可直接参考的需求条目示例（节选）：
| 需求编号 | 类别 | 需求描述 | 验收方式 | 优先级 |
|---|---|---|---|---|
| REQ-NET-001 | 性能 | 生产区到数据中心ERP时延≤50 ms，丢包率≤0.1% | IP SLA连续7天采样 | 高 |
| REQ-NET-002 | 可用性 | 核心链路故障切换时间≤1 s，业务不中断 | 断链测试+业务连续性验证 | 高 |
| REQ-SEC-001 | 安全 | 生产网与办公网默认拒绝互访，仅放行必要端口 | 防火墙策略审计+渗透测试 | 高 |
| REQ-SEC-002 | 合规 | 网络设备日志留存≥180天，支持按用户溯源 | 日志服务器查询验证 | 高 |
| REQ-OPS-001 | 运维 | 提供统一网管平台，支持拓扑、告警、性能视图 | 功能演示+验收测试 | 中 |
需求规格说明书完成后，必须组织客户方业务、IT、安全三方进行评审确认，并签字或邮件确认。确认后的需求变更要走变更流程，避免“边做边加需求”导致项目失控。只有把需求阶段做扎实，后续的拓扑设计、设备选型、IP规划、QoS策略、安全策略才有据可依，项目交付才能真正对齐业务目标。