За что вы платите DevOps-подрядчику каждый месяц: разбор счёта

Финансовый директор прислал скриншот счёта. Одна строка: «DevOps-сопровождение: 210 000 ₽». Вопрос: «А за что конкретно?» Это не претензия, он просто готовит бюджет на следующий год и хочет понять структуру затрат. Мы слышим этот вопрос примерно раз в квартал, и хорошо, что его задают. Значит, пора разложить счёт по строкам.

Две части счёта: фикса и пул часов

Наш типовой договор состоит из двух компонентов.

Фикса - это фиксированная ежемесячная оплата за то, что работает само. Точнее, за то, что мы делаем так, чтобы оно работало само: мониторинг и дежурство 24/7, обновления безопасности, ротация сертификатов, резервное копирование и проверка восстановления, плановые обновления инфраструктурных компонентов. Это рутина, которую нельзя забыть, нельзя сделать «когда будет время», и которая при любом нарушении превращается в инцидент. Доступность 99,9% и реакция от 15 минут - это прямое следствие фиксы, а не случайность.

Стоимость фиксы зависит от размера контура. Нода под мониторингом стоит от 14 000 ₽/мес. Если в контуре есть CI/CD, добавляется +50 000 ₽/мес за его сопровождение. Kubernetes-кластер: +100 000 ₽/мес за кластер. Кластер баз данных: +40 000 ₽/мес. Типовой чек с несколькими нодами, кластером и CI/CD выходит в диапазон 150 000-450 000 ₽/мес - это зависит от масштаба и режима работы.

Пул часов - это часть счёта на развитие: запросы, которые выходят за рамки рутинной эксплуатации. Добавить новый сервис в CI/CD, поднять тестовое окружение, переехать на новую версию Postgres, настроить новую панель мониторинга в Grafana, разобрать причины инцидента и внести изменения в оповещения. Это не форс-мажор и не исправление ошибок, это плановые улучшения, которые команда согласовывает в начале месяца.

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

Как выглядит реальный месячный отчёт

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

Состояние инфраструктуры. Доступность сервисов за месяц, число инцидентов по уровням критичности, общее время недоступности (если было). Если доступность держалась выше 99,9% - это одна строка. Если было что-то ниже, отдельный раздел с разбором.

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

Плановые работы. Что из рутины сделано: обновления пакетов, ротация сертификатов, проверка резервных копий, плановые тесты восстановления. Это то, что клиент не видит, пока не прочитает отчёт, и именно поэтому оно попадает в отчёт.

Расход пула часов. Каждая задача из пула - это название, сколько часов потрачено, статус. Выглядит примерно так:

• Настройка оповещений мониторинга по нагрузке базы данных: 3 ч, выполнено
• Обновление конфигурации тестового окружения: 2 ч, выполнено
• Разбор ночного сбоя сервиса 14-го числа, отчёт о причинах приложен: 4 ч

Итого: остаток пула на следующий месяц.

Эта структура пришла к нам не сразу. В 2004-м, когда мы только формализовали первые SLA-договоры, отчёт был гораздо проще: список заявок с приоритетами и временем реакции. Но уже тогда клиент мог сказать: «вот что вы сделали, вот за что я заплатил». Сейчас глубина детализации больше, но принцип тот же.

Честный компромисс: пул часов расходуется неравномерно

Вот что происходит на практике, и мы говорим об этом прямо.

Пул часов иногда недоедается. Команда запланировала задачи на месяц, но приоритеты клиента сдвинулись: выставка, запуск нового продукта, командировки. В итоге из 20 часов пула ушло 11. Деньги заплачены, работа не сделана. Это неудобно для обеих сторон: мы зарезервировали инженерное время, клиент не получил развитие.

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

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

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

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

Что входит в фиксу, а что нет

Частый вопрос при подписании договора: «А это входит в абонентку или нет?»

Входит в фиксу: круглосуточный мониторинг и оповещения, реакция на инциденты по SLA, обновления безопасности ОС и инфраструктурных компонентов, ротация TLS-сертификатов, резервное копирование и ежеквартальная проверка восстановления, ежемесячный отчёт.

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

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

Что с FinOps и видимостью затрат

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

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

Итог

Счёт за DevOps-аутсорсинг - это не абстрактная цифра. Это фикса (закрытая рутина с измеримыми обязательствами) плюс пул часов (зарезервированное инженерное время на развитие) плюс отчёт, который объясняет, куда ушло и то, и другое.

Если вам хочется понять, как устроен счёт для вашего конкретного контура, детали и тарифную сетку смотрите на странице DevOps-аутсорсинга и странице тарифов. Если хотите поговорить о конкретном составе договора под ваш масштаб, пишите.