远程部署时，别只开一个 SSH 窗口
2016 年还在自己管服务器的时候，我最怕的不是部署命令难写，而是 SSH 连上去之后，所有动作都挤在一个窗口里：看日志在这里，改配置在这里，重启服务也在这里。只要网络抖一下，或者手快切错目录，整个节奏就乱了。
后来我慢慢形成了一个习惯：远程部署时尽量不要只靠一个 SSH 窗口硬扛，至少要把会话层先稳定下来。tmux 不是新鲜技术，但在那几年它真的很实用。
我后来固定的窗口分工
真正做事时，我一般把会话拆成三块：
- 一个窗口专门 tail 日志
- 一个窗口处理发布命令和重启
- 一个窗口只留给临时排查
这样做最直接的好处是，你不会因为切来切去，把正在看的日志冲掉，也不容易把本来准备查看状态的窗口误当成可执行窗口。
为什么 tmux 比“多开几个 SSH”更稳
多开几个 SSH 当然也能做事，但 tmux 有两个优势特别实在。
第一，掉线后能接回去。
如果部署到一半本地网络断了，tmux 里的会话还在，重连之后直接 attach 回来继续看，不会因为一次断线就丢掉上下文。
第二，窗口布局可以固定。
日志看哪里、命令敲哪里、临时检查去哪一个 pane，时间长了会形成肌肉记忆，错误率会低很多。
我最常用的一套最小动作
不是每次都要玩很复杂的 pane 布局，我通常只坚持这几个动作：
- 上线前先
tmux new -s deploy - 日志和命令分窗，不混用
- 关键输出看完再滚回去，不拿历史记录当临时记忆
- 部署结束再手动收尾，不留一堆失控会话
这几条很朴素，但能解决 80% 的线上慌乱问题。
真掉线了，最有价值的不是“快”，而是“没丢”
以前我特别追求一套发布流程能不能再快半分钟，后来发现远程部署最重要的不是快，而是上下文别断。
你知道服务刚刚执行到了哪一步，日志最后一行是什么，配置改到了哪，这些信息只要保住，心态就稳很多。
tmux 本质上是在帮你保存“现场”。而远程运维很多时候拼的就是现场没有丢。
这套做法适合什么场景
如果你只是偶尔登录机器看一眼状态，多开一个终端也够用。但只要涉及下面这些动作，我都会建议把会话先稳住：
- 发布新版本
- 改 Nginx、Supervisor、PM2 一类配置
- 持续跟日志看回滚结果
- 半夜处理线上故障
这些场景一旦出错，不是多敲一条命令的问题，而是你很容易在慌乱中失去顺序。
小结
那几年很多人把运维问题归结为命令不熟，其实更常见的问题是工作台太乱。tmux 这种工具没有什么炫技空间，但它能把部署过程从“靠记忆硬撑”变成“有结构地执行”。对自己管服务器的开发者来说，这已经很值了。