Интеграция разработки и эксплуатации для компании DATA FOOD

О клиенте

Проблемы клиента

• Устаревшая инфраструктура — legacy-компоненты усложняли развитие системы и повышали стоимость её поддержки.

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

• Простои сервисов — из-за проблем с инфраструктурой происходили остановки в работе сервисов, которые напрямую влияли на бизнес и приводили к существенным финансовым потерям.

• Нехватка экспертизы — ограниченные внутренние компетенции затрудняли развитие инфраструктуры и оперативное решение технических задач.

• Ручной сбор логов — отсутствие централизованного сбора и анализа логов усложняло мониторинг и диагностику, увеличивая время поиска и устранения проблем.
  

Процесс работы

1. Провели аудит инфраструктуры и определили точки контроля

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

2. Настроили комплексный мониторинг

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

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

3. Централизовали сбор и анализ логов

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

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

4. Усилили безопасность резервного копирования

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

5. Взяли на себя DevOps-задачи

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

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

6. Подготовили инфраструктуру к дальнейшему развитию

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

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

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

При выборе архитектурных решений также учитывали дальнейшее развитие DevOps-практик и планы по внедрению Kubernetes.

Результаты

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

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

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

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

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

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