OpeItcLoc03/admin
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
2e5adcf11ec27bd88ad95515959f38bbaacc11fe
admin/.wiki/sources/vds-kzntsv-incident-2026-05-28.md
vitya 11554d45ac wiki(ingest): vds-kzntsv network-stack mismatch RCA + ifupdown anti-pattern 
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>
2026-05-28 14:12:14 +03:00

8.8 KiB
Raw Blame History

title, type, tags, ingested, raw_path, updated
title type tags ingested raw_path updated
vds-kzntsv outage incident — session chronology 2026-05-28 source
vds
rusonyx
network
dhcp
outage
session-trace
2026-05-28 (none — session-live, no external raw) 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-команды:

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

Reference in New Issue View Git Blame Copy Permalink