到了客户现场，先要申请的东西

一句话总结

第一天受阻的原因不是能力，而是权限。事先知道该申请什么，就能节省一天；不知道，就要等待三天。

为什么需要它

第一次拜访客户时，常见的一天是这样度过的：上午做介绍，下午审批携带笔记本电脑入场；第二天申请 VPN 账户，再下一天申请服务器访问权限。真正开始动手已经是第四天。这三天大多是因为没有提前说明需要什么而浪费的。

审批体系通常是串行的。VPN 审批结束后才能申请账户，账户开通后才能申请权限。第一天就应同时提交所有申请，让流程并行推进。

应申请什么

申请项	为什么需要	经常遗漏的事项
网络访问（VPN/专线）	否则什么也做不了	2FA 设备注册可能是另一套流程
账户与权限	连查询都无法进行	读取权限与执行权限彼此分离
服务器清单与架构图	不知道应查看哪里	最新版本可能不在 wiki，而在某个人的电脑里
日志位置与保留期限	用来确定调查范围	事后才发现超过 30 天的日志已不存在
负责人和联系机制	受阻时需要询问对象	夜间与周末的联系规则
变更流程	要修复问题就必不可少	紧急变更有时也需要审批

还有一项最常被遗漏：是否存在测试环境；如果存在，它与生产环境有什么不同。“完全相同”通常并不属实。数据量、外部集成和证书都会有所差异。

哪些东西不要碰

第一周的基本姿态是只读。这不是胆小，而是理性计算，因为在陌生系统中无法预测一次变更的影响范围。

动手之前，要确认三件事。

1. 能否回退——必须能够用语言说明如何恢复。
2. 会影响谁——如果还不知道谁在使用这台服务器，就不该动手。
3. 是否必须现在做——在调查阶段先急着修复，会丢失问题原因。

第三点尤其重要。重启会在消除症状的同时清除证据。即使必须重启，也应事先留下状态记录：进程列表、内存、打开的文件和近期日志。这一份快照日后可能构成报告的一半。

信任在第一周决定

即使技术判断正确，如果没有愿意听取意见的关系，也无法改变任何事情。第一周建立信任的方法很简单。

• 尽快交付小成果——相比三天后才完成的分析，应先提交一小时即可得到的确认结果。
• 不知道就明确说不知道——把猜测当成事实，只需一次就会失去信任。
• 在约定时间报告——即使没有进展，也要按时说明“尚无进展”。

实际工作中的表现

• 调查过程中才发现日志只保留了 20 天 → 如果第一天就询问保留期限，调查范围本可以采用不同方案。
• 找到了问题却没有修复权限 → 没有提前确认变更流程的结果。
• 重启后症状消失，最终以原因不明结案 → 没有先制作快照的代价。

后续学习将检查什么

接下来将观察第一天应取得的信息——如访问方式、保留期限和变更审批——如何改变后续对影响范围的判断，并在下一篇理论中扩展变更前应确认的对象。