Отказоустойчивость выключили на время: почему простой неизбежен

«Отключим отказоустойчивость на время работ» — фраза, которая звучит ответственно в момент обслуживания кластера. Миграции ВМ, обновление гипервизора, замена СХД, «чтобы быстрее переехало». Работы закончились в субботу. В понедельник все заняты тикетами. Через месяц высокая доступность всё ещё выключена. Через квартал падает узел — и выясняется, что автоматического перезапуска критичных машин нет. Простой уже не гипотеза.

В виртуализации отказоустойчивость (или аналог автозапуска/переключение на резерв) — не красивая галочка в лицензии. Это договорённость с бизнесом: при отказе хоста сервисы поднимутся на живых узлах за минуты, а не за часы ручного героизма. Когда режим оставлен выключенным «временно», компания фактически живёт на одном кубике удачи.

Как «временно» становится нормой

• в чеклисте работ нет пункта «вернуть отказоустойчивость и подтвердить скрином/мониторингом»;
• после обслуживания «всё пингуется» — и считают задачу закрытой;
• кластер в предупреждении, алерты заглушены как шум;
• часть ВМ исключили из отказоустойчивость из-за старого бага и забыли вернуть;
• новый админ не знает, что режим должен быть включён, документации нет.

Особенно опасно сочетание: отказоустойчивость выключена + бэкапы не тестировали + единственный путь к СХД. Отказ одного компонента превращает «окно работ» в полноценный простой офиса, 1С, телефонии или сайта.

Что теряет бизнес, когда переключение на резерв молчит

Директору не нужна лекция про распределение нагрузки. Ему нужна оценка: сколько минут простоя стоит час выручки или штрафа SLA — и почему автомат был выключен месяцами.

Технический минимум, о котором забывают

отказоустойчивость не работает «сам по себе», если нет ёмкости на соседях: зарезервированные ресурсы, совместимость CPU, доступность датасторов, корректные зависимости ВМ, актуальные VM Tools/агенты. Иногда режим включают, а при падении ничего не поднимается — и делают ложный вывод «отказоустойчивость бесполезен». На деле не проверили admission control и связность хранилища.

Отдельно: выключение отказоустойчивости «чтобы быстрее» при работах часто маскирует отсутствие нормального плана эвакуации и тестового окна. Ускорение сегодня покупается риском завтра.

Ошибки обслуживания кластера

Отключить защиту на всём кластере, хотя работали с одним хостом. Масштаб риска несоразмерен задаче.

Не зафиксировать в журнале изменений время выключения и ответственного за включение. Без владельца «временно» бесконечно.

Игнорировать предупреждения о недостаточном резерве. отказоустойчивость включён формально, но при отказе места не хватит — итог тот же простой.

Считать репликацию СХД заменой отказоустойчивость на уровне гипервизора. Это разные слои: один про диск, другой про автозапуск вычислительных машин.

После инцидента «починить руками» и не провести postmortem: почему автомат был off, какой пункт чеклиста пропущен.

Как вернуть дисциплину высокой доступности

1. Инвентарь. Какие ВМ критичны, где должен быть отказоустойчивость/автозапуск, какие исключения осознанны.
2. Проверка факта. Не «вроде включено», а статус кластера + тест на стенде или контролируемый переключение на резерв в окно.
3. Чеклист работ. Любое обслуживание: before (статус) → работ → after (отказоустойчивость on, алерты живые, скрин/заявка).
4. Мониторинг. Алерт не только «хост down», но и «отказоустойчивость disabled» / «insufficient resources».
5. Резерв ёмкости. Явный N+1 или согласованный риск с бизнесом — без самообмана.
6. Регламент исключений. ВМ вне отказоустойчивость только с датой пересмотра и подписью владельца сервиса.

Связь с бэкапами и окнами работ

отказоустойчивость защищает от отказа узла, не от логического удаления данных и не от кривого патча внутри гостевой ОС. Поэтому «отказоустойчивость включили» не отменяет бэкапы и не отменяет план отката. Но и бэкап не заменяет минуты автозапуска: восстановление из копии — это уже другой порядок времени. Компании нужны оба слоя; выключенный отказоустойчивость делает ставку только на долгий путь.

Чеклист на эту неделю

• открыть консоль виртуализации и проверить, не выключен ли отказоустойчивость «с прошлого окна»;
• сверить список критичных ВМ с политикой автозапуска;
• есть ли алерт на disabled отказоустойчивость;
• хватает ли резерва на отказ одного хоста;
• в шаблоне работ есть ли обязательный пункт возврата режима;
• когда последний раз делали учебный переключение на резерв.

FAQ

Можно ли держать отказоустойчивость выключенной на тестовом кластере? Да, если это изолированный контур. На проде — только на время работ с таймером и владельцем.

отказоустойчивость гарантирует ноль простоя? Нет: обычно краткий перезапуск ВМ. Но это минуты против часов ручного восстановления.

Что важнее — включить отказоустойчивость или купить ещё хост? Часто нужно оба: без ёмкости галочка пустая. Сначала честный расчёт admission.

Облако вместо своего кластера? Меняет инструменты, не отменяет вопрос переключение на резерв и ответственности за возврат режимов после работ.

Учебный переключение на резерв и культура окон работ

Раз в полгода стоит проводить контролируемый переключение на резерв некритичной или заранее согласованной ВМ: убедиться, что кластер реально поднимает машину, что мониторинг видит событие, что зависимости (DNS, IP, общие диски) на месте. Это дешевле внезапного падения хоста в отчётный день. Параллельно в шаблон работ добавляют обязательные поля: кто выключил отказоустойчивость, до какого времени, кто подтвердил включение, ссылка на заявка.

Если подрядчик обслуживает гипервизор, в договоре фиксируют: после любых работ статус отказоустойчивость и алертов подтверждается письменно. Иначе «временно» снова останется на месяцы, а простой станет сюрпризом для всех, кроме физики отказа железа.

Имеет смысл повесить на мониторинг отдельный алерт «отказоустойчивость disabled дольше N часов» с эскалацией на владельца инфраструктуры — не только на дежурного, который мог сам выключить режим. Тогда «временно» перестаёт быть невидимым состоянием.

Следующий шаг

Если высокая доступность когда-то отключали «на время» и с тех пор никто не подтвердил её возврат, простой — вопрос времени, а не удачи. Проверьте статус сегодня, верните режим, закрепите чеклист и алерт.

Навести порядок в кластере и политике переключение на резерв можно в рамках услуги Виртуализация — с проверкой ёмкости, мониторингом и регламентом работ без «забытых» выключений.