6 советов бизнесу, что проверить в инфраструктуре сайта

Чтобы в Черную пятницу не пострадать из-за того, что сайт “лежит”, а поток покупателей идет.

Очень досадно, когда отдел маркетинга\отдел продаж\коммерческий департамент или лично собственник бизнеса просчитали всё перед акцией (типа Чёрной пятницы) — и всё пошло прахом, потому что про возможные ошибки внутри сайта никто не подумал…

Впрочем, тут ни один из сотрудников вышеперечисленных отделов не виноват. Дело в том, что в программной части встречается такой сорт ошибок, которые проявляются исключительно во время наплыва клиентов. Что же делать? Опустить руки и играть в ромашку “упадёт — не упадёт”? Если знать, куда смотреть, то гадать не придётся. В этой статье мы собрали практические рекомендации, как избежать простоев, связанных с такими ошибками. Советы основаны на нашем четырнадцатилетнем опыте поддержки высоконагруженных веб-проектов.

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

Скорость отклика зависит от множества факторов: сервера, ОС, софта, отвечающего за фронтенд*, ПО, отвечающее за бэкенд** и базу данных.

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

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

Цель донастроек — это улучшение текущих показателей: ускорить запросы и быстрее возвращать ответы на них за счет кэширования или индексирования в базе данных.

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

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

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

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

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

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

Вот кейс о том, что проверять настройки — это очень важно.

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

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

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

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

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

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

**** CDN (Content Delivery Network) — географически распределенная инфраструктура, которая помогает сайтам быстрее загружаться и отвечать на запросы пользователей.

• Связность компонентов: использование подсистем, порядок обработки пользовательского запроса.
• Коммуникации с внешними сервисами: API платежного шлюза, сервис для email-рассылок, геосервисы, сторонние модули GPS, лимиты передачи данных в сети, лимиты передачи данных в канале связи.

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

• мониторинг сетевого интерфейса и его текущей скорости;
• мониторинг доступности сервера с нескольких точек — банальный пинг сервера из разных мест, чтобы не получилось так, что из офиса в Санкт-Петербурге сервер отвечает, а во Владивостоке — нет.

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

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

Зачем вообще использовать то, что может стать проблемой? Подобные сторонние сервисы не только снимают нагрузку с инфраструктуры. Они помогают в те моменты, когда система мониторинга “легла” вместе с сайтом, и служат резервным источником необходимой информации.

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

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