Робочий день повільно, але впевнено добігав кінця. Сонячне світло струмитося крізь жалюзі і заливали офіс золотистим багрянцем. Десь у кутку жужжала кавомашина, видавлюючи залишки кави з капсули. Наш проджект щось жваво обговорювала з дизайнером, а я правив косяки, люб'язно залишені мені молодшим програмістом.
І все начебто нічого, якби не повідомлення: «А що у вас з сайтом 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, може порушити працездатність будь-якого (майже) іншого сайту (так само використовує APC), в межах даного хостингу (точніше сервера).
Як наслідок - збитки через простій сайтів і, можливо, крадіжка даних, адже закешувати можна все, що завгодно.
Невже така логіка роботи хостингу є нормальною?
Після недовгої дискусії з розробниками сайту R, ми дійшли висновку, що можна просто виставити різний BX_CACHE_SID для наших сайтів.
Очевидно, що є певна проблема, так як сайт T пропрацював на даному Хостінгу близько півтора років і ніяких нарікань подібного характеру не викликав. А тут раптом такий казус.
Чому саме з сайтом R змішався наш кеш?
Чому не передбачено жодних механізмів розмежування кешу різних акаунтів на такому великому хостингу?
З цими питаннями я відправився додому. Вони не йшли з моєї голови до самого вечора.
Біля порога я був радо зустрінутий, вже встигла скучити за мною, дружиною, а на столі стояв гарячий і апетитно пахнучий вечерю.
«Це непорозуміння закінчилося» - подумав я з полегшенням.
Так, коли-небудь ми обов'язково займемося іграми...
UPD 1: обміркувавши коментарі, прийшов до висновку, що необхідно підвести коротке резюме по всьому вищесказаному
Завжди виставляйте унікальний ID кешу і регулярно робіть бекапи
UPD 2: В результаті спілкування з тех.підтримкою Хостінга, з'ясувалося, що вони взагалі не надають послугу поділу кешу акаунтів.
Дали контакти директора служби тех.підтримки, на які можна направити свої побажання по роботі хостингу.
UPD 3: Начальник служби тех.підтримки Хостінга поділився зі мною чудовою інформацією про те, що зараз ведеться розробка нового хостингового середовища, в якому буде передбачено поділ кешів акаунтів.
