ИИ задеплоит за тебя. А дежурить кто будет?

На днях в чате разработчиков мне написали: «Я описал Клоду проект с телефона, он собрал MVP и сам задеплоил на Firebase. В деплой я вообще не лез. Зачем теперь нужны сервисы деплоя?». Вопрос честный, и короткий ответ на него: незачем. Если ИИ развернул ваш проект и он работает, всё отлично, расходимся. Длинный ответ интереснее.

День первый: тут ИИ действительно победил

Признаю без оговорок: настройка сервера перестала быть проблемой. Любой ассистент напишет docker-compose, поднимет nginx, выпустит сертификат и объяснит каждую строчку. Гайды, по которым мы страдали вечерами, превратились в один промпт. Это прогресс.
Проблема в том, что настройка и была самой лёгкой частью. Она просто казалась сложной, потому что делалась один раз. А проект живёт месяцы.

День второй и все последующие

Что происходит с сервером дальше, из личного опыта за годы деплоев:

Сертификат истёк в пятницу вечером. Пользователи видят «соединение не защищено», вы узнаёте об этом в понедельник от клиента.

За одну ночь боты сделали 9999 попыток подобрать пароль к SSH. Сервер без защиты для интернета выглядит как открытая дверь, и в неё правда ломятся, обычно в первые же сутки.

Docker Hub перестал отвечать с российских IP. Деплой, который работал год, умер в момент пересборки образа. Кто не прописал зеркала реестра заранее, чинил это в панике на проде.

Диск кончился: каждая пересборка образа оставляет слои, за пару месяцев они съедают всё, и сервер встаёт с «no space left on device».

Прод упал в два ночи. Кто вам скажет? Никто, если нет мониторинга. Узнаете утром, от пользователей.

Как всё это закрывается руками, я подробно разбирал в прошлой статье, с конфигами и командами. Суть не в командах. Суть в том, что ни одна из этих проблем не решается на этапе «задеплоить». Они случаются потом, когда чат с ассистентом давно закрыт.

Почему ассистент не может дежурить

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

Дежурство это процесс, а не знание. Кто-то должен пинговать сайт каждые 20 секунд в 4 утра. Заметить, что сертификат не продлился, до того, как он истёк. Забанить бота на пятой попытке, а не рассказать, как настраивается fail2ban. Чат-ассистент не живёт в рантайме вашего сервера, у него нет ни процесса, ни ответственности. «Клод всё настроил» на практике означает «дежурным назначен я, просто настройка была бесплатной».

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

Дежурный за 30 строк

Чтобы не быть голословным, вот минимальный «дежурный», которого можно поставить за вечер. bash + cron, забирайте😉.

Пингер с алертом в Telegram:

#!/usr/bin/env bash
# /opt/watch.sh — дергается кроном раз в минуту
SITE="https://example.com"
TG_TOKEN="123:abc"; CHAT_ID="123456"
STATE=/tmp/site_down
code=$(curl -s -o /dev/null -w '%{http_code}' --max-time 10 "$SITE")
if [ "$code" -ge 500 ] || [ "$code" = "000" ]; then
if [ ! -f "$STATE" ]; then
touch "$STATE"
curl -s "https://api.telegram.org/bot$TG_TOKEN/sendMe" \
-d chat_id="$CHAT_ID" -d text="$SITE не отвечает (код $code) 👎🏻"
fi
else
if [ -f "$STATE" ]; then
rm -f "$STATE"
curl -s "https://api.telegram.org/bot$TG_TOKEN/sendMe
-d chat_id="$CHAT_ID" -d text="$SITE снова жив 👍🏻"
fi
fi

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

Диск, который молча кончается от docker-слоёв:

# crontab -e
0 6 * * 0 docker system prune -f
* * * * * [ $(df --output=pcent / | tail -1 | tr -dc 0-9) -gt 90 ] && \
curl -s "https://api.telegram.org/bot$TG_TOKEN/sendMessage" \
-d chat_id="$CHAT_ID" -d text="диск заполнен на 90%+ 👎🏻"

И бонус, о котором мало кто знает: деплой без 502 силами одного Caddy. При пересоздании контейнера Caddy может придержать запросы и доретраить их в новый контейнер, пользователи не заметят рестарта:
example.com {
reverse_proxy app:8000 {
lb_try_duration 30s
lb_try_interval 250ms
}
}

Тридцать секунд Caddy будет пытаться достучаться до бэкенда, прежде чем отдать ошибку. Этого хватает на docker compose up -d с уже собраннымобразом.

Работает? Работает. Но заметьте, что произошло: мы только что начали писать свою систему мониторинга на bash. Дальше по этой дороге: проверка, что упал сайт, а не сеть самого пингера (иначе ложные алерты), пинг чаще при падении, чтобы поймать восстановление, алерт про истекающий сертификат, бэкапы БД... Каждый шаг разумный, а сумма называется «вторая работа».

Кто тогда дежурит

Вариантов, собственно, четыре, и все честные:

Сам, по чеклисту. Дёшево, познавательно, но теперь у тебя вторая работа. Нормальный выбор для одного пет-проекта, плохой для пяти.

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

Панель на своём сервере. Уже лучше, но панель тоже надо ставить, обновлять и понимать. Дежурный по-прежнему ты, просто с приборной доской.

Managed-сервис поверх своего сервера: железо и данные твои, дежурство чужое. Я делаю сервис ровно в этой парадигме, djaploy: деплоит Docker-проект на ваш VPS и дальше сам держит день второй, от сертификатов и банов до мониторинга с алертом в Telegram и отката кнопкой. Скрипты, которые он выполняет на сервере, открыты, можно брать их как чеклист и не платить вовсе.

Вместо вывода

Мне кажется, рынок сейчас переоценивает «ИИ задеплоит» и недооценивает «а дальше само». Настройка подешевела до нуля, дежурство как стоило времени, так и стоит. Ценность смещается от «помоги развернуть» к «следи и буди меня, только когда я правда нужен».

А у вас кто дежурит по серверу? Вы сами, скрипты, сервис или «пока не падало»?