{"id":14275,"url":"\/distributions\/14275\/click?bit=1&hash=bccbaeb320d3784aa2d1badbee38ca8d11406e8938daaca7e74be177682eb28b","title":"\u041d\u0430 \u0447\u0451\u043c \u0437\u0430\u0440\u0430\u0431\u0430\u0442\u044b\u0432\u0430\u044e\u0442 \u043f\u0440\u043e\u0444\u0435\u0441\u0441\u0438\u043e\u043d\u0430\u043b\u044c\u043d\u044b\u0435 \u043f\u0440\u043e\u0434\u0430\u0432\u0446\u044b \u0430\u0432\u0442\u043e?","buttonText":"\u0423\u0437\u043d\u0430\u0442\u044c","imageUuid":"f72066c6-8459-501b-aea6-770cd3ac60a6"}

Хостинг Timeweb: причины пятничного сбоя

11.12.20 в 16:02 МСК мы столкнулись с аппаратной проблемой в работе системы маршрутизации. Серверы продолжали работать, но прекратили быть доступны извне. Сегодня мы расскажем, что произошло, что мы уже сделали и что еще предстоит сделать.

Что случилось

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

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

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

Что происходило дальше

В период сбоя телефония была недоступна. Ребята из поддержек, из офиса и дома, не имея доступов к тикетам и телефону, переключились на сообщества в VK и Telegram.

В этот момент инженеры находились в поиске временного решения, которое позволит вернуться сервису в строй. К 18:55 МСК мы восстановили доступность сети.

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

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

Что нам предстоит

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

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

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

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

Мы приносим извинения каждому, кто испытал сложности с доступом или понес финансовые/репутационные потери из-за аварии. И благодарны вам за взвешенную позицию и слова поддержки, которые вы писали, пока мы в поте лица занимались решением проблемы. Спасибо вам за доверие ❤

0
89 комментариев
Написать комментарий...
Alexey Oderey

Тоже отчитаюсь о том что случилось и над чем сейчас работаем. Примерно месяц назад наш VDS падал на час, вопросов нет, падал только наш, а не весь таймвеб, но нам от этого было не сильно легче. Чтобы вы понимали суть проблемы, мы используем в 50 суши точках свою самописную црм по типу dodo is и при таких падениях работа фактически встает, заказы не поступают, а текущие не оформляются и не завершаются, думаю примерные потери вы понимаете. Спустя месяц происходит это падение на 3 часа.  Как-то многовато падений для такого малого промежутка времени. Клиенты нам задавали вопросы на которые у нас не было ответов благодаря «супер оперативному и информативному информированию» от таймвеба. Сейчас в усиленном режиме работаем над переездом на другой (не российский) хостинг, с середины января думаю уже полностью уйдем от таймвеба. Да и чуть не забыл, даже если вы не покупали хостинг, а просто купили домен у таймвеба, то ваш сайт тоже будет лежать так как их днс-сервера тоже небыли доступны, так что рекомендую переносить всё, а не только хостинг. 
P.S клиент таймвеба с 2008 года.

Ответить
Развернуть ветку
Валентин Баранов

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

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

Ответить
Развернуть ветку
Alexey Oderey

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

Ответить
Развернуть ветку
Валентин Баранов

Надеюсь, у вас есть резервирование данных? Некоторое время назад мастерхост умер дней на 10, так что 4 часа Таймвеба это ещё мелочи) и да, там очень страдали те, у кого домены были зареганы у хостера.

Ответить
Развернуть ветку
Alexey Oderey

Ну уж не на столько все плохо) данные не на timeweb хранятся, и резервируются.

Ответить
Развернуть ветку
Валентин Баранов

Главное проверяйте бэкапы периодически) иначе бывает «неожиданный конец архива», и седой админ в 30 лет)

Ответить
Развернуть ветку
86 комментариев
Раскрывать всегда