Инциденты FirstVDS в 2026 году
Инциденты FirstVDS в 2026 году
Последняя проверка летней истории: 3 сентября 2026 года. События 22–24 сентября и объявление работ 25 сентября выборочно проверены 24 сентября; летние источники повторно не переаттестованы.
4 октября 2026 года добавлены закрытый московский инцидент k1338ns и наблюдение после окна Транстелеком-Казахстан. В истории работ отдельно подтверждена отметка выполнения перезагрузки Алматы 2 октября. Это выборочное дополнение; прочие исторические даты проверки сохранены.
3 октября 2026 года, до начала объявленного окна, проверено уведомление об аварийно-восстановительных работах Транстелеком-Казахстан. Оно опубликовано 2 октября; фактический результат и простой не подтверждены. Прежние окна и история ниже сохраняют свои даты проверки, в том числе snapshot от 1 октября.
1 октября 2026 года добавлены окна сетевого обслуживания Алматы и Москвы. Тест переключения в Алматы 1 октября уже отмечен выполненным; отдельная перезагрузка 2 октября ещё запланирована. Это не новые подтверждённые аварии. Остальная хронология сохраняет прежние даты проверки.
28 сентября повторно проверена официальная панель. После двух коротких эпизодов l142arm 27 сентября на том же московском ARM-пуле появились ещё две записи 28 сентября: один узел был недоступен 07:01–07:05, а затем отмечены временные ограничения 10:50–10:53. На момент чтения панель показывает все узлы l142arm доступными. Причина и связь четырёх записей не опубликованы; интервалы сообщений не являются измерением downtime каждого VDS.
26 сентября добавлены более поздние события узлов и управления за 24 сентября, DNSmanager 26 сентября и объявление сетевых работ в Алматы. Источник — официальная панель; прежние проверки сохранены.
4 октября — один московский узел k1338ns
При проверке 4 октября официальная панель содержит сообщение о недоступности одного узла k1338ns в 04:26 и закрытие в 04:36. Время перенесено как отображается: часовой пояс этих отметок явно не указан, поэтому перевод в UTC или Екатеринбург не выполняется.
10 минут — интервал сообщений, не измеренный простой всех VDS пула. Причина, идентификатор физического узла и число затронутых клиентов не опубликованы; общая причина с работами в Казахстане не установлена. Сопоставьте собственные пробы и ошибки приложения с уведомлением по своему серверу. Категория «Норм» сохраняется; эксплуатационные тесты здесь не выполнялись.
3 октября — объявленные работы Транстелеком-Казахстан
На официальной панели FirstVDS уведомление размещено с отметкой «Запланировано 02.10.2026 12:22». Часовой пояс этой служебной отметки отдельно не указан. Окно явно задано в МСК: 3 октября, 10:00–11:00 — 12:00–13:00 по Екатеринбургу, UTC+5.
Провайдер предупреждает о возможном ухудшении связи с внешними ресурсами: росте задержки, потере пакетов и снижении пропускной способности. В тексте есть некорректная формулировка «до 15 часа». Она не исправлена догадкой на «15 минут»: достоверно указан часовой интервал работ, но отдельная максимальная длительность деградации требует уточнения.
На проверку 3 октября до начала окна общая панель сообщает о доступности сервисов. Это не результат будущих работ и не измерение сетевого качества конкретного VDS. Уведомление хранится как объявленное обслуживание внешней сети, а не подтверждённый час простоя всей площадки. Связь с тестом переключения 1 октября и перезагрузкой 2 октября не установлена.
После окна, проверка 4 октября: общая панель показывает все сервисы доступными, включая узлы и сеть Алматы; её служебная отметка — 04.10.2026 07:02:01, без указанного часового пояса. Уведомления 3 октября уже нет среди предстоящих работ; в прочитанной истории работ отдельного итога этого окна не найдено. Это наблюдение доступности после окна, не подтверждение его успешного выполнения без перерывов и не измерение нулевого downtime. Первоначальное уведомление выше сохранено по проверке 3 октября.
Для ресурса в Казахстане сохраните внешние HTTP/TCP-пробы и потери пакетов до, во время и после окна; проверьте независимый резервный путь. Категория «Норм» сохраняется. Пересмотр нужен при подтверждённом превышении воздействия или повторяющейся деградации, а не только по числу объявлений.
Октябрь — объявленные работы на сети Алматы и Москвы
Источник исходного расписания — раздел плановых работ официальной панели FirstVDS, прочитанный 1 октября 2026 года. 4 октября по истории работ уточнено выполнение окна 2 октября; остальные строки сохраняют прежнюю дату проверки. Окна явно указаны провайдером в МСК (UTC+3). Двухчасовое окно обслуживания не означает двухчасовой простой.
| Окно, МСК | Площадка и работы | Заявленное воздействие | Состояние при проверке |
|---|---|---|---|
| 1 октября, 06:00–08:00 | Алматы: тест переключения на резерв оператора РЕТН | Возможны задержки, потери пакетов и снижение пропускной способности до часа внутри окна | Отмечено «Выполнено 01.10.2026 06:44»; это отметка панели, не измерение длительности воздействия |
| 2 октября, 05:00–07:00 | Алматы: применение конфигурации с перезагрузкой оборудования | Заявлена полная недоступность площадки до 30 минут | Проверка 4 октября: в истории «Выполнено 02.10.2026 09:55»; часовой пояс служебной отметки и фактический перерыв не установлены |
| 5 октября, 05:00–07:00 | Москва, IXcellerate: конфигурация с перезагрузкой оборудования | Несколько кратких деградаций при перемаршрутизации, до минуты каждая | Запланировано; отметка публикации 30 сентября, 14:08 |
| 7 октября, 05:00–07:00 | Москва, IXcellerate: отдельное окно таких же работ | Несколько кратких деградаций при перемаршрутизации, до минуты каждая | Запланировано; отметка публикации 30 сентября, 14:08 |
Часовой пояс служебных отметок публикации и выполнения отдельно от окон не обозначен. Дата первоначального объявления теста 1 октября в текущем блоке уже не видна: его строка показывает выполнение. На момент чтения общая панель сообщает о доступности сервисов. Это не собственный тест VPS и не подтверждение отсутствия перерывов во время уже выполненных работ.
Время окон для Екатеринбурга — соответственно 08:00–10:00 1 октября и 07:00–09:00 2, 5 и 7 октября (UTC+5). До будущих окон проверьте независимый резерв и доступ к копиям, исключите одновременный перенос данных или критичный релиз. После обслуживания проверяйте приложение и потерянные соединения по внешним пробам; не записывайте максимально допустимые 30 минут как уже случившийся outage.
Категория «Норм» сохраняется. Отметка выполнения перезагрузки 2 октября не является результатом отдельного окна Транстелеком-Казахстан 3 октября. Служебное время 09:55 не доказывает простой до этой минуты или превышение окна без независимых данных. Если воздействие превысит объявленные границы, его нужно зафиксировать отдельно по фактическим измерениям и сообщению провайдера.
Краткий вывод
Главный подтвержденный риск FirstVDS летом 2026 года связан с конкретной площадкой Qupra DC2 в Амстердаме. Отдельно фиксировалась выборочная недоступность HTTPS, SSH и RDP при штатной работе серверов, которую провайдер связывал с внешней фильтрацией трафика.
FirstVDS не ограничился публикацией постмортема и перенёс инфраструктуру в NorthC Amsterdam 1. 31 августа провайдер официально сообщил о завершении миграции виртуальных машин из Qupra DC2; новые VDS в Нидерландах уже создаются на новой площадке.
Само завершение переезда — mitigation старого риска, а не новый инцидент. Публичное сообщение не указывает на превышение окна, потерю данных или другой незапланированный ущерб во время миграции.
27–28 сентября — повторные события московского l142arm
На официальной панели видны четыре коротких записи одного компонента:
| Первое сообщение | Закрытие | Сообщение |
|---|---|---|
| 27 сентября, 10:38 | 10:41 | Недоступен один узел |
| 27 сентября, 13:26 | 13:30 | Недоступен один узел |
| 28 сентября, 07:01 | 07:05 | Недоступен один узел |
| 28 сентября, 10:50 | 10:53 | Временные ограничения |
На проверку 28 сентября панель показывает l142arm и остальные перечисленные узлы доступными. Эти записи не складываются в один непрерывный outage. Не опубликованы идентификатор затронутого физического узла, число клиентских VDS, root cause и подтверждение общей причины. Повторяемость одного пула стоит учитывать при тесте, но категория «Норм» этим дополнением не меняется.
27 сентября — повторные ограничения VMmanager zon.hoztnode.net
При проверке 27 сентября официальная панель уже показывает две закрытые записи, а не продолжающуюся недоступность:
| Первое сообщение | Закрытие | Компонент |
|---|---|---|
| 27 сентября, 00:18 | 27 сентября, 02:26 | VMmanager zon.hoztnode.net, часть функций |
| 27 сентября, 02:35 | 27 сентября, 02:36 | Та же панель, отдельная запись |
Время перенесено как отображается в истории; часовой пояс отдельно не указан. В прочитанном состоянии с отметкой обновления 27.09.2026 06:28:28 сервисы, включая этот VMmanager, обозначены работающими штатно. Это сообщение провайдера, не собственный тест авторизации.
Записи не объединяем в непрерывный простой до 02:36 и не приравниваем к остановке VM. Причина, полный охват клиентов и связь с закрытым эпизодом того же компонента 24 сентября не установлены. Повторяемость управления стоит отслеживать отдельно; категория «Норм» сохранена. История остальных событий и плановые работы ниже не переаттестованы этим дополнением.
22–24 сентября — московские узлы и DNS
Источник — официальная status-панель, на которую ссылается FirstVDS. Время ниже перенесено как показано в истории; часовой пояс у записей инцидентов отдельно не обозначен.
| Дата | Компонент | Опубликованные отметки |
|---|---|---|
| 24 сентября | Москва, k135nt | Один узел недоступен 06:03; закрытие 06:12 |
| 22 сентября | Москва, k135nt | Две записи с одинаковым началом 23:48, закрытиями 23:54 и 23:56 |
| 22 сентября | Москва, k1335nt | Несколько узлов 21:21; один узел 22:04; закрытие 22:41 |
| 22 сентября | DNS resolvers | Деградация 09:18–09:19 и отдельная запись 09:20–09:59 |
| 22 сентября | Москва, vz | Один узел недоступен 06:43; закрытие 06:45 |
Две записи k135nt не считаем двумя доказанно независимыми авариями: идентификаторы узлов и причина совпадения не опубликованы. Интервалы сообщений не являются измерением простоя каждого VDS и не складываются. Причины, полный охват и связь с Qupra не установлены; DNS resolvers не приравниваются к отказу всего DNS-хостинга.
Дополнение 26 сентября: новые записи узлов и управления
На той же панели прочитаны следующие закрытые события. Время приведено как отображается, без предположения о часовом поясе:
| Дата | Компонент | Первое сообщение → закрытие |
|---|---|---|
| 26 сентября | DNSmanager, часть функций | 12:22 → 12:25 |
| 24 сентября | Личный кабинет, часть функций; две отдельные записи | 15:55 → 16:00 и 16:02 → 16:09 |
| 24 сентября | VMmanager zon.hoztnode.net, часть функций | 15:45 → 16:21 |
| 24 сентября | Москва, один узел k1339ns | 14:36 → 14:37 |
| 24 сентября | Москва, один узел k135nt | 14:16 → 14:29 |
DNSmanager — интерфейс управления, не доказательство отказа DNS-разрешения всех доменов. Сбой VMmanager также не означает остановку всех VM. Две записи кабинета не объединяем в непрерывный простой. Для сравнения надёжности нужны идентификатор затронутого ресурса и собственные измерения; причина и общий охват из этих сообщений не следуют. Категория «Норм» сохраняется.
Объявленные работы 28 сентября — сеть Алматы
Уведомление опубликовано 24 сентября в 10:57 по отметке панели. Окно явно задано в МСК: 28 сентября, 10:00–13:00. Заявлена возможная деградация связности с внешними ресурсами — задержка, потери пакетов и снижение пропускной способности — до одного часа внутри этого окна, а не трёхчасовая полная недоступность.
До окна проверьте резервный доступ и поведение соединений при потерях; после него сопоставьте внешние пробы с исходными значениями. Это план, не уже случившаяся авария и не подтверждение связи с московскими событиями. Часовой пояс времени публикации отдельно не установлен.
Объявленные работы 25 сентября
На той же панели 23 сентября в 11:07 опубликовано обслуживание серверной стойки 25 сентября, 03:00–07:00 МСК. Заявленный перерыв — 15–50 минут, не четыре часа. Стойка и список клиентов не раскрыты; принадлежность к московским инцидентам не установлена.
Объявленное окно уже прошло; результат обслуживания и фактический перерыв этим дополнением не подтверждены. Для своего сервера проверьте уведомление, внешние пробы и состояние копий. Категория «Норм» сохраняется; эксплуатационные проверки здесь не выполнялись.
Хронология
| Дата | Локация или уровень | Событие | Статус | Источник |
|---|---|---|---|---|
| 31 августа | Амстердам | FirstVDS сообщил о завершении переноса виртуальных машин из Qupra DC2 в NorthC Amsterdam 1; новые VDS создаются на новой площадке | Миграция официально завершена | Официальное сообщение |
| 27 августа | Амстердам | FirstVDS сообщил, что августовская миграция идёт по графику; IP-адреса сохраняются, DNS менять не требуется | Промежуточный статус перед завершением 31 августа | Августовский дайджест |
| 13 июля | Амстердам | Объявлен переезд из Qupra DC2 в NorthC Amsterdam 1 с сохранением IP-адресов | Миграция была запланирована на 1–1,5 месяца и завершена 31 августа | Официальное сообщение |
| 29 июня — 1 июля | Qupra DC2 | Самая длительная авария охлаждения длилась около 44 часов | Серверы восстановлены поэтапно | Постмортем |
| 27 мая, 26 и 29 июня | Qupra DC2 | Три предыдущих отказа охлаждения примерно на 5, 5 и 4 часа | Восстановлено | Постмортем |
| 9 июня | Внешняя связность | У части пользователей не работали HTTPS, SSH, RDP и иногда ICMP | Серверы и внутренняя сеть работали штатно | Официальное сообщение |
Постмортем Qupra DC2
FirstVDS указал суммарную недоступность амстердамской площадки за май–июль около 58 часов. Первопричиной названы повторные отказы системы охлаждения дата-центра; жара стала триггером, но затяжной простой возник из-за цепочки инженерных и эксплуатационных отказов. Данные клиентов, по заявлению провайдера, сохранились.
Провайдер признал ошибки коммуникации, объявил компенсацию по SLA и промокоды, а затем решил полностью покинуть площадку. Для оценки надежности это важнее простого числа инцидентов: есть публичная хронология, признание ответственности и завершённое corrective action — перенос в другой дата-центр.
Переезд в NorthC Amsterdam 1
Причиной срочного ухода стало состояние старой площадки: охлаждение Qupra DC2 продолжало работать на резервном чиллере без резервного питания. FirstVDS выбрал NorthC Amsterdam 1 и описывает площадку как дата-центр уровня Tier III с резервированием ключевых инженерных систем.
До переезда клиентам были заявлены:
- сохранение текущих IP-адресов;
- отсутствие необходимости менять DNS;
- персональные уведомления о работах по конкретному серверу;
- проведение переноса с минимальным воздействием на сервисы;
- завершение к началу сентября 2026 года.
31 августа FirstVDS подтвердил, что миграция виртуальных машин завершена. Новые заказы VDS в Нидерландах открываются уже на NorthC Amsterdam 1.
Это закрывает организационную часть mitigation, но не доказывает долгосрочную стабильность новой площадки. После физического переезда нужно заново собрать baseline:
MTR и ping из нужных регионов
↓
iperf3 в обе стороны
↓
fio и latency диска
↓
внешний uptime-monitoring
↓
проверка backup и restore
Результаты старых тестов на Qupra DC2 не описывают NorthC полностью. Полезно отдельно проверить reboot history, IPv4/IPv6, rDNS, firewall, время системы и завершение backup jobs.
Влияние на категорию
FirstVDS остаётся в категории «Норм».
Завершённый переезд снижает известный инфраструктурный риск и показывает, что провайдер выполнил публично объявленный corrective action. Повышать оценку до «Рекомендую» только по факту миграции рано: нужна история эксплуатации NorthC, повторные замеры сети и дисков, а также проверка backup/restore после переноса.
Практический вывод
- российские и амстердамские услуги FirstVDS нужно оценивать отдельно;
- европейскую площадку нельзя использовать как единственную точку хранения;
- выборочная недоступность HTTPS или SSH не всегда означает падение VPS;
- при проблеме доступа полезно сравнивать разных операторов и использовать консоль VNC;
- перенос виртуальных машин официально завершён 31 августа;
- заявленное сохранение IP и DNS не отменяет проверки приложения после физического переноса;
- после переезда нужны новые MTR,
iperf3,fio, проверка backup/restore и внешний uptime-monitoring; - при новом инциденте нужно отдельно фиксировать, относится ли он к NorthC, российской площадке или внешней сети.