Почему дешевое облако – это победа в тендере, но проигрыш в бизнесе

В тендерной таблице две конфигурации могут выглядеть совершенно одинаково: по восемь vCPU каждая. Но по фактической мощности это могут быть совершенно разные системы.

vCPU – это единица учета, а не производительности. Она удобна для выставления счетов и контроля вычислительной мощности, но по одному количеству vCPU сравнивать реальные возможности систем нельзя. В центральную таблицу, как правило, попадает число vCPU, но не конкретная модель CPU и ее характеристики. В требованиях может быть указан минимальный уровень процессора, однако какой именно CPU предоставляет поставщик, тендерная форма обычно не учитывает.

Само понятие vCPU, т.е. виртуального ядра, у провайдеров тоже различается. У одного поставщика оно соответствует логическому потоку, у другого – физическому ядру. Поэтому при одинаковой записи в тендерной таблице или коммерческом предложении формально одинаковые варианты могут различаться по доступной вычислительной мощности как минимум вдвое.

Кроме того, одно физическое ядро провайдер может распределять между несколькими виртуальными машинами. Этот параметр напрямую влияет на быстродействие, но в тендерной документации часто отсутствует. И сама по себе цена vCPU не отвечает на главный вопрос: сколько вычислительной мощности потребуется для конкретной бизнес-задачи.

Более дорогой vCPU вполне может оказаться выгоднее. Но и высокая цена сама по себе ничего не говорит о качестве ресурса. Сначала нужно сравнить производительность на реальной нагрузке, а уже затем – итоговую стоимость.

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

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

Тогда появляется ответ на вопрос, которого обычно нет в тендерной документации: сколько ресурсов каждому поставщику реально требуется, чтобы выполнить заданную работу с нужным результатом. И только после этого имеет смысл сравнивать стоимость. Покупают не набор vCPU и RAM, а возможность выполнить конкретную бизнес-задачу с заданным результатом.

Рассмотрим типичную ситуацию. Дистрибьютор, 250 сотрудников. Учетная система, склад, портал для контрагентов, интеграции с маркетплейсами. Тендер самый обычный: в задании – 40 ядер, память, диски; на столе – три предложения. Побеждает то, которое примерно на 20% дешевле.

Через три месяца выяснилось, что закрытие периода вместо четырех часов занимает девять. Конфигурация формально не изменилась – те же 40 ядер, но разделяемый тариф и более низкая частота CPU не обеспечили прежней производительности. Для однопоточной операции это стало критичным. Чтобы вернуть время закрытия к приемлемому уровню, компании пришлось перейти на тариф с гарантированной долей ядра и расширить вычислительную конфигурацию примерно до 70 ядер.

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

Отдельно выросли расходы на резервное копирование. В техническом задании компания указала 7 Тбайт продуктивных данных. Но для расчета стоимости хранения нужно учитывать не только рабочий объем, но и все копии: ежедневные за месяц и ежемесячные срезы. В результате провайдер выставил счет уже за 22 Тбайт, втрое больше исходного объема. В результате счет вырос примерно вдвое относительно того, что закладывали в бюджет.

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

Компания сэкономила миллион на бумаге и переплатила больше миллиона живыми деньгами.

При этом проигравший поставщик тоже вышел бы за смету – примерно на 40%. Ни трафик, ни реальный объем копий, ни лицензии не были учтены ни в одном предложении. Победитель тут ни при чем: проблема была в самой тендерной модели, но в одном случае ошибка оказалась вдвое дороже.

Почти все коммерческое ПО – от платформ виртуализации до систем управления базами данных и прикладных систем – лицензируется по ядрам. Если более производительные ядра позволяют обойтись меньшим количеством vCPU, экономия возникает сразу по двум направлениям. Медленный CPU в таком сценарии увеличивает расходы: требуется больше вычислительной мощности, а значит, больше лицензий.

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

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

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

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

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

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

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

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

Ключевые провайдеры фиксируют общий уровень доступности на уровне трех девяток (99,9%), а при определенных условиях доступен и более высокий показатель. Но сама цифра мало о чем говорит. Важно понять, что именно провайдер считает доступностью виртуальной машины, сети, дисковой подсистемы или сервиса целиком.

Есть и еще одна важная граница. SLA может гарантировать доступность сервиса, но не регламентировать, насколько быстро он должен работать. Формально доступная машина при этом может работать значительно медленнее необходимого уровня. Для бизнеса это принципиальная разница: система может не считаться недоступной, но уже не выполнять свою задачу с нужной скоростью.

При disaster recovery нужно разделять доступность и восстанавливаемость. SLA в основном описывает штатную работу сервиса. При аварии действуют уже другие параметры: за какое время систему нужно восстановить и какой объем данных допустимо потерять (RTO и RPO).

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

Долгосрочный контракт на инфраструктуру нельзя строить вокруг фиксированного набора ресурсов. За три-пять лет меняются объем данных, профиль нагрузки, архитектура и сама стоимость эксплуатации. Поэтому цена и конфигурация на старте не могут быть единственной точкой отсчета на весь срок договора.

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

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

По той же причине TCO стоит считать не для одной точки, а для нескольких сценариев. Текущего потребления недостаточно: нужно учитывать и его рост, и сокращение. Например, отдельно рассмотреть ситуацию, при которой потребление увеличивается в 1,5–2 раза. Тогда видна разница между ценой входа и ценой роста. В базовом сценарии один вариант может выглядеть выгоднее, но при увеличении нагрузки стоимость масштабирования способна изменить всю экономику решения. На горизонте трех лет она зачастую важнее низкой стартовой цены.

Далее эту логику можно развить через стоимость единицы результата (cost per unit). Это уже не просто расчет затрат на инфраструктуру, а попытка связать их с тем, что бизнес фактически получает. Для начала нужно собрать все облачные расходы за определенный период и соотнести их с количеством выполненных операций. Например, если при расходах в 3–6 млн рублей в месяц было проведено 120 тыс. транзакций, стоимость одной составит 30 рублей.

Такая метрика дает бизнесу более понятную точку сравнения: поставщиков, архитектуры и конфигурации можно оценивать через стоимость одной операции, а не через набор ресурсов, который каждый провайдер считает по-своему. Финансовому блоку сопоставить 30 рублей за транзакцию с маржинальностью гораздо проще, чем 10 vCPU и 30 Гбайт RAM.

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

Закупка облачного сервиса – это не 10 vCPU, 20 Гбайт оперативной памяти и 20 дисков. Бизнесу нужен работающий сервис с заданными параметрами качества на весь срок договора. И если смотреть на закупку именно так, меняется сама точка сравнения предложений.

Одинаковый объем ресурсов еще не означает одинаковый результат. Два провайдера могут предложить по 10 vCPU, но дать разную производительность процессора. То же самое с дисковой подсистемой: одинаковый объем хранения не говорит о том, насколько быстро система будет работать. Поэтому характеристики процессора, базовая частота, гарантированная доля ядра, latency и IOPS имеют значение не сами по себе, а как показатели того, что бизнес получит за свои деньги.

То же происходит с надежностью. SLA, записанное одной цифрой, мало что объясняет, если непонятно, что именно считается доступностью – доступность виртуальной машины, сети, дисковой подсистемы или сервиса целиком. Производительность при этом может вообще остаться за скобками: формально доступная система вполне может работать медленнее, чем требуется бизнесу.

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

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

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