搞清楚谁在用，怎么用
做网络规划时，最容易犯的错误就是一上来就画拓扑图、选设备，却忽略了最根本的问题：这网络到底是给谁用的？比如我们之前接手一个社区医院的项目，一开始以为就是普通办公上网，结果调研才发现他们有远程会诊、影像传输这些高带宽需求。要是按常规配置，等系统上线肯定卡得不行。
所以第一步不是技术选型，而是跑现场、问人。问问医生是不是经常传CT片子，护士站有没有移动查房终端，财务室要不要连医保专线。把这些使用场景摸清楚，才能定出真实的流量模型和优先级策略。
别小看那些‘临时需求’
有个客户说‘暂时就几十个员工，以后再说’，结果半年内扩张到两百多人，还加了视频监控系统。当初交换机只留了两个扩展口，根本没法扩容。后来重新布线，成本翻倍。
经验是：哪怕对方说得再‘暂时’，也得按未来18个月的发展去预估。用户永远想不到自己会新增什么业务，但作为规划者得替他们想到。比如现在没无线，不代表三个月后不会全员配平板；现在没服务器，难保明年不上本地HIS系统。
安全边界要提前划好
曾经做过一个连锁药店的网络设计，门店和总部之间要传销售数据。客户一开始觉得用公共WiFi加账号密码就够了。但我们坚持做了IPSec隧道，并把POS终端单独划进VLAN。后来听说附近有家同行被蹭网盗走了交易记录，才意识到当时那个决定有多必要。
需求分析阶段就得把安全当成基础要素，而不是附加功能。哪些数据敏感，哪些设备暴露在公网，访问权限怎么分——这些问题要在画第一根线之前就有答案。
带宽不能只看理论值
办公室标称100M宽带，实际打开网页还是慢，问题往往出在并发连接数和延迟上。有一次发现一家企业的视频会议总是掉线，查下来不是带宽不够，而是路由器NAT表项只有2048条，上百人同时在线就把表打满了。
所以写需求的时候，除了‘需要多少M’，还得列清典型应用场景下的连接数、会话保持时间、抖动容忍度这些细节。可以这样描述：‘支持30路1080P视频会议并发，单向延迟低于200ms，丢包率小于0.1%’。
留点余地给意外情况
某次做完校园网规划，验收时一切正常。结果开学第一天，新生集中报到，上千人同时连WiFi，认证服务器直接崩了。问题不在网络架构，而在需求阶段没人提过‘瞬时高密度接入’这个场景。
现在我会专门问一句：有没有节日、促销、开学这类高峰期？像商场要做双十一大屏直播，展会要支撑千人扫码互动，这些特殊时段的压力必须纳入设计考量。
配置示例：基础QoS策略
class-map VOICE
match dscp ef
class-map VIDEO
match dscp af41
class-map DATA
match any<br><br>policy-map WAN-OUT
class VOICE
priority percent 30
class VIDEO
bandwidth percent 40
class DATA
fair-queue
random-detect这种策略看着简单，但前提是需求阶段就明确了语音优先级最高，视频次之。如果没有前期沟通，后期硬套模板只会水土不服。
文档比想象中重要
一年前做的项目，最近要升级。翻出当时的《需求确认书》，里面写着‘支持IPv6试点接入’，这才想起来预留了双栈配置。要是没这纸记录，现在肯定当成纯IPv4系统来处理。
每次做完访谈，立刻整理成表格发给客户确认。包括终端类型统计、应用系统清单、可用性要求等级。白纸黑字的好处是，既能避免后期扯皮，也能帮自己理清思路。