Статью подготовил наш партнёр Southbridge. Компания, которая занимается технической поддержкой инфраструктуры и DevOps.
Автор: Антон Скобин, директор по развитию Southbridge
Материал собран на основе проблем, с которыми Southbridge сталкивался при работе с проектами на 1С-Битрикс: обращения клиентов, аварии, которые приходилось разбирать, и настройки, которые приходилось чинить руками.
Самые частые инфраструктурные проблемы обычно на удивление банальны. Многие аварии начинаются с небольших неполадок, которые долго остаются незаметными, пока не перерастают в инцидент.
К нам обращаются компании с нагруженным сайтом на 1С-Битрикс: через него продают услуги, показывают видео, строят отчёты по сложным запросам к базе данных. По мере роста проекта и нагрузки начинают проявляться накопившиеся проблемы инфраструктуры: растёт число ошибок, увеличивается время ответа, отдельные операции зависают или выполняются слишком долго.
Разберём, чем чаще всего вызваны эти проблемы, и что можно проверить самостоятельно.
Прежде чем переходить к подробностям, вот короткая карта: по какому симптому в какую сторону смотреть.
Симптом | Где искать |
|---|---|
сайт постепенно становится медленнее | база данных, медленные запросы, PHP, веб-сервер |
проблемы усиливаются при росте нагрузки | соединения с БД, память, PHP-FPM, таймауты |
сервисы начинают выдавать ошибки | свободное место, память, логи |
восстановление после аварии оказывается сложным | резервные копии |
о сбое первым сообщает пользователь | мониторинг |
1. Проблемы с базой данных
База данных — одна из самых нагруженных и критичных частей Битрикс-проекта. Проблемы с ней встречались практически на каждом проекте, с которым работал Southbridge.
Причём это редко выглядит как простое «MySQL сломался». База может продолжать работать, но делать это всё хуже: потреблять слишком много памяти, медленно отвечать, упираться в лимит подключений или плохо справляться с конкретными запросами.
Что мы находили на реальных проектах
MySQL переставал отвечать.
Процесс MySQL завершался из-за нехватки памяти.
Утилизация доступных подключений превышала 95%.
Репликация была отключена или работала некорректно.
Требовалось восстанавливать повреждённую базу из резервной копии.
Отсутствовал тюнинг параметров БД под реальную нагрузку.
Медленные запросы создавали дополнительную нагрузку.
Отдельные таблицы разрастались до десятков гигабайт.
У крупных таблиц отсутствовали индексы.
Архитектура кластера БД не обеспечивала автоматического переключения при отказе.
Для бизнеса эти разные технические причины часто выглядят одинаково: страницы открываются медленно, сайт зависает, возникают ошибки, а во время пиковой нагрузки всё резко ухудшается.
Почему перезапуск помогает ненадолго
Самый неприятный вариант: сайт становится полностью недоступен. Но чаще проблема существует в форме постепенной деградации. Страница вместо секунды отвечает несколько секунд, во время роста трафика ситуация усугубляется, периодически возникают таймауты.
Администратор перезапускает MySQL, сайт снова работает, и проблема считается решённой. Перезапуск снимает симптом, но не устраняет причину.
Если база регулярно упирается в память, соединения или производительность отдельных запросов, следующий всплеск нагрузки вернёт ту же проблему.
Куда обычно смотрим
Сначала определяем, где именно ограничение: ресурсы сервера, настройки MySQL или MariaDB, запросы приложения, структура таблиц, индексы, репликация или архитектура самой базы.
Дальше решение зависит от причины: приходилось менять конфигурацию базы, настраивать мониторинг её параметров, восстанавливать и перестраивать репликацию, переносить базу, пересматривать резервное копирование, менять архитектуру и переносить базы в облако.
После изменений нужно проверить главное: выдерживает ли база обычную для проекта нагрузку без регулярных перезапусков и деградации.
Что можно сделать прямо сейчас
Посмотрите на четыре показателя сервера БД: загрузку процессора, использование памяти, число соединений и свободное место на диске.
Если какой-то ресурс регулярно подходит к пределу, это уже повод разбираться, даже если пользователи пока не жалуются.
Отдельно включите лог медленных запросов и посмотрите, что в него попадает. Проверка почти ничего не стоит и часто даёт первое направление для диагностики.
2. Заканчивается место на диске
Одна из самых банальных проблем в списке и при этом одна из самых частых. С нехваткой дискового пространства сталкивался почти каждый Битрикс-проект, который вёл Southbridge.
Сервер может иметь достаточно процессоров и памяти, приложение может нормально работать, база данных может быть исправна, а сайт всё равно останавливается: ему больше некуда записывать данные.
С какими случаями сталкивались
Свободного места оставалось меньше 5%.
Быстро росли логи Nginx.
Разрастался лог медленных запросов MariaDB.
Рос объём базы данных.
Требовалось дополнительное место для импорта данных.
Резервные копии занимали значительную часть диска.
Логирование было организовано хаотично.
Ротация логов отсутствовала или была настроена неправильно.
В одном из проектов только лог медленных запросов MariaDB занимал больше гигабайта и продолжал расти, потому что данные долго не ротировались и не сжимались.
Что происходит после заполнения диска
Проблемы начинают возникать сразу в нескольких местах. База не может нормально записывать данные. Не создаются временные файлы. Перестают записываться логи. Не выполняются резервные копии. Сервисы начинают выдавать ошибки или завершаться.
Хуже всего то, что путь туда обычно долгий: между состояниями «места становится мало» и «сайт перестал работать» есть время, если кто-то следит за этим показателем.
Почему просто расширить диск недостаточно
Сначала нужно понять, что именно занимает место. Просто увеличить диск недостаточно: если на нём бесконтрольно растёт лог, через некоторое время заполнится и новый объём.
Дальше настраиваем ротацию и сжатие логов, наводим порядок в хранении резервных копий, удаляем ненужные данные, при необходимости разносим разные типы данных по разным дискам.
После этого настраиваем мониторинг свободного пространства и пороги предупреждений. Тогда о нехватке места узнают заранее, до того как она превратится в аварию.
Что можно сделать прямо сейчас
Посмотрите, сколько свободного места осталось на продакшен-серверах. Если занято от 80 до 90% и больше, определите крупнейшие каталоги и разберитесь, что именно растёт.
Особенно стоит проверить логи, резервные копии, временные файлы и данные базы. Затем настройте хотя бы простое уведомление о достижении выбранного порога.
Это одна из самых дешёвых профилактических мер во всей инфраструктуре.
3. Проблемы с PHP и веб-сервером
Отдельная категория проблем: слой, который напрямую обслуживает запросы пользователей, Nginx, Apache, PHP и PHP-FPM. Здесь особенно легко ошибиться при диагностике: пользователь видит, что «тормозит Битрикс», хотя сам Битрикс тут ни при чём.
Что мы находили на реальных проектах
Apache переставал работать.
Требовались изменения конфигурации Nginx.
Nginx неправильно обрабатывал часть запросов.
Возникали таймауты при ожидании ответа от Apache.
PHP упирался в лимиты памяти.
PHP-FPM был установлен, но не использовался.
Требовалась оптимизация PHP-FPM.
Использовались устаревшие версии PHP.
В конфигурации Nginx накопилось много ручных изменений.
Логи веб-сервера содержали ошибки, указывающие на проблемы приложения или его конфигурации.
На старых проектах добавляется проблема совместимости: обновить PHP желательно с точки зрения эксплуатации и безопасности, но существующий сайт может оказаться не готов к новой версии.
Почему покупка более мощного сервера не всегда решает проблему
Последствия варьируются от отдельных ошибок до полной недоступности сайта. При неправильной конфигурации веб-стека сервер хуже использует имеющиеся ресурсы. Под обычной нагрузкой это может быть незаметно, а во время всплеска трафика появляются очереди, таймауты и ошибки.
В результате проблему легко ошибочно решить покупкой более мощного сервера: ресурсов становится больше, симптом на время исчезает, а причина остаётся.
С чего начинается диагностика
Разбираем всю цепочку обработки запроса: Nginx, Apache, PHP или PHP-FPM и то, как они взаимодействуют с приложением.
Проверяем конфигурации, логи, ограничения памяти, процессы, таймауты и версии программного обеспечения. Если требуется обновление, отдельно проверяем совместимость приложения.
После этого меняем конфигурацию и смотрим, как система ведёт себя под реальной нагрузкой.
Иногда задача выходит за рамки инфраструктуры. Например, ошибки веб-сервера могут показывать, что PHP-скрипт потребляет слишком много памяти или слишком долго выполняется. Тогда инфраструктура помогает локализовать проблему, но исправлять часть причин нужно уже в коде.
Что можно сделать прямо сейчас
Начните с логов Nginx или Apache и PHP. Читать их целиком не нужно: посмотрите ошибки за последние несколько дней и найдите повторяющиеся сообщения.
Затем проверьте версии PHP, Nginx и Apache и узнайте, поддерживаются ли они сейчас. Перед обновлением нужно проверить совместимость сайта, но даже если сайт пока не готов к актуальной версии ПО, доработку стоит запланировать заранее, не дожидаясь, пока сайт взломают.
Наконец, если сайт периодически тормозит, сопоставьте время замедления с загрузкой CPU, памятью и логами веб-сервера. Даже такая простая проверка помогает отделить проблему приложения от проблемы инфраструктуры.
4. Проблемы с резервными копиями
Резервное копирование было настроено у каждого Битрикс-клиента Southbridge. И почти никогда не работало идеально.
Что мы находили на реальных проектах
Ошибки выполнения резервного копирования.
Отсутствие ожидаемой резервной копии.
Отсутствие регулярных бэкапов MySQL.
Необходимость увеличить место под резервные копии.
Нереализованное отдельное резервное копирование файлов и базы.
Неудачные схемы хранения резервных копий.
Отсутствие контроля наличия свежих копий.
Неудачные механизмы резервного копирования для больших баз.
В одном из случаев после повреждения базы сайт пришлось восстанавливать из утренней копии. Данные за часть рабочего дня в восстановленной базе отсутствовали.
Где появляется ложное чувство безопасности
Худший сценарий очевиден: потеря данных. Но возможны и другие варианты. Копия есть, но восстановление занимает слишком много времени. База восстановилась, а нужной версии файлов сайта нет. Копии хранятся на том же сервере, который вышел из строя. Бэкап перестал выполняться несколько недель назад, но никто этого не заметил.
Вопрос «делаем ли мы бэкапы» тут слишком общий. Точнее спросить: до какого состояния и за какое время можно восстановить сайт, если этот сервер исчезнет прямо сейчас.
Что должно быть с бэкапами кроме самих бэкапов
Сначала определяем, какие данные нужно сохранять и с какой периодичностью. Базу данных и файлы рассматриваем отдельно.
Настраиваем автоматическое резервное копирование, контролируем его выполнение, отслеживаем объём хранилища. Для крупных баз отдельно подбираем подходящий механизм создания копий.
Ценность бэкапов определяется одним: получится ли реально восстановить сайт по ним, если понадобится. Если никто никогда не пытался поднять систему из существующих копий, надёжность самой системы резервирования остаётся под большим вопросом.
Что можно сделать прямо сейчас
Попросите ответственного сотрудника показать последнюю резервную копию базы и файлов сайта.
Затем задайте три вопроса: когда она создана, где физически хранится и кто знает процедуру восстановления.
Ещё лучше восстановить копию на тестовом сервере. Так сразу станет понятно, настоящее это резервное копирование или просто набор файлов на диске.
5. Мониторинг: вишенка на торте
Есть очень простой способ мониторить инфраструктуру. Ждать.
Все знают, что мониторинг нужен, но никто не любит с ним возиться. Нормальным мониторингом могут похвастаться немногие Битрикс-проекты, гораздо чаще системой мониторинга оказывается сам пользователь.
Сайт стал медленным, пользователь жалуется. Сайт перестал открываться, кто-то пишет разработчику. Закончилось место, об этом узнают уже после появления ошибок.
В результате инженер начинает заниматься проблемой только после того, как она уже повлияла на бизнес.
Как выстроить мониторинг, который реально работает
Сначала определяем критические компоненты конкретного проекта и показатели, по которым можно судить об их состоянии.
После этого настраиваем сбор метрик и алерты для серверов, базы данных, веб-сервера и других нужных сервисов.
Мало просто поставить Zabbix или любую другую систему мониторинга. Порог срабатывания должен оставлять время на реакцию, а само сообщение должно объяснять, что именно происходит.
Кроме отдельных аварий стоит следить и за динамикой показателей. Например, диск ещё не заполнен, но свободное пространство устойчиво сокращается день за днём. Это уже повод для внимания, хотя аварии пока нет.
Простая проверка мониторинга
Составьте список из пяти компонентов, без которых сайт не сможет работать.
Напротив каждого ответьте на два вопроса:
Как мы узнаем, что этот компонент перестал работать?
Узнаем мы об этом раньше пользователя или после него?
Если ответ на второй вопрос «после», мониторинг этой части инфраструктуры стоит настроить в первую очередь.
Итог
Пройдитесь по пяти пунктам:
База данных. Посмотрели на CPU, память, соединения и лог медленных запросов?
Диск. Знаете, сколько места свободно на продакшен-серверах и что на них растёт?
PHP и веб-сервер. Проверили логи Nginx, Apache и PHP, версии ПО?
Резервные копии. Пробовали восстановить последний бэкап и знаете, кто умеет это делать?
Мониторинг. Узнаёте о сбоях раньше пользователей или после них?
Если хотя бы на один вопрос ответ «нет» или «не знаю», у вас уже есть с чем работать.
За крупной аварией на Битрикс-проекте почти всегда стоит ворох мелочей, которые годами копились незаметно и в какой-то момент сложились вместе. Причём проблемы из разных разделов этой статьи часто связаны между собой: нехватка памяти на сервере БД проявляется как медленные запросы, медленные запросы разрастают лог, лог съедает диск, а переполненный диск роняет резервное копирование.
По каждому пункту выше можно пройтись самостоятельно. Если нужна проверка всей инфраструктуры сразу, у Southbridge есть бесплатный аудит. В него входит:
проверка инфраструктуры
настройки сервисов и программного обеспечения
CI/CD, если он есть в проекте
нагрузка и мониторинг, если они настроены
поиск проблемных мест в конфигурации и архитектуре
базовые настройки безопасности
рекомендации по найденным проблемам и рискам
По итогам команда получает список того, что требует внимания сейчас, что можно отложить и что стоит сделать, чтобы инфраструктура соответствовала нагрузке и задачам бизнеса.
Дальше с этим списком можно работать своей командой или передать реализацию и дальнейшую поддержку Southbridge.
