Skip to content

12. DevOps и эксплуатация

Навигация: Назад: Безопасность | Далее: Процессы разработки

Оглавление

DevOps и эксплуатация

DevOps-подход в SmartSupport нужен для трёх вещей: 1. Предсказуемые релизы — без ручной магии на проде.
2. Надёжность и наблюдаемость — чтобы любая проблема быстро находилась и устранялась.
3. Масштабируемость и повторяемость — возможность развернуть SmartSupport и в облаке, и on-prem у заказчика.

Базовые принципы: - всё, что можно — в коде (инфраструктура, деплой, конфигурации); - изначально закладывается поддержка нескольких сред (dev/stage/prod); - мониторинг и логирование — часть продукта, а не опция; - on-prem-установки не должны отличаться от SaaS по качеству эксплуатации.

Инфраструктурная схема

Референсная схема для SmartSupport: - уровень 1 — сеть и балансировщики: reverse proxy (Nginx/Traefik), TLS-терминация, маршрутизация по доменам/путям.
- уровень 2 — оркестрация: Kubernetes (k8s) для крупных инсталляций (SaaS/регион); Docker Compose для пилотов и небольших on-prem внедрений.
- уровень 3 — приложения: backend-сервисы (Ingestion, Ticket Service, Tasks, KB, Analytics, Monitoring); LLM/Agents Service; фронтенд (панель оператора/админа, web-чат); канальные адаптеры (Max, Telegram, Email, VK, API Gateway).
- уровень 4 — данные: PostgreSQL (основная БД); Vector DB (Qdrant/другая); Object Storage (S3-совместимое — Minio/облако); логи и метрики (Loki/ELK, Prometheus, Grafana).
- уровень 5 — DevOps-сервисы: GitLab / GitHub для репозиториев; CI/CD runners; хранилище секретов; система резервного копирования.

Изначально всё должно быть описано через: - docker-compose.yml (минимальный вариант); - Helm-чарты / kustomize для Kubernetes (масштабируемый вариант).

Continuous Integration (CI)

Цель CI — каждая коммит/merge request автоматически проверяется.

Основные этапы пайплайна CI 1. Lint & Static Checks
- проверка кода backend (Python/Node.js/Go);
- проверка фронтенда (TypeScript/JS);
- линтеры для Dockerfile, Helm-чартов, YAML.
2. Unit-тесты
- покрытие ключевой бизнес-логики;
- отдельные тесты для агентов (Router, Classification, RAG-интеграции).
3. Integration Tests / API Tests
- проверка базовых эндпоинтов;
- smoke-тесты RAG (есть ли соединение с БЗ/Vector DB).
4. Сборка артефактов
- Docker-образы для сервисов;
- фронтенд-сборка (SPA/SSR, если используется).
5. Публикация артефактов
- Docker Registry (GitLab Registry, Harbor, др.);
- version tagging (vX.Y.Z, latest для dev).

CI-конфигурация хранится в репозитории (например, .gitlab-ci.yml).

Continuous Deployment (CD)

Цель CD — чтобы доставка кода на окружения была безопасной, предсказуемой, повторяемой.

Общий подход: - dev — автоматический деплой при merge в основную ветку; - stage — деплой по кнопке (manual job); - prod — деплой через отдельное подтверждение (manual + approvals).

Механика: - Kubernetes: манифесты/Helm-чарты в репозитории; CD-пайплайн обновляет deployment’ы, configmap’ы, secrets; используется rolling update / blue-green (для критичных компонентов).
- Docker Compose: CD-пайплайн логинится в сервер; тянет свежие образы; перезапускает сервисы с минимальным downtime.

Обязателен шаг: post-deploy smoke-тесты (проверка, что системы живы: /health, /metrics, базовые API).

Среды (dev, stage, prod)

SmartSupport изначально должен поддерживать минимум 3 среды:

dev
- среда для разработчиков;
- допускаются экспериментальные ветки;
- могут использоваться “песочницы” LLM;
- данные — синтетические/обезличенные.

stage (pre-prod)
- максимально приближен к prod;
- реальные интеграции (тестовые ключи Max, Telegram, Email);
- тестовая БЗ;
- используется для приёмочных тестов, демонстраций, пилотов.

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

Все конфиги должны быть разделены: - через values.dev.yaml / values.stage.yaml / values.prod.yaml (для Helm); - через .env.dev / .env.stage / .env.prod (для Compose).

Мониторинг (Prometheus, Grafana, Uptime)

Наблюдаемость — часть продукта, а не доп. опция.

Собираемые метрики (Prometheus) - показатели приложений:
- RPS по каналам (Max/Telegram/Web/Email);
- среднее время ответа;
- доля автоответов ИИ;
- доля эскалаций операторам;
- ошибки API по классам (4xx/5xx);
- количество обращений по категориям.
- показатели инфраструктуры:
- CPU, RAM, диски;
- состояние контейнеров;
- состояние БД;
- latency до внешних сервисов (LLM/CRM).

Dashboards (Grafana) - “Общая панель системы” — доступность, ошибки, задержки;
- “Обращения и каналы” — RPS, автоответы, очередь операторов;
- “База знаний и RAG” — RAG-hit rate, ошибки поиска;
- “Инфраструктура” — ресурсы нод, контейнеры, storage.

Uptime Monitoring - отдельный сервис (например, Uptime Kuma / внешние чекеры);
- проверка: главной страницы; API /health; доступности web-чата; времени ответа ключевых эндпоинтов.

Логи (Loki / ELK)

Логи нужны для: - поиска ошибок; - аудита; - анализа работы агентов; - расследования инцидентов.

Логируются: - запросы/ответы (без ПДн, с маскировкой); - действия операторов/администраторов; - обращения к БД; - вызовы LLM (с обезличенными промптами); - события безопасности; - ошибки и исключения.

Используемые стек: - Loki + Promtail + Grafana (лёгкий и удобный вариант); - или ELK (Elasticsearch + Logstash + Kibana) для крупных инсталляций.

Обязательные требования: - маскирование ПДн в логах; - разделение логов по средам; - ограничение доступа к логам (только DevOps/ИБ/админы).

Alerting

Alerting должен быть простым, настроенным, с приоритизацией.

Уровни алертов 1. Критические (P1)
- недоступен prod;
- массовые 5xx;
- недоступна БД;
- очередь сообщений растёт (RabbitMQ / Kafka).
2. Важные (P2)
- RPS ИИ резко упал;
- высокая задержка ответов;
- проблемы с интеграцией (CRM/Max/Telegram);
- деградация RAG (резкого падение RAG-hit rate).
3. Информационные (P3)
- рост количества обращений по теме;
- аномалии по Social Monitoring;
- увеличение доли ручных обработок.

Каналы для оповещений - Telegram-канал DevOps/ИБ; - Email для ответственных; - дашборд статуса.

Alertmanager (Prometheus) или аналог используется для маршрутизации и агрегации алертов.

Backup & Recovery

Резервное копирование — обязательная часть эксплуатации SmartSupport.

Что бэкапим 1. PostgreSQL
- ежедневные full-бэкапы;
- периодические инкрементальные (при необходимости);
- хранение на отдельном хранилище/внешнем бакете.
2. Object Storage (вложения)
- регулярная репликация на вторичное хранилище;
- опционально — версионирование бакетов.
3. Vector DB
- регулярные snapshot’ы;
- либо репликация (если поддерживается).
4. Конфигурации
- Helm-чарты, docker-compose, .env (в Git + зашифрованные секреты).

Recovery-процедуры - документированная инструкция восстановления: БД → приложение → каналы;
- регулярные тестовые восстановления (DR-тренировки);
- RPO/RTO оговариваются в SLA:
- RPO (потеря данных) — например, ≤ 24 часа;
- RTO (время восстановления) — например, ≤ 4–8 часов.

Управление ключами и секретами

SmartSupport использует множество секретов: - токены Max/Telegram/VK; - SMTP-пароли; - ключи к CRM/ERP; - пароли к БД; - LLM API keys.

Принципы - никакие секреты не хранятся в коде и Git; - используется централизованное хранилище секретов:
- Kubernetes Secrets + sealed-secrets / SOPS;
- или сторонний Vault (HashiCorp Vault, AWS Secrets Manager, др.) для SaaS;
- доступ к секретам — только у DevOps/ИБ; - все секреты версионируются и ротируются:
- при увольнении сотрудников;
- при подозрении на компрометацию;
- регламентно (например, раз в 90 дней).

Итог

DevOps- и эксплуатационный контур SmartSupport обеспечивает: - предсказуемые релизы (CI/CD); - безопасное разделение сред (dev/stage/prod); - полную наблюдаемость (метрики, логи, алерты); - резервное копирование и сценарии восстановления; - безопасное управление ключами; - возможность развёртывания и в облаке, и on-prem у гос-заказчиков.