Как находить и устранять ошибки в работе сайта до того, как они повредят вашему бизнесу

Как находить и устранять ошибки в работе сайта до того, как они повредят вашему бизнесу

Введение

Ошибки — неотъемлемая часть любой разработки. Но если вы наш клиент, вы о них почти не узнаете. Мы находим их заранее, прежде чем они доберутся до ваших пользователей или повлияют на бизнес. Как нам это удаётся? Рассказываем простым языком и с реальными примерами из нашей практики.

 Вот как строится работа по этапам:

  1. Проверяем код автоматически — ещё до того, как он попадает на сайт
  2. Тестируем ключевые функции глазами пользователя
  3. Собираем и анализируем все ошибки и логи
  4. Следим за сайтом в реальном времени и реагируем мгновенно

Зачем нужна система обработки ошибок

 Уменьшать риски сбоев и минимизировать последствия – основная цель и задача при работе с ошибками. Веб-приложения сегодня – это совокупность клиентских (фронтенд), серверных (бэкенд) приложений, зависимых и внешних сервисов, серверного ПО. 

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

На помощь в решение этих задач нам приходят следующие системы:

  1. Система автоматического тестирования кода, включая приемочные тесты;

  2. Система генерации, сбора и обработки логов;

  3. Система мониторинга веб-приложения и среды его работы.

Рассмотрим каждую систему отдельно.


Автоматические тесты: код, который сам ищет ошибки

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

 

Типы автотестов

  1. Юнит-тесты: проверяют отдельные компоненты или модули приложения на предмет корректной работы.

  2. Интеграционные тесты: проверяют взаимодействие между различными компонентами системы.

  3. Функциональные тесты: проверяют функциональность системы с точки зрения пользователя.

Для бэкенд приложений – это специальные скрипты, которые запускаются автоматически (у нас – при приеме Merge Request) и проверяют код на наличие ошибок и несоответствий какой-либо функции ожидаемому результату.

r1.png

На скриншоте мы видим, что очередной деплой был провален из-за ошибки при выполнении автотеста. Приводится стэк ошибки, чтобы можно было быстро найти ее и починить.

Другой пример теста – сравнение результата выдачи функции с образцом. Например, какой-то эндпоинт отдает информацию об объекте в формате JSON. Автотест, который обычно пишется вместе с кодом самого эндпоинта (а по идеологии Test Dirven Development до самого кода эндпоинта), сверяет выдаваемый JSON на наличие нужных параметров и их значений.

Если выдаваемый по REST API результат не совпадает с ожидаемым или его структура нарушена, выдается ошибка, запрос на слияние ветки в dev автоматически отклоняется.

Таких тестов может быть сотни и тысячи, в зависимости от сложности проекта. Они дописываются вместе с изменением самой функции или зависимых систем.


Преимущества автотестов

  1. Уменьшение количества ошибок: коммиты с багами после не попадают в dev, тестовую и продуктивную версии приложения.

  2. Экономия времени: автотесты позволяют быстро выявлять ошибки, экономя время разработчиков на ручное тестирование.

  3. Повышение качества кода: Регулярное выполнение автотестов помогает поддерживать высокий уровень качества кода, выявляя и устраняя ошибки на ранних стадиях.

  4. Уменьшение числа регрессий: Автотесты помогают предотвращать регрессии, то есть случаи, когда исправление одной ошибки вызывает появление другой.

  

«Минусы» автотестов

  1. Как таковых минусов у автотестов нет, но есть «цена», которую надо платить за повышение качества кода и уменьшение числа ошибок:

  2. увеличение сроков разработки: написание и поддержка автотестов требует дополнительного времени разработчика;
  3. увеличение стоимости разработки;

  4. увеличение стоимости менеджмента и документирования проекта, так как тесты на новые функции надо описывать и обновлять в документации по проекту. 

Функциональные тесты проще всего запускать через внешние системы мониторинга, например, Sensorium Web Monitoring, которая дает возможность проверять критические функции приложения непосредственно в браузере как реальный пользователь.

Приемочные тесты

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

  1. Тестирование пользовательского интерфейса: проверка дизайна веб-сайта на соответствие макетам и требованиям заказчика, проверка удобства использования и корректного отображения элементов интерфейса на различных устройствах и в браузерах.

  2. Функциональное тестирование: проверка всех функциональных возможностей сайта, включая регистрацию пользователей, авторизацию, работу корзины, оформление заказов и другие ключевые функции.

  3. Тестирование производительности: проверка времени загрузки страниц, стабильности работы сайта при высокой нагрузке и выявление узких мест, которые могут приводить к снижению производительности.

  4. Тестирование безопасности: проверка защиты данных пользователей, выявление уязвимостей, таких как SQL-инъекции, XSS-атаки и другие угрозы безопасности.

  5. Тестирование совместимости: проверка корректной работы веб-сайта на различных операционных системах, устройствах и веб-браузерах.

Преимущества приемочных тестов

  1. Подтверждение соответствия требованиям: Приемочные тесты помогают убедиться, что система соответствует всем требованиям заказчика и спецификациям.

  2. Улучшение взаимодействия с заказчиком: Заказчик может участвовать в процессе тестирования, что способствует лучшему пониманию его потребностей и ожиданий.

  3. Снижение риска отказов: Выполнение приемочных тестов перед релизом помогает снизить вероятность отказов и сбоев в работе веб-приложения после запуска.

Запускать приемочные тесты имеет смысл при выливке изменений кода с dev-среды в тестовую и production. 

Логи: цифровой «черный ящик» сайта

Каждое действие на сайте оставляет след — в логах. Если что-то пойдёт не так, мы по этим записям быстро находим источник сбоя. Это как иметь камеру наблюдения внутри сайта: всё видно, всё понятно.

Логирование – это процесс записи информации о работе системы, который позволяет отслеживать и анализировать её поведение. Логи помогают быстро найти и исправить проблему в коде. 

Преимущества логирования

  1. Диагностика проблем: Логи помогают выявлять и диагностировать проблемы, возникающие в работе системы.
  2.  Анализ производительности: Логирование позволяет анализировать производительность системы и выявлять узкие места.

  3. Аудит изменений: Логи фиксируют все изменения в системе, что позволяет отслеживать действия пользователей и разработчиков.

  4. В сами веб-приложения мы встраиваем расширенные логи, чтобы отлавливать логические ошибки в обработке данных и время исполнения скриптов.

Например, для сбора и анализа данных по времени исполнения скриптов формируются удобные графики в Grafana: 

r2.png  

На этом графике отображена временная шкала и среднее время исполнения скриптов. Так мы видим, что время получения данных эндпоинта /api/kb.questions/navigation/ превышает 1 секунду, что, безусловно, очень долго, ведь простые скрипты должны исполняться за 0,001 секунду. 

Кроме того, на графике мы видим, что в выбранный период времени 3 скрипта исполнялись более 5 сек. Это и есть наши кандидаты на срочную оптимизацию.

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

Функционал уведомлений в Grafana позволяет получать сообщения, если показатели достигнут каких-то пороговых значений. Таким образом, можно не следить постоянно за производительностью скриптов, а реагировать только на конкретные инциденты.

r3.png

Кроме времени исполнения скрипта мы также следит и за другой «нагрузкой»: процессорным временем, количеством запросов и HTTP-статусами ответов. Это помогает оптимизировать потребляемые ресурсы и выявлять неоптимизированый код.

 

Особые логи

Иногда, требуется собирать особые записи о работе сайта. Например, мы поддерживаем сайт с онлайн-конкурсом и в рамках поддержки помогает пользователям решить технические вопросы. Обращаясь в поддержку, пользователи обычно дают минимум информации. Чтобы сократить время выявления и анализа проблемы, мы добавили особые логи, фиксирующие действия пользователей на разных этапах, от регистрации до размещения заявки. Такая прозрачность позволила в 3 раза ускорить обработку обращений. Особенно, если логи соединены с системой их обработки и уведомлений об инцидентах.

Обработка логов

Каждая система, приложение, может генерировать тысячи записей логов в секунду, хранить весь объем очень дорого. 

Обычно приложения не пишут журналы работы в системы хранения напрямую, а вместо этого они их отправляют тем или иным образом в промежуточные приложения -агрегаторы, которые позже передают данные в системы хранения типа ClickHouse. Мы пользуемся приложением Promtail для сбора логов.

r4.png


В результате в Graphana мы получаем удобный инструмент исследования всех логов, как логов сервера, так и веб-приложения. И так как все логи содержат временные метки, легко найти, что произошло на сервере или сайте в определенный момент времени. Это значительно сокращает время на диагностику проблемы.

 

Мониторинг ошибок кода

Внутри мы используем систему сбора ошибок Sentry, которая в последней версии эффективно комбинирует детекцию ошибок, сбор логов и запись действий пользователя.

Чтобы начать сбор логов, надо завести проект в Sentry и интегрировать сбор данных в само приложение. Для работы также необходимо завести и передавать переменные среды, в которой запускается приложение. Здесь разумно следовать уже установленному разделению внутри компании, мы используем local, stage, preview, prod среды.

Тогда все появляющиеся Проблемы (issues) будут привязаны к проекту и среде, что позволит находить и исправлять ошибки на ранних этапах разработки.

r5.png

 Внутри каждого issues доступно:

  1. Расширенная информация о среде возникновения ошибки (ОС, браузер, URL и прочее),

  2. Крошки – подробный лог действия пользователя и реакции системы, которые предшествовали ошибке и были сделаны после ошибки, 

r6.png  

  1. Стек-трейс ошибки, 

  2. Коммит и строка кода, которая вызвала ошибку (доступно, если вы подключили систему управления версиями кода в Sentry).

  3. Статистику возникновения ошибки.

  4. Запись действий пользователя, сопровождающие ошибку. 

r7.png  

 

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

Заключение

Итог: надёжный сайт — это не случайность, а система.

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

С их помощью мы:

  1. Выявляем ошибки ещё до того, как их заметят пользователи,
  2. Поддерживаем высокое качество и стабильность работы,
  3. Делаем так, чтобы сайт приносил результат, а не проблемы.

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

Мы рядом. Готовы взять ответственность за ваш результат.

Напишите нам — расскажем, как можем сделать ваш сайт надёжным, быстрым и безопасным.




Просмотров: 84