1. 机房现场的第一轮判断:设备还没上架就该定下来的事
网络设备安装与调试这件事,纸面上永远是“上架、接线、配置、测试”四步,但真正做过几次割接的人都知道,八成的返工都发生在这四步之外。我印象最深的一次是给一个小型办公区做接入层改造,图纸画得规规矩矩,货到了现场才发现机柜深度只有600毫米,设备挂耳装上去之后后门关不上,电源线插头被柜门顶住。那天下午四个人抬着设备来回折腾,最后是把机柜后门拆了才勉强通电。从那以后我养成一个习惯:设备下单之前先跑一趟现场,量柜深、看风道、数电源插座,把能提前确认的东西全部确认掉。
这一节讲的都是上架之前的事,听起来琐碎,实际上决定了后面所有工作的顺畅程度。目标场景是园区网和中小型机房,涉及接入交换机、汇聚交换机、路由器和无线控制器这类常见设备,虚拟化和云网设备不在讨论范围内。
1.1 机柜空间、深度与散热风道的三重核算
机柜空间不是简单地数还剩几个U。标准42U机柜里,1U等于44.45毫米,设备本身的高度好算,难算的是走线空间和散热余量。我的做法是预留至少20%的空U位,尤其是在接入设备密集的机柜里,设备与设备之间空一格,别图省事全堆在一起。发热量大的设备(比如带PoE供电的交换机、带风扇模块的汇聚设备)尽量放在机柜中上部,因为热空气往上走,底部进风口能吸到相对凉的空气。
机柜深度这个参数最容易被忽略。常见的600毫米深机柜放普通接入交换机没问题,但放了带双电源、后部走线的设备就很紧张。前维护设备需要前门能完全打开,后部接线需要至少100毫米的理线空间。我一般要求:设备前面板到前门内侧留80毫米以上,设备后部到后门留120毫米以上。达不到就得换柜或者换短机身型号,别指望现场能掰。
风道方向必须统一。机柜里最怕的是前出风和后出风混装,热风在柜内打转,夏天机柜顶部温度能比机房环境温度高出10度以上。上架前把每台设备的风扇方向查一遍,从前进风后出风的设备排在一起,方向不一致的单独放一个柜或者调整安装方向。
| 核算项 | 建议值 | 常见错误 |
|---|---|---|
| U位预留 | 不少于总容量的20% | 塞满导致后期扩容无位 |
| 前部维护空间 | ≥80毫米 | 前门无法全开,拔插跳线困难 |
| 后部接线空间 | ≥120毫米 | 电源线与网线挤压,柜门关不上 |
| 柜内温升 | 与环境温差≤8度 | 前后风道混装形成热回流 |
1.2 供电冗余与接地:最容易被“先通电再说”跳过的一环
供电这块,我见过太多“先插上再说”的操作。双电源设备一定要接到两路独立的供电回路上,哪怕是同一路市电下的两个不同空气开关,也比两路插在同一个PDU上强。判断标准很简单:拔掉一路,设备不掉电、不告警,才算真冗余。如果现场只有一路市电,那就在文档里老老实实写清楚“当前无真正冗余”,别给后面维护的人制造错觉。
功率核算也要做。一台24口PoE交换机满载供电时,光PoE部分就可能吃掉300瓦以上,加上设备自身功耗,一路16A的回路在满配机柜里其实很紧张。我的算法是:把机柜内所有设备铭牌功率相加,乘以0.8的同时使用系数,再留30%的余量,得出的数字去对比PDU和空开的额定值。
接地是另一个高频遗漏点。设备机壳接地、机柜接地排、机房等电位连接,这三者必须形成通路。验收时用万用表量一下机柜接地排到设备外壳的电阻,正常情况下应该接近导通状态。接地不良带来的问题不是立刻显现的,可能表现为端口偶发误码、雷雨季节设备损坏率偏高,排查起来非常费劲,所以宁可上架时多花十分钟。
1.3 上架顺序与理线规划:先想清楚“线往哪走”
上架顺序我的习惯是从下往上、从重到轻。重的设备(比如堆叠的汇聚交换机、带大功率电源的设备)放在机柜下部,重心稳,搬运时也不容易砸到下面的人。同组设备连续排列,中间不留空U,这样堆叠线和级联线短,走线干净。
理线规划要在设备上架前就定好。我的做法是在纸上画出机柜正视图,标出每台设备的U位、前面板端口朝向、线缆从左侧还是右侧出。接入交换机的网线一般从左侧走,电源线从右侧走,两边分开,互不干扰。理线架装在设备正下方,别装在正上方,否则跳线要往上绕一个弯,时间长了容易松脱。设备与理线架之间留半U空隙,方便手指伸进去插拔。
还有一个细节:螺丝。设备挂耳螺丝要全部拧紧,四个角都要上,别只拧两个。我见过因为只拧了对角两颗螺丝,设备在搬运振动中位移,导致后面板端口和配线架错位,跳线插不到位的情况。螺丝拧紧的力矩也有讲究,塑料面板的设备拧太紧会裂,金属面板的拧不紧会松,手感上拧到“贴着不动、再用力有明显阻力”就差不多。
2. 加电前必须完成的事:铜缆、光模块与标签体系
设备上架只是把铁壳子固定住了,真正决定网络能不能跑起来的是线。这段内容我在带新人的时候讲得最多,因为线缆和标签这两件事,做对了后面所有环节都顺,做错了就是无穷无尽的返工。有一次一个小项目,接入交换机到配线架的跳线全部用成品线随便插,没做标签,三个月后扩容时谁也说不清哪个口对应哪个工位,最后是拿着测线仪一个口一个口去点,两个人干了一整天。
2.1 铜缆与光模块的选型判断:距离和带宽先算清楚
铜缆的核心约束就一条:单段长度不超过100米,其中永久链路(配线架到信息面板)不超过90米,两端跳线合计不超过10米。超过这个长度,千兆可能还能勉强协商上,但误码率会明显上升,表现为高峰期丢包、大文件传输速度掉到几十兆。现场如果确实超距,别硬撑,改用光纤或者中间加一台小交换机做中继。
线缆等级要跟速率匹配。百兆场景超五类够用,千兆建议六类,2.5G和5G场景至少超六类,万兆铜缆要看具体型号和距离。屏蔽线和非屏蔽线的选择看环境:普通办公区非屏蔽完全够用,靠近强电井、变频设备、电梯机房的走线建议用屏蔽线,但屏蔽线必须做好两端接地,只接一端等于没接,反而可能引入干扰。
光模块的坑更多。多模光纤配多模模块,单模光纤配单模模块,这个基本原则大家都知道,但实际现场经常出现多模模块插单模跳线、或者模块波长和跳线类型不匹配的情况。判断方法很简单:看模块标签上的波长,850纳米一般对应多模,1310纳米和1550纳米对应单模,同时看跳线外皮颜色,多模通常是橙色或水蓝色,单模通常是黄色。两端模块的速率、波长、传输距离必须一致,一端是10公里模块另一端是40公里模块,短距那头可能因为收光过强而误码,必要时加衰减器。
| 介质类型 | 典型场景 | 单段距离上限 | 注意事项 |
|---|---|---|---|
| 六类非屏蔽铜缆 | 工位接入、设备间跳线 | 100米(含跳线) | 避免与强电同槽 |
| 多模光纤 | 楼内设备间互联 | 数百米(视模块而定) | 注意光纤类型与模块波长匹配 |
| 单模光纤 | 楼宇间、长距互联 | 数公里以上 | 检查收发光功率是否在范围内 |
| 堆叠专用线缆 | 同柜设备堆叠 | 通常1至3米 | 长度不够时不要强行拉拽 |
2.2 端口编号与标签规则:让三个月后的自己看得懂
标签这件事,规则比工具重要。我的规则是三层:物理位置、设备端口、对端信息。举个例子,一根跳线两端的标签分别写“A柜-03U-G1/0/12”和“B配线架-24口”,中间用箭头或者直接对端写法都行,关键是两端都能独立读懂,不需要查表。
标签材质要经得起时间。手写纸标签贴上去,半年就模糊了,机房温度高,胶还会化。用打印机打的线缆标签,外面带一层透明保护膜的那种,寿命长很多。标签贴在跳线两端距离接头5到10厘米的位置,别贴太靠接头,否则插拔时容易刮掉。
设备命名同样要有规则。主机名建议包含“位置、角色、序号”三段信息,比如接入层设备命名为“位置缩写-接入-编号”的形式。管理地址、VLAN、堆叠成员编号这些信息,跟主机名一起记在台账里。台账这个东西,我坚持用表格维护,字段至少包括:设备名称、管理地址、所在机柜与U位、上联端口、下联范围、负责人、投运日期。看起来麻烦,真出故障的时候能省下大量定位时间。
2.3 走线路径与弯折半径:光纤不是越多弯越好
走线的物理细节直接影响链路质量。网线的弯折半径一般要求不小于线缆直径的4倍,光纤要求更严格,动态弯折半径通常不小于30毫米,静态不小于20毫米。实际布线时最常见的错误是把多余长度的光纤盘成很小的圈用扎带一绑,短期看不出问题,长期衰减会明显上升。正确做法是盘成直径15厘米以上的大圈,用魔术贴固定,别用尼龙扎带勒死。
强弱电分离也是老生常谈但经常做不到的事。网线和电源线平行走线时,间距建议保持30厘米以上;必须交叉时尽量垂直交叉,减少耦合长度。机柜内的电源线和网线分别走两侧理线槽,实在做不到就用理线环隔开。我见过因为电源线和网线绑在一起,导致千兆链路频繁降速到百兆的案例,换线之后立刻恢复,说明干扰是真实存在的。
走线完成后做一次全面检查:所有跳线插到位有“咔哒”声,光纤接头端面用放大镜检查有没有灰尘和划痕,光纤接头不插设备时一定要盖防尘帽。灰尘是光链路的大敌,一个脏端面能让10G链路直接不通,用专用清洁工具擦一下就好,但前提是你知道要查这个。
3. 设备初始化:从Console口到可用的管理面
设备通上电,风扇转起来,指示灯亮起来,这只是硬件活了,软件层面还是一张白纸。初始化这一步的目标很明确:让设备具备一个稳定、安全、可远程管理的入口,同时把基础参数固化下来,为后续配置打底。很多现场事故就出在这一步——管理地址配错导致远程连不上,只能抱着笔记本去机房;或者没设账号密码策略,设备裸奔在网里。
3.1 带外管理口的接线与终端参数
新设备开箱第一件事是找Console口。大部分设备的Console口是RJ-45形式,也有USB形式的,随机附带的Console线要提前确认在不在箱子里。我吃过一次亏,设备到了才发现配套线材没带,临时找了一根普通网线接上去,结果引脚定义不对,终端一片乱码。后来固定做法是:工具箱里常备一根USB转串口的Console线和一根RJ-45转串口的线,两种接口都覆盖。
终端参数是固定的老几样:波特率9600,8位数据位,无校验,1位停止位,无流控。这个组合覆盖了绝大多数网络设备。如果连上去是乱码,先怀疑波特率不对,依次试115200和38400;如果完全没反应,检查线序和串口号是否选对。终端软件里把“发送回车换行”打开,有些设备需要回车才能唤醒命令行。
带外管理除了Console,还有独立的管理网口。这类网口通常标着MGMT或者带一个小扳手图标,接进独立的管理VLAN,跟业务流量物理或逻辑隔离。好处是业务网出问题时,管理通道还在,能远程登录排查。管理网口的地址规划要单独拿一段私网地址,别和业务地址混在一起,网关指向管理区的三层设备。
3.2 基础配置的最小集:四件事先落地
设备能登录之后,别急着配业务,先把四件事做完。
第一是主机名。命名规则前面讲过,落地的时候注意长度限制,有些设备主机名不能超过32个字符,中文和特殊符号尽量别用。
第二是时间同步。设备时间不准,日志时间戳就是错的,排查故障时根本对不上事件顺序。配置指向内网的时间服务器,时区设成当地时间。如果内网没有时间服务器,至少把设备时间手动校准,并且记录下来定期检查。
第三是管理地址与默认网关。给设备配一个管理VLAN内的地址,指定网关,然后从管理区的一台终端去ping它,确认三层可达。这一步不做,后面远程配置全靠猜。
第四是账号与权限。创建至少两个账号,一个日常运维用,一个应急用,密码长度不少于12位,包含大小写字母、数字和符号。远程登录方式优先用加密协议,明文协议关掉。同时配置登录失败锁定和超时退出,避免有人挂着会话不退出。
提示:基础配置做完立刻保存,并且导出一次配置文件。有些设备的配置在未保存状态下断电就丢了,初始化阶段反复断电重启的概率不低。
3.3 固件版本核对与升级窗口的选择
新设备出厂固件往往不是最新版本,有些甚至带着已知问题。上架前查一下当前版本,跟厂商发布说明对比,看有没有影响当前功能的关键修复。如果有,安排在业务割接前升级,别等到设备已经在网里跑着业务再动。
升级窗口的选择有讲究。升级过程通常需要重启,业务会中断,所以要放在业务低峰期,并且提前通知使用方。升级前做三件事:备份当前配置、记录当前版本号、准备好回退方案(有些设备支持双镜像,切换启动镜像就能回退)。升级文件通过管理网口或者U盘传入,传输完成后校验文件大小和哈希值,避免文件损坏导致升级失败变砖。
升级完成后的验证不能只看版本号变了。要检查配置是否完整保留、接口状态是否正常、管理地址是否可达、关键业务是否恢复。有些版本升级会改变默认行为,比如默认关闭某些端口、改变生成树默认模式,这些都要在升级后逐项确认。
4. 把规划图纸变成配置:VLAN、地址与链路的落地
前面都是准备工作,从这里开始进入真正的配置阶段。图纸上画的VLAN划分、地址段、上联关系,落到命令行里就是一条条配置。这一步最考验对整体架构的理解,因为单条命令写对不难,难的是所有设备的配置之间能对得上。我见过一个项目,接入层配了VLAN 10作为管理,汇聚层却把VLAN 10划给了业务,结果管理地址和业务地址冲突,全网时通时不通,查了两天才发现问题。
4.1 端口角色划分:access、trunk与hybrid的取舍
端口模式的选择本质上是“这个口接什么”的问题。接终端设备(电脑、打印机、摄像头、无线AP的管理口)用access模式,划进对应的业务VLAN,终端不需要打标签,插上就能用。接交换机之间的级联链路用trunk模式,允许多个VLAN通过,两端允许的VLAN列表必须一致,少一个就会导致某个业务网段不通。
hybrid模式灵活性最高,可以同时处理带标签和不带标签的帧,但配置复杂度也高,除非有特殊需求(比如一个口同时接IP电话和电脑,电话走语音VLAN、电脑走数据VLAN),否则不建议大面积使用。我的原则是:能用access就不用trunk,能用trunk就不用hybrid,简单即稳定。
端口还有几个必配项。接终端的access口开启边缘端口属性,跳过生成树的监听和学习阶段,终端插上立刻能用,同时避免终端开关机触发拓扑震荡。不用的端口全部关掉,划到一个隔离VLAN里,防止有人私接设备。接无线AP的口如果AP需要供电,确认PoE功率预算够不够,24口PoE交换机带满高功率AP时经常超预算,要提前算。
4.2 地址池与DHCP中继的配置链路
终端要拿到地址,DHCP这条链路必须通。典型结构是:DHCP服务器在核心或者独立服务器上,接入交换机不跑DHCP服务,只做二层转发,网关设备上配置DHCP中继指向服务器。配置中继时要注意两点:中继接口必须是终端的网关接口,源地址要能被DHCP服务器识别并匹配到对应的地址池。
地址池规划有几个经验值。一个C类地址段254个可用地址,实际办公场景下按工位数乘以1.5来估算,留出访客设备、打印机、临时终端的余量。地址租期办公网一般设8小时到1天,太短会导致续租流量大,太长会导致地址回收慢。保留地址(网关、服务器、打印机、AP管理地址)单独列出,从池子里排除,别让DHCP分出去。
验证方法很直接:终端释放再获取地址,看拿到的地址是否在预期网段、网关是否正确、DNS是否可用。如果拿不到地址,按顺序查:物理链路通不通、端口VLAN对不对、中继配置有没有、地址池还有没有余量、DHCP服务器有没有收到请求。这个顺序能覆盖九成以上的问题。
4.3 汇聚与接入之间的链路聚合
单条千兆链路在接入设备多的时候会成为瓶颈,这时候用链路聚合把两到四条物理链路绑成一条逻辑链路。配置要点是两端模式一致:都用静态聚合,或者都用动态聚合协议。一端静态一端动态,链路起不来,而且报错信息不明显,很容易被忽略。
聚合组的成员端口属性必须完全一致:速率、双工、VLAN配置、端口类型。成员端口不要跨设备板卡分布,尽量在同一块板卡上,减少单板故障的影响面。聚合之后检查负载分担方式,默认的源目地址哈希在多数场景够用,如果流量集中在少数几对地址之间,可以考虑改成基于源目端口的哈希。
配置完成后做一次拔线测试:拔掉聚合组里的一条线,业务应该不中断,流量自动切到剩余链路;插回去之后链路恢复,聚合组状态正常。这个测试能验证聚合是否真的生效,比看状态灯靠谱得多。
5. 联调验证:ping通只是最低标准
配置写完,状态灯全绿,ping也能通,很多人这时候就认为活干完了。实际上ping通只证明三层可达,离“业务可用”还有距离。真正的联调要验证的是:终端能不能正常访问业务系统、跨网段转发是否正常、冗余切换是否生效、无线覆盖是否达标、高峰时段性能是否够用。
5.1 分段验证法:从单机到跨网段逐层推进
我的验证顺序是从小到大。第一步,单台终端接在接入交换机的某个口上,确认链路协商速率和双工正确、能拿到地址、能ping通网关。第二步,同一VLAN内的两台终端互ping,确认二层转发正常。第三步,跨VLAN访问,确认三层网关和路由配置正确。第四步,访问外部网络或者上级业务系统,确认出口链路和NAT策略正常。
每一步都要记录结果,别跳步。跳步的代价是出问题时不知道是哪一层的问题。有一次跨VLAN不通,直接去查路由表,查了半天发现是接入层端口VLAN划错了,如果按分段法走,第二步就会发现同VLAN都不通。
验证工具上,除ping之外,建议用带源地址的探测方式,指定从某个VLAN的接口发起探测,这样能验证特定网段的转发路径。端口状态、MAC地址表、ARP表、路由表这四个表要会看,它们能告诉你流量走到了哪一步。
5.2 抓包与端口镜像的现场用法
ping不通的时候,抓包是最快的定位手段。配置一个镜像口,把可疑端口的进出流量复制到镜像口,笔记本接上去抓包分析。抓包看三件事:请求有没有发出去、响应有没有回来、回来的响应是不是预期的设备发的。
常见现象对应的问题很明确:只看到请求没有响应,说明对端没收到或者没回;看到请求和响应但源地址不对,说明网络里有地址冲突或者ARP欺骗;看到大量重传和乱序,说明链路质量有问题,回去查线缆和光功率。
镜像口配置要注意方向,入方向、出方向、双向都要看清楚需求。双向镜像流量翻倍,镜像口带宽要够,否则镜像口本身成为瓶颈,抓到的包不完整。抓包文件保存下来,作为故障证据,复盘的时候很有用。
5.3 无线覆盖与漫游的现场实测
无线部分是整个网络里最容易被“看着信号满格”糊弄过去的。信号强度只是指标之一,真正影响体验的是信噪比、信道干扰和漫游切换。实测方法:拿着笔记本或者手机,沿着使用区域走一圈,记录每个位置的信号强度、信噪比、关联的AP和切换次数。
判断标准上,信号强度在负65dBm以内算良好,负75dBm以内可用,低于负80dBm就会出现明显卡顿。信噪比低于20dB说明干扰严重,要检查信道规划,相邻AP不要用相同信道,2.4G频段只考虑1、6、11三个非重叠信道。漫游方面,从一个AP走到另一个AP,切换时间在几百毫秒内属于正常,如果出现秒级中断,检查AP之间的漫游配置和信号重叠区是否合理。
无线AP的上联口也要关注。一个AP带二三十个终端,上联千兆口在高峰期可能跑满,多AP场景考虑上联做聚合或者升级到更高带宽。AP的供电同样要算,PoE++和普通PoE的功率差很多,供电不足表现为AP反复重启或者射频功率自动降低。
6. 现场排障:几类高频故障的完整定位链路
排障能力是这类工作里最值钱的部分。同样的故障现象,有经验的人十分钟定位,没经验的人折腾一整天。差别不在知识量,而在于有没有一套固定的排查顺序,以及知不知道自己下的每一条命令是为了验证什么。下面这几类故障是我这些年遇到频率最高的,把定位链路完整写出来,遇到类似情况可以照着走。
6.1 端口灯不亮与协商失败:从物理层往上查
端口灯不亮,第一步永远是查物理层,别急着登录设备看配置。检查顺序:网线两端是否插到位、水晶头有没有压好、配线架跳线是否对应、对端设备是否上电。用测线仪测一下八芯通断,注意千兆需要八芯全通,百兆只需要1236四芯,有时候四芯能通但千兆协商不上,就是这个问题。
物理层没问题,就看协商结果。登录设备查看端口状态,如果显示down,检查端口有没有被手动关闭;如果显示up但速率是百兆而预期是千兆,检查两端速率双工设置是否一致,一端强制千兆一端自协商,很容易协商成百兆甚至半双工。半双工的典型表现是低速、冲突计数增长、大流量时丢包严重。
光口不亮另有一套查法。先看模块是否被设备识别,再看收发光功率是否在正常范围。收光功率过低说明链路衰减大或者接头脏,收光功率过高(比如短距模块用在很短的距离上)也会误码,需要加衰减。两端模块型号不一致、波长不匹配,也会导致链路起不来,这种情况在混用库存模块时特别常见。
6.2 拿到地址却上不了业务:四个方向的排查
终端能拿到IP地址,说明二层链路和DHCP链路是通的,问题出在三层及以上。按四个方向查。
方向一,网关可达性。ping网关通不通,不通就查终端VLAN和网关接口VLAN是否一致、网关接口是否up。
方向二,DNS解析。ping网关通但打不开网页,先ping一个域名,看能不能解析。解析不了就查DHCP下发的DNS地址对不对、DNS服务器是否可达。
方向三,路由与策略。跨网段访问业务系统不通,查路由表有没有对应条目、有没有访问控制策略拦截。策略拦截的特点是ping可能通但特定端口不通,用端口探测工具验证。
方向四,地址冲突。终端能上网但时断时续,检查是否有其他设备用了同一个地址。查看ARP表里同一个地址对应多个MAC,基本可以确认冲突,找出冲突源隔离掉。
6.3 间歇性丢包与广播风暴:看计数器比看现象可靠
间歇性丢包是最难查的一类。现象是平时好用,高峰期或者随机时间点卡顿。我的做法是先看接口计数器:CRC错误增长说明物理链路有问题,回去查线缆和光模块;冲突计数增长说明有半双工或者共享介质;广播包数量异常高说明有环路或者广播风暴。
环路是接入网里的常客,典型症状是全网变慢、设备CPU飙高、MAC地址表频繁跳变。生成树协议能防环,但前提是配置正确并且没有被绕过。检查生成树状态,看根桥位置是否合理、有没有端口处于阻塞状态、边缘端口是否被误接成了级联口。有人把两个墙插用一根网线连起来,就能制造一个环路,这种事在办公区发生的概率不低。
广播风暴还有一个来源是故障网卡。某台终端的网卡故障,持续发送广播帧,会把接入交换机的广播域打满。定位方法是看哪个端口的广播包速率异常,把这个端口关掉,观察全网是否恢复。关端口这个动作要快,别犹豫,先恢复业务再慢慢查原因。
7. 交付之前的收尾:备份、文档与验收清单
设备调通、业务跑起来,项目看起来结束了,但真正的交付质量体现在收尾动作上。我做过的项目里,返工率最低的那些,共同点都是收尾做得扎实:配置有备份、文档能看懂、验收有记录。反过来,那些半年后没人敢动的网络,往往就是当初“先上线再说”,留下一堆说不清道不明的配置。
7.1 配置文件与版本信息的双备份
配置备份要备份两份,一份存在设备本地(如果支持多配置文件),一份导出到外部存储。导出时机是每次变更之后,不是项目结束时一次性导出。变更后不备份,下次出问题回退时就会退到很久以前的状态,把中间的变更全部丢掉。
备份内容不只是运行配置,还包括:当前固件版本号、模块序列号、License信息、端口与配线架的对应关系。这些东西平时用不上,设备更换或者扩容时就是救命的信息。我习惯在备份文件名里带上日期和设备名,存放路径按项目分目录,避免文件堆在一起找不到。
版本信息单独记一页,写明每台设备当前运行的版本、上次升级时间、升级原因。这个记录能帮你判断某台设备是否落后于其他设备,也能在出现已知问题时快速定位是不是版本导致的。
7.2 交付文档的最小内容集
文档不需要写得多漂亮,但必须包含五样东西。第一是拓扑图,标注设备名称、管理地址、互联端口和链路类型,一张图能让人三分钟看懂网络结构。第二是地址规划表,列出每个VLAN的网段、网关、用途、DHCP范围。第三是设备台账,前面提过的那些字段。第四是配置说明,把非默认配置的意图写清楚,比如“这个ACL是为了限制访客访问内网”,避免后来的人不敢改。第五是应急联系方式与处置流程,出问题时先找谁、按什么步骤处理。
文档的存放位置也要统一,放在内网共享目录里,权限设置成运维团队可读写、其他人可读。别存在个人电脑上,人一走文档就丢了,这种情况太常见。
7.3 验收测试项清单与签字确认
验收不是走形式,是把关键指标逐项测一遍并留下记录。我的清单一般包含:所有终端抽样测试连通性、跨网段访问测试、冗余链路切换测试、断电恢复测试、无线覆盖抽样测试、管理通道可达性测试、配置备份完整性检查。每项写清楚测试方法、预期结果、实际结果、测试人。
冗余切换测试特别值得做。拔掉主链路,看业务中断多久、是否自动恢复;拔掉一台堆叠成员,看剩余设备是否正常;断开一路电源,看设备是否稳定运行。这些测试在业务低峰期做,发现问题还来得及修,等真出故障时才发现冗余不生效,代价就大了。
验收完成后双方签字,把清单归档。这份清单不只是给甲方看的,也是自己团队的护身符——出了问题能对照清单确认是不是验收时就没覆盖到的范围,避免扯皮。
最后分享一个我个人坚持了很多年的小习惯:每次项目收尾,花二十分钟写一份“如果明天我不在,接手的人需要知道什么”的备忘录,把那些没写进正式文档的隐性知识记下来,比如某个端口为什么特殊配置、某台设备的登录方式有差异、哪个环节容易出问题。这份东西不正式,但往往比正式文档更有用。设备会换代、配置会变,能让下一个人少走弯路的,通常就是这些看起来零碎的经验。