Сайт запущен. Что делать каждый месяц, чтобы он не умер

Пятница, девять вечера. Сообщение в Telegram: «Сайт не открывается, браузер пишет, что соединение не защищено». Я открываю, смотрю на сертификат. Истёк сегодня в 18:00.

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

Такие истории я слышу постоянно. Ниже то, что мы делаем, чтобы их не было у наших клиентов.

Почему сайты «умирают»

Почти никогда не бывает одной большой катастрофы. Бывает накопление мелочей:

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

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

Что мы делаем каждый месяц

У нас есть регламент. Он скучный, и в этом его смысл.

На это уходит от двух до шести часов в месяц на сайт, в зависимости от размера. Большую часть можно автоматизировать, но смотреть глазами всё равно нужно.

Тестовая заявка — самое важное

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

Бэкапы, которые никто не проверял

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

Наш минимальный вариант для Django + PostgreSQL в Docker выглядит примерно так:

# каждую ночь в 03:00: дамп базы, сжатие, хранение 14 дней
0 3 * * * docker compose exec -T postgres pg_dump -U app app \
  | gzip > /backups/db-$(date +\%F).sql.gz \
  && find /backups -name "db-*.sql.gz" -mtime +14 -delete

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

Как это выглядит на долгих проектах

Две наших самых долгих поддержки — сайт юридической фирмы Legal Alliance и медиапортал телеканала MY5.

Legal Alliance — Django с DRF и Celery на бэкенде, Nuxt 3 на фронте. Там кроме сайта есть новости, видео, поиск, история компании, и всё это регулярно обновляется юристами. Основная работа поддержки — не баги, а мелкие задачи: новый раздел практики, правка формы, обновление команды. Плюс те самые скучные пункты из списка выше.

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

Годовой цикл поддержки у нас выглядит примерно так:

Мониторинг: узнать раньше клиента

Худшее, что может случиться с подрядчиком на поддержке, — когда о падении сайта ему сообщает клиент. Значит, мы проспали.

Минимальный мониторинг почти бесплатный. Внешний сервис раз в минуту-две открывает главную страницу и пишет в наш рабочий Telegram-чат, если она не ответила или ответила ошибкой. Для бэкенда мы собираем ошибки Django в отдельный канал, чтобы видеть, если что-то сыплет 500-ми.

Отдельно — «тихие» проблемы. Сайт может открываться, но при этом:

• Celery-воркер упал, и письма или уведомления не уходят;
• очередь задач растёт;
• API отвечает, но отдаёт пустые списки, потому что сломался фильтр.

На такие вещи мы ставим простые проверки: эндпоинт здоровья, который смотрит не только «живо ли», но и «работает ли». Это пара десятков строк кода, а сэкономили они нам не одну неприятную переписку.

Контент и аналитика тоже поддержка

Технически исправный сайт, который не обновлялся год, тоже умирает, только медленнее. Посетитель видит новость двухлетней давности и закрывает вкладку. Google видит, что ничего не меняется, и показывает сайт реже.

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

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

Можно ли поддерживать сайт самому

Можно, если в команде есть человек, который понимает сервер. Я бы оставил себе три вещи, даже если всё остальное отдаёте подрядчику:

1. Домен и хостинг оформлены на компанию, логины у вас.
2. Напоминания о продлении приходят на общий адрес или в чат, а не на личную почту сотрудника.
3. Раз в месяц кто-то из вашей команды сам отправляет тестовую заявку.

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

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