Диагностика и восстановление после сбоев

1. Типовые картины

2. Порядок работы

2.1 Сначала чтение (без изменений)

• Модель: статус машин/приложений, неприменённые изменения, латентность API.
• События: severity, LIVE, occurrences, details.
• Задачи: FAILURE, REVOKED, залипшие.
• Журналы служб (не общий журнал): scalerd, haproxy, samurai, nginx, mongod.
• Железо: SMART, mdstat, ipmitool, ps по RSS.
• Сеть: ping по storage-сети, маршруты, VLAN на свиче по MAC.

2.2 Гипотеза → проверка

Каждая версия проверяется отдельно; совпадение по времени — не доказательство причины. Если причина не доказана — так и пишем в отчёте.

2.3 Штатное решение

• Через GUI/CLI/Model API/плейбук продукта.
• Файлы продукта — только значениями из модели, с бэкапом вне каталога продукта.
• Деструктивные шаги — с бэкапом и отмашкой.

2.4 Проверка и наблюдение

• Конкретные коды/значения (200, 307, ONLINE, barometer: ok).
• Наблюдение 1–24 часа: не вернулось ли событие.

3. Чего не делать

• Не переустанавливать систему до диагностики.
• Не менять пароли/учётки, когда модель просто медленная.
• Не форматировать диски «чтобы пересоздать».
• Не править iptables/конфиги руками «навсегда» — продукт перерисует.
• Не удалять события/кассеты, чтобы «стало зелёным».
• Не запускать bash -lc в скриптах на нодах (login-shell ждёт stdin).

4. После аварии питания: порядок

1. BMC: проверить доступ; при необходимости сбросить пароль штатной IPMI-командой.
2. mongod: проверить, что на каждой ноде три процесса (27017/27018/27019); поднять из конфига продукта, если не поднялись.
3. Модель: замерить латентность; дождаться PRIMARY + 2×SECONDARY.
4. Сеть: default route на всех нодах, storage-кольцо.
5. NTP: синхронизация и расхождение часов.
6. Приложения: marvinservices, приложения ONLINE.
7. S3: 307 на фронте, round-trip.

5. Что получает заказчик

• Восстановленная работоспособность.
• Разбор: что было, почему, что сделано, чем подтверждено.
• Что осталось (временные меры/наблюдение).
• Профилактика: что настроить, чтобы не повторилось.

6. Срочность

• Удалённая диагностика — в рабочий день; аварийные окна — по согласованию.
• Для продуктивных систем — только с согласованным доступом и окном.
• Если нужен вендор — помогаем собрать факты и эскалировать.

Частые вопросы

Узел красный или NOTCONFIGURED — что делать? Сначала прочитать, а не перезагружать: посмотреть задачи и журнал службы, неприменённые изменения, не остался ли висеть ручной процесс, который держит блокировку. Причина часто в неприменённом изменении или упавшем configure, а не в железе. Переустановка до диагностики стирает следы причины — поэтому она последняя, а не первая.

Можно ли обойтись без переустановки? В большинстве картин, которые мы разбирали, — да. Уехавшие часы, потерянный default route, разорванное storage-кольцо, не поднявшиеся mongod, политика DSS, не влезающая в число блоксторов, лечатся штатным путём. Переустановка — крайняя мера, когда причина доказана и других вариантов не осталось.

Сколько занимает восстановление? Зависит от причины, поэтому сроков «за N минут» не обещаем. Чтение фактов и постановка гипотезы — быстрые; дальше проверка каждой версии и штатное решение. После аварии питания порядок фиксированный: BMC, mongod, модель, сеть, NTP, приложения, S3. После исправления наблюдаем от часа до суток: не вернулось ли событие.

Что если нет бэкапа модели? Работаем от фактов: состояние железа, диски, сеть, конфигурация служб, то, что сохранилось в самой модели продукта. Это дольше и не всё гарантирует — политики, IAM и реестр кассет придётся сверять вручную. Поэтому снимок конфигурации и модели — обязательный пункт регламента, а не «когда дойдут руки».

Как не повторить аварию? Профилактика входит в отчёт: выровнять время и NTP, зафиксировать default route, проверить резервирование питания и storage-кольцо по VLAN, привести политику DSS в соответствие числу блоксторов, поставить мониторинг на события и задачи, а не на «зелёный GUI». Плюс регламент и инструкция, что делать первым.