В статье IT-World разберет, почему «классическая окупаемость» инфраструктуры редко работает как аргумент, какие расходы компании системно не закладывают, как считать TCO «по-взрослому» и в каких сценариях облако выигрывает даже тогда, когда на бумаге выглядит дороже. Также рассмотрим цену простоев, роль DR (Disaster Recovery — аварийное восстановление), гибридные модели и момент, когда размещение инфраструктуры на стороне компании действительно оправданно.
Облачные сервисы часто сравнивают с собственной инфраструктурой напрямую: стоимость серверов и лицензий против цены подписки. Проблема в том, что такой подход почти всегда искажает реальную экономику. Он не учитывает стоимость эксплуатации, цену простоев, нагрузку на ИТ-команду и распределение затрат во времени. В результате решения принимаются не на основе реального TCO (Total Cost of Ownership — совокупная стоимость владения), а на основе расчетов, оторванных от реальности.
В статье разберем, почему «классическая окупаемость» инфраструктуры редко работает как аргумент, какие расходы компании системно не закладывают, как считать TCO «по-взрослому» и в каких сценариях облако выигрывает даже тогда, когда на бумаге выглядит дороже. Также рассмотрим цену простоев, роль DR (Disaster Recovery — аварийное восстановление), гибридные модели и момент, когда размещение инфраструктуры на стороне компании действительно оправданно.
Почему честный расчет TCO переворачивает разговор об инфраструктуре
Сравнение «железо + лицензии» удобное, но неполное. В облаке вы покупаете не просто ресурсы, а готовый сервис с ответственностью провайдера, поддержкой и SLA (Service Level Agreement — соглашение об уровне сервиса). В on-prem значительная часть работ и рисков лежит на внутренней команде: администрирование, обновления, резервное копирование, мониторинг, реагирование на инциденты, обеспечение отказоустойчивости и безопасность. Эти затраты часто либо не считаются вовсе, либо учитываются формально, и именно поэтому позже возникает ощущение, что «по расчетам выходило дешевле».
Облачная стратегия vs точечная аренда ресурсов
Второй слой — распределение затрат во времени. Расходы на облако обычно закладываются в OPEX (Operating Expenditure — операционные расходы): платежи осуществляются постепенно и легче масштабируются. On-prem требует CAPEX (Capital Expenditure — капитальные расходы): крупные вложения «в моменте», отдельные процедуры согласования и более жесткую привязку к циклам закупки и обновления инфраструктуры. Для бизнеса это не только про цену, но и про управляемость денег и скорость изменений.
Почему «лобовое сравнение» почти всегда некорректно
Типовая ошибка выглядит так: компания складывает стоимость оборудования и лицензий, сравнивает с ценой облачного сервиса, делит одно на другое и получает «точку окупаемости». Дальше звучит привычный вывод: через несколько лет свое «железо» окупится, значит, выгоднее. Но само по себе такое сравнение некорректно: оно сопоставляет покупку инфраструктуры с использованием сервиса, хотя это принципиально разные модели затрат и ответственности.
Во-первых, деньги, не замороженные в инфраструктуре, остаются в обороте бизнеса и могут работать на рост. Это особенно заметно в периоды, когда важны скорость запуска проектов и гибкость бюджета. Во-вторых, деньги сегодня дороже, чем завтра (инфляция и стоимость капитала). В-третьих, нельзя сравнивать «инфраструктура + лицензия» с сервисом, не учитывая эксплуатацию, SLA и реальную нагрузку на внутреннюю команду.
CAPEX и OPEX: вопрос не только цены, но и управляемости
Для быстрорастущего бизнеса, новых направлений или сценариев с переменной нагрузкой облако часто выигрывает именно управляемостью: платежи распределены и не создают большой денежной нагрузки «здесь и сейчас». В on-prem бизнес вынужден покупать инфраструктуру с запасом на 2–3 года вперед, и это превращает условную «единицу мощности» в 1,5–2 единицы стоимости еще до того, как ресурсы реально понадобятся.
Самая недооцененная строка расходов — простой
Поломки, инциденты безопасности, сбои оборудования и нарушения доступности невозможно предсказать по времени, а значит, их сложно «ровно» заложить в бюджет. Но последствия считаются достаточно просто: если простой останавливает бизнес-процессы, можно оценить потерю выручки за период остановки. Это и есть стоимость простоя, так как ее почти никогда не удается компенсировать в будущем, условно «продав в два раза больше». Поэтому аргумент про доступность и устойчивость — это не абстракция, а вполне измеримая экономика.
В больших организациях такой разрыв особенно заметен. Например, отказоустойчивая инфраструктура для крупного ретейлера может стоить сотни миллионов рублей, а стоимость простоя одного дня для компании доходит почти до миллиарда — в подобных условиях инвестиции в устойчивость окупаются достаточно быстро.
Disaster Recovery в облаке. Как резерв перестает быть балластом
Один из практичных способов удешевить DR (Disaster Recovery — аварийное восстановление) — вынести резервный контур в облако. Сценарий давно отработан: оплачиваются в основном хранение данных и минимальная «дежурная» конфигурация, а вычислительные ресурсы масштабируются только в момент инцидента. Как правило, на запуск резервного контура требуется 20–30 минут, после чего бизнес может продолжать работу, внося плату за ресурсы по модели фактического потребления.
Интересно, что в России отдельно как услуга растут сервисы резервирования: по данным CNews, к концу 2025 года суммарный объем сегментов BaaS (Backup as a Service — резервное копирование как сервис) и DRaaS (Disaster Recovery as a Service — аварийное восстановление как сервис) мог достигнуть 20 млрд руб.
Почему гибрид — это не компромисс, а нормальный сценарий
Мир не делится на «или облако, или земля». На практике устойчивее всего работает гибридная архитектура, когда часть критичных систем остается on-prem, а облако используется там, где дает максимальную ценность: в тестовых и dev-средах, для резервирования, для пиковых нагрузок без покупки «лишнего» оборудования. Такой подход позволяет удерживать базовую предсказуемость и одновременно не переплачивать за запас мощностей «на всякий случай». Типовые сценарии гибридной модели:
• Продакшен (рабочий контур) размещается on-prem, тестирование и разработка — в облаке. • DR в облаке при основном контуре on-prem. • Пики (маркетинг, сезонность, кампании) закрываются облаком без покупки «лишнего» оборудования.
Где реальность, а где «мнимая уверенность»
Ощущение «держу сервер в отдельной комнате и закрываю на ключ» дает психологический комфорт, но не гарантирует реальную защищенность. Крупные провайдеры выстроили процессы, сертификации и практики, которые в обычной компании зачастую сложно поддерживать на таком же уровне постоянно. При этом ключевой вопрос безопасности все равно остается не про место размещения, а про управление доступами, резервирование и процессы реагирования на инциденты.
Перспективное направление — конфиденциальные вычисления (Confidential Computing — технологии, позволяющие дополнительно защищать данные во время обработки). Это потенциальный способ безопаснее работать с чувствительными данными в облаке в будущем, не упираясь только в географию инфраструктуры и закрывая требования регуляторики в работе с данными.
Когда on-prem действительно оправдан
On-prem действительно может быть выгоднее в сценариях с постоянной нагрузкой 24×7, близкой к 100% использования ресурсов, особенно если это критичная продакшен-система, где важны гарантированный ресурс и максимальная производительность. Здесь работает простая механика: облако особенно эффективно, когда нагрузка изменчивая, и вы платите за масштабирование по мере необходимости. Когда нужен постоянный «пик» и гарантированный физический ресурс, стоимость сервиса может расти быстрее.
Кроме экономики, есть и неэкономические факторы, которые легко ломают идеальную модель: регуляторные требования закрытого контура, отсутствие качественного Интернета, удаленные площадки, ограничения по размещению данных и требования к интеграции с локальными системами.
Есть ли точка, где облако становится невыгодным во времени
Если говорить честно, «точка», где облако перестает быть выгодным только потому, что прошло время, встречается редко. Оборудование устаревает, через 4–5 лет инфраструктуру все равно приходится обновлять, а вернуть остаточную стоимость сложно — «железо» дешевеет быстро. Поэтому корректнее смотреть не на «вечную окупаемость», а на управляемость затратами, скоростью изменений и ценой рисков в конкретном сценарии.
В споре «облако или on-prem» чаще всего побеждает не технология, а честная математика: TCO плюс стоимость простоев и цена управляемости. «Лобовые» сравнения по «железу» и лицензиям создают иллюзию контроля, но не показывают реальную нагрузку на команду и риски. На практике выигрышной все чаще оказывается гибридная модель: базовую предсказуемую нагрузку держат on-prem, а пики, dev/test и DR выносят в облако. И это тот случай, когда экономика и здравый смысл действительно совпадают.