Глоссарий терминов

Строка приглашения в терминале или текстовая инструкция для AI-модели. В Linux prompt показывает, где ты находишься и от какого пользователя работаешь.

В терминале `user@host:/app$` подсказывает пользователя, сервер и текущую директорию.

Стандартный поток обычного вывода программы.

`ls` печатает список файлов в stdout.

Стандартный поток ошибок и диагностических сообщений программы.

`cat missing.txt` пишет ошибку в stderr.

Числовой результат завершения команды. Обычно 0 означает успех, не 0 — ошибку или особое состояние.

CI останавливает job, если команда вернула exit code 1.

Командная оболочка, которая принимает команды пользователя и запускает программы.

Bash и zsh — популярные shell-оболочки.

Передача stdout одной команды во вход следующей команды через символ `|`.

`cat app.log | grep error` передает лог в grep.

Пробный запуск без реального изменения состояния системы.

Перед удалением файлов скрипт показывает dry-run список того, что будет удалено.

Проверка, что сервис жив и отвечает ожидаемым образом.

Endpoint `/health` может возвращать 200, если API готов принимать трафик.

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

`DATABASE_URL` часто передают приложению как env var.

Система управления сервисами в Linux: запускает процессы, следит за unit-ами, пишет события в journal.

`systemctl status nginx` показывает состояние nginx unit-а.

Объект systemd, который описывает сервис, таймер, mount point или другой управляемый ресурс.

`api.service` описывает, как запускать backend API.

Идентификатор процесса в операционной системе.

`ps aux` показывает PID каждого процесса.

Протокол безопасного удаленного доступа к серверу.

`ssh deploy@server` подключает тебя к серверу под пользователем deploy.

Файл SSH, где хранятся известные host keys серверов. Он помогает заметить подмену сервера.

Если host key изменился неожиданно, SSH покажет предупреждение.

Промежуточный сервер, через который подключаются к закрытым внутренним серверам.

К production DB можно попасть только через jump host в VPN.

Рабочее окружение, которым пользуются реальные пользователи.

Изменение в production требует проверки, наблюдаемости и rollback-плана.

Предпродакшен-окружение для проверки изменений перед production.

Pipeline может автоматически деплоить в staging и ждать approval перед production.

Серверная часть приложения: API, бизнес-логика, работа с базой данных и внутренними сервисами.

NGINX может проксировать запросы в backend API.

Клиентская часть приложения, которую видит пользователь: сайт, интерфейс или мобильный экран.

Frontend показывает ошибку, но причина может быть в backend timeout.

Интерфейс, через который программы общаются друг с другом.

Login API принимает credentials и возвращает результат авторизации.

Конкретный адрес или точка API, куда отправляют запрос.

`/health` — endpoint для проверки состояния сервиса.

Linux-команда для изменения прав доступа к файлу или директории.

`chmod +x deploy.sh` добавляет право запуска скрипта.

Linux-команда для изменения владельца и группы файла или директории.

`chown app:app config.yml` передает файл пользователю и группе app.

Три уровня прав Linux: владелец файла, группа и все остальные пользователи.

В `-rwxr-x---` первые права относятся к user, вторые к group, третьи к other.

Три базовых действия в Linux permissions: читать, писать и выполнять.

Для файла execute означает запуск, а для директории — возможность пройти внутрь по пути.

Система, которая переводит доменные имена в IP-адреса и другие записи.

`api.example.com` через DNS указывает на IP балансировщика.

Сетевой протокол с установлением соединения и гарантированной доставкой байтов по порядку.

HTTP чаще всего работает поверх TCP.

Сетевой протокол без установления соединения. Быстрее, но без гарантии доставки.

DNS-запросы часто идут по UDP.

Протокол запросов и ответов между клиентом и сервером.

Браузер отправляет HTTP GET на `/login` и получает HTML или JSON.

HTTP поверх TLS: данные шифруются и проверяется подлинность сервера.

`https://example.com` защищает трафик между браузером и сайтом.

Протокол шифрования и проверки подлинности соединения.

Ошибка сертификата TLS может сломать доступ к API, даже если backend жив.

Числовая точка входа на хосте, через которую процесс принимает сетевые соединения.

Nginx часто слушает 80 и 443 ports.

Сетевой фильтр, который разрешает или блокирует трафик по правилам.

Если firewall закрывает port 443, HTTPS-сайт будет недоступен.

Ситуация, когда операция не успела завершиться за отведенное время.

Timeout при подключении часто означает, что пакет не получил ответа.

Ошибка, когда хост доступен, но на нужном порту никто не принимает соединение или соединение отвергнуто.

Connection refused на 5432 может означать, что PostgreSQL не слушает этот port.

Метаданные HTTP-запроса или ответа: host, content-type, authorization и другие поля.

Header `X-Forwarded-For` помогает backend-у увидеть исходный IP клиента.

Распределение трафика между несколькими экземплярами сервиса.

Load balancer отправляет запросы на разные pod-ы API.

Веб-сервер и reverse proxy, который часто стоит на входе в приложение.

NGINX принимает HTTPS-запрос и проксирует его в backend.

Сервер, который принимает запрос клиента и передает его внутреннему сервису.

Reverse proxy скрывает внутренний адрес backend-а от пользователя.

В NGINX — backend или группа backend-ов, куда proxy передает запрос.

Если upstream не отвечает, пользователь может увидеть 502.

Ограничение частоты запросов или действий за период времени.

Rate limit защищает login API от слишком частых попыток.

Запрос от клиента к серверу.

HTTP request к `/checkout` может пройти через NGINX, API gateway и backend.

Ответ сервера на request.

Response содержит status code, headers и body.

Поток сетевых запросов или данных через систему.

Canary получает 5% traffic, чтобы проверить новую версию на малой доле пользователей.

Выбор пути, по которому request попадет к нужному сервису или handler-у.

Ошибка routing в NGINX может привести к 404 или отправке traffic не в тот backend.

Блок конфигурации NGINX, который описывает виртуальный сервер, домен, порты и правила обработки.

Server block с `server_name api.example.com` выбирает правила для API.

Блок NGINX, который выбирает правило обработки для конкретного пути URL.

Location `/api` может проксировать запросы в backend.

Перезагрузка конфигурации сервиса без полной остановки процесса.

После проверки синтаксиса NGINX можно сделать reload, не обрывая traffic.

Лог входящих запросов: кто пришел, куда, с каким status code и временем ответа.

Access log помогает увидеть рост 502 после release.

Лог ошибок сервера или proxy.

NGINX error log может показать upstream timeout.

Проверка конфигурации на синтаксические ошибки перед применением.

Перед NGINX reload запускают syntax check, чтобы не применить битый конфиг.

Усиление безопасности конфигурации за счет отключения лишнего и ограничения поверхности атаки.

NGINX hardening может включать rate limits и безопасные headers.

Система контроля версий, которая хранит историю изменений кода и конфигураций.

Через Git команда видит, кто и зачем изменил Terraform module.

Ветка разработки в Git для отдельной задачи или версии.

Фикс timeout-а можно сделать в branch `fix-api-timeout`.

Снимок изменений в Git с сообщением и автором.

Хороший commit объясняет, почему поменяли NGINX timeout.

Запрос на внесение изменений в основную ветку после review и проверок.

В pull request обычно пишут контекст, риск, проверку и rollback.

Проверка изменений другим инженером перед merge.

Review Terraform plan помогает заметить опасное удаление ресурса.

Версия продукта или инфраструктуры, которую команда готова доставить пользователям.

Release может иметь tag, changelog и набор артефактов.

Возврат системы к предыдущей рабочей версии или состоянию.

Если canary ухудшил latency, pipeline запускает rollback.

Подход, где желаемое состояние инфраструктуры хранится в Git, а система доставки синхронизирует его с окружением.

Argo CD применяет Kubernetes manifests из Git repository.

Главный источник правды о том, каким должно быть состояние системы.

Для GitOps source of truth — репозиторий, а не ручные изменения в кластере.

Инженер, который проверяет изменения перед merge.

Reviewer смотрит diff, risk, tests и rollback-план.

Объединение изменений из одной Git branch в другую.

После approve pull request делают merge в main.

Создание нового commit-а, который отменяет выбранное изменение.

Revert безопаснее reset для общей ветки, потому что история остается понятной.

Команда Git для перемещения указателя ветки или изменения staging area. В общей истории требует осторожности.

Reset в shared branch может сломать работу других инженеров.

Список изменений версии, понятный людям.

Changelog помогает понять, что вошло в release.

Semantic Versioning: схема версий вида major.minor.patch.

В semver версия `2.0.0` обычно означает breaking changes.

Явное подтверждение, что изменение можно продолжать: merge, deploy или apply.

Production deploy может требовать manual approval.

Платформа для сборки образов и запуска контейнеров.

Docker image собирается в CI и отправляется в registry.

Шаблон контейнера: файловая система, зависимости и команда запуска.

Образ `api:1.2.0` можно запустить как контейнер.

Запущенный экземпляр image как изолированный процесс.

Один Docker image можно запустить в нескольких containers.

Файл инструкций для сборки Docker image.

`FROM node:20` задает base image в Dockerfile.

Слой Docker image, который появляется после инструкции сборки и может кешироваться.

Если `package.json` не менялся, слой с `npm install` можно взять из cache.

Сборка Docker image в несколько стадий, чтобы финальный образ был меньше и чище.

В первой стадии компилируют приложение, во вторую кладут только готовый binary.

Хранилище Docker images.

CI пушит image в registry, а Kubernetes забирает его оттуда.

Метка версии образа или Git release.

Image tag `api:git-sha` помогает понять, что запущено в production.

Среда выполнения приложения после запуска.

Ошибка runtime отличается от ошибки build-time.

Этап сборки artifact-а или image до запуска приложения.

Ошибка build-time отличается от runtime-ошибки контейнера.

Компонент, который запускает containers из images.

Container runtime отвечает за запуск процесса, filesystem и isolation.

Метка версии container image.

Image tag `api:git-sha` помогает связать production container с commit-ом.

Слой container image, созданный инструкцией Dockerfile.

Secret нельзя класть в image layer, потому что он может остаться в истории образа.

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

Kubernetes перезапускает pod, если контейнер упал.

Набор узлов и control plane, на котором работает Kubernetes.

Production cluster может состоять из нескольких worker nodes.

Компоненты Kubernetes, которые принимают API-запросы и управляют состоянием кластера.

API server — часть control plane.

Агент на node, который запускает pod-ы и сообщает их состояние control plane.

Если kubelet не работает, node перестает нормально управлять pod-ами.

Минимальная единица запуска в Kubernetes: один или несколько контейнеров с общей сетью и storage.

Deployment создает ReplicaSet, а тот запускает pod-ы.

Kubernetes-объект, который управляет ReplicaSet-ами и rollout-ами приложения.

Deployment поддерживает 3 replicas API-сервиса.

Стабильная точка доступа к pod-ам, выбранным по selector.

Service отправляет трафик на pod-ы с label `app=api`.

Kubernetes-объект для маршрутизации внешнего HTTP/HTTPS-трафика к сервисам.

Ingress направляет `/api` в api-service.

Kubernetes-объект для несекретной конфигурации приложения.

ConfigMap может хранить feature flag или URL публичного endpoint-а.

Kubernetes-объект для чувствительных данных, но сам по себе он не заменяет полноценный secret manager.

Database password можно передать в pod через Secret.

Логическое пространство имен для разделения объектов в Kubernetes.

Staging и production часто живут в разных namespaces.

Пара ключ-значение на Kubernetes-объекте для группировки и выбора.

Service ищет pod-ы по labels.

Правило выбора объектов по labels.

Если selector Service не совпадает с labels pod-ов, endpoints будут пустыми.

Сигнал, что pod готов принимать трафик.

Pod может быть Running, но не Ready.

Процесс выката новой версии приложения.

`kubectl rollout status deployment/api` показывает состояние rollout-а.

Пакетный менеджер для Kubernetes manifests.

Helm chart позволяет переиспользовать templates для разных окружений.

Пакет Helm с templates, values и метаданными.

Chart описывает, как установить приложение в Kubernetes.

Параметры Helm chart-а, которые подставляются в templates.

Values для staging и production могут отличаться replicas и resource limits.

Желаемое состояние системы, описанное в конфигурации.

Kubernetes reconciliation loop приводит cluster к desired state.

Состояние Kubernetes pod-а, означающее готовность принимать traffic.

Pod может быть Running, но не Ready.

Состояние, при котором container или pod запущен, но это не всегда значит, что сервис готов.

Running без readiness не гарантирует, что request пройдет успешно.

Один экземпляр pod-а, которым управляет Deployment или ReplicaSet.

Три replicas API позволяют пережить падение одного pod-а.

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

Kubernetes Service дает DNS-имя для service discovery внутри cluster.

Infrastructure as Code: описание инфраструктуры как кода, который можно ревьюить и применять повторяемо.

Terraform — популярный инструмент IaC.

Инструмент IaC для описания и изменения инфраструктуры через plan/apply.

Terraform plan показывает, какие ресурсы будут созданы, изменены или удалены.

HashiCorp Configuration Language: язык конфигурации Terraform.

В HCL описывают resources, variables и outputs.

Плагин Terraform для работы с конкретным API: AWS, GCP, Kubernetes и другими.

AWS provider умеет создавать VPC, EC2 и security groups.

Объект инфраструктуры, которым управляет Terraform.

`aws_s3_bucket` — Terraform resource.

Файл состояния Terraform, где хранится связь между кодом и реальными ресурсами.

Remote state нужен команде, чтобы не расходиться в изменениях.

Блокировка state на время изменения, чтобы два apply не конфликтовали.

State locking защищает production от параллельных apply.

Переиспользуемый блок Terraform-конфигурации с входами и выходами.

VPC module можно использовать в dev, staging и production.

Расхождение между описанием инфраструктуры в коде и реальным состоянием.

Ручное изменение security group в облаке создает drift.

Инструмент configuration management для настройки серверов через playbooks.

Ansible может поставить nginx на 20 серверов одинаково.

Свойство операции давать один и тот же итог при повторном запуске.

Повторный Ansible playbook не должен ломать уже настроенный сервер.

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

Plan важнее простого diff, потому что показывает реальное влияние на инфраструктуру.

Применение описанного состояния к реальной инфраструктуре.

Terraform apply выполняют после review plan-а.

Удаление ресурса или инфраструктуры через IaC-инструмент.

Destroy в production должен быть явно замечен на review.

Входные параметры модуля или job-а.

Terraform module принимает inputs вроде region и CIDR.

Выходные значения модуля или команды, которые можно использовать дальше.

VPC module может отдавать subnet IDs через outputs.

Именованные значения, которые делают конфигурацию переиспользуемой.

Variables позволяют отличать dev, staging и production без копирования кода.

Identity and Access Management: управление пользователями, ролями и правами доступа.

Terraform review должен внимательно проверять IAM permissions.

Virtual Private Cloud: изолированная сеть в облаке.

VPC module обычно создает subnets, route tables и security groups.

Облачное правило сетевого доступа к ресурсу.

Security group не должен открывать database port всему интернету.

Практики автоматической проверки, сборки и доставки изменений.

CI запускает тесты на PR, CD выкатывает проверенный artifact.

Цепочка автоматических стадий: validate, test, build, scan, deploy.

Pipeline останавливает release, если tests failed.

Описание автоматического процесса, например GitHub Actions workflow.

Workflow запускается на pull request.

Отдельная задача внутри pipeline или workflow.

Job `build-image` собирает Docker image.

Машина или контейнер, где выполняются job-ы pipeline.

GitHub-hosted runner запускает steps workflow-а.

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

Docker image, test report и coverage report могут быть artifacts.

Сохраненные данные для ускорения повторных запусков.

Cache npm dependencies ускоряет pipeline.

Доставка новой версии приложения или конфигурации в окружение.

Deploy в staging идет автоматически, а production требует approval.

Короткая проверка после deploy, что основные функции живы.

Smoke check открывает `/health` и делает тестовый login.

Постепенный rollout новой версии на маленькую долю трафика.

Canary получает 5% traffic, и система сравнивает error rate с baseline.

Стратегия деплоя с двумя окружениями: старое обслуживает трафик, новое готовится рядом.

После проверки трафик переключают с blue на green.

Переключатели функций без нового deploy.

Feature flag позволяет отключить новую рекомендацию без rollback всего release.

Software Bill of Materials: список компонентов и зависимостей артефакта.

SBOM помогает понять, затронута ли система новой CVE.

Доказуемое происхождение artifact-а: где, кем и из какого исходного кода он был собран.

Provenance снижает риск подмены image в supply chain.

Цепочка происхождения и доставки кода, зависимостей, артефактов и окружений.

Supply chain security защищает pipeline от подмены dependency или image.

Способность понимать состояние системы по внешним сигналам: metrics, logs, traces и events.

Observability помогает понять, почему p95 latency выросла после release.

Числовые time series, показывающие состояние системы во времени.

Request rate, error rate и latency — типовые metrics.

Записи событий приложения или инфраструктуры.

Log с request id помогает связать ошибку с конкретным запросом.

Данные о пути запроса через несколько сервисов.

Trace показывает, что задержка появилась в database call.

Экран с ключевыми метриками и сигналами для диагностики.

Хороший dashboard отвечает на рабочий вопрос, а не просто красиво выглядит.

Система сбора и хранения metrics, часто используется с Kubernetes.

Prometheus scrape-ит `/metrics` endpoint приложения.

Инструмент для dashboards и визуализации данных из Prometheus, Loki и других источников.

Grafana dashboard показывает latency, traffic, errors и saturation.

Система хранения и поиска logs от Grafana Labs.

Loki помогает искать logs по labels сервиса и namespace.

Стандарт и набор инструментов для сбора metrics, logs и traces.

OpenTelemetry instrumentation добавляет trace id в запросы.

Сигнал, который требует внимания или действия человека/системы.

Actionable alert содержит симптом, impact, runbook и escalation path.

Пошаговая инструкция для диагностики или восстановления сервиса.

Runbook для API 5xx говорит, какие metrics, logs и rollback проверить.

Дежурство инженера, который реагирует на production-инциденты.

On-call engineer получает page, оценивает severity и начинает triage.

Передача проблемы на следующий уровень ответственности, если её нельзя решить быстро или безопасно.

Если database outage длится больше 10 минут, runbook требует escalation DBA-команде.

Service Level Indicator: измерение пользовательски важного поведения сервиса.

Доля успешных login-запросов — SLI availability.

Service Level Objective: целевое значение SLI за период.

99.9% успешных login-запросов за 28 дней — SLO.

Service Level Agreement: внешний договор с пользователями или клиентами, часто с последствиями нарушения.

SLA может обещать компенсацию при нарушении availability.

Допустимый объем ошибок или недоступности, который остается в рамках SLO.

Если error budget почти сгорел, команда может замедлить risky releases.

Скорость расходования error budget.

Высокий burn rate по 1h и 6h окнам может означать срочный incident.

Событие, которое ухудшает пользовательский опыт или нарушает надежность сервиса.

Рост 5xx на checkout — incident, если пользователи не могут оплатить заказ.

Класс серьезности incident-а по влиянию на пользователей и бизнес.

SEV1 обычно означает большой impact и срочную координацию.

Роль человека, который координирует incident response и следит за процессом.

Incident commander не обязан сам чинить, его задача — управление ситуацией.

Разбор incident-а после восстановления: impact, timeline, causes, corrective actions.

Blameless postmortem улучшает систему, а не ищет виноватого.

Повторяемая ручная операционная работа, которую стоит автоматизировать или убрать.

Ручной перезапуск одного и того же worker-а каждую неделю — toil.

Планирование ресурсов и запаса мощности под текущую и будущую нагрузку.

Capacity planning учитывает рост traffic, CPU, memory и database connections.

Запас ресурса до насыщения или деградации.

Если CPU держится на 85%, headroom может быть слишком маленьким.

Проверка поведения системы под заданной нагрузкой.

Load testing checkout показывает p95 latency при 100 RPS.

Базовый уровень метрики или поведения, с которым сравнивают изменения.

Новый release сравнивают с baseline latency прошлой версии.

95-й перцентиль: 95% значений не выше этой величины.

p95 latency 300 ms означает, что 95% запросов быстрее или равны 300 ms.

Насыщение ресурса: система близка к пределу CPU, memory, IO, queue или connections.

Рост queue length может показывать saturation worker-ов.

Механизм, который замедляет входящий поток, когда система не успевает обработать нагрузку.

Backpressure лучше, чем бесконечно растущая queue и падение сервиса.

Контролируемое ухудшение функциональности вместо полного падения сервиса.

Если recommendations недоступны, checkout продолжает работать без рекомендаций.

Запасное поведение при сбое зависимости или функции.

Fallback может вернуть cached response, если внешний API не отвечает.

Recovery Time Objective: сколько времени допустимо восстанавливать сервис.

RTO 30 минут означает, что восстановление должно уложиться в 30 минут.

Recovery Point Objective: сколько данных допустимо потерять по времени.

RPO 5 минут означает, что backup/replication допускают потерю не больше 5 минут данных.

Контролируемые эксперименты, проверяющие устойчивость системы к сбоям.

Chaos experiment может отключить одну zone с маленьким blast radius.

Максимальный масштаб влияния сбоя или эксперимента.

Перед chaos test важно ограничить blast radius одним сервисом или namespace.

Условие, при котором эксперимент или rollout надо немедленно остановить.

Если error rate выше 2%, canary должен остановиться по abort condition.

Site Reliability Engineering: инженерная практика построения надежных сервисов через SLO, automation, incident response и постоянное улучшение системы.

SRE помогает решить, когда ускорять релизы, а когда тратить error budget на надежность.

Пользовательский сценарий оформления заказа или оплаты. В учебных примерах это критичный бизнес-flow.

Если checkout тормозит, пользователь может не завершить покупку.

Задержка: сколько времени занимает request, операция или ответ сервиса.

Рост p95 latency после release может означать performance regression.

Надежность сервиса с точки зрения пользователя: доступность, корректность и предсказуемое время ответа.

Reliability измеряют через SLI/SLO, а не через ощущение “вроде работает”.

Скорость, с которой команда доставляет новые возможности пользователям.

SRE ищет баланс между feature velocity и reliability.

Доступность: доля времени или запросов, когда сервис успешно выполняет свою функцию.

99.9% availability допускает ограниченный error budget за период.

Время, в течение которого система или процесс остается запущенным.

Uptime сам по себе не доказывает, что пользователи получают корректные ответы.

Доля запросов или операций, завершившихся ошибкой.

Canary останавливают, если error rate новой версии выше baseline.

Идентификатор запроса, который помогает связать logs, traces и события между сервисами.

По request id можно найти весь путь проблемного checkout-запроса.

Событие в системе: deploy, restart, error, alert или изменение состояния.

Kubernetes events помогают понять, почему pod не стал Ready.

Классические сигналы мониторинга: latency, traffic, errors и saturation.

Golden signals помогают быстро понять форму production-проблемы.

Алерт, по которому понятно, что случилось, насколько это важно и что делать дальше.

Actionable alert ведет к runbook-у и содержит impact.

Хронология incident-а или изменения: что произошло и когда.

Timeline помогает связать deploy в 14:02 с alert в 14:05.

Быстрая первичная оценка проблемы: impact, severity, владелец и следующий шаг.

Во время triage команда решает, это SEV1 или локальная деградация.

Передача контекста другому инженеру или смене.

Handoff должен содержать статус, гипотезы, уже сделанные проверки и следующий шаг.

Конкретное действие после incident-а с владельцем, сроком и ожидаемым эффектом.

Action item “добавить alert” полезен только если понятно, какой риск он снижает.

Исправляющее действие, которое снижает вероятность или impact повторения incident-а.

Corrective action может добавить rate limit или улучшить rollback.

Более широкий сценарий действий для класса ситуаций. Runbook обычно более пошаговый и конкретный.

Playbook incident response описывает роли, коммуникацию и escalation.

Резервная копия данных или конфигурации для восстановления.

Backup бесполезен без регулярного restore drill.

Учебная проверка восстановления из backup-а.

Restore drill подтверждает, что RTO/RPO достижимы на практике.

Очередь задач или сообщений, ожидающих обработки.

Рост queue length может быть первым сигналом saturation.

Large Language Model: большая языковая модель, которая генерирует или анализирует текст.

Support-agent может использовать LLM для ответа на вопрос пользователя.

Практики эксплуатации LLM-систем: prompts, routing, evals, tracing, cost и safety.

LLMOps добавляет evals перед изменением prompt template.

Практики доставки и эксплуатации ML-моделей в production.

MLOps включает model versioning, serving, monitoring и rollback.

Запуск модели как сервиса для online или batch inference.

Model serving endpoint принимает запрос и возвращает prediction.

Выполнение модели на входных данных для получения результата.

Online inference должен укладываться в latency budget API.

Графический процессор, который часто используют для ускорения ML inference и training.

GPU capacity дорого стоит, поэтому нужны quotas и cost budgets.

Объединение нескольких запросов в пакет для более эффективной обработки.

Batching может снизить cost per request, но увеличить latency.

Количество задач, которые система обрабатывает одновременно.

Высокая concurrency без лимитов может перегрузить inference API.

Стоимость использования LLM, зависящая от числа входных и выходных tokens.

Длинный prompt повышает token cost каждого запроса.

AI-система, которая может планировать шаги, вызывать tools и действовать по цели.

Agent может искать в knowledge base и создавать ticket через tool.

Механизм, когда модель вызывает внешние функции или сервисы.

Tool calling позволяет agent-у получить статус заказа из API.

Права на выполнение действий или доступ к данным.

Agent должен иметь минимальные permissions для tools.

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

Каждый tool call агента должен попадать в audit log.

Ограничение числа шагов, которые agent может сделать за один запуск.

Step budget защищает от бесконечного цикла agent-а.

Retrieval-Augmented Generation: модель отвечает с опорой на найденные документы или данные.

RAG ищет актуальную инструкцию в knowledge base перед ответом.

База данных для поиска по embedding-векторам.

Vector DB возвращает похожие документы для RAG.

Числовые векторы, которые представляют смысл текста или объекта.

Embeddings позволяют искать похожие статьи по смыслу.

Разбиение документа на небольшие части перед созданием embeddings.

Плохой chunking может ухудшить качество RAG.

База знаний, из которой AI-система берет факты и инструкции.

Support-agent ищет ответы в knowledge base компании.

Проверки качества AI-системы на заранее подготовленных или живых примерах.

Evals ловят regression после изменения prompt-а.

Набор эталонных примеров для сравнения качества моделей, prompts или retrieval.

Перед release support-agent проверяют на golden dataset.

Постепенное ухудшение качества ответов или predictions.

Quality drift может появиться после изменения данных в knowledge base.

Атака, где пользователь пытается заставить модель игнорировать правила или раскрыть данные.

Prompt injection может просить agent-а отправить секреты через tool.

Ограничения и проверки, которые удерживают AI-систему в безопасных рамках.

Guardrails могут блокировать tool call с опасными параметрами.

ML- или AI-модель, которая делает prediction, классификацию или генерирует ответ.

Model version нужно отслеживать так же внимательно, как version backend-а.

Шаблон prompt-а с переменными, который формирует запрос к LLM.

Prompt template можно менять без deploy кода, поэтому нужны evals.

Слой между приложением и LLM provider-ами для routing, retries, limits, logging и cost control.

LLM gateway помогает переключить provider без переписывания business logic.

Поиск релевантных документов или данных перед генерацией ответа.

Если retrieval нашел устаревший документ, RAG-ответ может быть неверным.

Метрика того, как часто retrieval находит полезный документ или правильный источник.

Падение retrieval hit rate может ухудшить ответы support-agent-а.

Оценка качества AI-системы на eval-наборе или online-проверке.

Низкий eval score блокирует rollout нового prompt-а.

Числовая оценка качества ответа, retrieval или поведения модели.

Quality score можно сравнивать с baseline после изменения model version.

Практики ограничения и наблюдения расходов на инфраструктуру или AI inference.

Cost control для LLM включает quotas, token budgets и alerts на cost spike.

AI-агент или сервис, который помогает отвечать на обращения поддержки.

Support-agent должен логировать prompt, tool calls и final response.