ESTT: хостинг-провайдер вторые сутки поднимает инфраструктуру после сбоя
Авария у ESTT началась 8 ноября около 4:00 МСК: пострадали клиентские сервисы, виртуальные серверы и личный кабинет. 9 ноября компания сообщила о восстановлении значительной части инфраструктуры, но причину сбоя так и не назвала.
Что случилось
Российский хостинг-провайдер ESTT (e-Style Telecom) вторые сутки восстанавливает инфраструктуру после крупного технического сбоя. По данным сервиса Detector404, жалобы клиентов начались 8 ноября около 4:00 по московскому времени. 9 ноября компания сообщила, что инженерам удалось вернуть в строй значительную часть инфраструктуры: виртуальные серверы постепенно запускаются, к ним возвращается сетевой доступ. Личный кабинет клиентов при этом остаётся недоступным. Причину аварии, масштаб последствий и сроки полного восстановления ESTT не называет, обещая подробное официальное заявление позже.
Детали
ESTT обслуживает малый, средний и крупный бизнес, а также интернет-проекты, то есть речь идёт о множестве клиентских окружений, а не об одном сервисе.
- первые сообщения о проблемах — около 4:00 МСК 8 ноября;
- 9 ноября восстановлена значительная часть инфраструктуры, виртуальные серверы запускаются поэтапно;
- панель управления клиентов недоступна, поэтому часть работ — например, перезагрузку или смену конфигурации — клиенты сделать не могут;
- причина не раскрыта, официального разбора инцидента пока нет.
Сбой произошёл через неделю после массированной кибератаки на другого российского провайдера — Beget, которая привела к уничтожению облачной инфраструктуры. Связь между двумя инцидентами не установлена, и рассматривать их как одну кампанию оснований нет. В прошлом году ESTT уже попадала в новости из-за DDoS-атаки: тогда пострадали сети «Вкусно — и точка» и «Много лосося», приложения Cofix и «Суши мастер», а также сервис автоматизации ресторанов iiko.
День оказался неудачным и для других: 9 ноября с 9:16 МСК пошли жалобы на перебои интернета у абонентов Ростелекома — больше всего из Краснодарского края, также из Тюменской и Ростовской областей и Чечни, причём и на проводных, и на Wi-Fi подключениях. У GitHub 8 ноября с 13:36 до 15:32 МСК часть неавторизованных пользователей получала таймауты и ошибку 503, а утром 9 ноября компания сообщила о новом росте таймаутов из-за наплыва анонимных обращений; с 3 ноября фиксировались сбои в Actions, Pages, Git-операциях и пул-реквестах.
Что это значит
Для клиента хостера такой инцидент означает не «подождать, пока починят», а проверить собственный план восстановления: есть ли копии данных вне площадки провайдера, как быстро развернуть окружение на другом хосте, какой TTL у DNS-записей и где лежит документация по сборке сервисов. Пока панель управления недоступна, любые действия через неё невозможны — и это отдельный аргумент за то, чтобы ключевые процедуры не зависели от одного веб-интерфейса. Второй момент — прозрачность: когда провайдер двое суток не называет причину, клиенту сложно оценить, восстановлены ли данные полностью и что именно потеряно. Разбор инцидента с хронологией и описанием отказавших компонентов здесь нужен не из вежливости, а чтобы понять, какие риски переезжают вместе с вами в следующий раз.
Комментарии 0
Комментариев пока нет — будьте первым.
Оставить комментарий
Имя и текст — этого достаточно. Комментарий появится сразу; подозрительные сообщения уходят на проверку.