Запрос обычно звучит просто: «нужно администрирование сервера, там вроде ничего сложного». Потом открываем доступы, а там SSL истек 3 дня назад, диск забит на 96%, бэкапы «есть», но никто не проверял, можно ли из них восстановиться, релиз делает один человек с ноутбука. В этот момент быстро становится понятно, почему один подрядчик просит 30 тыс. ₽, а другой 120 тыс. ₽.
По сути бизнес покупает не доступ по SSH. Он покупает управляемость: кто заметит сбой, кто отреагирует, сколько данных можно потерять и за какое время сервис вернется в строй.
Сервер может отвечать, а деньги уже уходят
Самая частая ошибка - смотреть только на доступность сайта. То, что главная страница открывается, еще ни о чем не говорит. База может отвечать медленно, очередь задач - стоять, ночной cron - падать без алерта, а менеджеры узнают о проблеме уже от клиентов.
На одном e-commerce проекте у нас был стек Laravel 11, PostgreSQL 16, Redis, Docker Compose. Клиент говорил: «иногда подвисает, но в целом все работает». Мы подняли Prometheus и Grafana и увидели, что ночью падала выгрузка остатков, а утром отдел продаж подтверждал заказы на то, чего уже нет. Только отмененных заказов набежало на 280 тыс. ₽ за месяц.
Практический минимум зрелой поддержки у нас обычно такой:
- Uptime Kuma или Zabbix - следить за доступностью
- Prometheus + Grafana - видеть метрики базы, диска и очередей
- проверяемые бэкапы и понятный регламент доступов
- алерты в Telegram или Slack, чтобы проблема не жила до утра
CTO логистической платформы как-то точно это сформулировал: инфраструктурные проблемы у малого бизнеса обычно связаны не с нехваткой инструментов, а с тем, что процессы нельзя повторить в стрессе.
Где заканчивается поддержка и начинается DevOps
Если релиз делается вручную, окружения отличаются, а деплой зависит от одного инженера, это уже история не про «поддержать сервер». Здесь нужен DevOps-подход: тесты, сборка, выкладка и откат должны идти по сценарию, а не по памяти.
У клиента из B2B-логистики был Node.js 20 + NestJS и фронтенд на Next.js. До нас релизы выкатывали по SSH, по ночам, когда «поспокойнее». Мы собрали staging, настроили GitHub Actions, контейнеризацию и откат по кнопке. Через 4 недели команда выкатывала изменения почти каждый день, а откат вместо 2-3 часов занимал 15 минут.
Docker здесь полезен только как часть процесса. Образ нужно собрать, сохранить в GitHub Container Registry или Docker Hub, проверить и доставить без ручной магии. Если процесса нет, один Docker просто добавляет новый слой проблем.
Почему чек отличается в разы
Цена почти никогда не зависит только от числа серверов. Один сервер с PostgreSQL, платежами и критичным API часто обходится дороже трех промо-сайтов на WordPress. Разница в риске и в том, сколько ответственности реально берет на себя подрядчик.
| Формат | Что обычно внутри | Диапазон |
|---|---|---|
| Разовая настройка | базовый запуск, без реакции на инциденты | 20-50 тыс. ₽ |
| Администрирование | мониторинг, обновления, бэкапы, реакция по договору | 40-90 тыс. ₽/мес |
| DevOps-сопровождение | CI/CD, staging, IaC, сопровождение релизов и базы | 90-180 тыс. ₽/мес |
Я бы советовал задать подрядчику два вопроса: какой у вас RPO и какой RTO. Грубо говоря, сколько данных бизнес готов потерять и за сколько сервис поднимется обратно. Если час простоя стоит компании 50-100 тыс. ₽, разговор про бюджет сразу становится предметным.
Хорошую услугу видно по артефактам, а не по обещаниям
Я обычно смотрю на следы реальной работы. Есть ли карта инфраструктуры, список сервисов, история инцидентов, журнал изменений, ревизия доступов, тест восстановления из бэкапа. Если подрядчик показывает Grafana dashboard и план улучшений на квартал, это хороший признак.
Спросить стоит вот что:
- как часто вы проверяете восстановление из бэкапов
- релизы идут вручную или через CI/CD
- где лежит документация и кто ее обновляет
- что произойдет, если текущий инженер уйдет
- какие отчеты мы увидим каждый месяц
У нас был и обратный пример, где мы сами перемудрили. Для двух сервисов подняли Kubernetes, потому что команда хотела «сразу как у больших». На деле релизы быстрее не стали, а времени на поддержку самой платформы уходило слишком много. Потом упростили все до Docker Compose, managed PostgreSQL и GitLab CI, и новое окружение стало подниматься за 20-30 минут, а не за полдня.
Когда бизнесу уже пора двигаться в DevOps
Порог обычно очень приземленный: релизы чаще одного раза в неделю, 2 и больше окружения, несколько разработчиков, критичная база, требования к восстановлению не «когда получится», а в конкретных часах и минутах. В этот момент ручное администрирование уже начинает тормозить выручку так же заметно, как плохой код.
В ближайшие 6-12 месяцев бизнес будет все чаще покупать не «админа на подхвате», а предсказуемость релизов и восстановления. Если хотите быстро проверить своего подрядчика, спросите одну вещь: покажите, как вы поднимете сервис, если база упадет сегодня в 03:10. После такого разговора картина обычно становится ясной.
