有一次维护共享存储，我原本以为只是挂载失败：业务侧看不到共享目录，自动挂载也没有恢复。第一反应很自然——把原来的挂载动作再试几次，或者把重试次数调大一点。可是在真正检查之前，我停了下来。挂载动作依赖一个前提：我们知道对面的设备是谁，而且知道从哪里可以到达它。
这次的问题，恰好出在这个前提上。记录里的设备类型和地址说明并不准确，目标地址实际对应的是网络存储设备，而不是原先记录的电脑；另一个候选地址又无法连通。于是，表面上看是“挂不上”，实际上是维护资料先把身份和位置写错了。后面的自动化策略没有可靠依据，越重试越像是在重复一个未经核实的猜测。
挂载失败之前，身份已经错位
共享目录是一种很容易被误解的资源。看到一个地址、一个共享名，再配上一条挂载命令，人会自然地以为这已经足够描述目标。可是地址只回答“去哪里找”，没有回答“那边是什么服务”；共享名只回答“要什么”，也没有回答“它是否真的由这个设备提供。
这次核查把两个层次分开了。先看服务发现和实际网络响应，再看共享服务是否可访问。结果显示，目标地址背后确实是网络存储设备，能够提供共享服务；另一个候选地址则无法建立连通。原有文档把这两者写反或写混之后，设备清单、挂载脚本和后续判断就一起偏了。
自动化的第一步不是执行动作，而是确认动作面对的对象没有被文档认错。
这件事让我重新意识到，维护资料里的注释不是装饰。设备类型写错，看似只影响阅读，实际上会改变排障路径：面对电脑，人可能去检查登录状态或某个应用；面对网络存储设备，则应该检查服务、共享导出和网络可达性。身份一旦错位，后面每个动作都有可能“技术上合理、对象上错误”。
表面是重试，实质是缺少证据
挂载失败时不断重试，是最容易走的错误捷径。它有一个让人安心的外观：命令正在运行，次数也在增加，似乎只差一次好运气。可是如果原地址本来就不可达，或者地址对应的并不是预期服务，重试只会延长等待时间，并不会创造新的事实。
如果不处理身份和地址问题，后果不只是这一次共享目录暂时不可见。业务进程可能反复等待一个永远不会成功的挂载动作；备份任务可能把目标判定为离线；看门狗则可能持续拉起无效操作，消耗资源并制造更多日志。更麻烦的是，下一次维护者看到“自动重试过很多次”，容易误以为网络曾经有过短暂波动，而忽略最初的配置错误。
所以我没有先增加重试次数，而是先做独立的服务发现和连通性检查。这里的“独立”很重要：检查身份的动作不能完全依赖挂载脚本本身，否则脚本的错误假设会被检查过程再次带进去。只有把“它是谁”“能不能到”“有没有目标服务”分别确认，挂载动作才有资格进入下一步。
先排地址，再谈优先级
地址核查完成后，决策就清楚了：可访问共享服务的地址作为首选，另一个无法连通的候选地址保留为备选，但不能再被当成同等可靠的入口。备选不是把未知状态包装成冗余，而是给未来环境变化留下一个有边界的退路。
我选择把可达地址设为首选，是因为它已经有实际服务响应，而不是因为它在旧文档里排在第一个。顺序应该由证据决定。另一个地址虽然当前无法连通，也不必立刻从所有资料里抹掉；它可以保留，但必须带着清楚的状态和触发条件，不能让执行器无条件地把它当作正常入口。
优先级不是配置文件里的排列顺序，而是对当前可验证事实的排序。
这也改变了设备清单的写法。清单至少要能同时表达设备身份、服务类型、首选地址、备选地址和共享资源。把这些信息拆散在脚本注释、备份文档和个人记忆里，短期可能还能运行，长期却很容易再次漂移。某一处改了，另一处没改，系统就会重新回到“能不能访问”与“到底是谁”的混乱里。
让挂载器有界，让恢复有节奏
身份和地址校准后，还需要处理自动恢复。挂载器不应该承担所有事情。它适合做一次业务动作：检查当前是否已经挂载，尝试首选地址，必要时按明确规则尝试备选地址，然后在有限时间内返回结果。它不适合无限等待，也不适合在前台阻塞业务进程。
我判断恢复应交给低频看门狗，是因为挂载失败和业务请求不应该绑定在同一条等待链上。看门狗可以在一个周期内检查共享状态，发现手动卸载或异常断开后，再重新执行有界挂载。这样，业务继续运行，恢复动作也有机会在稍后的周期完成。恢复不是越快越好，而是既不能放任故障，也不能为了恢复而把正常工作拖住。
这里还有一个容易被忽略的边界：看门狗必须知道什么叫“已经恢复”。不是命令返回了就算成功，而是共享服务可达、目标共享确实挂载、业务侧能够使用，至少要形成一条最小验收链。如果只检查进程存在，可能得到一个“看门狗正常、共享目录仍不可用”的假成功。
一个可靠的恢复流程，应该把尝试次数、等待时间和成功条件都写成边界，而不是把希望寄托在持续重试上。
把配置和验收放在同一条链上
这次修复不只是改一行地址。现有挂载脚本和备份文档里的设备类型、地址注释都需要更正；目标共享也要加入设备清单，并明确可达地址优先。只有这些地方一起更新，后续维护者才不会从旧资料中重新读出错误结论。
我会把验收分成几个连续问题。第一，服务发现结果是否支持设备身份。第二，首选地址是否能访问目标共享服务。第三，备选地址在不可达时是否不会抢占首选。第四，手动卸载后，看门狗能否在一个周期内恢复挂载。第五，恢复过程中业务是否没有被同步阻塞。每个问题都对应一个具体事实，不能用“脚本执行成功”一项代替全部答案。
这件事让我重新意识到，配置正确不等于系统可靠。配置只是把判断写下来，验收则要证明判断仍然和现实一致。真正要保留的不是某个地址，而是地址背后的证据、优先级和失败边界。
下次我会怎么做
下次遇到共享存储挂载异常，我会先暂停重试，按身份、可达性、服务和共享资源的顺序核查。先确认对方是什么设备，再确认哪个入口真的能到达；先把首选和备选排好，再决定挂载器应该做多少工作。
我会把设备身份、服务类型、地址优先级和共享清单放进同一份可核对的配置，并同步更新相关维护文档。地址出现变化时，先更新事实，再更新动作，避免只改脚本而留下错误说明。
最后，我会让挂载动作保持有界，把持续恢复交给低频看门狗，并用“一个周期内能恢复、业务不被阻塞、共享实际可用”作为验收标准。一个流程成熟的标志，不是它能在网络正常时自动挂载，而是它在身份不确定、地址失效和资源被卸载时，仍然知道该先确认什么、最多尝试什么，以及什么时候应该停下来。
我更愿意把这看成一种工作习惯，而不是一个技巧：面对自动化故障，先校准现实，再设计动作；先留下证据，再安排重试。这样下一次故障到来时，系统依赖的就不只是某个人记得一条地址，而是一条可以被重新验证的判断链。