Срочное устранение проблем на сайте

Клиент: Интернет-магазин спортивной одежды на 1С-Битрикс (Аспро: Максимум).
Ситуация: Воскресенье, 14:00. Владелец магазина решил самостоятельно обновить модуль торгового каталога, чтобы «всё было по красоте». После обновления сайт перестал открываться — белый экран и ошибка 500. Заказы не принимаются, клиенты уходят к конкурентам.
Что сделано (экстренно, в течение 2 часов):

1. Приём сигнала: Клиент позвонил в панике через 15 минут после неудачного обновления.
2. Диагностика: Через FTP получил доступ к файлам. Включил режим отладки Битрикс (bitrix/.settings.php) и увидел в логах фатальную ошибку: несовместимость нового модуля с версией PHP на сервере.
3. Быстрый откат: У клиента, к счастью, была резервная копия, сделанная хостингом прошлой ночью. Восстановил файлы модуля из этой копии (перезаписал папку модуля).
4. Проверка: Сайт сразу открылся. Проверил ключевые разделы: каталог, корзину, оформление заказа — всё работало.
5. Консультация: Объяснил клиенту, что перед обновлением нужно проверять совместимость и всегда делать резервную копию. Предложил на будущее делать это через меня или в рамках абонентского обслуживания.
6. Результат: Сайт восстановлен за 2 часа. Потеряно около 15–20 заказов за это время, но клиент избежал простоя на весь день.

Клиент: Сайт стоматологической клиники на WordPress.
Ситуация: Утро понедельника. Сайт открывается, но через 3 секунды происходит автоматический редирект на страницу подозрительного онлайн-казино. Пациенты жалуются в мессенджеры. Репутация клиники под угрозой.
Что сделано:

1. Диагностика: Проверил исходный код страниц через браузер — обнаружил зашифрованный JavaScript-скрипт, вставленный в футер. Скрипт грузился со стороннего домена.
2. Изоляция: Немедленно заблокировал доступ к сайту через .htaccess (вывел заглушку «ведутся технические работы»), чтобы остановить редирект и не пугать посетителей.
3. Очистка: Через FTP и phpMyAdmin тщательно проверил все файлы и базу данных. Удалил вредоносный код из файлов темы и нашёл подозрительного пользователя в админке с правами администратора (удалил его).
4. Усиление защиты: Сменил все пароли (к базе, FTP, админке), обновил ядро WordPress и все плагины до актуальных версий, установил плагин безопасности для мониторинга.
5. Восстановление: Убрал заглушку. Сайт заработал чисто.
6. Результат: Сайт восстановлен через 4 часа. Репутация спасена. Клиент заказал абонентское обслуживание для регулярного мониторинга безопасности.

Клиент: Новостной портал на Django.
Ситуация: Пятница, вечер. Трафик на сайт резко вырос из-за вышедшей горячей новости. Сервер не справляется: страницы грузятся по 30 секунд, база данных падает с ошибкой «Too many connections». Читатели уходят, реклама не грузится.
Что сделано (срочная оптимизация без отключения сайта):

1. Анализ на живую: Зашёл на сервер по SSH, запустил top и htop — увидел, что процессор загружен на 100%, памяти почти нет. Проверил логи MySQL — множество медленных запросов к одной таблице.
2. Быстрые правки:

• Добавил индексы в проблемную таблицу через phpMyAdmin (это немного ускорило запросы).
• Временно отключил несколько «тяжёлых» виджетов на главной (слайдер последних комментариев), которые генерировали сложные запросы.
• Включил агрессивное кэширование страниц для анонимных пользователей на уровне сервера (кеш на 5 минут).

1. Мониторинг: После каждой правки проверял нагрузку. Через час сайт стабилизировался: страницы открывались за 3–4 секунды, сервер дышал.
2. Рекомендация: Посоветовал клиенту перейти на более мощный тариф VPS и настроить нормальное кэширование.
3. Результат: Пик трафика пережит без полного падения. Клиент не потерял аудиторию в критический момент.

Клиент: Сайт-портфолио фотографа на самописной PHP-системе.
Ситуация: Клиент сам решил почистить сервер и случайно удалил папку с изображениями за несколько лет работы. Сайт открывается, но все фотографии отсутствуют, на их месте — битые ссылки. Паника.
Что сделано (срочное восстановление за 3 часа):

1. Успокоил клиента: Первым делом объяснил, что удалённые файлы часто можно восстановить, если на диске ничего не перезаписывалось.
2. Запретил запись: Немедленно попросил хостинг отключить запись на диск, чтобы новые данные не перезаписали старые сектора.
3. Восстановление из бэкапа хостинга: У хостинга была резервная копия за вчерашний день. Через панель управления запросил восстановление папки с изображениями из этой копии. Процесс занял около часа.
4. Проверка: После восстановления проверил несколько случайных страниц — все изображения на месте.
5. Профилактика: Настроил автоматическое резервное копирование на внешний диск, чтобы в будущем не зависеть от хостинга.
6. Результат: Все фотографии восстановлены. Клиент облегчённо выдохнул и заказал настройку бэкапов.

Клиент: Интернет-магазин на WooCommerce.
Ситуация: Внезапно обнаружилось, что при оплате заказа через карту деньги с клиентов списываются, но в административной панели магазина заказы не появляются. Менеджеры не видят новые заказы уже несколько часов. Часть клиентов уже позвонила с возмущением.
Что сделано:

1. Блокировка проблемы: Немедленно переключил платёжный шлюз в тестовый режим, чтобы новые оплаты не проходили, пока мы чиним.
2. Диагноз: Проверил логи платежей и логи WooCommerce. Оказалось, что после обновления плагина платежного шлюза перестал корректно обрабатываться callback-запрос от банка (статус «оплачено» не передавался в магазин).
3. Откат плагина: Быстро откатил плагин платежного шлюза до предыдущей рабочей версии.
4. Ручная обработка: За это время накопилось около 15 успешных оплат, по которым заказы не создались. Мне пришлось вручную, сверяясь с логами банка, создать эти заказы в админке и отправить клиентам подтверждения.
5. Тестирование: Проверил оплату на тестовом заказе — всё заработало.
6. Результат: Деньги клиентов не потеряны, все заказы восстановлены. Репутация магазина спасена. Клиент теперь знает, что обновлять платёжные модули нужно только после тщательной проверки на тестовом контуре.