Оптимизация IT‑расходов: как сократить инфраструктурные издержки без потерь

По данным исследования компании «СТРИМ Консалтинг», российский рынок IT‑услуг достиг 681 млрд рублей в 2023 году, а к 2028 году может вырасти до 1,9 трлн. При этом IT‑инфраструктура остаётся одним из самых быстрорастущих направлений расходов в компаниях.

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

Что входит в IT‑расходы и почему они растут

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

Причины, по которым растут затраты на IT‑инфраструктуру:

• Повышение цен на ПО. В 2023 году, по данным КРОК, стоимость российского корпоративного софта выросла на 10–20%, и в 2024 году тренд сохранился.

• Увеличение расходов на кибербезопасность. По оценкам экспертов проекта «Кибериспытание», бизнес уже тратит на это до 500 млн рублей, и траты будут удваиваться каждые несколько лет.

• Нехватка квалифицированных специалистов. Опрос компании «Консоль» показал, что 64% работодателей испытывают дефицит кадров уровней миддл и сеньор. Это снижает управляемость инфраструктурой.

• Отсутствие контроля. Согласно статистике, до 30% облачных ресурсов оплачиваются, но не используются.

Какие подходы к оптимизации наиболее эффективны

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

• FinOps,
• OpEx,
• аудит.

FinOps: управление финансами в IT

FinOps — это не просто сокращение расходов в облачной среде, а система распределения ответственности и прозрачности. Она объединяет финансы, IT и разработку.

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

В платформу Yandex Cloud встроены механизмы для реализации принципов FinOps: можно настроить бюджеты и уведомления, задать теги и структуру раздельного биллинга, а также использовать детализированную аналитику для контроля расходов. Это упрощает старт и помогает постепенно выстраивать FinOps‑культуру внутри команды.

Перевод расходов в OpEx и автоматизация

Многие компании переходят с крупных капитальных вложений (CapEx) на операционные расходы (OpEx). Например, облачные платформы предлагают модель pay as you go, когда бизнес платит только за используемые ресурсы.

В этом также помогают:

• автоскейлинг — функция автоматического масштабирования;
• планировщики — например, для отключения сервисов в ночное время;
• сканеры неиспользуемых ресурсов.

Аудит и консолидация инфраструктуры

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

Как устроено управление IT‑расходами

Для эффективного управления бюджетом нужна система:

• Кросс‑функциональная команда. В неё входят представители IT, финансов и продуктов. Такая группа совместно отвечает за планирование, контроль и пересмотр расходов на инфраструктуру.

• Политика тегирования. Вся инфраструктура размечается с помощью тегов по проектам, командам, бизнес‑направлениям и средам — например, dev/test/prod. Это позволяет точно понимать, кто и для чего использует ресурсы.

• Бюджетирование. Устанавливаются лимиты на расходы, настраиваются уведомления при приближении к порогам и автоматические действия при их превышении — например, временное отключение ресурсов. Это помогает избежать неожиданных перерасходов.

• Регулярная аналитика. Строятся дашборды с ключевыми метриками: распределение расходов по тегам, уровень утилизации и траты, которые не удалось точно привязать к конкретным проектам, командам или владельцам. Это позволяет вовремя находить аномалии и корректировать использование ресурсов.

Даёт ли оптимизация реальный эффект, можно отслеживать по метрикам:

Каких ошибок стоит избегать при оптимизации: чек‑лист

1. Отсутствие анализа и расчётов. Перед внедрением любой оптимизации и DevOps‑практик нужно просчитать окупаемость и понять, насколько компании выгодны эти вложения и готова ли она к ним сейчас.

2. Поспешные сокращения. Быстрые и агрессивные меры, такие как чрезмерное снижение размеров инстансов или отказ от резервирования, могут снизить производительность и даже вызвать отказы критически важных систем.

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

4. Размытое распределение ответственности. Если нет политики тегирования и аллокации, когда ответственность за расходы закреплена за конкретными командами или проектами, то риск перерасхода возрастает.

5. Игнорирование безопасности и отказоустойчивости. Пытаясь сэкономить, компании могут урезать затраты на безопасность, отказоустойчивость или резервное копирование. Это повышает риски инцидентов, которые приведут к ещё большим расходам.

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

Как провести аудит инфраструктуры: кейс производителя мебели

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

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

1. Цели и задачи

Клиенту была нужна инфраструктура, способная адаптироваться к скачкам нагрузки, функционировать без постоянного внимания и поддержки большой команды, а также обеспечивать стабильную работу бизнес‑приложений. В идеале — нужна была система, которую можно поддерживать силами 1–2 инженеров.

2. Состояние инфраструктуры

Инфраструктура была собрана на разрозненных виртуальных машинах — без единого архитектурного подхода и с использованием устаревших технологий. Облачные сервисы практически не применялись, из‑за чего усложнялось управление и масштабирование. Вместо управляемого хранилища использовалось собственное — это увеличивало затраты и снижало эффективность использования ресурсов.

3. Автоматизация и CI/CD

Принцип Infrastructure as Code (IaC) применялся частично и без полноценного контроля версий. Это приводило к ошибкам при внесении изменений и усложняло сопровождение. Сквозной автоматизации релизов не было — процессы сборки и выкладки сервисов оставались ручными или фрагментарно автоматизированными. Особенно трудозатратными были задачи по развёртыванию в новых средах.

4. Мониторинг и алерты

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

5. Архитектура и сетевые настройки

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

6. Масштабирование и устойчивость

Пиковые нагрузки регулярно приводили к сбоям из‑за нехватки ресурсов. Инфраструктура не была рассчитана на масштабирование: приходилось либо держать избыточный запас, либо мириться с потерей доступности. Сценарии автоскейлинга не были реализованы.

7. Безопасность

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

По итогам аудита мы получили сводку ключевых проблем и решений:

По предварительным расчётам, реализация этих шагов может сократить инфраструктурные расходы до 30%. Сейчас мы вместе с командой клиента находимся в процессе пошагового внедрения всех рекомендованных изменений.

Что в итоге

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

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

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