服务器开发工程师的网站搭建与运维实战手册

　　跟开发吵了一架。就去年5月份，他甩给我一个 deploy.yml，说“按这个跑，线上环境和本地一模一样”。我信了。真信了。他拍着胸脯说镜像层都固定了 SHA，我手一滑就点了 apply——结果三分钟内，慢查询报警堆成山，DBA老张冲进工位扒我屏幕，风扇一直在转，声音大得像要起飞。

　　我原以为是配置没生效，结果 curl 了下健康检查端点，返回里明晃晃写着“cache miss ratio: 98.7%”。不是缓存没配，是压根没加载 config.json。deploy.yml 里那行 include: ./configs/env/prod.yml，路径写错了。少了个 dot。dot！就是那个小点，键盘右下角、Ctrl 键上面那个键，我每天敲八百遍，那天偏偏漏了。谁路过问了句“好了没”，我头都没抬，回了个“快了”，其实手已经悬在 rm -rf /tmp/redis- 上方两秒——没敢点。

　　服务器开发工程师的网站搭建与运维实战手册？它站得住的地方就一个：优胜劣汰。不是技术多牛，是扛不住的早被踢出生产环境了。上周五值班，凌晨两点接告警，主库连接数飙到 2047。我看日志第一眼就懵了：所有请求都在查同一个 union all 嵌套六层的视图，而这个视图的底层表，去年就被开发手动删过分区，没走 DROP PARTITION，是 TRUNCATE。我查了备份策略文档——哦，分区级备份？不存在的。我们只做全量物理备份，每周日凌晨三点开始，跑了俩小时，中间运维小王进来泡咖啡，问我“这波能熬到天亮不”，我说“看命”。他点点头，把速溶咖啡粉倒进我杯子里，没加水，直接盖上盖子走了。

文章配图，仅供参考

　　窗外天黑了。其实是傍晚六点，但机房窗玻璃反光太强，像黄昏提前卡了帧。我盯着 SHOW PROCESSLIST 的输出，第 47 行那个 sleep 1800 的连接，是监控探针——但它没死，它只是赖着不走。开发后来微信解释：“临时加的调试逻辑，忘了关”。我没回。我盯着那一行，看了足足一分半。不是气，是怕。怕自己哪天也这么写一句 “//TODO: remove before prod”，然后把它 merge 到 master。怕得胃抽了一下，外卖凉了，塑料盒边缘结了层白霜，我打开闻了闻，是宫保鸡丁，但辣椒油已经浮在表面凝成琥珀色的小片。

　　说回那本手册。它根本不是教程，是幸存者笔记。你翻到最后一页，发现全是 timestamp 和 grep 命令行片段，没有一行是讲原理的。“2023-05-17T02:18:03+08:00 | grep ‘Lock wait timeout’ | head -20”——就这么干巴巴杵着。我第一次见的时候还以为排版 bug。结果上个月又撞上同样 timeout，我照着抄了一遍命令，果然捞出四条阻塞链。其中一条的 blocking_pid，来自一个叫 monitor-worker-v2-beta 的容器，名字带 beta，部署时间却是三天前。我截图发给领导，他回了个“？”，我就知道这事没完。午饭吃的素包子，韭菜馅儿，特别冲，吃完打嗝都有股植物性攻击性。

　　手册里最硬核的一节叫《误操作后的三秒原则》。不是教你咋救，是教你怎么在三秒内判断“还能不能自己扛”。我试过两次。第一次，删库语句刚执行完，手指还在回车键上抖，就摸手机打 DBA 电话；第二次，在 pg_terminate_backend() 输到一半时停住，先 tail -f /var/log/postgresql/postgresql-.log 看有没有人在并发 DDL——因为上回就是两个同事同时跑 ALTER TABLE，一个锁元数据，一个锁表本身，互相等，最后靠 kill -9 postgres 进程树收场。那晚我睡办公室沙发，毯子有股消毒水混着旧毛衣的味道。

　　开发今天又来找我，说要改个字段类型。varchar(128) → text。我问他为什么，他说前端传参长度不固定。我说加个校验不行吗。他摇头：“业务方要求‘不拦’。”我点头，心里想着，他们上次说“不拦”的时候，是把一个 null 值往 datetime 字段里塞，导致整个定时任务调度器崩了仨小时。屏幕上的行数一直在跳，每秒刷新两次，像是某种倒计时。我原以为只要 schema 变更走灰度、有 rollback SQL 就算过关，结果上线后五分钟，下游服务集体报错“unexpected type mismatch”，查了一圈，发现 ORM 层居然缓存了旧的 column metadata，连重启都不管用，得清 pod 的整个 cache mount。我不懂他们为啥非要挂那个特定目录，就像我不懂为啥 nginx 配置里有个 upstream 名字叫 "backend_legacy_v3_final"，后面还跟着注释“勿删，有历史债务”——谁写的？没人认领。

　　所以别跟我说什么手册“系统全面”，它就一张皱巴巴的 A4 纸，贴在服务器机柜侧面，胶带翘边，印着几行铅笔字：“别信 dev 环境的响应时间”“任何 delete 操作前先 explain analyze”“备份恢复流程，半年练一次，否则等于没备”。我上周重练了，restore 花了四十一分钟。比去年快七分钟。可当我切到 pg_stat_database 查 pg_restore 的 last_query_time 时，发现时间戳不对——差三分钟。我愣了五秒，才想起是时区没同步，主库用 UTC+8，备份服务器还卡在 UTC。就这么个小坑，我在文档里补了一行：“restore 前先 date -s 'TZ=Asia/Shanghai'”。现在那张纸右边多了一道蓝色圆珠笔的横线，底下是我写的：“下次换 SSD，别再用 NVMe 当存储节点跑 pg_wal。”

（编辑：我爱制作网_池州站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!