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

一句话总结

第一天卡住的原因不是能力，而是权限。事先知道该申请什么，就能省下一天；不知道，就要等上三天。拿到权限后，还要当场确认拿到的是否真是自己申请的。

为什么需要它

第一次拜访客户时，常见的一天是这样的：上午介绍，下午审批笔记本电脑带入，第二天拿到 VPN 账号，第三天才获得服务器访问权限，真正动手已是第四天。可到了第四天打开日志一看，保留期只有两周，客户说的三周前那次故障的日志早已删除；问题找到了，能修的权限却只有只读，只好重新提交变更申请。这些延误大多是“没有提前说明需要什么”造成的。

审批流程大多是串行的：VPN 审批结束后才能提交账号申请，账号下来后才能申请权限。每一步的审批人不同，每位审批人各要花一天。所以要在第一天把所有申请同时提交，让它们并行推进。即使是必须按顺序办理的事项，只要提前告知“下一步要申请什么”，前一步一结束，下一项审批就能立即提交。

要申请什么

申请项	为什么需要	常被遗漏的
网络接入（VPN/专线）	什么都做不了	2FA 设备登记是单独的流程
账号 + 权限	连查询都做不了	读权限和执行权限是分开的
服务器清单·架构图	不知道该看哪里	最新版不在 Wiki，而在某个人的 PC 上
日志位置·保留期	决定调查范围	过了 30 天就没有了，事后才知道
负责人与联络机制	卡住时可以问谁	夜间·周末的联络规则
变更流程	要修改就必不可少	紧急变更也需要审批的情况

此外还有一项最常被遗漏：是否有测试环境，如果有，它和生产环境有什么不同。“一样的”这种回答通常不是事实。数据量、外部对接、证书都不一样。在花一天时间试图于测试环境复现只在生产中出现的问题之前，先拿到差异清单。

如何确认拿到的权限

收到账号开通的通知后，一登录就先看几件事。这些都是只读命令，在陌生服务器上也很安全。

id; groups                 # which groups this account belongs to
sudo -l                    # what may be run as root, without running it
chage -l "$USER"           # account and password expiry dates
timedatectl                # is the clock synced, which time zone

sudo -l 不会真正使用执行权限，只显示列表。如果这里缺少需要的命令，第一天就立即提交追加申请。chage -l 的到期日出乎意料地常常成为障碍。合作方账号往往发放期限很短，调查正进行到一半时账号就被锁了。时钟和时区，在之后对照多台设备的日志时会用到。

日志保留期不要听口头说法，要去配置里确认。文件日志通常由 logrotate 管理。rotate 是删除前保留的份数，要乘以轮转周期（daily、weekly）才是时长。weekly 配 rotate 4，就会保留当前正在写的文件和大约 4 周的旧文件。如果有 maxage，比这个天数更旧的文件会被删除，与份数无关。

grep -nE 'daily|weekly|monthly|rotate|maxage' /etc/logrotate.conf /etc/logrotate.d/*
journalctl --disk-usage
ls -d /var/log/journal     # absent: the journal may live in memory only
journalctl --list-boots | head -3

systemd 日志（journal）默认按容量而不是按时长删除。默认上限是文件系统大小的 10%，最多 4G，时长限制（MaxRetentionSec）默认关闭。因此日志越多的服务器，journal 覆盖的时间就越短。还有一个更重要的陷阱：在默认设置（Storage=auto）下，只有存在 /var/log/journal 目录时才保存到磁盘，否则只放在内存中。这样的服务器一旦重启，之前的 journal 就全部消失。如果 journalctl --list-boots 中只有一次启动记录，就要怀疑是这种情况。

不碰什么

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

动手之前先确认三件事。

能否回滚 —— 必须能用语言说明回滚的方法。
谁会受影响 —— 如果不知道谁在用这台服务器，就还为时过早。
是否必须现在做 —— 在调查阶段就先动手修，会丢失原因。

尤其是第三点。重启会在消除症状的同时抹掉证据。即使需要重启，也要在那之前留下状态——进程列表、内存、打开的文件、最近的日志。只需几秒钟。

date -u +%FT%TZ                          # when this snapshot was taken
ps auxf                                  # process tree
free -m                                  # memory
ss -tanp                                 # sockets and their owners
lsof -p "$PID"                           # files the process holds open
journalctl -u "$UNIT" --since "30 min ago"

先记下时间的原因是，快照一多，就分不清哪个是重启前的。这一份快照日后会占报告的一半。

信任在第一周决定

即使说的话在技术上正确，如果没有愿意倾听的关系，也什么都改变不了。第一周建立信任的方法很简单。

小事快速反馈 —— 一小时的确认结果要比三天的分析先交出去。
不知道就说不知道 —— 把推测当作事实说出来，信任会一次性失去。
在约定的时间汇报 —— 即使没有进展，也要按时说明“暂无”。

在实际项目中

调查中才发现日志只有 20 天 → 如果第一天问了保留期，调查范围就会不同。如果第一天就告诉客户“三周前的故障无法通过日志确认”，就能提前寻找其他证据（监控指标、客户方的记录）。
服务器重启后 journal 一片空白 → 存储方式是内存。如果故障原因就在重启之前，那段记录从一开始就不可能留下。
找到了问题却没有修改权限 → 没有事先确认变更流程的结果。如果第一天就用 sudo -l 看出读权限和执行权限是分开的，就不会卡住。
调查途中账号被锁 → 没有确认合作方账号的到期日。
重启后症状消失，以原因不明结案 → 没有快照就重启的代价。

在后续学习中确认的内容

紧接着的理论课讲如何在变更前画出什么会触及什么。之后的实验中，要亲自找出第一天的申请清单、保留期、上游与下游、共享状态和批处理窗口，并编写回滚脚本和重启前的快照脚本。本节讲到的保留期计算和快照命令会原样用上。