Самый дорогой риск абонентки — не аварии. Аварии видно. Дорого другое: подрядчик, которому выгодно находить себе работу. Часы оплачиваются, неиспользованные сгорают, а проверять обоснованность каждой задачи у клиента нет ни времени, ни экспертизы: за экспертизой он и пришёл. Снаружи честного подрядчика от «находчивого» не отличить: оба отвечают быстро, оба присылают счета вовремя.
Отличие живёт в истории переписки. Этот кейс не про один проект, а про сквозную линию из 9 эпизодов за 24 месяца: мы отговаривали клиента от работ, на которых заработали бы. Каждый эпизод оставил след: задачу в трекере или сообщение в чате. Сумм в кейсе нет ни одной, и это принципиально: деньги здесь показаны только поведением.
Сводка
| Отрасль клиента | digital-агентство (веб-студия) |
| Клиент | анонимизирован — «Медиастудия», Россия |
| Формат сотрудничества | абонентская DevOps-поддержка, договор ИП↔ИП, прямой клиент |
| Тип проекта | мета-кейс: модель отношений на длинной абонентке |
| Объём работ | ~14 серверов в обслуживании, 96 задач в трекере за период |
| Дата проекта | 10 июн 2024 – 28 фев 2026 (628 дней — диапазон эпизодов) |
| Трудозатраты | помесячная абонентка с минимальным объёмом; отдельные эпизоды кейса — от 0.25 ч |
| Команда | 3 специалиста (инженер-сисадмин · инженер точечно · руководитель проекта) |
| Технологический стек | ISPmanager · Bitrix · MySQL/MariaDB · nginx · Zabbix · Redmine |
| Сдано | клиент передал бюро конечного заказчика на прямой контракт и рекомендовал бюро третьей компании |
Что было
У агентства парк из ~14 серверов: GitLab, облако, мониторинг, панель и пачка клиентских сайтов, в основном Bitrix. Мы зашли в мае 2024-го, после ухода прежнего админа, на классическую абонентку: минимальный месячный объём, неиспользованные часы сгорают, внеплановые задачи оплачиваются сверху.
Экономика такого договора толкает подрядчика в одну сторону: чем больше задач «найдёшь», тем больше счёт. Клиент это понимает не хуже нас. Первые месяцы любой абонентки уходят на проверку, кого он на самом деле нанял. Ниже — что эта проверка показала, эпизод за эпизодом.
9 эпизодов
1. Клиент сам приносит большой проект — мы закрываем его за 0.25 часа. Июнь 2024. Клиент ставит задачу: проработать переход на управление инфраструктурой как кодом (IaC), выдать план и стоимость. Готовый бюджет, прямой запрос, бери и оценивай. Инженер отвечает из практики: ISPmanager стандартизации поддаётся очень плохо, ставить и настраивать его всё равно придётся вручную. Зато бэкапы панель разворачивает сама. Решающим аргументом стало время: «с учётом времени обновления ДНС — которое длится часы — нет особого смысла за большие деньги изобретать что-то. т.е. пока ДНС обновится, уже всё развернётся». Вместо проекта — совет без счёта: разнести сервер бэкапов и боевой ЦОД по разным хостерам. Ответ клиента в задаче: «понял. тут больше нет вопросов». В трудозатратах: 0.25 часа.
2. «Выиграем копейки». Июль 2024. Заходит речь о том, чтобы дожать nginx-кэш на Yii-бэкенде клиентского сайта. Часы тюнинга были бы наши. Инженер режет тему сам: «это явно надолго и выиграем копейки. Не стоит, помоему». И вместо кэша отдаёт разработчикам клиента рекомендации уровня приложения.
3. Счёт в минус себе. Октябрь 2024, контракт на 10 часов в месяц. В отчёте за месяц: по факту трудозатрат было 4.5 часа — «недоработали». Цифра не с потолка: сумма записей в трекере сходится с чатом до четверти часа.
4. «50 единиц потерялись — в следующем месяце доплачу». Расхождение в учёте бюро нашло само и само же объявило в чате клиента, не дожидаясь акта сверки. Учёт часов при этом открыт постоянно: бот бюро отвечает на запрос трудозатрат прямо в общем чате.
5. «Торопиться не надо». Декабрь 2024 – январь 2025. Переговоры о крупном проекте для заказчика клиента: созвон, 2 инженера, проработка архитектуры. В январе — отбой, заказчик не потянул бюджет. Реакция бюро в чате: «торопиться не надо». Без дожима, без «специальных условий до конца недели».
6. Два честных варианта цены и право выбрать дешёвый. Март 2025. Dev-серверу клиентского проекта нужен PHP 8.1, ОС старая. Инженер выдаёт оба пути с честной ценой в часах. Быстрый: временная лицензия панели и переключение версии — час работы. Правильный: новый сервер с поддерживаемой ОС и перенос — от 3 часов, база 30 ГБ и 80 ГБ файлов, «БД не быстро заливаются, такого размера». Клиент выбрал дешёвый. Бюро зафиксировало риск (сервер всё равно предстоит обновлять) и не настаивало.
7. «Может, не надо ничего чистить?» Август 2025. Прилетает задача на расчистку диска: оплачиваемая, согласованная, можно молча сделать. Инженер сначала смотрит скриншоты: «места почти половина по скринам — может не надо ничего чистить?» Задача не состоялась.
8. Память не докидываем без диагноза. Ноябрь 2024. У клиента привычный рефлекс на тормозящий сервер: «просто докинуть памяти». Инженер останавливает: «не факт что поможет, без выяснения причины, что за процесс и почему сожрал». Расширение железа — самая лёгкая продажа в поддержке, потому что её не нужно обосновывать. Мы обосновываем: сначала причина, потом железо.
9. «Верните половину памяти». Февраль 2026, кризис в сезон продаж у магазина конечного клиента: под нагрузкой серверу добавили ресурсов, память выросла с 24 до 64 ГБ. Кризис прошёл, и инженер сам пишет: «память пусть обратно вдвое урезают до 32G… если всё ровно — пусть вернут как было». Клиент платит хостеру меньше. Инициатива — подрядчика, которому за неё никто не платит.
Хронология
| Период | Эпизоды |
|---|---|
| июнь–июль 2024 | отказ от IaC за 0.25 ч; «выиграем копейки» |
| октябрь–ноябрь 2024 | «недоработали» в счёте; «не докидывать памяти без причины» |
| декабрь 2024 – январь 2025 | «торопиться не надо» на сорвавшихся переговорах |
| март 2025 | два варианта цены, клиент выбрал дешёвый |
| август 2025 – январь 2026 | «может не надо ничего чистить?»; «50 единиц потерялись — доплачу» |
| февраль 2026 | «верните половину памяти» |
Эпизоды распределены по 24 месяцам обычной работы: между ними шли ежемесячные обновления, инциденты и плановые задачи. Линия отказов сквозная, а не разовая акция в начале контракта.
Результаты
| Метрика | Значение |
|---|---|
| Задокументированных отказов от оплачиваемых работ | 9 за 24 месяца (06.2024 – 02.2026) |
| Самый быстрый «отказ от проекта» | 0.25 ч — задача про IaC закрыта одним обоснованием |
| Счёт в минус себе | 4.5 ч при контрактных 10 ч/мес, в отчёте — «недоработали» |
| Передача конечного клиента на прямой контракт бюро | ноябрь 2024, по инициативе владельца агентства |
| Рекомендация бюро третьей компании | август 2024: «я тут хочу порекомендовать вас в качестве девопсов» |
| Длительность отношений | 24+ месяца, договор продлевается |
Итог этой проверки выглядел так. В ноябре 2024-го владелец агентства сам предложил: «хотим этого клиента передать вам на прямой контракт. Возьмёте?» Для рынка субподряда это исключение: субподрядчика от конечного клиента обычно прячут, а не знакомят с ним напрямую. Ещё раньше, в августе, тот же владелец рекомендовал бюро знакомой компании как DevOps-подрядчика. Рекомендация и переданный контракт — единственная «выручка» этого кейса, и она оказалась больше всех часов, от которых мы отказались.
Команда
- Инженер-сисадмин (бюро): основной поток задач; автор большинства отказов из этого кейса
- Инженер (бюро): точечные подключения (пресейл, консилиумы по железу и БД)
- Антон Херсун, Xaver Pro — руководитель проекта
Выбираете DevOps-подрядчика на абонентку и хотите понять, кого нанимаете на самом деле? Начните так же, как клиент из этого кейса: с небольшой проверки. Пришлите бриф или текущую техническую документацию — мы посмотрим, выделим узкие места, вернёмся с фиксированной оценкой в часах. Если что-то из задуманного делать не стоит, скажем об этом первыми. Разговор бесплатный.