«Возникла ошибка на сайте» — как снизить риски ошибок на сайте
Рассмoтрим откуда могут возникать проблемы, какие ошибки бывают, как минимизировать риски ошибок, как учесть эти моменты еще на стадии разработки.
Введение
В статье разберем ситуацию «Проект запущен в эксплуатацию, и на нем выявляются неожиданные проблемы/ошибки». Рассмoтрим откуда могут возникать проблемы, какие ошибки бывают, как минимизировать риски ошибок, как учесть эти моменты еще на стадии разработки.
Какие ошибки могут возникать в работающем проекте?
Сайт работает в динамичной среде — к нему подключаются с разных устройств, могут быть задействованы различные API. Данные сайта постепенно накапливаются в базе данных и в диске сервера.
Практически все ошибки, возникающие в проекте имеют в своем основании одну из следующих причин:
Логическая ошибка. Неверно задан алгоритм, ошибка в кодировании.
Техническая ошибка при разработке (ошибка синтаксиса, ссылка на несуществующий объект, система не может выполнить запрос, 500 ошибка и так далее).
Не хватает ресурсов. Место на диске забито, памяти не хватает для выполнения операции, CPU перегружен и так далее.
Ошибка на стыке различных сервисов. Один сервис что-то у себя изменил (параметры API, кодировку, методы проверки и так далее), а сайт, обращающийся к сервису по API получил ошибку. Либо отправка почты не проходит из-за каких-то блокировок на почтовом сервере.
Ошибка целостности данных. Например, удалили из базы пользователя, а на него ссылались какие-то объекты. В итоге информация по этим связанным объектам выводится неверно, или неверно считаются метрики.
Ошибка пользователя. Пользователь накрутил настройки так, что система начала давать сбой (например, пользователь настроил редирект 301 для страницы саму на себя).
Неверные системные настройки. Например, кто-то на сервере решил поэкспериментировать с ограничениями доступа или изменением версий ПО сервера.
Недоступность каких-то ресурсов (например, JS или CSS файлов).
Теперь выделим возможные причины ошибок:
Ошибки программиста. Программист может сделать в основном сценарии выполнения верно, а в каких отдельных случаях не учесть нюансы. Например, вывод ROI он сделал, но не учел, что за период может быть 0 в Расходах. Тогда будет ошибка деления на 0.
Проблемы настроек сервера, сайта, внешних сервисов. Ключевое — давать критичные настройки только тем, кто их понимает и ответственно подходит к их изменению.
Неоптимизированный код. То есть, код работает быстро на малых данных, а на больших данных начинает тормозить.
Не учтены нюансы устройства. Например, особенности использования на мобильных.
Не учтены нюансы на уровне ТЗ. Программист внедряет то, что написано в ТЗ. Но в реальном мире гораздо больше нюансов, чем в любом ТЗ. Поэтому ошибка может возникнуть из-за новых данных, о которых не было известно ранее. Например, что ставка по ипотеке может быть отрицательной!
Фиксация ошибки
Если вы владелец продукта, то первое что необходимо сделать — максимально точно зафиксировать данные по ошибке:
Скрин ошибки. Не нужно интерпретировать ошибку или писать «там что-то странное выскочило», лучше дать непосредственно скрин проблемы. Тем, кто умеет делать видеоскрины — +100 баллов к карме;
URL страницы. Адрес страницы, где вы встретили проблему (не название страницы, а именно адрес https://site.ru…);
Текущий пользователь. Под каким пользователем была ошибка (чтобы программист потом проверял именно под этим или аналогичным пользователем, а не под админом);
Для продвинутых — содержание консоли браузера F12/Console — там будет информация по состоянию внутренних ошибок в браузере.
Чем точнее вы это сделаете, тем проще будет сделать диагностику ошибки и проще, и быстрее будет решить проблему.
Чтобы разработчик мог исправить проблему, ему необходимо воспроизвести ее у себя, добиться ее устойчивого повторения. Если проблема плавающая — ее очень сложно исправлять и проблематично удостовериться, что проблема исчезла после внесения правок.
Кто виноват?
Этот вопрос кажется непродуктивным со стороны разработчиков, но в нем так же есть смысл.
Не в том плане, чтобы наказать за ошибку. В этом случае вы просто получите озлобленного разработчика, который в итоге будет работать против проекта (например, просто как бы не замечая очевидные ошибки, которые он может увидеть в коде). Это нужно скорее для того, чтобы донести суть и причину ошибки до всех разработчиков (и в особенности до того, кто ее допустил, чтобы в будущем он ее не совершал).
Если у вас систематически один человек допускает одни и те же ошибки, то скорее всего его надо снимать с проекта (если это халатность с его стороны). Тут важно понимать суть ошибки, а не просто рубить с плеча направо и налево. Очень легко разрушить атмосферу в коллективе, если просто начать искать виноватых без изучения проблемы.
Ищите причину и кто допустил ошибку для того, чтобы сделать выводы для минимизации риска подобной проблемы в будущем. Проблема обычно не в людях, а в процессах.
А если кажется, что в людях — имеет смысл начать с себя любимого.
Что делать с ошибками?
Ошибки как минимум надо быстро исправлять. По каждой ошибки желательно находить реальную причину, а не просто исправить. И тут же вспоминаем про любимую всеми курсами и книгами по менеджменту «5 почему». Для обработки ошибок это идеально подойдет.
Можно также вести лог зафиксированных ошибок. Это позволит их анализировать в будущем и делать какие-то выводы (например, не подпускать Петю к механизму регистрации на пушечный выстрел).
Профилактика возникновения ошибок в проекте
Как можно минимизировать риск возникновения критичных ошибок на сайте? Для этого необходимо вести системный журнал ошибок: фиксировать все ошибки (внутренние и фронт ошибки). Проводить их категоризацию.
Когда в Falcon происходит ошибка, мы пытаемся ее соотнести к какой-то категории ошибки — это упрощает дальнейший анализ по ошибкам в целом. Подробнее про механизма анализа ошибок на Falcon Space
Также необходимо обеспечить периодический анализ состояния по логу ошибок. Это требует затрат в проекте, но так вы сможете узнавать о некоторых критичных ошибках не от пользователей, а на самой ранней стадии.
Также важно обеспечить непрерывный контроль критических точек проекта. Например, раз в неделю/месяц вручную проверять самые важные элементы:
Регистрация;
Заполнения ключевых форм (обращение на сайте);
Оформление заказа (положить в корзину);
Вход на сайт.
Сами определите какие механизмы и как часто тестировать. Как вариант, можно заказать периодическую работу по проверке этих механизмов по инструкции у тестеров на kwork или аналогичной площадке.
Также косвенным признаком ошибки может быть снижение показателей и метрик: кол-во регистраций, посещаемость, увеличение показателя отказов и так далее.
Аналитика по ключевым параметрам позволит увидеть «дымок» до того как вы увидите языки пламя в виде явных ошибок.
Подробнее о внедрении автоматического тестирования сайте смотрите здесь.
Как минимизировать ошибки на стадии разработки
Чтобы уменьшить количество ошибок в будущем, поставьте во главу угла Простоту. Чем проще решение, тем надежнее оно работает. Чем больше кастома и чем более накручено решение, тем сложнее его поддерживать и тем больше в нем может быть непредвиденных нюансов.
Заказчики обычно совсем не думают об этом аспекте разработки и пытаются втиснуть в проект ненужное усложнение. То есть, есть убеждение, что все будет работать идеально в любом случае. В реальности это совсем не так — чем сложнее и заковыристее решение, тем выше риск ошибки и тем больше оно доставит хлопот в будущем.
Как минимум, заказчик должен просто прислушиваться к опасениям разработчиков. Если ваш разработчик вообще не выказывает ни разу опасений и за все берется как бравый солдат, то возможно он не думает о последствиях костыльных и тяжелых решений.
Я — за простоту и надежность. Чем проще и стандартнее решение, тем надежнее оно работает. И это касается всего — дизайн, обработка данных, бизнес-логика, структура контента и так далее.
Второе, что может улучшить ситуацию — это контроль кода. Необходимо закладывать некий бюджет на ревизию кода (анализ кода на возможные проблемы), на рефакторинг кода (улучшение кода без изменения функциональности). Все это позволит увеличить уверенность, что код не будет выдавать каких-то фокусов, а также упростит дальнейшую поддержку.
Третье — проверка на реальных данных. Реальный объем данных, загрузка настоящий данных, а не удобных тестовых данных, при которых все выглядит красиво, но как вставишь реальные данные, все куда-то едет.
Заключение
Ошибки будут всегда. Там, где пишется код под проект, всегда будут ошибки. Там, где люди используют активно IT продукт, всегда будут ошибки. Хотелось бы, чтобы было по другому, но от них невозможно полностью избавиться. Вспомнить хотя бы Windows с его патчами, сервис паками и так далее.
Главное — мониторить ошибки и оперативно реагировать на них.
Большинство ошибок типовые — по мере их исправления их становится все меньше и меньше.
Со стороны владельца веб-проекта важно обеспечить мониторинг ошибок, выделять средства на профилактику проблем, а также проработать детали процесса реагирования на возникающие проблемы. Меры, описанные в статье, позволят снизить риски возникновения критичных ошибок на вашем сайте.
How to
Новости 
Кейсы 
Интервью и дискуссии 
Маркетинговые исследования 
Просто о сложном 
Проверено ADPASS 
Рекламные кампании 