Аудит инфраструктуры и внедрение рекомендаций: CI/CD-шаблоны, Vault, мониторинг и логи

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

Клиент обратился к нам с запросом оценить состояние инфраструктуры и привести её в порядок.

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

Конец марта — июль 2025 года, около 4 месяцев

2 DevOps-инженера, менеджер проекта, фронтенд-разработчик, 2 старших Ruby-разработчика

Работа шла в три этапа: аудит, согласование плана, внедрение.

Мы изучили серверы, получили доступы к виртуальным машинам, описали состав ПО и проанализировали сборку, деплой, сеть и бэкапы. Основные находки:

• Сборка и деплой запускаются вручную. Единых шаблонов CI/CD нет: файлы для запуска приложений копируются и переписываются в каждом репозитории. Процесс не описан, правила для веток и окружений не едины.
• Настройки приложений хранятся в зашифрованных .env-файлах и переменных проектов без общего регламента.
• Приложения продакшена работают на одном сервере. Балансировки нет, плана восстановления после отказа тоже. Второй сервер держит только реплики баз данных.
• Конфигурация Nginx правится руками на каждой машине. Доступ к ВМ идёт через системных пользователей, на части серверов один аккаунт на всю команду.
• Бэкапы настроены для файлов, PostgreSQL и поискового индекса и лежат в объектном хранилище, но проверка целостности копий не настроена.
• На части машин операционная система вышла из поддержки или близка к этому.

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

Мы разбили рекомендации на задачи, декомпозировали и оценили их, затем согласовали приоритеты с клиентом.

• Инфраструктура как код. Создали Ansible-репозиторий, добавили плейбук для создания пользователей с персонализированными доступами, перенесли в него конфигурации Nginx для продакшена и стейджа.
• Хранилище секретов. Развернули Vault с PostgreSQL в качестве бэкенда, добавили роль для его резервного копирования и написали документацию для разработчиков. Затем интегрировали Vault с GitLab, чтобы сборки получали переменные окружения из хранилища, а не из файлов в репозиториях. В дальнейшем разработка перевела работу с секретами и конфигурацией приложений полностью на Vault.
• CI/CD-шаблоны. Доработали общий шаблон пайплайна, проверили его на нескольких сервисах и перевели работу CI/CD на новый формат, основанный на шаблонах. Шаблоны подключили в репозитории, проверили тестовые деплои на стейдже. После тщательного тестирования изменения были применены на продакшен окружениях. Во всех репозиториях описали процесс сборки и публикации.
• Мониторинг и алерты. Развернули новый стек мониторинга (Prometheus, Grafana, Alertmanager, cAdvisor, node-exporter, postgres-exporter) на отдельном сервере, перенесли дашборды и сбор метрик PostgreSQL, добавили авторизацию и настроили шаблоны алертов.
• Логи. Описали конфигурации хостов в инвентаре и с помощью Ansible-роли и настроили OpenSearch и Fluent Bit на хостах: распределение по индексам, разбор логов регулярными выражениями, защита от потери записей при недоступности OpenSearch.
• Бэкапы. Проанализировали существующие скрипты и документацию, доработали скрипт резервного копирования, обновили restic и несколько раз проверили развёртывание данных из копий, в том числе время загрузки из хранилища и бинарные бэкапы OpenSearch. Также проверили настройки резервного копирования базы данных и по итогам проверки убрали задачи на снятие копий в SQL формате через pg_dump - так как текстовая копия занимала значительную часть хранилища и объем не позволял даже теоретически проверить её целостность и время загрузки.
• Сеть и безопасность. Просканировали хосты на открытые порты, изучили правила фаервола, согласовали конфигурацию с клиентом и применили её на серверах, включая стейдж и сервер CMS. Отдельно решали проблему с пробросом портов в Docker. Проверили хосты с помощью OpenSCAP — инструмента, который сверяет настройки системы с профилем безопасности CIS (набор рекомендаций по защите серверов), — чтобы найти проблемы конфигурации.

Роли и настройки проверяли на тестовой машине или стейдже, а процесс и переменные описывали в документации к ролям и проектам.

Результатом работ стали:

• Автоматизированы рутинные действия, снижен риск человеческого фактора, в том числе зависимость от отдельных людей, которые знают, как всё устроено (bus factor).
• Снизились трудозатраты на массовые изменения в CI/CD проектов: правка шаблона заменила правки в каждом репозитории.
• Появилась документация по автоматизированным разделам: Vault, мониторинг, Nginx, роли Ansible, сборка и публикация.
• Базовая безопасность приведена в порядок, а дальнейшие улучшения сформированы в бэклог.