Как российский технический директор урезал расходы на инфраструктуру в два раза и что из его опыта применимо на других рынках?

Итоги интервью: ключевые тезисы и что они значат для рынка.

Расходы на инфраструктуру растут быстрее выручки, потому что решения принимаются фрагментарно: где-то переплата за неиспользуемые ресурсы, где-то дублирование мощностей, где-то устаревшие тарифы. Финансовый директор видит общую сумму, технический директор — зоопарк сервисов и отсутствие прозрачной атрибуции затрат. Без единой картины потребления и стоимости владения любые сокращения превращаются в риск для стабильности. Корень проблемы — не в ценах поставщиков, а в отсутствии управленческого учёта инфраструктуры как продукта с метриками и владельцем.

Связанные услуги: каталог, AI Boost Team, стать клиентом.

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

Это главное из разговора, который я разбирал на этой неделе. Собеседник — технический директор российской компании среднего бизнеса, 50–500 сотрудников, гибридная инфраструктура: часть в облаке, часть на своём железе, свои каналы, свои лицензии. Имя, компанию и провайдера не называю — договорённость о неразглашении. Расшифровку ниже режу по смыслу, не по хронологии.

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

Пять реплик из разговора и что за ними стоит

«Мы два года думали, что у нас дорогое облако. Оказалось, у нас дорогая неопределённость».

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

Пока этой таблицы нет, любой разговор о сокращении — гадание. Финансовый директор видит общую сумму, вы видите зоопарк сервисов, и оба не можете показать, где именно деньги превращаются в ноль.

«Я не могу сокращать то, у чего нет владельца. Как только у сервиса появилась фамилия, у затрат появился предел».

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

Дальше — тегирование. Единые метки: команда, продукт, среда prod/stage/dev. Не ради красивой картинки в дашборде.

«Тег — это не биллинг. Это способ спросить у команды, зачем ей пять сред».

Именно так. Тег даёт возможность задать вопрос по адресу и получить ответ. Побочный эффект — команды сами начинают выключать dev-среды на ночь, потому что теперь их витрата видна в общем отчёте.

«Мы не торговались. Мы пришли с таблицей, где видно, что 20–30% мощностей не производят ничего».

Ориентир по доле неиспользуемых ресурсов в типовой инфраструктуре среднего бизнеса — 20–30%. Это оценка из практики, не отраслевое исследование, и на вашей инфраструктуре цифра будет своей. Но порядок обычно такой.

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

«Резервируемые мощности — это скидка за то, что вы наконец знаете свой профиль нагрузки».

Непиковые нагрузки на резервируемые мощности, отказ от избыточных реплик и снапшотов, консолидация баз данных и хранилищ. Каждый шаг — только там, где он не бьёт по SLA. Где бьёт — сначала компенсирующая мера, потом сокращение. Не наоборот.

«Самый дорогой инцидент — тот, который мы предотвратили, а он не попал в отчёт».

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

3 цитаты, которые стоит запомнить

1. «Дорогая неопределённость» — точная формулировка того, что происходит до инвентаризации. Не цены высокие. Непонятно, за что именно вы платите.
2. «Не могу сокращать то, у чего нет владельца» — организационное условие любой экономии. Без фамилии в таблице сокращение вернётся через квартал.
3. «Скидка на неправильно подобранный объём — скидка на перерасход» — почему торг с провайдером идёт последним шагом, а не первым.

С чего начинается экономия — с торга или с таблицы?

С таблицы. Торг без инвентаризации даёт разовый эффект, который съедается через 2–3 квартала: объёмы вырастут, тариф останется «выгодным» только на бумаге.

Метрики до и после: что фиксировали

Каждый шаг замерялся до/после. Не по итогам проекта, а по ходу — иначе экономия превращается в историю, которую нельзя защитить перед финдиректором.

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

Почему 100% атрибуции не нужно?

Потому что остаток — это общие сервисы: мониторинг, логирование, сеть, безопасность. Их дешевле держать в пуле, чем размазывать по командам с точностью до 0%. Гонка за 100% съест больше времени, чем сэкономит денег.

Когда это не сработает

Честная часть разговора, которую обычно вырезают из кейсов.

• Инфраструктура полностью аутсорсена без доступа к детализации. Если вы получаете один счёт и одну строку «услуги хостинга», тегирование не запустить. Первый шаг — не оптимизация, а переговоры о раскрытии детализации. Без этого вы покупаете файл, не решение.
• Нет выделенного владельца инфраструктуры. Если в компании это «все и никто», ревизия превращается в общественную нагрузку и умирает через 2 месяца после первого отчёта.
• Фаза резкого роста. Когда выручка растёт быстрее, чем вы успеваете пересобирать конфигурацию, экономия на мощностях напрямую тормозит продукт. Здесь задача другая: не урезать, а поставить учёт, чтобы понимать цену роста.
• Жёсткие регуляторные требования. Запрет менять площадку, класс хранения или контур обработки данных обнуляет половину шагов. Остаётся консолидация и пересмотр тарифов внутри разрешённого периметра.
• Экономия на резервировании критичных сервисов. Классическая ошибка: срезали реплику у сервиса, который держит выручку, и получили простой дороже годовой экономии.
• Слепое копирование чужой архитектуры. Профиль нагрузки у всех разный. Что дало минус 40–50% у одного, у другого даст инцидент в первый же месяц.

И главное ограничение — отсутствие регулярного цикла. Разовая ревизия возвращает перерасход обратно. Работает цикл: раз в месяц отчёт, раз в квартал пере