vitya
11554d45ac
Incident 2026-05-28 ~05:45–13:52 MSK на vds-kzntsv. ~2.5ч активного outage + ~5.5ч на эфемерной статике до окончательного fix хостером. Revised RCA: наш netplan+systemd-networkd конфликтовал с provider's expected ifupdown stack. Их start/ipadd procedure ожидает чистый ifupdown и не может auto-recover когда networkd «держит» eth0. 8 дней работало потому что networkd сам тянул DHCP. Когда что-то на стороне Rusonyx разорвало DHCP-binding — auto-recovery не сработала. Fix: systemctl mask netplan + systemd-networkd* (на running system без stop — IP и SSH сохранились), Rusonyx ребутнул VM и положил чистый /etc/network/interfaces.d/ifcfg-eth0 через свой start/ipadd. Netmask /18, gw 89.253.192.1, чистый ifupdown. Wiki: - NEW concepts/vds-kzntsv-dhcp-outage-2026-05-28 — full RCA + recovery runbook (эфемерная статика + permanent-fix via ifupdown) + diagnostic dot-graph + revised lessons-learned + anti-pattern - NEW sources/vds-kzntsv-incident-2026-05-28 — timeline 05:25 backup OK → 08:43 statics → 13:52 final reset; provider's ifcfg-eth0 content; ticket text reference - UPDATE entities/vds-kzntsv — mask /18, ifupdown stack, kernel cmdline net.ifnames=0 объясняет eth0 naming, hypervisor hw80, pass-store путь, Known issues § - UPDATE concepts/rusonyx-vps-onboarding-quirks — quirk #9 переписан про /18 layout + canonical ifcfg, quirk #10 NEW про ifupdown vs netplan stack choice + bootstrap mask commands - UPDATE index.md + log.md Tasks: - STATUS header: incident RESOLVED summary - NEXT_SESSION: следующая сессия — cleanup netplan-artifacts (optional), registry GC (~20G pending), board-viewer-build unhealthy разбор Memory (out-of-repo): vds-kzntsv-rusonyx-network-recovery переписан с revised RCA — canonical bootstrap step «mask netplan/networkd» для всех Rusonyx Ubuntu VDS. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
127 lines
8.8 KiB
Markdown
127 lines
8.8 KiB
Markdown
---
|
||
title: vds-kzntsv outage incident — session chronology 2026-05-28
|
||
type: source
|
||
tags: [vds, rusonyx, network, dhcp, outage, session-trace]
|
||
ingested: 2026-05-28
|
||
raw_path: (none — session-live, no external raw)
|
||
updated: 2026-05-28
|
||
---
|
||
|
||
# vds-kzntsv incident chronology 2026-05-28
|
||
|
||
Live-session трасса диагностики и восстановления отказа [[../entities/vds-kzntsv]]. Полный разбор паттерна + recovery runbook — в [[../concepts/vds-kzntsv-dhcp-outage-2026-05-28]].
|
||
|
||
## Timeline (MSK)
|
||
|
||
| Время | Событие | Источник |
|
||
|---|---|---|
|
||
| 2026-05-28 05:25 | Daily backup pipeline `vds-backup-rsync-kreknin` стартует | ntfy-уведомление пользователю |
|
||
| 2026-05-28 05:45 | Backup завершён успешно — 19m51s, 69G, 7 snapshots передано на kreknin | ntfy + backup log |
|
||
| 2026-05-28 ~06:00–08:00 | (окно отказа DHCP — точное время неизвестно) | — |
|
||
| 2026-05-28 ~08:15 | User обнаруживает что vds-kzntsv недоступен по сети, пинг падает на хостер-gateway | user message |
|
||
| 2026-05-28 08:20 | Сессия с агентом начинается, запрос креды на VDS | conversation |
|
||
| 2026-05-28 08:25 | Probe с workstation и с [[../entities/books-vds]] (same hoster) — оба `Destination Host Unreachable` на `89.253.192.40` | bash output |
|
||
| 2026-05-28 08:30 | User открывает Rusonyx panel → VNC console, шлёт скриншот журнала | screenshot |
|
||
| 2026-05-28 08:35–08:42 | Диагностика через VNC: `ip -br link` → eth0 UP без IPv4; `networkctl status` → degraded (configuring), LLDP видит `hw80.rusonyx.ru` | screenshots |
|
||
| 2026-05-28 08:43 | Recovery через статику (3 команды + DNS) — IP получен, маршруты добавлены | user confirms "Заработало!" |
|
||
| 2026-05-28 08:44 | SSH с workstation работает; uptime 1h (VDS был ребутнут ~07:44, но IP DHCP всё равно не пришёл) | `ssh vitya@89.253.255.94 hostname` |
|
||
| 2026-05-28 08:44 | 18 docker контейнеров поднялись через restart policy — gitea, registry, verdaccio, postgres, mariadb, mongo, owncloud, oCIS, modulair-rag стэк и пр. | `docker ps` |
|
||
| 2026-05-28 08:50 | Disk cleanup: docker builder prune (10.6G) + image prune (0.3G) + truncate container logs (~3G); disk 89% → 79% | `df -h /` before/after |
|
||
| 2026-05-28 09:00 | Тикет в Rusonyx отправлен | user sends |
|
||
| 2026-05-28 ~12:20 | Rusonyx отвечает: «возможно потребуется перезагрузка», запрашивают разрешение | helpdesk |
|
||
| 2026-05-28 ~12:25 | Даём разрешение с условиями (5-10мин уведомление + готовность VNC к recovery) | helpdesk |
|
||
| 2026-05-28 ~13:00 | Rusonyx: «настройте дефолт — `mask netplan + systemd-networkd`, `enable networking`» | helpdesk |
|
||
| 2026-05-28 ~13:20 | После уточнений согласовали что они сами пропишут конфиг через свой `start/ipadd` | helpdesk |
|
||
| 2026-05-28 ~13:30 | Выполнен `systemctl disable+mask netplan + systemd-networkd.{service,socket,wait-online}` через SSH. IP и SSH остались живые. | session bash |
|
||
| 2026-05-28 ~13:52 | Rusonyx ребутает VM с reset-конфига через их provisioning | их сторона |
|
||
| 2026-05-28 14:00 | Smoke: SSH + 24 контейнера up + `api.ipify.org → 89.253.255.94`. Сервер полностью восстановлен. | session bash |
|
||
|
||
## Что сломалось
|
||
|
||
- DHCP lease для VM `vps534388` (MAC `52:54:00:9c:63:01`) на гипервизоре `hw80.rusonyx.ru` не возобновлялся.
|
||
- VM выпала из L3-сети полностью: своя сторона корректна (link UP, networkd шлёт DHCP discover), хостер не отвечает offer'ом.
|
||
- Reboot VM не помог.
|
||
|
||
Подробные подтверждающие сигналы — в [[../concepts/vds-kzntsv-dhcp-outage-2026-05-28]] § Симптомокартина.
|
||
|
||
## Что починили
|
||
|
||
Статика на eth0 через 3 ip-команды:
|
||
|
||
```bash
|
||
sudo ip addr add 89.253.255.94/24 dev eth0
|
||
sudo ip route add 89.253.192.1 dev eth0
|
||
sudo ip route add default via 89.253.192.1
|
||
```
|
||
|
||
DNS: `nameserver 89.253.252.30/.31` (Rusonyx).
|
||
|
||
**Эфемерно.** Persistence в netplan **отложен** до ответа хостера — если они починят DHCP, persistent статика конфликтнёт.
|
||
|
||
## Gateway discovery — как нашли 89.253.192.1
|
||
|
||
Gateway у Rusonyx сидит в /18 надсети `89.253.192.0/18`, а не в нашей /24. Источник — `ip route` на [[../entities/books-vds]] (sibling VPS у того же хостера):
|
||
|
||
```
|
||
$ ssh root@89.253.255.133 'ip route'
|
||
default via 89.253.192.1 dev eth0 metric 400
|
||
89.253.192.0/18 via 89.253.192.1 dev eth0 src 89.253.255.133 metric 400
|
||
89.253.192.1 dev eth0 scope link metric 400
|
||
89.253.255.0/24 dev eth0 proto kernel scope link src 89.253.255.133
|
||
```
|
||
|
||
См. также quirk #9 в [[../concepts/rusonyx-vps-onboarding-quirks]].
|
||
|
||
## Финальная конфигурация (после resolution хостером 13:52 MSK)
|
||
|
||
`/etc/network/interfaces.d/ifcfg-eth0` (положен их `start/ipadd` procedure):
|
||
|
||
```
|
||
auto eth0
|
||
allow-hotplug eth0
|
||
iface eth0 inet static
|
||
address 89.253.255.94
|
||
netmask 255.255.192.0
|
||
post-up ip ro add 169.254.0.0/16 dev eth0 metric 400
|
||
post-up ip ro add 89.253.192.1 dev eth0 metric 400
|
||
post-up ip ro add default via 89.253.192.1 dev eth0 metric 400
|
||
post-up ip ro add 89.253.192.0/18 via 89.253.192.1 dev eth0 src 89.253.255.94 metric 400
|
||
post-up ip ro del 89.253.192.0/18 dev eth0 proto kernel scope link src 89.253.255.94
|
||
```
|
||
|
||
Изменение по сравнению с тем что было до инцидента:
|
||
- **Сетевой стек** — был mixed (netplan + networkd поверх ifupdown), стал чистый ifupdown
|
||
- **Netmask** — стал /18 явно (`255.255.192.0`) вместо неявного /24 + link-route trick
|
||
- **systemd unit state:** `netplan` masked, `systemd-networkd*` masked, `networking` enabled
|
||
|
||
Kernel cmdline без изменений: `net.ifnames=0 biosdevname=0` (Rusonyx force eth0 naming).
|
||
|
||
## Тикет в Rusonyx — итоговый текст
|
||
|
||
Тикет отправлен через myvm.rusonyx.ru helpdesk, account `21075162`, тема: «VPS 534388 (vps-21075162-534388) — нет DHCP lease ~05:45 28.05.2026 MSK».
|
||
|
||
Основная часть:
|
||
- Подтверждённое окно простоя ~2.5ч (с 05:45 — последний успешный backup — до 08:30 recovery).
|
||
- Отсутствие уведомления с их стороны.
|
||
- Корневая причина на стороне хостера, с конкретикой (LLDP, networkd journal, отсутствие DHCPv4 offer'ов).
|
||
- Диагностика клиентом, не support'ом — что не норма для production-уровня услуги.
|
||
- Запрос: (a) технический RCA, (b) SLA-компенсация, (c) procedural followup по их мониторингу VM-уровня, (d) статус DHCP — починен или фиксируем статику постоянно.
|
||
|
||
Полный текст — в сессионной переписке `~/.claude/projects/C--Users-vitya-projects--admin/` (conversation log).
|
||
|
||
Ответ хостера ещё не получен (на момент ingest этого source).
|
||
|
||
## Что обнаружили попутно
|
||
|
||
1. **Диск 89% → 79% после GC** — освободили 14G (build cache 10.6G + dangling images 0.3G + container logs ~3G). Disk-GC pending давно, см. `vds-kzntsv` § Open issues. Поставлена task [[../../.tasks/vds-kzntsv-disk-gc-followup]] на полный registry-GC (20G возможный reclaim).
|
||
2. **`board-viewer-build` unhealthy** — отдельная история, не блокер сейчас.
|
||
3. **`ping` не установлен** на VDS — Ubuntu 24.04 base не включает iputils-ping. Использовали curl для проверки сети. Можно установить `apt install iputils-ping` при следующем maintenance.
|
||
|
||
## Cross-refs
|
||
|
||
- [[../concepts/vds-kzntsv-dhcp-outage-2026-05-28]] — runbook + RCA-pattern.
|
||
- [[../entities/vds-kzntsv]] — host details.
|
||
- [[../entities/books-vds]] — sibling, source для gw discovery.
|
||
- [[../concepts/rusonyx-vps-onboarding-quirks]] — vendor quirks, дополнен quirk #9.
|
||
- [[vds-kzntsv-bootstrap-2026-05-20]] — оригинальный bootstrap.
|