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

Практический опыт показывает: критерии выбора провайдера становятся действительно полезными только после нескольких циклов закупки, миграции и эксплуатации, когда требования проходят проверку реальными проектами. За последние годы три раза был пройден полный цикл выбора облачной инфраструктуры через открытые закупки по Федеральному закону от 18.07.2011 № 223-ФЗ, и на каждом этапе уточнялись требования к площадкам, провайдерам и сервисной модели. Именно такая последовательная работа позволяет понять, какие параметры помогают пережить и миграцию, и неизбежные сбои.

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

В расчет полной стоимости владения включались:

• оборудование и цикл его обновления под растущей нагрузкой;
• инженерная инфраструктура: питание, охлаждение, пожаротушение;
• команда, способная поддерживать контур 24/7 без провалов;
• время реакции на рост нагрузки и появление новых цифровых сервисов.

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

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

1. Площадка (ЦОД)

Формальным ориентиром выступает уровень Tier III, но долгое время подходящих сертифицированных ЦОД в регионе не было. Поэтому требования были разложены на конкретные инженерные признаки:

• автоматическое пожаротушение;
• достаточное количество вводов электропитания;
• резервирование по охлаждению и питанию;
• устойчивость к отказам ключевых инженерных систем.

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

2. Провайдер

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

Критичными оказываются:

• наличие команды с подтвержденными компетенциями эксплуатации;
• соответствие PCI DSS для среды с большим количеством платежных операций;
• выполнение требований по защите каналов связи и обработке персональных данных.

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

3. Услуга и SLA

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

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

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

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

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

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

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

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

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

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