Кратко

  • TodoEnCloud — действующая мадридская компания в сфере облачных и управляемых сервисов, а не просто спящая запись в корпоративных или сетевых реестрах. Компания утверждает, что предоставляет публичное облако с 2011 года; Tessi зафиксировала приобретение бизнеса в 2018 году; а действующие реестровые записи, сертификаты, сайт и данные маршрутизации указывают на продолжающуюся деятельность.
  • Испанское публичное облако компании представлено как три зоны в трёх дата-центрах Мадридского региона, соединённых кольцом тёмного волокна. Сертификат ENS от ноября 2025 года называет площадки: Interxion на Calle Albasanz 71, DATA4 на Avenida de la Industria 15 в Алькобендасе и IPCore на Calle Marzo 16. Это независимые операторы площадок; TodoEnCloud, судя по всему, владеет или контролирует сервисное оборудование и сетевой уровень, а не здания, подстанции или генераторы.
  • 12 июля 2026 года AS201346 анонсировал четыре маршрута IPv4 /24, охватывающих 1024 адреса. Коллекторы RIPE наблюдали три соседние вышестоящие сети, связанные с Cogent, Lumen и NEAR IP, а проверенный маршрут имел действительную авторизацию RPKI. Это весомое операционное свидетельство, хотя отсутствие видимого IPv6 и записи в PeeringDB оставляет пробелы в публичной картине межсетевых соединений.
  • Три площадки полезны лишь тогда, когда клиентские вычисления, хранилища, сеть, идентификация, управление и резервное копирование намеренно распределены между ними. TodoEnCloud не публикует количество установленных серверов, полезную ёмкость CPU или хранилищ, запас по каждой площадке, переподписку, показатели восстановления, историю инцидентов или стандартный график уровней обслуживания. Поэтому возможности площадок не следует считать доказательством того, что любой арендованный ресурс переживёт потерю одной площадки.
  • В целом операционные свидетельства сильные, а публичные свидетельства о восстановлении — средние. Покупатель может проверить юридическое лицо, материнскую компанию, площадки, сертификаты, адресное пространство и активную маршрутизацию. Чтобы считать облако переносимым и устойчивым к отказу площадки, покупателю всё ещё нужны архитектура под конкретную нагрузку, границы питания и волокна, целевые показатели точки и времени восстановления, правила обслуживания, эскалация поддержки, политика запасного оборудования и хронометрированное испытание вывода.

Облако сосредоточено в трёх конкретных зданиях Мадрида

Предложение TodoEnCloud необычно полезно для анализа инфраструктуры: компания называет физический уровень под своим облаком. Настранице публичного облакасказано, что сервис распределён по трём испанским дата-центрам, соединённым высокоскоростным волоконным кольцом с низкой задержкой и представленным клиентам как три зоны в пределах одной зоны доступности. Настранице дата-центровназваны Digital Realty, DATA4 и IPCore. Решающее значение имеетсертификат ENS, выданный в ноябре 2025 года: он идентифицирует Interxion на Calle Albasanz 71, DATA4 Group на Avenida de la Industria 15 в Алькобендасе и IPCore Дата-центр на Calle Marzo 16 в Мадриде.

Эти адреса превращают утверждение в нечто большее, чем схема. Digital Realty указывает Calle Albasanz 71 как своюплощадку MAD1— объект площадью 8 280 м² в составе мадридского портфеля из четырёх объектов.Страница мадридского кампуса DATA4размещает её площадку MAD01 по тому же адресу в Алькобендасе, что указан в сертификате TodoEnCloud, и описывает кампус со значительными резервами электроэнергии. Всобственном описании IPCoreуказано нейтральное к операторам здание площадью 1 200 м² на Calle Marzo 16 с резервируемыми питанием и охлаждением, несколькими вводами волокна и круглосуточными услугами удалённых рук.

Таким образом, физическая картина — это облако мадридской агломерации, а не национальное распределение по удалённым регионам Испании. Albasanz и Calle Marzo находятся в самом Мадриде; DATA4 — в Алькобендасе к северу от центра. Разнесение в пределах агломерации защищает от пожара в стойке, отказа здания, сбоя локального коммутатора или работ на одном присоединении к энергосети. Оно слабее защищает от регионального сбоя связи, крупной аварии в энергосистеме, программной ошибки, развёрнутой повсюду, общей проблемы поставщика или операционной ошибки, которую растиражировала одна команда.

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

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

Исход решает архитектура, а не слова.

TodoEnCloud управляет сервисным уровнем, а не всем физическим имуществом

Корпоративная идентичность ясна.Уведомление о конфиденциальностина сайте идентифицирует TODOENCLOUD S.L. в Мадриде и приводит тот же номер телефона, что и в деловых справочниках. Коммерческие реестры относят создание компании к 2011 году. В годовом отчёте Tessi за 2019 год зафиксированоприобретение Todo en Cloud в 2018 годукак часть экспансии французской группы в облачную архитектуру и услуги дата-центров. Сайт TodoEnCloud теперь сообщает, что её услуги входят в цифровую фабрику Innovation & Trust группы Tessi.

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

Слова о собственности на сайте компании требуют такой же осторожности. TodoEnCloud говорит о «собственной инфраструктуре в Испании», а иногда — о «наших» дата-центрах. Однако названные здания эксплуатируют Digital Realty, DATA4 и IPCore. Более точное прочтение: TodoEnCloud владеет, арендует или контролирует серверы, хранилища, сетевое оборудование и программное обеспечение, развёрнутые в сторонних центрах колокации, и покупает электроэнергию, площади, физическую охрану и сервисы площадок по договорам с этими операторами. Компания может также арендовать тёмное волокно, «зажигая» его собственным оптическим оборудованием.

Такая многослойная собственность — норма. Немногим региональным облакам нужно владеть подстанцией, бетонной оболочкой и баками с дизельным топливом, чтобы предоставлять серьёзный сервис. Следствие: ответственность распределена по договорам. Digital Realty, DATA4 или IPCore реагирует на тревогу в здании и обслуживает инженерные системы площадки. Оператор связи или провайдер волокна ремонтирует внешний маршрут. TodoEnCloud управляет клиентской платформой, сетевой политикой и, возможно, активным оптическим уровнем. Вендоры поставляют серверы, диски, сетевые карты и комплектующие. В конечном счёте Tessi контролирует «дочку».

Клиенту принадлежат приложение, модель данных, учётные данные и та схема восстановления, которую он купил.

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

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

TodoEnCloud приводит необычно конкретные сертификационные свидетельства. Еёдействующий сертификат ISO 27001охватывает системы управления информацией, обеспечивающие публичный и частный IaaS в мадридском головном офисе и по двум адресам дата-центров: Albasanz 71 и Avenida de la Industria 15. Он действителен с июля 2024 года по июнь 2027 года. Отдельныйсертификат ISO 27701покрывает систему управления конфиденциальностью информации для той же деятельности и тех же двух площадок до сентября 2027 года.

Более поздний сертификат ENS шире. Он фиксирует все три названных дата-центра и сообщает, что системы, обеспечивающие публичный и частный IaaS, проверены по Национальной схеме безопасности Испании в средней категории. Это создаёт датированный мост между маркетингом трёх площадок и областью внешнего аудита. Он также снимает видимое противоречие на странице безопасности компании, где всё ещё сказано, что ISO 27001 покрывает два дата-центра. Наиболее правдоподобное объяснение — расхождение во времени: в документах ISO перечислены две площадки, а более поздний аудит ENS добавляет IPCore.

Сертификация ценна тем, что фиксирует управление, определённую область действия, аудитора и срок действия. Она не раскрывает ёмкость и не делает каждую нагрузку высокодоступной. ISO 27001 касается системы менеджмента информационной безопасности. ISO 27701 расширяет управление конфиденциальностью. Категория «Средний» ENS накладывает меры контроля на системы, обслуживающие соответствующие потребности испанского государственного сектора.

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

Сертификации площадок следует также отделять от сертификаций провайдера. На странице дата-центров TodoEnCloud есть широкие утверждения о площадках уровня Tier III+ или Tier IV, компонентах с резервированием N+1, независимых подстанциях, аккумуляторах и генераторах, а также о доступности от 99,95 до 99,999 %. Похоже, это обобщение возможностей площадок выбранных операторов. Это не опубликованное соглашение об уровне сервиса TodoEnCloud, и сам диапазон охватывает очень разные допуски по простою. В году из 365 дней 99,95 % допускают около 4 часов 23 минут недоступности; 99,999 % — около 5 минут 15 секунд.

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

Сертификат может также исключать зависимость, которую клиенты считают покрытой. В сертификатах ISO названы два ЦОДа, тогда как публичное облако теперь описывает три. Управляемый сервис AWS или Azure, продаваемый TodoEnCloud, зависит от этих внешних платформ, а не только от сертифицированного испанского облака. Граничный узел на заводе или у столба освещения физически находится вне мадридских площадок. У собственного локального кластера клиента свои границы питания и безопасности. Поэтому область действия следует читать для каждого сервиса отдельно, а не приклеивать к логотипу компании как универсальное свойство.

Установленная и полезная ёмкость остаются нераскрытыми

Самый большой пробел в публичных данных — ёмкость. TodoEnCloud предлагает публичное облако, частное облако, bare metal, Kubernetes, GPU-инстансы, резервное копирование, аварийное восстановление, колокацию и управляемую эксплуатацию. Компания говорит, что клиенты могут масштабироваться и платить за использование. Она не публикует ни количество и поколение вычислительных хостов, ни суммарные физические ядра, память, парк ускорителей, носители, полезные петабайты, обычную загрузку, мощность стоек, зарезервированный запас или распределение по площадкам.

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

Последнее различие — самое важное. Ёмкость, полезная в обычный день, не обязательно является отказоустойчивой. Предположим, три площадки загружены на 60 % от безопасной клиентской нагрузки каждая. Потеря одной оставит две площадки, которым придётся нести по 90 % — ещё до учёта неравномерности нагрузки, локальности данных и сетевых ограничений. Это могло бы быть восстанавливаемо. При обычной загрузке 80 % двум выжившим пришлось бы выйти на 120 %, что невозможно без сброса части нагрузки или остановки части сервисов. Эти цифры — примеры, а не оценки загрузки TodoEnCloud.

Они показывают, почему одно лишь количество площадок не устанавливает восстанавливаемость.

Инвентаризация оборудования создаёт ещё один пробел.Предложение частного облака TodoEnCloudпростирается от развёртываний из трёх узлов до крупных индивидуальных сред на оборудовании клиента или приобретённом за счёт провайдера.Предложение bare metalобещает выделенный физический контроль с облачной моделью потребления. Эти сервисы нельзя восстановить, выделив любую универсальную виртуальную машину. Восстановление может потребовать того же семейства CPU, объёма памяти, сетевого интерфейса, ускорителя, прошивки или подключения к хранилищу. Запасной узел, лежащий на складе, ещё не подключён кабелями, не настроен и не введён в кластер.

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

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

Сеть реально активна и разнообразнее одной транзитной линии

Сетевые данные — самый сильный независимый операционный сигнал. В ноябре 2014 года в реестре RIPE за компанией TODO EN CLOUD SL был закреплён номерAS201346. За компанией также числится действующее выделение IPv4 185.77.132.0–185.77.135.255. 12 июля 2026 годапредставление статуса маршрутизации в RIPEstatпоказывало четыре анонсированных префикса /24, 1024 анонсированных адреса IPv4, полную видимость среди сообщающих IPv4-пиров и отсутствие анонсированного пространства IPv6.

Данные RIPE о наблюдаемых соседяхпоказывали три сети на вышестоящей стороне AS201346: AS174, связываемую с Cogent; AS3356, связываемую с Lumen; и AS49600 — NEAR IP. Репрезентативный префикс /24 имелдействительную авторизацию маршрута RPKI. CIDR Report также видел, что AS201346 анонсирует эквивалент /22 по путям Cogent и Lumen. Эти наблюдения подтверждают активный хостинг и разнообразие маршрутов убедительнее, чем одна лишь страница продуктов.

Но у этих данных есть пределы. Коллектор BGP может показать, что три вышестоящие автономные системы распространяют маршруты TodoEnCloud. Он не может показать, что у каждой площадки есть физически отдельные вводы ко всем трём сетям, что каждый оператор способен принять всю трафиковую нагрузку или что каналы не сходятся в общей канализации, комнате встреч операторов (meet-me room) или общей оптической платформе. Два контракта с операторами могут сойтись на одном городском волоконном маршруте. Три маршрута могут заканчиваться на одном пограничном шасси.

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

Зарегистрированная политика маршрутизации компании тоже выглядит старше наблюдаемой сети. Её объект aut-num в реестре RIPE называет AS35699 и AS201942 в операторах импорта и экспорта, тогда как живые наблюдения показывают Cogent, Lumen и NEAR IP. Объекты реестровой политики обычно отстают от операционных договорённостей, но это расхождение — полезное предупреждение не читать административный текст как живую карту топологии. Клиенту, которому нужны гарантии маршрутов, следует получить актуальную схему сети и испытать переключение, а не выводить её из объекта десятилетней давности.

Публичный запрос сетей в PeeringDB не возвращал записей для AS201346. Это отсутствие не означает плохой связности. PeeringDB — добровольный операционный справочник, и сеть, работающая преимущественно на транзите, может функционировать без записи в нём. Но это убирает один распространённый способ проверить присутствие на площадках, участие в точках обмена трафиком, политику трафика и публичные контакты сети. На собственных страницах компании упоминаются связи с точками обмена интернет-трафиком и несколькими операторами, но порты обмена и ёмкости для AS201346 не названы.

Отсутствие видимого IPv6 — более прямой вопрос к сервису. Четыре живых маршрута IPv4 поддерживают обычный хостинг, но клиентам, строящим современные публичные сервисы, может требоваться нативный двухстековый доступ. Трансляция сетевых адресов на уровне провайдера или отдельный вышестоящий оператор могут иногда дать IPv6 без маршрута AS201346, но такая схема должна быть явной. Покупателю стоит спросить, доступен ли IPv6 виртуальным машинам и bare-metal серверам, как адреса маршрутизируются при переключении между площадками и одинаково ли защита от DDoS относится к обоим семействам протоколов.

Кольцо волокна уменьшает часть отказов и создаёт собственную проблему ремонта

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

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

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

Задержки и потери между площадками влияют на поведение хранилища ещё до полного отказа. Синхронная репликация ждёт подтверждения с удалённой стороны и может замедляться при деградации канала. Асинхронная репликация может продолжаться локально, но увеличивает объём недавних данных под риском. Защита от split-brain может намеренно остановить одну сторону, чтобы две копии не принимали конфликтующие записи. С точки зрения клиента, осторожная остановка хранилища — это всё равно простой, но она может быть верным выбором для сохранения целостности.

TodoEnCloud предлагает отдельные услугиIP-транзита, DDoS-защиты и VPN. Это может упростить зоны ответственности: один провайдер управляет и вычислениями, и связностью. Но это же может сконцентрировать отказ, если всеми ими управляют одни и те же пограничные узлы, команда поддержки, состояние аккаунта или сетевая автоматизация. В отказоустойчивой схеме должны быть определены канал доступа вне полосы (out-of-band) и канал связи, который остаётся работоспособным, когда производственная сеть или панель клиента недоступны.

Устойчивость энергоснабжения упирается в фактический путь до стойки клиента

Три оператора площадок описывают серьёзные системы электроснабжения. На мадридской странице Digital Realty указано охлаждение N+1 на MAD1. DATA4 описывает крупный мадридский кампус со значительной электрической ёмкостью. IPCore рекламирует ИБП 2N, резервный дизель-генератор и резервируемое охлаждение. TodoEnCloud обобщает выбранные площадки как имеющие независимые подстанции, отдельные вводы, ИБП, аккумуляторы и генераторы.

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

Плотность мощности также ограничивает полезное оборудование. GPU- и bare-metal-продукты могут потреблять на стойку значительно больше, чем старые универсальные серверы. На площадке может быть свободная площадь, но не хватать выдаваемых киловатт, охлаждения или пропускной способности шин для ещё одного плотного развёртывания. Новые страницы GPU у TodoEnCloud рекламируют ресурсы NVIDIA L4 и L40 по требованию, но не сообщают ни об объёме парка, ни о плотности стоек, ни о том, есть ли ёмкость ускорителей на одной или нескольких площадках.

Клиентам стоит рассматривать мгновенное масштабирование как коммерческое обещание, ограниченное установленным парком.

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

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

Хранилище, резервное копирование и аварийное восстановление — разные продукты

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

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

Целевая точка восстановления (RPO) и целевое время восстановления (RTO) превращают эти продукты в измеримые обязательства. Точка восстановления определяет, сколько недавних данных может быть потеряно. Время восстановления определяет, как долго бизнес может ждать. Ни то ни другое нельзя выводить из слов «автоматическое резервное копирование» или из числа площадок. База данных с синхронной репликацией может стремиться к почти нулевой потере данных, но останавливаться при разделении сети. Ночное резервное копирование может восстановить после потери здания, но пожертвовать рабочим днём транзакций.

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

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

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

Труд поддержки — часть ёмкости

Центральное коммерческое обещание компании — внимательные архитектура и эксплуатация. На сайте предлагаются опции поддержки от 8×5 до 24×7, круглосуточный мониторинг, администрирование систем, помощь с миграцией и персональные технические контакты. Отзывы клиентов подчёркивают отзывчивость. Для регионального провайдера этот человеческий слой может быть реальным преимуществом перед очередью тикетов, которая ничего не знает о приложении клиента.

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

В открытых материалах не указаны состав смен, глубина дежурств, реакция эскалации, определения серьёзности инцидентов или обязательства по услугам удалённых рук. Оценки по LinkedIn и деловым базам данных говорят о небольшой испанской компании, хотя такие цифры неполны, и их не следует принимать за проверенную численность персонала. Релевантный вопрос для покупателя — не общая численность сотрудников, а сколько квалифицированных людей смогут действовать по этому сервису в 03:00, как быстро подключится второй специалист и у кого есть полномочия объявить аварию на площадке или у оператора связи.

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

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

Биллинг и контроль аккаунта могут сделать здоровую машину бесполезной

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

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

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

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

Испанская локация значима, но суверенитет — это стек

Локальность данных — центр предложения TodoEnCloud. Компания говорит, что дата-центры её публичного облака находятся в Испании и что она не передаёт информацию за пределы Европы. Сертификат ENS размещает проверенные системы IaaS в трёх площадках Мадридского региона. Испанское юридическое лицо и материнская компания Tessi идентифицируемы. Для покупателей, которым нужно испанское место размещения, это конкретные преимущества перед расплывчатой меткой «регион Европа».

Локация не отвечает на все вопросы суверенитета. Вендоры оборудования могут быть иностранными. Программное обеспечение поддержки, тикет-система, телеметрия, доменные сервисы и данные об угрозах могут затрагивать другие юрисдикции. Управляемый мультиоблачный сервис может администрировать нагрузки в AWS, Azure или Google Cloud. Метаданные резервных копий могут перемещаться иначе, чем полезные данные. Французская материнская компания может иметь управленческий или поддерживающий доступ, даже когда серверы остаются в Мадриде. Ни одно из этих обстоятельств само по себе не отменяет суверенитета; каждое должно быть отражено в карте потоков данных.

Политика безопасности компаниивыстраивает её область действия в соответствии со стандартами ISO и Национальной схемой безопасности Испании.Королевский декрет Испании 311/2022требует рассматривать безопасность как целостный процесс и включает непрерывность деятельности, реагирование на инциденты, защиту хранимой и передаваемой информации и аудит. Поэтому сертификация ENS в средней категории содержательнее, чем самопровозглашённый лозунг о локации. Это всё же оценка категории и области действия, а не юридическое заключение для конкретного клиента.

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

Физическая концентрация в Мадриде создаёт компромисс. Она даёт однозначную испанскую резидентность и мультиплощадочную схему с низкой задержкой. Она не даёт широкой географической разнесённости. Клиентам с требованием удалённой копии может понадобиться другой испанский регион, локальная площадка клиента, мощности Tessi в другом месте Европы или второй провайдер. Этот выбор должен определяться моделью угроз и юридическими потребностями, а не одним словом «суверенный».

Открытое ПО помогает уйти, но миграция — всё равно физическая передача

TodoEnCloud сообщает, что более 90 % её ядра построено на открытом программном обеспечении, и предоставляет доступ через API, Terraform и OpenTofu. Её гибридный имультиоблачный сервисделает упор на документированные методы, распределённые нагрузки и снижение зависимости от одного поставщика. Эти решения могут улучшить переносимость благодаря знакомым образам, оркестрации и объектным интерфейсам вместо уникальных проприетарных форматов.

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

Закон ЕС о данных (Data Act) делает этот вопрос особенно актуальным. Впояснениях Европейской комиссии к Data Actсказано, что клиенты облачных и пограничных сервисов должны иметь возможность менять провайдера, а плата за переход, включая плату за исходящий трафик в процессе перехода, отменяется с 12 января 2027 года. Регламент требует договорной информации о процедурах, форматах, ограничениях и расчётном времени и ожидает, что инфраструктурные провайдеры будут по возможности обеспечивать функционально эквивалентный результат.

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

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

Практические пути отказов коррелированы

Трёхплощадочная архитектура TodoEnCloud даёт несколько способов ограничить инцидент, но последствия для клиента зависят от того, где остаётся корреляция.

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

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

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

Различается и то, кого затрагивает инцидент. Клиент с одной виртуальной машиной может потерять сайт и его пользователей. Клиент управляемого частного облака может потерять корпоративное приложение, доступ сотрудников и зависимых поставщиков. Государственный орган, использующий сервис в области действия ENS, может нести обязательства по отчётности и непрерывности. TodoEnCloud несёт расходы на ремонт, компенсации и ущерб репутации. Операторы площадок и операторы связи несут собственные обязательства по сервису. Tessi несёт коммерческий риск на уровне группы. Инцидент — одно событие, но последствия распределены по всей цепочке.

Что сделало бы кейс отказоустойчивости полным

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

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

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

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

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

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

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