Рабочий день медленно, но уверенно подходил к концу. Солнечный свет струился сквозь жалюзи и заливали офис золотистым багрянцем. Где-то в углу жужжала кофемашина, выдавливая остатки кофе из капсулы. Наш проджект что-то оживлённо обсуждала с дизайнером, а я правил косяки, любезно оставленные мне младшим программистом.
И всё вроде бы ничего, если бы не сообщение: «А что у вас с сайтом 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 смешался наш кэш?
Почему не предусмотрено никаких механизмов разграничения кэша разных аккаунтов на таком большом ?
С этими вопросами я отправился домой. Они не уходили из моей головы до самого вечера.
У порога я был радушно встречен, уже успевшей соскучиться по мне, супругой, а на столе стоял горячий и аппетитно пахнущий ужин.
«Это недоразумение закончилось» — подумал я с облегчением.
Да, когда-нибудь мы обязательно займемся играми…
Автор: smelukov
