Плановое техобслуживание сервера — как не потерять доверие игроков

MAATRIX GAMES

Сервер лежит десять минут — и в Discord уже пять сообщений «сервер сдох, верните донат». Обидно, если это было плановое обновление, о котором вы честно предупреждали за неделю, просто предупреждали не там и не так. Разница между «нормальным ТО» и «волной репортов на серверлистах» почти всегда не в самих работах, а в том, как вы их анонсировали и показали игрокам, что происходит.

Зачем вообще формально анонсировать ТО

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

• Меньше репортов на мониторинги. Sinsevri, GTop100 и подобные площадки понижают позиции за нестабильный аптайм — если вы заранее выставили статус «на обслуживании», часть ботов-чекеров это учитывает и не засчитывает даунтайм как аварию.
• Меньше оттока. Игрок, который увидел анонс за сутки, планирует вечер по-другому. Игрок, который наткнулся на «Connection timed out» без объяснений, с вероятностью в разы выше просто уходит на другой сервер того же режима.
• Доверие как актив. На малых и средних RP/PvP серверах комьюнити прощает многое, если видит, что админ ведёт себя предсказуемо — предупреждает, укладывается в объявленное время, откатывает при проблемах. Это репутация, которая работает лучше любой рекламы.

Ниже — рабочая последовательность: как выбрать время, как предупредить, что показывать во время работ и что делать, если что-то пошло не так.

Как выбрать окно обслуживания

Первое правило — окно должно приходиться на минимум трафика, а не на удобное вам время. Смотреть нужно не «в среднем по палате», а по своей аудитории: у RU-комьюнити пик обычно 19:00–00:00 по МСК в будни и почти весь день в выходные, у EU/US-аудитории — свои часовые пояса со сдвигом на 7–10 часов.

Как это получить без гаданий:

• Графики онлайна из панели хостинга — если хостинг (как у MAATRIX GAMES) отдаёт статистику по CPU/RAM/сети в реальном времени, по нагрузке на сеть видно пики почти так же точно, как по числу игроков.
• Логи коннектов. В Minecraft можно вытащить время входов/выходов из логов через grep "logged in" logs/latest.log, для источников с RCON — периодически дёргать status или players и складывать в CSV самому.
• Discord-активность. Если бот считает онлайн голосовых и активность в чате, эти графики почти всегда коррелируют с онлайном на сервере.

Практическое правило для большинства RU-серверов: окно 04:00–07:00 по МСК — трафик минимален почти у всех аудиторий, включая EU. Для чисто US-комьюнити сдвиньте на их ночь — это будет день по Москве.

Второе правило — не растягивайте окно «на всякий случай». Если обновление занимает обычно 15 минут, анонсируйте 30, а не «с 3 до 6 утра», просто чтобы подстраховаться. Игроки запоминают заявленное время и ждут, что сервер оживёт именно тогда — слишком широкое окно так же подрывает доверие, как и опоздание.

Таймлайн предупреждений — за сколько и где писать

Одного поста в Discord за час до работ недостаточно — часть аудитории просто не онлайн в этот момент. Рабочая схема для планового ТО (не экстренного патча):

Время всегда указывайте с явной таймзоной (МСК/UTC) — если у вас смешанная RU/US аудитория, дублируйте в двух зонах, иначе половина игроков придёт не вовремя и решит, что вы наврали со временем.

Финальные предупреждения удобно слать прямо из игры через RCON, без захода в Discord:

rcon-cli say [ТО через 5 минут] Сервер уйдёт на плановое обслуживание, сохранитесь заранее
rcon-cli say [ТО через 1 минуту] Сервер выключается для обновления

Для Minecraft то же самое можно завернуть в консольную команду сервера или в плагин-таймер (например, кастомный scheduler-плагин, который сам шлёт broadcast по расписанию) — так не нужно сидеть у консоли и следить за часами.

MOTD и статус-страница на время работ

MOTD — самый недооценённый канал: его видит каждый, кто пытается зайти, даже если пропустил все посты в Discord. Меняйте его заранее и возвращайте после:

# server.properties (Minecraft), за сутки до ТО
motd=§eТО в 04:00 МСК (~30 мин), детали в Discord

# во время работ, если оставляете сервер видимым в списке
motd=§cСервер на плановом обслуживании, вернёмся к 04:30 МСК

Для Rust то же самое — server.hostname в server.cfg или через параметр запуска +server.hostname. Для CS2/Source-серверов — hostname в server.cfg, применяется командой sv_reload_hostname без рестарта, если правите на лету заранее.

Отдельная статус-страница — не обязательный, но сильно снижающий тревожность инструмент. Не нужен сложный сервис: достаточно простой статичной страницы (можно на GitHub Pages или в поддиректории вашего сайта), которую вы вручную или скриптом переключаете между «Online» / «На обслуживании» / «Обновление задерживается». Более автоматизированный вариант — сторонний аптайм-монитор, который сам показывает публичную страницу статуса и шлёт уведомления в Discord при недоступности порта; на время анонсированного ТО такие сервисы обычно позволяют поставить maintenance-окно, чтобы не слать ложную тревогу подписчикам. Здесь пригодится подход из статьи про аптайм-мониторинг игрового сервера — те же инструменты, что ловят аварийные падения, умеют и плановые окна.

Если у вас уже есть статусный Discord-бот, который дёргает A2S-запрос или пингует RCON и постит embed с онлайном — на время ТО он же может публиковать отдельный embed «Maintenance in progress» вместо «Server offline», чтобы бот не путал плановые работы с падением. Логика такого бота разобрана в статье про Discord-бота для мониторинга статуса сервера.

Чек-лист самого обслуживания

Когда окно наступило, порядок действий должен быть заранее записан — не придумывать на ходу под давлением «игроки ждут»:

1. Бэкап перед любыми изменениями, даже если обновление кажется тривиальным. Правило простое: если откатывать нечем — не начинайте работы.

   tar -czf backup-pre-maintenance-$(date +%Y%m%d-%H%M).tar.gz world/ server.properties plugins/

1. Мягкая остановка, а не kill — дайте серверу сохранить мир/состояние. В Minecraft — save-all затем stop через RCON, в Rust — quit после server.writecfg, не pkill -9.
2. Само обновление — версия ядра, плагины/моды, конфиги. Меняйте по одному пункту за раз, если это не рутинный патч, который вы уже обкатали на тестовом сервере.
3. Тест перед открытием: зайдите сами (или через тестовый аккаунт), проверьте спавн, критичные команды, RCON-отклик, плагины из топ-листа по нагрузке.
4. Открытие — снимаете whitelist-заглушку/maintenance-режим, возвращаете нормальный MOTD, публикуете «сервер онлайн» в Discord и на статус-странице.

Если обновление затрагивает моды/плагины, отдельно стоит свериться с чек-листом из статьи про обновление сервера без потери прогресса игроков — там подробнее про совместимость версий и что делать, если плагин не готов к новому ядру. А сам процесс резервного копирования по расписанию, чтобы бэкап перед ТО не был единственной точкой отказа, разобран в статье про настройку автобэкапов.

Что делать, если работы затянулись

Это происходит чаще, чем хочется признавать: миграция схемы MySQL для плагинов идёт дольше расчётного, новая версия ядра ломает половину модов, конвертация мира зависает. Здесь доверие теряется не из-за самого затягивания, а из-за тишины.

• Сообщайте о задержке сразу, как только поняли, что не укладываетесь — не ждите истечения заявленного окна, чтобы «может, ещё успеем». Одно сообщение «работы идут дольше ожидаемого, новая оценка — +20 минут» снимает большую часть раздражения.
• Держите жёсткий порог отката. Заранее решите: если через X минут после начала проблема не решена — откатываетесь на бэкап и открываете сервер в старом состоянии, разбираетесь с обновлением отдельно, без давления «игроки уже час ждут». Незапланированный даунтайм на несколько часов бьёт по доверию сильнее, чем честный откат.
• Публикуйте промежуточные статусы, даже если сказать особо нечего: «ещё работаем, новая оценка через 15 минут» лучше, чем ничего — тишина читается как «всё сломалось окончательно».

Если ситуация дошла до полноценной аварии, а не планового ТО — дальнейшие шаги диагностики и связи с игроками расписаны в статье что делать, если сервер упал: чек-лист диагностики.

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