Важно: обязательная идентификация владельцев доменов .RU, .РФ и .SU через Госуслуги



Информируем вас о важных изменениях в правилах регистрации и обслуживания доменных имен в зонах .RU,.РФ и .SU.

С 1 сентября 2026 года вступают в силу новые требования законодательства Российской Федерации, согласно которым для управления доменами в указанных зонах администраторам необходимо пройти обязательную идентификацию через портал Госуслуги (ЕСИА) с использованием подтвержденной учетной записи. Данное требование распространяется на физических лиц, индивидуальных предпринимателей и юридические лица.

Что необходимо сделать?
Для физических лиц и индивидуальных предпринимателей (резидентов РФ)
Если вы уже являетесь нашим клиентом и владеете доменами в зонах .RU,.РФ или .SU, пройти идентификацию через Госуслуги (ЕСИА) можно уже сейчас.

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

Для юридических лиц (резидентов РФ)
Перед прохождением идентификации рекомендуем выполнить предварительную проверку:
  • убедиться, что организация зарегистрирована в Госуслугах (ЕСИА);
  • проверить, что сотрудник, ответственный за управление доменными именами, добавлен к учетной записи организации и обладает необходимыми полномочиями.
После этого необходимо обратиться в отдел сопровождения клиентов через тикет-систему личного кабинета. Специалисты предоставят вам индивидуальную ссылку для прохождения процедуры идентификации через ЕСИА.

my.adminvps.ru/knowledgebase/562/

Схема сети: новая возможность в DCImanager

Карта подключений строится на основе данных о подключениях из карточек оборудования. Администратор может переключаться между разными слоями отображения. Например, проверить оборудование в определенном VLAN, просмотреть общую топологию связности коммутаторов или вывести только управляющие подключения BMC либо PDU.



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

Контроль сетевой связности и точное планирование
Главное преимущество новой функции — наглядное представление состояния всех сетевых соединений. Если раньше DCImanager позволял отслеживать здоровье серверов и температурные показатели стоек и ЦОД, то теперь администраторам доступна сводка по статусам линков.





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

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

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



www.ispsystem.ru/docs/dcimanager-admin/moduli/modul-shema-seti

Как VMmanager ускорил развертывание новых сервисов на 40%



ТАГРАС — нефтесервисный холдинг со штаб-квартирой в Альметьевске (Республика Татарстан), который предоставляет услуги не только ведущим предприятиям нефтегазовой отрасли, но и представителям смежных сфер.

ТАГРАС работает на рынке с 2006 года и на данный момент обслуживает более 1500 заказчиков. В структуру холдинга входит более 50 предприятий, разделенных на восемь дивизионов — каждый закрывает свою отрасль для диверсификации рисков:
  • Система-Сервис — производство, прокат и ремонт нефтепогружного оборудования;
  • ТАГРАС-РС — внутрискважинные работы по ремонту, ГРП и ПНП;
  • ТаграС-ЭнергоСервис — строительные и ремонтные работы в энергетическом комплексе и промышленном строительстве;
  • ТМС групп — машиностроение и сервис нефтепромыслового и бурового оборудования;
  • ТаграС-ТрансСервис — грузопассажирские перевозки и логистика;
  • Геофизический дивизион — исследования и сейсморазведка;
  • БС-Платформа — информационная безопасность и цифровая трансформация предприятий, сервисная поддержка систем;
  • ТАТНЕФТЕДОР — строительство и обслуживание автомобильных дорог.
В общей сложности в компаниях холдинга работает порядка 15 000 человек.

Исходные данные
С 2019 года ТАГРАС находится на пути цифровой трансформации. После ревизии бизнес-процессов в 2020–2025 годах проходила информатизация всех дивизионов холдинга. Параллельно с 2022 года для минимизации санкционных рисков началась замена импортного ПО на отечественные аналоги в соответствии с подпрограммой «Цифровой суверенитет» TAGRAS-Digital.

Поставленную задачу решает ИТ-дивизион компании — БС-Платформа. В общей сложности этот дивизион обслуживает 7000 пользователей и более 100 различных информационных систем в ИТ-инфраструктуре компаний холдинга.

Цели и задачи
В рамках программы «Цифровой суверенитет» необходимо было:
  • Повысить независимость от иностранного ПО, перейдя на отечественное решение с необходимым функционалом.
  • Обеспечить уровень безопасности данных, соответствующий последним отраслевым стандартам.
  • Заложить основу для будущего масштабирования, то есть для развертывания новых проектов в рамках ИТ-инфраструктуры холдинга, для которых еще нет явного ТЗ.

Решение, которое используется в проекте
Для решения поставленных задач в 2023 году специалисты БС-Платформы взяли курс на отказ от зарубежных облаков и перенос сервисов холдинга ТАГРАС в частный программно-аппаратный комплекс. Для этого на базе платформы виртуализации VMmanager был создан ПАК «Частное облако», который объединяет ресурсы четырех дивизионов: Таграс-РС, БС-Платформа, Таграс-ТрансСервис и Татнефтедор.

VMmanager был выбран по итогам строгого сравнительного тестирования близкого по функционалу конкурирующего отечественного решения по более чем 70 параметрам и функциям.

На фоне конкурента продукт VMmanager выделялся важными для внедрения преимуществами:
  • Простая и быстрая установка через скрипт, не требующая глубоких знаний Linux;
  • Широкий спектр способов развертывания виртуальных машин;
  • Доступ к обновлениям без дополнительной авторизации, менеджер установки с графическим интерфейсом (все в рамках лицензии), а также возможность установки обновлений без остановки трафика, то есть вне сервисных окон;
  • Интеграция с биллингом, которая позволяет легко заказывать дополнительные услуги или отказываться от неиспользуемых.

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

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

Для развертывания использовалась v2025.08.2–1 платформы управления инфраструктурой, на которой была запущена 141 виртуальная машина, 64 из них — под управлением Astra Linux 1.7.5 и 1.8.1. В качестве СУБД для поддержки продуктовых сред 1С задействовали Тантор и PostgreSQL.

Особенности решения, используемого в проекте
Решение поддержит новые проекты, которые инициируются в холдинге ТАГРАС, обеспечив тем самым гибкость: импортозамещение корпоративной почты, миграцию системы электронного документооборота из коммерческих облачных ресурсов в ПАК «Частное облако» и другие общехолдинговые проекты.

Результаты
После внедрения ПАК «Частное облако» обеспечивает поддержку корпоративной почты на 4500 пользователей, электронного документооборота всех дивизионов холдинга, а также продуктового контура 1С четырех дивизионов.

В боевых условиях заказчик провел сравнительное нагрузочное тестирование производительности двух платформ. Результаты показали превосходство VMmanager.

Ключевые результаты ПМИ:
  • VMmanager набрал максимальные баллы в 90% категорий.
  • Преимущество в важных аспектах: документация, простота установки, интеграция с биллингом.
  • Экономия времени: установка и администрирование проще на 40–50%.

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

Внедрение отечественного решения повысило безопасность данных. Теперь она соответствует ведущим отраслевым стандартам и требованиям регулятора.

Ускорили развертывание новых сервисов: скорость развертывания сократилась на 40%, а в целом ТСО — на 20–30%.

Мнение заказчика
В рамках программы цифрового суверенитета мы провели глубокую ревизию инфраструктуры и приняли решение организовать ПАК «Частное облако» на отечественном продукте виртуализации VMmanager.

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

Сегодня уверенно смотрим в будущее: платформа дает нам фундамент для масштабирования в любых направлениях — от импортозамещения почтовой системы до реализации новых амбициозных задач.

Дмитрий Александрович Нефёдов
первый заместитель директора по информационным технологиям, главный инженер ООО «Про-Ресурс»

Как авиакомпании построить отказоустойчивую виртуальную инфраструктуру с VMmanager



«КрасАвиа» — российская региональная авиакомпания. Базируется в Красноярском крае, осуществляет регулярные перевозки как внутри края, так и в соседние регионы, а также выполняет международные рейсы в Монголию. В общей сложности более 30 направлений на регулярной основе, включая районы Крайнего Севера.
www.krasavia.ru

Помимо пассажирских перевозок «КрасАвиа» доставляет почту, продовольствие, лекарства и другие жизненно необходимые грузы в районы Крайнего Севера, а также выполняет санитарные рейсы для оказания экстренной медицинской помощи, в том числе в труднодоступных территориях; осуществляет полеты в рамках деятельности лесопожарного центра; участвует в поисково‑спасательных операциях.

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

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

«КрасАвиа» приняла решение перейти на отечественную платформу виртуализации.

Задачи проекта
В авиационной отрасли к ИТ-инфраструктуре предъявляются повышенные требования по надежности и безопасности: даже кратковременные сбои могут влиять на критичные операционные процессы.

«КрасАвиа» требовалось развернуть стабильную и производительную платформу виртуализации с учетом имеющихся ИТ-ресурсов.

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

Почему выбрали VMmanager
Для компании, которая одновременно выполняет пассажирские, грузовые, санитарные и вахтовые перевозки, важно, чтобы ИТ-инфраструктура могла развиваться вместе с бизнесом. После анализа доступных отечественных решений компания остановила выбор на VMmanager.

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

VMmanager — инструмент для создания отказоустойчивой виртуальной среды, а также для централизованного управления аппаратной и контейнерной виртуализацией.
Дополнительные критерии выбора VMmanager:
  • Российская разработка
  • Работа с отечественным решением без зависимости от зарубежных поставщиков, а также вхождение в реестр отечественного ПО.
  • Отказоустойчивость
  • Возможности кластеризации и построения отказоустойчивой инфраструктуры обеспечивают стабильную работу корпоративных сервисов.
  • Единый интерфейс
  • Вся работа выполняется в рамках единого контура, что обеспечивает централизованное управление ИТ-инфраструктурой.

Этапы внедрения
Проект начался с развертывания тестового демостенда, который специалисты «КрасАвиа» и ISPsystem реализовали совместно.

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

Пилотирование проекта продолжалось шесть месяцев. За это время платформа VMmanager показала стабильную работу и полностью подтвердила соответствие требованиям заказчика. В результате тестовая среда была переведена в промышленную эксплуатацию.

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

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

Благодаря переходу на платформу VMmanager авиакомпании удалось сохранить высокий уровень надежности ИТ-сервисов и обеспечить устойчивую работу инфраструктуры для ежедневной деятельности предприятия.

Мнение заказчика
Отмечу высокую производительность платформы, удобную консоль управления и быструю работу консоли виртуальных машин. Виртуальные машины работают стабильно и быстро. Мы не используем какие‑то специфические функции: VMmanager для нас прежде всего надежная платформа виртуализации.
Сергей Алексеевич Баёв
Начальник отдела по инфраструктуре и телекоммуникационным системам

Как банку снизить затраты на инфраструктуру и повысить безопасность с VMmanager


alefbank.ru

АО АКБ «Алеф-Банк» — универсальный банк, предоставляющий как традиционные банковские продукты, так и услуги с использованием цифровизации. Это финансовая организация с развитой ИТ-инфраструктурой и собственным ИТ-департаментом.

В ДИТ банка сформировалось два управления: одно занимается интеграцией банковских информационных систем, другое выполняет функции технической поддержки, эксплуатации, настройки, закупки оборудования, а также сопровождения прикладного ПО.

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

Контекст и исходная инфраструктура
До внедрения VMmanager компания использовала зарубежное ПО в качестве основной платформы виртуализации — и сейчас продолжает частично эксплуатировать продукт. Также в рамках импортозамещения на протяжении двух лет применялось решение на базе платформы виртуализации с открытым исходным кодом.

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

Задачи проекта
В рамках проекта перед командой банка стояли задачи, связанные с поддержанием и миграцией инфраструктуры на новое решение:
  • Импортозамещение. Поиск отечественного продукта в условиях новых требований и ограничений.
  • Оптимизация затрат. Поиск оптимального баланса между стоимостью владения новой платформой и её возможностями.
  • Безопасность. Использование решений, подходящих для работы в регулируемой среде, включая наличие сертификата ФСТЭК.
  • Развитие виртуальной инфраструктуры. Формирование устойчивой среды для запуска новых проектов банка.

Почему выбрали VMmanager
При выборе платформы команда ориентировалась на практические сценарии эксплуатации и модели лицензирования.

VMmanager — инструмент для создания отказоустойчивой виртуальной среды, а также для централизованного управления аппаратной и контейнерной виртуализацией.
Основные факторы выбора VMmanager от ISPsystem:
  • Экономическая эффективность
  • VMmanager обеспечил более предсказуемую стоимость владения по сравнению с альтернативами при сопоставимом наборе функций и предоставил гибкие варианты лицензирования.
  • Стабильность работы
  • В процессе эксплуатации команда отметила более стабильную работу системы — в процессе миграции на VMmanager не возникало сетевых проблем, что повысило стабильность операций.
  • Наличие сертификата ФСТЭК
  • Сертификат ФСТЭК стал одним из ключевых факторов при выборе решения для использования в банковской инфраструктуре.

Реализация проекта и планы
ИТ-среда банка — это критичная система, где любые изменения инфраструктуры напрямую влияют на доступность сервисов и бизнес-процессы. Поэтому переход на VMmanager выполняется поэтапно и вдумчиво: с предварительным тестированием и последовательным переносом сервисов без остановки ключевых систем.

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

Проект находится в активной фазе, и заказчик уже отмечает ряд эффектов:
  • Повышение стабильности инфраструктуры. По словам команды, инфраструктура стала более стабильной и меньше требует постоянного контроля. Также снизилось количество инцидентов при операционных задачах.
  • Удобство эксплуатации. Дополнительно отмечаются быстрый отклик и качественная обратная связь, что особенно важно на этапе внедрения.
В результате банк получил платформу, которая сочетает экономическую эффективность и соответствие требованиям регуляторов в условиях критичной ИТ-среды.

В планах заказчика — поэтапное расширение использования VMmanager и увеличение количества лицензий по мере роста инфраструктуры и задач проекта.

Мнение заказчика
Внедрение VMmanager стало для нас важным шагом в развитии цифровой инфраструктуры и импортозамещении в линейке программных продуктов банка. У нас появилась возможность удобно управлять виртуальными ресурсами и оперативно администрировать банковские информационные системы. Но главное мы получили надёжную, безопасную и аттестованную среду виртуализации, которая соответствует требованиям законодательства в сфере информационной безопасности.
Павел Дулле
Директор департамента информационных технологий АО АКБ «Алеф-Банк»

www.ispsystem.ru/vmmanager

В наличии выделенный сервер на AMD Ryzen 7 7700 (16 ядер) в Германии и Финляндии



Прямо сейчас в наличии выгодные конфигурации серверов на 16 ядерном процессоре AMD Ryzen 7 7700 (до 5.3 GHz ) и 64 GB в Европе (Германия, Финляндия).

Процессор AMD Ryzen 7 7700 оснащен встроенной графикой AMD Radeon Graphics. Она базируется на архитектуре RDNA 2 и имеет 2 вычислительных блока (128 ядер) с частотой до 2200 МГц.

  • Устанавливаем Windows Server 2019,2022,2025, Windows 10 Pro, Linux
  • Панель управления сервером
  • Безлимитный канал 1 Gbps
  • Защита от DDoS

Что может встроенная графика Ryzen 7 7700

  • Вывод изображения / диагностика
  • Для установки ОС, rescue, KVM/IPMI, базовой графической консоли.
  • RDP / VNC / лёгкий GUI
  • Windows/Linux с графическим интерфейсом, браузер, офисные задачи, панели управления.
  • Видео-сервер
  • Plex/Jellyfin/FFmpeg с аппаратным ускорением видео: H.264/H.265 encode/decode, AV1 decode — при нормальных драйверах и поддержке софта.
  • Лёгкая 2D/3D-графика
  • Простые приложения, браузерная графика, несложные визуальные задачи.


Конфигурации и аренда сервера abcd.host/hetzner-dedicated-servers
По вопросам пишите в личный кабинет my.abcd.host или Telegram: @ABCDSupportBot

Спасибо, что остаетесь с нами!
ABCD.HOST

Рассказываем что произошло в NL/DE





Рассказываем что произошло в NL/DE или «приключение на 20 минут, вошли и вышли».
  • 2 июня: с разницей в 30 минут отключаются локации. Никакой ясности нет, явно что-то не так;
  • К вечеру получаем сообщение, что датацентр nLighten по собственной инициативе обесточил всё оборудование и заблокировал доступ к серверным шкафам. Деталей очень мало;
  • Деталей по-прежнему очень мало. Спустя несколько дней получаем сообщение, что процесс сдвинулся с мертвой точки, планируют назначение даты выгрузки оборудования;
  • С 15 июня происходит выгрузка, миграция в другой датацентр;
  • Сотрудники нового поставщика, к которому мы перевезли оборудование, не были готовы к проведению большого количества работ, что вызвало длительную задержку. В связи с этим было принято решение экстренно ехать сначала во Франкфурт-на-Майне, а затем и в Нидерланды для завершения работ своими силами.
20ого числа прибыли в Нидерланды, забрали нужные компоненты со склада и прямой дорогой отправились во Франкфурт. Дорога заняла примерно 5 часов на машине с минимальными остановками. В ночь с 20 на 21 июня запустили все сервисы в Германии как и обещали.
  • Обратный маршрут был в Нидерланды. Согласовали пропуск в датацентр, подготовили все необходимое и также оперативно завершили работы с выявлением сломавшихся компонентов из-за резкого выключения питания и последующим запуском всех вычислительных узлов.
  • Более 10 часов перелетов, 1500 километров дороги для финального решения всего инцидента.
Что стало причиной: доподлинно неизвестно, предварительно это беспрецедентное решение руководства сети датацентров nLighten на фоне заявлений журналистов про компанию Mirhosting, которая занимается сопровождением IT-инфраструктуры. К слову, Mirhosting на всем протяжении безупречно выполняли поставленные задачи и отличались высокими компетенциями. Сложно назвать произошедшее чем-то кроме поспешно сделанных решений, которые повлекли за собой последствия.
  • Потери данных? Все данные за исключением одного гипервизора в полной сохранности. По нему все ещё ведется работа.
  • Компенсации: начислено 22 дня + 1 полный месяц для всех услуг Германии и 25 дней + 1 полный месяц для всех услуг в Нидерландах.
  • Выводы из всей истории: беспрецедентная непростая ситуация, по которой сложно было принять правильные решения ввиду абсурдности и очень малого количества деталей произошедшего.
Потихоньку будем формировать дополнительные площадки в тех же странах, чтобы дать возможность создать услугу на разных площадках, но в той же стране.

hip.hosting

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



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

ihor.online/vds

Инцидент с охлаждением в дата-центре локации «Амстердам» (Qupra DC2). Постмортем и наши обязательства



Статус на момент публикации (3.07.2026). Все серверы локации «Амстердам» работают в штатном режиме. Дата-центр функционирует на внешнем (резервном) чиллере; работы по восстановлению основной системы охлаждения продолжаются. Мы держим ситуацию под усиленным контролем. Пока основная система охлаждения не восстановлена и не подтверждён резерв, мы считаем ситуацию незакрытой.

Это подробный разбор того, что произошло с локацией «Амстердам» в мае–июле 2026 года, почему это случилось, что мы сделали не так и что делаем дальше. Мы понимаем, что подвели вас, и приносим извинения. Ниже — по существу

Коротко о главном
  • В мае–июле 2026 года в дата-центре нашей локации «Амстердам» (Qupra DC2) произошла серия отказов системы охлаждения. Оборудование уходило в аппаратную защиту от перегрева, из-за чего серверы были недоступны.
  • Первопричина — отказы системы охлаждения на стороне дата-центра. Аномальная жара стала триггером, но не единственной причиной: цепочка инженерных и эксплуатационных отказов на площадке превратила единичный сбой в каскад (подробно — ниже).
  • Данные клиентов сохранены. Аварии касались доступности, а не целостности данных.
  • Компенсация и бонусы для пострадавших клиентов локации «Амстердам»: возврат за фактический простой на баланс (тикет в техподдержку, по SLA) плюс бонусы-промокоды на продление — QUPRA100 (100% на 14 дней) и следом QUPRA15 (15% на 3 месяца). Для уже ушедших клиентов — отдельный порядок. Подробнее — в разделе «Компенсации и бонусы».
  • Мы не рассматриваем гарантии или доработки со стороны Qupra — только переезд локации на новый дата-центр.
  • Повышение цен, о котором вы получили уведомление, — не связано с инцидентом: это совпадение по времени, и мы это учли (см. раздел «О ценах»).

Что произошло
В дата-центре Qupra DC2 (Амстердам), где размещена наша локация «Амстердам», несколько раз выходила из строя система охлаждения. Когда охлаждение останавливается, оборудование в стойках быстро перегревается, и включается защита. Часть её срабатывает автоматически, на уровне железа: процессоры снижают частоты (троттлинг), а при достижении критической температуры сервер аппаратно выключается сам. Часть — управляемо, по нашему решению: чтобы не ронять машины жёстко и сохранить ваши данные, мы штатно и контролируемо выключаем серверы (graceful shutdown), а дата-центр при необходимости обесточивает перегретые стойки со своей стороны. Результат в любом случае один: сервер временно недоступен.

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

Хронология
Ниже — все известные нам эпизоды недоступности локации «Амстердам», связанные с охлаждением. Время указано по МСК.
  • 27.05.2026, 12:33 → 19:42 (≈5 часов). Отказ системы охлаждения: вышел из строя основной чиллер на крыше. Вечером дата-центр привёз и установил резервный чиллер.
  • 26.06.2026, 16:51 → 21:55 (≈5 часов). Снова отказ охлаждения. Инцидент пришёлся на ночь выходного дня. Мы не опубликовали о нём информацию своевременно — это была ошибка (см. раздел «Что мы сделали неправильно»).
  • 29.06.2026, 13:10 → 16:58 (≈4 часа). Очередной отказ охлаждения.
  • 29.06 (поздний вечер) → 01.07.2026, 22:24 — самая длительная авария (≈44 часа). Отказавший чиллер запустить не удалось. Дата-центр организовал доставку и подключение внешнего чиллера, но подключение затянулось из-за отсутствия на площадке нужных силовых кабелей — их привезли только 1 июля. Внешний чиллер подключили около 14:00, серверы начали подниматься примерно с 15:30, восстановление шло поэтапно.
Суммарная недоступность локации за май–июль составила порядка 58 часов. Мы не считаем это приемлемым и не спорим с вашими собственными подсчётами простоя — они верны.

Почему это произошло
Триггером отказов стала аномальная жара в Западной Европе летом 2026 года: система охлаждения площадки не удержала тепловую нагрузку при высокой наружной температуре. Но жара — не единственная причина. За затяжным простоем конца июня стоит цепочка инженерных и эксплуатационных отказов на самой площадке.

Что именно отказало
Приводим восстановленную картину работы инженерных систем дата-центра — по информации, которой мы располагаем.
  • До конца мая охлаждение обеспечивал основной чиллер на крыше здания. 27 мая он вышел из строя.
  • Дата-центр привёз резервный чиллер, разместил его за зданием и запитал от внешнего дизель-генератора, подключив к системе охлаждения. Нам сообщили, что основной (крышный) чиллер также восстановлен.
  • В конце июня внешний дизель-генератор, питавший резервный чиллер, был убран с площадки — и резервный чиллер обесточился.
  • Дата-центр переключился на основной чиллер, но тот, вопреки сообщению о восстановлении, к вечеру отказал окончательно — запустить его не удалось даже с привлечённым сервисным инженером.
  • Оперативно найти замену дизель-генератору не получилось. Для подключения резервного чиллера напрямую к электрощиту площадки пришлось заказывать силовые кабели (около 60 метров), доставка заняла порядка суток. На это время охлаждение держали на фрикулинге, без компрессора.
  • После доставки кабелей резервный чиллер подключили штатно, и охлаждение вышло на рабочий режим. На сегодня локацию охлаждает один исправный чиллер; второй (на крыше) остаётся в восстановлении.
Мы приводим эту цепочку не чтобы переложить вину, а потому что она объясняет наше решение. Критически важный контур охлаждения держался на временном внешнем дизель-генераторе; чиллер, о восстановлении которого нам сообщили, при первой же нагрузке отказал; на площадке не оказалось ни резервного питания, ни готовых кабелей для быстрого ввода резерва. Повторяющиеся отказы, судя по всему, лишь усугубляли износ оборудования, а адекватной реакции площадки мы не увидели. Единичный сбой каскадом обрушил всю локацию. Это не разовое невезение и не только погода — это состояние инженерной инфраструктуры и эксплуатации площадки.

Наша ответственность
Мы не будем прятаться за формулировкой «виноват дата-центр». За питание и охлаждение физически отвечает площадка, а не хостинг-провайдер, — но выбор площадки это наша ответственность. Мы разместили вашу инфраструктуру в Qupra DC2, мы на ней оставались, и перед вами за результат отвечаем мы. Именно поэтому наше решение — уходить с площадки, а не ждать её доработок (см. «Что мы меняем»).

Мы переехали в Qupra DC2 в конце 2025 года, когда прежняя площадка (euNetworks) закрывалась и просила арендаторов освободить помещение. Новый дата-центр оказался не готов держать нашу нагрузку. Это в том числе наш урок по выбору и аудиту площадки.

О слухах: это НЕ история с изъятием серверов
Этим летом в Амстердаме случилось несколько разных инцидентов у разных операторов, и в сети их смешивают. Уточним прямо: наш инцидент — технический, связан только с охлаждением. Он не имеет отношения к истории с принудительным обесточиванием и изъятием серверов у другого оператора в другом дата-центре, которая обсуждалась в те же недели. Ваши серверы никто не изымал и не опечатывал, доступ к ним не блокировался по чьему-либо требованию.

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

Что мы сделали неправильно
Отдельно и без смягчений — о наших собственных ошибках.

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

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

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

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

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

Бонусы (промокоды)
Сверх компенсации — два промокода на продление серверов локации NL (все тарифы). Тикет для них не нужен, они применяются вами самостоятельно в личном кабинете. Действуют только для услуг, заказанных до 1 июля 2026; скидка распространяется и на сам сервер, и на дополнительные услуги.

Промокоды применяются последовательно, именно в таком порядке:
  • QUPRA100 — скидка 100% на 14 дней. Активировать с 3 июля по 3 августа. После активации сервер будет работать две недели бесплатно.
  • QUPRA15 — скидка 15% на 3 месяца. Активировать с 18 июля по 31 августа, после того как отработают 14 дней по QUPRA100.
Важно: сначала QUPRA100, затем QUPRA15. Если активировать 15% раньше, он перебьёт скидку 100%. Все действующие скидки отображаются в личном кабинете в разделе «Скидки». Пошаговая инструкция — здесь.

Если вы уже отказались от услуги из-за инцидента
  • Компенсация — в общем порядке: напишите тикет в техподдержку, мы вернём стоимость простоя на баланс (с последующим выводом на вашу карту или счёт).
  • Бонус — в ручном режиме: напишите тикет в отдел продаж и опишите ситуацию. Мы вручную назначим скидку на новую услугу с аналогичными условиями (100% на 14 дней, далее 15% на 3 месяца).
Стоимость новых услуг не должна превышать стоимость ваших услуг, пострадавших в результате инцидента.

Почему мы не компенсируем упущенную выгоду
Отдельно и честно — о том, что многие ждут, но чего мы сделать не можем.

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

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

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

О ценах
Понимаем, как это выглядит со стороны: сервис падал — а вы получили уведомление о повышении цен. Это совпадение по времени: плановое изменение тарифов готовилось заранее и не связано с инцидентом. Тем не менее момент вышел болезненным, и та же скидка 15% на продление затронутых услуг (см. «Компенсации и бонусы») смягчает для вас это повышение.

Что мы меняем
Площадка. Принято решение уходить из Qupra DC2. Сейчас мы выбираем новый дата-центр. Основной кандидат, которого мы оцениваем, — площадка в Амстердаме уровня Tier 3 с сертификацией управления непрерывностью бизнеса (ISO 22301) и точкой присутствия AMS-IX; параллельно рассматриваем ещё несколько вариантов. Решение принимаем на этой неделе. Конкретную площадку, график переезда и порядок переноса объявим отдельным анонсом. Сам переезд спланируем так, чтобы исключить или свести простой к минимуму и заранее предупредить вас по каждой затронутой услуге. Текущие IP-адреса на услугах будут сохранены.

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

Коммуникация. Мы работаем по принципу, который в этом инциденте показал себя как единственно
  • правильный, — говорить честно и по делу:
  • регулярные апдейты по расписанию во время аварии, с указанием времени следующего обновления;
  • дежурный специалист на связи во время инцидента;
  • никакой цензуры в чатах — мы не удаляем критику, не баним пользователей за неудобные вопросы, модераторы следят только за порядком.
Продажи. Внедряем механизм остановки приёма заказов в проблемной локации на время аварии, чтобы ситуация с «оплатил — не развернулся сразу» не повторилась.

Извинения
Мы подвели вас — и техническим сбоем, и тем, как повели себя в его первые часы. Спасибо тем, кто разбирал ситуацию публично и задавал неудобные вопросы: это помогло нам увидеть свои ошибки без прикрас. Доверие возвращается не заявлениями, а делами, и мы намерены его вернуть.