Баги и поломки при работе с сайтом: как защитить проект от самых частых ошибок

Сценарий «чиним одно — ломается другое» очень неприятен для владельца сайта. Добавление новой функции или смена дизайна на одном отрезке может повлиять на работу всего проекта, что особенно актуально для проектов с проблемами в кодовой базе. Такое может происходить по разным причинам, о которых мы сегодня поговорим.

Команда Initlab использует инструменты промышленной разработки (Enterprise) для повышения качества создания и поддержки проектов. Это позволяет нам отслеживать ошибки на самых ранних этапах, своевременно исправлять и не позволять посетителям сайта находить их вместо нас. Гасить очаги проще, чем полноценные пожары.

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

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

Самые распространённые ошибки, возникающие на сайте при внесении правок:

Ошибки стилизации

Пример. Мы увеличили отступ одного блока, а это форматирование применилось на всём сайте или на рандомной странице.

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

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

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

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

При изменениях/переносе. В идеальной ситуации, любые правки на сайт вносятся только через тестовую копию.

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

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

Однако даже такие меры предосторожности могут не спасти от багов, но хотя бы минимизируют урон от прямой работы с сайтом.

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

Внесли правки, внедрили новую функцию — сайт лёг. И здесь речь не о профессионализме — это банальные рабочие моменты, которые могут случиться с каждым. Но, например, в случае совместной работы над функционалом можно неправильно объединить ветки и получить ошибку в логике или стилизации.

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

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

Разница очень проста: например, у нас есть кнопка. Она может съехать — это найдёт визуальный тест, а может не нажиматься — для этого нужен функциональный.

Как работают визуальные регрессионные тесты. Они оповещают нас об изменениях во внешнем виде сайта. Механизм прост: мы снимаем «эталонные» скриншоты страниц, чтобы тест в дальнейшем мог сравнить их с внешним видом сайта после внесения любых изменений. При нахождении отличий система оповещает разработчика, что результаты «до» и «после» не сходятся. Это происходит в момент выгрузки изменений на тестовую копию сайта.

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

Инструменты. Для функциональных и визуальных регрессионных тестов мы используем Playwright.

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

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

Если в первом случае проверка происходит по скриншотам, то здесь проверяется наличие нужных URL и текстов на странице.

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

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

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

Визуальные регрессионные и функциональные тесты мы пишем отдельно под каждый проект.

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

Все изменения на сайте мы обязательно прогоняем через тестовую копию. Это нужно для того, чтобы не внести на живой сайт критических ошибок. Мы работаем на локальной копии и переносим результат на тестовую, чтобы проверить работоспособность внесённых изменений. Сравнивается состояние сайта «до» и «после» изменений. Это помогает отловить критические и не очень ошибки, которые можно просто не заметить. Так мы повышаем стабильность и не тратим лишнее время на фикс проблем, которые можем занести при внесении правок «на живую».

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

Статические анализаторы выполняют более глубокие проверки логики кода. Они анализируют кодовую базу, автоматически отслеживают ошибки и указывают на них. Это помогает тратить меньше времени на проверку кода и следить за качеством работы каждой команды. Конфликты при совместной работе значительно снижаются — на ошибки указывают не коллеги, а беспристрастный робот. В целом, эти инструменты нужны для соблюдения стандартов разработки любых CMS (Drupal, Битрикс и т.д.), даже в случае работы только одной команды над проектом.

Как работают линтеры для проверки стилизации кода. Они указывают на ошибки в оформлении. То есть код не выглядит так, как должен — это проверка внешнего вида.

Инструменты. PHP_CodeSniffer проверяет файлы на наличие нарушений определённых стандартов кодирования, помогает сделать код чистым и последовательным.

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

Инструменты. PHPStan помогает найти баги в коде.

Линтеры и статические анализаторы запускаются при переносе изменений на тестовую копию и сразу дают понять, что нужно исправить. Их также можно запустить локально перед переносом изменений на тестовую копию.

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

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

Недавно наш сотрудник Андрей Тымчук заметил проблему с проверкой от PHPStan на одном из проектов поддержки — в CI всегда устанавливалась актуальная версия и при её использовании отображалась ошибка, не связанная с кодом проекта. Андрей создал подробный репорт о проблеме. В новом релизе проблема была исправлена.

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

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

Тестирование не может гарантировать полного отсутствия ошибок по двум причинам:

Поэтому для защиты боевой версии сайта (prod) нам нужен мониторинг.

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

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

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

Система мониторингов — это наш золотой стандарт по постоянной поддержке работоспособности проектов. Пункты, описанные выше, входят во все тарифы поддержки серверов и в сервисы поддержки сайтов. То есть это инструменты, которые мониторят универсальные для всех проектов параметры.

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

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

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

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

Мониторинг приложения может проверять:

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

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

Песочница — черновая копия сайта, где программисты внедряют первые варианты правок. На этом этапе можно посмотреть, удовлетворяет ли кодовая база линтерам.

Тестовая копия — вариант сайта для тестирования изменений и демонстрации правок клиенту. При переходе на этот этап линтеры запускаются автоматически, если вдруг мы сами не отсмотрели всё в песочнице. Здесь же можно проверить работоспособность изменений при помощи тестов.

Боевой сайт — парадный вариант, видный всему интернету. Сюда попадает всё, что согласовано с клиентом, разработчиками, тестами и линтерами.

Мониторинг — то, что поможет сайту не упасть. Мониторинг автоматически отследит, если с сайтом что-то пойдёт не так. Он не допустит простоя и угроз для вашего проекта.

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

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

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

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

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

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

При помощи линтеров и статических анализаторов можно найти условную тысячу ошибок во всей кодовой базе сайта. Исправлять их сразу займёт сотни человеко-часов. Но мы можем запустить проверки линтеров только на той части кода, которую меняем с конкретной задачей. Благодаря этому новый код от нас всегда качественный и мы можем исправить его «окрестности» — фрагменты кода по соседству, которые касаются конкретной решаемой задачи. Так мы не только будем внедрять правки без ошибок, но и улучшим качество сайта на поддержке.

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

Мы в Initlab считаем, что отслеживание ошибок нужно по-максимуму отдать на откуп автоматике и «выезжать» только на починку. Пусть вопросами «А работает ли корзина?» или «Не съехал ли каталог?» задаются только хорошо себя зарекомендовавшие инструменты, а не заказчик.