Runbook

Предварительная версия

Это предварительный runbook. Исходные raw-данные по инфраструктурным репозиториям (deployer, infrastructure, apps) пусты — процедуры составлены на основе архитектурного контекста и общих практик Kubernetes/Helm. Все команды и шаги требуют валидации на staging перед использованием в production. Не используйте эти инструкции без предварительной проверки DevOps-командой.

Деплой

Стандартный деплой

Ниже описана ожидаемая последовательность на основе архитектурного контекста. Конкретные команды уточняйте у DevOps-команды.

1. Убедиться, что CI/CD pipeline завершился успешно
2. Мерж в main-ветку, как правило, запускает автоматический деплой через ArgoCD
3. Helm chart обновляет Kubernetes deployment
4. Pod verification выполняет smoke-тесты
5. Проверить Sentry на отсутствие новых ошибок

Ручной деплой через Deployer

Репозиторий dot.mind/devops/deployer предоставляет пайплайн для разового ручного деплоя зонтичного чарта dumatel-system в namespace dev01:

# Запускается вручную из GitLab CI (ветка main)
# Переменные: KUBECONFIG_DINA (base64), DOCKER_REGISTRY_USER, DOCKER_REGISTRY_PASSWORD
helm registry login -u "$DOCKER_REGISTRY_USER" -p "$DOCKER_REGISTRY_PASSWORD" cr.selcloud.ru
helm dependency build charts/dumatel-system/
helm upgrade --install dumatel-system --namespace dev01 charts/dumatel-system/

Откат

1. Определить проблемный релиз в Helm history
2. Откат к предыдущей версии (предполагаемая команда: helm rollback <release> <revision> — уточните revision у DevOps)
3. Проверить pod health после отката
4. Зафиксировать инцидент

Типичные инциденты

Pod в CrashLoopBackOff

Симптомы: Pod перезагружается каждые несколько секунд.

Диагностика:

kubectl logs <pod> --previous    # Логи предыдущего запуска
kubectl describe pod <pod>        # События и причины рестарта

Частые причины:

• Неверные environment variables (NATS_HOST, DATABASE_URL)
• Нехватка памяти (OOMKilled)
• Ошибка инициализации БД (миграции не применены)

Решение:

1. Проверить configmap и secrets
2. Увеличить resource limits при OOMKilled
3. При ошибке миграций — запустить миграцию вручную

NATS JetStream недоступен

Симптомы: Сообщения не обрабатываются, consumer lag растёт.

Диагностика:

kubectl get pods -l app=nats      # Статус NATS pods
nats stream ls                     # Список потоков
nats consumer info <stream> <consumer>  # Статус consumer

Решение:

1. Перезапустить NATS pods при необходимости
2. Проверить network policies
3. Очистить stuck consumers: nats consumer rm <stream> <consumer>

Высокий response time

Симптомы: P95 latency > 5s, пользователи жалуются на медленность.

Диагностика:

1. Проверить CPU/Memory через kubectl top pods
2. Проверить PostgreSQL slow query log
3. Проверить NATS consumer lag

Решение:

1. Масштабировать HPA: kubectl scale deployment <name> --replicas=<N>
2. Оптимизировать медленные запросы
3. Добавить индексы при необходимости

Ошибки отправки email (Gull)

Симптомы: Email не доставляются, ошибки в Sentry.

Диагностика:

1. Проверить логи Gull worker
2. Проверить SMTP connectivity
3. Проверить очередь NATS для email-задач

Решение:

1. Проверить SMTP credentials в secrets
2. При массовой блокировке — связаться с провайдером
3. Retry через Orker автоматически повторит неудачные попытки

Управление базой данных

Миграции

# Проверить текущую версию
alembic current

# Применить все миграции
alembic upgrade head

# Откатить последнюю
alembic downgrade -1

# Проверить целостность
alembic upgrade head && alembic downgrade base  # CI тест

Важно: миграции управляются централизованно через пакет sqlalchemy-models-and-migrations.

Бэкапы

• PostgreSQL: автоматические бэкапы через pgbackrest (роль Ansible ansible/roles/pgbackrest/ подтверждена в инфраструктурном репозитории). Расписание бэкапов не зафиксировано в raw-данных — уточняйте у DevOps-команды.
• Проверка восстановления — периодически

Контакты

Роль	Канал
On-call инженер	По расписанию
Backend team	Slack/Teams
DevOps team	Slack/Teams
Sentry	https://sentry.io (проект Думатель)