TEMPLE Cloud Temple SAS продаёт размещённые мощности, которые по-прежнему зависят от стоек, транзита и окон ремонта

Кратко

• TEMPLE Cloud Temple SAS — это заметный французский sovereign-cloud бизнес: на публичных страницах Cloud Temple описаны IaaS с квалификацией SecNumCloud, VMware IaaS, OpenSource IaaS, объектное хранилище, bare metal, VPC, частная магистраль, размещение и поддержка для регулируемых отраслей.
• Согласно официальным страницам о соответствии, периметр IaaS Secure Temple включает VMware IaaS, OpenSource IaaS, S3 Object Storage, шифрование HSM-KMS и Bare Metal; срок действия SecNumCloud v3.2 указан до 30 мая 2028 года. На той же странице PaaS OpenShift перечислен отдельно.
• Публичная маршрутизация реальна и актуальна: RIPEstat показал анонс AS33930 на 12 июля 2026 года с шестью префиксами IPv4 и двумя префиксами IPv6, полностью валидными результатами происхождения RPKI в проверенном представлении и широкой видимостью в RIS.
• Риск не в том, что у провайдера нет публичных операционных свидетельств; риск в том, что сертификация, видимость AS и ярлыки продуктов по-прежнему не говорят клиенту, какая именно стойка, зона доступности, путь восстановления, уровень поддержки или процесс вывода защищают конкретную рабочую нагрузку.
• Покупателям стоит рассматривать публичные свидетельства Cloud Temple как прочную отправную точку для комплексной проверки, а затем проверять размещение рабочих нагрузок, эскалацию поддержки, доступность оборудования, тесты восстановления, ответственность за каналы клиента, влияние на выставление счетов и ограничения переносимости данных до перевода критических систем.

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

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

Собственная страница компании«Кто мы?»позиционирует Cloud Temple вокруг чувствительных отраслей — промышленности, финансов, здравоохранения и государственного сектора — как рынков, где её обещание должно иметь значение. Настранице локацийперечислены офисы в Париже / Дефанс, Лионе, Туре, Кане и Нанте, при этом адрес Париж / Дефанс — Le Belvedere - SPACES, 1-7 Cours Valmy, 92800 Puteaux. Это полезное свидетельство идентичности, но карта офисов — не карта инфраструктуры. Покупатель не должен путать адрес офиса с площадкой, где работают виртуальная машина, bare-metal-сервер, S3-бакет, VPC-шлюз или физическая стойка.

Более весомое публичное свидетельство — это след в области соответствия и продуктов. Настранице процедур соответствияCloud Temple говорится, что компания имеет сертификацию ISO 27001 для инфраструктуры с 2018 года и для управляемых сервисов с 2022 года, сертификацию HDS для деятельности с данными здоровья, квалификацию SecNumCloud v3.2, отчётность ISAE 3402 и другие европейские записи о соответствии. На той же странице даётся самое конкретное заявление о периметре: «IaaS Secure Temple» перечислен в рамках SecNumCloud v3.2 со сроком действия до 30 мая 2028 года, а в сноске сказано, что этот периметр включает VMware IaaS, OpenSource IaaS, S3 Object Storage, шифрование HSM-KMS и Bare Metal. Это не делает все продукты идентичными, но помещает основные инфраструктурные продукты в публичный периметр квалификации.

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

Линейка продуктов показывает, почему эти детали важны. Вычислительные предложения Cloud Temple охватывают несколько моделей потребления. На публичном сайте описаныOpenSource IaaSдля виртуализированной инфраструктуры на суверенной платформе,VMware IaaSдля сред VMware в квалифицированном облаке,Bare Metalдля выделенных физических серверов и VM Instances в предварительной версии — более общие виртуальные машины в облачном стиле. Публичная документация компании по OpenSource IaaS описывает вычислительные ресурсы Cisco UCS, блочное хранилище IBM Spectrum Virtualize и IBM FlashSystem, объектное хранилище Dell ECS, сетевое оборудование Juniper, выделенные вычислительные blade-серверы и тома хранения, помесячное потребление, концепции регионов и зон доступности, резервное копирование, варианты репликации и работу через API или Terraform. Это не легковесный каталог хостинга. Это физический и операционный стек.

У стека есть конкретное следствие: установленная мощность и доступная мощность — не одно и то же. Страница может показывать классы blade-серверов, классы хранилищ и показатели связности, но клиенту всё равно нужно спрашивать, доступен ли нужный класс в желаемом регионе, требует ли добавление ещё одного хоста наличия оборудования на складе, есть ли срок поставки у GPU-серверов, есть ли во второй зоне доступности сопоставимая производительность хранилища и допускает ли лицензия клиента переключение без простоя (live failover).

В концепциях OpenSource IaaS Cloud Temple перечислены классы blade-серверов от ECO до PERFORMANCE 4 с объёмом памяти, числом ядер, связностью 10 Гбит/с или 25 Гбит/с и, для старшего класса, GPU NVIDIA L40S по состоянию на 1 мая 2024 года. Это полезная деталь. Она также говорит покупателю, что мощность не абстрактна: её обеспечивают конкретные семейства оборудования с конечным запасом.

Bare metal заостряет мысль.Документация Bare Metalописывает выделенные физические серверы, подключённые к распределённому блочному хранилищу, blade-серверы Cisco UCS, хранилище IBM Spectrum Virtualize, размещение в зонах доступности, консольный доступ в стиле KVM, монтирование ISO, операции с питанием, теги VLAN и два сетевых интерфейса, скорость которых зависит от класса сервера. Продукт привлекателен именно потому, что даёт клиенту больше контроля над средой эксплуатации. Но этот контроль возвращает часть риска клиенту. Если клиент устанавливает собственный гипервизор или операционную систему, Cloud Temple может предоставить сервер, хранилище и доступ к платформе, но решения, превращающие оборудование в отказоустойчивое приложение, остаются за клиентом.

На стороне VMware похожее напряжение. Материалы Cloud Temple по VMware IaaS описывают выделенные ресурсы серверов, хранилища и сети, совместимость с vSphere, L2-VLAN, распространение между зонами доступности, задержку внутри зоны доступности менее 3 мс и между зонами менее 5 мс в документированном представлении, а также высокую доступность, которая работает только при требуемой конфигурации кластера. В публичной документации отмечается: если в зоне доступности только один гипервизор, автоматический перезапуск на другом гипервизоре невозможен. Именно такие предложения превращают облачное обещание в инженерную реальность.

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

Хранилище тоже требует точности. На публичнойстранице объектного хранилищаCloud Temple говорится, что сервис основан на Dell Elastic Cloud Storage, обладает высокой совместимостью с S3, квалифицирован по SecNumCloud, сертифицирован по HDS и ISO 27001, автоматически реплицируется в три зоны доступности, использует схему избыточности EC 12+4, поддерживает TLS 1.2/1.3 и серверное шифрование, показывает доступность 99,99 % и долговечность 99,999999999 %, а также рекламирует отсутствие платы за исходящий трафик. Это серьёзные заявления для покупателей резервных копий, архивов и приложений. Их всё равно нужно сопоставить с собственной обязанностью клиента настроить жизненный цикл, неизменяемость, ключи и политику восстановления. Объектное хранилище в трёх зонах помогает с долговечностью платформы; само по себе оно не доказывает, что клиент сможет восстановить нужную версию объекта после атаки вымогателей, ошибочного удаления, плохой конструкции хранения или компрометации ключа доступа.

Разделение ответственности не скрыто.Страница общей ответственностиCloud Temple отправляет читателей к матрицам RACI для IaaS, VM Instances, объектного хранилища, сети и других сервисов. Вматрице ответственности IaaSсказано, что Cloud Temple несёт ответственность и подотчётность за реализацию физических дата-центров, вычислительной инфраструктуры, инфраструктуры хранения, магистральной связности, лицензий на основное программное обеспечение платформы, базовую конфигурацию тенанта и первоначальную настройку резервного копирования. Там также сказано, что клиент несёт ответственность и подотчётность за определение общей архитектуры, числа тенантов, числа зон доступности, стратегии непрерывности и восстановления, расчёт размеров вычислений, хранилища, сети и резервных копий, создание и поддержку виртуальных машин, привязку каждой ВМ к согласованным планам резервного копирования и восстановления, а также за периодические тесты резервного копирования и восстановления.

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

Поэтому вопрос о риске в статье — не «Является ли TEMPLE Cloud Temple SAS настоящей облачной компанией?». Ответ — да. Вопрос в том: «Какая часть этой клиентской системы находится внутри подотчётного периметра Cloud Temple, а какая остаётся собственным проектом клиента?»

То же разделение проявляется в сети.Документация частной магистралиCloud Temple говорит, что продукт предоставляет частные сети L2 VPLS между зонами доступности, компоненты приватного доступа в интернет, IP-адресацию, встроенную защиту от DDoS, порты для внешней связности, каналы 1G/10G и частные линии на двух разнообразных оптических путях для продуктов выделенных каналов.Страница концепций интернетаговорит, что Cloud Temple управляет собственной AS, предлагает два транзитных пути и две точки обмена в Париже, поддерживает BGP4, предоставляет публичные IPv4 поштучно и префиксы IPv6, резервирует интернет-полосу с шагом 100 Мбит/с и тарифицирует по 95-му перцентилю, а не за объём трафика. Это материальные факты сетевого дизайна, а не декоративные заявления.

Но опять же, граница важна.Матрица ответственности сетиговорит, что клиент несёт ответственность и подотчётность за подписку на связность оператора для доступа к физическому дата-центру Cloud Temple и за управление инцидентами, проблемами и ёмкостью на собственных каналах оператора клиента. Cloud Temple берёт на себя ответственность за магистраль, точки сбора и точки межсоединения дата-центра, а для физического размещения ответственность начинается с оборудования top-of-rack. Именно на этой границе многие инциденты становятся болезненными. Рабочая нагрузка может быть здоровой внутри Cloud Temple, но площадка клиента может выйти из строя из-за корпоративного канала MPLS, абонентского канала оператора, неудачного изменения IPsec, локального межсетевого экрана, ошибки DNS или ограничения ёмкости на стороне клиента.

Публичные данные о маршрутизации подтверждают, что компания управляет реальной сетью. RIPE RDAP дляAS33930называет CLOUD-TEMPLE и указывает Cloud Temple SAS как регистранта, с адресом организации Le Belvedere, 1 Cours Valmy, 92800 Puteaux.Обзор ASв RIPEstat определил держателя как CLOUD-TEMPLE Cloud Temple SAS и показал, что AS анонсирована на момент запроса 12 июля 2026 года.Представление анонсированных префиксовв RIPEstat показало восемь активных анонсов в окне, завершающемся 12 июля 2026 года: 91.223.207.0/24, 45.15.212.0/22, 185.56.204.0/22, 194.6.240.0/24, 93.187.40.0/21, 80.75.152.0/21, 2a02:668::/36 и 2a02:668:9000::/36.

Эта запись о маршрутизации сильнее, чем след, оставленный только маркетингом.Представление статуса маршрутизациив RIPEstat показало шесть префиксов IPv4, два префикса IPv6, 6656 анонсированных адресов IPv4, 8192 IPv6 /48, 54 наблюдаемых соседа и почти полную видимость в RIS в проверенном снимке. Представление согласованности маршрутизации показало, что анонсированные префиксы AS33930 присутствуют и в источниках BGP, и в RIPE route-policy, без списка несогласованных префиксов в проверенном выводе. Проверка RPKI вернула «valid» для восьми проверенных пар «префикс — происхождение» AS33930. Эти факты не говорят клиенту, насколько избыточна конкретная услуга, но показывают, что сетевой уровень виден, поддерживается и не является просто остатком прошлого.

Свидетельства о транзите и пиринге также полезны, хотя читать их нужно осторожно. В замечаниях RIPE RDAP для AS33930 упоминаются запросы на пиринг, детали обменов France-IX и Equinix Paris.Страница сети Cloud Templeв PeeringDB перечисляет сеть как Cloud Temple, со старым именем Intrinsec, открытой общей политикой пиринга и датой обновления в апреле 2025 года. Публичное представление обменов в PeeringDB показывает записи France-IX Paris и Equinix Paris IX на 10 Гбит/с, а представление объектов перечисляет Telehouse Paris 2, Telehouse Paris 3, Equinix PA6, Digital Realty Paris PAR7 и DATA4 Paris Marcoussis - PAR1 как объекты, связанные с профилем сети. Это подтверждает межсоединение на парижском рынке, но это всё же публичный профиль пиринга, а не обязательная карта размещения рабочих нагрузок клиента.

Публичная страница статуса добавляет ещё один ракурс.Страница статусаCloud Temple показывает компоненты в рамках FR1, включая метки зон доступности PA6, PAR7, TH3, PAR7S, TH3S и AZ07, а также категории: OpenIaaS, Object Storage, PaaS OpenShift, Bare Metal, VPC, edge-сервисы и публичные интерфейсы. Страница статуса ценна тем, что даёт клиентам публичное место для наблюдения за инцидентами и обслуживанием. Сама по себе она не отвечает на более глубокий вопрос: какие из этих зон доступности, сервисов и компонентов реально использует этот клиент, и переживёт ли его собственное приложение, если один из них деградирует?

Пути отказа становятся яснее, если читать линейку продуктов как единую систему. Отказ стойки или объекта по-разному влияет на вычисления, хранилище, сеть и размещение в зависимости от размещения. Отказ аплинка или маршрута по-разному влияет на интернет-сервисы, префиксы клиента, VPN-доступ и видимость поддержки в зависимости от дизайна BGP. Отсутствие оборудования на складе важно для bare metal, GPU-серверов, расширения хранилища, межсетевых экранов и замены хостов. Сбой поддержки по-разному проявляется на уровнях Standard, Premium и Company. Ошибка биллинга или заказа может задержать выделение ресурсов или расширение.

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

Условия поддержки — часть этой инфраструктуры.Страница уровней поддержкиCloud Temple перечисляет поддержку Standard, Premium и Company с ежемесячными ставками 5, 7 и 10 процентов от суммы выставленного счёта, минимальными ежемесячными уровнями выставления счетов, разным доступом к техническому менеджеру аккаунта, целевыми показателями ответа P1 в 2 часа, 30 минут и 15 минут, а также мониторингом и вмешательством 24/7 при облачных инцидентах. Там также сказано, что инженеры доступны 24/7 для облачных инцидентов, а запросы поддержки обрабатываются в рабочие часы по каналам, с поддержкой во Франции на французском и английском языках. Разница важна. Производственный инцидент, за который отвечает Cloud Temple, — это не то же самое, что общий запрос о помощи, изменение конфигурации на стороне клиента, вопрос планирования миграции или запрос на некаталоговую задачу.

Страница поддержки также отсылает к матрице ответственности для инцидентов с влиянием на производство, за которые отвечает Cloud Temple. На практике эта оговорка — не мелкий шрифт. Если виртуальная машина клиента работает на уровне гипервизора, но приложение лежит, потому что сломана гостевая ОС, путь поддержки меняется. Если VPC клиента здоров, но наземный канал оператора лежит, путь поддержки меняется. Если резервная копия существует, но клиент никогда не запускал тесты восстановления, путь поддержки меняется.

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

Опубликованные SLA делают тот же вывод цифрами.SLA для VM Instancesопределяет ежемесячное обязательство по доступности 99,95 % для каждой активной оплачиваемой VM Instance, что эквивалентно 21,9 минуты допустимой недоступности в месяц. Но оно измеряет недоступность на уровне нижележащей инфраструктуры Cloud Temple, исключает гостевую ОС, клиентское ПО, конфигурацию сети клиента, сбои приложений, плановое обслуживание, отсутствующие компоненты управления, злоупотребления и форс-мажор, а для получения сервис-кредитов требуется заявка в поддержку в течение 30 календарных дней. Это обычная структура облака. Это также предупреждение: SLA — это не гарантия доступности приложения.

SLA для VPCстоль же конкретен. Он даёт 99,99 % ежемесячной доступности для плоскости данных VPC и 99,9 % для плоскости управления, причём пять минут считаются порогом недоступности. Он покрывает управляемые Cloud Temple компоненты VPC, такие как маршрутизатор, частные сети, внешний шлюз, NAT, DNAT и плавающие IP. Он исключает правила фильтрации клиента, неверную адресацию, сбои подключённых вычислений, внешнюю интернет-связность за пределами границы разграничения Cloud Temple, плановое обслуживание, злоупотребления и форс-мажор. Эти исключения — не дефекты документа; так проведена реальная операционная граница.

Объектное хранилище имеет другой профиль вывода и восстановления. На публичной странице продукта сказано, что клиенты могут получать объекты через S3-совместимый доступ и что Cloud Temple не взимает плату за исходящий трафик.Матрица ответственности S3говорит, что Cloud Temple отвечает за поддержку и безопасность платформы S3, доступ к сервису, журналы, мониторинг, инциденты, проблемы, ёмкость и изменения сервиса. Клиент отвечает за создание объектов, создание ключей доступа, управление жизненным циклом объектов, правами на объекты, логической безопасностью, резервными копиями данных, периодическими тестами восстановления, планами непрерывности приложений и выполнением обратимости. Это значит, что отсутствие платы за исходящий трафик полезно, но переносимость по-прежнему требует планирования, учётных данных, полосы пропускания, логики хранения и проверенного целевого места.

Миграция — это место, где размещённые мощности часто показывают свою истинную цену. Продукты Cloud Temple явно совместимы с привычными экосистемами: средами VMware, доступом S3, OpenSource IaaS в стиле OpenStack, работой через API, подготовкой через Terraform и BGP для префиксов клиента. Это сигналы интероперабельности. Они снижают зависимость от поставщика по сравнению с закрытым проприетарным стеком. Однако вывод из платформы — всё равно проект: образы серверов, тома хранилища, объектные бакеты, правила межсетевого экрана, права доступа, маршрутизация, ключи, DNS, мониторинг, соглашения о поддержке и окна отката должны сойтись.

Матрица ответственности IaaS говорит, что клиент отвечает за планирование обратимости, выбор целевой инфраструктуры, выполнение переходных операций и управление эффектами на качество сервиса во время переноса, а Cloud Temple занимается демонтажем конфигураций и безопасным стиранием после окончания договора.

Выставление счетов и заказы — не побочные вопросы. Страница поддержки говорит, что минимальный расчёт поддержки начинается, когда ресурсы выделены. Сетевая документация говорит, что публичные IPv4-адреса предоставляются в пределах наличия, интернет-полоса резервируется с шагом 100 Мбит/с, частные каналы могут включать обязательства на 36 месяцев, а выделенное размещение или услуги hands-and-eyes могут иметь сроки 12 или 36 месяцев в зависимости от позиции. Объектное хранилище тарифицируется по потреблению, а bare metal и размещение привязаны к физическим единицам. Эта смесь влияет на отказоустойчивость.

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

Каналы закупок добавляют ещё один операционный слой. Страницы IaaS и Bare Metal Cloud Temple указывают покупателям из госсектора и здравоохранения на публичные закупочные маршруты, такие как UGAP и CAIH. Это важно, потому что может упростить внедрение для организаций, которые не могут покупать инфраструктуру через разовые переговоры. Это также означает, что планирование отказоустойчивости может определяться рамочными условиями, заранее одобренными позициями каталога, формами заказов, минимальными обязательствами и сроками публичных закупок.

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

Это одна из причин, почему экономику размещённых мощностей не стоит сводить к цене за единицу в месяц. Клиент, переходящий из собственной серверной к TEMPLE Cloud Temple SAS, переносит капитальные затраты, кадровую нагрузку и риск объекта провайдеру со специализированной инфраструктурой. Это может быть рационально, особенно для регулируемых клиентов, которые не могут легко построить контроль уровня SecNumCloud самостоятельно.

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

Заявление об отсутствии платы за исходящий трафик в объектном хранилище — хороший пример выгодного для покупателя условия, операционный смысл которого зависит от контекста. Если клиент может получить все объекты через S3-совместимый доступ без платы за исходящий трафик, коммерческий барьер для выхода ниже, чем во многих конфигурациях гиперскейл-провайдеров. Но перенос многих терабайт или петабайт всё равно требует времени, полосы, контроля ключей доступа, ёмкости целевого места, дисциплины именования объектов и осознания политики хранения. Если включён Object Lock, клиент также обязан соблюдать собственные решения о неизменяемости.

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

Публичную страницу статуса стоит использовать так же практично. Она ценна тем, что называет компоненты, за которыми клиенты могут наблюдать во время инцидента, и сигнализирует о том, что Cloud Temple сделал часть своего операционного состояния видимой. Однако компонент статуса полезен только тогда, когда клиент знает, как он соотносится с его сервисом. Если клиент видит позицию для FR1 Object Storage или конкретной метки зоны доступности, может ли он сказать, затронуты ли его бакет, тенант, VPC-шлюз или bare-metal-сервер? Есть ли на собственном мосту инцидентов клиента человек, понимающий эти метки?

Обещал ли уровень поддержки канал связи для нужной серьёзности? Видимость помогает только тогда, когда она связана с регламентами клиента и записями о принадлежности.

Есть также тихая зависимость в собственном публичном контуре провайдера. Точечный DNS-запрос показал cloud-temple.com в адресном пространстве Cloud Temple, DNS-серверы Gandi, защиту почты Microsoft, консоль на другом адресе Cloud Temple и хост страницы статуса через Atlassian Statuspage и CloudFront. Это обычные решения, и они не ослабляют основное свидетельство о платформе. Однако они показывают, что коммуникации с клиентом могут зависеть от слоёв за пределами AS33930. При серьёзном инциденте сайт провайдера, консоль, страница статуса, почтовый путь, телефонная поддержка и тенант клиента могут выйти из строя или выжить в разных комбинациях.

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

Глобальная категория, присвоенная этой статье, тоже требует нюанса. Облачные сервисы можно покупать и использовать по всему миру, и у AS33930 есть глобальная видимость маршрутизации. Но публичная история суверенитета Cloud Temple прежде всего французская и европейская: язык продуктов FR1, французские офисы, французские команды поддержки, квалификация ANSSI, значимость HDS, парижский пиринг и сигналы французского рынка объектов. Для клиента за пределами Франции такая зависимость может быть привлекательной, если цель — французская или европейская локализация данных.

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

Суверенитет также может создавать ложное ощущение полноты, если клиент воспринимает его как замену архитектуре. Квалифицированный французский провайдер может снизить воздействие определённых правовых, операционных и безопасностных проблем, но не может решить за клиента вопросы классификации данных, переключения маршрутов при сбое, кластеризации приложений, прав тенанта, ротации ключей, частоты восстановления или приоритетов вывода. Публичная документация Cloud Temple необычно ясна в том, что многие из этих пунктов остаются за клиентом. Эта ясность — хорошая новость.

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

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

Затем он должен попросить TEMPLE Cloud Temple SAS подтвердить, какие позиции управляются провайдером, какие — клиентом, какие входят в периметр SecNumCloud, какие относятся к HDS, какие находятся вне квалифицированных зон, какие в предварительной версии и какие требуют отдельной профессиональной помощи. Это упражнение будничное, но именно на нём отказоустойчивость облака становится видимой.

Физическое размещение — самое конкретное напоминание о том, что у облака есть границы.Документация по размещениюCloud Temple описывает физический хостинг по стоечным единицам в общих стойках или по выделенной стойке 42U, две электрические цепи для общих стоек, лимиты мощности на U, серверные блоки 2U с питанием C19, выделенные стойки с мощностью 3 кВт по двум электрическим цепям 16A, дополнительные приращения 2 кВт, максимальную массу оборудования 1000 кг, мониторинг PDU, медные или оптические сетевые порты, связность в meet-me room и услуги hands-and-eyes. Там также сказано, что выделенные стойки находятся в общем пространстве размещения за пределами зоны SecNumCloud. Последнее различие важно: «размещение Cloud Temple» и «квалифицированный IaaS Secure Temple» — не взаимозаменяемые выражения.

Для некоторых клиентов размещение — это мост. Устаревшее устройство, система, близкая к мейнфрейму, проприетарный блок хранения, HSM, межсетевой экран или промежуточный сервер миграции могут нуждаться в размещении рядом с облачными ресурсами, пока регулируемая нагрузка переезжает. Это может быть разумно. Это также может создать архитектуру с двумя периметрами: часть — квалифицированное облако, часть — неквалифицированный физический хостинг, часть — оборудование клиента, часть — сеть под управлением Cloud Temple, часть — канал оператора.

Если клиент предполагает, что у всего одинаковая квалификация, поддержка и механика восстановления, дизайн может вводить в заблуждение. Документация по размещению полезна именно тем, что заставляет покупателя говорить о стоечных единицах, ваттах, портах, оптических путях, времени реакции hands-and-eyes и эскалации поддержки.

Аргумент о суверенитете данных поэтому сильнее всего, когда он остаётся конкретным. Страницы Cloud Temple делают правдоподобное заявление о суверенитете вокруг французской эксплуатации, квалификации SecNumCloud, HDS, ISO 27001, команд поддержки во Франции и продуктов, спроектированных для регулируемых отраслей. Страница объектного хранилища подчёркивает французские и европейские регуляторные потребности. Страница поддержки говорит, что команды поддержки базируются во Франции и работают из Франции. Страница соответствия перечисляет официальные даты и периметры действия. Но суверенитет — это не только национальный ярлык.

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

Публичный сетевой след даёт похожий урок. У AS33930 есть видимые префиксы, валидная авторизация происхождения маршрутов в проверенном представлении, участие в точках обмена и записи об объектах. Это лучше, чем видеть только фронт-энд реселлера в чужой сети. Это означает, что у Cloud Temple есть прямой маршрутизируемый контур и публичная история межсоединений.

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

Сильнее всего затронуты те клиенты, на которых Cloud Temple и нацелен: госорганы, поставщики здравоохранения, финансовые фирмы, промышленные операторы, издатели ПО и другие организации, которым нужны и гарантии соответствия, и операционная непрерывность. В таких средах сбой облака редко бывает просто неудобством. Он может задержать медицинскую помощь, остановить регулируемую отчётность, остановить системы рядом с производством, заблокировать госуслуги, нарушить доступ к идентичности или помешать издателю ПО обслуживать нижестоящих клиентов. Правильный вопрос при комплексной проверке — не «Может ли Cloud Temple разместить виртуальную машину?».

Очевидно, может. Вопрос: «Соответствует ли выбранный дизайн сервиса тому вреду, который наступит, если это приложение остановится?»

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

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

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

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

Окна обслуживания заслуживают такого же внимания. Формулировки SLA исключают плановое обслуживание, о котором уведомили в рамках договора поддержки клиента. Это нормально, но переносит практическое планирование на клиента. Кто получает уведомления об обслуживании? Передаются ли они команде, владеющей приложением? Знает ли клиент, может ли обновление гипервизора вызвать перезапуск? Понимает ли он, что некоторые обновления ОС гипервизора могут быть решением клиента, потому что Cloud Temple не знает всех ограничений, связанных с нагрузкой? Присутствуют ли во время окна команды резервного копирования, мониторинга и межсетевого экрана?

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

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

Если приложению нужно ещё четыре GPU-сервера во время аварии, или замена хоста после отказа сервера, или дополнительная пропускная способность объектного хранилища во время восстановления, клиент должен знать, будет ли ответ немедленным, плановым, зависящим от заказа или от расчёта.

То же относится к доказательству восстановления. Квалифицированная платформа Cloud Temple, избыточность S3 и архитектура резервного копирования создают более прочную отправную точку, чем обычный хостинг. Но матрицы ответственности IaaS и S3 неоднократно относят согласованность плана резервного копирования и периодическое тестирование восстановления к клиенту, иногда с участием Cloud Temple. Это должно изменить язык закупок.

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

Оценка доказательности для TEMPLE Cloud Temple SAS должна быть поэтому лучше, чем осторожность «тонкого следа» из задания, но всё же не абсолютной. Публичная запись широкая, актуальная и конкретная: официальные страницы описывают позиционирование в регулируемых отраслях, французские офисы, периметры SecNumCloud и HDS, семейства продуктов, уровни поддержки, архитектуру объектного хранилища, дизайн частной магистрали, условия SLA для VPC и VM, физические лимиты размещения, маршрутизацию AS33930, валидность RPKI, точки обмена и публичные компоненты статуса. Это существенный след.

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

Практический вывод для покупателей — относиться к TEMPLE Cloud Temple SAS как к заслуживающему доверия суверенному облаку, которому всё ещё нужно доказательство на уровне рабочей нагрузки. Попросите схему, которая называет регион, зоны доступности, вычислительные хосты или классы, классы хранилищ, S3-бакеты, политики резервного копирования, VPC-шлюзы, интернет-выходы, каналы клиента, контакты поддержки и пути эскалации. Спросите, какие обязательства покрыты периметром SecNumCloud, какие относятся к HDS, какие являются обычным размещением, какие находятся в предварительной версии, а какие принадлежат клиенту.

Спросите, как запрашиваются сервис-кредиты и что они не покрывают. Спросите, как нагрузка уходит, как стираются данные, как обрабатываются ключи и как ведёт себя поддержка вне рабочих часов.

Для читателей, занимающихся инфраструктурой, урок шире. Провайдер суверенного облака может быть одновременно по-настоящему операционным и все равно зависеть от будничной физики мощностей. TEMPLE Cloud Temple SAS продаёт привлекательную комбинацию: квалифицированную французскую инфраструктуру, узнаваемые корпоративные платформы, видимую маршрутизацию, объектное хранилище в трёх зонах доступности, поддержку во Франции и явные матрицы ответственности. Но клиент покупает не «суверенитет» абстрактно. Он покупает конкретный тенант, класс серверов, уровень хранения, сетевой путь, уровень заявок, календарь обслуживания и условия вывода.

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