以下为真实案例，用于复盘排障方法。
周一早上，服务台收到一张工单：用户能打开公网网站，也能收发邮件，但内部采购系统提示“找不到服务器”。同办公室其他人都正常。很多人看到“系统打不开”，第一反应是服务器或网络故障。我更关注三个条件：公网正常、只影响一个内部域名、只影响一台电脑。先做最小验证：通过服务器 IP 可以打开页面；通过内部域名无法访问；ipconfig /all 显示 IP 和网关正常；故障电脑的 DNS 与正常电脑不同；指定企业内部 DNS 查询时，域名立即解析成功。根因是一款第三方 VPN 卸载后残留了手工 DNS 配置。把网卡恢复为 DHCP 下发的 DNS、更新租约并清理客户端缓存后，业务恢复。但真正值得复盘的不是“改回 DNS”这一步，而是为什么这个问题能进入生产办公环境。我把原因分成三层：直接原因是网卡指向错误 DNS；触发原因是 VPN 修改配置后未恢复；管理原因是终端没有网络基线检查，软件卸载后也没有健康验证。后续动作包括：给服务台增加网络信息采集脚本；对非批准 DNS 做基线告警；把 VPN 安装、升级和卸载纳入标准变更；把“网络不通”细分为 IP、网关、DNS、端口和认证问题。运维效率并不只取决于你会多少命令。更关键的是能否迅速缩小故障域，以及能否把一张工单转化成下一次更早发现问题的机制。这类问题也提醒管理者：服务台数据不能只统计“处理了多少单”，还要观察同类故障是否重复、首次派单是否准确、修复后有没有形成基线。如果相同问题不断出现，再快的个人处理速度也只是重复劳动。把排障证据结构化，才能让团队整体能力持续增长。#IT运维 #桌面运维 #网络排障 #DNS #故障复盘 #IT管理
发布于 广东
分享
评论
1
未登录
友善发言
评论
加载中
