凌晨两点网站打不开:一个人值班时的前 15 分钟排查顺序
按固定顺序确认影响、看资源、查入口和应用、只看故障窗口日志,动手前先写好最小动作和回退。
更新于
从你遇到的现象开始。这些指南不依赖 OpsMate,并区分诊断检查和会改动服务器的操作。
按固定顺序确认影响、看资源、查入口和应用、只看故障窗口日志,动手前先写好最小动作和回退。
不会 Linux、不会 SSH 时,先换网、看云控制台、记证据。会登录后再按 15 分钟顺序排查。
不会管理服务器时,先确认影响面、看云控制台、保存证据,再决定找谁。面板能用的继续用。
用测试机和 SSH 私钥,从注册到在 OpsMate 里打开终端。没装 Docker 或非 root 也能扫完主机信息。未通过安全检查的命令会被拦截且不会执行。低风险修复默认自动执行,每一步都会记录。
OpsMate 把 SSH 终端和 AI 放在同一页:不会命令就用自然语言排查,会一点就手敲 uptime/df。未通过安全检查的命令会被拦截且不会执行。低风险修复默认自动执行,每一步都会记录。证据留在终端。
人不在电脑前时,先在 Telegram 私聊看巡检告警卡片,再决定是否用自然语言继续排障。
用一条消息描述问题,AI 通过 SSH 跑检查命令。每个处置按风险分三档:低风险的(比如有把握的服务重启、日志轮转)会直接自动执行;中风险的(比如改配置、重建容器)会先发给你审批,30 分钟内没人处理也会自动执行;高风险的(改数据库结构、内核参数、网络和防火墙)只告警、不执行。系统拿不准的时候,会按更高一档处理。未通过安全检查的命令会被拦截且不会执行。低风险修复默认自动执行,每一步都会记录。远程 SSH 需要云端密钥;大改动、回滚和长时间观察回到电脑前做。
先确认容器状态和退出码,再看每个退出码通常意味着什么、不能说明什么,最后找日志里的第一条异常。
退出码 137 只说明收到 SIGKILL。用 OOMKilled、docker events 和内核日志查清是内核 OOM Killer、Docker 还是宿主机上的其他东西,再决定下一步。
先确认是重启循环,再查重启策略和退避、健康检查、依赖是否就绪,以及内存、磁盘和端口。
服务器内存使用率 88% 算不算问题?先看 available 而不是 used,再查 swap 换页、内存压力(PSI)和 OOM 记录;附一次真实测试环境里的告警记录。
df 显示磁盘满时,先区分容量与 inode,再用 docker inspect 确认是否 json-file 日志在涨;维护窗口再配 max-size/max-file。
Linux 磁盘突然满了?3 步排查:用 df -h 和 df -i 分清是容量还是 inode,用 du 找出变大的目录,再看是日志、业务数据还是已删除仍被占用的文件。
.env、配置文件、Shell 历史、docker inspect、crontab 和 Git 历史里可能藏着明文密码和 Token。3 步只读自查,再按「先换新、再删除」处置,附发日志给 AI 前的脱敏命令。
502 Bad Gateway 怎么解决?Nginx 返回 502 说明上游出了问题。对照 error.log 报错原文(Connection refused、prematurely closed、invalid header),在 Ubuntu 上一步步排查和修复。
没有专职运维时,按外部可用性、资源、服务、日志、备份和告警责任人建立最小监控;含只读基线、告警规则与 OpsMate 巡检用法。
区分登录尝试与成功登录,检查异常进程和持久化痕迹;先保留证据,不做入侵结论,疑似入侵时升级处理。
先列出对方能碰到的地方,查谁还能登录;先配好自己的密钥再锁定对方账号,每一步都先备份、留好回退,最后换掉他看过的密钥,清理遗留的定时任务。
接手别人搭的服务器:先盘点服务、端口、备份和证书,写成一页清单,再建立每周检查和升级路径。
网站半夜打不开,或登录记录里出现可疑 SSH 登录,都先按对应指南做只读排查,再决定要不要改服务器。
OpsMate(itops.sh)把 SSH 终端和 AI 放在同一页,由你核对证据。每次让 AI 帮忙看,终端里最近的输出都会一起发到云端 AI,敏感信息请先去掉。
免费开始 本地凭证桌面端