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

Этот глоссарий покрывает термины, которые используются по всей книге: в главах и приложениях.

Если термин встречается в исходном английском написании (например, Bus factor, CI/CD, p95) — это сделано намеренно: чтобы сохранять совместимость с привычной инженерной терминологией и поиском по материалам.

Сокращения#

• ADR: Architecture Decision Record — документ, фиксирующий архитектурное решение, контекст и причины выбора.
• AI: Artificial Intelligence — здесь: модели и инструменты, на базе которых работают агенты.
• AC: Acceptance Criteria — критерии приёмки (что считается “принято”, как проверять).
• API: Application Programming Interface — контракт взаимодействия сервисов/клиентов.
• Bus factor: “сколько людей может выпасть из команды, прежде чем работа остановится”; практически — сколько людей способны выполнить критичную задачу без эскалации к одному эксперту.
• CI/CD: Continuous Integration / Continuous Delivery — контур сборки/тестирования/доставки.
• DoD: Definition of Done — критерии “готово” для задачи/итерации (доказуемые, проверяемые).
• CTO: Chief Technology Officer — технический директор.
• DevOps: практики и роль на стыке разработки и эксплуатации (доставка изменений, инфраструктура, автоматизация).
• IaC: Infrastructure as Code — управление инфраструктурой через код (Terraform/Ansible и т.п.).
• MTTD: Mean Time To Detect — среднее время обнаружения инцидента (до алерта/старта реакции).
• MTTR: Mean Time To Resolve/Recover — среднее время восстановления после инцидента.
• NFR / НФТ: Non-Functional Requirements — нефункциональные требования (производительность, надёжность, безопасность, сопровождаемость и т.п.).
• PII: Personally Identifiable Information — персональные данные/идентифицирующая информация.
• PR: Pull Request — запрос на слияние изменений (обсуждение/ревью/проверки → merge).
• ROI: Return on Investment — окупаемость инвестиций.
• SRE: Site Reliability Engineering — инженерия надёжности (SLO/SLI, инциденты, устранение системных причин).
• SLA: Service Level Agreement — договорные обязательства по уровню сервиса.
• SLI: Service Level Indicator — измеримый показатель сервиса (например, p95‑задержка).
• SLO: Service Level Objective — целевое значение для SLI.
• TCO: Total Cost of Ownership — совокупная стоимость владения.
• TTRC: Time To Root Cause — время до определения первопричины.
• VP Engineering: руководитель инженерного направления (вице‑президент по инженерии).
• VPN: Virtual Private Network — защищённое подключение к внутренним ресурсам.

Нотация плейсхолдеров#

В книге часто используются плейсхолдеры (значения‑заглушки) в угловых скобках — например, <WINDOW>, <THRESHOLD>, <TTRC_SECONDS>.

Правила:

• Формат: <UPPER_SNAKE_CASE> без пробелов внутри (например, <WINDOW>, а не <WINDOW> с пробелами внутри угловых скобок).
• Смысл: плейсхолдеры не являются “пропуском” и не требуют перевода. Это переменные, которые нужно заменить на ваши реальные значения/пороги.
• Граница применимости: плейсхолдеры используются в шаблонах (промпты/SOP/runbooks/AC/DoD). В боевых документах/артефактах их либо заменяют, либо явно помечают как TBD.

Примеры заполнения:

• <WINDOW> — окно времени: 30m, 24h, 7d (например: “за последние <WINDOW>” → “за последние 7d”).
• <THRESHOLD> — порог: 0.5%, 200ms, 80% CPU (например: “доля ошибок > <THRESHOLD>” → “доля ошибок > 0.5%”).
• <N> — количество: 50, 1000 (например: “топ‑<N> инцидентов” → “топ‑50 инцидентов”).
• <TTRC_SECONDS> / <TTRC_TARGET> — фактическое/целевое время до первопричины: 900 / 600 (секунды) или в явном формате, который вы используете.

Термины и артефакты#

• ИИ‑агент: автономный исполнитель задач на базе модели/инструмента, который действует в заданной роли и по правилам (ограничениям), создаёт артефакты, делает проверки и эскалирует при неопределённости/рисках.

• Rules (правила проекта): постоянный контекст и конвенции, которые применяются “всегда” (например: команды сборки/тестов, требования к стилю, правила безопасности и процесса разработки). Смысл — дать агенту и команде короткий набор неизменяемых “рельс”, вместо копирования одних и тех же инструкций в каждый диалог.

• Разрешённый список (allowlist): перечень допустимых действий/команд/операций. Всё остальное — запрещено по умолчанию.

• Журнал аудита: журнал “кто/что/когда сделал” (команды, изменения, решения, артефакты), чтобы можно было расследовать инциденты и обеспечивать контроль.

• Базовый уровень: точка отсчёта “как было до” (метрики/качество/скорость), с которой сравнивают изменения.

• Обратно совместимо: изменение не ломает существующих клиентов/контрактов; откат возможен без “домино‑эффекта”.

• Бизнес‑кейс (business case): обоснование внедрения (зачем, эффект, риски, критерии успеха, план пилота).

• CAB: Change Advisory Board — комитет/процесс согласования изменений (классический ITIL‑подход).

• Canary rollout / канареечная выкатка: постепенный выпуск изменения на малую долю трафика/инстансов с измерением метрик перед расширением.

• Управление изменениями: дисциплина внедрения изменений в процессах/инструментах/ролях так, чтобы трансформация была управляемой (а не “хаосом внедрения”).

• dry-run: выполнение операции в режиме “без применения” (например, --check) для проверки ожидаемых эффектов.

• eval-набор: набор тестовых сценариев/кейсов для измерения качества работы агента (например, инциденты из истории).

• Edge case (краевой случай): редкий/сложный сценарий, на котором система часто ломается; противоположность “типовому” кейсу.

• Доказательства (evidence): не обещания, а наблюдаемые данные: метрики, артефакты, журналы действий, результаты проверок.

• Пакет решения (decision packet): краткий проверяемый артефакт, который отделяет факты от гипотез, фиксирует риск и явно показывает, что требует подтверждения, и какие проверки/следующие шаги планируются. В тексте книги: при первом упоминании пишем «пакет решения (decision packet)», дальше — «пакет решения».

• TRACE: блок “аудита контекста” в ответе агента: что именно было реально прочитано и использовано (правила, SKILL.md, ссылки на артефакты) — чтобы можно было понять, на чём стояли выводы и как воспроизвести результат.

• Контрольная точка качества: контрольная точка, на которой агент обязан остановиться и предъявить артефакты/доказательства для проверки (обычно человеком или автоматикой).

• ROUTER / Skill Router (роутер ролей/навыков): дисциплина маршрутизации перед ответом: агент выбирает одну базовую роль (base) для выполнения и 0..N ролей‑проверяющих (checkers) по risk/touchpoints, затем фиксирует TRACE и только после этого пишет основной ответ.

• Ревью человеком: контрольная точка, на которой результат обязан пройти ревью человеком перед продолжением (или перед опасным/необратимым шагом).

• golden tests (эталонные тесты): фиксированный набор проверок/кейсов, который служит “эталоном” качества при изменениях агента/процессов.

• Agent Skills: открытый формат переносимых процедур и пакетов знаний для агентов. Артефакт живёт в папке, содержит SKILL.md (метаданные + инструкции) и может включать scripts/, references/, assets/.

• SKILL.md: основной файл Agent Skill с YAML frontmatter (name, description и др.) и инструкциями в Markdown. В тексте книги “обновить/версионировать skill” означает внести правки в SKILL.md (и связанные материалы в папке Agent Skill).

• Подгрузка по требованию (progressive disclosure): принцип экономии контекста: сначала агент видит только метаданные Agent Skills (когда использовать), затем подгружает полный текст SKILL.md и дополнительные ресурсы только для выбранного Agent Skill.

• go/no-go: решение “продолжаем/останавливаем” (обычно после пилота или контрольной точки), принятое по заранее заданным критериям.

• Ограничения: явные правила “что нельзя/что можно”, права доступа, запреты на опасные операции, требование подтверждения и т.п.

• read_only: режим работы, в котором исполнитель имеет право только читать/собирать данные и формировать артефакты, но не имеет права менять состояние систем (особенно production). Любые действия, меняющие состояние, требуют явного подтверждения и/или отдельного контура исполнения.

• Handoff (передача контекста): дисциплина передачи подзадачи отдельному исполнителю: цель, входные артефакты, ограничения/права, формат выхода и условия остановки. Нужна потому, что специализированный исполнитель часто стартует “с чистого контекста” и не имеет доступа к предыдущему диалогу.

• Happy path: типовой сценарий без ошибок/нештатных условий.

• Идемпотентность: повторное выполнение операции не меняет итоговый результат (или меняет предсказуемо и безопасно).

• Инцидент: событие, которое приводит к деградации/недоступности сервиса или нарушению SLO/SLA.

• Канбан / WIP limits: ограничение “работы в процессе” (Work In Progress), чтобы снижать переключение контекста и повышать предсказуемость.

• Kill switch (аварийный выключатель): механизм мгновенного отключения агента/функции при риске или деградации.

• Least privilege (минимальные привилегии): принцип выдачи только тех прав, которые необходимы для работы (и не больше).

• Linter (линтер): статическая проверка кода/текста на ошибки и стиль.

• Внешнее подтверждение: подтверждение действия через отдельный канал/процесс, независимый от текста/контекста, который может быть скомпрометирован (например, ручное подтверждение в UI/чат‑команде).

• p95 / p99: перцентили; p95 — значение, ниже которого укладывается 95% наблюдений (аналогично p99).

• Prompt injection (инъекция промпта): атака/ошибка, когда агент воспринимает внешние данные (логи, тикеты, комментарии) как инструкцию и нарушает правила.

• Шаблон промпта: воспроизводимая форма постановки задачи (контекст → ограничения → критерии готовности → план проверки → ожидаемый выход).

• Commands (команды / шорткаты): повторяемые сценарии работы, оформленные так, чтобы их можно было запускать “одной строкой” (например: подготовить PR, прогнать проверки, собрать отчёт). Это полезно для частых кейсов, где важны одинаковые шаги и одинаковый формат результата.

• Маскирование (redaction): автоматическое скрытие/удаление секретов и PII из логов/артефактов.

• Регрессия: ухудшение метрики/качества после изменения.

• Риск‑регистр: список рисков с описанием сценария, последствий, митигаций и способов проверки.

• Rollback (откат): заранее продуманный и проверяемый способ быстро вернуть систему в стабильное состояние.

• runbook / runbooks: исполнимый или полу‑исполняемый сценарий действий при инциденте/операции (шаги + условия + проверки + эскалация). В RU‑тексте книги термин пишем моноширинно: runbook (ед.ч.) / runbooks (мн.ч.), без транслитерации.

• SOP (Standard Operating Procedure): стандартная операционная процедура — воспроизводимый процесс выполнения типовой задачи (шаги, условия остановки, проверки, артефакты, критерии готовности).

• Условия остановки (stop conditions): критерии, при которых агент обязан прекратить выполнение и эскалировать человеку (нехватка данных, высокий риск, опасное действие, неоднозначность).

• Subagent (специализированный исполнитель): “второй агент” с отдельным контекстом, которому делегируют подзадачу ради фокуса и изоляции контекста. Важно: это концепт исполнения/организации работы, а не обязательная фича конкретного вендора.

• Модель угроз (threat model): систематическое описание активов, угроз, векторов атак и митигаций перед развёртыванием в продакшене.

• Triage (триаж): первичная сортировка и диагностика инцидента: собрать факты, сузить гипотезы, принять решение об эскалации/действии.

• Verifier (верификатор): независимый “скептик”, который проверяет, что заявленное “готово” действительно работает: прогоняет релевантные проверки, ищет пропуски и крайние случаи, возвращает отчёт “что проверено и прошло / что сломано / что не проверено”.

• Проверка / план проверки: как именно убедиться, что результат корректен (выборка кейсов, крайние случаи, метрики, сравнение “до/после”, критерии принятия).

• Версионирование: правила версионирования шаблонов/промптов/процессов, чтобы отслеживать “ломающие” изменения и совместимость.

• Тест-раннер: исполнитель, который проактивно запускает тесты/проверки (в том числе golden tests) при изменениях и доводит контур до “зелёного”, не переписывая ожидания тестов под текущую реализацию.

• Debugger (отладчик): специализированный исполнитель для поиска первопричины (root cause analysis): воспроизведение симптома → локализация → минимальный фикс/эксперимент → проверка результата с доказательствами.

Инструменты и форматы (в контексте книги)#

• Агент: агент, который может читать/менять файлы, запускать команды, собирать артефакты и вести задачу end‑to‑end (например, Cursor Agent).
• Чат‑режим: модель/интерфейс в режиме диалога (например, ChatGPT/DeepSeek в чат‑режиме), удобен для обсуждения, дизайна, исследования.
• JSON / YAML: форматы данных/конфигов, часто используются в примерах (логи, конфиги, пайплайны).