Yandex Cloud: Виртуальная машина выключается из-за настроек расписания

  • Обновлено
  • Чтение ≈ 3 минуты
  • Нужны права администратора

Краткий ответ

Виртуальная машина регулярно оказывается выключенной в определённые часы. Это не доказывает существование встроенного расписания остановки у обычной ВМ: причиной могут быть внешняя автоматизация, задание в гостевой ОС, правила группы ВМ, ручные операции либо особый жизненный цикл прерываемого экземпляра.

В этой статье
  1. Признаки неисправности и область применимости
  2. Почему это происходит
  3. Пошаговая диагностика и устранение
  4. Как проверить, что проблема исправлена
  5. Если проблема осталась

#Признаки неисправности и область применимости

Виртуальная машина регулярно оказывается выключенной в определённые часы. Это не доказывает существование встроенного расписания остановки у обычной ВМ: причиной могут быть внешняя автоматизация, задание в гостевой ОС, правила группы ВМ, ручные операции либо особый жизненный цикл прерываемого экземпляра.

#Почему это происходит

Возможная причинаКак узнатьЧто делать
Внешний планировщик вызывает APIЗадание Cloud Functions, скрипт CI или сторонний планировщик выполняет команду управления ВМ.Остановки повторяются в одно время и есть операции stopСопоставьте время и идентификатор инициатора.
ВМ прерываемого типаДля прерываемых машин действуют специальные условия остановки и жизненного цикла.Экземпляр останавливается без установленного cronПроверьте тип ВМ.
Остановка из гостевой системыsystemd timer, cron или администратор запускают выключение.В журнале ОС есть штатный shutdownПроверьте журнал ОС и задания.

#Пошаговая диагностика и устранение

  1. Запишите характер остановокВ Compute Cloud откройте карточку ВМ и её историю операций. Зафиксируйте время и тип последней операции, статус перед остановкой и совпадение по дням недели. Не включайте машину без согласования: остановка могла быть плановой для экономии бюджета.
  1. Проверьте тип и владельца машиныПосмотрите, отмечена ли ВМ как прерываемая и не входит ли в управляемую группу экземпляров. В группе могут действовать политика масштабирования и управление жизненным циклом; такие настройки обычно важнее отдельных ручных действий.
  1. Найдите внешнюю автоматизациюУточните у команды инфраструктуры, нет ли заданий облачного планировщика, CI/CD, Terraform, функций или собственных скриптов с разрешениями на Compute Cloud. Сверьте журналы и аудит операций со временем остановки. Слово «расписание» в названии задачи не означает штатное расписание ВМ.
  1. Проверьте гостевой журнал предыдущей загрузкиЕсли на Linux сохранился системный журнал, просмотрите сообщения предыдущего запуска на предмет shutdown и причины завершения. На машине без persistent journal могут отсутствовать предыдущие записи — это не доказывает аварии.
  2. Linux с systemd и сохранёнными журналами; только чтение
    Linux · Терминал (Bash)КомандаНужен sudo
    Linux с systemd и сохранёнными журналами; только чтение. В выводе ищите shutdown, poweroff и вызвавшую процесс службу.
    sudo journalctl -b -1 --no-pager | tail -n 100
  1. Проверьте таймеры systemd и cronНа сервере просмотрите список таймеров и задания администратора, ищите только относящиеся к остановке. Вмешательство в чужие запланированные задания может разрушить процессы резервного копирования.
  2. Linux с systemd, чтение
    Linux · Терминал (Bash)Команда
    Linux с systemd, чтение. Если найдено подозрительное имя, сначала изучите описание таймера, а не отключайте его.
    systemctl list-timers --all
  1. Сопоставьте облачные события и ОСЕсли ОС зарегистрировала штатный poweroff в ту же секунду, ищите локальное действие; если ОС ничего не знает, но журнал операций показывает stop от API, проверьте сервисный аккаунт инициатора и его права. При неожиданном выключении проверьте сообщения платформы и поддержку.
  1. Измените только подтверждённый источникПри найденном автоматическом задании согласуйте с владельцем новую политику: отключение или изменение расписания делайте в его системе управления, предварительно зафиксировав прежнее значение. Если ВМ прерываемая, пересмотрите требования к доступности; не пытайтесь обходить политику перезапусками.
  1. Проверьте следующий ожидаемый периодЗапланируйте контролируемое наблюдение статуса в период, когда раньше ВМ останавливалась, и убедитесь, что нет новой операции stop. Проверьте, что связанные задания резервного копирования и экономии ресурсов сохранили необходимые интервалы.

#Как проверить, что проблема исправлена

В заданный временной промежуток ВМ остаётся в согласованном состоянии, журнал операций не показывает нежелательную остановку, а владелец автоматизации подтвердил новое расписание.

#Если проблема осталась

Если нет следов запланированной операции и журнал ОС обрывается внезапно, проверьте прерываемый статус, сбой питания гостевой ОС и состояние облачной платформы. Не приписывайте причину «встроенному планировщику» без записи о нём.

Так эту ошибку тоже называют

Источники и обновления

Последнее обновление статьи: 2 ноября 2026. Версии программ и интерфейсы меняются — если шаги не совпадают с вашей версией, сверяйтесь с документацией производителя.