Мы, как настоящие Шерлоки, ищем, изучаем и анализируем ситуацию, пока не дойдём до истины. И временами бывает, что истина где-то рядом, но добраться до неё не так просто.
К нам обратился с проблемой наш клиент: их сайт периодически падал. В разное время суток, но происходило это почти каждый день по несколько раз. Просто в какой-то момент сайт перестаёт загружаться в браузере и выдаёт ошибку до тех пор, пока не будет выполнена перезагрузка сервера.
С самого начала вопросов было немало. Во-первых, сайт хостился на отдельном виртуальном сервере клиента, с которым мы ранее не работали. Было непонятно, кто и как его настраивал и настраивал ли, насколько адекватно подобрана конфигурация.
Во-вторых, сайт был разработан не нами. И, несмотря на то что под капотом у него был привычный фреймворк Yii2, при поверхностном изучении кода логика казалась не интуитивной и неочевидной.
В-третьих, на сайте была настроена синхронизация с внешним сервисом, выдающим актуальную информацию по товарным позициям путём предоставления XML-выгрузки. К сожалению, никакой документации по обработке выгрузки на сайте не было.
При первичном осмотре сервера была обнаружена аномальная нагрузка на него. Бинго! Сервер заражён вредоносным скриптом-майнером. Вдаваться в подробности не будем, но уязвимость закрыли, майнер удалили — злоумышленники больше не смогут генерировать биткоины за наш счёт. Окей, нагрузка снизилась — но сайт продолжал падать.
Изучили логи сервера на наличие ошибок — не обнаружили ничего, что могло бы указывать на возможную причину.
Обратились к системным администраторам для диагностики возможных причин. На протяжении нескольких дней мы совместно пытались определить проблему. Устанавливали специальный софт для диагностики, меняли настройки сервера, оптимизировали его работу. Ситуация немного улучшилась, падения стали происходить реже — но всё равно продолжались.
Мы изучали и оптимизировали код, логику синхронизации данных. Иногда, обнаружив слабое место и исправив его, были уверены, что вот оно, наконец-то всё поняли, разобрались — и про падения сайта теперь можно забыть. Но уже менее чем через сутки получали уведомление от робота, что сайт снова недоступен.
Мы пробовали менять конфигурацию виртуального сервера, что тоже не дало результата. Следующим шагом должен был быть перенос и тестирование сайта на нашем сервере. Процесс не всегда быстрый, учитывая большой объём данных проекта. Тем не менее, до этого шага мы так и не добрались, решив проблему на стороне программирования. Детально изучив скрипт синхронизации данных, пошагово проанализировав его работу, мы обратили внимание, что иногда запросов к базе данных генерируется слишком много. Проблема была решена увеличением лимитов запросов к базе данных и установкой микрозапаздывания между выполнением операций к базе PHP-функцией usleep. Вот уже несколько недель сайт работает как часы.
Как же так, неужели нельзя было понять причину сразу, а не спустя часы диагностики, попыток, проб и ошибок?
Возникновение разного рода неполадок, перегрузов на сайтах клиентов — дело не обыденное, но сталкиваться с ним приходится. Причины, как правило, определяются и устраняются оперативно, так как вся информация на виду. Здесь же мы не имели практически никаких зацепок. А те, что были, иногда противоречили друг другу. Если дело в скрипте синхронизации, которая происходила в начале часа, — почему сайт периодически падал в конце часа? Если синхронизация не происходит ночью, почему падения были и в это время суток? Почему после разработки сайта падений не было несколько лет, а потом начались, хотя с тех пор код обработки выгрузки не менялся? К сожалению, не всегда всё так очевидно, как хотелось бы, и, чтобы решить проблему, приходится не только детально погружаться в логику работы сайта, но и хорошенько поэкспериментировать.
Алгоритм импорта сам по себе оказался тяжёлым в силу особенностей архитектуры проекта. Нами была проведена его оптимизация таким образом, чтобы нагрузка на базу данных была более сбалансированной. А, собственно, начались падения в то время, когда количество товарных позиций на сайте, а вместе с этим и количество запросов к базе данных, сильно возросло.
Какой вывод можно сделать из этой истории?
- Мало разработать сайт. Важно, чтобы код и запросы к базе данных были оптимизированы. Чем сложнее и нагруженнее планируется сайт, тем это правило актуальнее. Выбирайте компанию, в компетенциях которой уверены.
- Даже простая поверхностная документация сложной системы со стороны разработчиков в будущем может хорошо сэкономить вам время и деньги.
- Не экономьте на хостинге/сервере (во втором случае — и на его настройке). Иногда в погоне за сэкономленными 200 рублями в месяц можно потерять гораздо больше. Торможение и падения, кроме всего прочего, негативно влияют на SEO, сайты могут заметно понижаться в выдаче поисковых систем. Хоститься лучше на сервере с запасом ресурсов.
- Ну и, конечно, вопрос безопасности. Разработчики должны уделять ему особое внимание, знать о возможных уязвимостях и не допускать их. Владельцы сайтов должны бережно относиться к доступам, надёжно хранить пароли, менять в случае смены подрядчика.
