网络还是通的，服务器也还在跑，ERP、文件共享、打印、无线这些业务平时都能用，但只要碰到人员变动、设备更换或者一次故障，就会发现很多事情说不清：某个服务器到底依赖什么、某条防火墙策略为什么开着、离职人员的权限有没有收干净、备份到底能不能恢复。

所以我在看 100–300 人规模的企业环境时，一般不会先问交换机是什么型号、服务器有多少核。设备当然重要，但在现网已经运行一段时间的情况下，更应该先把业务、网络、账号、权限和备份这几条线梳理清楚。

一、先把业务和基础设施之间的关系画出来

第一件事不是改配置，而是先确认公司的关键业务都跑在哪里。

例如： ERP/MES、文件服务器、AD/DNS、数据库、虚拟化平台、备份系统，这些系统之间并不是彼此独立的。一个“ERP 打不开”的问题，实际可能出在 DNS、数据库、存储、虚拟化宿主机、防火墙策略，甚至服务账号上。

至少要把下面几件事说清楚：谁在访问谁、走哪一段网络、依赖哪些服务、故障以后先恢复谁。

我通常会先画一张很简单的逻辑关系图，不追求漂亮，能把业务路径说明白就行。等这张图能和现网对得上，再去谈 VLAN、ACL、防火墙策略或者服务器迁移，风险会小很多。

图：企业 IT 基础架构逻辑关系示意

二、网络规划的重点不是 VLAN 数量，而是边界能不能说明白

100–300 人的公司，如果办公电脑、服务器、无线终端、访客设备甚至生产设备长期混在同一个网络里，前期确实省事，后面排错和权限控制会越来越麻烦。

一般会按业务需要划分办公网、服务器区、生产区、访客网，以及必要的管理区域。但我不建议为了“看起来安全”机械地切很多 VLAN。

真正要先确认的是：哪一类终端需要访问哪一类服务器，具体用什么服务。

例如：普通办公终端可能需要访问 AD/DNS、文件服务器和 ERP，但通常没有必要直接访问数据库管理端口、虚拟化管理界面、交换机管理地址或者备份系统后台。

网络分区以后，这些访问关系还要能落到 ACL 或防火墙策略上。设备怎么选是第二步，第一步是每条放行规则都能解释得清楚。

三、服务器在内网，也不应该默认“都能访问”

不少老环境里有一个习惯：只要是内网，就认为风险不大，所以服务器区基本对办公网全开。平时看不出问题，一旦终端中毒、账号被滥用或者有人误操作，影响范围就会放大。

更合适的做法是按照真实业务做最小必要访问。

下面只是一个思路示例，不是让所有企业照着开放：

说明：这里只是访问关系结构示例，不写固定端口。生产策略应以实际业务依赖和日志验证为准。

四、AD 要管的是账号生命周期，不只是统一登录

AD 部署好了，不代表账号管理就做好了。

实际最容易积累问题的是人员变化：入职时不断加权限，调岗时新权限加上了，旧权限却没撤；离职时账号停用了，但共享目录、历史安全组、某些业务系统里的授权还留着。

我更习惯把普通员工账号、管理员账号、服务账号、临时账号和第三方维护账号分开看。员工从入职、调岗到离职，也尽量通过安全组控制权限，而不是每次直接给个人账号加例外。

这样半年以后再回头查一个人为什么能访问某个目录，至少还能从“用户 → 安全组 → 权限”这条关系追下去。

五、文件共享最怕长期直接给个人账号授权

Windows 文件服务器刚开始用的时候，最省事的做法就是“谁需要就给谁”。人少时问题不大，人一多，目录 ACL 很快会堆出一长串个人账号。

这种环境一旦人员调岗或者部门调整，权限就很难彻底回收。

我的处理习惯是先不急着重构，先把现有 ACL 导出来，找出直接授权给个人账号的核心目录，再按部门、岗位或业务角色设计安全组。随后选一个低风险目录做小范围验证，确认读、写、修改、删除都符合预期，再逐步迁移。

共享权限和 NTFS 权限也不要两边都做得特别复杂。两层都堆大量例外，过一段时间以后连维护的人自己都容易判断错。

六、备份任务显示成功，只能说明“备份跑完了”

这件事我一直比较看重。

备份软件每天显示 Success，并不能直接等于业务一定能恢复。真正恢复时，经常还会碰到数据库一致性、服务账号、证书、DNS、网络策略或者应用依赖的问题。

所以备份至少要回答四个问题：备了什么、能恢复到哪个时间点、实际需要多久、谁能够完成恢复。

如果这四个问题没人能回答清楚，那备份即使每天都是绿色，也不能算真正建立了恢复能力。

七、恢复验证不用一开始就动最重要的生产系统

可以先从风险小的对象开始。比如恢复一个历史文件、恢复一台测试虚拟机、恢复一份配置，或者在隔离环境里验证一个非生产数据库。

关键不是看到“恢复任务完成”，而是确认恢复出来的对象真的能打开、能启动、能正常提供服务。

同时把恢复点、开始时间、完成时间、实际耗时、所需账号、网络依赖和遇到的问题记下来。真遇到故障时，这些记录比单纯的备份任务截图有用得多。

八、运维文档不用写得很厚，但必须和现网对得上

对于这个规模的企业，我认为至少要长期维护几样东西：资产清单、逻辑拓扑、IP/VLAN 规划、关键访问关系、核心设备配置备份、管理员责任人，以及关键业务依赖。

文档最常见的问题不是“没有”，而是有一份几年前的版本。现网改了几轮，文档完全没跟上，最后大家还是靠记忆。

所以文档不用追求几十页，重点是能用于接管和排错。比如换一个 IT 人员以后，他能不能根据这些资料找到核心设备、知道哪些业务跑在哪、出故障以后先看哪里。

另外，高权限密码不建议直接写进普通文档，但账号归属、责任人和应急恢复方式必须明确。

九、现网已经比较乱时，不要同时把所有东西都改掉

有些环境一盘点，网络、AD、文件权限、备份、服务器都存在历史问题。这时候最容易出现的想法是“一次全部重做”。

设计方案可以一次规划完整，但生产改造最好拆开。

我一般先做只读盘点，把资产、拓扑、IP、账号、权限、备份和业务依赖先留档；然后先处理明显风险，比如 IP 冲突、磁盘容量、硬件告警、无人管理的高权限账号、关键系统没有可验证的恢复能力。

网络分区、权限重构、服务器迁移这些影响面比较大的事情，再按照维护窗口分批做。每次改动都要知道改了什么、影响谁、怎么验证，出现异常时怎么退回来。

这样做看起来慢一点，但生产环境里通常更稳。

十、怎么判断这套环境已经开始“可维护”了

我通常不会用“买了多少设备”来判断基础架构做得好不好，反而会随机抽几个日常场景。

新员工入职，账号、文件权限和业务权限能不能按流程开通；员工调岗以后，旧权限能不能撤掉；员工离职后，账号和访问权限能不能完整回收。

再看故障场景：服务器出问题时，能不能很快找到业务依赖、备份位置和恢复路径；网络异常时，能不能按终端、接入、核心、安全边界、DNS、服务器、应用这一条链路往下查，而不是先重启一圈设备再说。

如果这些事情都能说得清、查得到、有人负责，基础架构才算真正进入了可维护状态。

100–300 人企业的 IT 基础架构不一定要做得很复杂。真正重要的是网络边界清楚、账号有人管、权限能解释、备份能恢复、配置找得到，做了变更以后也知道怎么验证和回退。

设备以后会换，系统版本也会升级，但这些基础关系只要一直是清楚的，后续扩容、迁移和排错都会轻松很多。

我自己更看重的是一套环境能不能做到三件事：别人可以接手，出了问题可以定位，调整失败以后可以退回来。能做到这几点，才是真正能长期维护的企业基础架构。