服务器重启后 IP 没了:一次 Linux 网络运行时状态与持久化配置的复盘

2023 年,一次机房断电检修后,我把一台服务器彻底"弄丢"了——它还在机架上,电也通了,可整个网络,谁都连不上它。事情要从一个月前说起。那台服务器要配一个固定内网 IP,我登上去,熟练地敲下 ip addr add 192.168.1.50/24 dev eth0,又 ip route add 配了网关。敲完一 ping,通了;服务起来,跑得稳稳的。我心满意足:IP 配好了。这之后整整一个月,这台机器风平浪静,服务一直在线,我早把这事忘了。直到那天机房断电检修,所有机器统一重启。检修结束,别的机器陆陆续续都回来了,唯独这一台——ping 不通,SSH 连不上,像从网络上凭空蒸发了。我以为是硬件出问题了,跑去机房接显示器看。一开机,系统好好的,登录也正常。我 ip addr 一看,eth0 那一行,干干净净——【没有 IP】。我一个月前亲手配上去的那个 192.168.1.50,不见了,一点痕迹都没有。我当时脑子是懵的:我明明配过啊?我亲眼看着它 ping 通的,它稳稳跑了一个月——一个"配好了"的东西,怎么会因为重启一下,就【什么都不剩】?我盯着那行空荡荡的 eth0,心里第一次冒出一个我从没想过的问题:我那天敲下的 ip addr add,它把那个 IP,到底"写"到哪里去了?这件事逼着我把"运行时状态"和"持久化配置"的区别、Linux 开机时谁来配网络、ifcfg 与 nmcli 这一整套彻底理清了。本文复盘这次实战。

问题背景

环境:CentOS 7,一台内网服务器,要配固定 IP
事故现象:
- 一个月前用 ip addr add 配好了 IP,ping 通,服务正常
- ★ 机房断电检修、统一重启之后
- ★ 这台机器彻底失联:ping 不通、SSH 连不上
- 接显示器进去看:eth0 上【没有任何 IP】

现场排查:
# 1. 接显示器进系统,看网卡 —— IP 没了
$ ip addr show eth0
2: eth0: <BROADCAST,MULTICAST,UP> ...
    link/ether 52:54:00:ab:cd:ef ...
    # ★ 注意:这里【没有】inet 192.168.1.50 那一行!
    #   IP 凭空消失了。

# 2. 我一个月前,就是这么配的(回忆)
$ ip addr add 192.168.1.50/24 dev eth0    # ★ 当时这么敲的
$ ip route add default via 192.168.1.1

# 3. ★ 关键:去看网卡的【配置文件】
$ cat /etc/sysconfig/network-scripts/ifcfg-eth0
DEVICE=eth0
BOOTPROTO=dhcp                            # ★★ 看这里!
ONBOOT=yes
# ★ 配置文件里写的是 BOOTPROTO=dhcp —— 开机时
#   去问 DHCP 要地址。而这个内网没有 DHCP 服务器,
#   要不到 -> eth0 开机后就是【没有 IP】。
# ★ 配置文件里【根本没有】192.168.1.50 这个地址!

# 4. ★ 手动再配一次 —— 立刻就通
$ ip addr add 192.168.1.50/24 dev eth0
$ ip route add default via 192.168.1.1
$ ping 192.168.1.1
64 bytes from 192.168.1.1: ...            # ★ 立刻又通了

# 5. ★ 但只要再重启,IP 又会没 —— 因为配置文件没改

根因(后来想清楚的):
1. ★ ip addr add 这条命令,改的是【当前正在运行的
   内核】里的网络状态 —— 它是【运行时(runtime)】
   的修改,只活在【内存】里。
2. ★ 它【不会】去写任何磁盘上的配置文件。一个字
   都不写。
3. ★ 机器一重启,内存全部清空 —— 我那天在内存里
   加的那个 IP,跟着一起没了,不留任何痕迹。
4. ★ 开机后,系统的网络服务,会去读【磁盘上的
   配置文件】(ifcfg-eth0)来配网卡。而那个文件
   里写的是 BOOTPROTO=dhcp,从没改过。
5. ★ 于是开机后 eth0 按文件说的去 DHCP 要地址,
   要不到,就一直空着 —— 机器失联。
6. 真正的错:我做了【运行时修改】,却以为自己做了
   【持久化配置】。它能稳跑一个月,只是因为这一个
   月里,机器恰好没重启过 —— 内存没被清而已。
不是 IP 配丢了,是它从一开始,就只配在了内存里,
从来没有落到磁盘上。重启清空内存,它自然就没了。

修复 1:运行时状态 vs 持久化配置——两层完全不同的东西

# === ★ 本文最核心的一个区分:这是两层东西 ===

# === ★ 一台运行中的 Linux,"配置"分两层 ===
# 第一层:★【运行时状态(runtime state)】
#   - 这是【当前这个正在运行的系统】,此刻的状态。
#   - 它活在【内存】里。
#   - 网卡上有哪些 IP、有哪些路由、防火墙现在拦
#     什么、挂载了哪些盘…… 这些"此刻的事实",
#     都属于运行时状态。
# 第二层:★【持久化配置(persistent config)】
#   - 这是写在【磁盘文件】里的配置。
#   - 它的作用是:★ 告诉系统"【下次开机】时,
#     应该把自己配成什么样"。

# === ★ 这两层,平时是分开的、独立的 ===
# ★ 关键认知:改了其中一层,【不会自动同步】到
#   另一层。它们是两份独立的东西。
# - 你改"运行时状态" -> 当前立刻生效,但【磁盘
#   文件原封不动】。
# - 你改"持久化配置" -> 磁盘文件变了,但【当前
#   运行的系统毫不知情】,要等下次开机、或手动
#   重新加载,才生效。

# === ★ 一次重启,会发生什么 ===
# 重启 = 内存被彻底清空,系统从零开始。
#  1. ★ 运行时状态:全部丢失,一干二净。我在内存
#     里做的任何修改,都【不复存在】。
#  2. ★ 系统重新启动时,各种服务会去【读磁盘上的
#     持久化配置文件】,照着文件,把系统【重新
#     配置一遍】。
# ★ 所以,一台机器重启后长什么样,★【完全由磁盘
#   配置文件决定】,和重启前你在内存里做过什么,
#   没有半点关系。

# === ★ 回到本文:我犯的到底是什么错 ===
# ip addr add 192.168.1.50 —— 这是【运行时】修改。
#   它只动了内存里的状态。
# ★ 我以为我"配置好了 IP"。可我做的,是"运行时
#   修改",不是"持久化配置"。
# ★ 它能撑一个月,纯粹是因为这一个月内存一直没被
#   清空(没重启)。这是【侥幸】,不是【配好了】。
#   重启一来,内存一清,真相立刻暴露。

# === ★ 一个判断:你的修改,"重启后还在吗" ===
# 区分"运行时"还是"持久化",就问一个问题:
#   ★【如果现在重启,我这个修改还在不在?】
#  - 还在 -> 它是持久化的(写进了配置文件)。
#  - 没了 -> 它只是运行时的(只在内存里)。
# ★ 真正"配好一件事",意味着这两层【都】到位:
#   运行时生效了(现在能用)+ 持久化了(重启还在)。

# === 认知 ===
# ★ Linux 的配置分两层:运行时状态(在内存,当前
#   生效)和持久化配置(在磁盘文件,决定下次开机
#   的样子)。改一层不会自动同步到另一层。重启会
#   清空运行时状态、并完全照磁盘配置文件重建系统。
#   "配好了"必须两层都到位。

修复 2:开机时,到底是谁在配置网络

# === ★ 既然重启照配置文件来,那是谁在读、在配 ===

# === ★ 开机配网络的"那个角色" ===
# 系统启动时,有一个【网络管理服务】被拉起来,由
#   它负责:读取网卡的持久化配置文件,然后照着
#   把每一张网卡配好(设 IP、设路由、设 DNS)。
# ★ CentOS 7 / RHEL 7 上,这个角色通常是
#   ★ NetworkManager(也可能是老式的 network 服务)。
$ systemctl status NetworkManager
● NetworkManager.service - Network Manager
   Active: active (running) ...            # ★ 它在跑
$ systemctl status network                 # 老式服务(可能也在)

# === ★ 它读的配置文件在哪 ===
# CentOS 7 上,每张网卡一个配置文件,放在:
$ ls /etc/sysconfig/network-scripts/
ifcfg-eth0   ifcfg-lo   ...
# ★ ifcfg-eth0 就是 eth0 这张网卡的持久化配置。
#   开机时,网络服务就读它,照它配 eth0。

# === ★ 所以,"开机网络长什么样"的因果链是 ===
# 开机
#  -> NetworkManager 启动
#  -> 读 /etc/sysconfig/network-scripts/ifcfg-eth0
#  -> 照文件内容配置 eth0
#  -> eth0 最终的 IP / 路由,★ 完全等于文件说的。
# ★ 本文的文件写着 BOOTPROTO=dhcp,内网又没 DHCP,
#   于是这条链走下来,eth0 就是没 IP。

# === ★ 为什么 ip 命令的修改"进不了"这条链 ===
# ip addr add 改的是【内核当前的运行时状态】。它
#   ★【不经过】NetworkManager,也【不写】ifcfg
#   文件。
# ★ 所以下次开机,NetworkManager 读 ifcfg 文件时,
#   根本不知道我曾经手动加过一个 IP —— 那个修改,
#   从来没进入过"开机会被读取"的那份配置。
# ★ 这就是运行时修改"重启不保留"的根本机制:它
#   压根没出现在开机要读的那个文件里。

# === ★ 一个要注意的坑:别让两个服务打架 ===
# ★ NetworkManager 和老式 network 服务,职责重叠。
#   两个【同时启用】,可能互相覆盖配置,引发诡异
#   问题。一台机器上,选一个用,把另一个停掉/禁用:
$ systemctl disable network                 # 例:统一用 NM
# ★ 排查网络配置怪事时,先确认是谁在管网络、有没有
#   俩服务在抢。

# === 认知 ===
# ★ 开机时,由 NetworkManager(或老式 network 服务)
#   读取 /etc/sysconfig/network-scripts/ifcfg-* 这些
#   配置文件,照着把网卡配好。ip 命令的运行时修改
#   既不经过这个服务、也不写这些文件,所以开机这
#   条链里根本看不到它 —— 这就是它重启不保留的
#   原因。

修复 3:ifcfg 文件——把网络配置"写到磁盘上"

# === ★ 正道之一:直接写 ifcfg 配置文件 ===

# === ★ 看懂一个 ifcfg 文件 ===
$ cat /etc/sysconfig/network-scripts/ifcfg-eth0
# 出问题时它长这样:
DEVICE=eth0
BOOTPROTO=dhcp            # ★ 开机怎么拿 IP:dhcp=问DHCP要
ONBOOT=yes                # ★ 开机是否启用这张网卡
# ★ BOOTPROTO=dhcp + 没有 DHCP 服务器 = 开机拿不到 IP。

# === ★ 改成"静态 IP"的正确写法 ===
$ vi /etc/sysconfig/network-scripts/ifcfg-eth0
# 改成:
DEVICE=eth0
ONBOOT=yes                # ★ 开机就启用
BOOTPROTO=static          # ★★ 改成 static:用下面写死的地址
IPADDR=192.168.1.50       # ★ 静态 IP
NETMASK=255.255.255.0     # ★ 子网掩码(或用 PREFIX=24)
GATEWAY=192.168.1.1       # ★ 默认网关
DNS1=8.8.8.8              # ★ DNS 服务器
# ★ 逐项说明:
#  - BOOTPROTO=static -> 不问 DHCP,用文件里写的地址。
#  - IPADDR / NETMASK / GATEWAY -> 把那天我用 ip
#    命令在内存里配的东西,这次【写进文件】。
#  - ONBOOT=yes -> 没有它,开机根本不启用这张卡。

# === ★ 改完文件,要让它生效 ===
# ★ 注意:改完 ifcfg 文件,当前运行的系统【还不
#   知道】—— 文件是改了,但运行时状态没变(还记得
#   "改一层不同步另一层"吗)。要让它生效:
$ nmcli connection reload         # 让 NM 重新读配置文件
$ nmcli connection up eth0        # 或重启这张网卡
# 老式 network 服务则是:
$ systemctl restart network
# ★ 这一步做完,"运行时"和"持久化"两层就【对齐】了:
#   现在能用 + 重启也还在。

# === ★ 验证:这次是真的配好了 ===
$ ip addr show eth0 | grep inet
    inet 192.168.1.50/24 ...      # ★ 运行时:有了
$ grep IPADDR /etc/sysconfig/network-scripts/ifcfg-eth0
IPADDR=192.168.1.50               # ★ 持久化:也有了
# ★ 两层都到位 —— 这才叫"IP 配好了"。

# === ★ 改网络配置,务必留一条"退路" ===
# ★ 远程改网卡配置是【高危操作】:配错一个字,
#   network 一重启,你自己的 SSH 就断了,而且
#   【再也连不回来】。
# ★ 安全做法:① 改之前先备份 ifcfg 文件;② 尽量
#   通过带外管理(IPMI / 云控制台 VNC)操作,
#   而不是纯 SSH;③ 或者用一个"定时回滚"兜底:
$ cp ifcfg-eth0 ifcfg-eth0.bak    # 改前必备份

# === 认知 ===
# ★ 把网络配置持久化的传统方式,是写
#   /etc/sysconfig/network-scripts/ifcfg-eth0:
#   BOOTPROTO=static 配合 IPADDR/NETMASK/GATEWAY,
#   ONBOOT=yes。改完必须 nmcli connection reload + up
#   (或重启 network)让运行时跟持久化对齐。远程改
#   网络前务必备份、留退路。

修复 4:nmcli——NetworkManager 时代的正道

# === ★ 更推荐的方式:用 nmcli 操作 NetworkManager ===

# === ★ 为什么推荐 nmcli ===
# 直接手写 ifcfg 文件能用,但容易写错、字段也多。
#   既然系统由 NetworkManager 管,★ 用它的官方
#   命令行工具 nmcli 来配,它会:
#  - 帮你把配置写进正确的地方(生成/更新连接配置);
#  - ★ 同时处理好"运行时"和"持久化"两层 —— 不用
#    你再手动 reload。
# ★ 这正是 nmcli 的好处:一条命令,两层一起搞定。

# === ★ 先看 NetworkManager 眼里有哪些"连接" ===
$ nmcli connection show
NAME    UUID        TYPE      DEVICE
eth0    xxxx-xxxx   ethernet  eth0
# ★ NM 把网络配置叫"连接(connection)"。一个连接,
#   就对应一份持久化配置。

# === ★ 给一个连接配静态 IP(关键四条)===
$ nmcli connection modify eth0 ipv4.method manual
$ nmcli connection modify eth0 ipv4.addresses 192.168.1.50/24
$ nmcli connection modify eth0 ipv4.gateway 192.168.1.1
$ nmcli connection modify eth0 ipv4.dns 8.8.8.8
# ★ 这几条 modify:
#  - ipv4.method manual -> 用手动指定的地址(相当于
#    ifcfg 里的 static)。
#  - ★ 每一条 modify,都会被 NM【写进磁盘上的连接
#    配置文件】—— 自动持久化,不用你管。

# === ★ 让修改"现在就生效"===
$ nmcli connection up eth0
# ★ modify 只改了"持久化配置";up 这一步,是把这份
#   配置【应用到当前运行的系统】。
# ★ 做完 modify + up,两层就都齐了:磁盘上有了
#   (重启还在)+ 当前也生效了(现在能用)。

# === ★ nmcli 几个常用操作 ===
$ nmcli device status            # 看每张网卡的状态
$ nmcli connection show eth0     # 看某连接的全部配置
$ nmcli connection up eth0       # 启用一个连接
$ nmcli connection down eth0     # 停用一个连接
$ nmcli -t -f ipv4.addresses connection show eth0   # 只看 IP
# ★ 还可以用 nmtui —— 一个文字版的图形界面,菜单
#   里点点就能配,适合不想记命令时。

# === ★ ifcfg 和 nmcli,到底什么关系 ===
# ★ 在 CentOS 7 上,nmcli 改完连接,NM 默认仍会
#   把配置【落到 ifcfg-eth0 文件】里(新系统可能
#   落到 /etc/NetworkManager/system-connections/)。
# ★ 所以它俩不是对立的:nmcli 是"操作工具",
#   ifcfg 是"存储格式"之一。推荐统一用 nmcli 操作,
#   ★ 别再用 nmcli 改一半、又手动 vi 文件改一半 ——
#   两种方式混用,容易让配置对不上。

# === 认知 ===
# ★ NetworkManager 时代,推荐用 nmcli 配网络:
#   nmcli connection modify 改配置(自动持久化到
#   磁盘),nmcli connection up 让它当前生效 ——
#   一套命令把"运行时 + 持久化"两层都对齐,不用
#   手动 reload。别 nmcli 和手写 ifcfg 混用。

修复 5:这个坑无处不在——iptables、sysctl、mount 全一样

# === ★ "运行时改了、没持久化",远不止网络一处 ===

# === ★ 坑 1:防火墙规则(iptables)===
# 直接 iptables 加的规则,和 ip addr 一样,只在
#   【内存】里,重启就没:
$ iptables -A INPUT -p tcp --dport 8080 -j ACCEPT  # ★ 运行时!
# ★ 要持久化,得显式保存,或用 firewalld 的
#   --permanent:
$ firewall-cmd --add-port=8080/tcp              # ★ 运行时,重启没
$ firewall-cmd --permanent --add-port=8080/tcp  # ★ 写进配置文件
$ firewall-cmd --reload                         # 让持久化的生效
# ★ firewalld 的经典坑:只加了不带 --permanent 的,
#   当时通、重启就不通。

# === ★ 坑 2:内核参数(sysctl)===
$ sysctl -w net.ipv4.ip_forward=1               # ★ 运行时,重启复原
# ★ 要持久化,写进配置文件:
$ echo 'net.ipv4.ip_forward = 1' >> /etc/sysctl.conf
$ sysctl -p                                     # 让文件里的立刻生效
# ★ "我明明开了 ip_forward,重启后转发又不行了" ——
#   就是 sysctl -w 没落盘。

# === ★ 坑 3:挂载磁盘(mount)===
$ mount /dev/vdb1 /data                         # ★ 运行时挂载
# ★ 重启后这个挂载就没了。要开机自动挂,得写进
#   /etc/fstab:
$ echo '/dev/vdb1 /data ext4 defaults 0 0' >> /etc/fstab
# ★ "数据盘挂好用了好久,重启后 /data 空了" ——
#   就是只 mount 没写 fstab。

# === ★ 坑 4:路由 / 主机名 / 时区…… ===
# ip route add（运行时) vs 写进网卡配置（持久化)
# hostname xxx(运行时) vs hostnamectl set-hostname(持久化)
# ★ 规律惊人地一致:几乎每一类系统配置,都有
#   "一条立刻生效的运行时命令" + "一个要写的
#   持久化文件"这两面。

# === ★ 一个通用的心智模型 ===
# ★ 看到一条"立刻就改变了系统行为"的命令,先警觉:
#   它改的是运行时,还是持久化?问自己那句话 ——
#   ★【现在重启,它还在吗?】
# ★ 大量"当时好好的,重启 / 过段时间就出问题"的
#   故障,根子都在这:做了运行时修改,误以为是
#   持久化配置。

# === ★ 验证持久化是否成功的"硬核"办法 ===
# ★ 不确定一个配置到底持久化没有?最可靠的验证 ——
#   ★ 挑一个安全的时间窗口,真的重启一次,然后
#   检查配置还在不在。
# ★ "我以为持久化了"和"重启后它真的还在",是
#   两回事。重要的配置,值得用一次真实重启来确认。

# === 认知 ===
# ★ "运行时改了、忘了持久化"是个跨领域的通用坑:
#   iptables/firewalld、sysctl、mount/fstab、路由、
#   主机名…… 全都是"一条运行时命令 + 一个持久化
#   文件"。每做一个配置,都问一句"现在重启它还在
#   吗",重要配置用一次真实重启来验证。

修复 6:运行时与持久化排查纪律

# === 这次事故暴露的认知盲区,定几条纪律 ===

# === 1. ★ Linux 配置分两层:运行时状态(内存)和持久化配置(磁盘文件)===

# === 2. ★ 改一层不会自动同步到另一层,它们是两份独立的东西 ===

# === 3. ★ 重启清空运行时状态,系统完全照磁盘配置文件重建 ===

# === 4. ★ ip addr / iptables / sysctl -w / mount 都是运行时命令,重启即失 ===

# === 5. ★ 判断一个修改是哪一层,就问:现在重启,它还在吗 ===

# === 6. 网络持久化:写 ifcfg 文件,或用 nmcli connection modify ===
$ nmcli connection modify eth0 ipv4.method manual ipv4.addresses IP/24

# === 7. ★ nmcli modify 改配置 + nmcli up 生效,一套对齐运行时和持久化两层 ===

# === 8. ★ "配好了"= 运行时生效(现在能用)+ 持久化(重启还在),缺一不可 ===

# === 9. 远程改网络是高危操作,改前备份配置文件、尽量用带外管理留退路 ===

# === 10. 排查"配置重启就丢"的步骤链 ===
$ ip addr / iptables -L / sysctl -a  # ① 看运行时当前状态
$ cat 对应的持久化配置文件            # ② 看磁盘文件里写的是什么
# ③ 两者对不上 -> 就是只改了运行时没持久化
$ 用 nmcli/写文件 把配置落盘          # ④ 根治:持久化
$ 挑窗口真实重启一次验证             # ⑤ 确认重启后还在
# 按这个顺序,"配置重启就消失"基本能定位、能根治。

命令速查

需求                        命令
=============================================================
看网卡当前 IP(运行时)     ip addr show eth0
看网卡持久化配置            cat /etc/sysconfig/network-scripts/ifcfg-eth0
看 NM 的连接列表            nmcli connection show
配静态 IP(nmcli)          nmcli con mod eth0 ipv4.method manual ...
让连接配置生效              nmcli connection up eth0
重新加载 ifcfg 文件         nmcli connection reload
重启老式网络服务            systemctl restart network
防火墙规则持久化            firewall-cmd --permanent --add-port=...
内核参数持久化              写 /etc/sysctl.conf 后 sysctl -p
挂载持久化                  写一行进 /etc/fstab
看是谁在管网络              systemctl status NetworkManager

口诀:ip addr 改的是内存里的运行时状态,重启清空内存它就没了
      要重启还在必须写进磁盘配置文件,配好了=运行时生效+持久化两层都到位

避坑清单

1. Linux 的配置分两层,运行时状态活在内存里,持久化配置写在磁盘文件里决定下次开机的样子
2. 改运行时状态不会自动同步到持久化文件,改持久化文件也不会自动让当前系统生效,两者独立
3. 重启会彻底清空运行时状态,系统完全照磁盘上的配置文件把自己重新配置一遍
4. ip addr add 和 iptables 和 sysctl -w 和 mount 都是运行时命令,只改内存重启就会失效
5. 判断一个修改是运行时还是持久化,就问自己一句如果现在重启这个修改还在不在
6. 开机时由 NetworkManager 读 ifcfg 配置文件来配网卡,ip 命令的修改不写文件所以重启不保留
7. 网络配置持久化要写 ifcfg 文件或用 nmcli connection modify,改完要 reload 或 up 才生效
8. nmcli modify 改配置会自动持久化到磁盘,再配合 nmcli up 让它生效,一套对齐两层
9. 真正配好一件事等于运行时已生效加上已持久化,两层缺一不可少了哪层都会出问题
10. 远程修改网络配置是高危操作,改前先备份配置文件,尽量用带外管理或留一条回滚退路

总结

这次"重启一下,IP 凭空蒸发"的事故,纠正了我一个关于"已经做好了"的、藏得极深的错觉。在我过去的认知里,一件事"做好了",是一个【一次性的、永久成立的】结果。我那天敲下 ip addr add,看着它 ping 通,那一刻在我心里,"IP 配好了"这件事,就像一颗钉子,被我【钉】进了这台机器里——钉子钉进去了,它就【在那儿】了,我可以转身离开,不必再回头。它之后稳稳跑了一个月,更是反复"印证"着我这个判断:你看,它一直好好的,可见我那颗钉子,钉得多结实。可机房的那次断电,像一只手,轻轻一推,我那颗"钉得结实的钉子"——连同它钉住的 IP——就整个滑落了,地上什么都没留下。现场逼着我承认一件很难堪的事:我那天做的,根本不是"把钉子钉进木头",而是"把一样东西,放在了一张桌子上"。它稳稳待了一个月,不是因为它被固定住了,只是因为这一个月里,没有人碰过这张桌子。桌子一晃(重启),东西就掉了。我把"它现在在那儿"错当成了"它被固定在那儿"——而这两者之间,隔着一个我从来不知道、也从来没去做的动作:【把它固定下来】。复盘到根上我才明白,我心里那个"做好了",其实悄悄塞进了一个我自己都没察觉的假设——我假设"现在生效"会自动地、理所当然地"一直生效下去"。可一个运行中的系统,它有"此刻的样子",也有"它记得的、下次重生时要变成的样子",这是两本完全不同的账。我在"此刻的样子"上动了手,那一笔,鲜活、立刻可见、立竿见影;可它从没被抄进"下次重生要变成的样子"那本账里。而重启,就是一次彻底的重生——系统死去,然后【只照着后面那本账】,把自己重新拼装起来。前面那本账上我写的一切,随着旧的躯体一起湮灭了。这次最大的收获,是我对"生效了"这三个字,生出了一种新的戒心。一件事"现在能用",只是它【活着】;而它"重启之后还在",才说明它真正【扎下了根】。活着,可能只是因为还没人来打扰;扎根,才是经得起一次推倒重来。这两者看起来一模一样——一个跑了一个月的服务,你根本分不清它是"扎了根"还是只是"侥幸地活着"——可一场断电、一次重启,就会把它们之间那道残酷的鸿沟,瞬间劈开。所以下一次,当我做完一项配置、一项部署、一项设置,看着它顺利运转、正要满意地转身离开时,我会强迫自己停下来,补问一句最朴素、却最致命的话:如果此刻,这台机器就在我眼前重启一次——我刚刚做的这一切,【还会在吗】?如果我不能笃定地回答"在",那我就还没有真正做完。我做的,只是把东西放在了桌上;我还欠它最后、也最关键的一下——把它,亲手钉进去。

—— 别看了 · 2026