Облачные цифровые платформы: чек-лист для безошибочного выбора

В презентации поставщика всё выглядит линейно: SLA, сертификаты, регион, API, скидка за годовой коммит. В рабочей архитектуре это разные контуры риска.

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

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

Архитектурный фундамент: сначала модель сервиса, потом прайс-лист

Термин «облако» слишком часто используют как маркетинговую наклейку. По определению NIST облачная модель имеет пять признаков:

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

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

NIST выделяет три базовых сервисных модели: SaaS, PaaS и IaaS. Для выбора облачной цифровой платформы это первый архитектурный фильтр.

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

PaaS сокращает операционную нагрузку, но создаёт технологическую зависимость. Управляемая очередь, бессерверные функции, облачная аналитическая БД, proprietary IAM и event bus ускоряют деплой. Затем команда обнаруживает, что перенос приложения требует не миграции контейнеров, а переписывания интеграционного слоя.

IaaS даёт больше контроля. Вместе с ним команда получает патчи ОС, hardening образов, правила сегментации, резервирование, мониторинг, управление секретами и реагирование на уязвимость нулевого дня. Нельзя выбрать IaaS, а затем ожидать эксплуатацию уровня SaaS.

Есть и четыре модели развертывания: публичная, частная, общественная и гибридная. На практике бизнесу чаще всего нужен не «гибрид ради гибрида», а чёткое разделение контуров:

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

Облако не отменяет эксплуатацию. Оно переносит часть операций провайдеру и делает оставшиеся ошибки клиента масштабируемыми.

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

SLA надо считать по цепочке, а не читать в рекламном блоке

SLA отдельного managed-сервиса не является SLA приложения. Это базовая ошибка при оценке надёжности.

Допустим, клиентский запрос проходит через DNS, балансировщик, API-шлюз и сервис авторизации. У каждого компонента заявлена доступность 99,9%. В последовательной цепочке доступность перемножается:

0,999 × 0,999 × 0,999 × 0,999 = примерно 0,996.

Итоговая доступность — около 99,6%. В договоре можно видеть четыре строки с «тремя девятками». Пользователь увидит один отказавший сценарий.

Разница кажется небольшой, пока её не переводят в время простоя. При доступности 99,9% за сутки допустимый простой составляет около 86 секунд. При 99% — около 864 секунд. Один процентный пункт означает десятикратный рост допустимого простоя.

Но и этот расчёт оптимистичен. Он предполагает независимость отказов. В реальной системе компоненты часто связаны общими доменами отказа:

• один регион;
• одна зона доступности;
• общий IAM;
• общий DNS-провайдер;
• единый канал до внешней платёжной системы;
• одна команда, которая выкатывает ошибочный коммит во все инстансы;
• общая база данных без проверенного failover.

Поэтому критерии выбора облачных платформ должны включать не «SLA выше 99,9%», а архитектурный разбор пользовательского пути. Берётся критичная операция: авторизация, заказ, создание документа, запуск производственного задания, выгрузка отчёта. Затем строится реальный список зависимостей. Не маркетинговая схема, а трасса запроса из логов и конфигурации.

Как провести расчёт без самообмана

1. Определите бизнес-операции, а не абстрактный сервис. «CRM доступна» — слабая формулировка. «Менеджер создаёт сделку и прикладывает документ за пять секунд» — проверяемая операция.

2. Зафиксируйте последовательные и параллельные зависимости. Сервис авторизации, база, очередь, файловое хранилище, внешний API, почта, DNS — это не фон. Это часть доступности операции.

3. Выделите единые точки отказа. Одна база в одной зоне, единый tenant администратора, общий секрет в CI/CD, один канал VPN — каждый такой узел снижает ценность резервных компонентов.

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

5. Спросите, что именно компенсирует SLA. Кредит в следующем счёте не восстанавливает потерянные заказы и не исправляет повреждённые данные. SLA — экономическое обязательство, не механизм отказоустойчивости.

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

RTO и RPO: резервная копия не равна восстановлению

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

RTO — Recovery Time Objective. Максимально допустимое время между сбоем и восстановлением сервиса.

RPO — Recovery Point Objective. Максимально допустимая потеря данных по времени от последней точки восстановления.

Это не характеристики, которые можно получить из описания тарифа. Их назначает бизнес для каждого процесса. Платёжная операция, складской контур, архив документов и песочница для ML-экспериментов не должны иметь одинаковые цели восстановления.

Условная классификация может выглядеть так:

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

Проблема в том, что «бэкапы включены» ничего не говорит о достижении RTO и RPO. Нужно выяснить детали:

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

Последний пункт критичен. План аварийного восстановления без теста — документ, а не защита. Если восстановление базы занимает 40 минут, но DNS, секреты, ingress-правила, интеграционные ключи и очередь поднимаются вручную ещё шесть часов, фактический RTO равен не 40 минутам.

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

Полезная практика — проводить game day. Не в production без подготовки, а в изолированном контуре: удалить тестовый кластер, отключить доступ к одному региону, отозвать сервисный ключ, восстановить БД из резервной точки. Время фиксируется. Несоответствия документации фиксируются. Runbook обновляется коммитом, а не обещанием «доделать позже».

Сертификат не закрывает ИБ-вопросы

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

Фраза «у нас ISO» без уточнений технически пуста. Нужны четыре параметра:

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

Редакция ISO/IEC 27017:2015 опубликована давно и подлежит пересмотру. Это не повод автоматически отклонять провайдера. Это повод запросить актуальную область применения документов и не подменять спецификацию безопасности логотипом на лендинге.

Безопасность облачной платформы упирается в несколько практических слоёв.

Идентификация и доступ

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

Проверяйте:

• поддержку SSO через применимый в компании протокол;
• возможность запретить локальные пароли или ограничить их аварийным контуром;
• ролевую модель и granular permissions;
• журналы входов, изменений прав и действий API;
• отдельные service accounts для CI/CD и интеграций;
• процедуру break-glass доступа с обязательным аудитом.

Данные и ключи

Шифрование «at rest» и «in transit» стало стандартной формулировкой. Но смысл в деталях. Где лежат ключи? Может ли клиент использовать собственный ключ? Что произойдёт при его отзыве? Доступна ли ротация? Есть ли журнал обращений к ключевому хранилищу?

Для части сценариев достаточно управляемого шифрования поставщика. Для критичных данных может понадобиться customer-managed key или отдельный контур управления ключами. Это не улучшение ради галочки. Это усложнение: потерянный или неверно отозванный ключ способен сделать данные недоступными даже владельцу.

Сеть и журналы

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

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

Персональные данные и субобработчики

Юрисдикция не решается одной строкой «соответствует требованиям». Если платформа обрабатывает персональные данные в контексте GDPR, отношения с провайдером-обработчиком оформляются договором. В нём должны быть определены обработка данных после прекращения договора и порядок привлечения субобработчиков, для которого требуется предварительное письменное разрешение контролёра.

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

FinOps: облачный счёт растёт по архитектуре

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

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

FinOps не сводится к попытке купить всё дешевле. Его основа — распределение затрат. Для этого до деплоя определяется стратегия тегирования. Минимальный набор меток обычно привязывает ресурс к:

• продукту или сервису;
• команде-владельцу;
• окружению: production, staging, development;
• центру затрат;
• проекту или клиентскому контракту;
• сроку жизни, если ресурс временный.

Без такой схемы невозможно посчитать unit economics. Нельзя отличить нагрузку клиента от внутренних экспериментов. Нельзя закрыть неиспользуемые ресурсы без риска снести чужой production.

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

В выборе облачной платформы нужно отдельно проверить механику лимитов. Есть ли budget alerts? Можно ли установить квоты по проекту? Блокируется ли создание дорогих ресурсов политикой? Видит ли владелец продукта прогноз расходов до закрытия месяца? Финансовый контроль без технических ограничений — это уведомление о перерасходе, а не предотвращение перерасхода.

Vendor lock-in начинается не с API

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

Зависимость от поставщика бывает нескольких типов:

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

2. Приложение. Бизнес-логика реализована через встроенные workflow, low-code-конструкторы, serverless-функции или закрытые расширения. Перенос потребует перепроектирования, а не копирования.

3. Инфраструктура. Terraform-модули, сетевые политики, IAM-роли и образы жёстко привязаны к конкретному облаку. Infrastructure as Code облегчает повторяемость, но не автоматически делает архитектуру переносимой.

4. Контракт. Данные доступны в интерфейсе до дня расторжения, а срок для полной выгрузки, удаление резервных копий, стоимость egress и формат финального архива описаны расплывчато.

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

Требование «никакого lock-in» обычно приводит к другой крайности: команда отказывается от управляемых сервисов, собирает всё на переносимых компонентах и платит операционной сложностью. Правильная цель — не нулевая зависимость. Нужна измеримая цена выхода.

Проверьте сценарий выхода до подписания договора. За сколько дней экспортируются данные? Кто оплачивает передачу? Какие форматы доступны? Что останется после удаления tenant? Как долго провайдер хранит резервные копии? Можно ли перенести домены, сертификаты, журналы и ключевые конфигурации? Ответы должны быть в документах, демонстрации или договоре. Устные заверения не участвуют в восстановлении системы.

Итоговый порядок выбора платформы

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

1. Спецификация нагрузки. Перечень процессов, данных, интеграций, требуемых регионов и классов критичности. Без неё SaaS, PaaS и IaaS сравниваются на уровне терминов.

2. Матрица ответственности. По каждому слою определено, кто владеет настройкой, патчингом, доступом, журналами, резервированием и реагированием.

3. Расчёт доступности критичных операций. Не SLA одного компонента, а зависимая цепочка с едиными точками отказа и исключениями договора.

4. Утверждённые RTO и RPO. Для каждого критичного процесса есть бизнес-владелец, сценарий восстановления и результат последнего теста.

5. Проверка IAM, журналов и ключей. SSO, MFA, роли, экспорт аудита, управление секретами и модель шифрования проверены на конкретном сервисе, а не в общем описании платформы.

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

7. Модель затрат. Теги, владельцы, бюджеты, квоты, прогноз и правила работы с обязательствами заданы до production-деплоя.

8. Сценарий выхода. Проведён тестовый экспорт, понятны форматы, сроки, стоимость передачи данных и объём ручной работы при миграции.

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