Как SRE-аудит помог выявить узкие места в инфраструктуре проекта
Когда бизнес вырастает в шесть раз за два года, это не только повод для радости, но и большие риски. Инфраструктура не поспевает за трафиком, временные решения становятся постоянными, команда проекта работает без выходных, а сайт всё равно не вывозит пиковых нагрузок и сбоит. Проблемы с мониторингом, нарастающий хаос, потеря контроля, а главное – непонимание, как навести во всём этом порядок, с чего начать. Выявить проблемы и определить первые шаги изменений помогает SRE-аудит сайта. Рассказываем на примере Flowwow.
Что было не так?
- С ростом бизнеса инфраструктура сервисов разрослась, стала менее управляемой, надежной и стабильной.
- Система мониторинга перестала отвечать новым требованиям и задачам.
- Стали чаще возникать проблемы при работе под нагрузкой, особенно при резком росте числа заказов (в праздничные дни).
- Отсутствовала унификация и стандартизация процессов. Не было инструкций и шаблонов для работы в случае инцидентов.
- «Ручное управление» требовало постоянной вовлеченности сотрудников. В периоды пиковых нагрузок команда была вынуждена работать без выходных.
- Продолжительные даунтаймы, простои сайта угрожали устойчивости бизнеса и финансовым результатам.
- У команды отсутствовал нужный уровень экспертизы для самостоятельного аудита и модернизации инфраструктуры.
Кейс
Flowwow – онлайн-сервис для доставки цветов и подарков из локальных магазинов в более чем 950 городах мира. Благодаря этой платформе, клиенты могут покупать различные подарочные наборы для близких, а продавцы размещать свои товары и развивать бизнес. Маркетплейс предоставляет пользователям доступ к технической платформе, рекламным инструментам, поддержке и CRM. Сервис работает в России, Беларуси, ОАЭ, Армении, Грузии, Великобритании и других странах.
В связи с бурным ростом бизнеса основной задачей Flowwow стала работа с инфраструктурой проекта: нужно было сделать ее более управляемой, стабильной, унифицированной. Клиент попросил нас оценить состояние инфраструктуры и дать список рекомендаций по её улучшению.
Что мы сделали?
Провели комплексный SRE- аудит проекта, сосредоточив внимание на нескольких критических областях. На основе полученной информации сформировали подробный перечень рекомендаций и план дальнейших действий.
IaC
- Невозможно развернуть инфраструктуру с нуля.
- Сложный workflow, затрудняющий работу команды разработчиков.
- IaC, который не дает понимания итоговой инфраструктуры.
- Текущая инфраструктура не полностью покрыта IaC. В облаках присутствуют предустановленные ресурсы (default vpc), чего не должно быть при работе с Terraform: это вносит путаницу.
Наши рекомендации
- Разделить инфраструктуру и ПО – Terraform от Ansible.
- Уйти от избыточности. Создать только необходимые модули Terraform, с полным описанием и примерами использования.
- Отказаться от публичных модулей Terraform.
- Переделать роли и плейбуки в Ansible. Отказаться от публичных ролей, добавить molecule, создать документацию и инструкции по работе с окружениями.
- Добавить в репозиторий с helm чартами чарты инфраструктурных сервисов, таких как Ingress, Nginx, Prometheus operator и т.п., удалить их из Terraform.
CI/CD
- Jenkins Jobs представляют собой по большей части ручные джобы: миграции, бэкапы, автомержи, очистки кэшей/очередей, 1С-инвойсы, разного рода кроны и т.д.
- Часть джоб – набор команд в конфигурации джобы, в том числе git pull. А часть джоб запускают bash-скрипты, которые уже есть на серверах.
- В Jenkins нет четкого разделения джоб по контурам. При изменении или добавлении какого-то сервера в инфраструктуру, нужно будет вносить корректировки во все связанные джобы.
- Список jobs в документации не полный.
- Деплой песочниц организован неудобно и непрозрачно. Например, нет автоматического удаления.
- Воркфлоу в репозитории кода выглядит не связным из-за отсутствия описания того, какие приложения есть в проекте и как они связаны между собой.
- Есть разные пайплайны с закомментированным кодом. Неясно, как это всё между собой связано.
Наши рекомендации
- Привести в задокументированный вид.
- Провести рефакторинг: унифицировать деплои, сделать отдельно деплой песочниц.
- Избавиться от лишних Jenkins jobs, вынеся часть в код с использованием Ansible или пайплайнов, а бэкапные задачи — в крон или альтернативные решения.
- Вынести все из репозитория кода, описать весь общий флоу, отделив инфраструктуру от приложений.
- Сделать автоматическое развертывание песочниц исходя из названия feature ветки.
- Унифицировать workflow для всех приложений, разработать единый пайплайн.
Документация
- Нет описания всей инфраструктуры и полного перечня контуров/серверов (инвентори).
- Отсутствуют данные по всем приложениям и плохо видна связь между ними.
- Не хватает четких инструкций в документации по laC.
- Нет полной документации по CI/CD-процессам.
Наши рекомендации
- Использовать подход к документации как к коду. Например, есть репозитории с IaC и репозитории с описанными CI/CD-процессами. Документация по использованию этих инструментов должна быть прикреплена к самим инструментам при помощи readme.
- Составить базу общих знаний по использованию разных технологий в отдельном разделе.
- Вынести инфраструктурную документацию и типовые инструкции по эксплуатации в свой раздел документации. Он должен поддерживаться и актуализироваться в рамках технической поддержки.
- Разделить документацию на категории и хранить в разных местах.
Что получил заказчик?
- Возможность увидеть все свои ключевые процессы «со стороны», без отрыва основной команды проекта «от производства».
- Перечень конкретных проблем, требующих устранения для стабильной и устойчивой работы проекта.
- Качественную экспертизу и подробную «дорожную карту» дальнейших действий по реорганизации проекта.
Почему это сработало?
SRE-аудит помогает увидеть комплексную картину, определить ключевые проблемы инфраструктуры и приоритетные направления работы.
Выполняя рекомендации, полученные по итогам аудита, компания может повысить:
- стабильность и надежность системы – сократив количество сбоев и время простоев;
- производительность – уменьшив время отклика системы, скорость загрузки страниц;
- эффективность команд DevOps или SRE – за счет оптимизации процесса реагирования на инциденты и автоматизации рутинных задач;
- удовлетворенность клиентов – благодаря улучшению качества обслуживания, пользовательского опыта.
Всё это позитивно сказывается на бизнес-результатах компании. Эксплуатационные затраты на обслуживание системы сокращаются (за счет оптимизации и автоматизации мониторинга), а доходы (благодаря повышению надежности системы и сокращению времени простоев) – растут.
Рекомендации
К росту бизнеса важно готовиться заранее. Быстрая динамика и новые масштабы проекта могут ударить по устойчивости компании, обернуться убытками и репутационными рисками. Чтобы избежать проблем, убедитесь в том, что ваша инфраструктура готова к другому уровню нагрузок и задач, выявите и устраните потенциальные угрозы.
SRE-аудит проекта позволит вам получить профессиональную экспертизу системы и оценить ключевые метрики, в том числе:
- доступность – время безотказной работы и простоя за определенный период;
- время реагирования на инциденты – необходимое для их обнаружения и разрешения;
- масштабируемость – способность системы справляться с возросшей нагрузкой;
- мониторинг – способность системы отследить важный инцидент и проанализировать его в дальнейшем.
Напишите нам, чтобы обсудить ваш проект.
Упомянутые услуги
Ответим на заявку в ближайшие 24 часа. А еще мы можем проконсультировать вас по телефону +7 800 555-91-99, электронной почте info@itsumma.ru или в Telegram-чате.
