XSALTO35667 Alpilink Cloud S.A.S. продаёт арендуемые мощности, которые по-прежнему зависят от стоек, транзита и ремонтных окон

Кратко

• Реестр RIPE RDAP регистрируетAS35667как XSALTO35667 для Alpilink Cloud S.A.S.; по данным RIPEstat, AS анонсировался на момент запроса 15 июля 2026 года, при этом94.143.216.0/21— видимое выделение IPv4, а для этого источника установленвалидный RPKI.
• Публичный маршрут стабилен, но узок:статус маршрутизации RIPEstatпоказывал один префикс IPv4, 2048 адресов IPv4, ни одного видимого префикса IPv6 и одного наблюдаемого соседа, аданные о соседях RIPEstatидентифицировали этого соседа как AS28768.
• Собственнаястраница Services CloudAlpilink заявляет housing, IaaS, виртуальные машины, managed-сервисы, резервное копирование и внешнее аварийное восстановление, круглосуточную поддержку французских экспертов, три связанных центра обработки данных, гарантированную полосу 40 Гбит/с, более 1500 обслуживаемых серверов и 3 ПБ хранимых данных; это заявления самой компании об операционной деятельности, а не независимый аудит мощностей.
• Текущий уровень доказательности — «средне-сильный» для идентификации и контроля маршрута, но лишь «средний» для устойчивости клиента. Публичные данные подтверждают реальную французскую облачную и хостинговую деятельность, однако клиентам всё ещё нужны актуальные подтверждения размещения в стойках, пригодной к использованию ёмкости, проектирования питания и охлаждения, диверсификации маршрутов за пределами родительского AS, изоляции резервных копий, эскалации поддержки и прав на миграцию.

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

Самый важный первый шаг — идентификация. Покупатель не может оценить арендуемые мощности, пока не знает, какая организация контролирует адреса, контракты, службу поддержки и физические активы за сервисом. На этот счёт у XSALTO35667 Alpilink Cloud S.A.S. есть полезные публичные данные. RIPE RDAP наhttps://rdap.db.ripe.net/autnum/35667называет AS35667 как XSALTO35667 и связывает его с Alpilink Cloud S.A.S.; запись организации показывает адрес: 2 Rue de la Viscose, Le Rayon Vert, 38130 Échirolles, France. В том же ответе RDAP указаны административные контакты и контакты сетевой эксплуатации XSALTO с адресом в Seyssinet-Pariset. Эти данные не являются гарантией производительности, но закрепляют компанию в реальном французском операционном контексте.

Адресное пространство тоже выглядит ясно. RIPE RDAP наhttps://rdap.db.ripe.net/ip/94.143.216.0/21определяет диапазон 94.143.216.0–94.143.223.255 как FR-XSALTO-20090310, выделение PA, страна FR, статус active, и связывает его с Alpilink Cloud S.A.S. Обзор AS в RIPEstat наhttps://stat.ripe.net/data/as-overview/data.json?resource=AS35667сообщил, что AS анонсировался на момент запроса 15 июля 2026 года. Конечная точка announced-prefixes наhttps://stat.ripe.net/data/announced-prefixes/data.json?resource=AS35667показывала 94.143.216.0/21 в двухнедельном окне, завершившемся 15 июля 2026 года. Обзор префикса наhttps://stat.ripe.net/data/prefix-overview/data.json?resource=94.143.216.0/21подтвердил AS35667 как держателя происхождения.

Сеть также защищена объектом авторизации маршрута. Конечная точка валидации RPKI в RIPEstat по адресуhttps://stat.ripe.net/data/rpki-validation/data.json?resource=35667&prefix=94.143.216.0/21вернула состояние valid с валидирующей ROA для источника AS35667, префикса 94.143.216.0/21 и максимальной длины /21. Это значимый сигнал гигиены. Он не гарантирует аптайм, операционную безопасность или диверсификацию маршрутов, но снижает один класс предотвратимых маршрутных рисков: валидная авторизация происхождения маршрута даёт вышестоящим сетям и валидаторам способ отклонять несанкционированные источники для анонсируемого /21.

Эти технические факты важны, потому что компания продаёт физическую зависимость в облачной обёртке. Собственная страница Services Cloud по адресуhttps://www.alpilink.fr/services-cloud/перечисляет housing, IaaS, виртуальные машины, managed-сервисы, резервное копирование и внешнее аварийное восстановление. На ней сказано, что Alpilink Services Cloud предлагает экспертизу и услуги суверенного хостинг-оператора во Франции, с французской командой экспертов, доступной 24 часа в сутки, обязательствами по безопасности и устойчивой корпоративной политикой. Там же приведены масштабные показатели: три связанных ЦОД, гарантированная полоса 40 Гбит/с, более 1500 обслуживаемых серверов и 3 ПБ хранимых данных. Это не общие программные утверждения. Они подразумевают стойки, питание, охлаждение, диски, сетевые каналы, резервные копии, персонал поддержки и объекты.

Сложность для покупателя в том, что публичные данные сильны на уровне идентичности и позиционирования самой компании, но неполны на уровне живой ёмкости. Мы видим текущий AS, текущую видимость маршрута, валидность RPKI, строки о площадках в PeeringDB и подробную страницу облачных услуг от самой компании. Мы не видим посегментный учёт ёмкости: доступные шкафы, зарезервированное питание, свободные порты, склад серверов, запасные диски, запас гипервизорного кластера, насыщенность резервных копий, договоры remote hands или глубину очереди поддержки. Это различие не враждебно по отношению к Alpilink.

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

AS35667 зарегистрирован безупречно, но публичная маршрутная поверхность узкая

Данные о маршруте обнадёживают в одном отношении и ограничивают в другом. Статус маршрутизации RIPEstat по адресуhttps://stat.ripe.net/data/routing-status/data.json?resource=AS35667сообщал: один префикс IPv4, 2048 адресов IPv4, ноль префиксов IPv6 в видимой картине AS35667, 326 из 326 пиров RIS IPv4 видели маршрут и один наблюдаемый сосед на момент запроса 15 июля 2026 года. Это сильная видимость единственного IPv4-маршрута. Это означает, что AS не просто присвоен: его широко видели в публичных данных маршрутизации.

Ограничение состоит в том же показателе, прочитанном с точки зрения устойчивости. Один видимый префикс и один наблюдаемый сосед не доказывают многопутевую клиентскую архитектуру. Конечная точка соседей RIPEstat по адресуhttps://stat.ripe.net/data/asn-neighbours/data.json?resource=AS35667показала AS28768 как единственного наблюдаемого соседа в наблюдении от 14 июля 2026 года. Представление whois в RIPEstat по адресуhttps://stat.ripe.net/data/whois/data.json?resource=AS35667также фиксирует импорт от AS28768 и экспорт в AS28768. Конечная точка согласованности по адресуhttps://stat.ripe.net/data/as-routing-consistency/data.json?resource=AS35667обнаружила 94.143.216.0/21 и в BGP, и в whois, а AS28768 — и в видах импорта, и экспорта. Это аккуратно. Но и сконцентрировано.

AS28768 — не несущественный фон. Сетевой объект PeeringDB дляhttps://www.peeringdb.com/api/net?asn=28768идентифицирует XSALTO с 10 префиксами IPv4, 10 префиксами IPv6, одним IX и тремя записями о площадках в публичном профиле, аhttps://www.peeringdb.com/api/netixlan?asn=28768перечисляет пиринг France-IX AURA LyonIX. Данные netfac в PeeringDB по адресуhttps://www.peeringdb.com/api/netfac?net_id=9058показывают присутствие AS28768 в Cogent Grenoble, Orange Business - La Fabrique в Гренобле и XSALTO Grenoble в Сессине-Паризе. Это говорит о том, что более широкая сеть XSALTO/Alpilink, судя по всему, шире одного AS35667.

Но назначение здесь конкретно — XSALTO35667 Alpilink Cloud S.A.S., и публичная картина AS35667 сама по себе не показывает такой же диверсификации. Объект AS35667 в PeeringDB по адресуhttps://www.peeringdb.com/api/net?asn=35667указывает в профиле один префикс IPv4, один префикс IPv6, трафик 1–5 Гбит/с, охват Европа, сбалансированное соотношение, ноль IX и одну площадку. Конечная точка netfac по адресуhttps://www.peeringdb.com/api/netfac?net_id=13798показывает эту площадку как XSALTO Grenoble в Сессине-Паризе. Конечная точка netixlan для AS35667 в ходе этого обзора не вернула ни одной публичной строки IX LAN. Опять же, это не означает, что операционной диверсификации не существует; это означает, что публичное доказательство диверсификации для этого AS ограничено.

Это важно, потому что многие сбои у клиентов происходят на границе между «у группы есть устойчивость» и «у моего конкретного пути обслуживания есть устойчивость». Если виртуальные машины клиента пронумерованы из 94.143.216.0/21 и их путь в интернет идёт через AS35667 и AS28768, клиенту стоит спросить, как устроен AS28768, где находятся пограничные маршрутизаторы, может ли маршрут переключиться внутри сети группы, какие транзитные и пиринговые пути реально несут трафик и зависят ли DNS, поддержка, резервное копирование и управляющий доступ клиента от той же площадки.

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

Физическая инфраструктура сосредоточена в Гренобле: текущий и будущий слои нельзя путать

Физическая сторона данных указывает на Гренобль и окрестные муниципалитеты. В записях RIPE есть Эшироль и Сессине-Паризе. PeeringDB указывает XSALTO Grenoble как площадку в Сессине-Паризе. Страница Services Cloud даёт контактный адрес: Le Rayon Vert, 2 rue de la Viscose, 38130 Échirolles. Страница гарантий HDS по адресуhttps://www.alpilink.fr/services-cloud/garanties-hds/называет ALPILINK CLOUD по адресу 6 Avenue Pierre de Coubertin, 38170 Seyssinet-Pariset, а также Orange - La Fabrique (EOLAS) по адресу 73 Rue Général Mangin, 38100 Grenoble как субподрядчика на две стойки. Это необычно конкретная публичная информация для регионального облачного провайдера.

Та же страница HDS важна и для границы оператора. На ней сказано, что у Alpilink Cloud есть собственный ЦОД, который компания эксплуатирует без субподряда, за исключением colocation-хостинга в ЦОД, перечисленных в таблице. Alpilink Cloud описывается как хостер, Orange - La Fabrique — как субподрядчик на деятельность с двумя стойками, а поддержка частично обеспечивается персоналом в Таити с зашифрованным доступом, круглосуточно.

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

Это ценное раскрытие, но операционные детали, которые клиент должен проверить, всё равно остаются. Публичная страница говорит о наличии ISO 27001 и применимости HDS, но не публикует полный объём аудита, размещение стоек клиента, топологию резервного копирования, точное разделение между собственной площадкой Alpilink и стойками, размещёнными у Orange, или то, какие нагрузки находятся в каком месте. Для клиента с медицинскими данными различие между местом хранения данных, административным доступом, хранилищем резервных копий, инструментом мониторинга и службой поддержки имеет значение.

Для клиента без медицинских данных то же различие важно для восстановления и контрактной ответственности.

Анонс нового ЦОД Alpilink добавляет будущий слой. Статья самой компании от января 2026 года по адресуhttps://www.alpilink.fr/datacenter-souverain-a-grenoble-alpilink-groupe-renforce-son-offre-dhebergement-avec-un-nouveau-site-opere-par-alpilink-cloud/сообщает, что Alpilink Groupe строит новый суверенный ЦОД в Гренобле, который будет эксплуатировать Alpilink Services Cloud, для усиления инфраструктуры к лету 2027 года. Сайт будет расположен в Сен-Мартен-д'Эре, в здании, приобретённом и оборудованном под ЦОД. Описаны модульная многозальная архитектура, высокие потолки, конструкция высокой плотности, резервирование электричества и климата, дизель-генераторы, усиленная физическая безопасность, контроль доступа, мониторинг, совместимость с требованиями продвинутого аварийного восстановления и непрерывности бизнеса, целевой PUE около 1,3 и график: работы в 2026 году, сдача и тесты в начале 2027 года, поэтапный ввод в эксплуатацию летом 2027 года.

Страница проекта по адресуhttps://www.alpilink.fr/services-cloud/nouveau-datacenter-alpilink-cloud-a-grenoble/повторяет ту же рамку: будущая площадка рассчитана на более высокую плотность, устойчивость, суверенитет и энергоэффективность; заявлена цель — архитектура, эквивалентная Tier III; на момент публикации графика площадка ещё не введена в эксплуатацию. Это важная граница между установленной и пригодной к использованию ёмкостью. Запланированная площадка может поддерживать предпродажи, резервирование и архитектурное планирование. Она не может подтвердить на июль 2026 года, что будущие залы, тракты питания и охлаждения и процедуры миграции клиентов уже пригодны для производственного трафика.

Поэтому правильный вопрос при комплексной проверке двойной. По текущему сервису: где именно сегодня находится нагрузка клиента — в собственном ЦОД Alpilink, в стойках Orange - La Fabrique, на другой связанной площадке или в управляемом месте, не названном публично? По проекту 2027 года: когда зарезервированное пространство станет доступно клиенту, какие приёмочные испытания должны пройти, как будут мигрировать клиенты и что произойдёт, если график новой площадки сдвинется? Установленная ёмкость — это оборудование и объекты, которые можно запитать, охладить, подключить и обслуживать сегодня.

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

Текущий каталог услуг достаточно широк, чтобы породить много путей зависимости

Список на странице Services Cloud — housing, IaaS, виртуальные машины, managed-сервисы, резервное копирование и внешнее аварийное восстановление — важен, потому что у каждой услуги своя форма отказа. Housing ближе всего к физической инфраструктуре. Клиент может владеть оборудованием, но Alpilink предоставляет место в стойке, питание, охлаждение, кросс-коннекты, физический доступ и частично remote hands. IaaS и виртуальные машины переносят больше ответственности на провайдера: гипервизоры, хранилище, оркестрация, обслуживание хостов, снапшоты, иногда шаблоны ОС. Managed-сервисы добавляют персонал и процедуры.

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

Собственные цифры дают представление о масштабе: три связанных ЦОД, гарантированная полоса 40 Гбит/с, более 1500 обслуживаемых серверов и 3 ПБ данных. Эти цифры достаточно конкретны, чтобы быть полезными. Но они взяты от самой компании. Публичная маршрутная запись AS35667 показывает один видимый /21; более широкий объект AS28768 в PeeringDB указывает на больший сетевой след; страница Services Cloud указывает на многосайтовую инфраструктуру; страница HDS называет собственный ЦОД и субподрядное размещение у Orange.

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

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

Агрегированная ёмкость — полезная отправная точка; проектирование услуги под конкретную нагрузку — это и есть решение о покупке.

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

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

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

Managed-сервисы создают ещё одну скрытую зависимость — людей. Публичные страницы Alpilink подчёркивают доступность французских экспертов, круглосуточное покрытие и локальную поддержку. На странице HDS указано, что часть персонала поддержки находится в Таити, а часть — в компании. Это может быть преимуществом, потому что разброс часовых поясов улучшает покрытие в нерабочее время. Но это требует ясности. Какая команда может перезагрузить оборудование по питанию? Какая команда имеет доступ к управляющим сетям? Какие инциденты требуют присутствия персонала в Гренобле? Как контролируются привилегии?

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

Маршрутные и DNS-данные стоит читать как доказательство контроля, а не как полную карту услуг

Публичные маршрутные данные доказывают контроль над пригодным к использованию интернет-ресурсом. Они не говорят, где находится каждая услуга. Геолокация RIPEstat по адресуhttps://stat.ripe.net/data/geoloc/data.json?resource=94.143.216.0/21и MaxMind GeoLite по адресуhttps://stat.ripe.net/data/maxmind-geo-lite/data.json?resource=94.143.216.0/21помещают /21 во Францию в просмотренной картине. Запрос DNS-цепочки по адресуhttps://stat.ripe.net/data/dns-chain/data.json?resource=xsalto.comпоказал, что xsalto.com резолвится в 81.200.40.205 с серверами имён ns01.xsalto.net, ns02.xsalto.net и ns03.xsalto.net. Этот веб-адрес xsalto.com находится вне блока /21 AS35667, поэтому его не следует использовать как доказательство местоположения или ёмкости 94.143.216.0/21.

Это нормальный паттерн. Маркетинговый сайт компании может находиться на отдельной платформе, в унаследованном диапазоне адресов, в сети группы, у веб-хостера или у CDN-провайдера. Местоположение публичного сайта полезно только тогда, когда речь идёт о доступности сайта. Это не прямая карта клиентских вычислений. С другой стороны, маршрутизируемый /21 — полезное доказательство контроля, но не каталог услуг. На нём могут размещаться системы управления, клиентские ВМ, DNS, мониторинг, шлюзы резервного копирования и внутренние интерфейсы. Без публичной карты услуг сторонний наблюдатель не может сказать, какие адреса соответствуют какому продукту.

PeeringDB добавляет ещё один слой, но и у него есть ограничения. Запись AS35667 в PeeringDB по адресуhttps://www.peeringdb.com/api/net?asn=35667указывает XSALTO 2, веб-сайтhttp://www.xsalto.com, AS-set AS-XSALTO, один префикс IPv4, один префикс IPv6 в профиле, охват Европа, трафик 1–5 Гбит/с, ноль публичных IX и одну площадку. API площадок по адресуhttps://www.peeringdb.com/api/fac/7114идентифицирует XSALTO Grenoble в Сессине-Паризе с двумя сетями и нулевым числом IX в этой записи. PeeringDB поддерживается операторами и может быть неполной, но всё равно это полезное публичное свидетельство того, что AS — не просто абстрактная регистрация.

Более широкий профиль AS28768 по адресуhttps://www.peeringdb.com/api/net?asn=28768— это место, где появляется более крупная история взаимосвязей. В нём указан один IX и три площадки, а конечная точка netixlan указывает France-IX AURA LyonIX. Это может поддержать гипотезу о том, что у более широкой сети Alpilink больше путей, чем у одного AS35667. Но это не доказывает без схемы сети конкретного клиента, что у трафика клиента AS35667 есть независимые апстримы, независимые пограничные маршрутизаторы, независимые волоконно-оптические маршруты или автоматическое переключение между площадками. Публичный маршрут AS35667 виден за AS28768; клиентам стоит спросить, какая диверсификация существует за этой границей.

Валидность RPKI — самый сильный пункт гигиены маршрутизации в текущих данных AS35667. Она снижает риск случайного или злонамеренного конфликта происхождения. Она не решает всех проблем маршрутизации. Если у AS28768 отказ, если площадка теряет питание, если перерезан кросс-коннект, если межсетевой экран закрылся в режиме fail-closed, если событие DDoS перегрузило точку обмена, или если DNS клиента зависит от единственного пути провайдера, RPKI не восстановит приложение. Это контроль аутентификации маршрутов, а не операционный план восстановления.

Электропитание, охлаждение и плотность: анонсированную ёмкость нужно оценивать осторожно

Страницы нового ЦОД Alpilink примечательны тем, что говорят непосредственно о плотности питания и тепловом проектировании. Статья от января 2026 года говорит, что будущая площадка рассчитана на растущие прикладные нагрузки, критически важные информационные системы и рабочие нагрузки данных/ИИ. В ней упоминаются модульная многозальная архитектура, высокие потолки, резервирование электричества, резервирование климата, дизель-генераторы, физическая безопасность, контроль доступа, супервизия, совместимость с продвинутым аварийным восстановлением и непрерывностью бизнеса, а также целевой PUE около 1,3.

Страница проекта аналогично говорит, что будущий ЦОД нацелен на архитектуру, эквивалентную Tier III, полное резервирование электричества, модульную многозальную конструкцию, энергетическую плотность и эффективное управление потоками горячего/холодного воздуха.

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

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

Сроки имеют значение. На тех же страницах работы и оснащение запланированы на 2026 год, сдача и тесты — на начало 2027 года, поэтапный ввод в эксплуатацию — на лето 2027 года. На дату публикации этой статьи эти будущие залы следует рассматривать как запланированные или находящиеся в разработке, а не как уже доказанную пригодную к использованию ёмкость. Покупатель, резервирующий пространство, может выиграть от проекта; покупателю, которому нужно немедленное производственное восстановление, нельзя полагаться на эту будущую площадку, пока она не введена в эксплуатацию, не протестирована, не подключена, не законтрактована и не принята.

Текущие заявления о «зелёном» хостинге тоже стоит читать внимательно. Статья об устойчивости от июля 2024 года по адресуhttps://www.alpilink.fr/alpilink-cloud-notre-engagement-envers-un-hebergement-durable/говорит, что Alpilink использует часть своей инфраструктуры в экологически ответственном ЦОД со 100% возобновляемой электроэнергией, охлаждением на грунтовых водах без потребления воды, соответствием Европейскому кодексу поведения по энергоэффективности ЦОД и энергоэффективностью ниже 1,30 PUE. Статья от июня 2024 года по адресуhttps://www.alpilink.fr/un-datacenter-peut-il-etre-vert/говорит, что ЦОД Alpilink Cloud недалеко от Гренобля спроектирован максимально «добродетельно» и использует гидроэлектроэнергию.

Эти заявления об устойчивости могут быть операционными преимуществами. Эффективное охлаждение и местная возобновляемая энергия могут снизить операционные расходы и риски. Но PUE и «зелёная» энергия сами по себе не доказывают резервную ёмкость. Площадка с низким PUE может быть заполнена. Сайт на возобновляемой энергии всё равно может иметь ограничения по генераторам, ИБП, охлаждению, обслуживанию или персоналу. Устойчивый жизненный цикл оборудования может снизить отходы, но при этом усиливает необходимость понимать возраст оборудования, политику запасных частей и планы обновления.

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

Локализация данных — сильная сторона, но её нужно уточнять по каждой услуге

Позиционирование Alpilink построено вокруг французского суверенитета. Страница Services Cloud говорит, что компания предлагает суверенный хостинг во Франции и французскую поддержку. Статья о Tech&Fest 2026 по адресуhttps://www.alpilink.fr/techfest-2026-alpilink-services-cloud-au-coeur-des-enjeux-de-souverainete-numerique/представляет Alpilink Services Cloud в центре вопросов цифрового суверенитета, облака и непрерывности бизнеса в Гренобле. Страница гарантий HDS прямо касается хостинга медицинских данных, местоположения данных, сертификации, ролей субподрядчиков и риска доступа из третьих стран. Это более полезное раскрытие, чем расплывчатый значок «безопасное облако».

Практическое правило остаётся: по каждой услуге отдельно. Производственная ВМ клиента может находиться в собственной площадке Alpilink. Резервная копия может лежать в другом связанном ЦОД. Зависимость стойки с медицинскими данными может включать Orange - La Fabrique. Доступ поддержки может включать персонал в Таити через зашифрованный доступ. DNS может быть в одной системе, счета — в другой, документация клиента — в третьей.

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

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

Для нагрузок, не связанных с медициной, применима та же проверка, но с другими ярлыками. Где находятся данные? Кто может получить к ним доступ? Право какой страны регулирует контракт? Какие субподрядчики предоставляют стойки, сеть, питание, мониторинг или поддержку? Как быстро клиент может выгрузить данные? Хранятся ли резервные копии в той же юридической и операционной области, что и производственная среда? Сохраняются ли логи во Франции? Ключи шифрования находятся у клиента, у провайдера или являются общими?

Если клиенту нужно уйти, сможет ли он получить образы дисков, дампы баз данных, экспорт объектного хранилища и контроль над DNS, не дожидаясь ручной очереди поддержки?

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

Сценарии отказов: что ломается первым и кого это затрагивает

Самый очевидный путь отказа — проблема со стойкой или площадкой. Клиенты housing могут потерять питание, охлаждение, кросс-коннекты или доступ remote hands. Клиенты IaaS могут столкнуться с отказом хоста, хранилища или сети. Клиенты managed-сервисов могут также потерять последовательность действий персонала, необходимую для диагностики инцидентов. Если затронутая площадка — собственный ЦОД Alpilink, провайдер контролирует большую часть реагирования. Если затронутый актив — субподрядная colocation-стойка, провайдер должен координировать действия с оператором colocation. Это различие важно во время ночного или выходного сбоя.

Маршрутный путь отказа уже, но виден. В наблюдаемых данных AS35667 публично идёт через AS28768. Если внутренняя граница между AS35667 и AS28768, маршрутизаторы родительского AS или апстрим/пиринговая инфраструктура за AS28768 испытывают проблемы, клиенты с адресами из 94.143.216.0/21 могут увидеть эффекты достижимости. Валидность RPKI не поможет, если авторизованный путь физически или операционно лежит. Клиентам стоит спросить, можно ли перенести клиентские префиксы, есть ли несколько пограничных устройств, где они находятся и тестируется ли диверсификация путей, а не просто настраивается.

Путь отказа поддержки — человеческий. Заявление Alpilink о круглосуточной поддержке ценно, а упоминание поддержки в Таити на странице HDS может улучшить покрытие. Но клиентам стоит знать, что эта поддержка реально может сделать. Может ли ночная команда перезапустить хост? Заменить диск? Получить доступ к площадке? Одобрить изменения маршрута? Восстановить резервную копию? Общаться на нужном клиенту языке? Действовать при ограничениях на медицинские данные? Разница между «мы видели оповещение» и «мы восстановили сервис» — это разница между мониторингом и восстановлением.

Путь отказа миграции — самый тихий и часто самый дорогой. Текущие облачные сервисы Alpilink и будущий проект ЦОД делают миграцию центральным вопросом. Клиентам может понадобиться переезд из существующего зала Alpilink на новую площадку в Сен-Мартен-д'Эре, с унаследованной стойки в зал высокой плотности, с физических серверов на IaaS или от Alpilink к другому провайдеру. Каждый переезд зависит от перенумерации сети, TTL DNS, экспорта резервных копий, репликации хранилища, окон обслуживания, зависимостей приложений и доступности персонала. Строительство будущего ЦОД улучшает устойчивость только после того, как план миграции станет реальным.

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

Публичные материалы вокруг Tech&Fest описывают команды DSI, RSSI и бизнес-команды, ищущие региональные и суверенные облачные модели. Это именно те пользователи, для которых время восстановления, местонахождение данных и эскалация поддержки — не абстрактные вопросы.

Что повысило бы или понизило уровень доказательности

Текущий уровень доказательности — «средне-сильный» для идентичности и гигиены сети, потому что RIPE RDAP, RIPEstat и PeeringDB согласуются по компании, AS, блоку адресов, видимости маршрута и французскому контексту площадок. Для устойчивости клиента уровень — «средний», поскольку публичные данные не показывают живую карту услуг за агрегированными заявлениями. Alpilink публикует больше операционных деталей, чем многие небольшие провайдеры, но клиентам всё равно нужно прямое подтверждение текущего размещения в стойках, пригодной ёмкости, проектирования питания, изоляции резервных копий и полномочий поддержки.

Уровень вырос бы, если бы Alpilink опубликовал датированный инфраструктурный отчёт, который сопоставляет текущие услуги с площадками, объясняет, какие ЦОД соединены оптическим кольцом, указывает, где расположены пограничные устройства AS35667 и AS28768, называет текущие договорённости об апстримах/транзите на уровне услуг, предоставляет публичную страницу статуса или истории инцидентов, описывает разделение резервных копий и отличает текущую ёмкость от площадки 2027 года.

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

Уровень упал бы, если бы AS35667 потерял широкую видимость маршрута, если бы валидное состояние RPKI исчезло без объяснений, если бы информация о площадках в PeeringDB устарела или стала противоречивой, если бы страницы компании перестали отличать текущие услуги от будущей ёмкости, если бы формулировки HDS/ISO стали неясными или если бы клиенты не могли получить текущие факты о площадках и восстановлении по контракту. Он также упал бы, если бы проект будущего ЦОД маркетингово подавался как пригодная производственная избыточность до ввода в эксплуатацию и тестирования.

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

Что клиенты должны потребовать, прежде чем засчитывать ёмкость

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

Для устойчивости маршрута карта должна отделять AS35667 от более широкого контекста AS28768. Публичные данные RIPEstat показывают AS35667 с одним видимым IPv4-блоком /21 и одним наблюдаемым соседом, тогда как PeeringDB показывает AS28768 с более широким следом площадок и пиринговых точек. Это различие может быть совершенно разумным внутри одной группы провайдера, но клиент не должен предполагать, что каждый путь AS28768 защищает каждую услугу AS35667.

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

Для устойчивости площадок карта должна отличать собственный ЦОД Alpilink от зависимости от стоек Orange - La Fabrique, названной на странице гарантий HDS. Клиент, чья нагрузка размещена в зале, управляемом Alpilink, сталкивается с одной моделью реагирования; клиент, чья нагрузка зависит от субподрядных стоек, — с другой. Покупатель должен знать, кто контролирует физический доступ, кто может заменять оборудование, кто отвечает на инциденты с питанием, какие окна обслуживания применяются и какие сервис-кредиты или права выхода действуют, если одна из площадок недоступна.

Без этой детали фраза «три связанных ЦОД» остаётся полезным маркетинговым контекстом, а не доказательством избыточности на уровне клиента.

Для установленной и пригодной к использованию ёмкости покупатель должен запрашивать текущие цифры, а не проектные. Заявления на странице Services Cloud о 1500 обслуживаемых серверах, 3 ПБ данных и полосе 40 Гбит/с описывают агрегированный масштаб. Страницы проекта в Гренобле на 2027 год описывают будущие залы высокой плотности, резервирование с генераторами и целевой PUE. Ни один из этих наборов заявлений не говорит конкретному клиенту, сколько свободных CPU, RAM, хранилища, мощности шкафа, ёмкости кросс-коннектов или времени поддержки доступно сегодня.

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

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

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

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

Вывод для операторов, зависящих от этих услуг

XSALTO35667 Alpilink Cloud S.A.S. следует рассматривать как реального французского регионального облачного и хостингового оператора с более сильным, чем в среднем, публичным подтверждением идентичности. AS35667 зарегистрирован на Alpilink Cloud S.A.S., его основной видимый IPv4-блок /21 широко анонсируется, RPKI валиден, PeeringDB указывает XSALTO Grenoble, а собственные облачные страницы Alpilink описывают housing, IaaS, виртуальные машины, managed-сервисы, резервное копирование, аварийное восстановление, сертификаты, гарантии для медицинских данных и историю с несколькими ЦОД. Операционная картина достаточно конкретна, чтобы иметь значение.

Картина зависимости тоже достаточно конкретна, чтобы задавать вопросы. Публичная маршрутная поверхность AS35667 узка. Более широкая сеть AS28768 выглядит более разнообразной, но точный путь клиента нужно проверить. Масштабные заявления Services Cloud — собственные и агрегированные. Новый проект ЦОД в Гренобле запланирован на 2027 год, и его не следует засчитывать как пригодную производственную ёмкость на июль 2026 года. HDS, ISO 27001 и заявления об устойчивости ценны, но их нужно сопоставить с фактической площадкой, услугой и путём поддержки клиента.

Для текущего клиента практические вопросы прямые. Какая площадка размещает мою нагрузку сегодня? Какой AS и какой префикс её несут? Какие апстримы и маршрутизаторы находятся на моём пути? Резервные копии находятся вне домена производственного отказа? Какой персонал может действовать в нерабочее время? Каково моё время восстановления при отказе хоста, системы хранения, питания стойки, проблемы маршрута или сбоя площадки? Если мне нужно мигрировать в новый ЦОД, что должно измениться и кто отвечает за каждый шаг?

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

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