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