dsh-workbuddy-connect 这个连接组件，十个第一次装的人里有六七个会卡在同一个地方：包解压了、命令也跑起来了，日志最后一行停在handshake pending不动，人立刻开始怀疑网络，其实八成是本地环境漏了一项或者配置里少了个字段。我前后在三类环境里装过它——一台刚重装系统的干净机器、一台受管控的办公笔记本、一台完全离线的内网服务器，卸载重装加起来十几次，坑基本踩了个遍。这篇安装避坑指南就按实际动手顺序讲：环境依赖怎么提前验、配置怎么逐字段确认、连不通的时候怎么一层层把问题揪出来。不管你之前有没有接触过这个组件，只要照着顺序走一遍，能省掉大半天瞎试的时间。
1. 先搞清楚这个组件装完到底有什么
很多人装失败不是因为操作错，而是从头到尾不知道自己在装什么。dsh-workbuddy-connect 不是一个点开就用的图形客户端，它是一个常驻型的连接组件，装完之后你机器上会多出来一整套东西：一个主程序、一个配置目录、一个缓存目录、一个日志文件，如果走了服务化安装，还会多一个开机自启的服务单元。心里有这张地图，后面报错的时候才知道该去哪个目录翻。
1.1 三条职责线：连接保持、本地索引、凭据管理
主程序干的第一件事是会话保持：跟服务端建立一条长连接，按固定周期发心跳，断了按指数退避重连。这件事是它存在的主要理由，也是排错时最常出问题的一环。第二件事是本地工作区索引，由一个可选插件负责，扫描你指定的目录、建立文件清单，用于后续的增量同步判定。这个插件是可选装的，不装主程序照样能跑，只是没有本地索引能力。第三件事是凭据与设备标识管理，第一次启动时会生成设备指纹、写入租户标识，后面所有的握手都依赖这两样东西。
这三条职责线对应三个不同的故障面，搞清楚之后排错思路会清晰很多：连接不上是第一条线的问题，日志里报索引超时是第二条线的问题，握手被拒多半是第三条线。我见过有人把索引插件的报错当成网络问题查了两天，最后发现是inotify监听数不够。
1.2 三种安装方式的取舍，别盲目选最省事的那种
官方一般会给三条路：离线压缩包、系统包管理器、一键脚本。这三条路不是随便挑的，选错了后面升级和卸载都会难受。
| 安装方式 | 适合场景 | 优势 | 隐藏代价 |
|---|---|---|---|
| 离线压缩包 | 内网机器、无外网出口的服务器 | 完全可控，不依赖任何外部源 | 升级要手动替换，服务单元要自己写 |
| 系统包管理器 | 有内部软件源的团队机器 | 升级卸载干净，依赖自动处理 | 内部源版本往往滞后，容易装到旧版 |
| 一键脚本 | 个人开发机、临时验证环境 | 最快，参数默认值基本够用 | 脚本行为不透明，出问题不好定位 |
我的建议很直接：但凡这台机器以后要长期跑，就用离线包 + 自己写服务单元。一键脚本适合你今天只是想验证一下能不能连上，验证完就删掉。包管理器那条路最大的问题是版本滞后，内部源里的版本经常落后两三个小版本，而你排查问题时网上看到的日志格式、命令参数全是新版的，对不上就会浪费大量时间。
1.3 依赖分级设计：为什么主程序敢不依赖运行时
这个组件有个容易让人困惑的设计：主程序是静态编译的单文件，理论上不依赖任何系统运行时；但索引插件是另一套语言写的，需要解释器环境和若干系统库。这种"分级依赖"的设计意图很明确——连接能力必须绝对可靠，索引能力可以降级。主程序静态编译就是为了避免"目标机器缺库导致连不上"这种致命问题。
代价是：你可能装出了一个"半残"的状态。wbc status显示连接正常、wbc doctor大部分检查项是绿的，但日志里每隔几分钟刷一条索引插件加载失败的警告。很多人看到连接正常就不管了，结果同步行为跟预期完全不一样。所以装完之后一定要看清楚 doctor 输出里有没有plugin: index这一项，它是单独判定的。
2. 环境依赖：装之前先把地基验一遍
这一章是我最想强调的部分。安装失败里至少一半是环境问题，而环境问题有个特点：装之前花五分钟能查出来，装之后要花两小时才能反推出来。所以我的习惯是先跑一遍体检清单，全部通过再动手解压。
2.1 操作系统、glibc 与 OpenSSL 的隐性门槛
主程序静态编译，理论上不挑系统，但插件和某些系统调用是挑的。我整理了一张实际验证过的底线表：
| 依赖项 | 最低要求 | 检查命令 | 不满足时的表现 |
|---|---|---|---|
| 操作系统 | 主流 Linux 发行版近三个大版本 | cat /etc/os-release | 服务单元语法不兼容 |
| glibc | 2.28 及以上 | ldd --version | 插件加载报GLIBC_2.28 not found |
| OpenSSL | 1.1.1 及以上 | openssl version | TLS 握手阶段直接失败 |
| 内核 | 4.x 及以上 | uname -r | 文件监听行为异常 |
| 磁盘 | 剩余 2 GB 以上 | df -h | 缓存写入失败，索引反复重建 |
glibc 这一项最容易翻车，因为它报错特别晚。你在老系统上装完，主程序跑得好好的，连接也建立了，只有当你启用索引插件时才会蹦出一句version 'GLIBC_2.28' not found。这时候再去升级系统就不现实了，只能放弃插件。所以我的做法是：如果这台机器 glibc 低于 2.28，安装时直接跳过插件，别抱侥幸心理。
2.2 运行时环境：版本、包源与虚拟环境的三重确认
索引插件需要 Python 3.10 及以上。看起来简单，实际上有三个坑。
第一个坑是系统自带 Python 版本低。很多发行版默认还是 3.8 或 3.9，而你python3 --version看到的可能就是系统那个。第二个坑是有多个 Python 时，插件调的是哪一个不由你决定，它走的是自己内部探测逻辑，探测顺序跟你的PATH顺序不一定一致。第三个坑是包源，内网机器如果没有配置内部镜像，pip install会一直超时，而超时报错里不会告诉你是源的问题。
我的处理方式是显式指定，不让它自己猜：
# 确认版本 python3.11 --version # 建独立虚拟环境，避免污染系统环境 python3.11 -m venv /opt/dsh-wbc/venv /opt/dsh-wbc/venv/bin/pip install --upgrade pip /opt/dsh-wbc/venv/bin/pip install -r /opt/dsh-wbc/plugin/requirements.txt -i <内部源地址>装完之后在配置里把plugin.python_path显式指向/opt/dsh-wbc/venv/bin/python。这一步看着啰嗦，但能省掉后面"为什么插件加载的库版本不对"这类玄学问题。
提示：不要用系统 Python 的
--user方式装依赖。一旦换了执行用户，装的东西就找不到了，而报错信息只会说模块不存在，非常容易误判成装漏了。
2.3 系统参数：文件句柄、监听数与时钟，三个必须提前调的数
这三项如果装完再调，你得重启服务甚至重启机器，很烦。装之前一次性调好。
文件句柄数：组件要同时持有连接、缓存文件、索引数据库的句柄，默认 1024 不够。工作区十万级文件时，建议调到 65535。
文件监听数：这是最容易被忽略的一项。索引插件用inotify监听目录变化，系统默认fs.inotify.max_user_watches一般是 8192。一个中等规模的项目目录轻松超过这个数，超了之后插件不会报错，只是静默地漏掉一部分变更，表现为"文件改了但同步没跟上"，查起来极其痛苦。
估算方法很简单：目录下文件数 × 1.2，向上取整到万。二十万文件就设 262144，五十万就设 524288。
# 临时生效，先验证 sudo sysctl -w fs.inotify.max_user_watches=524288 sudo sysctl -w fs.inotify.max_user_instances=1024 sudo sysctl -w fs.file-max=2097152 # 验证后再写进 /etc/sysctl.d/99-dsh-wbc.conf 持久化时钟同步：这一项决定你能不能通过握手。服务端校验令牌时会比对时间戳，本地时间偏差超过 5 分钟就会被判定为无效请求，而报错信息通常只是一句auth rejected，不会告诉你是因为时间不对。装之前先看一眼：
timedatectl status chronyc tracking # 或 ntpq -p重点看System clock synchronized是不是yes，以及偏移量是不是在毫秒级。我遇到过一次偏移 7 分钟的机器，所有网络检查全绿，就是握手不过，查了三个小时。
2.4 一次性体检脚本，复制就能跑
把上面这些串起来，写成一个脚本，装之前跑一遍，全绿再动手：
#!/usr/bin/env bash set -u echo "== 系统 =="; cat /etc/os-release | head -2 echo "== 内核 =="; uname -r echo "== glibc =="; ldd --version | head -1 echo "== openssl =="; openssl version echo "== 磁盘 =="; df -h /opt echo "== 句柄 =="; ulimit -n; sysctl -n fs.inotify.max_user_watches echo "== 时钟 =="; timedatectl status | grep -E "synchronized|Time zone" echo "== 端口占用 7777 =="; ss -lntp 2>/dev/null | grep 7777 || echo "空闲" echo "== 出网可达性 =="; timeout 5 bash -c 'cat < /dev/null > /dev/tcp/<服务端地址>/8443' \ && echo "TCP 8443 可达" || echo "TCP 8443 不可达"/dev/tcp这个探测方式不需要装任何工具，挺实用。注意timeout 5一定要加，不可达的时候连接会挂很久。
3. 安装过程：包校验、路径选择与权限落地
环境验完之后，安装本身其实不复杂，但有几个细节做不好，后面会以很隐蔽的方式咬你一口。
3.1 包完整性校验与被低估的路径选择
压缩包下载下来第一步是校验哈希，这一步别省。传输中断导致的包损坏，解压可能不报错，但运行时会出现莫名其妙的段错误或者插件加载失败。
sha256sum dsh-workbuddy-connect-2.4.7-linux-amd64.tar.gz # 与发布页给出的值逐字符比对，不要只看长度关于解压路径，有三条硬性建议。
不要装在/tmp：有些系统会定期清理，某天服务突然起不来，查半天发现程序文件没了。不要装在带空格或中文的路径下：服务单元解析、脚本传参都可能出问题，这类问题报错信息完全不指向根因。不要装在用户家目录然后用 sudo 运行：我踩过这个坑——第一次用普通用户跑，缓存目录归普通用户所有；后来改成sudo启动，程序以 root 身份写不进原来的缓存目录，日志报权限错误，而文件权限看着是 755 一切正常，因为问题在目录的所有者上。
推荐布局：
/opt/dsh-wbc/ ├── bin/dsh-workbuddy-connect ├── bin/wbc -> dsh-workbuddy-connect ├── plugin/ ├── venv/ └── version /etc/dsh-workbuddy-connect/config.yaml /var/lib/dsh-workbuddy-connect/ # 缓存与索引 /var/log/dsh-workbuddy-connect/3.2 服务账号与权限落地，别用 root 跑
常驻服务用专用账号是最低要求。这个组件要读配置、写缓存、读工作区目录，三处权限都要给对。
sudo useradd -r -s /usr/sbin/nologin -d /var/lib/dsh-workbuddy-connect wbc sudo mkdir -p /var/lib/dsh-workbuddy-connect /var/log/dsh-workbuddy-connect sudo chown -R wbc:wbc /var/lib/dsh-workbuddy-connect /var/log/dsh-workbuddy-connect sudo chmod 750 /var/lib/dsh-workbuddy-connect sudo chmod 640 /etc/dsh-workbuddy-connect/config.yaml配置文件里可能有令牌，权限必须是 640 甚至 600，不能是默认的 644。工作区目录的读权限也要给wbc账号，但不要给写权限——组件只需要读，给它写权限反而增加了误删风险。
systemd 单元写起来不复杂，但有两个参数要注意：
[Unit] Description=dsh-workbuddy-connect agent After=network-online.target Wants=network-online.target [Service] Type=simple User=wbc Group=wbc ExecStart=/opt/dsh-wbc/bin/dsh-workbuddy-connect serve --config /etc/dsh-workbuddy-connect/config.yaml Restart=always RestartSec=10 LimitNOFILE=65535 Environment=HOME=/var/lib/dsh-workbuddy-connect [Install] WantedBy=multi-user.targetAfter=network-online.target这一项很多人图省事写成network.target，差别在于后者只保证网络栈初始化完成，不保证有 IP。开机时如果网络还没起来就启动，组件会连续重连失败，虽然Restart=always最终能救回来，但日志里会多出一堆误导性的错误。LimitNOFILE必须显式写，systemd 有自己的默认值，不受系统ulimit影响。
3.3 首次初始化：设备标识与租户参数
第一次启动前要先生成配置。wbc init一般会交互式问几个问题，其中两个最关键：
租户标识（tenant）：这个值填错是最隐蔽的错误之一，因为服务端会正常返回握手响应，只是响应里带的策略是空的，表现出来就是"连上了但什么也不同步"。填的时候必须跟团队给的完全一致，大小写敏感。
设备名（device_name）：这个值在同一个租户下必须唯一。默认值通常是主机名，而很多批量部署的机器主机名是一样的，结果第二台机器上来就把第一台踢下线，两台机器反复互踢，日志里全是session replaced by another device。建议在设备名里带上用途或编号，比如dev-laptop-03。
初始化完成后，配置文件里应该能看到这几项：
tenant: team-alpha device_name: dev-laptop-03 device_id: 8f3c... (自动生成，不要手改)device_id是首次启动时生成的，一旦生成就不要改，改了等于换了一台新设备，服务端会认为是陌生终端。
4. 配置验证：从字段含义到一次成功握手
配置这东西，抄模板很容易，理解字段含义很难。这一章把几个真正影响行为的字段拆开讲，再给出验证方法。
4.1 关键字段逐条拆解
endpoint: wss://workbuddy.internal.example:8443/connect ca_bundle: /etc/dsh-workbuddy-connect/ca.pem heartbeat_interval: 30s connect_timeout: 10s reconnect: base: 1s max: 60s jitter: 0.2 cache: dir: /var/lib/dsh-workbuddy-connect/cache max_size: 8GB log: level: info file: /var/log/dsh-workbuddy-connect/agent.log max_backups: 7| 字段 | 作用 | 常见错误值 | 后果 |
|---|---|---|---|
| endpoint | 服务端地址 | 用了 http 或端口写错 | 直接连不上 |
| ca_bundle | 私有 CA 证书路径 | 不填、路径错、目录当文件填 | TLS 握手失败 |
| heartbeat_interval | 心跳周期 | 设成 5s 以下 | 服务端限流，频繁断连 |
| connect_timeout | 单次连接超时 | 设成 30s 以上 | 故障时排错速度极慢 |
| cache.max_size | 缓存上限 | 不设或设得比磁盘还大 | 磁盘写满导致服务异常 |
| log.level | 日志级别 | 平时就开 debug | 日志暴涨，关键信息被淹没 |
重点说两个。heartbeat_interval不是越小越好，很多人觉得心跳密集一点连接更"牢"，实际上服务端有心跳频率上限，设成 5 秒以下会被判定为异常客户端，反而触发强制断开。默认 30 秒是经过考量的，别动它。
ca_bundle是私有部署环境的必填项。这个字段最容易填错的方式是填成目录而不是文件，或者文件内容是 PEM 但混进了多张证书导致解析失败。验证方法很朴素：
openssl x509 -in /etc/dsh-workbuddy-connect/ca.pem -noout -subject -dates能正常输出主题和有效期就说明格式没问题。
4.2 重连退避的参数怎么算，别凭感觉调
退避策略的公式是：
第 n 次重连等待 = min(base × 2^n, max) × (1 ± jitter)base=1s、max=60s、jitter=0.2的意思是：1 秒、2 秒、4 秒、8 秒、16 秒、32 秒、60 秒、60 秒……每次在计算值上下浮动 20%。加抖动的目的是避免一批机器同时断线后同一时刻集体重连，把服务端瞬间打满。
调参的原则：max不要超过 300 秒，否则网络恢复后要等很久才能重连上；base不要低于 500 毫秒，否则服务端维护窗口重启时你的机器会疯狂刷新连接。jitter建议保持 0.2，调到 0 相当于关掉随机化，批量部署时会出问题。
4.3 doctor 自检输出怎么读
wbc doctor是装完之后第一个该跑的命令。它会输出一串检查项，每项有状态和说明。常见的输出结构大致是这样：
[ok] binary version 2.4.7 [ok] config parsed, tenant=team-alpha [ok] cert ca bundle loaded, expires in 287 days [ok] clock offset +0.3s [warn] plugin index plugin not enabled [fail] endpoint tcp connect timeout after 10s读这个输出有个技巧：从下往上读。最后一项往往是根因，上面的是因它而失败的连锁反应。比如上面这个例子，endpoint不通，前面几项依然可能是绿的（它们只查本地），但如果你看到cert和clock也红了，那说明问题更早，先修前面的。
还有一点：[warn]不要一律忽略。上面这个plugin not enabled如果是因为你本来就打算不用插件，那没问题；如果你以为自己装了插件，那就是没装上。
4.4 三步验证，确认它真的在工作
doctor 全绿只说明"能连"，不说明"能干活"。我习惯再走三步：
# 第一步：进程与服务状态 systemctl status dsh-workbuddy-connect --no-pager wbc status # 第二步：本地健康端点 curl -s http://127.0.0.1:7777/healthz # 期望返回 {"status":"ok","uptime":1234,"session":"active"} # 第三步：真实业务动作 wbc sync --dry-run --path /home/me/workspace --verbose第三步是关键。--dry-run会完整走一遍列举、比对、生成计划的过程，但不实际传输。如果这一步能列出差异清单，说明索引、配置、连接三条线都是通的。只看wbc status显示connected是不够的，连接建立但业务不通的情况并不少见。
5. 连接排错：分层定位，别一上来就抓包
连不通的时候最忌讳上来就抓包看，一堆加密流量根本看不出什么，还浪费大量时间。我的习惯是严格按层往下走，每一层都有一个明确的判定结论，走完一定能定位到具体哪一层的问题。
5.1 四层定位法：DNS、TCP、TLS、应用协议
第一层 DNS。域名解析出来的是什么，是不是你以为的那个地址。
getent hosts workbuddy.internal.example dig +short workbuddy.internal.example内网环境里特别常见的问题是：机器上配了多个 DNS，先用内部 DNS 解析不到，再回落到外部 DNS，返回了一个完全不相关的地址。表现就是 TCP 连接超时，而你以为服务端挂了。检查/etc/resolv.conf里的顺序，必要时在/etc/hosts里写死映射——这是内网排查最省事的一招。
第二层 TCP。端口通不通。
timeout 5 bash -c 'cat < /dev/null > /dev/tcp/workbuddy.internal.example/8443' && echo ok ss -tnp | grep 8443如果 TCP 不通，问题要么在本地防火墙，要么在网络策略，要么对端没监听。这时候别继续往下查，先找网络管理员确认端口白名单——这条路走通之前，后面所有检查都是白费。
第三层 TLS。握手能不能完成，证书链是否被信任。
openssl s_client -connect workbuddy.internal.example:8443 \ -CAfile /etc/dsh-workbuddy-connect/ca.pem -servername workbuddy.internal.example -brief重点看返回值里有没有Verify return code: 0。如果是20 (unable to get local issuer certificate)，说明 CA 链没配全，把中间证书一并放进ca_bundle。如果是10 (certificate has expired)，那就得找服务端换证书。私有 CA 环境里这两个错误出现频率极高。
第四层应用协议。前三层都通了但握手还是被拒，问题就在应用层：租户填错、设备标识冲突、令牌过期、时间偏移。这一层的日志信息最丰富，开log.level: debug跑一次，把完整握手过程捞出来看。
5.2 五个高频现象，对应五组现场命令
| 现象 | 最可能原因 | 现场命令 | 处理 |
|---|---|---|---|
handshake pending卡住不动 | DNS 解析慢或 TCP 超时 | getent hosts//dev/tcp探测 | 修 DNS 或开白名单 |
| 连上几秒就断，反复重连 | 心跳频率超限或 MTU 不匹配 | grep heartbeat/ping -M do -s 1472 | 调回 30s / 调小 MTU |
auth rejected无详细信息 | 时钟偏移、令牌过期 | timedatectl/wbc auth inspect | 同步时间 / 重新登录 |
| 两台机器互相踢下线 | 设备名重复 | grep device_name | 改成唯一设备名 |
| 同步列表一直为空 | 租户标识错或路径权限不足 | wbc sync --dry-run --verbose | 核对租户 / 修目录权限 |
MTU 这一项值得单独说。有些网络路径中间存在封装开销，实际可用 MTU 小于 1500，而 TLS 握手包如果超过路径 MTU 就会被静默丢弃，表现是"小包能过、大包失败"，也就是 TCP 能连上但 TLS 握手卡住。判定方法：
ping -M do -s 1472 workbuddy.internal.example # 1500 - 28 ping -M do -s 1400 workbuddy.internal.example如果 1472 不通而 1400 通，说明路径 MTU 在 1428 左右，把本机网卡 MTU 调到 1400 再试。
5.3 私网环境的三件必查项
内网服务器的排错跟公网机器不太一样，有三处必须优先确认。
端口白名单：出方向的 8443 是否放通，这是第一件事。别自己想办法绕，直接找网络管理员按流程申请。私网里所有"看起来像网络问题"的现象，先排掉这条再说。
证书链与内部 CA：私有 CA 签发的证书不会在系统信任库里，必须显式通过ca_bundle指定。另外要注意证书的 SAN 字段，有些内部证书只签了 IP 没签域名，而你配置里写的是域名，一样会校验失败。用openssl x509 -in cert.pem -noout -text | grep -A1 "Subject Alternative Name"看一眼就清楚了。
时间源：内网机器经常连不上外部时间源，而内部时间源又没配，导致时间慢慢漂。漂到几分钟就开始握手失败。建议所有机器统一指向内部时间源，配置在/etc/chrony.conf里。
注意：任何情况下都不要尝试用非常规手段绕过网络管控。合规的路径是提申请、加白名单，这既是最快的，也是唯一不会给自己和团队带来麻烦的做法。
6. 常见问题速查表与几条踩坑心得
前面讲的都是系统性的方法，这一章补充一些零碎的、文档里不会写的东西。
6.1 速查表：症状到动作
| 症状 | 优先检查 | 一条命令定位 |
|---|---|---|
| 服务起不来 | 配置语法、文件权限 | journalctl -u dsh-workbuddy-connect -n 50 |
| 启动成功但连不上 | endpoint、DNS、端口 | wbc doctor |
| 连上后 CPU 飙高 | 索引插件扫描范围过大 | wbc index status |
| 日志疯狂刷同一行 | 退避参数设错或设备名冲突 | tail -f看时间戳间隔 |
| 磁盘占用持续增长 | 缓存上限没设或日志没轮转 | du -sh /var/lib/dsh-workbuddy-connect |
| 升级后行为变了 | 配置文件新旧字段不兼容 | wbc config diff |
6.2 升级与卸载，残留清理比安装更麻烦
升级的时候，最容易忽略的是配置文件兼容性。新版本可能把某个字段改名或者改了默认值，而你原来的配置文件语法上仍然合法，所以启动不报错，行为却悄悄变了。我的做法是升级前备份配置，升级后跑一次wbc config diff，把差异过一遍。
卸载的时候，有三处残留要手动清：
sudo systemctl disable --now dsh-workbuddy-connect sudo rm -rf /opt/dsh-wbc sudo rm -rf /var/lib/dsh-workbuddy-connect # 缓存与索引 sudo rm -rf /var/log/dsh-workbuddy-connect sudo rm -f /etc/dsh-workbuddy-connect/config.yaml其中/var/lib/dsh-workbuddy-connect一定要删干净。索引数据库残留会导致重新安装后读到旧数据，表现是"看起来同步了但实际没有"，非常难查。我遇到过重装后索引一直显示三万多个文件，实际目录早就清空了，就是这个原因。
另外，卸载前记得在服务端把设备注册记录解绑。有些团队对设备数量有上限，不清记录的话装到第三台就加不进去了。
6.3 几条不写在文档里的经验
第一条：装新机器之前，先在旧机器上把日志跑一遍对照。这个组件正常运行时日志是很有规律的，你熟悉了正常长什么样，异常一眼就能看出来。我习惯留一份正常启动的日志样本，出问题时直接 diff。
第二条：log.level平时用 info，排错时临时开 debug，问题解决立刻调回来。debug 级别下索引扫描的每一条文件变更都会打日志，一个活跃工作区一天能打出几个 GB，磁盘满了之后组件会静默降级，你以为在 debug 其实日志早就断了。
第三条：别在配置里用环境变量而不用配置文件。有些部署方式支持DSH_WBC_ENDPOINT这类环境变量覆盖配置，用起来挺方便，但排查时极容易漏——你改了配置文件没生效，因为环境变量优先级更高。我现在的原则是：配置文件是唯一真相来源，环境变量只在临时测试时用，用完就清掉。
第四条：批量部署一定要给每台机器唯一的设备名。这条前面提过，但值得再说一次，因为它在单机测试时永远暴露不出来，一上量就集体互踢，现场非常混乱。用一个生成规则，比如主机名前缀加用途和序号，写进部署脚本里。
最后分享一个我常用的小脚本，挂在 crontab 里每小时跑一次，能第一时间发现连接异常：
#!/usr/bin/env bash resp=$(curl -s --max-time 5 http://127.0.0.1:7777/healthz) if ! echo "$resp" | grep -q '"status":"ok"'; then echo "$(date -Is) health check failed: $resp" >> /var/log/dsh-wbc-watchdog.log systemctl restart dsh-workbuddy-connect fi这个脚本的价值不在于重启，而在于留下了一条带时间戳的记录。有这条记录，事后追溯问题的时候就能精确对上服务端的日志时间点，比自己回忆"大概是下午三点多的时候连不上"靠谱得多。
