Margrop
Articles274
Tags438
Categories23
1password AC ACP AI AP API AppDaemon Aqara CI/CD Caddy Cloudflare Cookie 认证 Cron D1 Date Diagrams.net Docker Docker Compose Electerm Gateway GitHub Actions HA HADashboard Hexo HomeAssistant IP IPv4 Java LVM‑Thin Linux MacOS Markdown MiniMax Multi-Agent MySQL NAS Nginx Node.js OOM OpenAI OpenClaw OpenResty PPPoE Portainer PostgreSQL ProcessOn Prometheus Proxmox VE SOCKS5 SSL Session Shell Subagent TTS TimeMachine UML Uptime Kuma VPN VPS Web WebSocket Windows Workers activate ad adb adblock agent aligenie aliyun alpine annotation aop authy autofs backup baidupan bash bitwarden boot brew browser caddy2 cdn centos cert certbot charles chat chrome classloader client clone closures cloudflare cmd command commit container crontab ctyun ddsm demo dependency deploy developer devtools dll dns docker domain download draw drawio dsm dump dylib edge exception export fail2ban feign firewall-cmd flow frp frpc frps fuckgfw function gcc gfw git github golang gperftools gridea grub gvt-g hacs havcs heap hello hexo hibernate hidpi hoisting homeassistant hosts html htmlparser https idea image img img2kvm import index install intel io ios ip iptables iptv ipv6 iso java javascript jetbrains jni jnilib jpa js json jsonb jupter jupyterlab jvm k8s kernel key kid kms kodi koolproxy koolproxyr kvm lan lastpass launchctl learning lede letsencrypt linux live low-code lvm lxc m3u8 mac macos mariadb markdown maven md5 microcode mirror modem modules monitor mount mstsc mysql n2n n5105 nas network nfs node node-red nodejs nohup notepad++ npm nssm ntp oop openfeign openssl os otp ovz p14 packet capture pat pdf pem perf ping pip plugin png powerbutton print pro proxy pve pvekclean python qcow2 qemu qemu-guest-agent rar reboot reflog remote remote desktop renew repo resize retina root route router rule rules runtime safari sata scipy-notebook scoping scp server slmgr so socks source spk spring springboot springfox ssh ssl stash string supernode svg svn swagger sync synology systemctl systemd tap tap-windows tapwindows telecom template terminal tls token totp tvbox txt ubuntu udisk ui undertow uninstall unlocker upgrade url v2ray vhd vim vlmcsd vm vmdk web websocket wechat windows with worker wow xiaoya xml yum zip 中国电信 云电脑 交换机 人机协作 代理 体检 值班 健康检查 光猫 公网IP 内存 内存优化 内网IP 写作 升级 协作 博客 反向代理 启动 周一 周末 夏令时 多智能体 多节点 多节点管理 天猫精灵 天翼云 安全 安装 定时任务 容器 容器网络 导入 小米 常用软件 广告屏蔽 序列号 应用市场 异常 心跳 感悟 打工 打工人 技术 抓包 排查 描述文件 故障 故障排查 效率 效率工具 无服务器 日记 时区 显卡虚拟化 智能家居 智能音箱 服务管理 架构 梯子 模块 流程 流程图 浏览器 漫游 激活 火绒 焦虑 玄学 生活 电信 画图 监控 直播源 直觉 端口扫描 管理 续期 网关 网络 网络风暴 群晖 脚本 腾讯 自动化 虚拟机 认证 证书 语雀 超时 路由 路由器 软件管家 软路由 运维 运维监控 连接保活 通信机制 部署 配置 钉钉 镜像 镜像源 门窗传感器 问题排查 防火墙 阿里云 阿里源 集客

Hitokoto

Archive

周一早上刚坐到工位,钉钉就已经发来了三个告警

周一早上刚坐到工位,钉钉就已经发来了三个告警

周一早上刚坐到工位,钉钉就已经发来了三个告警

周一早上八点四十五,我端着咖啡准时出现在工位上。这个时间点我已经维持了快两年——不算早,但也不能算迟,刚好卡在”领导还没到但同事已经来了一半”的那个区间。

刷卡、开机、倒咖啡。这是我每天到公司后的固定流程,三件事做完大概需要五分钟。往常这五分钟是平静的,钉钉还算安静,Prometheus图标还是绿的,我的咖啡还能保持刚倒出来时的温度。

但今天不一样。

刚把咖啡放到桌上,手机就震动了。解锁一看,好家伙,钉钉已经积攒了三条未读消息,全是监控告警。三条告警,像三道闪电,把我周一早上的好心情劈得七零八落。

第一条:某VM的磁盘空间不足,触发阈值80%。
第二条:某个Gateway的连接数异常,比平时高了30%。
第三条:某个服务的健康检查连续失败三次。

我端着咖啡的手停在半空中,看着这三条消息,脑子里快速过了一遍:磁盘、连接、健康检查。三个问题,三个不同的服务,之间可能有关联,也可能没有。它们就像周一早上送来的”豪华午餐”,不,我已经吃过了——代价是整个上午。

周一早上是个特殊的时段

作为一个在上海打工的运维工程师,我对周一早上有着深刻的理解。这种理解不是来自书本,而是来自无数次血的教训。

周一早上,是一个特殊的时段。它之所以特殊,是因为它集合了好几个”不利因素”:

第一,经历了两天周末的”积累”。 周六周日虽然大部分人不上班,但服务器可不休息。定时任务照跑、日志照写、缓存照积、数据库照更新。两天的积累下来,原本不起眼的小问题,可能就变成了触发告警的大问题。

你想啊,一个日志文件,周末两天没人管,它就可能从100MB变成10GB。一个连接池,周末没人用,可能就慢慢泄漏了。一个缓存,周末没人刷新,可能就过期了但还在被调用。这些问题平时都被”周一到周五的正常工作”给掩盖了,周末反而成了它们”展示”的窗口。

第二,系统负载呈现”阶梯式”回升。 周一早上九点开始,用户陆续回来上班,系统负载从周末的低谷开始爬升。这个爬升过程往往伴随着各种意想不到的问题——连接池不够用了、缓存命中率下降了、前端静态资源加载变慢了、数据库慢查询突然增多了,诸如此类。

这就像你家的水管,早上九点大家都在用水,水压就可能不够。你平时一个人住感受不到,但周一早上突然多出来几十个人同时用水,问题就来了。服务器也是一样的道理。

第三,人的状态还没完全恢复。 周末休息了两天,周一早上多多少少有点”假期综合症”。反应慢半拍、注意力不太集中、看到告警要愣两秒才能想起这个问题是什么。这对于需要快速响应的运维工作来说,可不是什么好事。

我上周五还处理了个什么问题来着?周一早上再看到类似的问题,我的反应是”这个问题我好像见过”,然后愣了两秒才想起来”哦,上周五那个不是这个问题,那个是另一个问题”。

所以周一对运维来说,往往是最忙的时候。不是因为工作本身有多复杂,而是因为问题多,而且人的状态还没完全恢复,处理起来效率也低。这种”身心俱疲还要处理一堆破事”的感觉,大概只有做过运维的人才懂。

三个告警的”豪华午餐”

回到今天早上的三个告警。

先说第一个:磁盘空间不足。告警显示某台VM的根分区使用率超过了80%。我SSH上去一看,好家伙,/var/log目录下有个日志文件已经吃掉了20GB。这个日志文件是某服务的访问日志,从今年年初写到现在的,每天一个文件,日积月累就成了现在这副模样。

说实话,看到这个我是有点无语的。logrotate配置了没有?配置了。日志轮转为什么不生效?查看了一下配置,发现日志轮转的触发条件是”文件大小超过100MB”,但这个日志文件是按日期切割的,每天一个文件,每天那个文件都是100MB左右,不多不少,刚好卡在100MB以下,所以logrotate认为”这文件还没到需要轮转的大小”,就不管它了。

行吧,又是一个经典的历史遗留问题。先手动清理一下,把这个文件归档压缩,腾出空间让服务先跑起来。然后改一下切割策略,这个问题就算暂时处理了。但根本解决方案还是要改代码,让日志按大小轮转而不是按日期——这个问题我记下了,回头要找机会改。

第二个告警:Gateway连接数异常。比平时高了30%,从平均500并发跳到了650。这个数字听起来不算夸张,但对于我们这种架构来说,连接数飙升往往意味着有问题。先看看是不是业务量真的涨了,查了一下记录,发现连接数上升的时间点刚好是早上八点半左右——这个时间点正常情况下业务量不应该有这么大的波动。

那就不是业务原因了。

再看详细日志,发现是某几个IP在频繁建立新连接但从不关闭。断开再重连,断开再重连,每分钟重复几十次。这种行为通常意味着两种可能:要么是客户端配置有问题,要么是有人在”蹭”服务。

最后查出来是某台探针服务的配置有问题,它本来应该是长连接的,但配置被改成了”短连接模式”,导致每几秒就重新建立一次连接。长连接变成了短连接,每次连接都走一遍握手流程,连接数自然就飙起来了。

改回配置,重启服务,连接数恢复正常。这个问题其实两周前就有苗头了,当时连接数就在慢慢涨,从520到540再到560,每次涨一点点,我每次看到都觉得”应该问题不大”,就没管。结果今天直接飙到650,触发告警了。

又一次验证了那句话:问题不等人,你不找它,它就来找你。

第三个告警:健康检查连续失败。某服务的/health端点返回了500错误。这是一个比较紧急的告警,因为健康检查失败意味着服务可能已经不可用了。用户访问网站,发现打不开,刷新还是不行,最后就问你”网站怎么坏了”。

SSH上去看日志,发现是数据库连接池耗尽了。连接池最大100个,现在全部被占用,新的请求进不来,自然就报错了。

查了一下具体原因,发现是某个查询语句没有加索引,导致全表扫描,执行时间从正常的50毫秒变成了30秒。30秒的查询,100个连接池,瞬间就塞满了。新请求来了,没连接可用,只能报错。

加索引、重启服务、恢复。这个问题看似简单,但根因是代码层面没有做好优化。又是历史遗留问题,又是某个”当时没考虑周全”的代码留下了隐患。这段代码可能是一个实习生写的,也可能是一个老员工三年前写的,反正现在找到责任人已经不可能了,只能自己默默承受。

三个告警,处理完已经十一点了。咖啡从滚烫变成了温凉,一口都没来得及喝。我看了眼时间,心想还好还好,没到午饭时间,还算高效。

问题从来不是单独出现的

处理完这三个告警,我坐在工位上发了会儿呆。

咖啡已经凉透了。工作群里的消息已经堆了几十条——都是处理告警时发的”问题已处理”、”服务已恢复”、”原因已定位”之类的废话。邮箱里还有十几封未读邮件,我懒得看,估计又是周报和会议通知。

然后我突然想到一个问题:这三个问题之间,有没有可能是有关联的?

仔细想了想,还真可能有。

磁盘空间不足,导致某日志写入变慢,影响了某服务的响应时间。响应时间变慢,导致长连接超时,客户端断开重连,重连频率上升,连接数就飙升了。连接数飙升,加上某查询没有索引,数据库连接池被塞满,健康检查就失败了。

你看,这一环扣一环的,说不定还真是个连锁反应。

但问题是,我没办法证明这一点。因为:

  1. 磁盘空间不足不会立即影响服务响应
  2. 日志写入慢也不一定导致连接超时
  3. 连接数飙升可能有其他原因

我只能猜测,猜测完了也不能验证。只能”头痛医头脚痛医脚”,把三个问题分别处理了,然后祈祷它们不会再一起出现。

这就是运维工作的日常。你遇到一个问题,处理一个问题,但永远不知道这个问题是不是更大问题的一部分。你永远在打地鼠,但地鼠永远打不完。

周一早上的感悟

处理完这三个告警,我坐在工位上发呆了一会儿。

说实话,有那么一瞬间是有点沮丧的。

明明周末休息了两天,以为自己新的一周会有个好的开始。结果周一早上就来了这么一出。三个问题,处理了三个小时,咖啡凉了、早餐没吃、心情也不太好了。

但是转念一想,好像也习惯了。

运维这份工作就是这样。你永远不知道下一个告警是什么,也永远不知道问题会在什么时候出现。周一早上的”惊喜大礼包”已经算是比较温和的了,至少不是凌晨两点把你叫醒的那种。至少我今天还睡了个好觉才来的,虽然睡眠质量可能不太行,但至少是躺在床上的那种睡眠,不是坐在电脑前盯着监控屏幕的那种。

想通了这一点,反而轻松了一些。告警来了就处理,处理完就继续处理下一个。这不就是运维的日常吗?

与其抱怨为什么周一会出问题,不如想想怎么让下周一不再出同样的问题。三个问题已经处理完了,但根因还没解决。下周要做的事情:

  • 日志切割策略要改,按大小轮转而不是按日期
  • 监控要加上去,连接数异常要提前告警而不是等爆发了才告警
  • 代码审查要加索引检查,避免再出现全表扫描

这些事情做完,下周一可能还是会来三个告警,但至少不会是同样的三个。下一个三个告警,会是新的三个问题,我还能学到新的东西。这么一想,好像也没那么糟。

打工人的周一

最后想说几句关于打工人的话。

周一对打工人来说,总是特殊的。不管你是做什么工作的,周一都意味着”假期结束”。这种感觉从学生时代就开始了,我们都知道周一要上班,所以周日的晚上往往睡不好,想着”明天又要上班了,好烦啊”。

这种心理状态,不是一种”想不想上班”的问题,而是一种”对未知事件的焦虑”。你不知道这周会遇到什么问题,不知道这周要加多少班,不知道这周会不会又有什么”惊喜”在等着你。学生时代是担心考试,工作中是担心告警,本质上都是对未知的恐惧。

我的应对方式是:做好心理准备,然后接受它。

周一早上到公司,先深呼吸三次,告诉自己:”这一周可能会遇到各种问题,但没关系,问题总会解决的。紧张也没有用,放轻松,该来的总会来。”

然后打开钉钉,看告警,开始干活。

告警不会因为你的心情好就不出现,但你可以因为自己的心态好而更快地处理它。这是我这些年总结出来的经验。

好了,今天的周记就写到这里。下周一的告警大礼包,我们下周再见。


作者:小六,一个在上海努力生存的普通打工人,今天的咖啡虽然凉了,但周一还会继续,告警也会继续,而我也会继续

Author:Margrop
Link:http://blog.margrop.com/post/2026-04-20-monday-three-alerts-at-work-start/
版权声明:本文采用 CC BY-NC-SA 3.0 CN 协议进行许可