Windows VPS после обновления ждёт перезагрузки: как выбрать окно обслуживания

У любого обновления на Windows Server есть два времени, и они редко совпадают. Первое — когда установщик написал, что всё готово и нужна перезагрузка. Второе — когда бухгалтер снова открывает базу в 1С, нажимает «Провести» и документ действительно проводится. Между ними лежит окно обслуживания. Оно измеряется не часами на экране входа в Windows, а моментом, когда рабочая операция снова выполняется. Если планировать только первое время, окно получается красивым на бумаге и неприятным в понедельник утром.

Эта статья про то, как выбрать это окно для терминального Windows VPS, на котором работают люди и что-то крутится по расписанию. Универсального числа минут здесь не будет: оно зависит от вашего приложения, объёма базы, набора служб и от того, насколько аккуратно всё настроено. Зато будет способ найти свою цифру и не потерять в ней запас на неудачный запуск.

Сначала найдите тех, кому важен момент остановки

Перезагрузка выключает всё сразу, но последствия у разных программ разные. Текстовый редактор с автосохранением переживёт её почти безболезненно. Приложение, которое в середине операции записывает данные в несколько мест, переживёт хуже. Поэтому первый шаг — не выбирать время, а составить список того, что на сервере вообще чувствительно к остановке.

Обычно такой список складывается из нескольких групп:

• Интерактивная работа людей. Открытые сеансы, несохранённые документы, длинные формы, отчёты, которые строятся десятки минут.
• Пакетные операции внутри бизнес-приложения. Закрытие периода, массовое перепроведение, выгрузка, обмен между базами. Такие операции нельзя просто «поставить на паузу», их надо дождаться или заранее перенести.
• Фоновые задания по расписанию. Резервная выгрузка, синхронизация, отправка отчётов, загрузка файлов от партнёров. Их важно сопоставить с окном: задание, которое должно было стартовать в момент перезагрузки, либо не запустится, либо запустится в неподходящий момент.
• Службы, к которым подключаются другие системы. Веб-публикации, обмен по расписанию, интеграции, принимающие запросы извне.

Практичнее всего пройти по этому списку и для каждой позиции ответить на два вопроса: что случится, если её оборвать в произвольный момент, и сколько времени ей нужно, чтобы завершиться штатно. Второй ответ почти всегда получается неожиданным. Люди помнят, что отчёт «строится минут десять», а в конце месяца он строится сорок.

Отдельно о заданиях по расписанию

Планировщик заданий — частый источник сюрпризов вокруг перезагрузки. Задание может числиться в системе, а ожидаемого результата не дать. Microsoft в разборе проблем с невыполняющимися заданиями советует тестировать скрипт отдельно от планировщика, смотреть статус и историю задания и заглядывать в журнал TaskScheduler/Operational. Там же отмечено, что задание способно завершиться без нужного результата, а для поиска причины помогают упрощённый скрипт и собственное журналирование действий (документация Microsoft).

Для окна обслуживания из этого следует практический вывод: после перезагрузки мало увидеть, что задание «готово» или «выполнено». Нужно знать, что оно сделало то, ради чего существует. Если ваш скрипт ничего не пишет в собственный журнал, самое время добавить хотя бы строку «начал», строку «закончил» и количество обработанных объектов. Это превращает неопределённое «вроде отработало» в проверяемое утверждение.

Предупредить людей так, чтобы их предупреждение дошло

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

Рабочая схема выглядит так:

1. Заранее, за день-два. Короткое объявление в том канале, который люди действительно читают: дата, время начала, ожидаемая недоступность и что сделать до начала (сохранить работу, не запускать длинные операции).
2. Перед началом, за разумное для ваших людей время. Напоминание, что через столько-то минут сеансы будут завершены. Какое именно время считать разумным — решение вашей команды; ориентир задаёт самая короткая операция, которую человек может спокойно довести до конца.
3. В момент начала. Проверка, кто ещё вошёл в систему, и разговор по существу, а не автоматический удар по кнопке.

Важная деталь: автоматика обновлений и ваше расписание могут вести себя по-разному в зависимости от настроек. В документации Microsoft по политикам автоматических обновлений сказано, что политики управляют установкой и последующей перезагрузкой, а некоторые настройки взаимодействуют друг с другом. В частности, правило об отсутствии автоматической перезагрузки при вошедших пользователях влияет на плановый рестарт (политики автоматических обновлений).

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

Кто и как завершает сеансы

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

Пример окна между двумя рабочими периодами

Возьмём условный пример: небольшая бухгалтерия, сотрудники работают на одном терминальном VPS. Это не реальный случай и не результат измерения, цифры подобраны только чтобы показать логику расчёта.

Рабочий день заканчивается около 18:30, но два человека иногда задерживаются. Утром первые заходят около 8:30. Фоновая выгрузка данных стартует в 21:00 и занимает около получаса. Между 18:30 и 8:30 получается четырнадцать часов, но это не окно обслуживания: это территория, из которой нужно вычесть всё, что нельзя нарушать.

Если выгрузка длится полчаса и должна выполняться ночью, её разумнее поставить до начала обновлений, а не после: тогда вы заранее убеждаетесь, что она отработала, и не рискуете, что она стартует посреди установки. Тогда окно, например, может начаться в 22:00. Остальное время до 8:30 — это ваш бюджет на установку, перезагрузку, запуск, проверку и запас. Из этого бюджета нужно сознательно оставить часть нетронутой. Причина в том, что неудачный старт приложения не отнимает у вас пять минут, он отнимает столько, сколько требуется на разбор, а это заранее непредсказуемо.

Обратите внимание, что в этом примере мы нигде не обещали числа. Мы только показали, из каких кусков окно состоит и где у него границы. Подставлять в них реальные цифры нужно по результатам прошлых обслуживаний и пробного прогона.

Какие службы должны подняться сами

После перезагрузки Windows начинает запускать службы. Часть из них поднимется автоматически, часть ждёт ручного запуска, часть зависит от других. Для окна обслуживания здесь важно одно: список служб, без которых рабочая операция невозможна, должен быть написан, а не храниться в голове того, кто «просто знает».

Для типичного сервера с бизнес-приложением в этот список обычно входят:

• служба базы данных или сервер приложений, если они стоят на этом же VPS;
• служба лицензирования, если приложение требует лицензию;
• служба терминального доступа, чтобы люди вообще смогли войти;
• служба печати, если пользователи печатают с сервера;
• собственные службы обмена и интеграции.

Для каждой нужно знать три вещи: настроен ли у неё автоматический запуск, от кого она запускается и от каких служб зависит. Если служба базы стартует раньше, чем сетевой диск с данными стал доступен, она запустится и тут же упадёт или станет работать с пустым местом. Подробнее о настройке автозапуска и зависимостей есть в отдельном материале: автозапуск служб на Windows Server после перезагрузки.

Автоматический запуск — не то же самое, что готовность

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

Поэтому в вашем списке рядом с каждой службой полезно записать не только «должна быть запущена», но и «по какому признаку видно, что она работает по-настоящему». Для службы базы это может быть успешное подключение клиентом. Для обмена — свежая запись в её журнале. Для печати — тестовая страница. Это один короткий признак, но он отделяет «Windows загрузился» от «сервис готов».

Проверять нужно рабочую операцию, а не экран входа

После перезагрузки очень соблазнительно вздохнуть, увидеть экран входа или даже зайти на рабочий стол и закрыть окно. Но экран входа доказывает лишь то, что загрузилась операционная система и работает удалённый доступ. Бизнес-приложение, печать и задания — это отдельные слои, и каждый может не подняться.

Поэтому проверка после перезагрузки должна идти по цепочке реальных действий, как будто вы утренний пользователь:

1. Вход. Зайти под обычной учётной записью, а не только администратором: права и профили у них разные, и проблемы часто видны только у обычного пользователя.
2. Запуск приложения. Открыть рабочую базу или программу, дождаться полной загрузки интерфейса.
3. Рабочая операция. Выполнить то, ради чего сервер существует: открыть документ, провести тестовую запись, сформировать короткий отчёт. Если тестовые данные трогать нельзя, выбрать операцию чтения, которая проходит через ту же цепочку.
4. Печать. Отправить пробную страницу или короткий документ на принтер, которым пользуются люди.
5. Задания. Посмотреть, что запланированные задания находятся в ожидаемом состоянии, а при возможности запустить одно вручную и убедиться, что оно оставило результат в журнале.

С заданиями полезно вспомнить уже упомянутый совет Microsoft: смотреть статус и историю, а при сомнениях заглядывать в журнал TaskScheduler/Operational и вести собственные записи. Если вы завели в скрипте свой журнал, проверка превращается в чтение одной строки: «последняя запись — сегодня, обработано столько-то». Это куда надёжнее, чем доверять статусу.

Ещё одна маленькая, но полезная привычка: записывать время по ходу проверки. Не «минут пятнадцать», а «вошёл — 22:48, приложение открылось — 22:55, тестовая операция прошла — 22:58». Эти заметки и есть те самые данные, из которых в следующий раз вы вычислите длительность окна не на глаз.

Неудачный старт тоже входит в окно

Планируя окно, мы привыкли считать только благополучный сценарий: установили, перезагрузили, проверили, разошлись. Но окно обслуживания существует именно для того, чтобы было место для неблагополучного. Если оно рассчитано впритык, любая заминка превращается в аварию, потому что утром придут люди, а система ещё не готова.

Что может пойти не так на старте приложения, и сколько времени это обычно «съедает», зависит от вашей системы. Но сами категории предсказуемы:

• Служба не поднялась. Нужно выяснить почему: зависимость, права, занятый порт, пропавший ресурс. Иногда хватает перезапуска, иногда нужно читать журнал.
• Приложение стартует, но операция не проходит. Например, потеряна связь с базой или лицензией. Здесь время уходит на диагностику.
• Задание не выполнилось. Разбор по журналу планировщика и собственному журналу скрипта.
• Обновление встало и просит ещё одну перезагрузку. Это добавляет целый цикл остановки и запуска.

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

Разделение на два этапа — полезный приём, когда обновлений много или приложение тяжело стартует. В первую ночь устанавливаются обновления и проверяется, что система поднимается. Во вторую — вы делаете то, что требует более долгого окна. Так одна неудача не накладывается на другую.

Когда стоит решить, что окно закончилось неудачно

Заранее договоритесь, в какой момент вы перестаёте чинить и начинаете откатывать план или объявлять задержку. Решение, принятое в 7:50 под давлением, почти всегда хуже решения, оговорённого заранее. Достаточно одной фразы: «если к такому-то часу рабочая операция не проходит, мы сообщаем пользователям, что сервис недоступен до такого-то времени». Это не бюрократия, а способ не принимать важное решение в панике.

Какое место здесь занимают ресурсы VPS

Связь между ресурсами сервера и окном обслуживания вполне прямая, хотя и не всегда очевидная. Установка обновлений нагружает диск и процессор, а запуск приложения после перезагрузки — ещё и память. Если ресурсов впритык, всё это идёт медленнее, и окно растягивается. Если запас есть, процессы укладываются быстрее и предсказуемее.

VPS MAATRIX строятся на NVMe-дисках и процессорах AMD EPYC, с root-доступом. Тарифы начинаются с Ba (1 vCPU, 2 ГБ RAM, 40 ГБ NVMe), дальше идут Uab (2 vCPU, 4 ГБ, 80 ГБ), Heka (4 vCPU, 8 ГБ, 160 ГБ), Maat (8 vCPU, 16 ГБ, 240 ГБ) и Djed (16 vCPU, 32 ГБ, 320 ГБ). Эти параметры — отправная точка для пробы, а не обещание ёмкости: сколько пользователей и какая база поместятся на конкретном тарифе, покажет только тест с вашим приложением. Для окна обслуживания такой тест особенно полезен: прогоните на выбранной конфигурации типичный цикл «обновление — перезагрузка — запуск — проверка» и запишите реальные времена. Тогда выбор тарифа и выбор окна окажутся связаны не догадкой, а замером.

Серверы доступны в нескольких локациях, указанных в публичном предложении: UK, US, RU и FR. Оплата возможна картой РФ и через СБП, а VPS создаётся автоматически через пару минут после оплаты. Точное наличие образов и операционных систем в нужной локации проверяйте в форме заказа. Это удобно для проб: можно развернуть отдельный сервер под репетицию обслуживания, не трогая рабочий.

Репетиция, которая делает цифру настоящей

Если у вас есть возможность, самый надёжный способ узнать длительность окна — один раз пройти его на копии. Разверните тестовый сервер с похожей конфигурацией, установите те же обновления, перезагрузите, запустите приложение и проведите проверку рабочей операции. Не подгоняйте условия под красивый результат: если на рабочем сервере база больше, а служб больше, учитывайте это в оценке.

Что именно записать на репетиции:

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

Последний пункт самый ценный. Именно он превращает «запас на неудачу» из абстрактного слова в конкретный отрезок. Репетиция не гарантирует, что в боевой раз всё пройдёт так же, но убирает главный источник неожиданностей: вы впервые видите, как ведёт себя ваша система после обновления.

Окно закрывается не там, где кажется

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

Поэтому, назначая время, считайте от этой точки назад: когда первый человек должен получить рабочий сервис, сколько нужно на запас, сколько на проверку, сколько на запуск и перезагрузку, и когда в таком случае должны разойтись последние пользователи. Получившееся время и есть ваше окно. А если оно не помещается между двумя рабочими периодами, лучше узнать об этом заранее, чем в семь пятьдесят утра.