PT. INDONESIA SUPER CORRIDOR - Дата-центр должен доказать, что заявленная ёмкость дата-центра выдержит ограничения по энергоснабжению и каналам связи

Резюме

• У PT. INDONESIA SUPER CORRIDOR - Дата-центр для этой выборки есть необычно конкретные публичные сигналы:сайт ISCрекламирует дата-центр ISC MPR уровня Tier IV на 550 стоек в Мампанг-Прапатан,страница «О компании» ISCсообщает, что компания построила сетевую и дата-центровую инфраструктуру в Cyber 1, астраница клиента Uptime Instituteперечисляет выданные награды для ISC Дата-центр DPR, ISC Дата-центр Cyber-1 Building CBR Level 9 и Дата-центр ISC MPR.
• Маршрутный след реален, но узок.APNIC RDAPназывает AS142379 как ISC-DC-AS-ID для PT. INDONESIA SUPER CORRIDOR - Дата-центр, аRIPEstat12 июля 2026 года показывал шесть текущих анонсов IPv4 /24 с полной видимостью IPv4 в RIS, но без текущей видимости IPv6 и только с одним наблюдаемым соседом по AS.
• Главный пробел в проверке не в том, существует ли бизнес дата-центров под брендом ISC. Вопрос в том, есть ли у рекламируемых предложений стоек, облака и аварийного восстановления достаточно раскрытых сведений о вводах электроснабжения, времени работы генераторов, резервировании охлаждения, разнообразии точек встречи операторов, тестах переключения клиентов и процедурах выхода, чтобы поддерживать промышленные нагрузки, когда условия по электропитанию, каналам или объекту становятся некомфортными.

ISC — более весомый случай, чем просто запись в справочнике

Некоторые профили инфраструктуры начинаются с тонкой записи в реестре и дальше не продвигаются. PT. INDONESIA SUPER CORRIDOR - Дата-центр — другой случай. Компания видна всправочнике BTW, на собственных публичных страницах услуг, в базе наград Uptime Institute, в записях PeeringDB о её точке обмена и организации, а также в живых наблюдениях маршрутизации. Это не делает операционную картину полной, но меняет вопрос. Это не поиск здания, которого может не существовать. Это проверка того, насколько можно доверять рекламируемой платформе дата-центра, у которой публичная история сильнее в части объектов и упаковки продуктов, чем в части измеренного восстановления клиентов.

Главная страница ISCоткрывается конкретным утверждением: «550 стоек доступны в дата-центре ISC MPR уровня Tier IV (5 МВт), Мампанг-Прапатан-Рая, Джакарта, Индонезия». Там также рекламируются 100 Мбит/с IIX и 10 Мбит/с IX, питание 10A, выделение публичных IP-адресов /29 и два UTP плюс два оптоволоконных кросс-коннекта для предложения в формате полной стойки. На той же странице сказано, что объект защищён, работает круглосуточно с персоналом, охраняется видеонаблюдением с детекцией движения, а доступ осуществляется через PIN-коды и карты. Это не расплывчатые облачные эпитеты. Это утверждения о стойках, мощности, кросс-коннектах и физическом доступе.

Страница «О компании»добавляет более старый контекст Cyber 1. ISC сообщает, что начинала с построения собственной сети и дата-центра в Cyber 1 в Джакарте, и описывает исходное предложение как надёжную управляемую сеть с несколькими подключениями внутри объекта с высоким временем безотказной работы. Там также говорится, что компания несёт обязанности по PCI DSS, когда хранит, обрабатывает или передаёт данные держателей карт для клиентов. На той же странице указано, что ISC находится в центре среды интернет-обмена Индонезии, заявляет устойчивость питания от двух источников через отдельный распределительный щит и позиционирует услуги вокруг качества объекта уровня Tier III. И снова это история физической инфраструктуры: местоположение, распределение питания, охват сети и обязательства по соблюдению требований.

Uptime Institute придаёт этой истории независимую форму, хотя и не полный операционный вердикт. На егостранице клиента PT Indonesia Super Corridorперечислены три площадки с выданными наградами: ISC Дата-центр DPR в Денпасаре, ISC Дата-центр Cyber-1 Building CBR Level 9 в Джакарте и Дата-центр ISC MPR в Джакарте.Список наград Uptime по странам для Индонезииставит ISC рядом с другими сертифицированными индонезийскими объектами. Покупателю всё же следует внимательно читать тип и объём награды, посколькусобственные материалы Uptime по сертификации уровнейразличают сертификацию проектирования, построенного объекта и эксплуатации. Но база наград действительно поддерживает предпосылку, что у ISC есть объекты, которые стоит оценивать, а не просто брендовая страница.

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

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

Карта активов включает три названных объекта, а не одну типовую серверную

Собственная навигация ISC разделяет историю дата-центра по страницам CBR, MPR и аварийного восстановления на Бали.Страница Дата-центр Tier III CBRрекламирует колокацию по юнитам, половине стойки и полной стойке с показателем уровня обслуживания 99,982%, пропускной способностью IIX и IX, выделением IP-адресов, правами доступа, мониторингом трафика, поддержкой smart-hands и учётными записями DCIM. Пакет полной стойки на этой странице рекламирует 100 Мбит/с IIX, 10 Мбит/с IX, диапазон публичных IP-адресов /29, пять доступов пользователей дата-центра, два порта кросс-коннекта UTP и два оптоволоконных ядра. Это унаследованная часть истории ISC, связанная с Cyber 1.

Страница Дата-центр Tier IV MPRнесёт более высокий уровень доступности. Она рекламирует показатель уровня обслуживания 99,995% для пакетов колокации по юнитам, половине стойки и полной стойке, повторяет формулировки IIX/IX и контент-кэша, а также добавляет предложения облака для бизнеса и облака для предприятий. Эти облачные пакеты заявляют 1 Гбит/с подключения к IIX, OIXP и Equinix IX, до 4 ГБ или 32 ГБ памяти, до 80 ГБ или 640 ГБ хранилища, один публичный IP-адрес, одну ОС Linux, порт 1 Гбит/с и до 30 Мбит/с международной пропускной способности. Этот набор важен, потому что он превращает ISC из компании только колокации в провайдера размещённой инфраструктуры, чьи клиенты могут полагаться на вычисления, сеть и хранилище, управляемые ISC, а не только на собственное оборудование.

Страница DRC Tier III Baliдаёт угол восстановления. Объект в Денпасаре описывается как центр аварийного восстановления, рекламируются концепции RPO и RTO, гигабитные соединения с несколькими точками обмена, взаимосвязанная оптоволоконная конструкция, устойчивое питание от двух источников разного напряжения и полная резервная генераторная ёмкость, FM200 и детекторы дыма над и под фальшполом, круглосуточное видеонаблюдение, доступ по картам и отпечаткам пальцев, а также прецизионное кондиционирование с резервной системой. Это полезные утверждения, потому что они обозначают пути отказа, о которых, как знает компания, клиенты будут спрашивать: отказ основной инфраструктуры, обрыв оптоволокна, перебой питания, пожар и охлаждение.

Сторонние справочники объектов поддерживают существование нескольких площадок ISC, внося при этом шум по ёмкости, который покупатели не должны игнорировать.Страница компании ISC на Baxtelописывает ISC как оператора двух дата-центров в одном регионе и указывает 6 МВт, тогда как еёстраница ISC Towerописывает площадку MPR как дата-центр уровня Tier IV в Южной Джакарте с 550 стойками и заявляет истинную резервированность двойного пути 2N ИБП, дизельные генераторы и поддержку IPv4/IPv6.Datacenters.comперечисляет три объекта ISC в Индонезии, а еёстраница MPRсообщает о 6 500 квадратных футах, 1 791 квадратном футе фальшпола и 16,0 МВт мощности. Эти цифры не сходятся с собственным заголовком ISC в 5 МВт или рыночным сигналом в стиле LinkedIn, описывающим до 8 МВт ИТ-нагрузки. Расхождение не является доказательством искажения; сторонние справочники могут отставать, оценивать или смешивать мощность здания с ИТ-нагрузкой. Однако именно поэтому клиентам следует запрашивать датированный график ёмкости.

Полезный вывод в том, что ISC не следует сводить к одному активу. CBR, MPR и Bali DRC предстают как отдельные части публичной истории. Риск в том, что публичные страницы размывают их операционные границы. Какие стойки находятся в Cyber 1? Какие облачные пакеты предоставляются из MPR? Какие нагрузки действительно могут переключаться на Бали? Доступны ли рекламируемые подключения к точкам обмена в каждой комнате или только через более широкую сеть ISC?

Если клиент покупает услугу «Tier IV», находится ли каждая зависимость в пути услуги внутри этого объёма Tier IV или порталы управления, системы поддержки, вышестоящие каналы, биллинг и репозитории резервных копий находятся в других комнатах? Эти вопросы определяют пригодную к использованию устойчивость.

Заявленной ёмкости нужен коэффициент пересчёта

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

Собственная страница MPR помогает проиллюстрировать проблему пересчёта. Предложение полной стойки включает источник питания 10A, выделение публичных IP-адресов /29, мониторинг трафика, услугу smart-hands, два порта UTP и два оптоволоконных ядра. Это практичный пакет для корпоративной колокации, но он не равен утверждению, что каждая из 550 стоек может непрерывно потреблять 10A, что все стойки имеют одинаковую плотность мощности или что охлаждения и вышестоящей пропускной способности достаточно для работы каждой стойки при современных нагрузках ИИ или плотного хранения.

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

Та же осторожность относится к облачным пакетам. Страницы MPR и CBR рекламируют «Cloud Business» и «Cloud Enterprise» с показателями уровня обслуживания 99,9%, ограничениями памяти и хранилища, одним публичным IP-адресом, одной ОС Linux, формулировками о порте 1 Гбит/с и до 30 Мбит/с международной пропускной способности. Эти условия выглядят скромнее, чем предложения стоек, и могут быть нацелены на обычные бизнес-нагрузки, а не на крупномасштабные вычисления.

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

На текущем рынке дата-центров мощность — самый важный коэффициент пересчёта.Отчёт МЭА «Энергия и ИИ»прогнозирует, что потребление электроэнергии дата-центрами будет расти значительно быстрее общего спроса на электроэнергию до 2030 года. Давление глобально, но проявляется локально: каждому зданию нужны подключение к сети, распределительное устройство, ёмкость ИБП, ёмкость охлаждения, поддержка генераторов, топливная логистика и разрешение на расширение. Заголовок ISC о 5 МВт для MPR значим в этом контексте, но недостаточен. Клиентам нужно знать, является ли это число ёмкостью сети, ёмкостью здания, ИТ-нагрузкой, будущей проектной ёмкостью или текущей продаваемой зафиксированной ёмкостью после вычета существующих клиентов, резервных запасов и запаса на обслуживание.

ISC могла бы устранить большую часть неопределённости скучным раскрытием: общая ёмкость вводов электросети, зафиксированная ИТ-нагрузка, доступная продаваемая нагрузка, средняя и максимальная плотность стойки, топология ИБП, время работы генераторов на топливе, контракты на дозаправку, конструкция байпаса обслуживания, резервирование охлаждения и допущения, стоящие за показателем 99,995% для MPR. Публичные страницы в нескольких местах рекламируют питание от двух источников и резервные генераторы. Это отправная точка.

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

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

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

Сетевые доказательства живые, но не широкие

AS142379 — это маршрутный якорь для записи в справочнике.APNIC RDAP для AS142379называет автономную систему «ISC-DC-AS-ID» и указывает контекст держателя как PT. INDONESIA SUPER CORRIDOR - Дата-центр в Индонезии. Данные административного и технического контактов указывают на адрес электронной почты ISC, а контакт по abuse использует адрес hostmaster ISC в здании Cyber Building. Это сильное доказательство идентичности в реестре.

Картина IP-ресурсов показывает границу группы CNI.APNIC RDAP для 103.91.24.0указывает блок 103.91.24.0 - 103.91.27.255 как CNI-ID, выделенное переносимое адресное пространство для PT Cyber Network Indonesia, интернет-провайдера в Джакарте.APNIC RDAP для 123.253.248.0аналогично указывает 123.253.248.0 - 123.253.251.255 как CNI-ID. Это не ослабляет операционную позицию ISC, поскольку публичные и сторонние записи ISC неоднократно помещают её в контекст CNI Group. Это значит, что клиентам следует понимать, какое юридическое и операционное лицо контролирует адресное пространство, объект, точку обмена и клиентский контракт.

Обзор AS в RIPEstatна 12 июля 2026 года сообщал, что AS142379 анонсируется, и называл держателя ISC-DC-AS-ID - PT. INDONESIA SUPER CORRIDOR - Дата-центр.Конечная точка announced-prefixes RIPEstatпоказывала шесть текущих префиксов IPv4 /24: 103.91.24.0/24, 103.91.25.0/24, 103.91.26.0/24, 103.91.27.0/24, 123.253.248.0/24 и 123.253.249.0/24.Данные routing-status RIPEstatпоказывали, что все 325 из 325 пиров RIS IPv4 видели набор маршрутов в момент запроса, 1 536 анонсированных адресов IPv4 и отсутствие видимых для RIS текущих анонсов IPv6.

Это хорошее доказательство достижимости, но не полная история разнообразия.Данные ASN-neighbours RIPEstatпоказывали одного наблюдаемого соседа: AS38496.APNIC RDAP для AS38496идентифицирует эту AS как CNI-AS-ID для PT Cyber Network Indonesia. Это выглядит как внутренние или смежные с группой отношения апстрима/агрегации, а не как доказательство того, что у AS142379 есть несколько независимых внешних апстримов, видимых в глобальном BGP. Если клиенту объекта нужна диверсификация операторов, вопрос не в том, «маршрутизирует ли ISC адреса?». Вопрос в том, «сколько физических путей входа, кросс-коннектов операторов и политик апстрима может реально использовать моя услуга?».

Безопасность маршрутов — более светлая точка.Проверка RPKI для 103.91.24.0/24ипроверка RPKI для 123.253.248.0/24в RIPEstat на момент запроса вернули статус valid для AS142379. Действительность RPKI не предотвращает сбои и не доказывает разнообразие объектов, но это реальный сигнал гигиены маршрутизации. Она снижает один класс риска неверного указания источника и показывает, что адресная среда CNI/ISC не является полностью заброшенной поверхностью маршрутизации.

IPv6 — более слабый сигнал. Baxtel описывает ISC Tower как полностью поддерживающую IPv4 и IPv6, а ISCX рекламирует пиринг IPv4 и IPv6. Но текущий вид AS142379 в RIPEstat не показывал видимых префиксов IPv6 на момент запроса. Это может означать, что IPv6 предоставляется через другие ASN, через LAN точек обмена, через сети клиентов или в настоящее время не originates из AS142379. Для покупателей практический вывод прост: не предполагайте dual-stack услугу по маркетинговым формулировкам.

Спросите, какой ASN originates клиентский IPv6, входят ли облачные пакеты IPv6, покрывает ли их RPKI, и имеют ли пути IPv6 те же мониторинг и поддержку, что и IPv4.

ISCX стратегически полезна, но не доказывает каждый путь клиента

История точки обмена ISC — реальный актив.Сайт ISCXописывает «Connectivity Internet Exchange Point with Tier IV Дата-центр Support in Indonesia» и перечисляет доступ IXP Manager, статус трафика, обновления MAC-адресов и IRR-фильтров, панели мониторинга, поддержку route-server, looking glass, BGP-сообщества, IRR-фильтрацию и RPKI.Страница ISCX в PeeringDBперечисляет точку обмена ISCX Internet Exchange под PT. Indonesia Super Corridor в Джакарте, с веб-сайтомhttp://iscx.isc.id, полями технического контакта и отметкой обновления от июня 2025 года.Страница организации PT. Indonesia Super Corridor в PeeringDBдаёт контекст адреса Cyber 1 и идентифицирует организацию за записями, обращёнными к точке обмена.

Для оператора дата-центра точка обмена может значить не меньше, чем сырой транзит. Она может снижать внутреннюю задержку, удерживать трафик локальным, привлекать контент и сети доступа и создавать коммерческую причину для операторов поддерживать присутствие в здании. Страницы ISC неоднократно упоминают IIX, OIXP и Equinix IX в пакетах услуг. Её облачные предложения заявляют доступ 1 Гбит/с к IIX, OIXP и Equinix IX, а страницы колокации упаковывают пропускную способность IIX и IX в планы стоек. Эти утверждения соответствуют объекту, который продаёт не только пространство и мощность, но и близость к индонезийской межсетевой связности.

Осторожность в том, что присутствие точки обмена и резервирование клиента — разные вещи. Route-сервер, IXP Manager и looking glass помогают участникам управлять пирингом. Сами по себе они не доказывают, что у клиента колокации есть два оптоволоконных входа, две комнаты встречи операторов, два контракта с апстримами, изолированные пути внутри здания или проверенное переключение с одного оператора на другой. Точка обмена может быть как точкой концентрации, так и инструментом устойчивости.

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

PeeringDB также создаёт интересное разделение. ISCX и организация PT. Indonesia Super Corridor видимы, и в PeeringDB есть сетевая страница для AS136825, связанного профиля Indonesia Super Corridor с объектами межсоединений, включая CNI/ISC DC CBR, CNI DC MPR и CNI DC DPS. Но прямой запрос API PeeringDB для AS142379 на момент проверки не вернул сетевого профиля AS142379. Это отсутствие само по себе не проблема; многие операторы объектов разделяют ASN объекта, точки обмена и услуг. Это значит, что клиентам следует спрашивать, какой AS, какая фабрика точки обмена и какой физический порт использует их конкретная услуга.

Самый сильный вопрос покупателя топологический: «Нарисуйте путь». Для полной стойки в MPR покажите путь от электросети к ИБП к стойке, охлаждение к стойке, кросс-коннект к комнате встречи операторов, оператора к апстриму, порт точки обмена к route-серверу и резервную сеть к DRC, если применимо. Для облачной ВМ покажите гипервизор, хранилище, коммутатор top-of-rack, агрегацию, файрвол, транзит, пиринг, резервное копирование и портал управления. Для клиента аварийного восстановления покажите основной объект, путь репликации, измерение RPO/RTO и цель восстановления. Без такого чертежа ISCX — привлекательный сигнал, но не гарантия.

Собственность и операционная граница всё ещё требуют ясности на уровне контракта

Публичные доказательства ISC неоднократно пересекаются со средой группы CNI. Рассмотренные здесь распределения IP-адресов APNIC назначены PT Cyber Network Indonesia. AS38496, единственный наблюдаемый сосед AS142379 в представлении RIPEstat, — это CNI-AS-ID. Профили PeeringDB помещают PT. Indonesia Super Corridor, ISCX и объекты с брендом CNI в один практический ландшафт межсоединений. Сторонние справочники объектов описывают ISC как часть контекста CNI Group. Эта картина не подозрительна.

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

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

Тот же вопрос применим внутри объекта: управляется ли облачная услуга ISC на оборудовании, принадлежащем ISC, аффилированной структурой CNI, оборудованием клиента в стойке ISC или партнёром, чьё имя не видно на публичной странице продукта?

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

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

Страница аварийного восстановления задаёт правильные вопросы и оставляет сложные ответы открытыми

Страница Bali DRC полезна, потому что явно называет концепции восстановления. Она упоминает RPO, RTO, универсальное восстановление, защиту бизнес-приложений, сжатие, дедупликацию, подключение к нескольким точкам обмена, устойчивое питание, противопожарную защиту, мониторинг и резервное прецизионное кондиционирование. Этот словарь — ровно то, что корпоративные покупатели должны ожидать от поставщика аварийного восстановления. Страница не просто говорит «данные в безопасности»; она определяет время восстановления, точку восстановления, сеть, питание, пожар и охлаждение как компоненты предложения.

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

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

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

Клиентам нужно знать, является ли предложение DRC от ISC резервным копированием и восстановлением, pilot-light, тёплым резервом, active-active или просто колокацией на второй площадке. У каждого шаблона разные стоимость и поведение при сбое.

Это важно, потому что «DRC» на рынке можно перепродать. Второй комнаты с питанием и охлаждением недостаточно. Центр аварийного восстановления нужно тренировать. Клиенту следует спросить дату последнего теста, объём теста, достигнутые RPO и RTO, допущения о сбое, владельца runbook, план staffing, процесс уведомления клиентов и доказательства после теста. Следует спросить, зарезервирована ли ёмкость восстановления или предоставляется по мере возможности. Следует спросить, проходят ли сетевые пути DRC через те же точки концентрации в Джакарте, которые отказали.

Следует спросить, что произойдёт, когда бедствие — это не отказ здания, а киберинцидент, блокировка биллинга, сбой облачного контроллера или случайное удаление.

Публичные материалы DRC от ISC достаточно сильны, чтобы оправдать эти вопросы, но недостаточно сильны, чтобы на них ответить. Компания явно рекламирует концепции, которые имеют значение. У неё есть названный объект на Бали в списке клиентов Uptime и справочниках в стиле Datacenters.com/DatacenterMap. Публично не хватает доказательств восстановления уровня клиента. Это не необычно для колокации, потому что многие детали находятся в предложениях и контрактах. Но это означает, что публичным читателям не следует превращать заголовки «RPO» и «RTO» в уверенность, не запросив измеренные доказательства.

Кто пострадает, если платформа откажет

Затронутые стороны шире, чем арендаторы стоек. Традиционный клиент колокации может потерять доступ к размещённому оборудованию, если откажут питание, охлаждение, контроль доступа или smart-hands. Облачный клиент может потерять вычисления, хранилище, публичный IP-сервис или доступ к управлению, если откажет виртуальная инфраструктура, управляемая ISC. Участник точки обмена может потерять пиринг или видимость управления локальным трафиком, если откажут ISCX или поддерживающие её объектные службы.

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

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

Вторая затронутая группа — небольшие сети и контент-провайдеры, которые могут использовать ISCX или размещённую в ISC инфраструктуру для пиринга. Если откажут route-сервер, коммутационная фабрика или домен питания объекта, локальный трафик может быть перенаправлен на более длинные пути или отказать для сетей без резервного пиринга. Если откажут портал IXP или система мониторинга, участники могут потерять операционную видимость, даже если пересылка пакетов продолжится.

Публичные материалы ISCX рекламируют панели мониторинга и функции route-сервера; клиентам следует спросить, являются ли эти системы внеполосными, резервированными и управляются ли они независимо от фабрики точки обмена, которую они мониторят.

Третья затронутая группа — клиенты, покупающие облако, а не пространство. Облачные покупатели часто имеют меньше видимости в то, где находятся их нагрузки. Они могут видеть план ВМ, память, хранилище, публичный IP-адрес и пакет пропускной способности, но не кластер хостов, репликацию хранилища, политику обслуживания гипервизора, расписание резервного копирования или путь эскалации поддержки. Если облачные услуги ISC построены на компактном пуле ресурсов, практический риск — конкуренция шумных соседей, обслуживание хостов, сбой хранилища, ограниченная международная пропускная способность или медленная поддержка во время инцидента на объекте.

Публичные планы полезны для ценообразования и объёма; их недостаточно для промышленной архитектуры.

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

Пути отказа, которые нужно тестировать, обыденны и неумолимы

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

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

Второй путь отказа — охлаждение. Страница DRC упоминает прецизионное кондиционирование с резервной системой, а страницы обслуживания ссылаются на работы по системе охлаждения. Это хорошее начало. Риск в том, что ограничения охлаждения и мощности взаимодействуют. Стойка может быть продана с 10A, но плотное оборудование может создавать горячие точки, и резервирование охлаждения должно поддерживать фактическую нагрузку, а не среднюю.

Клиентам следует запросить детали изоляции холодного/горячего коридора, диапазоны температуры и влажности, резервирование блоков охлаждения, конструкцию чиллера или DX, историю обслуживания и сигналы тревоги, видимые через DCIM.

Третий путь отказа — прерывание в точке встречи операторов. Публичные материалы ISC рекламируют кросс-коннекты, пропускную способность IIX/IX, ISCX, route-серверы, OIXP, Equinix IX и формулировки о нескольких точках обмена. Представление BGP для AS142379 всё ещё показывает одного наблюдаемого соседа, AS38496, и отсутствие текущего маршрута IPv6 из этой AS. Это не противоречит истории точки обмена, но означает, что публичные доказательства на уровне AS не показывают широкого разнообразия транзита.

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

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

Дата-центр может иметь хорошие средства контроля и всё равно быть подвержен обычным зависимостям здания.

Пятый путь отказа — строительное или ёмкостное несоответствие. Публичные записи содержат несколько чисел ёмкости: заголовок ISC о 5 МВт для MPR, маркер Baxtel о 6 МВт для компании, цифра Datacenters.com в 16,0 МВт для MPR и другие рыночные отсылки к ИТ-нагрузке до 8 МВт. Существование разных чисел само по себе не тревожно, но это предупреждение против покупки по числу со слайда. Клиентам следует спросить, какое число актуально, является ли оно ёмкостью электросети, валовой, критической, ИТ или планируемой, и резервирует ли их контракт ёмкость или лишь даёт доступ к ней, пока она доступна.

Шестой путь отказа — административный. Учётные записи DCIM, клиентские порталы, службы поддержки, системы биллинга и права доступа — часть инфраструктуры. Если портал недоступен, клиент может не иметь возможности мониторить трафик, открыть заявку, выделить облачную ёмкость, скорректировать сетевые фильтры или убедиться, что событие обслуживания запланировано. ISCX рекламирует IXP Manager и панели мониторинга. ISC рекламирует клиентские учётные записи DCIM. Покупателям следует относиться к этим системам как к операционным зависимостям и спрашивать, как они резервируются, мониторятся и поддерживаются.

Что изменило бы оценку

ISC может улучшить публичную оценку риска без публикации чувствительных данных клиентов. Помогла бы короткая сетевая страница: ASN, используемые для услуг объекта, облака и точки обмена; текущие префиксы IPv4 и IPv6; апстримы/транзитные провайдеры; фабрики точек обмена; политика route-сервера; статус RPKI; ссылки на looking glass; записи PeeringDB; контакты abuse и NOC; а также каналы уведомлений об обслуживании. У компании уже достаточно публичных материалов для поддержки такой страницы. Консолидация снизила бы неопределённость.

Ещё больше помогла бы страница ёмкости объекта. Она должна различать CBR, MPR и Bali DRC; перечислять проектный уровень и объём награды; указывать валовую мощность, зафиксированную ИТ-нагрузку и доступную продаваемую нагрузку; объяснять диапазоны плотности стоек; идентифицировать допущения по вводам электросети и генераторам; раскрывать резервирование охлаждения; и объяснять, работают ли облачные услуги на одной или нескольких площадках. Не нужно раскрывать отдельных клиентов. Нужно сделать заявленную ёмкость проверяемой.

Ещё более ценной была бы страница доказательств восстановления. Она могла бы описать доступные шаблоны аварийного восстановления, опубликовать примерные категории RPO/RTO, объяснить частоту тестов восстановления, перечислить варианты резервного копирования и репликации, указать, зарезервирована ли ёмкость DRC или предоставляется по мере возможности, и предоставить канал статуса или истории инцидентов. Клиентам не нужно совершенство. Им нужно знать, тренировала ли компания отказ, от которого продаёт защиту.

Для уверенности в сети AS142379 должна показывать более широкое публичное разнообразие, если она предназначена для прямого обслуживания промышленных клиентов. Несколько видимых апстримов, сетевой профиль AS142379 в PeeringDB, текущий пригодный для клиентов IPv6, чистое покрытие RPKI по всем видимым префиксам и публичный looking glass — всё это повысило бы уверенность. Если AS142379 — лишь внутренний или специфичный для объекта ASN, тогда как клиентское разнообразие находится под AS136825, AS38496 или другими ASN CNI/ISC, ISC должна сказать об этом прямо.

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

Для уверенности при закупках ISC следует выровнять рыночные заявления о ёмкости. Покупатель, видящий 5 МВт, 6 МВт, 8 МВт и 16 МВт в разных публичных местах, не может знать, какая цифра определяющая. Ответ может быть простым: мощность площадки, ИТ-нагрузка, запланированное расширение, ёмкость здания или ошибка справочника. Но публичное расхождение создаёт трение. При закупках дата-центра чистое заявление о ёмкости не косметика; оно определяет, сможет ли клиент зарезервировать пространство и мощность на три-пять лет.

Операционная оценка

PT. INDONESIA SUPER CORRIDOR - Дата-центр получает среднюю оценку по сетевым и операционным доказательствам с сильной составляющей существования объекта. Сильная часть заслужена: у ISC есть официальные страницы объектов, названные активы CBR/MPR/Bali, записи о выданных наградах Uptime Institute, публичные предложения стоек и облака, поверхность точки обмена ISCX, идентичность AS в APNIC, текущая видимость IPv4 в RIPEstat и действительный RPKI на выборочных видимых префиксах. Это намного лучше спящей оболочки или непроверенного хостингового бренда.

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

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

В дата-центрах разница между «доступными стойками» и «выживаемой ёмкостью» — это место, где живёт реальный риск.