线上运维
几台自用的 Linux 主机,Nginx 反向代理、证书自动续期、每日巡检。原则是把能自动化的都自动化,把必须人工的写成一页清单。
后端 · 运维 · 自动化
做后端和运维,日常打交道的对象是几台 Linux 主机、一个不轻的数据库,以及一堆随时可能出状况的定时任务。这里放的是长期积累下来的东西:踩过的坑、想清楚的判断、还有那些不想再查第二遍的命令。
写了十来年服务端,早就过了追新框架的阶段。现在更在意的是:半年之后回来看,还能不能一眼看懂当初为什么这么写;半夜被叫起来处理故障的时候,手上有没有一条确定能走通的路。
工作里最花时间的三件事,说出来都很朴素——把系统跑稳、把重复的操作收敛成脚本、把出过的问题写成能回看的记录。它们不产生什么漂亮的成果,但少了任何一件,剩下的都会变得难做。
工作之外读一些和器物、地图、城市史有关的书。看得多了会发现,排查故障和历史考据其实是一回事:都是在残缺的线索里找结构,区别只在于一个是代码,一个是人。
大致分成四条线。它们不是并列的模块,更像是同一套东西从四个角度去看:越往下越靠近机器,越往上越靠近用它的人。
几台自用的 Linux 主机,Nginx 反向代理、证书自动续期、每日巡检。原则是把能自动化的都自动化,把必须人工的写成一页清单。
发布、日志归档、数据导出、批量改配置这类反复动作,尽量收敛成一条命令。脚本写得难看没关系,能重跑、能回滚才是重点。
PostgreSQL 主库配每日全量加异地冷备,每隔一段时间做一次真实的恢复演练——备份能不能用,只有恢复过才算数。
参数为什么这么取值、方案为什么被放弃、回滚走到第几步,都记下来。写给下一次的自己,也写给愿意读的人。
下面这些东西用了很久,谈不上推荐,只是说明一下平时的工作环境。工具会换,判断问题的方法不太会。
排障的时候,先用 top、ss、journalctl 这几样看一遍,多数问题在第一步就能看出轮廓;剩下那部分,通常要靠日志里的时间线去对。
技术上的讨论、勘误、或者只是想说一句「这里写得不对」,都可以写信过来。来信时简单说下背景和具体问题,回复会快很多。