40 篇博文 含有标签「运维」

使用环境:关于同一台电脑LInux系统下使用多个SSH key 切换使用(或者多用户使用ssh提交代码)

Nginx 反向代理 Node 服务时，很多问题表面上都像“接口有 bug”。
可 2017 年我自己在处理代理和部署问题时，越来越多时候发现，根因其实不在业务代码，而在请求经过 Nginx 之后，有些关键信息没有被完整传下去。

云服务器磁盘扩容这件事，很多时候会被理解成“容量加上了就结束”。
但 2016 年我自己处理这类操作时，越来越不敢只看控制台上的容量变化。因为真正决定这次扩容有没有落地到系统可用状态的，往往不是云平台页面，而是机器里挂载点和开机自动挂载有没有确认好。

看到 mysql.proc 相关错误时，很多人第一反应是“表坏了”。
这个判断不完全错，但 2016 年我在看这类问题时越来越觉得，真正值得警惕的不是某一张系统表本身，而是它背后通常暴露出一整段升级和权限处理流程都没收好。

数据库升级这种事，很多团队会认真写升级步骤，却不认真写回滚步骤。可真正到了线上，最能决定你心态的往往不是“怎么升”，而是“如果升坏了，能不能稳稳退回来”。

图形化数据库工具很容易让人操作得太顺。
尤其是像 DataGrip 这类客户端，连接、查询、查看结构都很方便，很多动作看上去像在本地演练一样自然。但 2016 年我开始更频繁地用这类工具处理线上数据后，最先养成的习惯反而不是记快捷键，而是先看自动提交有没有关掉。

服务启动失败这件事，最怕的不是问题复杂，而是人一慌就到处乱看。2016 年自己管机器的时候，我也吃过这种亏：一发现接口没起来，就先怀疑代码、怀疑框架、怀疑依赖版本，结果折腾了半天，最后只是端口被别的旧进程占着。

2016 年还在自己管服务器的时候，我最怕的不是部署命令难写，而是 SSH 连上去之后，所有动作都挤在一个窗口里：看日志在这里，改配置在这里，重启服务也在这里。只要网络抖一下，或者手快切错目录，整个节奏就乱了。

服务器刚开出来的时候，最诱人的动作通常是立刻登录上去装环境、拉代码、跑服务。
我早期也经常这样做，因为会觉得业务先上线最重要。可 2016 年之后自己管机器越来越多，我反而越来越愿意先停几分钟，把基础加固做完再继续。

MongoDB 副本集这套能力刚接触时，很容易给人一种“数据已经更安全了”的感觉。这个判断不算错，但如果进一步把它理解成“那就等于已经做好备份了”，问题就会变得很严重。2014 年我在看一些 MongoDB 部署经验时，越来越觉得这两个概念必须尽早分开。