На Хабре вышла статья, которая заставила меня пересмотреть отношение к одному из крупных российских хостинг-провайдеров. Автор, технический специалист, который осознанно платил за надёжность, а не за дешевизну, рассказывает, почему он уходит из Timeweb Cloud.
Причина — не случайный сбой, а системные проблемы в дата-центре Qupra в Амстердаме (зона ams-1), которые за два месяца превратились в 46 часов простоя.
О чём статья
Автор выбрал Timeweb Cloud, потому что верил в «имя» и обещанную надёжность. На сайте провайдера указан аптайм 99,98% — это значит, что в год допустимо всего 1 час 45 минут простоя.
Реальность за май–июнь 2026 года:
- 6 крупных аварий в зоне ams-1
- ~46 часов суммарной недоступности (и одна авария на момент написания всё ещё идёт)
- Это превышает годовой лимит SLA примерно в 26 раз за два месяца
- Фактическая доступность — около 96,8% вместо обещанных 99,98%
В чём системность проблемы
Автор подчёркивает: это не просто «невезение».
Все инциденты происходят по одной и той же причине:
- 23 мая — авария питания из-за жары.
- 25 мая — Timeweb пишет об «апгрейде системы охлаждения».
- 26 мая — авария повторяется.
- 27 мая — охлаждение полностью отключается, стойки обесточивают.
- Июнь — та же история повторяется 26 и 29 июня.
То есть «ремонт» не устранил причину. Это не разовая проблема, а системный сбой инфраструктуры площадки, за которую отвечает сам провайдер.
«Авария воспроизводится через дни и недели. Это и есть определение системной проблемы, а не форс-мажора.»
Отдельная история — постмортем
В мае Timeweb дважды обещал опубликовать подробный постмортем (разбор причин) по кластеру аварий. Прошёл месяц — разбора нет.
При этом по другим, менее масштабным инцидентам (libvirt, S3, диски в MSK-1) они отчитывались оперативно. Автор справедливо замечает: компания умеет делать разборы, но по самой позорной серии аварий — молчит.
Два аргумента, которые автор считает несостоятельными
1. «За такие деньги — чего вы хотите?»
Автор платил не минимальный ценник, а премию за надёжность. За те же деньги, по его словам, OVH даёт более мощное железо. Timeweb он выбрал за имя и сервис.
2. «Поднимите реплики, стройте отказоустойчивую архитектуру»
Отказоустойчивость на стороне клиента — это защита от редких сбоев, а не способ компенсировать регулярные проблемы провайдера. Если клиент вынужден строить мульти-региональную схему, чтобы пережить отказы кондиционера в ДЦ провайдера, значит, провайдер перекладывает свою работу на клиента.
Что в итоге
Автор уходит из Timeweb Cloud не из-за одной аварии, а из-за того, что это стало системой. Доверие к инфраструктуре потеряно.
Он переезжает — и советует другим:
- Маркетинговый SLA ≠ договорной SLA. «99,98%» на лендинге — обещание, а не обязательство с компенсацией.
- Смотрите на канал статусов провайдера. Полистайте за год перед тем, как платить.
- Конкретная локация важнее бренда. Проблемы были у конкретного ДЦ Qupra в Амстердаме, а не у всего Timeweb.
- Честно спрашивайте с хостера. Отказоустойчивость на вашей стороне — страховка, а не замена базовому аптайму.
Если коротко
Статья — честный и аргументированный разбор ситуации, когда провайдер с хорошим маркетингом не выдерживает собственных обещаний. Автор не просто жалуется, а показывает хронологию, цифры и системность проблемы.
Для всех, кто выбирает хостинг, это хороший урок: проверяйте не только цену и бренд, но и реальную статистику инцидентов по конкретному дата-центру.
И да, в комментарии под статьей уже пришли представители Timeweb с предложением разобраться — посмотрим, будет ли постмортем и компенсации, и насколько системно провайдер готов решать проблему.
Читайте также:
А можно не прогонять статьи через нейронки, чтобы написать ещё статьи?