Блог Директ Лайн

Всё началось с того, что у сайта одного из наших клиентов появились проблемы с доступностью. Сайт открывался минимум за 20 секунд. Или же страницы вовсе не открывались (без возврата какой-либо ошибки - просто «Веб-страница недоступна»).

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

Первым делом я стал искать проблему в самом движке сайта. Были проверены все скрипты, время обращения к базе, рациональность запросов и т.п. В самом худшем случае страницы генерировались за 200-250 мс. Это – нормально. Да и средства отладки в браузерах говорили о том, что провисает запрос именно на ожидании ответа от сервера.

Масло в огонь добавило ещё то, что различные городские поддомены сайта открываются так же с переменным успехом. Например, http://novosibirsk.teplodar.ru прогружается с адекватной скоростью, а http://voronezh.teplodar.ru вдруг подвисает. Поддомены – это просто алиасы. Движок, отдающий контент – один. И отдает он этот контент максимум за 200 мс. Так в чём же дело?

Что бы исключить влияние браузеров и кэша идем в консоль и пытаемся получить сайт, что называется, «в чистом виде» - wget’ом. Долбим один и тот же сайт подряд и видим, что страница выгружается раз через раз. То моментально – то вообще по таймауту отваливается. Уже интересно.

Делаем:

debiantest:/home/stas# nslookup teplodar.ru
Server: 80.242.64.7
Address: 80.242.64.7#53

Non-authoritative answer:
Name: teplodar.ru
Address: 90.156.201.36
Name: teplodar.ru
Address: 90.156.201.55
Name: teplodar.ru
Address: 90.156.201.57
Name: teplodar.ru
Address: 90.156.201.81


Видим 4 разных IP адреса. И каждый раз при новом запросе они тасуются – на первое место встают разные адреса. Работает балансер нагрузки, нормально.

Пингуем по очереди эти 4 адреса и обнаруживаем, что 90.156.201.81 не отвечает. Сделаем трассировку до него:

debiantest:/home/stas# tracert 90.156.201.81
traceroute to 90.156.201.81 (90.156.201.81), 30 hops max, 40 byte packets
1 gw1.ksn.ru (80.242.76.1) 0.215 ms 0.227 ms 0.248 ms
2 ip64-69.ipblk.ksn.ru (80.242.64.69) 0.406 ms 0.410 ms 0.404 ms
3 fe1-0-1-8.ll-nsk.zsttk.ru (80.89.128.81) 13.036 ms * *
4 nsk15.nsk25.transtelecom.net (217.150.59.118) 1.527 ms 1.534 ms 1.527 ms
5 TTK-lgw.Moscow.gldn.net (194.186.0.193) 58.250 ms 58.040 ms 58.630 ms
6 * * *
7 * * *
8 * * *
9 * * *
10 * * *


А на остальные адреса запрос проходит в 9 хопов. И славный узел TTK-lgw.Moscow.gldn.net, который судя по всему является шлюзом между Транс Телекомом и Голден Телекомом проходит особо не задерживаясь. Беда-беда с этим 90.156.201.81. Точнее на пути к нему.

Гугление показало, что на TTK-lgw.Moscow.gldn.net с завидной периодичностью возникают какие-то проблемы – то выборочно адреса какие-то через него недоступны, то пинг на нём вырастает до 200-300 мс.

Я думаю, не надо объяснять чем эта ситуация печальна. Статистика показывает, что эти глюки прямо влияют на показатели отказов, глубину просмотра и на общую посещаемость сайта. Четверть пользователей, впервые обращаясь к сайту или любому из его поддоменов, не могут дождаться загрузки (ещё бы – ожидание от сервера было минимум 20 секунд!). Мало того, IP адрес недоступного сервера запишется в кэш и на сайт человек не попадёт до его очистки. То есть, возможно, что и никогда. То же самое касается и поисковых роботов.

Нет, я конечно привираю – четверть это слишком. Проблемы-то, как выяснилось, настигли только пользователей тех провайдеров, у которых магистральный – ТТК. Но, во-первых – таких немало! А во-вторых, это лишь частный случай, который удалось выявить и проанализировать.

Ну что же поделать, звоним в Мастерхост! Всё как положено, соединяют с техническим специалистом. А он, не дослушав мои объяснения проблемы, выдаёт: «Так 55й айпишник заблокирован на Билайне!». Ой, и правда, чего это я пристаю с вопросами какими-то! Но, во-первых – проблема с другим адресом. А во-вторых, очень интересно, что они вот так спокойно говорят по факту «Дык добрая часть пользователей Билайна не может попасть на ваш сайт, мы в курсе, всё нормально». Никаких уведомлений, разумеется, никто не присылал. Никакие меры, судя по всему, не принимаются. Так нормально ли это?

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

Но благо саппорт Мастерхоста сработал оперативно. В течение пары-тройки часов после звонка адрес 90.156.201.81 убрали из записей ДНС сервера. Но только для домена teplodar.ru! А для куча поддоменов основного сайта и остальных 200 с лишним сайтов на этом IP остаются так же раз-через-раз доступными для очень большого количества пользователей. При повторном звонке в тех.поддержку на следующий день с просьбой убрать всё таки этот несчастный IP из записей для поддоменов получил «Конечно, уберем в течении 40 минут!». Не убрали. На третий день эпопеи звоню опять, уже ругаюсь. Выясняется, что для нескольких поддоменов ситуацию всё таки исправили (а дальше видимо смена у специалиста кончилась и он ушёл домой). Но! Для тех, которых всё-таки успели исправить – оставили из четырех один IP адрес. И именно тот, который заблокирован Билайном. «Johnny, la gente esta muy loca, WTF!?»…

Ну и напоследок ещё раз скажу об оперативности работы технических специалистов компании Мастерхост. Как-то сделал я заявку на выделенный IP адрес для сайта одного из крупных клиентов. Всё ок, сделали быстро, молодцы! Но сайт перестал грузиться. И у нас, и у клинта, и у клиентов клиента Кэш DNS. Звоню в поддержку, излагаю ситуацию, прошу сделать так, чтобы пару суток сайт был доступен и по новому IP и по старому. На что получаю «У нас нет технической возможности». Ну бред ведь. Задаю, скорее, риторический вопрос: «Ну а ночью вы могли сервер перенастроить хотя бы? Или предупредить о том как это всё интересно у вас происходит?». На что получаю железное и логичное «Ну вы же не просили».

Мораль? Даже один из самых стабильных из виртуальных хостингов работает нестабильно. Почему так происходит и кто виноват – открытые вопросы. В описанном кейсе есть и техническая сложность обнаружения проблемы, и неадекватная реакция технических специалистов на заявки, и просто «забивание» технической поддержки на заявки… Выходит, что спасение утопающих – дело рук самих утопающих.

Глаз да глаз! Будьте внимательны и зрите в корень!