За что вы платите 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 мелких события (упал pod, сертификат обновился с предупреждением, диск подошёл к порогу) и ноль Sev-1. Неспокойный месяц — отдельный разговор.

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

Расход пула часов. Каждая задача из пула — название, сколько часов потрачено, статус. Выглядит примерно так: «Настройка алертинга по метрикам Redis — 3 ч, выполнено. Обновление Helm chart для staging — 2 ч, выполнено. Разбор деградации API в ночь на 14-е — 4 ч, постмортем приложен». Итого: остаток пула на следующий месяц.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Итог

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

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