Рассказываем что произошло в 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

Статус на момент публикации (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-адреса на услугах будут сохранены.

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

Коммуникация. Мы работаем по принципу, который в этом инциденте показал себя как единственно

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

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

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

Вчера (2 июля) один из серверов виртуализации в ЦОД Алматы перестал отвечать, так как произошёл аппаратный отказ процессора AMD EPYC 9655.

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

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

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

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

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

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

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

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

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

Потери клиентских данных не зафиксировано.

Первопричина
Первопричиной инцидента стал аппаратный отказ процессора AMD EPYC 9655.

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

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

Почему первоначально возникла версия о проблеме с дисками
На первом этапе была выдвинута гипотеза о неисправности дисковой подсистемы. Для проверки этой версии диски аварийного узла были перенесены в другой сервер.

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

Позднее было установлено, что причина незагрузки на доноре была не в отказе самих накопителей. Проблема заключалась в повреждении загрузочной логики: загрузочный раздел на RAID1-массиве был поврежден, а GRUB2 находился в неработоспособном состоянии.

Инженер полностью восстановил загрузку: заново настроил GRUB2 и вручную создал EFI-записи в NVRAM материнской платы. После этого узел начал загружать основную операционную систему, однако под нагрузкой виртуализации снова воспроизводилось зависание ОС.

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

Дополнительное диагностическое наблюдение
Во время диагностики был выполнен обратный тест: диски от другого сервера были установлены в неисправную платформу.

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

Поэтому в таком режиме деградация процессора не проявлялась.

Рассмотренные варианты восстановления
Рассматривались два основных сценария восстановления.

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

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

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

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

Стабилизация узла
После восстановления GRUB2 и EFI-записей сервер начал загружать основную операционную систему, но зависал при появлении нагрузки от виртуализации.

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

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

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

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

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


После восстановления интернет-связности миграция была продолжена.

Итог восстановления
После восстановления сети все виртуальные машины и данные были перенесены на соседние узлы кластера.

Потери клиентских данных не произошло.

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

Выводы
Инцидент был вызван нестандартным аппаратным отказом процессора AMD EPYC 9655. Отказ не проявлялся в минимальном rescue-окружении и становился заметен только после запуска полноценной операционной системы под нагрузкой виртуализации.

Диагностику осложнили следующие факторы:

• Повреждение загрузочного раздела RAID1 и неработоспособность GRUB2.
• Необходимость вручную восстанавливать GRUB2 и EFI-записи в NVRAM материнской платы.
• Длительная самодиагностика серверной платформы после каждого зависания и перезагрузки.
• Неочевидный характер отказа процессора, который проявлялся только под нагрузкой KVM.
• Независимое сетевое событие, вызванное незаявленными работами оператора RETN.

Какие меры мы уже предприняли и что ещё планируем сделать:

• Вся хронология событий и симптомы проблемы внесены в нашу внутреннюю базу знаний, чтобы в случае возникновения аналогичной ситуации время на устранение значительно сократилось.
• В ближайшее время мы закончим организацию второго канала с магистральным провайдером Транстелеком Казахстан, чтобы не зависеть только от RETN.
• Возместим время простоя вашего VPS в локации Казахстан за 2 июля. Для этого, пожалуйста, напишите запрос в техподдержку.

К облачным серверам с GPU в дата-центре Алматы скоро добавится новая видеокарта — NVIDIA RTX PRO 6000. Карта рассчитана на работу с крупными моделями и ресурсоемкими нагрузками.
Для каких задач подойдет:

• Обучение и дообучение моделей на больших датасетах.
• Инференс крупных LLM — 96 ГБ видеопамяти позволяют размещать масштабные модели на одной карте.
• HPC и научные вычисления, симуляции, аналитика больших данных.
• Тяжелая медиа-обработка и 3D-рендеринг.

Конфигурацию можно гибко менять и добавлять мощности в панели управления по мере роста проекта. Данные обрабатываются локально в дата-центре в Алматы в соответствии с требованиями законодательства Республики Казахстан. Оплата в тенге по модели pay-as-you-go.

pro.servercore.com/almaty_offer_gpu

Обновлены условия использования сервиса «Сеть доставки контента (CDN)».

Изменения вступают в силу 10 июля 2026.

Основные изменения:
Раздел 3 «Порядок предоставления услуги»: уточнен порядок настройки CDN-ресурсов, обязанности Заказчика и права Исполнителя (включая установление лимитов, проведение проверок и привлечение третьих лиц).

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

Раздел 5 «Окончание предоставления услуги»: уточнен порядок прекращения оказания услуги, включая удаление ресурсов после отключения за неуплату, отключение неиспользуемых CDN-ресурсов и ограничение доступа при нарушении Условий.

https://selectel.ru

Как ранее предупреждал и давал возможность продлить хоть на 10 лет по старым ценам.

Что изменилось ?
Ryzen 9 9950x (5400GHz) [32 vCore] / 8 DDR5 5600 МГц / 100 ГБ NVME = 2000р превратились в 2600р
Ryzen 9 9950x (5400GHz) [32 vCore] / 16 DDR5 5600 МГц / 200 ГБ NVME = 4000р в 5200р
Ryzen 9 9950x (5400GHz) [32 vCore] / 24 DDR5 5600 МГц / 300 ГБ NVME = 6000р в 7800р
Ryzen 9 9950x (5400GHz) [32 vCore] / 32 DDR5 5600 МГц / 400 ГБ NVME = 8000р в 10400р
Ryzen 9 9950x (5400GHz) [4 vCore] / 2 DDR5 5600 МГц / 25 ГБ NVME = 1000р в 800р

В данном случае мне прибыль никак не увеличилась.
Это чисто корректировка равная корректировке Selectel сколько они мне новых денег доначислили с 1 июля.

Вечные
Ryzen 9 9950x (5400GHz) [32 vCore] / 8 DDR5 5600 МГц / 100 ГБ NVME = 40000р превратились в 100000р/разово
Ryzen 9 9950x (5400GHz) [32 vCore] / 16 DDR5 5600 МГц / 200 ГБ NVME = 60000р в 200000р/разово
Ryzen 9 9950x (5400GHz) [32 vCore] / 24 DDR5 5600 МГц / 300 ГБ NVME = 90000р в 300000р/разово
Ryzen 9 9950x (5400GHz) [32 vCore] / 32 DDR5 5600 МГц / 400 ГБ NVME = 150000р в 350000р /разово
Ryzen 9 9950x (5400GHz) [4 vCore] / 2 DDR5 5600 МГц / 25 ГБ NVME = 20000р в 48000р/разово
Ryzen 9 9950x (5400GHz) [4 vCore] / 4 DDR5 5600 МГц / 50 ГБ NVME = 30000р в 84000р/разово

LowCost тарифы, которые были Intel-8700 сначала, потом стали 7950x
Тут ключевое что изменилось? Разумеется произошла корректировка цен из-за Selectel, а так же они перестали сохранять идентичность цены 8700(7950x128ram стоил столько же сколько и 4 дедика 8700 ранее, но щас не стало не так) т.к 7950x стал сильно отличаться. И по сути просто был новый расчет с учетом новой цены Selectel. Кто покупал вечные тот словил кайф короче у него ничего не менялось.
Ryzen 9 7950x (4,5 ГГц) [1 vCore] / 1 DDR5 / 25 ГБ NVME = 350р в 450р
Ryzen 9 7950x (4,5 ГГц) [2 vCore] / 2 DDR5 / 50 ГБ NVME = 500р в 700р
Ryzen 9 7950x (4,5 ГГц) [3 vCore] / 4 DDR5 / 100 ГБ NVME = 800р в 1100р
Ryzen 9 7950x (4,5 ГГц) [4 vCore] / 6 DDR5 / 150 ГБ NVME = 1100р в 1800р
Ryzen 9 7950x (4,5 ГГц) [8 vCore] / 8 DDR5 / 200 ГБ NVME = 1600р в 2200р

Вечные
Ryzen 9 7950x (4,5 ГГц) [1 vCore] / 1 DDR5 / 25 ГБ NVME = 6666р в 27000р/разово
Ryzen 9 7950x (4,5 ГГц) [2 vCore] / 2 DDR5 / 50 ГБ NVME = 11666р в 42000р/разово

Что еще изменилось? РУ коло
РУ локации Москва-Наг + Кемерово-ДЦ1 = у нас тоже повышали электричество в Москве Кемерово и любом другом городе РФ. Пустая стойка М9 так вообще колосально высасывает, но уже предпринимаются меры чтобы ее распродавать в складчинах под сетевое оборудование.
Тут просто везде добавилось 200р за долю, 2 доли значит 400р, 4 доли значит 800р тд тд
Вечные точно так же повысились 100к 200к 300к таким же расчетом.

Что еще поменялось? Пермь.
Пермь убытками у нас висит, я хотел ее закрыть. Раз, Два.
Но прежде чем закрыть решил провести еще один эксперимент.
1500р доля превратилась в 2000р доля, 2 доли 3000р в 4000р значит, т.е. по 500р за долю увеличилось.
Следующий этап 1 сентября 2026.
Если от Перми откажется народ и она еще сильнее станет делать убытки, наверно в Октябре-Ноябре точно закрою ее, а серверы просто подарю чуваку с Перми.

Денег нет, но вы держитесь ©

Лето — отличное время для запуска новых проектов. Получите 15% скидку на новый заказ хостинга в течение всего июля.

Промокод: SUMMER-SALE
Почему выбирают OWLHOST?

Надёжный хостинг в Нидерландах

• Быстрые NVMe SSD
• Защита от DDoS-атак
• Техническая поддержка 24/7

Акция действует до 31 июля.

Заказать хостинг

Подробнее:
www.owlhost.net/ru/services/hosting/

https://timeweb.cloud

30 июня 2026 Про перегретый дата-центр
В мае мы рассказывали, как перевезли инфраструктуру в зоне ams-1 из закрывающегося ЦОДа в новый.
Сценарий, где новый дата-центр с полноценной системой охлаждения и резервирования, выходит из строя, потому что чиллеры вышли из строя, было сложно себе представить. Но он произошел.
В дополнение к этому цепочка подрядчиков, отвечающих за обслуживание охлаждающего оборудования со стороны ЦОДа ведет себя в лучших традициях анекдотов. Медленно, малоэффективно и абсолютно без какой-либо конкретики по срокам. Вот что нам ответили буквально час назад.
Попытки запустить отказавший чиллер не увенчались успехом. Сейчас ЦОД организовал срочную поставку новых силовых кабелей (вероятно для подключения внешнего чиллера к сети ДЦ) — обещают завтра до 12-14 мск. Параллельно ЦОД привлекает дополнительного профильного специалиста для углубленной диагностики и восстановления узла системы охлаждения, но он будет там завтра утром.
Это не соответствует ни нашим ожиданиям, ни нашим стандартам качества и обслуживания.
Мы запустили процесс по поиску нового ЦОДа и дальнейшей миграции оборудования. Но честно — процесс это не быстрый, бюрократичный и требует предварительного согласования многих технических деталей. Особенно учитывая локацию и текущие реалии.
Писать в саппорт с вопросами по срокам не особо целесообразно, так как мы сами ждем информацию.
Как есть.

24 июня 2026 Обновили ядро Linux на всех Ryzen-серверах в Москве

В копилку стабильности — и с конкретным обновлением под капотом.
Во время работы с высокопроизводительными серверами на Ryzen 7950X нашли причину редких зависаний нод. На старом ядре Ubuntu 22.04 эти процессоры могли работать нестабильно.
Это могло обернуться внезапной недоступностью виртуальных машин, хотя с самими проектами все было в порядке.
Чтобы устранить проблему, обновили ОС и ядро на всех Ryzen-серверах в московской локации.
Переезд выполнили поэтапно: сначала подняли резервные серверы, перенесли на них проекты и только потом приступили к обновлению основных хостов. Поэтому пользователи не столкнулись с простоем.
Теперь гипервизоры работают на новом ядре, а риски возможных зависаний нод осталась в прошлом.
Если вам нужны мощные серверы в Москве, есть еще одна новость — расширили парк Ryzen 7950X, чтобы было больше доступных конфигураций под ваши проекты.

19 июня 2026 AI-агенты в связке с Cline, Codex и OpenCode
Наших AI-агентов и AI Gateway можно использовать прямо в инструментах разработки.
Подключаете один раз → и дальше задаете вопросы по проекту, редактируете код и запускаете команды в терминале — прямо в рабочем окне.
Как это устроено: среда обращается к модели через OpenAI-совместимый API по вашему ключу. Используете наши модели и инфраструктуру, а интерфейс — привычный редактор или окно чата.
Подключение сводится к трем полям в настройках расширения:

• 1. Тип провайдера — OpenAI Compatible
• 2. Базовый URL агента или AI Gateway
• 3. И, наконец, ваш API-ключ.

Дальше можно отправлять запросы модели прямо из кода. Если используете AI Gateway, в настройках доступны и параметры генерации — размер контекста, лимит токенов, температура.
Подробнее о каждой среде в доке → Cline, Codex и OpenCode.

18 июня 2026 История USmall — хайлоад изнутри
6+ млн товаров, 130 ритейлеров и до 70 млн запросов во время распродаж. Мигрировали USmall в наше облако и записали видеокейс о том, как устроена инфраструктура такого проекта.
Из любопытного:

• 1. 130 площадок — 130 изолированных контуров. На каждую свой репозиторий и Docker-образ. Релизы независимы, все изменения изолированы.
• 2. Свой механизм иерархических подов. В основе паттерн одноразовых подов — каждый выполняет один цикл и завершается. Поверх него команда построила иерархию, где родительский под запускает дочерние. Так обходят ограничение Python по пропускной способности одного воркера и обрабатывают задачи параллельно.
• 3. Выделенный сервер под оркестратор. Когда Airflow потребовалась отдельная конфигурация, под него собрали сервер на двух 32-ядерных процессорах и перенесли без простоя.
• 4. AI прямо в Kubernetes-кластере. В тестовом режиме крутится нейросеть, которая ускоряет подключение новых магазинов.

Все это команда ведет сама — новые ноды добавляет за пару минут через панель, без отдельных DevOps-инженеров. А инфраструктура у нас вышла на 35% дешевле прежнего провайдера — при том же объеме.
В видео Станислав, руководитель Python-разработки USmall, рассказывает про архитектуру и почему выбрали наше облако.
Смотреть видеокейс на ютубе, рутубе и в вк.
Или читать подробный разбор на сайте → timeweb.cloud/success-story/usmall

17 июня 2026 IPv6 в базах данных
Теперь облачной базе данных можно выдать бесплатный публичный IPv6-адрес.
Полезно, если:
1. Уже раскатали IPv6 в своей инфраструктуре и не хотите держать IPv4 только ради базы
2. Масштабируете проект и постепенно уходите от дефицитных IPv4-адресов
3. Строите cloud-native или корпоративную инфраструктуру, где важна поддержка IPv6.
Подключается в пару кликов: при создании новой базы или в настройках существующей «Сеть» → «Публичный IPv6-адрес». Если переключателя IPv6 у базы нет — значит, на вашей сети он пока недоступен.
При защищенном TLS-подключении адрес автоматически привяжется к техническому домену базы. Остальные детали в документации → timeweb.cloud/docs/public-ip/ipv6-adresa
Фича появилась не случайно — ее давно просили в разделе идей (тут и тут), теперь она в проде.
Привязать айпишник к базе

16 июня 2026 Получили награду от Иннополиса
Посетили закрытую встречу резидентов и партнеров Иннополиса с участием руководства Татарстана. Обсудили совместные планы и получили неожиданную, но приятную статуэтку (на фото).
Напомним, что осенью прошлого года наш офис переехал в Казань, где мы участвуем в развитии ИТ-среды и выстраиваем сотрудничество с Университетом Иннополис.
Рады, что коллеги отметили нашу динамику. А ведь времени прошло всего ничего.
Вдохновляет

16 июня 2026 Изменение цен на выделенные серверы
С 1 июля 2026 года цены на выделенные серверы в Москве и Санкт-Петербурге вырастут на 12%.
Причина: рост цен на стойки и серверы со стороны поставщиков.
Цена на выделенные серверы в других локациях, серверы с GPU, расширение канала и доп IP-адреса остаются без изменений.
Рекомендуем заблаговременно внести на баланс сумму, достаточную для оплаты серверов по новым тарифам.

11 июня 2026 Хранилище S3-бакетов и сетевых дисков в Петербурге перевалило за 6 петабайт

В прошлых новостях про инфраструктуру рассказали, как облако устроено изнутри. Сегодня спускаемся уровнем ниже — в кластер, где физически лежат ваши бакеты и сетевые диски. Повод подходящий — после ввода двух новых нод общая емкость кластера превысила 6 петабайт.
Две трети этого объема занимают запасные копии, и так задумано. Все объекты реплицируются трижды — на разных серверах и в разных стойках.
Зачем столько копий? Диски — расходник и ломаются без расписания: бывают месяцы без единой замены, а в прошлом поменяли сразу три из 436 накопителей кластера.
Каждая замена проходит незаметно для ваших проектов: вышел из строя диск → кластер за пару часов восстанавливает копии на соседних нодах, и данные все это время можно читать и записывать.
Что под капотом. Ceph-кластер из 27 серверов с двумя тирами: быстрые NVMe-ноды — под активные данные, емкие HDD — под архивы и объекты, к которым обращаются редко. Между уровнями данные распределяются автоматически.
Кластер растет быстро. В феврале 2024 года в нем было три ноды и 70 терабайт под данные клиентов, сейчас — 27 нод и 2 петабайта. В 30 раз больше за два с половиной года.
Недавно добавили еще две ноды — одну в горячий тир, одну в холодный, ввели без окон обслуживания, данные перераспределились фоном.
6 петабайт — не предел. Про новые отметки расскажем в следующих постах.

10 июня 2026 Запустили мониторинг сервисов
Теперь можно отслеживать стабильность работы сайтов, серверов и приложений, размещенных в нашей инфраструктуре или на сторонних платформах.
Если что-то пойдет не так, вы сразу получите уведомление на почту, в Телеграм или Макс. О восстановлении — тоже.
Что можно мониторить:
Сайты и веб-приложения. Интернет-магазин упал ночью — узнаете сразу, а не утром по потерянным заказам.
Доступность серверов. Сервер перестал отвечать на запросы — среагируете до того, как это заметят остальные.
TCP-порты сервисов — базы данных, почта, API. База перестала отвечать — увидите до того, как приложение начнет спамить юзеров ошибками.
SSL-сертификаты. Продлите сертификат заранее — пока пользователи не заметили в браузере предупреждение о небезопасном соединении.
Проверки идут из нескольких регионов — без ложных алертов из-за временных сетевых сбоев.
Бонусом: история инцидентов по каждому сервису, дашборд с аптаймом, настройка интервала и таймаута, пауза без потери настроек. Подробнее в документации → timeweb.cloud/docs/monitoring
Стоимость — 30 ₽ в месяц за сервис, списания почасовые.
Подключить мониторинг → timeweb.cloud/my/monitoring

8 июня 2026 Последние инфраструктурные изменения
Атака на DNS, отказ диска, плановые работы на хосте — раньше это могло влиять на работу ваших проектов. С ростом числа клиентов и нагрузок прежние архитектурные решения перестали справляться.
Перестроили инфраструктуру по трем направлениям так, чтобы такие ситуации проходили для вас незаметно — или с минимальным эффектом.
1. Защитили исходящие запросы ваших серверов
Приложения регулярно обращаются к внешним сервисам по доменным именам — платежным шлюзам, API, базам, репозиториям. Каждый запрос проходит через наши DNS-резолверы. При мощной атаке на них запросы могли подвисать или не доходить — приложения теряли связь с внешним миром, даже когда серверы работали штатно.
Развернули резолверы по схеме anycast: запрос уходит на ближайший доступный узел → нагрузка распределяется между всеми. Атака на один узел не выводит DNS из строя — остальные продолжают отвечать, и приложения работают стабильно.
2. Отвязали данные от конкретного хоста
Внедряем сетевое хранилище NVMe-oF вместо локальных дисков. Начали с Москвы, постепенно раскатываем дальше.
На практике: если у конкретной ноды отказывает железо, сервер быстрее перезапускается на исправном оборудовании. Не нужно ждать, пока починят именно эту ноду, или разворачиваться из бэкапа.
3. Сделали миграцию виртуальных машин универсальной
С ростом числа клиентских конфигураций уперлись в корнер-кейсы — на некоторых миграция могла подвисать или требовать остановки сервера. Теперь переносим серверы быстро и без даунтайма в любом конфиге. Обычно в трех сценариях:
Плановые работы на железе: на время обслуживания хоста мигрируем машины на другой.
Балансировка: если хост перегружен, переносим часть виртуалок на свободный.
Проблемное железо: если нода ведет себя нестабильно, сразу запускаем миграцию до реальных сбоев.
Главная идея — закладывать запас прочности, чтобы инфраструктура справлялась и с текущим ростом, и с нештатными ситуациями.
P.S. Инженеры уже пишут статью на Хабр про факапы и победы в росте инфраструктуры. Пишите в комментариях, что хотите там увидеть — разберем.

3 июня 2026 Поручить работу с сервисами своему AI-агенту
Чтобы поднять сервер, базу и бакет под новый проект — можно просто создать AI-агента в связке с Timeweb Cloud MCP. Пишете агенту, что нужно, он запрашивает подтверждение и после вашего разрешения берется за работу.
Причем наш MCP можно подключить и к стороннему агенту — например, Cursor, Claude или своему боту. Подробнее про подключение → в доке.
Из последних апдейтов — открыли для MCP почти весь публичный API. Доступны все методы, кроме удаления, добавим их позже.
Что вы можете поручить агенту в связке с Timeweb Cloud MCP:
Запустить инфраструктуру с нуля
Создай сервер на Ubuntu 24.04 с 4 ГБ RAM в Москве для тестов
Мониторить работу
Покажи список серверов и их статус, а еще оцени состояние кластера
Собрать контур под проект
Создай балансировщик и добавь в него 2 сервера, а потом настрой приватную сеть между ними
Запустить AI-агента с поддержкой MCP → timeweb.cloud/my/cloud-ai/tools

2 июня 2026 Под капотом управляемых сервисов
Вместе с инфраструктурой и сетью продолжаем менять то, что напрямую влияет на стабильность. Сегодня подробнее про управляемые сервисы — базы данных, кластеры Kubernetes, балансировщики и др.
Главное — перестроили процесс развертывания сервисов.
Теперь задачи разделены: cloud-init поднимает сервис при создании, а фоновая служба агента на инстансах DBaaS обслуживает его дальше.
Что это значит для вас — сервисы в среднем создаются на 3 минуты быстрее. А за счет сокращения задержки между запросом из панели и его выполнением агент оперативнее применяет изменения.
Параллельно:
1. Пересобрали образы ОС под сервисы. Вместо универсального образа у баз данных, Kubernetes и других сервисов теперь свой минимальный образ только с нужными зависимостями. За счет этого сервис создается быстрее и не зависит от состояния внешних репозиториев.
2. Подняли все версии PostgreSQL до последних минорных. Обновили линейки 17.x, 16.x, 15.x — чтобы у вас был доступ к стабильным версиям с закрытыми уязвимостями.
3. Усилили безопасность управляемых баз. Перенесли сетевую изоляцию на уровень гипервизора виртуальной машины и пересмотрели список доступных расширений PostgreSQL.

–20% на российские и кириллические домены

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

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

До 16 июля для вас действует скидка 20% на регистрацию российских и кириллических доменов по промокоду RUSCYRJUL
www.nic.ru/catalog/domains/russian-and-cyrillic/