用户说不清、群里一直催、手里又没有完整权限，现场问诊该怎么继续？
先抓住一次具体的失败，再把排查往前推。
此前那篇《财务说“系统卡了”……》里，我们写了三个问题：
谁受影响？
卡在哪一步？
什么时候开始？
评论区一条高赞留言，把现场拉回来了：
这个提醒很实在。
让一个正等着交报销单的人判断故障范围，确实不容易。你问得越像排障流程，他越可能觉得你在拖时间。
三个问题还要问，但问法得跟着现场变。
01
PART
他回答“不知道”，就先接住他知道的那一小段
下面用一个接报情景说明。
用户发来一句：
“系统又卡了，领导等着呢。”
可以先回：
“收到。我先看你现在卡住的这一步。方便的话先别反复点提交，我确认一下有没有已经生成的记录。”
然后，把“具体哪里卡”换成一个更容易回答的问题：
“现在屏幕上是哪一页？是点上传没有反应，还是已经显示报错？”
不让他解释协议，也不要求他先调查整个办公室。他能告诉你的，通常就是眼前这个画面。
如果能到场，就边到场边了解；能在授权范围内远程协助，就请他按刚才的步骤演示一次。
涉及财务单据时，让他先隐去敏感内容，别把真实票据截图扔进大群。
一次复现时，先记下：
发生时间：最近一次失败是在几点。
具体动作：点了什么、传了什么、停在哪一步。
实际结果：一直转圈、返回报错，还是没有反应。
有报错就记原文，别只记“网络异常”四个字。
这些信息，已经能帮你找到第一条可核对的线索。
02
PART
“谁受影响”，这件事可以由网工来补
“只有你们卡，还是其他部门也卡？”
这句话在纸面上很好，现实里用户可能从没问过其他部门。
可以换成：
“你旁边有人正在做同一个操作吗？方便的话，我们找一台有权限的电脑，用不含敏感信息的测试文件试一次。”
如果没有，就先记：
影响范围待确认。
继续处理眼前的问题，不要因为范围没问全，就把接报卡住。
做对照时，尽量一次只换一个条件。例如：
同一个账号、同一台电脑，先后比较两个业务入口。
同一业务，在两台终端上比较。
同一终端，比较两种经过批准的接入方式。
先确认测试是否被允许，再记录账号、文件和访问方式的差别。
需要注意：
另一台电脑成功，只能说明存在值得追的差异，不能直接证明服务器没有问题。
账号权限、后端节点、浏览器状态或访问路径，都可能不同。
对照的用处，是缩小下一步该查什么。
03
PART
“上次是上个月”，也不是一句没用的回答
你问什么时候开始，他说：
“上次用还好好的。”
别急着追一个他记不住的准确时间。
可以换成：
“上次成功时，是同一台电脑、同一个入口、做同一个操作吗？今天第一次失败大约在几点？”
“上个月正常”和“今天9点12分失败”，中间虽然有一大段空白，也能先形成时间范围。
接下来，由运维侧核查相关变化：
安全策略有没有调整？
业务系统有没有发布？
证书、代理有没有变化？
接入方式或访问入口有没有改变？
有变更记录就核对时间，没有记录就明确写“未确认”。
现场容易吃亏的，是刚听到“上周五改过策略”，就马上认定是那条策略。
时间对得上只是线索，还得看失败请求有没有经过它。
04
PART
没有服务器权限，先别把自己逼成全能运维
有读者问：
“哪来两端同时抓包的条件？”
很多现场确实没有。
先留下终端侧能确认的信息
即使暂时拿不到服务器权限，也可以先记录：
失败时间和操作步骤。
错误提示原文。
终端所在网段和业务入口。
已经完成的对照，以及测试结果。
有权限且熟悉工具时，再看浏览器中对应请求的状态和耗时。
不要把带令牌、账号或业务数据的完整记录发进公共群。
向对应负责人提出具体请求
网工在自己的权限内核查链路、会话、策略和日志。
需要服务器日志时，可以向应用负责人提出一个能执行的请求：
“请协助核对9点12分前后，这次上传是否到达，以及对应的返回状态。”
这样的请求，比“你们查一下服务器”更容易接得住。
如果没人能协调，就由故障负责人安排协同。
让问题进入有人接手的流程，不等于把所有系统都揽到自己身上。
05
PART
群里怎么回，才能让大家知道事情在推进？
现场还没有根因，群里已经第三次问进展。
可以这样回：
已接手。目前确认财务一台终端在上传测试文件时失败，登录和查询可以完成，其他用户范围还在确认。
正在核对本次请求与相关变更，已请应用同事协查。9点30分前更新进展，有新的影响会提前说明。
这段话不需要先宣布谁有责任。
它交代了大家此时最需要知道的信息：
已经确认了什么。
接下来由谁查什么。
什么时候再更新。
更新时间要按现场能力承诺，到点即使没定位，也要更新。
“预计更新进展”，不要写成“预计修好”。
涉及大面积或关键业务中断时，直接按故障等级启动响应。
到场、升级和信息收集可以并行，不必在聊天窗口里凑齐所有答案。
06
PART
留一张接报单，下次少从头问一遍
下次可以把这张表放进工单里：
| 记录项目 | 怎么写 |
|---|---|
| 受阻动作 | 登录、查询、提交、上传，具体卡在哪一步 |
| 失败时间 | 最近一次失败时间，以及报错原文 |
| 影响范围 | 已确认哪些终端或用户受影响，未知部分单独标出 |
| 对照结果 | 改变了什么条件，结果有什么差别 |
| 当前进展 | 已确认什么，正在核查什么 |
| 协同安排 | 谁接下一步，下次什么时候更新 |
先填得到的内容，空着的写“待确认”。
别为了把表填满，让用户重复提交，或者等待已经影响恢复的材料。
网工需要判断，也需要现场条件。
用户说不清时，把问题拆成他能配合的一步，剩下的调查接过来做，往往更容易推进。
· · ·
你遇到过最难接的一句故障描述是什么？
欢迎说说现象，请隐去公司和个人信息。
SPOTO 思博网络是全球 IT 人才在线教育品牌，深耕 ICT 职业教育二十余年。华为授权培训合作伙伴。课程涵盖思科、华为认证及云计算、Linux、PMP、软考、CISP 等方向，已服务全球 152 个国家和地区的 55 万余名学员。
学习改变命运，知识成就未来。如果你想在 IT 路上走得更远，SPOTO 思博愿做你的同行者。想在 IT 领域进阶，欢迎与我们同行。