Почему я ухожу из Timeweb Cloud: 46 часов простоя в Амстердаме за два месяца — по данным самого хостера

TL;DR. Я выбирал Timeweb не из-за цены, а из-за «имени» и обещанной надёжности. За май–июнь 2026 года зона ams-1 (Амстердам, дата-центр Qupra) пережила шесть крупных аварий с суммарным окном недоступности около 46 часов — причём последняя авария на момент написания этих строк всё ещё не закрыта и идёт уже более 15 часов. Хостер ^[1] на своём сайте обещает Tier III и аптайм 99,98 % — это 1 час 45 минут простоя в год. За два месяца факт превысил годовой лимит этого обещания примерно в 26 раз. Все цифры ниже — не мои домыслы и не «жалобы в чате», а сообщения из официального канала статусов самого Timeweb.

Почему я вообще выбрал Timeweb

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

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

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

Что обещает сам хостер ^[1]

На сайте Timeweb прямо написано: инфраструктура размещается в дата-центрах уровня Tier III с коэффициентом отказоустойчивости не менее 99,98 %.

Давайте посчитаем, что это значит на практике. В году 8 766 часов. 99,98 % аптайма — это значит, что на простой отводится:

0,02 % × 8 766 ч ≈ 1,75 часа = 1 час 45 минут в ГОД.

Запомним эту цифру: 1 час 45 минут в год. Это тот бюджет недоступности, который хостер ^[1] сам себе назначил своим маркетингом.

Что происходило в Амстердаме на самом деле

Я собрал хронологию по официальному каналу статусов Timeweb (@timewebcloud_alerts) — это их собственный рупор, куда они сами публикуют аварии. Вот что было в зоне ams-1 (дата-центр Qupra, Нидерланды) всего за два месяца:

Итого: около 46 часов недоступности за 61 день — и счётчик ещё крутится.

И отдельно подчеркну про последнюю строку. Авария началась 29 июня в 21:44 мск. Я пишу эти строки спустя более чем 15 часов — и в канале статусов всё ещё висит «продолжаем заниматься системой кондиционирования, ожидаем информации по срокам окончательного запуска». Один этот инцидент уже в ~8–9 раз перекрыл весь годовой бюджет простоя по их SLA. И он ещё не закончился.

Каждый столбец — отдельная авария. Синяя пунктирная линия у самого нуля — это весь годовой бюджет простоя, который хостер ^[1] сам себе разрешил своим SLA 99,98 %.

Сравним с обещанием:

• Обещанный бюджет простоя: 1 ч 45 мин в год.

• Факт ams-1: ~46 часов за два месяца (и это без учёта того, что последняя авария ещё идёт).

• Это примерно 26-кратное превышение годового лимита SLA — и не за год, а за два месяца.

• Фактическая доступность ams-1 за май–июнь получается ~96,8 % против заявленных ≥ 99,98 %.

Честная оговорка, чтобы меня не поймали на передёргивании. В таблице — окно «от первого сообщения об аварии до сообщения „инцидент закрыт“», то есть время до полного восстановления. В части инцидентов хостер ^[1] указывал частичный аффект («7 % нод», «34 ноды»). Но 23 и 27 мая — это, по их же словам, полное обесточивание машинного зала.

Это системная проблема

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

Хронология говорит сама за себя:

• 23 мая — авария питания из-за жары.

• 25 мая Timeweb пишет, что ДЦ «апгрейдит систему охлаждения машинных залов» — как реакцию на 23 мая.

• 26 мая — авария повторяется.

• 27 мая — система охлаждения полностью выключается, все стойки обесточивают.

• А потом, в июне, всё повторяется снова — 26-го и дважды 29-го.

То есть «ремонт» причину не устранил.

И отдельно — прямое признание самого хостера. 27 мая в их канале:

«За простой в зоне ams-1 за 23, 26 и 27 мая будет сделан перерасчёт после полного восстановления площадки.»

Три аварии за пять дней — официально, их же словами.

Обещанный постмортем, которого нет

Отдельная деталь, которая многое говорит об отношении к клиентам.

По майскому кластеру аварий хостер ^[1] дважды публично пообещал постмортем:

• 23 мая (закрытие инцидента): «Подробный постмортем с разбором причин опубликуем отдельно».

• 27 мая: «По итогам отчёта площадки выпустим постмортем».

Прошёл месяц с лишним. Этого постмортема нет — ни в канале статусов, ни в их блоге на Хабре. При этом есть разборы по другим, куда менее масштабным инцидентам они спокойно публиковали — постмортем по libvirt, по сбою S3, по дисковой подсистеме в зоне MSK-1. То есть механика «признать и разобрать» у компании есть. Но по самой крупной и позорной серии аварий — отказам питания и охлаждения в Амстердаме — наступила тишина.

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

«За такие деньги чего вы хотите» и «поднимите реплики»

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

Первый: «за такие деньги чего вы хотите». Я уже сказал: Timeweb не дешёвый. За те же деньги OVH даёт более мощное железо. Я предпочел заплатить за надёжность — и именно её не получил. На минуточку, цены у Timeweb среди РУ-хостеров раза в 3 выше.

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

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

Базовый аптайм обязан обеспечивать сам хостинг ^[1]. Если клиент вынужден строить сложную мульти-региональную схему только для того, чтобы пережить отказы кондиционера в ДЦ провайдера, — значит, провайдер перекладывает свою работу на клиента. И при этом берет за это деньги.

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

Будем честны: не всё — вина хостера

Если посмотреть на канал алертов целиком, видно ещё один большой пласт инцидентов — DDoS-атаки на локацию Нидерланды (особенно зимой 2024–2025, когда волны шли почти ежедневно, и периодически в 2026-м). Вот это я в вину Timeweb не ставлю. DDoS — внешний фактор, отражение атак — это нормальная боль любого провайдера, и они с ней работали.

Моя претензия — конкретная и узкая: кластер отказов питания и охлаждения в ДЦ Qupra в мае–июне 2026 года. Это не хакеры. Это инженерная инфраструктура площадки, за которую отвечает хостер ^[1]. И именно она постоянно подводит.

Серое — DDoS (внешний фактор, к хостеру претензий нет). Красное — инфраструктура и сеть. Хорошо виден зимний пик DDoS 2024–25 и отдельный майско-июньский кластер инфраструктурных отказов 2026 года.

Почему я ухожу

Я принял решение переезжать. И не из-за одной аварии — аварии случаются у всех. А из-за того, что это стало системной историей: один и тот же дата-центр за два месяца регулярно становится причиной масштабных простоев, причём по одной и той же причине.

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

И мне правда жаль. В остальном сервис Timeweb действительно удобный — приятная панель, нормальная поддержка. Но никакая панель управления не компенсирует постоянные простои. Когда твой проект в Амстердаме лежит десятки часов за два месяца, удобство интерфейса перестаёт что-либо значить.

А если у вас инфраструктура в этой же зоне — поделитесь в комментариях, совпадает ли ваша картина простоев с этой хронологией. Будет интересно собрать статистику от других пользователей.

Слово хостеру: право на ответ

Я сознательно не делаю из этого «приговор без защиты». У Timeweb есть аккаунт здесь, на Хабре — @Timeweb_Cloud, — и я буду рад, если коллеги придут в комментарии и ответят по существу. Вопросы у меня предметные:

1. Где обещанный постмортем по майскому кластеру ams-1? Вы дважды публично обещали его (23 и 27 мая). Прошёл месяц — разбора нет. По libvirt, S3 и дискам в MSK-1 постмортемы вы выпускали. Почему по самой крупной серии аварий — тишина?

2. Что конкретно сделано с охлаждением в ДЦ Qupra? После 23 мая вы писали об «апгрейде системы охлаждения». Но 26, 27 мая и весь июнь авария повторялась. Что именно заменили/починили и почему это не сработало?

3. Будет ли перерасчёт? 27 мая вы обещали перерасчёт за 23, 26 и 27 мая. Он сделан? А за июньские простои? По какой методике считается компенсация?

4. Рассматриваете ли вы смену площадки в Нидерландах? Если конкретный дата-центр системно не держит охлаждение — это вопрос смены подрядчика, а не «ещё одного обновления прошивки».

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