Цена виртуальной машины сама по себе почти ничего не говорит об экономике ИТ. Ключевой показатель здесь — стоимость полезной нагрузки: сколько бизнес платит не за CPU-час как таковой, а за обработанную транзакцию, пользовательский час, расчетное задание, тестовый контур или витрину данных. Именно с этой точки, а не со спора «свой сервер или облако», CIO и CFO стоит начинать разговор об облачной модели, сообщает IT-World.
Главная мысль простая, хотя в корпоративной инфраструктуре ее упорно пытаются не замечать: бизнесу не нужен сервер в стойке. Бизнесу нужна работа, которую этот сервер выполняет. Поэтому сравнение «аренда VM против купленного железа» выглядит логично только на первом слайде презентации. Как только дело доходит до реальной эксплуатации, в расчет лезет все то, что обычно стыдливо прячут в сноски: СХД, сеть, лицензии, резервирование, электричество, охлаждение, место в стойке, администрирование, мониторинг, ИБ, обновления, аварийные замены, запас по мощности, закупочные циклы и стоимость капитала.
Отдельная неприятность собственного контура — деградация экономики во времени. Сервер, купленный сегодня, через три года не просто стареет физически: он уже проигрывает рынку по производительности на единицу вложений. В нормальной финансовой модели это учитывают через срок жизни оборудования, NPV и падение относительной производительности. И тут выясняется, что любимый аргумент «мы уже купили сервер, значит он дешевле облака» работает только при очень грубом подсчете. Для финансового блока важнее другое: сколько стоит единица результата, какова фактическая утилизация, что происходит в пике, сколько стоит простой, во сколько обходится недозаказанная мощность и сколько времени занимает запуск нового проекта.
Центральный показатель в этой логике — утилизация. Если железо загружено неравномерно, собственная инфраструктура быстро теряет видимую дешевизну. В статье приводится базовая логика сравнения: стоимость собственного контура нужно делить на фактическую загрузку, а не на паспортную мощность. Иными словами, если инфраструктура работает на 30% возможностей, то каждая единица результата становится заметно дороже. Не потому, что сервер плохой, а потому, что компания оплатила весь объем ресурсов, а ценность создается только третью от него.
Пример показательный: контур куплен под пик в 1000 условных единиц мощности, а средняя нагрузка держится на уровне 350. Финансово организация уже оплатила 1000, но реально потребляет 350. Остальное — страховка от всплеска спроса, длинного закупочного цикла, медленного capacity planning и управленческого страха «вдруг не хватит». В этом месте и появляется стоимость полезной нагрузки как более честная метрика. Она быстро показывает, что дешевый сервер-час может скрывать дорогую бизнес-операцию.
Облако в такой модели интересно не только тем, что его можно быстро масштабировать. Для CFO важнее другой эффект: эластичность переносит часть риска на провайдера. Есть два типовых сценария, в которых компании теряют деньги. Первый — купили мощности с запасом, но пик не случился: проект задержался, сезон оказался слабее, продуктовая гипотеза не взлетела, дочерняя структура так и не подключилась. Деньги уже ушли, актив стоит, пользы меньше, чем ожидалось. Второй сценарий обратный: купили слишком мало, пик пришел, система просела, SLA сорван, пользователи ушли, бизнес потерял выручку или доверие. На бумаге инфраструктура могла выглядеть экономной, а по факту оказалась дорогой.
У облачной модели здесь практическое преимущество: если нагрузку можно распараллелить, компания покупает не просто ресурсы, а время до результата. Нужно пересчитать отчет за час вместо суток — можно краткосрочно взять больше мощности. Нужно быстро поднять среду — подняли. Не нужна — выключили. Конечно, это не отменяет архитектурной дисциплины: плохо спроектированная система и в облаке сожжет бюджет без всякой жалости. Но при нормальном управлении облако позволяет платить ближе к реальному профилю потребления, а не к гипотетическому максимуму, который может случиться раз в квартал.
Лучше всего эта экономика работает там, где нагрузка переменная. Сезонные сервисы, проектные контуры, короткие вычислительные окна, тестовые среды и аналитика — все это естественные кандидаты. В крупных компаниях среды разработки и тестирования часто живут годами, хотя реально нужны несколько часов в день или несколько дней перед релизом. В облаке такие контуры можно поднимать по расписанию, отключать на ночь, ограничивать квотами и привязывать затраты к конкретному продукту. Для продактов и руководителей разработки это уже не абстрактная «оптимизация ИТ», а прозрачная модель затрат по командам и инициативам.
Аналогичная история с аналитикой. Если бизнесу важен не постоянный уровень мощности, а конкретное окно выполнения, то логика «железо должно стоять всегда» начинает выглядеть странно. Еще один сильный сценарий — резервирование и disaster recovery. Держать полностью симметричный второй контур в собственном ЦОДе дорого и часто экономически сомнительно. Облачная модель позволяет собирать разные уровни готовности — от холодного резерва до почти горячего — без закупки полного объема инфраструктуры на старте. Для групп компаний добавляется еще один аргумент: облако упрощает унификацию сервисов, стандартов безопасности и платформенных решений между дочерними структурами с разным уровнем зрелости. Особенно это полезно для бизнеса, который растет через M&A и получает в наследство зоопарк ИТ-подходов.
Но честный разговор об облаке начинается не с восторга, а с ограничений. Если нагрузка стабильная 24/7, хорошо прогнозируется, держит высокую утилизацию и не требует быстрого масштабирования, собственная инфраструктура может оказаться рациональнее. Особенно если у компании дешевая площадка, зрелая эксплуатация, сильная ИБ и понятный горизонт загрузки. Для крупнейших групп собственное облако вообще может стать внутренней индустриальной платформой. Правда, только при одном условии: внутренний ИТ должен реально уметь работать как провайдер. Поставить серверы и прикрутить портал самообслуживания недостаточно. Нужны каталог услуг, SLA, capacity management, FinOps, chargeback или хотя бы showback, стандарты платформы, процессы обновлений, поддержка 24/7, безопасность, документация и понятная зона ответственности.
Есть и технические ограничения, которые нельзя замазать красивой презентацией. Дорогой трафик, чувствительность к задержкам, тяжелый legacy, лицензии с привязкой к ядрам или площадке — все это делает сценарий «перенесем как есть в облако» скорее дорогим, чем эффективным. Из этого следует, пожалуй, самый полезный вывод для российской ИТ-аудитории: спорить о выгоде облака на уровне цены VM уже поздно. Вопрос теперь в другом — умеет ли компания считать стоимость полезной нагрузки и связывать инфраструктурные расходы с конкретным результатом для продукта и бизнеса. У кого эта метрика появится раньше, тот и перестанет покупать мощности на всякий случай.