Поучительная история о том, что может случиться с сайтом на shared-хостинге
Рабочий день медленно, но уверенно подходил к концу. Солнечный свет струился сквозь жалюзи и заливали офис золотистым багрянцем. Где-то в углу жужжала кофемашина, выдавливая остатки кофе из капсулы. Наш проджект что-то оживлённо обсуждала с дизайнером, а я правил косяки, любезно оставленные мне младшим программистом.И всё вроде бы ничего, если бы не сообщение: «А что у вас с сайтом T?».Один мой хороший знакомый заметил, что один из наших сайтов отображается некорректно и дал мне знать.Я отбросил все дела загрузил страничку с сайтом. Никаких проблем на ней не наблюдалось. Ну, разве что требовался небольшой редизайн…«С сайтом всё в порядке» — написал я знакомому и снова погрузился в увлекательный мир кода и багов.Через некоторое время, мой мозг всё же вынул из памяти тревожный сигнал моего знакомого и я невольно полез повторно проверять сайт. Отчего-то уверенный в работоспособности сайта, я испытывал лёгкую самоуверенность.Главная страница сайта, уныло встретила меня сбившейся кодировкой и полным отсутствием css. Черные символы абракадабры на девственно-белом фоне вернули меня в реальность. Самоуверенность моментально улетучилась и я начал лихорадочно вдавливать CTRL+F5 в клавиатуру.«Это просто кэш… Да… Просто кэш…» — повторял я себе раз за разом.Когда я осознал, что моя десятая по счёту попытка сбросить кэш браузера не даёт никаких результатов, а главная страница сайта продолжает изменять своё обличие с каждым нажатием на заветные клавиши, первое, что пронеслось в моей голове — «Взлом?!». Мои опасения начали крепнуть, когда после очередной перезагрузки страницы, я увидел красную по белому надпись, в которой говорилось, что такая-то таблица не была найдена.Руки сами пустились менять все, имеющие отношение к сайту, доступы: админка, база данных, SSH.После, я начал внимательно изучать логи. Хотя, логи — это громко сказано. В моем распоряжении были только отчеты по работе веб-сервера. Журналы сбоев MySQL и неудачных попыток авторизации через SSH, на shared-хостинге не выдают.Ничего странного в логах небыло выявлено и я направился прямиком в SSH консоль для того, чтобы соединиться с MySQL напрямую, ведь я отчетливо помню, что сайт ругался на отсутствие таблиц в базе данных.Очень странно, но все таблицы были на месте (по крайней мере те, на которые ругался сайт, точны были на месте).В качестве CMS, на сайте T, используется 1С-Битрикс. Мы очень любим эту систему и всячески ею восторгаемся (за редким исключением).Каково же было мое удивление, когда, зайдя в настройки сайт, я увидел данные от совершенно постороннего сайта R. Путь к корню, имя домена и некоторые другие настройки — были изменены. Я, остолбеневший, смотрел в монитор круглыми от удивления глазами. В то же время, где-то позади меня, наш проджект уже разливала настойку валерьяны. Я зачем-то нажал F5. То, что произошло после этого, повергло меня в глубочайший шок и уныние. Настройки сайта вновь приняли нормальные значения.В этот момент, я на мгновение усомнился в адекватности всей IT-индустрии в целом и начал верить в чудеса. Телефонный звонок супруги вывел меня из ступора. Я поднял трубку. До сих пор не могу вспомнить о чем она мне говорила, так как ощущение чего-то загадочного не покидало меня и мой мозг лихорадочно пытался найти хоть какое-то объяснение случившемуся.Я что-то буркнул в трубку и дал отбой. Ну теперь, я хотя бы в чем-то уверен. Уверен, что дома меня ждет много интереснейшей информации о самом себе.Но это потом, а сейчас надо понять — что происходит.
После следующей перезагрузки страницы с настройками, я вновь увидел чужие значения.Судя по абсолютному пути до корневой папки веб-сервера, у нас были прописаны настройки сайта, которых располагался на том же Хостинге что и мы.Я моментально нащупал рукой телефонную трубку и позвонил в тех.поддержку Хостинга.Из разговора стало понятно, что решить наши проблемы прямо сейчас они не в состоянии. Сотрудник тех.поддержки вежливо дал мне понять, что мне стоит написать обращение по электронной почте и мое обращение будет рассмотрено в течение суток, в порядке живой очереди. После того как я, столь же вежливо, высказал им всё, что я о них думаю, я положил трубку и написал им, наполненное эпитетами, письмо. На всякий случай, мы так же написали письмо и в тех.поддержку 1С-Битрикс.Мертвую тишину офиса нарушало лишь тиканье больших настенных часов и еле слышный шум системы охлаждения системного блока. Белоснежные часы округлой формы, выполняли в офисе несколько функций. Во-первых, они являлись элементом интерьера. Мебели у нас в офисе не много, ничего лишнего. Хотя, я совершенно не против прикупить большой и мягкий диван, чтобы в перерывах между задачами, можно было лечь с чашечкой кофе в руках и, вытянув ноги, погрузиться в мечты о том, что когда-нибудь мы отойдем от разработки сайтов и займемся разработкой интереснейших и конечно же инновационных, с точки зрения геймплея, игр.Во-вторых, эти белоснежные круглые часы таки выполняли заложенную в них функцию — они показывали время. Если кому-то нужно было узнать время, то он непременно поворачивался к этим часам. Они обладают каким-то необъяснимым и почти гипнотическим влечением. И никого не волновало, что в смартфоне под рукой, или на экране монитора, тоже есть часы.
Вот и в этот момент наш педантичный надзиратель неумолимо отсчитывал время с каждым шагом секундной стрелки.А мы всё ждали, что вот-вот, уже сейчас, наш почтовый сервер примет долгожданный ответ от какой-нибудь из тех.поддержек.Но письма всё не было. Ни о какой работе и речи быть не могло. Мой мозг, гоняя серое вещество, пытался разгадать эту странную метаморфозу с сайтом T.Понимая, что если сайт в таком состоянии увидят его посетители, они явно не обрадуются, я полез закрывать его от общего доступа. Тем более, если имеет место взлом, то вполне возможно, что сайт уже полон инъекций, с целью кражи cookie-файлов, а значит, посещение данного сайта абсолютно противопоказано.После нажатия заветной кнопки в настройках главного модуля, сайт погрузился в анабиоз.Я, из любопытства, зашел на сайт R, чьи настройки были прописаны в настройках нашего сайта.«Site Under Construction» — красовалось на главной странице сайта R.Мозг попытался установить связь между двумя последними событиями и я снова открыл доступ к сайту T.Вновь зайдя на сайт R, я увидел, что и он восстановил свою работоспособность.Совпадение или зависимость? Повторив манипуляции в настройках главного модуля, я убедился, что здесь имеет место зависимость сайта R от нашего сайта T и наоборот.Но как такое может быть? Всё, чем связаны сайты T и R — это хостинг.
«А давайте позвоним по телефону, указанному на сайте R и попытаемся объяснить им ситуацию» — неожиданно для всех предложила наш проджект.Не успели мы ощутить всю гениальность этой идеи, как вдруг в офисе раздался телефонный звонок.На том конце трубки были ребята, которое разрабатывали сайт R и в данный момент тоже находятся в недоумении от происходящих событий.Мне передали трубку.После недолгого разговора, выяснилось, что они, так же как и мы, понятия не имеют о причинах происходящего.«Видимо на хостинге, каким-то непонятным образом, имеется символическая ссылка между двумя нашими базами» — предположил я.Ну, а какое еще объяснение тут можно было найти? Доступы к обоим базам — разные, но, каким-то странным образом, изменения в их базе данных, влияют на нашу и наоборот.«Вы пробовали создать другую базу данных?» — продолжал я.«Да, это уже третья» — с грустью в голосе ответили мне на том конце трубке.Таким образом, вариант с символической ссылкой не выдерживал никакой критики.Те ребята тоже написали обращение в тех.поддержку Хостинга. Мы обменялись именами, скайпами и телефонами, условившись держать друг-друга в курсе событий.Вестей от тех.поддержки Хостинга всё не было. Я вновь набрал из номер и начал объяснять сотруднику тех.поддержки, что ситуация патовая и одна и та же проблема наблюдается уже на двух аккаунтах Хостинга.Ничего внятного в ответ я так и не услышал. По окончанию бессмысленного и безрезультатного разговора, я окончательно убедился в том, что тех.поддержка Хостинга нам точно не поможет.Ну, по крайней мере было ясно, что это не взлом.С этого момента, я перестал надеяться на тех.поддержку Хостинга и взял всё в свои руки.
Что-то подсказало мне, что я получу ответы на свои вопросы, зайдя в список таблиц через админку 1С-Битрикс. Ну на самом деле, других вариантов откуда можно было бы начинать поиски, не было.Я был удивлен не менее прежнего, когда обнаружил, что содержимое таблицы b_lang (где хранятся настройки сайтов) и содержимое админской страницы настроек сайта — разнятся.Что за чертовщина?! Как такое может быть?! «Их два!» — мелькнуло у меня в голове.«Соединений с базой данных — два» — я всё больше укреплялся в этой мысли.Как иначе объяснить, что админка показывает одно, а содержимое таблиц — другое? Еще немного развив эту идею, я вспомнил про постоянные соединения с базой данных.Хотя, судя по описанию технологии постоянных соединений, они разграничены как минимум именем пользователя и паролем при подключении к базе, а эти данные у сайтов R и T — разные.И все-таки, может ли система кэширования как-то запомнить соединение и отдавать его при двух абсолютно разных подключениях? К этому моменту я уже готов был поверить во всё, что угодно.Я отключил функцию постоянных соединений в настройках 1С-Битрикс и, заодно, тип кэширования оставил пустым (до этого там стояло значение — «APC»).То же самое я попросил сделать и моих коллег по несчастью.Когда всё было готово, я нажал F5. Это были самые долгие и волнительные секунды моей жизни. Ну не может быть всё так просто.Наконец страница загрузилась и… сайт заработал! У сайта R тоже всё было в порядке. Был только один способ проверить, всё ли нормально. Я зашел в настройки главного модуля и снова отправил сайт в состояние «Under Construction». Сайт T, послушно последовал данному указанию, а сайт R оставался в рабочем состоянии. Этот факт говорил нам о том, что проблема успешно решена и базы больше не связаны между собой.Но в чем же проблема? В постоянных соединениях или в кэшировании? Удалось выяснить, что проблема заключалась в том, что у сайтов, которые вообще никак не связаны между собой, перемешался APC-кэш.
1С-Битрикс, в файле dbconn.php, принудительно кэширует следующие таблицы:
b_file b_file_bucket_size b_lang b_option b_lang_domain b_site_template b_event b_agent Список может отличаться.Среди прочих таблиц, здесь отчетливо видна та самая b_lang, где хранятся настройки сайтов. Следовательно — сайты T и R попеременно записывали данные в эту таблицу и кэшировали ее в APC. Когда сайт R кэшировал таблицу, сайт T брал закэшированную копию и наоборот.Но вот самый главный вопрос — как возможно на хостинге, с тысячами работающих аккаунтов, смешивание кэша? Ведь получается, что кэш любого сайта, использующего APC, может нарушить работоспособность любого другого сайта, в пределах данного хостинга (точнее сервера).Как следствие — убытки из-за простоя сайтов и, возможно, кража данных, ведь закэшировать можно всё, что угодно.Неужели такая логика работы хостинга является нормальной? После недолгой дискуссии с разработчиками сайта R, мы пришли к выводу, что можно просто выставить разный BX_CACHE_SID для наших сайтов.Очевидно, что есть определенная проблема, так как сайт T проработал на данном Хостинге около полутора лет и никаких нареканий подобного характера не вызывал. А тут вдруг такой казус.Почему именно с сайтом R смешался наш кэш? Почему не предусмотрено никаких механизмов разграничения кэша разных аккаунтов на таком большом хостинге? С этими вопросами я отправился домой. Они не уходили из моей головы до самого вечера.У порога я был радушно встречен, уже успевшей соскучиться по мне, супругой, а на столе стоял горячий и аппетитно пахнущий ужин.«Это недоразумение закончилось» — подумал я с облегчением.Да, когда-нибудь мы обязательно займемся играми…
