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

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.