Облачные платформы для бизнеса: как выбрать надежный сервис

Это разные уровни ответственности, рисков и затрат.

Ошибка обычно начинается с фразы «перенесём всё в облако». После неё в новый контур переезжают виртуальные серверы с прежними лимитами, неотключёнными тестовыми средами, локальными учётными записями и монолитом, который масштабируется только целиком. Через квартал счёт растёт, SLA не спасает, а команда обнаруживает, что резервная копия находится в той же зоне отказа, что и рабочая база.

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

Сначала определить слой: IaaS, PaaS или SaaS

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

IaaS, PaaS и SaaS отличаются не интерфейсом, а тем, кто отвечает за каждый слой стека. Чем ниже уровень сервиса, тем больше контроля у компании и тем больше операционной работы у её IT-команды.

IaaS нужен, когда требуется контроль над операционной системой, сетевой топологией, агентами мониторинга или нестандартным ПО. Но IaaS не отменяет администрирование. Виртуальная машина в облаке остаётся виртуальной машиной: её нужно патчить, ограничивать доступ, резервировать и мониторить. Облако не исправляет слабую конфигурацию SSH, старый агент CI/CD или открытую базу данных.

PaaS снимает часть рутины. Управляемая СУБД, Kubernetes-сервис, очередь сообщений или платформа функций сокращают число компонентов, которые команда должна обслуживать самостоятельно. Но здесь появляется другой класс зависимости: архитектура начинает опираться на API, лимиты и модель развертывания конкретного провайдера. Выход из такой платформы может быть дороже, чем вход.

SaaS закрывает прикладную задачу. Компании не нужен собственный кластер для CRM, если задача — вести сделки, воронки и коммуникации с клиентами. Однако SaaS нельзя оценивать как «облако без инфраструктуры». Здесь критичны права доступа, федерация учётных записей, журналирование действий, экспорт данных, политика хранения и возможность отключить сотрудника без ручной чистки десятка рабочих пространств.

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

Для корпоративного софта есть полезный тест. Если продукт можно заменить без переписывания бизнес-процесса, чаще подходит SaaS. Если создаётся собственная цифровая функция компании — расчётный модуль, личный кабинет, отраслевой сервис, интеграционный слой, — потребуется PaaS или IaaS. Не наоборот.

SLA и Tier: цифры, которые маркетинг любит округлять

«Доступность 99,9%» звучит убедительно до перевода в минуты. За месяц такой SLA допускает около 43 минут простоя. За год — примерно 8,76 часа. Для внутренней базы знаний это может быть приемлемо. Для платёжного контура, контактного центра или системы обработки заказов — уже нет.

SLA 99,99% уменьшает допустимый простой примерно до 4,4 минуты в месяц и 52,6 минуты в год. Разница между третьей и четвёртой девяткой — не 0,09%. Это почти порядок по допустимому времени недоступности.

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

При анализе SLA нужно разложить документ на четыре вопроса:

1. Что именно измеряется. Доступность виртуальной машины, API, панели управления, базы данных и прикладного сервиса — разные метрики. Рабочая VM не означает работающую бизнес-функцию.

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

3. Какой компонент является точкой отказа. Один балансировщик, одна зона, один VPN-шлюз или единая корпоративная учётная запись способны обнулить архитектурные усилия.

4. Что происходит при нарушении. Кредит в счёт будущего потребления — не план восстановления. Нужны собственные RTO и RPO: допустимое время восстановления и допустимая потеря данных.

Отдельно стоит смотреть на уровень дата-центра. Tier I и Tier II для критичных корпоративных систем — слабая база. Tier III допускает плановые работы без остановки инфраструктуры. Tier IV предполагает максимальную отказоустойчивость с резервированием компонентов. Но классификация площадки не равна устойчивости вашего приложения.

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

Что проверить за пределами Tier

У зрелого облачного контура есть минимум три независимых слоя устойчивости:

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

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

ФЗ-152: облако не переносит ответственность на провайдера

Если облачные сервисы для бизнеса обрабатывают персональные данные, разговор о безопасности должен начинаться с модели данных. Не с логотипов ISO. Не с общего обещания «данные защищены». Нужно определить, какие категории данных попадают в систему, кто является оператором, где размещается ИСПДн и какие меры требуются для конкретного уровня защищённости.

В российской практике выделяют четыре уровня защищённости персональных данных: УЗ-1, УЗ-2, УЗ-3 и УЗ-4. Требуемый уровень зависит от характеристик системы, категорий данных, числа субъектов и актуальных угроз. В том числе используется порог в 100 000 субъектов персональных данных. Но сводить классификацию к одной цифре нельзя: итоговая модель определяется не только объёмом базы.

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

В договоре и технической документации нужны ответы на конкретные вопросы:

• в каких дата-центрах и регионах хранятся рабочие данные, резервные копии и журналы;
• есть ли аттестат соответствия под требуемый уровень защищённости ИСПДн, а не общая декларация безопасности;
• как разделены клиентские контуры при мультиарендной модели;
• кто и при каких условиях получает административный доступ;
• доступны ли централизованные логи входов, изменений прав, операций с данными и действий API;
• как удаляются данные после расторжения договора и какой срок живут резервные копии;
• как организовано уведомление об инцидентах и предоставление технических артефактов для расследования.

Сертификация ISO/IEC 27001 подтверждает наличие системы менеджмента информационной безопасности. ISO/IEC 27017 описывает практики безопасности облачных сервисов. Это полезные сигналы зрелости процессов. Но сертификат не отвечает на вопрос, соответствует ли конкретная конфигурация клиента требуемому уровню УЗ.

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

«Соответствие стандарту» — свойство процесса. «Защищённая система» — свойство конкретной конфигурации и дисциплины её эксплуатации.

Типовая уязвимость: облако настроено как локальная сеть

Самый частый провал — переносить on-premise-привычки в публичный контур. В локальной сети сервис мог годами жить за периметром. После миграции он получает публичный IP, широкий security group, сервисный аккаунт без срока действия и объектное хранилище с ошибочной политикой доступа.

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

• доступ администраторов через MFA и раздельные роли, а не общий root-аккаунт;
• минимальные сетевые правила, без диапазонов 0.0.0.0/0 там, где нужен доступ из конкретной подсети;
• секреты в специализированном хранилище, а не в переменных CI, конфигурационных файлах и коммитах;
• неизменяемые или защищённые журналы аудита с отдельным сроком хранения;
• резервные копии, проверенные восстановлением в изолированном контуре;
• регулярная ревизия прав сервисных учётных записей и интеграционных токенов.

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

TCO: счёт за облако складывается не из цены виртуальной машины

Публичное облако продаётся как OPEX: платите за фактическое потребление, масштабируетесь по запросу, не покупаете серверы заранее. Это удобно. Но «по факту» не значит «дёшево».

TCO облачного решения состоит как минимум из шести частей:

1. Вычисления и хранение. Виртуальные машины, контейнерные ноды, диски, снапшоты, объектное хранилище, IOPS.

2. Сеть. Исходящий трафик, межзонные и межрегиональные передачи, VPN, балансировщики, публичные адреса.

3. Управляемые сервисы. Базы данных, очереди, мониторинг, журналы, резервное копирование, KMS, CDN.

4. Лицензии. ОС, СУБД, средства защиты, коммерческие агенты, корпоративные SaaS-подписки.

5. Эксплуатация. SRE, DevOps, ИБ, поддержка, аудит, реагирование на инциденты.

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

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

Почему lift-and-shift почти всегда раздувает бюджет

Lift-and-shift — перенос приложения «как есть». Иногда это оправдано: нужно быстро закрыть риск устаревшего железа, освободить площадку или пройти короткое окно миграции. Но как постоянная стратегия он часто создаёт дорогой гибрид старых проблем и нового биллинга.

Типовая картина:

• VM перенесена с фиксированным размером, хотя пиковая загрузка бывает несколько часов в месяц;
• тестовые среды не выключаются ночью и в выходные;
• диски, снапшоты и старые образы остаются после удаления серверов;
• база данных развёрнута на чрезмерной конфигурации, поскольку её так же держали на локальном железе;
• трафик между сервисами ходит через платные сетевые границы;
• мониторинг собирает всё подряд, включая бесполезные debug-логи.

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

Резервирование обычно снижает стоимость предсказуемой нагрузки. Pay-as-you-go оставляет гибкость для нерегулярных пиков и новых сервисов. Смешивать эти модели нормально. Ненормально резервировать неизвестный объём или держать постоянные ресурсы для нагрузки, которая давно стала эпизодической.

Публичное, частное или гибридное облако: выбор по границе риска

Модель развёртывания определяет не только стоимость. Она определяет, где проходят границы контроля, изоляции и масштабирования.

Публичное облако подходит для переменной нагрузки, быстрого запуска новых продуктов, сред разработки, аналитики, веб-сервисов и SaaS-систем. Его сильная сторона — скорость выделения ресурсов и модель OPEX. Слабая — необходимость дисциплины в конфигурации и постоянного контроля расходов.

Частное облако или выделенная инфраструктура оправданы, когда требуются высокий уровень изоляции, специфические аппаратные зависимости, предсказуемая постоянная нагрузка или ограничения внутренней политики. Это не автоматический выбор для «критичных данных». Иногда управляемый сервис в публичном облаке даёт более зрелый мониторинг и резервирование, чем самодельный кластер в серверной компании.

Гибридная модель разумна, если разделение систем основано на реальных требованиях. Например, чувствительная часть ИСПДн и старые интеграции остаются в выделенном контуре, а фронтенд, аналитика, резервные среды или пиковые вычисления используют публичное облако. Плохая гибридная модель строится иначе: «половину оставим как было, вторую половину вынесем, потом разберёмся с сетью». В ней появляется сложная маршрутизация, дублирование IAM, задержки, дорогой трафик и неясная зона ответственности.

Не начинать миграцию с самого критичного контура

Рациональный порядок выглядит так:

1. Инвентаризировать приложения, данные, интеграции, учётные записи и зависимости от локальной инфраструктуры.

2. Разметить нагрузки по критичности, требованиям к RTO/RPO, данным и допустимому простою.

3. Выбрать пилот с измеримым эффектом: среда разработки, резервное копирование, аналитическая витрина, некритичный веб-сервис.

4. Собрать базовую платформу: сеть, IAM, журналирование, управление секретами, резервирование, бюджеты и оповещения.

5. Провести миграцию пилота, нагрузочный тест и тест восстановления.

6. Зафиксировать фактический TCO, число инцидентов, время деплоя, время восстановления и операционную нагрузку команды.

7. Только после этого масштабировать паттерн на более критичные системы.

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

Выбор облачной платформы — это выбор операционной модели

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

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

Финальная спецификация перед запуском должна быть короткой и проверяемой:

• модель сервиса соответствует задаче: SaaS не используют как суррогат собственной разработки, а IaaS — как дорогой способ запустить типовую CRM;
• для каждой системы определены RTO, RPO и допустимый простой, а SLA провайдера сопоставлен с этими значениями;
• критичные компоненты не зависят от одной зоны, одной VM, одного администратора или одной резервной копии;
• обработка персональных данных привязана к требуемому уровню защищённости ИСПДн, договору и технической конфигурации;
• права доступа разделены, MFA включена, сервисные учётные записи и секреты контролируются;
• TCO включает сеть, хранение, логи, лицензии, поддержку, миграцию и возможный выход из платформы;
• восстановление из резервной копии проверено тестом, а не отмечено в презентации;
• у команды есть владелец платформы, бюджетные лимиты и процедура реакции на инцидент.

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