Уезжаете на месяц: как подготовить инфраструктуру к своему отсутствию

MAATRIX

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

Сфокусируйтесь на том, что нельзя отложить, а не на всём подряд

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

Простой фильтр — по каждому риску спросить: если это случится и никто не среагирует до вашего возвращения, ущерб будет обратимым? Например, вы собираетесь уехать с 25 августа по 25 сентября 2026 года:

• Нельзя отложить. Домен, у которого регистрация заканчивается 10 сентября — если не продлится автоматически, сайт и почта отвалятся посреди вашего отсутствия, и восстановление домена после истечения — это дни или недели, а иногда и торги с перекупщиком. То же с оплатой хостинга: если баланс VPS обнулится, а автосписание не сработает, сервер остановится, и без вас его никто не включит.
• Можно отложить. Некритичный баг в админке, который никто, кроме вас, не замечает. Рефакторинг куска кода, который работает и не трогается. Обновление мажорной версии базы данных — если оно не горит прямо сейчас, лучше сделать это после возвращения, с полным вниманием и временем на откат.

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

Мониторинг: убедитесь, что алерт дойдёт не только до вас

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

Что стоит проверить и поправить до отъезда:

• Добавьте второго получателя алертов, который не привязан к вашему личному телефону. Это может быть отдельный групповой чат, куда добавлены вы и хотя бы ещё один человек — даже нетехнический, если его задача просто переслать сообщение дальше или позвонить тому, кто разберётся.
• Не полагайтесь на единственный канал доставки. Если весь мониторинг замкнут на Telegram-бота, а у бота истечёт лимит запросов, поменяется токен или временно недоступен сам Telegram — вы не узнаете об инциденте вообще. Как настроить дублирующий канал доставки на случай сбоя основного — в статье резервный канал уведомлений, если Telegram лёг.
• Добавьте канал, не требующий телефона с интернетом — например, email на ящик, который проверяется даже с чужого устройства, или SMS-уведомление через сервис мониторинга, если он это поддерживает. В Uptime Kuma это делается в разделе Notifications: заводится второй провайдер (например, email в дополнение к Telegram) и привязывается к тем же проверкам, что и основной.
• Протестируйте канал заранее, а не полагайтесь на предположение. Временно занизьте порог алерта на тестовом сервисе или сервере и убедитесь, что сообщение реально дошло до второго получателя, а не потерялось из-за неверного chat_id, лимита бота или спам-фильтра почты. Тест за неделю до отъезда стоит десяти минут и снимает главный риск — обнаружить проблему с доставкой уже в момент, когда алерт нужен по-настоящему.
• Проверьте пороги алертов, чтобы за время вашего отсутствия не накопился шум, который заставит получателя отключить уведомления вручную — это одна из типичных причин, по которой критичный алерт теряется среди десятков неважных.

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

Автопродление: домены, SSL и оплата хостинга

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

Пройдитесь по трём пунктам заранее:

1. Домен. Зайдите в личный кабинет регистратора и убедитесь, что автопродление включено, а не просто было включено когда-то и слетело после смены способа оплаты. Проверьте дату списания — она должна быть заведомо раньше даты истечения, с запасом на случай, если карта не пройдёт с первого раза. Убедитесь, что письма от регистратора уходят на ящик, который реально проверяется, а не на старый корпоративный адрес, в который никто не заходит.
2. SSL-сертификат. Если используется Let's Encrypt с автопродлением через certbot или acme.sh, не доверяйте настройке на слово — запустите тестовый прогон:

# certbot: проверка, что автопродление реально сработает
certbot renew --dry-run

# проверить, что таймер systemd вообще активен и не упал молча
systemctl status certbot.timer
systemctl list-timers | grep certbot

Если dry-run падает с ошибкой — почти всегда это проблема с DNS-валидацией, занятым портом 80 или истёкшим API-токеном у DNS-провайдера, и лучше найти это за две недели до отъезда, а не в момент, когда сертификат уже просрочен и сайт отдаёт предупреждение браузера.

1. Оплата хостинга. Проверьте баланс VPS и способ автосписания. Если провайдер поддерживает автопополнение с привязанной карты — включите его и убедитесь, что карта не истекает в ближайшие месяцы (это частая причина остановки сервера — карта просто перевыпущена банком с новым номером). Стоит заранее понимать логику списания с баланса и что происходит при его обнулении, чтобы не столкнуться с остановкой сервера впервые именно в отпуске.

Удобный способ не держать три отдельных дедлайна в голове — свести домены, сертификаты и даты продления хостинга в один реестр с датами и ответственным за оплату, а не полагаться на память или разрозненные письма от разных сервисов. Подробный разбор, как вести такой реестр, — в статье реестр доменов и сертификатов: кто платит, когда истекает.

Доверенный человек: минимальный набор на самый крайний случай

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

Что должно быть в этом наборе, на одну страницу, распечатанную или в закреплённом сообщении:

• Куда писать в первую очередь — конкретный человек или сервис поддержки (например, тикет-система хостинга), а не «разберитесь сами».
• Контакты поддержки хостинга и регистратора домена — телефон или чат, с пометкой, что у провайдера уже есть данные аккаунта и достаточно назвать номер договора или e-mail.
• Кто может выступить платным исполнителем в крайнем случае — знакомый администратор или фрилансер, готовый разово вмешаться, с пометкой «привлечь, если сайт не работает больше суток».
• Как связаться с вами в экстренной ситуации — конкретный канал и примерное время на связи (даже «раз в три дня, вечером»), без иллюзии постоянной доступности.
• Явное «не делайте этого»: не логиниться на сервер самому, не передавать пароли по телефону человеку, представившемуся поддержкой, не соглашаться на «срочные» просьбы оплатить или изменить что-то без проверки через уже известный контакт.

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

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

Бэкапы: проверенные, а не предполагаемые

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

Перед отъездом стоит не проверить логи, а провести настоящий тест восстановления — на тестовый сервер или во временную директорию, с проверкой, что данные читаются:

# пример для borgmatic
borgmatic list
borgmatic extract --archive latest --path /tmp/restore-test-vacation

# для дампа базы — не просто убедиться, что файл существует,
# а восстановить его в тестовую базу и свериться со счётчиком строк
pg_restore -d test_restore_db /var/backups/db/latest.dump
psql -d test_restore_db -c "SELECT count(*) FROM users;"

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

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

Договоритесь с кем-то о готовности среагировать на критический инцидент

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

Что стоит обсудить с таким человеком до отъезда, даже если разговор займёт десять минут:

• Что считается критическим. Узкий критерий — «сайт недоступен больше нескольких часов» или «пришло уведомление, что домен не продлился» — работает лучше расплывчатого «если что-то не так, звони».
• Что у него есть на руках — как минимум доступ на чтение логов или дашборда мониторинга, чтобы оценить масштаб, не дожидаясь вас. Полный административный доступ разумно давать только при уверенности в компетенции и готовности отозвать доступ после возвращения.
• Формат вознаграждения, даже символического — превращает абстрактное «обращайся, если что» в реальное обязательство ответить.
• Явную границу: если ситуация выходит за рамки того, что он может оценить — правильное действие «подождать и написать в общий чат», а не героически чинить незнакомую систему.

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

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