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

Operational behavior сервиса строится вокруг safety, isolation и полной наблюдаемости попытки. Сервис должен уметь выполнять опасные infra-actions, но только через typed contracts, policy checks и контролируемые runners.

Execution Lifecycle

sequenceDiagram participant CP as control-plane-service participant D as dispatcher participant R as runner participant V as Vault participant A as artifact-worker participant S as S3/MinIO CP->>D: executeJob(JobSpec) D->>D: validate and create attempt D->>R: lease attempt R->>D: heartbeat(started) R->>V: resolve secret refs R->>R: execute typed runner action R->>D: heartbeat(progress) R->>A: submit logs and outputs A->>S: write artifact bundle A->>D: artifact refs R->>D: complete attempt D->>CP: ExecutionResult callback

Runner Isolation Policy

Базовые правила:

  • Каждый runner запускается в изолированном pod/process sandbox.
  • Runner имеет минимальные network permissions, заданные runner_requirements.
  • Secret values доступны только в runtime memory и только конкретному attempt.
  • File system workspace ephemeral.
  • Raw outputs проходят secret masking до сохранения.
  • Любая destructive operation должна быть явно помечена в JobSpec.

Запрещено:

  • generic uncontrolled shell;
  • передача secret values в inputs.variables;
  • запись kubeconfig, ssh key или cloud credentials в artifacts;
  • выполнение package content, который не прошел marketplace approval или trusted source policy;
  • изменение plan или operation status напрямую.

Approved Commands

Execution допускается только через typed job types:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
allowed_job_types:
  ansible:
    - ansible.playbook.run
    - ansible.role.run
    - ansible.inventory.validate
    - ansible.check_mode.run
  kubernetes:
    - kubernetes.manifest.apply
    - kubernetes.manifest.delete
    - kubernetes.wait
    - kubernetes.rollout.status
    - kubernetes.resource.patch
    - kubernetes.resource.read
  helm:
    - helm.install
    - helm.upgrade
    - helm.rollback
    - helm.uninstall
    - helm.test
    - helm.template
  opentofu:
    - opentofu.plan
    - opentofu.apply
    - opentofu.destroy
    - opentofu.output
    - opentofu.state.inspect
  ssh:
    - ssh.command.run
    - ssh.file.upload
    - ssh.file.download
    - ssh.service.restart
    - ssh.system.fact.collect
  verification:
    - verify.http.endpoint
    - verify.tcp.connect
    - verify.kubernetes.condition
    - verify.postgres.ready
    - verify.resource.capability
    - verify.custom.probe

Новый job type добавляется как protocol extension: runner implementation, contract schema, policy rules, evidence behavior и docs.

Secrets

Vault является единственным источником secret material.

Правила:

  • JobSpec содержит только vault://... refs.
  • Dispatcher не раскрывает secret values.
  • Runner получает секрет по lease-bound token или service identity.
  • Secret redaction применяется к logs, heartbeat messages, errors и artifacts.
  • Secret access audit должен быть связан с attempt_id.

Artifacts

Каждый attempt производит artifact bundle.

Минимальный bundle:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
artifact_manifest:
  attempt_id: exec-attempt-123
  job_type: ansible.playbook.run
  files:
    - path: logs/stdout.log
      stream: stdout
      digest: sha256:abc
    - path: logs/stderr.log
      stream: stderr
      digest: sha256:def
    - path: result/result.json
      type: normalized_result
      digest: sha256:ghi
  redaction:
    applied: true
    rules_version: 1

UI показывает logs/artifacts через control-plane-service, который запрашивает refs и выдает product-level access.

Cancellation

Cancellation flow:

sequenceDiagram participant CP as control-plane-service participant D as dispatcher participant R as runner participant A as artifact-worker CP->>D: cancelAttempt(attempt_id) D->>D: mark cancellation requested R->>D: heartbeat D-->>R: cancellation_requested=true R->>R: stop safely R->>A: upload partial artifacts R->>D: complete(cancelled) D->>CP: ExecutionResult(cancelled)

Если runner не отвечает, dispatcher ждет grace period и переводит attempt в lost или cancelled по policy.

Timeouts

Timeout задается в JobSpec и может быть ограничен service policy.

Поведение:

  • dispatcher отслеживает deadline;
  • runner получает cancellation request;
  • partial logs сохраняются;
  • final status становится timed_out, если runner подтвердил timeout, или lost, если heartbeat пропал;
  • control-plane-service решает, делать retry, PlanPatch или manual intervention.

Retries

Retry всегда создает новый attempt.

flowchart LR NodeRun1[node_run attempt 1 failed] --> CP[control-plane decision] CP --> NodeRun2[node_run attempt 2] NodeRun2 --> Attempt2[execution_attempt new id]

Execution-plane не решает retry policy сам. Он может только вернуть failure category и retry hints.

Idempotency

Idempotency защищает API от повторной доставки команды.

Правила:

  • executeJob idempotent по idempotency_key;
  • completeAttempt idempotent по attempt_id + terminal payload digest;
  • повторный heartbeat append-only;
  • artifact creation deduplicates by digest where safe.

Observability

Метрики:

  • attempts by status/job type/runner kind;
  • queue latency;
  • lease acquisition latency;
  • execution duration;
  • heartbeat lag;
  • artifact upload duration;
  • failure categories;
  • cancellation latency;
  • runner pool capacity.

Traces:

  • operation_id;
  • plan_node_id;
  • node_run_id;
  • attempt_id;
  • runner_instance_id.

Logs:

  • service logs не содержат secret values;
  • runner raw logs уходят в artifact storage;
  • operational errors имеют stable error code.

Disaster Recovery

После сбоя:

  • dispatcher восстанавливает active attempts из БД;
  • expired leases переводятся в lost;
  • pending outbox events публикуются повторно;
  • callbacks в control-plane-service доставляются повторно;
  • artifact worker проверяет incomplete uploads и помечает artifacts как partial или failed.

Extension Points

  • AI agent может читать logs/evidence через control-plane-service и предлагать repair PlanPatch.
  • IAM добавляет service identities, permissions и approval policy.
  • Audit подписывается на execution events и secret access records.
  • Billing использует attempt duration, runner kind и artifact size.

Эти extensions не получают право обходить JobSpec, Vault refs и runner isolation.

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

На странице

Execution Lifecycle Runner Isolation Policy Approved Commands Secrets Artifacts Cancellation Timeouts Retries Idempotency Observability Disaster Recovery Extension Points