Почти все владельцы сложных веб-проектов сталкивались с неожиданными поломками функционала. Ещё вчера всё работало как часы — а сегодня накрылся функционал заказа или регистрации. Вдвойне странно если программисты ничего в последние дни не меняли, но даже если работы велись, причина поломки может быть с ними не связана. Расскажу про основные узкие места.
Ошибка разработчика
Даже хорошие программисты не застрахованы от ошибок. Чаще всего виновата элементарная усталость — внимание притупляется, что и даёт возможность проскочить обидной ошибке в код.
Чаще всего такие ошибки хорошо заметны внешне и быстро обнаруживаются (например, не нажимается кнопка “Купить”). Но такие ошибки так же быстро исправляются.
Реальная проблема возникает в случаях, когда разработчик постоянно повторяет одну и ту же ошибку из раза в раз. В большинстве случаев достаточно обратить внимание разработчика на это.
Что провоцирует подобные ошибки?
- Срочные задачи, которые нужно решать “здесь и сейчас”.
- Постоянная перегруженность разработчика. Работать по 12-14 часов в сутки — это плохо.
- Работа над кодом по ночам. Это частая проблема разработчиков, ночью никто не отвлекает от процесса работы и кажется, что работается лучше. Однако, ближе к полуночи внимание сильно притупляется, а человек этого как правило не замечает.
- Постоянное отвлечение разработчика от кодинга вопросами и небольшими несрочными задачами. Чатики и звонки в большинстве случаев — это большое зло. Лучше запланируйте с вашим разработчиком планерку в определенное время, а небольшие задачи старайтесь формулировать и отправлять в письменном виде.
Ошибка вследствие действий разработчика
Очень часто путают с первым вариантом, но этот класс ошибок сильно отличается от предыдущего. Суть проблемы в том, что в результате внесения правок в одном программном модуле совершенно непредсказуемо может сломаться другой. Разработчик, естественно, проверяет результат только той работы, которой непосредственно занимался, и не смотрит на остальной функционал
Таких проблем будет меньше, если:
- Проект развивают те программисты, которые изначально его разрабатывали и знают “от и до”.
- Проект хорошо документирован. Тогда даже новые разработчики смогут достаточно быстро разобраться в неочевидных взаимосвязях.
- Разработка ведётся на отдельном dev-сервере.
- Весь основной функционал проекта перед выкаткой изменений на “боевой” сервер предварительно тестируются. А потом ещё раз тестируется на “боевом”.
Ограниченность ресурсов сервер
Такие проблемы возникают с ростом проекта.
Растет количество информации в базе данных. Со временем тяжелые запросы к такой начинают вешать базу. Например, в какой-то момент перестанет нормально работать сложный фильтр по товарам в интернет-магазине.
Растет трафик на сайт либо сайт подвергается DDOS-атаке. Ресурсы сервера всегда ограничены, особенно если говорить про виртуальный хостинг. Поэтому с какого-то момента весь сайт или отдельные его страницы могут перестать открываться или станут делать это крайне медленно.
Если у вас виртуальный хостинг или VDS, то на физическом сервере, на котором расположен ваш проект, может появиться другой «тяжелый» проект из-за которого ваш может начать работать значительно хуже и медленнее.
Что делать:
- Оптимизировать запросы и архитектуру проекта. Довольно затратная и долгая процедура, но это того стоит.
- Если оптимизация не дает нужных результатов или по каким-то причинам невозможна, то придется переезжать на более мощный сервер.
Изменения и обновления программного обеспечения
Любой веб-проект — это довольно сложная система: функционал работает под управлением CMS сайта, которая в свою очередь работает под управлением ПО сервера, которое работает под управлением операционной системы сервера. И это довольно упрощенная схема.
Десятки программ работают одновременно, в связке друг с другом, и время от времени обновляются или заменяются на аналогичные. Иногда это приводит к непредсказуемым конфликтам, которые ломают интернет-проект.
Частично защититься от этого можно если проект работает на отдельном «железном» сервере и после каждого изменения проводится полное функциональное тестирование проекта.
Выводы
Не бросайтесь искать виноватого. Исследуйте проблему вместе с вашими разработчиками. Больше чем в половине случаев причина не так очевидна, как кажется на первый взгляд.
Доверяйте разработчикам — они, как правило, умные и честолюбивые люди и стремятся исправлять свои ошибки, дайте им такую возможность.
Поставьте точный срок исправления бага и до его окончания не давите на разработчиков. Однако, если срок вышел, а проблема так и не исправлена — вы имеете полное право применять санкции.