Drupal Emergency: як отримати швидку допомогу з сайтами на Друпалі

16.05.2014
drupal emergency
Автор:

У нашому житті всяке буває: буває, що Друпал літає - а буває, що не літає; а буває, що взагалі падає. Це буває рідко (принаймні - у нас, скромненько так зауважимо), але, як правило, у самий неслушний момент трапляються найпідступніші проблеми.

І ось сталося страшне - ваша дівчина хвора Друпал впав і/або поламався. І частинка Миколи Гавриловича Чернишевського, що живе в кожному з нас, запитує:

1) Хто винен?

2) Що робити?

У своїй практиці ми частенько отримуємо Skype-дзвінки "АЛЛО? ЦЕ ДРУПАЛ-ХЛОПЦІ? ААААА, ВСЕ ПРОПАЛО! НЕ РОБИТЬ! SOS!", які зароджують в нас відчуття, ніби ми працюємо на швидкій допомозі... Тобто стоїть питання життя сайту, і вирішувати його треба терміново.

Не біда, ми вже звикли до форс-мажорів. Ми робимо наступне - обслідуємо пацієнта та дивимося всередину. Спочатку перевіряємо сервер на предмет проблем:

1. Чи є база даних, і якщо є, то перевіряємо її конфігурацію та стан на поточний момент.

2. Перевіряємо, чи запущено всі служби на сервері і чи вони функціонують.

3. Наявність у конфігурації веб-сервера підозрілих параметрів і їх значень.

4. Перевіряємо налаштування під Друпал, як усередині його інсталяцій, так і на рівні веб сервера.

5. Коли було зроблено останні коміти в репозиторії, і найголовніше - ким, щоб вичислити автора по айпі емейлу або по нікнейму в соцмережах.

... Слідують ще 43 перевірки...

49. Встановлюємо свої системи моніторингу всього і вся на сервері (від елементарної перевірки наявності вільного місця на диску до детального логування більшості серверних додатків).

Фіксимо сервер, оживляємо, піднімаємо, дивимося, чи живий вже пацієнт або ще швидше ні. Ліземо далі, перевіряємо сам сайт:

1. Проводимо аналіз на "чистоту" коду сайту;

2. Робимо аудит безпеки даних на сайті;

3. Аналізуємо швидкість завантаження сервісу;

4. Перевіряємо, чи встановлено на сайті останні версії необхідних модулів і ядра Друпала.

Обслідування показує всі проблеми і, звісно, їх треба вирішувати. Просимо у власника сайту дати добро та виправляємо знайдені неподобства. Ну і подальшу технічну підтримку налаштовуємо, без проблем.

Розповім про найпоказовіший приклад. Звернувся ізраїльський замовник. Сайт не показував ноду. Замовник наполегливо ноду редагував, зберігав, сайт її не показував, хоча в редагуванні все було нормально. Замовник божеволів. Ми розгорнули копію, подивилися реалізацію сайту по лінії найменшого опору, знайшли причину, і довго посміхалися... Виявилося, що в шаблоні було прописано текст в PHP-коді. І скільки ти ноду не редагуй - виведення немає. Це був найпростіший та самий цинічний епікфейл за всю нашу 7-річну практику. До цієї пори згадуємо.

Був ще такий випадок. Рано вранці приходить лист від клієнта приблизно такого змісту - "Вона хотіла видалити кролика, а видалилося все! Поможіть-рятуйте, торгувати нічим!". Заходимо на сайт, а сторінки категорій товарів порожні, хоч око виколи. Ясно, як білий день, що проблему створили невмілі дії контент-менеджера над словником таксономії. А замовлення з сайту-то йдуть конвеєром, відкочувати базу даних не варіант (ніхто ж не бекапить кожну хвилину). Пощастило звичайно, що наш адмін налаштував систему щоденних бекапів на самий ранок. Та й навряд чи хто з 3 ночі до 8 ранку буде сметану в інтернет-магазинах замовляти. Відкотилися до найсвіжішого бекапу, провели курси підвищення кваліфікації для контент-менеджера, та й повернулися в звичайний робочий режим.

Ну і ось такий ще був такий прикол. Клієнти нам траплялися-то різні: і дуже серйозні, і не дуже (я зараз про почуття гумору , якщо що, а ви про що подумали?). Так от, був у нас такий замовник, який дуже терміново зажадав запуску бета-версії сайту. Як грім серед ясного неба! Що в цьому смішного, запитаєте ви? У клієнта була на це ну дуже вагома причина... Виявляється, прочитавши свій гороскоп, він дізнався, що це був дуже сприятливий день для розміщення сайту :) Куди тут попреш проти "пророцтва" оракула? Звичайно ж, прохання такого забобонного клієнта ми тремтячими руками виконали. Як кажуть, якщо треба, то "поїхали!" ©

Отже, спираючись на свій 7-річний досвід практикуючих психологів друпалерів ми прийняли вольове колективне рішення надати світу системний сервіс швидкої Drupal-допомоги. Недовго думаючи, ми назвали його просто Drupal Emergency. Плануємо в майбутньому зняти серіал "Drupal-Інтерни", на всякий випадок.

Щодо самого сервісу - телефонуйте нам хоч вночі (але це буде дорожче). Вдень - простіше. А якщо випадок нам сподобається - то й по-приколу розрулимо, для історії :)

Голосів: 1 Рейтинг: 5

Також по темі

1

На даний час сервіси з готовими html-темами набирають стають дедалі популярнішими. Однак, чи так вже легко верстати на їх основі Drupal-сайти?...

2

Часто на адресу Drupal можна побачити заяву в стилі: «На цьому фреймворці не створити high-load веб-сайту». Ми спростуємо цей міф не...

3

При прийнятті рішення запустити власний вебсайт одним із найважливіших питань є вибір реалізації - CMS чи самопис? Дізнайтеся більше про переваги фреймворка Drupal.

4

Нещодавно ми представили "золотий" список SEO модулів, рекомендованих для успішної пошукової оптимізації...

5

Серед десятків тем для Drupal не важко й заблукати. Ми підготували огляд найкорисніших та популярних тем серед тих, які в можете знайти ...

Subscribe to our blog updates