📍 WDQWDWQD987AAAAA:216.73.216.175
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /bb6789bb2d72.html
📄

网站无法访问，内部团队怎样分配责任：一份可执行排查清单

网站无法访问时，内部团队最容易犯的错误是所有人同时动手，结果互相覆盖操作、重复重启服务，反而丢失现场证据。合理的分工原则是：先按“用户侧→网络链路→服务器→应用与数据库→域名与解析”分层，每一层指定唯一负责人，负责人只负责收集本层证据并给出判断，不越层修改。下面这份清单按排查顺序列出每层要查什么、怎么查、结果说明什么，可直接作为值班分工表使用。

第一层：用户侧与访问范围，由客服或运营负责

这一层的目标是确认“无法访问”是普遍现象还是个别现象，避免整个团队为一个人的本地问题加班。

• 要查什么：报障者所在地区、网络运营商、设备类型、浏览器，以及是否所有页面都打不开。
• 怎么查：让报障者用手机流量（关闭Wi-Fi）再访问一次，并截图完整报错页面；同时在公司外部网络用同一路径访问一次做对照。
• 结果说明什么：只有个别人打不开、切换网络后恢复，问题多半在报障者本地网络或DNS缓存，交给其自行清理即可；多地区多运营商同时失败，才升级到下一层。

第二层：域名解析与网络链路，由运维负责

这一层判断请求是否还能找到服务器。域名解析、CDN回源、服务器网络是三个不同环节，不要混为一谈。

• 要查什么：域名当前解析到的IP是否与预期一致；解析记录是否被误改或过期；CDN是否处于异常状态。
• 怎么查：用nslookup 你的域名或dig 你的域名在多个公共DNS上查询，对比返回值；再用ping和traceroute看链路在哪一跳中断。
• 结果说明什么：解析结果为空或指向陌生IP，说明是解析层问题；解析正常但链路在某一跳后全部超时，可能是机房网络或防火墙策略问题。注意：链路超时也可能只是该节点禁用了ICMP，不能仅凭此断定故障点。

第三层：服务器与Web服务，由运维与后端共同确认

这一层要区分“服务器活着但服务没响应”和“服务器本身不可达”，两者的处理人不同。

• 要查什么：服务器能否登录、CPU与内存是否耗尽、磁盘是否写满、Web服务进程是否存活、端口是否在监听。
• 怎么查：登录服务器后执行df -h看磁盘、free -m看内存、systemctl status看服务状态，再用curl -I 本机地址从服务器内部访问一次。
• 结果说明什么：服务器内部能访问、外部不能，问题在防火墙或负载均衡；内部也返回5xx，问题在应用层，转交开发；磁盘写满导致服务无法写日志而崩溃，属于典型的可预防故障，应先清理再扩容。

第四层：应用、数据库与最近变更，由开发负责

多数“突然打不开”来自一次未被评估的变更。开发负责人的首要动作不是改代码，而是确认最近动过什么。

• 要查什么：最近一次发布的时间与内容、数据库连接是否正常、依赖的第三方接口是否可用、错误日志中的首个异常堆栈。
• 怎么查：查看发布记录与配置变更记录；在应用日志中定位第一条报错而非最后一条；用只读账号测试数据库连通性。
• 结果说明什么：报错时间与发布时间吻合，优先回滚验证；数据库连接池耗尽通常表现为大量超时而非立即报错，需要看连接数曲线；第三方接口故障则要确认是否有降级方案。

责任分配的三条硬规则

1. 同一时刻每层只有一个人操作，其他人只读不写，避免证据被覆盖。
2. 每层必须在规定时间内给出结论，例如十五分钟内无法排除本层嫌疑就升级，不允许无限深挖。
3. 恢复服务与定位根因分开进行，先恢复可用性，再在事后复盘中补齐原因分析。

下一步建议：把上面四层整理成一页值班表，写清每层的负责人、检查命令和升级时限，并在下一次发布前做一次模拟演练，确认每个人知道自己该看哪一层、该在什么时候把问题交给下一个人。