Axis笔记

外观

3.3 处理与升级步骤

约 516 字

排查手册

本页对应「三、操作步骤」的 3.3，完成处理与升级步骤。返回上级：故障排查操作手册。

前置条件

  • 3.1 与 3.2 已完成，故障层与首条错误均已确认。
  • 掌握最近一次变更的版本号与备份位置。
  • 已知升级联系人与各自的响应时限。

操作步骤

  1. 按止血优先原则处理，先恢复可用性再查根因。
sudo systemctl reload nginx
sudo systemctl restart axis-api
systemctl is-active nginx axis-api
  1. 若与最近发布相关，直接回滚到上一版本。
ls -l /srv/axis/www/releases
sudo -u deploy ln -sfn /srv/axis/www/releases/202606080900 /srv/axis/www/current
sudo nginx -t && sudo systemctl reload nginx
  1. 检查资源是否耗尽，先做保护性降级。
df -h /srv/axis
free -m
sudo journalctl -u axis-api --since '-10 min' --no-pager | tail -n 30
  1. 达到以下任一条件即升级，不继续单人尝试：15 分钟内未恢复、影响登录或支付、存在数据损坏风险、需要改动机房或云资源。
/srv/axis/scripts/alert.sh P1 "site down over 15min, escalated to on-call"
  1. 记录时间线与交接信息。
cat <<'EOF' | sudo tee -a /srv/axis/logs/incident.log
time: 2026-06-08T09:20+08:00
impact: example.com 全站 502，约 8 分钟
action: 回滚至 202606080900 版本，已恢复
next: 交由后端排查新版本连接池配置
EOF

结果确认

  • 核心页面 curl -sSI https://example.com 返回 200。
  • 监控平台状态恢复正常，并收到恢复通知。
  • 事件记录包含起止时间、影响范围、处置动作与后续责任人。
  • 接手人能在 5 分钟内从记录中还原现场并继续处理。

注意事项

  • 回滚是止血手段，不是根因修复；恢复后仍需定位原版本的问题。
  • 升级时提供事实与已做操作，不要只发一句“服务挂了”。
  • 未确认根因前不要删除日志与临时文件，那是复盘依据。
  • 升级后本机仍保持观察，直到接手人明确确认接管。