这类环境我接触得比较多。公司从几十个人发展到一两百人以后IT 往往不是突然“坏掉”而是慢慢变得越来越难维护。网络还是通的服务器也还在跑ERP、文件共享、打印、无线这些业务平时都能用但只要碰到人员变动、设备更换或者一次故障就会发现很多事情说不清某个服务器到底依赖什么、某条防火墙策略为什么开着、离职人员的权限有没有收干净、备份到底能不能恢复。所以我在看 100–300 人规模的企业环境时一般不会先问交换机是什么型号、服务器有多少核。设备当然重要但在现网已经运行一段时间的情况下更应该先把业务、网络、账号、权限和备份这几条线梳理清楚。一、先把业务和基础设施之间的关系画出来第一件事不是改配置而是先确认公司的关键业务都跑在哪里。例如 ERP/MES、文件服务器、AD/DNS、数据库、虚拟化平台、备份系统这些系统之间并不是彼此独立的。一个“ERP 打不开”的问题实际可能出在 DNS、数据库、存储、虚拟化宿主机、防火墙策略甚至服务账号上。至少要把下面几件事说清楚谁在访问谁、走哪一段网络、依赖哪些服务、故障以后先恢复谁。我通常会先画一张很简单的逻辑关系图不追求漂亮能把业务路径说明白就行。等这张图能和现网对得上再去谈 VLAN、ACL、防火墙策略或者服务器迁移风险会小很多。图企业 IT 基础架构逻辑关系示意二、网络规划的重点不是 VLAN 数量而是边界能不能说明白100–300 人的公司如果办公电脑、服务器、无线终端、访客设备甚至生产设备长期混在同一个网络里前期确实省事后面排错和权限控制会越来越麻烦。一般会按业务需要划分办公网、服务器区、生产区、访客网以及必要的管理区域。但我不建议为了“看起来安全”机械地切很多 VLAN。真正要先确认的是哪一类终端需要访问哪一类服务器具体用什么服务。例如普通办公终端可能需要访问 AD/DNS、文件服务器和 ERP但通常没有必要直接访问数据库管理端口、虚拟化管理界面、交换机管理地址或者备份系统后台。网络分区以后这些访问关系还要能落到 ACL 或防火墙策略上。设备怎么选是第二步第一步是每条放行规则都能解释得清楚。三、服务器在内网也不应该默认“都能访问”不少老环境里有一个习惯只要是内网就认为风险不大所以服务器区基本对办公网全开。平时看不出问题一旦终端中毒、账号被滥用或者有人误操作影响范围就会放大。更合适的做法是按照真实业务做最小必要访问。下面只是一个思路示例不是让所有企业照着开放来源目标用途处理思路办公终端AD / DNS域认证、解析按实际域服务需求放行办公终端文件服务器文件共享仅开放业务需要的文件服务业务终端ERP / MES业务访问按应用实际端口放行管理终端服务器/网络设备运维管理限定管理来源与权限说明这里只是访问关系结构示例不写固定端口。生产策略应以实际业务依赖和日志验证为准。四、AD 要管的是账号生命周期不只是统一登录AD 部署好了不代表账号管理就做好了。实际最容易积累问题的是人员变化入职时不断加权限调岗时新权限加上了旧权限却没撤离职时账号停用了但共享目录、历史安全组、某些业务系统里的授权还留着。我更习惯把普通员工账号、管理员账号、服务账号、临时账号和第三方维护账号分开看。员工从入职、调岗到离职也尽量通过安全组控制权限而不是每次直接给个人账号加例外。这样半年以后再回头查一个人为什么能访问某个目录至少还能从“用户 → 安全组 → 权限”这条关系追下去。五、文件共享最怕长期直接给个人账号授权Windows 文件服务器刚开始用的时候最省事的做法就是“谁需要就给谁”。人少时问题不大人一多目录 ACL 很快会堆出一长串个人账号。这种环境一旦人员调岗或者部门调整权限就很难彻底回收。我的处理习惯是先不急着重构先把现有 ACL 导出来找出直接授权给个人账号的核心目录再按部门、岗位或业务角色设计安全组。随后选一个低风险目录做小范围验证确认读、写、修改、删除都符合预期再逐步迁移。共享权限和 NTFS 权限也不要两边都做得特别复杂。两层都堆大量例外过一段时间以后连维护的人自己都容易判断错。六、备份任务显示成功只能说明“备份跑完了”这件事我一直比较看重。备份软件每天显示 Success并不能直接等于业务一定能恢复。真正恢复时经常还会碰到数据库一致性、服务账号、证书、DNS、网络策略或者应用依赖的问题。所以备份至少要回答四个问题备了什么、能恢复到哪个时间点、实际需要多久、谁能够完成恢复。如果这四个问题没人能回答清楚那备份即使每天都是绿色也不能算真正建立了恢复能力。七、恢复验证不用一开始就动最重要的生产系统可以先从风险小的对象开始。比如恢复一个历史文件、恢复一台测试虚拟机、恢复一份配置或者在隔离环境里验证一个非生产数据库。关键不是看到“恢复任务完成”而是确认恢复出来的对象真的能打开、能启动、能正常提供服务。同时把恢复点、开始时间、完成时间、实际耗时、所需账号、网络依赖和遇到的问题记下来。真遇到故障时这些记录比单纯的备份任务截图有用得多。八、运维文档不用写得很厚但必须和现网对得上对于这个规模的企业我认为至少要长期维护几样东西资产清单、逻辑拓扑、IP/VLAN 规划、关键访问关系、核心设备配置备份、管理员责任人以及关键业务依赖。文档最常见的问题不是“没有”而是有一份几年前的版本。现网改了几轮文档完全没跟上最后大家还是靠记忆。所以文档不用追求几十页重点是能用于接管和排错。比如换一个 IT 人员以后他能不能根据这些资料找到核心设备、知道哪些业务跑在哪、出故障以后先看哪里。另外高权限密码不建议直接写进普通文档但账号归属、责任人和应急恢复方式必须明确。九、现网已经比较乱时不要同时把所有东西都改掉有些环境一盘点网络、AD、文件权限、备份、服务器都存在历史问题。这时候最容易出现的想法是“一次全部重做”。设计方案可以一次规划完整但生产改造最好拆开。我一般先做只读盘点把资产、拓扑、IP、账号、权限、备份和业务依赖先留档然后先处理明显风险比如 IP 冲突、磁盘容量、硬件告警、无人管理的高权限账号、关键系统没有可验证的恢复能力。网络分区、权限重构、服务器迁移这些影响面比较大的事情再按照维护窗口分批做。每次改动都要知道改了什么、影响谁、怎么验证出现异常时怎么退回来。这样做看起来慢一点但生产环境里通常更稳。十、怎么判断这套环境已经开始“可维护”了我通常不会用“买了多少设备”来判断基础架构做得好不好反而会随机抽几个日常场景。新员工入职账号、文件权限和业务权限能不能按流程开通员工调岗以后旧权限能不能撤掉员工离职后账号和访问权限能不能完整回收。再看故障场景服务器出问题时能不能很快找到业务依赖、备份位置和恢复路径网络异常时能不能按终端、接入、核心、安全边界、DNS、服务器、应用这一条链路往下查而不是先重启一圈设备再说。如果这些事情都能说得清、查得到、有人负责基础架构才算真正进入了可维护状态。100–300 人企业的 IT 基础架构不一定要做得很复杂。真正重要的是网络边界清楚、账号有人管、权限能解释、备份能恢复、配置找得到做了变更以后也知道怎么验证和回退。设备以后会换系统版本也会升级但这些基础关系只要一直是清楚的后续扩容、迁移和排错都会轻松很多。我自己更看重的是一套环境能不能做到三件事别人可以接手出了问题可以定位调整失败以后可以退回来。能做到这几点才是真正能长期维护的企业基础架构。