Почти все владельцы сложных веб-проектов сталкивались с неожиданными поломками функционала. Ещё вчера всё работало как часы — а сегодня накрылся функционал заказа или регистрации. Вдвойне странно если программисты ничего в последние дни не меняли, но даже если работы велись, причина поломки может быть с ними не связана. Расскажу про основные узкие места.

Почему ломаются проекты?

Ошибка разработчика

Даже хорошие программисты не застрахованы от ошибок. Чаще всего виновата элементарная усталость — внимание притупляется, что и даёт возможность проскочить обидной ошибке в код.

Чаще всего такие ошибки хорошо заметны внешне и быстро обнаруживаются (например, не нажимается кнопка “Купить”). Но такие ошибки так же быстро исправляются.

Реальная проблема возникает в случаях, когда разработчик постоянно повторяет одну и ту же ошибку из раза в раз. В большинстве случаев достаточно обратить внимание разработчика на это.

Что провоцирует подобные ошибки?

  • Срочные задачи, которые нужно решать “здесь и сейчас”.
  • Постоянная перегруженность разработчика. Работать по 12-14 часов в сутки — это плохо.
  • Работа над кодом по ночам. Это частая проблема разработчиков, ночью никто не отвлекает от процесса работы и кажется, что работается лучше. Однако, ближе к полуночи внимание сильно притупляется, а человек этого как правило не замечает.
  • Постоянное отвлечение разработчика от кодинга вопросами и небольшими несрочными задачами. Чатики и звонки в большинстве случаев — это большое зло. Лучше запланируйте с вашим разработчиком планерку в определенное время, а небольшие задачи старайтесь формулировать и отправлять в письменном виде.

Ошибка вследствие действий разработчика

Очень часто путают с первым вариантом, но этот класс ошибок сильно отличается от предыдущего. Суть проблемы в том, что в результате внесения правок в одном программном модуле совершенно непредсказуемо может сломаться другой. Разработчик, естественно, проверяет результат только той работы, которой непосредственно занимался, и не смотрит на остальной функционал

Таких проблем будет меньше, если:

  • Проект развивают те программисты, которые изначально его разрабатывали и знают “от и до”.
  • Проект хорошо документирован. Тогда даже новые разработчики смогут достаточно быстро разобраться в неочевидных взаимосвязях.
  • Разработка ведётся на отдельном dev-сервере.
  • Весь основной функционал проекта перед выкаткой изменений на “боевой” сервер предварительно тестируются. А потом ещё раз тестируется на “боевом”.

Ограниченность ресурсов сервер

Такие проблемы возникают с ростом проекта.

Растет количество информации в базе данных. Со временем тяжелые запросы к такой начинают вешать базу. Например, в какой-то момент перестанет нормально работать сложный фильтр по товарам в интернет-магазине.

Растет трафик на сайт либо сайт подвергается DDOS-атаке. Ресурсы сервера всегда ограничены, особенно если говорить про виртуальный хостинг. Поэтому с какого-то момента весь сайт или отдельные его страницы могут перестать открываться или станут делать это крайне медленно.

Если у вас виртуальный хостинг или VDS, то на физическом сервере, на котором расположен ваш проект, может появиться другой «тяжелый» проект из-за которого ваш может начать работать значительно хуже и медленнее.

Что делать:

  • Оптимизировать запросы и архитектуру проекта. Довольно затратная и долгая процедура, но это того стоит.
  • Если оптимизация не дает нужных результатов или по каким-то причинам невозможна, то придется переезжать на более мощный сервер.

Изменения и обновления программного обеспечения

Любой веб-проект — это довольно сложная система: функционал работает под управлением CMS сайта, которая в свою очередь работает под управлением ПО сервера, которое работает под управлением операционной системы сервера. И это довольно упрощенная схема.

Десятки программ работают одновременно, в связке друг с другом, и время от времени обновляются или заменяются на аналогичные. Иногда это приводит к непредсказуемым конфликтам, которые ломают интернет-проект.

Частично защититься от этого можно если проект работает на отдельном «железном» сервере и после каждого изменения проводится полное функциональное тестирование проекта.

Выводы

Не бросайтесь искать виноватого. Исследуйте проблему вместе с вашими разработчиками. Больше чем в половине случаев причина не так очевидна, как кажется на первый взгляд.

Доверяйте разработчикам — они, как правило, умные и честолюбивые люди и стремятся исправлять свои ошибки, дайте им такую возможность.

Поставьте точный срок исправления бага и до его окончания не давите на разработчиков. Однако, если срок вышел, а проблема так и не исправлена — вы имеете полное право применять санкции.