AI-Ops Documentation

Русский English
  • Главная
  • Карта документации
0. С чего начать
  • Что это за продукт
  • Для кого он
  • Как устроена документация
  • Быстрые ссылки
  • Как начать разработку
  • Как найти нужный сервис
  • К кому идти по вопросам
1. Продукт
Обзор продукта
  • Миссия продукта
  • Ценность для бизнеса
  • Основные сценарии
  • Границы системы
Пользователи и персоны
  • Сегменты пользователей
  • Роли пользователей
  • Основные потребности
Пользовательские сценарии
  • Регистрация / логин
  • Основной пользовательский сценарий
  • Оплата / заказ / действие
  • Поддержка и сценарий восстановления
Функции продукта
Фича: Аутентификация
  • Цель
  • Пользовательская история
  • Бизнес-правила
  • Ограничения
  • Метрики успеха
  • Связанные сервисы
  • Связанные события / данные
  • Фича: Профиль
  • Фича: Организации
  • Фича: Топология
  • Фича: Вычислительные ресурсы
  • Фича: Кластеры
  • Фича: Каталог сервисов
Требования
  • Функциональные требования
  • Нефункциональные требования
  • Требования к производительности
  • Требования к безопасности
  • Конфиденциальность и соответствие
  • Доступность
Метрики
  • Ключевая метрика (North Star)
  • Продуктовые KPI
  • Метрики воронки
  • Метрики качества
  • Метрики экспериментов
2. Домены
Домен: Identity
  • Назначение
  • Основные концепции
  • Сущности
  • Бизнес-правила
  • Сервисы домена
  • Данные домена
  • Связанные фичи
  • Домен: Профиль пользователя
  • Домен: Поиск
  • Домен: Заказы / транзакции
  • Домен: Уведомления
  • Домен: Аналитика
  • Домен: Рекомендации
3. Архитектура
Обзор системы
  • Что входит в систему
  • Что не входит
  • Высокоуровневая диаграмма
C4 Model
  • Контекстная диаграмма
  • Диаграмма контейнеров
  • Диаграмма компонентов
  • Диаграмма развёртывания
Интеграционная архитектура
  • Внешние системы
  • Интеграции API
  • Webhooks
  • Сторонние провайдеры
Потоки данных
  • Онлайн-поток данных
  • Пакетный поток данных
  • Поток событий
  • Владение данными
Архитектура безопасности
  • Аутентификация
  • Авторизация
  • Управление секретами
  • Шифрование
  • Аудит и логирование
Надежность и масштабируемость
  • SLA / SLO
  • Планирование мощностей
  • Отказоустойчивость
  • Обратное давление и повторы
  • Восстановление после сбоев
Архитектурные принципы
  • Границы доменов
  • Принципы проектирования API
  • Принципы проектирования событий
  • Принципы контрактов данных
  • Диаграмма: auth микросервисы
Control plane
  • Архитектура компонентов (control plane)
  • Доменная модель v0
  • Протокол v0 (control plane)
  • Примеры (control plane)
Сервисы (control plane)
Сервис control plane
  • API
  • Модель данных
  • События
  • Модули
  • Операции
Сервис execution plane
  • API
  • Модель данных
  • События
  • Модули
  • Операции
Сервис resource catalog
  • API
  • Модель данных
  • События
  • Модули
  • Операции
4. Инженерия
Сервисы
Каталог сервисов
  • Все сервисы списком
  • Владельцы
  • Критичность
  • Уровень / домен / статус
  • Сервис аутентификации
  • Сервис аккаунтов
  • Облачный сервис
  • Сервис учётных данных
  • Herald
  • Сервис идентификации
  • API Gateway
  • Сервис токенов
Фронтенд
  • Обзор фронтенда
  • Структура приложения
  • Routing (фронтенд)
  • State management (фронтенд)
  • Design system (фронтенд)
  • UI components (фронтенд)
  • API контракты фронтенда
  • Обработка ошибок (фронтенд)
  • Performance (фронтенд)
  • Feature flags (фронтенд)
  • Тестирование фронтенда
Бэкенд
  • Обзор бэкенда
  • Паттерны сервисов
  • Рекомендации по API
  • Событийные паттерны
  • Паттерны доступа к БД
  • Кэширование
  • Асинхронные задачи и воркеры
  • Идемпотентность
  • Обработка ошибок
  • Тестирование бэкенда
Данные
  • Обзор данных
  • Системы-источники
  • Контракты данных
  • Каталог схем событий
  • Хранилище данных
  • Витрины данных
  • ETL / ELT-пайплайны
  • Качество данных
  • Происхождение данных
  • Политики хранения
  • Политики доступа
ML / DS
  • Обзор ML/DS
  • Сценарии (ML)
  • Каталог моделей
  • Feature store
  • Training pipelines
  • Inference pipelines
  • Offline evaluation
  • Online evaluation / A-B
  • Мониторинг (ML)
  • ML runbooks
QA / Качество
  • Стратегия качества
  • Пирамида тестов
  • Тестовые окружения
  • Тестовые данные
  • Ручное тестирование
  • Автоматизированное тестирование
  • Нагрузочное тестирование
  • Тестирование безопасности
  • Критерии приёмки релиза
  • Процесс разбора багов
5. Платформа
Инфраструктура
  • Ansible
  • WireGuard
  • Kubernetes
  • Longhorn
  • Ingress
  • PostgreSQL Cluster
  • Redis
  • Kafka
  • Vault
  • MinIO
  • Authentik
  • Monitoring
  • Logging
  • Tracing
  • Nexus
  • SonarQube
  • GlitchTip
  • GitLab Runner
  • Kubernetes Dashboard
  • OLM
  • Deploy
  • Internal DNS
  • Обзор (инфраструктура)
  • Config generator
  • Пример (инфраструктура)
  • Скрипты (инфраструктура)
Окружения
  • Локальное
  • Stage
  • Pre
  • Продакшен (prod)
  • Tech
  • Облако
  • Объектное хранилище
  • CI/CD
  • Секреты и сертификаты
Наблюдаемость
  • Логирование
  • Метрики
  • Трейсинг
  • Алертинг
  • Резервное копирование и восстановление
6. Разработка
  • Быстрый старт
  • Локальная настройка
  • Карта репозиториев
  • Стандарты кода
  • Git-процесс
  • Стратегия ветвления
  • Руководство по код-ревью
  • Критерии готовности
  • Процесс релиза
  • Флаги фич
  • FAQ разработчика
  • Миграция secure auth
7. Эксплуатация
  • Дежурство
  • Управление инцидентами
  • Уровни критичности
  • Политика эскалации
  • Постмортемы
  • Ранбуки
  • Управление изменениями
  • Непрерывность бизнеса
8. Аналитика
  • План трекинга событий
  • Определения KPI
  • Каталог дашбордов
  • Словарь метрик
  • Эксперименты
  • Стандарты отчётности
9. Управление
  • Решения (ADR)
  • Политика статуса контента
  • Changelog обновлений документации
Безопасность и соответствие
  • Модель угроз
  • Безопасная разработка
  • Управление доступом
  • Конфиденциальность
  • Реагирование на инциденты
Ответственность и владельцы
  • Команды
  • Зоны ответственности команд
  • Владельцы сервисов
  • Владельцы доменов
  • Контакты
Глоссарий
  • Бизнес-термины
  • Продуктовые термины
  • Технические термины
  • Сокращения

Онлайн-поток данных

Previous Next

Online data flow описывает синхронные потоки данных в системе — запросы от клиентов через API Gateway к микросервисам и обратно. Используется для операций, требующих немедленного ответа.

Архитектура

graph TB subgraph "Client Layer" WebApp[Web Application] MobileApp[Mobile App] CLI[CLI Tools] end subgraph "Edge Layer" LB[Load Balancer
Ingress NGINX] Gateway[API Gateway
Envoy Proxy] end subgraph "Service Layer" Identity[Identity Service
gRPC] Credential[Credential Service
gRPC] Auth[Auth Service
gRPC] Account[Account Service
gRPC] end subgraph "Data Layer" PostgresIdentity[(PostgreSQL
Identity DB)] PostgresCredential[(PostgreSQL
Credential DB)] RedisCache[(Redis
Cache & Sessions)] end WebApp -->|HTTPS/REST| LB MobileApp -->|HTTPS/REST| LB CLI -->|HTTPS/REST| LB LB --> Gateway Gateway -->|gRPC| Identity Gateway -->|gRPC| Credential Gateway -->|gRPC| Auth Gateway -->|gRPC| Account Identity --> PostgresIdentity Identity --> RedisCache Credential --> PostgresCredential Credential --> RedisCache Auth --> RedisCache Account --> PostgresIdentity style Gateway fill:#4A90E2 style PostgresIdentity fill:#51B749 style RedisCache fill:#DC382C

Типы online потоков

1. REST API (Public)

Протокол: HTTP/1.1, HTTP/2 Формат: JSON Аутентификация: JWT Bearer tokens

Примеры endpoints:

1
2
3
4
5
6
7
POST   /api/v1/auth/register        # Регистрация пользователя
POST   /api/v1/auth/login           # Аутентификация
POST   /api/v1/auth/refresh         # Обновление токенов
POST   /api/v1/auth/logout          # Выход из системы
GET    /api/v1/users/me             # Получение профиля
PUT    /api/v1/users/me             # Обновление профиля
POST   /api/v1/identifiers/verify   # Верификация email/phone

Request/Response Example:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
POST /api/v1/auth/register HTTP/2
Host: api.aiops.io
Content-Type: application/json
User-Agent: AIOps-Web/1.0

{
  "username": "john_doe",
  "email": "john@example.com",
  "password": "SecureP@ssw0rd!"
}

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
HTTP/2 201 Created
Content-Type: application/json

{
  "user": {
    "id": "550e8400-e29b-41d4-a716-446655440000",
    "username": "john_doe",
    "status": "active",
    "created_at": "2024-03-09T10:30:00Z"
  },
  "tokens": {
    "access_token": "eyJhbGciOiJSUzI1NiIs...",
    "refresh_token": "eyJhbGciOiJSUzI1NiIs...",
    "expires_in": 900
  }
}

2. gRPC (Internal)

Протокол: HTTP/2 with Protocol Buffers Аутентификация: Service-to-service mutual TLS (планируется)

Service Definitions:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
// identity.proto
service IdentityService {
  rpc CreateUser(CreateUserRequest) returns (CreateUserResponse);
  rpc GetUser(GetUserRequest) returns (GetUserResponse);
  rpc GetUserByUsername(GetUserByUsernameRequest) returns (GetUserResponse);
  rpc GetUserByIdentifier(GetUserByIdentifierRequest) returns (GetUserResponse);
}

// credential.proto
service CredentialService {
  rpc SetPassword(SetPasswordRequest) returns (SetPasswordResponse);
  rpc VerifyPassword(VerifyPasswordRequest) returns (VerifyPasswordResponse);
  rpc ChangePassword(ChangePasswordRequest) returns (ChangePasswordResponse);
}

Python Client Example:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
import grpc
from aiops.identity.v1 import identity_pb2, identity_pb2_grpc

async with grpc.aio.insecure_channel('identity-service:50051') as channel:
    stub = identity_pb2_grpc.IdentityServiceStub(channel)

    response = await stub.GetUser(
        identity_pb2.GetUserRequest(user_id=user_id)
    )

    print(f"User: {response.user.username}")

Детальные flow patterns

Pattern 1: User Registration

sequenceDiagram participant Client participant Gateway participant Identity participant Credential participant PostgresI participant PostgresC participant Outbox participant Redis Client->>Gateway: POST /api/v1/auth/register
{username, email, password} Note over Gateway: 1. Validate request body Note over Gateway: 2. Rate limit check Gateway->>Identity: CreateUser(username) Identity->>PostgresI: BEGIN TRANSACTION Identity->>PostgresI: INSERT INTO users
(id, username, status) Identity->>Outbox: INSERT INTO outbox_events
(UserCreatedEvent) Identity->>PostgresI: COMMIT Identity-->>Gateway: User{id, username, status} Gateway->>Credential: SetPassword(user_id, password) Note over Credential: Hash password with Argon2id Credential->>PostgresC: BEGIN TRANSACTION Credential->>PostgresC: INSERT INTO password_credentials
(user_id, password_hash) Credential->>Outbox: INSERT INTO outbox_events
(PasswordSetEvent) Credential->>PostgresC: COMMIT Credential-->>Gateway: PasswordCredential{user_id} Gateway->>Identity: AttachIdentifier(user_id, email, challenge_id) Identity->>PostgresI: INSERT INTO identifiers
(user_id, type, value, verified_at) Identity-->>Gateway: Identifier{id, verified_at} Gateway->>Gateway: CreateSession + GenerateTokens Gateway->>Redis: SET session:{id} {data} EX 2592000 Gateway-->>Client: 201 Created
{user, tokens} Note over Outbox: Background worker publishes events to Kafka

Характеристики: - Latency: ~200-500ms (зависит от Argon2id hashing) - Transactions: 2 отдельные БД транзакции (Identity, Credential) - Consistency: Eventually consistent через events

Pattern 2: Authentication (Login)

sequenceDiagram participant Client participant Gateway participant Identity participant Credential participant Auth participant Redis participant PostgresI participant PostgresC Client->>Gateway: POST /api/v1/auth/login
{username, password} Gateway->>Identity: GetUserByUsername(username) Identity->>Redis: GET user:username:{username} alt Cache hit Redis-->>Identity: Cached user data else Cache miss Identity->>PostgresI: SELECT * FROM users
WHERE username = ? PostgresI-->>Identity: User record Identity->>Redis: SETEX user:username:{username}
TTL=300 end Identity-->>Gateway: User{id, status} alt User not found or disabled Gateway-->>Client: 401 Unauthorized end Gateway->>Credential: VerifyPassword(user_id, password) Note over Credential: Load password_hash from DB Credential->>PostgresC: SELECT password_hash
FROM password_credentials
WHERE user_id = ? PostgresC-->>Credential: password_hash Note over Credential: Argon2id verification
(constant-time) alt Invalid password Credential-->>Gateway: {is_valid: false} Gateway-->>Client: 401 Unauthorized end Credential-->>Gateway: {is_valid: true} Gateway->>Auth: CreateSession(user_id, metadata) Auth->>Redis: SET session:{id} {user_id, ...} EX 2592000 Auth->>Auth: GenerateTokens(user_id, session_id) Auth-->>Gateway: {access_token, refresh_token} Gateway-->>Client: 200 OK
{access_token, refresh_token}

Характеристики: - Latency: ~150-300ms (с кешем), ~300-600ms (без кеша) - Cache strategy: Username → User lookup кешируется на 5 минут - Security: Constant-time password verification

Pattern 3: Authenticated API Request

sequenceDiagram participant Client participant Gateway participant Service participant Redis participant PostgresS Client->>Gateway: "GET /api/v1/users/me
Authorization: Bearer JWT" Note over Gateway: "1. Extract JWT from header" Note over Gateway: "2. Verify signature (JWKS)" Note over Gateway: "3. Check exp, iss, aud" Note over Gateway: "4. Extract user_id from sub" Gateway->>Service: "GET /users/me
x-user-id, x-session-id" Service->>Redis: "GET user key" alt Cache hit Redis-->>Service: Cached user data else Cache miss Service->>PostgresS: SELECT user WHERE id PostgresS-->>Service: User record Service->>Redis: "SETEX user key TTL=300" end Service-->>Gateway: User data Gateway-->>Client: "200 OK + user data"

Характеристики: - Latency: ~10-50ms (с кешем), ~50-150ms (без кеша) - Cache TTL: 5 минут для user data - Validation: JWT валидируется на Gateway, сервис доверяет x-user-id

Pattern 4: Data Mutation with Cache Invalidation

sequenceDiagram participant Client participant Gateway participant Service participant Redis participant PostgresS Client->>Gateway: "PUT /api/v1/users/me
Authorization Bearer JWT
body username" Gateway->>Service: "PUT /users/id
x-user-id" Service->>PostgresS: BEGIN TRANSACTION Service->>PostgresS: "UPDATE users SET username WHERE id" Service->>PostgresS: COMMIT Note over Service: Invalidate caches Service->>Redis: "DEL user key" Service->>Redis: "DEL user username key" Service-->>Gateway: Updated user data Gateway-->>Client: "200 OK + updated user"

Характеристики: - Cache invalidation: Удаление всех связанных cache keys - Consistency: Write-through pattern (сначала DB, потом cache)

Performance Optimizations

1. Connection Pooling

PostgreSQL (через PgBouncer):

1
2
3
4
5
6
7
8
# sqlalchemy-postgres-kit
async_engine = create_async_engine(
    DATABASE_URL,
    pool_size=20,              # Max connections per pod
    max_overflow=10,           # Burst capacity
    pool_pre_ping=True,        # Health check before use
    pool_recycle=3600,         # Recycle connections after 1h
)

Redis:

1
2
3
4
5
6
7
8
# redis-client-kit
redis_client = AsyncRedisClient(
    host="redis-master",
    port=6379,
    max_connections=50,
    socket_keepalive=True,
    health_check_interval=30,
)

2. Caching Strategy

Multi-level cache:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
@cache(ttl=300, key_prefix="user")
async def get_user_by_id(user_id: UUID) -> User | None:
    """
    1. Check Redis cache
    2. If miss, query PostgreSQL
    3. Store result in Redis
    """
    cached = await redis.get(f"user:{user_id}")
    if cached:
        return User.parse_raw(cached)

    user = await db.query(UserDB).filter_by(id=user_id).first()
    if user:
        await redis.setex(
            f"user:{user_id}",
            ttl=300,
            value=user.to_domain().json()
        )

    return user.to_domain() if user else None

Cache invalidation patterns: - Write-through: DB write → cache invalidate - TTL-based: Auto-expire после N секунд - Event-based: Kafka event → invalidate cache

3. Request Batching (DataLoader pattern)

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
from aiodataloader import DataLoader

class UserLoader(DataLoader):
    async def batch_load_fn(self, user_ids: list[UUID]) -> list[User | None]:
        """Load multiple users in single query"""
        users = await db.query(UserDB).filter(
            UserDB.id.in_(user_ids)
        ).all()

        user_map = {u.id: u for u in users}
        return [user_map.get(uid) for uid in user_ids]

# Usage in single request
user_loader = UserLoader()

# These calls are batched into single DB query
user1 = await user_loader.load(user_id_1)
user2 = await user_loader.load(user_id_2)
user3 = await user_loader.load(user_id_3)

4. Read Replicas (planned)

graph TB Service[Service] Primary[(PostgreSQL Primary
Read/Write)] Replica1[(PostgreSQL Replica 1
Read-only)] Replica2[(PostgreSQL Replica 2
Read-only)] Service -->|Writes| Primary Service -->|Reads| Replica1 Service -->|Reads| Replica2 Primary -.->|Replication| Replica1 Primary -.->|Replication| Replica2 style Primary fill:#51B749 style Replica1 fill:#90EE90 style Replica2 fill:#90EE90

Observability

Request Tracing

OpenTelemetry spans:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
from opentelemetry import trace

tracer = trace.get_tracer(__name__)

@tracer.start_as_current_span("get_user")
async def get_user(user_id: UUID) -> User:
    with tracer.start_as_current_span("cache.get"):
        cached = await redis.get(f"user:{user_id}")

    if not cached:
        with tracer.start_as_current_span("db.query"):
            user = await db.query(UserDB).get(user_id)

        with tracer.start_as_current_span("cache.set"):
            await redis.setex(f"user:{user_id}", 300, user.json())

    return user

Metrics

Prometheus metrics:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
from prometheus_client import Histogram, Counter

request_duration = Histogram(
    'http_request_duration_seconds',
    'HTTP request latency',
    ['method', 'endpoint', 'status']
)

cache_hits = Counter(
    'cache_hits_total',
    'Number of cache hits',
    ['cache_type', 'key_prefix']
)

cache_misses = Counter(
    'cache_misses_total',
    'Number of cache misses',
    ['cache_type', 'key_prefix']
)

Error Handling & Retry

Circuit Breaker

1
2
3
4
5
6
7
from circuitbreaker import circuit

@circuit(failure_threshold=5, recovery_timeout=60)
async def call_external_service():
    """Auto-open circuit after 5 failures"""
    response = await http_client.post(...)
    return response

Retry with Exponential Backoff

1
2
3
4
5
6
7
8
9
from tenacity import retry, stop_after_attempt, wait_exponential

@retry(
    stop=stop_after_attempt(3),
    wait=wait_exponential(multiplier=1, min=1, max=10)
)
async def query_database():
    """Retry DB query up to 3 times"""
    return await db.query(...)

Связанные страницы

  • Event Flow — асинхронные потоки данных через Kafka
  • Data Ownership — кто владеет какими данными
  • API Design Principles — REST API guidelines
Потоки данных Пакетный поток данных
Меню
Главная Карта документации
0. С чего начать
С чего начать Что это за продукт Для кого он Как устроена документация Быстрые ссылки Как начать разработку Как найти нужный сервис К кому идти по вопросам
1. Продукт
Продукт
2. Домены
Домены Домен: Профиль пользователя Домен: Поиск Домен: Заказы / транзакции Домен: Уведомления Домен: Аналитика Домен: Рекомендации
3. Архитектура
Архитектура Диаграмма: auth микросервисы
4. Инженерия
Инженерия
5. Платформа
Платформа Облако Объектное хранилище CI/CD Секреты и сертификаты Резервное копирование и восстановление
6. Разработка
Разработка Быстрый старт Локальная настройка Карта репозиториев Стандарты кода Git-процесс Стратегия ветвления Руководство по код-ревью Критерии готовности Процесс релиза Флаги фич FAQ разработчика Миграция secure auth
7. Эксплуатация
Эксплуатация Дежурство Управление инцидентами Уровни критичности Политика эскалации Постмортемы Ранбуки Управление изменениями Непрерывность бизнеса
8. Аналитика
Аналитика План трекинга событий Определения KPI Каталог дашбордов Словарь метрик Эксперименты Стандарты отчётности
9. Управление
Управление Решения (ADR) Политика статуса контента Changelog обновлений документации

На странице

Архитектура Типы online потоков 1. REST API (Public) 2. gRPC (Internal) Детальные flow patterns Pattern 1: User Registration Pattern 2: Authentication (Login) Pattern 3: Authenticated API Request Pattern 4: Data Mutation with Cache Invalidation Performance Optimizations 1. Connection Pooling 2. Caching Strategy 3. Request Batching (DataLoader pattern) 4. Read Replicas (planned) Observability Request Tracing Metrics Error Handling & Retry Circuit Breaker Retry with Exponential Backoff Связанные страницы