Экономика облака начинается не с цены виртуальной машины и выбора «купить сервер или арендовать». Правильная точка входа для CIO и CFO - показатель cost-per-workload: стоимость обработанной транзакции, пользовательского часа, расчетного задания, тестового контура, витрины данных и продуктовой среды.
Если считать только сервер-час, как обычно и делают, собственная инфраструктура нередко выглядит дешевле. Сервер куплен, стоит в стойке, амортизируется, бухгалтерия его уже провела. Но это плохая математика. Сервер сам по себе бизнесу не нужен. Нужна полезная работа, которую он делает. Вот тут-то становится целесообразно говорить об облаке, как о финансовом инструменте. Причем, эффективном.
Почему «купить сервер дешевле» — это слабый аргумент
У собственного ЦОДа компании есть неприятная особенность: он хорошо выглядит в презентации закупки, плохо — в динамике эксплуатации.
В расчет всегда попадают «обязательные дополнения». Там есть СХД, сеть, лицензии, резервирование, электричество, охлаждение, место в стойке, администрирование, мониторинг, ИБ, обновления, аварийные замены, запас по мощности, закупочные циклы и стоимость капитала. Добавим сюда же технологическое «старение»: через три года час CPU уже не тот. В моделях реальной стоимости это прямо учитывается через срок жизни оборудования, NPV и деградацию производительности железа относительно рынка.
В общем, попытка напрямую сопоставить «виртуальную машину в облаке» и «купленный сервер» ни к чему продуктивному не приведет. Для CIO и CFO важны другие показатели:
- сколько стоит полезная нагрузка;
- какова фактическая утилизация;
- что происходит в пике;
- сколько стоит простой;
- сколько стоит недозаказанная мощность;
- сколько времени занимает запуск нового проекта.
Если у компании нагрузка ровная, предсказуемая, с высокой утилизацией и зрелой эксплуатацией, собственный контур может быть рационален. Но если инфраструктура покупается под пик, а большую часть времени стоит полупустой, экономика быстро меняется.
Утилизация как основа эффективности
Для облака критична утилизация. В классической формуле сравнения облака и собственного дата-центра это видно довольно отчетливо.
UserHours_cloud × (Revenue − Cost_cloud) ≥ UserHours_datacenter × (Revenue − Cost_datacenter / Utilization)
Смысл простой: собственная инфраструктура должна окупаться не номинальной стоимостью сервера, а стоимостью сервера, деленной на фактическую утилизацию. Если железо загружено на 30%, полезная единица работы становится сильно дороже. Не потому что сервер плохой. Потому что две трети мощности оплачены, но не создают ценности.
Допустим, контур куплен под пик в 1000 условных единиц мощности. Средняя нагрузка — 350. Финансово компания оплачивает 1000, бизнес фактически потребляет 350. Остальное — страховка от пика, закупочного цикла, медленного capacity planning и страха «вдруг не хватит».
В облаке страховка устроена иначе. Ресурс можно добавить на время и выключить, когда он не нужен. Это никак не отменяет архитектурной дисциплины: плохая архитектура в облаке тоже стоит дорого. Однако при нормальном управлении компания платит ближе к профилю реальной нагрузки.
Эластичность как снижение рисков
Эластичность часто продают как «можно быстро масштабироваться». Для финансового директора важнее другое: эластичность переносит часть риска с компании на провайдера. О чем идет речь? Есть два риска.
Первый — купили больше, чем нужно. Пик не случился, проект задержался, сезон оказался слабее, дочернее общество не подключилось, продуктовая гипотеза не взлетела. Железо уже в бюджете. Деньги потрачены.
Второй — наоборот, купили меньше, чем нужно. Пик случился, система легла, пользователи ушли, внутренний заказчик получил SLA ниже обещанного, бизнес потерял выручку или доверие. На бумаге инфраструктура была дешевле. В реальности нет.
Облаку на неопределенность спроса, по большому счету, все равно. Если задачу можно распараллелить, компания покупает время до результата. Надо пересчитать отчет за час, а не за сутки? Берем больше мощности на час. Не нужно — выключаем. И так далее. В собственном контуре для этого пришлось бы держать резерв постоянно.
Где облако дает экономику
Самый понятный сценарий с переменной нагрузкой. Все, что имеет пики, сезонность или проектный характер, обычно хорошо ложится на облачную модель.
Среды разработки и тестирования — отдельный «наболевший», так сказать, вопрос. В крупных компаниях они часто живут годами, хотя нужны несколько часов в день или несколько дней перед релизом. В облаке такие среды можно поднимать по расписанию, выключать на ночь, ограничивать квотами и относить затраты на конкретный продукт.
Аналитика, которой важна не постоянная мощность, а окно выполнения. Если бизнесу нужно получить расчет к утру, инфраструктура должна быть подобрана под срок.
DR и резервные площадки в собственном ЦОДе — вопрос экономически сомнительный, так как для компании держать полностью симметричный второй контур дорого. Облачная же модель позволяет строить разные классы готовности: от холодного резерва до почти горячего, но без закупки всего объема «железа» на старте.
И последнее - сценарий в группах компаний. Когда у головной компании есть ИТ-команда, у дочерних обществ тоже есть, но разной зрелости. Облачная модель помогает унифицировать сервисы, стандарты безопасности и платформенные решения, сохранив при этом прозрачность потребления для разных бизнес-единиц. Такой подход особенно полезен для компаний, растущих через M&A.
Когда облако будет невыгодным
Честный разговор об экономике требует и обратной стороны. Все-таки есть сценарии, где собственные мощности компании выигрывают.
- Если нагрузка стабильная 24/7, хорошо прогнозируется, имеет высокую утилизацию и не требует быстрого масштабирования, купленная инфраструктура может выиграть. Особенно если компания умеет эффективно эксплуатировать железо, имеет дешевую площадку, зрелую ИБ и понятный горизонт загрузки.
- Если компания сама по себе является рынком, на котором можно создать собственного инфраструктурного «монополиста» для головной организации, дочерних обществ и внутренних продуктов. Другими словами, для отдельных крупнейших групп собственное облако может выступать как мощная индустриальная платформа.
Небольшой контекст для второго пункта: масштаб без зрелости не работает. Купить серверы и поставить портал самообслуживания не равно быть провайдером. Нужны каталог услуг, SLA, capacity management, FinOps, chargeback или хотя бы showback, стандарты платформы, процессы обновлений, поддержка, эксплуатация 24/7, безопасность, документация и внятная модель ответственности.
- Если внутренний ИТ уже умеет оказывать сервис как провайдер, экономика собственного облака может быть сильной. Если нет — внешний облачный провайдер выигрывает не только ценой железа, но и операционной зрелостью.
- У компании есть технические ограничения. К примеру, нагрузки с дорогим трафиком, чувствительные к задержкам системы, legacy с тяжелой миграцией, лицензии, привязанные к ядрам или площадке, и др. В таких случаях миграция «перенесем все как есть в облако» редко дает эффективность. Сначала надо понять профиль workload, потом уже выбирать модель.
Что считать перед переходом
Хороший бизнес-кейс начинается с инвентаризации нагрузки.
Нужно посчитать фактическую утилизацию CPU, RAM, storage и сети. Не выделенную, а реально потребленную. Затем — профиль нагрузки: средняя, пик, сезонность, окно обработки, допустимое время простоя.
Отдельно считаются люди и процессы. Сколько стоит команда эксплуатации? Сколько времени уходит на закупки, ввод мощностей, обновления, аварии, согласования с ИБ? Сколько стоит задержка запуска продукта на два месяца из-за инфраструктуры?
Потом идут лицензии, сетевой трафик, хранение, резервное копирование, DR, требования к журналированию, шифрованию и сегментации. И обязательно — сценарий выхода. Не потому что провайдер может оказаться плохим, а потому что архитектура без плана выхода из облака превращает экономику в зависимость.
Уже после миграции нужен FinOps. Без него облако быстро становится дорогим: забытые виртуальные машины, избыточные диски, неправильные классы хранения, отсутствие квот, отсутствие владельцев ресурсов. Облако не экономит само по себе. Оно дает механизм экономить.
Российский контекст: регуляторика
Отдельная глава про регуляторику не является целью этой статьи, но обойти российский контекст совсем не получится, потому что он напрямую влияет на экономику выбора.
Требования к локализации данных, отраслевые стандарты, необходимость работать на сертифицированном стеке — все это долгое время воспринималось как барьер для облака. Логика была простая: compliance проще обеспечить, когда инфраструктура физически под контролем. Облако в этой картине мира выглядело как риск, а не как инструмент.
Однако рынок адаптировался. Российские облачные вендоры, включая Astra Cloud, научились строить инфраструктуру под регуляторику, то есть с нужными сертификатами, с данными, которые не покидают защищенный контур, с возможностью пройти аудит и аттестацию. Вместе с этим сложилась новая практика: бизнес начал совмещать требования регулятора с экономической эффективностью облака через гибридные сценарии.
Чувствительные данные и критичные системы остаются на собственной или частной инфраструктуре — там, где это необходимо. Переменная, пиковая и менее чувствительная нагрузка уходит в облако, давая ту самую эластичность, за которую и ценят этот подход.
Есть одно «но». Гибридная модель работает только тогда, когда провайдер одинаково хорошо закрывает все виды поставки. На практике у многих игроков рынка on-premise либо формальная опция, либо отдельный продукт с другой архитектурой и другой командой. Поэтому выбор облачного поставщика является такой же частью экономического решения, как выбор между облаком и собственной инфраструктурой.
Подытожим
Облако выгодно, когда снижает стоимость полезной работы, повышает утилизацию, сокращает время запуска и переносит часть инфраструктурных рисков на провайдера. Для CIO — это все, что связано с архитектурой. Для CFO — TCO и стоимость капитала. Для бизнеса — скорость и устойчивость.
Глобально вопрос выбора должен звучать так: для каких рабочих нагрузок облако даст лучшую экономику, а где собственный или выделенный контур будет эффективнее?