Глоссарий

Глоссарий — единое место истины для терминов в проекте. Каждая запись содержит оригинал (английский или аббревиатура), русский эквивалент (если применим), краткое определение и ссылки на листья, где термин используется в контексте.

В каждой записи указана категория по принципу из inventory/terminology.md:

• A — устоявшийся в SRE-индустрии англицизм; не переводим, пишем латиницей курсивом без склонения.
• B — есть устоявшийся русский перевод; используем перевод в листьях.
• C — двойная форма при первом упоминании: русский (английский).
• D — спорные; решение по контексту.

Глоссарий растёт инкрементально. Если встретили термин в листе, которого здесь нет, — это хорошая причина открыть PR.

A

ABAC

Attribute-Based Access Control — модель авторизации, в которой решение «можно ли» вычисляется из атрибутов subject (роль, department, clearance), resource (sensitivity, owner) и context (time, IP, MFA strength). Решает scaling-проблему RBAC в больших orgs (role explosion), но требует attribute hygiene — кто их валидирует, что происходит при stale attribute.

Категория A — пишется заглавными. См. Access Control & IAM.

ADR

Architecture Decision Record — фиксация технического решения в формате context → decision → consequences, версионируется в git, ревьюится в PR. Через два года новый engineer открывает ADR и понимает, почему было принято решение, — не «решили в чате полтора года назад».

Категория A — пишется заглавными. См. Architecture Decision Records. Источник: Michael Nygard, Documenting Architecture Decisions (2011); adr.github.io.

action items

Конкретные задачи с владельцем, дедлайном, приоритетом и критерием готовности. Появляются на постмортеме или ином ритуале. Без всех четырёх атрибутов action item — «доброе пожелание», и через два-три невыполненных списка убивает доверие к ритуалу.

Категория C — двойная форма «задачи (action items)» при первом упоминании. См. Blameless Postmortem, Postmortem Culture. Источник: Beyer et al., SRE Book, гл. 15.

alert fatigue

Состояние, в котором команда теряет способность отличать актуальные сигналы от шума из-за большого количества алертов. Симптом — actionable rate ниже 50%, дежурный ack’ает на автомате и пропускает реальные инциденты.

Категория B — «усталость от алертов». См. Alert Fatigue Management, On-Call Rotation.

aspirational SLO

Цель, которую команда уже измеряет и показывает рядом с действующим SLO, но по которой пока не обязана действовать: в политике бюджета прямо записано, что её нарушение ничего не запускает. В Workbook описана для случая, когда правильная цель жёстче нынешних возможностей продукта и вводить её сразу значит жить в постоянном нарушении.

Категория D — устоявшегося перевода нет; пишется латиницей курсивом, смысл раскрывается в предложении. См. SLO Engineering. Источник: Beyer et al., SRE Workbook, гл. 2.

attack surface

Сумма всех точек, через которые потенциальный атакующий может попасть в систему: открытые порты, публичные API, зависимости, права у пользователей. Минимизация attack surface снижает вероятность компрометации.

Категория B — «поверхность атаки». См. Vulnerability Management, Threat Modeling.

audit trail

Хронологический след действий, по которому через год можно восстановить «кто, когда и почему» сделал изменение. Реализуется через git history, IAM audit log, structured incident log.

Категория B — «журнал аудита» (или «след аудита», если рядом уже стоит «log»). См. Service Ownership, GitOps, Secrets Management.

auto-scaling

Динамическое изменение количества compute-ресурсов в ответ на нагрузку. В Kubernetes — HPA (по CPU/memory/custom metrics), VPA (resource recommendations), Cluster Autoscaler (node-level). Решает reactive часть масштабирования, но не заменяет capacity planning — auto-scaling упрётся в node-pool limit или cloud quota, если capacity не была спрогнозирована заранее.

Категория A — устоявшийся англицизм. См. Capacity Planning.

B

backup

Резервная копия данных, сделанная для возможности проверенного восстановления при потере primary. В SRE-практике главная дисциплина — untested backup ≠ backup: backup, который никто никогда не восстанавливал, существует только на бумаге. Используется в паре с явными RPO/RTO и регулярными restore-drills с измеряемым MTTR.

Категория A — устоявшийся англицизм; «бэкап» как транслитерация допустима в неформальном контексте. См. Backup & Restore.

blameless

Принцип разбора инцидентов, в котором фокус на системе, а не на «кто это сделал». Разбор по умолчанию исходит из того, что у каждого участника были добрые намерения и он поступал правильно при той информации, что у него была. Психологическая безопасность — предпосылка blameless, не следствие шаблона.

Категория A — пишется латиницей курсивом, без склонения. См. Postmortem Culture, Blameless Postmortem. Источник: Allspaw, Blameless PostMortems and a Just Culture (Etsy, 2012); Dekker, The Field Guide to Understanding ‘Human Error’; Beyer et al., SRE Book, гл. 15.

break-glass

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

Категория C — «аварийный доступ (break-glass)» при первом упоминании, дальше «аварийный доступ». См. Disaster Recovery, Access Control & IAM.

bulkhead

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

Категория C — «изоляция по отсекам (bulkhead)» при первом упоминании, дальше «отсеки». См. Resilience Patterns. Источник: Michael Nygard, Release It!; Netflix, Hystrix: How it Works.

burn rate

Скорость, с которой сервис сжигает error budget. При burn rate 14.4× тридцатидневный бюджет исчерпан за 50 часов. Используется как input для multi-window multi-burn-rate alerting.

Категория A. См. SLI-based Alerting, SLO / Budget Review. Источник: Beyer et al., SRE Workbook, гл. 5.

C

canonical log line

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

Категория C — «каноническая строка лога (canonical log line)» при первом упоминании. См. Logging. Источник: Brandur Leach, Fast and flexible observability with canonical log lines (Stripe, 2019).

canary release

Стратегия выкатки изменения малыми долями трафика (5 / 25 / 50 / 100%) с health gate по SLI на каждом шаге. При нарушении burn rate — автоматический rollback. Не путать с blue-green (две полные версии, переключение целиком).

Категория A. См. Progressive Delivery.

calibration meeting

Регулярная встреча руководителей одной зоны ответственности, на которой они вместе пересматривают свои рекомендуемые уровни для инженеров и согласовывают общую интерпретацию career ladder. Без неё команда A и команда B имеют расходящиеся «L5», решения о повышениях становятся несправедливыми, зарплатные диапазоны разъезжаются. Ритм — полугодие или квартал; результат — общая интерпретация ladder и решения о повышениях на основе артефактов.

Категория B — «калибровка / калибровочная встреча». См. Calibration Meeting.

career ladder

Документированная система уровней инженерных ролей и критериев переходов между ними — expectations per level (skills, scope, impact, behaviours) плюс явные signals для promotion. Engineer читает, чтобы понять, что от него ожидается; manager использует для review; calibration meeting уточняет применение между командами.

Категория C — двойная форма «карьерная лестница (career ladder)» при первом упоминании. См. Career Ladders. Источник: Will Larson, Staff Engineer; Progression.fyi (75+ публичных ladders).

cardinality

Число уникальных комбинаций значений измерений. В модели Prometheus каждая уникальная комбинация label образует отдельный временной ряд; labels с неограниченным множеством значений (user_id, email, request ID) могут резко увеличить объём данных.

Категория A — «кардинальность (cardinality)» при первом упоминании. См. Telemetry Economics. Источник: Prometheus — Metric and label naming.

change failure rate

Доля deploy, после которых требуется немедленное вмешательство, например rollback или hotfix. Одна из двух метрик нестабильности в текущей модели DORA; требует явного определения deployment и intervention для приложения или сервиса.

Категория A. См. DORA Metrics, Change Governance.

chaos engineering

Дисциплина hypothesis-driven экспериментов, в которых система вводится в контролируемый сбой ради проверки её resilience-свойств. Не «сломаем что-нибудь», а явная steady-state hypothesis → инъекция → измерение → вывод.

Категория A. См. Chaos Engineering. Источник: Rosenthal & Jones, Chaos Engineering: System Resiliency in Practice (O’Reilly, 2020).

CI/CD

Continuous Integration / Continuous Delivery (или Deployment). Pipeline сборки, тестов и доставки кода в production как кодовый артефакт. Платформа, на которой работают progressive delivery, IaC, GitOps.

Категория A. См. CI/CD. Источник: Humble & Farley, Continuous Delivery (Addison-Wesley, 2010).

ChatOps

Operations через chat-интерфейс с встроенным audit trail. Термин ввёл GitHub около 2011 с Hubot. Три уровня: push (нотификации в chat — alerts / CI), pull (bot отвечает на queries — /oncall, /status), action (триггер операций через chat — /deploy, /incident declare). Современные incident-platforms (incident.io, Netflix Dispatch, FireHydrant) — Slack-native ChatOps.

Категория A — пишется без склонения. См. ChatOps, Severity Classification, Incident Response.

circuit breaker

Обёртка вокруг вызова зависимости с тремя состояниями. В замкнутом вызовы идут как обычно и считаются ошибки. Когда ошибок становится больше порога, цепь размыкается: вызовы сразу получают отказ или запасной ответ и до зависимости не доходят. После паузы наступает полуоткрытое состояние: проходит пробный вызов, и по его результату цепь замыкается или размыкается снова.

Категория A — пишется латиницей без склонения; состояния называются по-русски: замкнут, разомкнут, полуоткрыт. См. Resilience Patterns, Service Mesh. Источник: Michael Nygard, Release It!; Martin Fowler, CircuitBreaker (2014).

cognitive load

Объём знаний и контекста, который команда удерживает «в голове», чтобы продолжать работать с системой. Skelton/Pais выделяют три типа (intrinsic, extraneous, germane); рабочая SRE-эвристика — «сколько сервисов и технологий держит команда без потери качества». Превышение → degraded incident response, устаревающие runbook’и, on-call lottery. Решается либо split на меньшие team boundaries, либо инвестицией в платформу, которая снимает extraneous load. Во втором издании книги когнитивная нагрузка поднята до уровня принципа проектирования организации, а не одного из соображений.

Категория C — «когнитивная нагрузка (cognitive load)» при первом упоминании. См. Team Topologies, Toil. Источник: Skelton & Pais, Team Topologies (IT Revolution, 1-е изд. 2019, 2-е изд. 2025).

context propagation

Передача идентификатора трейса и идентификатора родительского спана вместе с запросом, от сервиса к сервису. Без неё спаны разных сервисов не складываются в одно дерево. В OpenTelemetry по умолчанию контекст едет в заголовке traceparent из спецификации W3C Trace Context.

Категория C — «передача контекста (context propagation)» при первом упоминании, дальше «передача контекста». См. Distributed Tracing. Источник: OpenTelemetry, Context propagation.

contributing factors

Множество условий, совместное наступление которых вызвало инцидент. Подход NBJS (Necessary But Only Jointly Sufficient) альтернативен наивному поиску «root cause»: вместо одной причины — список факторов, каждый из которых отдельно предотвратил бы инцидент.

Категория C — двойная форма «факторы вклада (contributing factors)» при первом упоминании. См. Postmortem Culture. Источник: Allspaw, Each Necessary, But Only Jointly Sufficient.

Conway’s Law

«Любая организация, которая проектирует систему, неизбежно произведёт design, чья структура повторяет структуру коммуникации этой организации» (Mel Conway, 1968). В Team Topologies используется не как наблюдение, а как инструмент — inverse Conway maneuver: сначала проектируется желаемая архитектура, отсюда выводятся team boundaries.

Категория A — устоявшийся англицизм. См. Team Topologies. Источник: Conway, How Do Committees Invent? (Datamation, 1968).

coverage

Code coverage — процент кода, выполненного тестами. Полезен как diagnostic (что не покрыто) и для сравнения модулей; бесполезен как target. «80% обязательно для merge» через Goodhart’s law порождает тесты без assertions или на trivial code (геттеры) — coverage growth есть, signal value не растёт. Mutation score — гораздо более честная метрика качества тестов, но дороже считать.

Категория A — устоявшийся англицизм. См. Test Strategy.

CUJ

Critical User Journey — последовательность шагов, из которой состоит ключевое для пользователя действие: найти товар, положить в корзину, оплатить. SLO, записанный на такой путь, отвечает на вопрос «смог ли человек сделать то, за чем пришёл». SLO отдельного сервиса на него не отвечает: путь проходит через несколько сервисов и ломается на любом.

Категория C — «критичный пользовательский путь (critical user journey, CUJ)» при первом упоминании, дальше CUJ. См. SLO Engineering. Источник: Beyer et al., SRE Workbook, гл. 2.

CVE

Common Vulnerabilities and Exposures — публичная нумерация известных уязвимостей (CVE-YYYY-NNNN). Поддерживается MITRE; используется как vocabulary в vulnerability management.

Категория A — пишется заглавными. См. Vulnerability Management, Supply Chain Security.

CVSS

Common Vulnerability Scoring System — числовая оценка серьёзности CVE по шкале 0–10. Базовая метрика для приоритизации патчей, но не единственная: combined CVSS + EPSS + asset context даёт actionable очередь, в отличие от наивного «патчим всё что CVSS ≥ 7».

Категория A — пишется заглавными. См. Vulnerability Management.

D

DAST

Dynamic Application Security Testing — поиск уязвимостей в работающем приложении через внешние запросы, без доступа к исходникам. Дополняет SAST (статический анализ кода): видит то, что проявляется только в runtime. Инструменты — OWASP ZAP, Burp Suite.

Категория A. См. Security Code Review, Vulnerability Management.

deadline propagation

Проброс дедлайна: срок ответа назначается один раз на входе в систему и передаётся вниз по цепочке вызовов. Каждый сервис перед очередным шагом проверяет, осталось ли время, и не начинает работу, результат которой уже некому отдать.

Категория C — «проброс дедлайна (deadline propagation)» при первом упоминании, дальше «проброс дедлайна». См. Resilience Patterns. Источник: Beyer et al., SRE Book, гл. 22.

decision log

Отдельный артефакт инцидента, в котором фиксируются значимые решения: кто решил, когда, какие альтернативы рассматривались, какой rollback plan. Не «размешан в Slack scrollback» — отдельный документ. Primary input для постмортема.

Категория B — «журнал решений». См. War Room Patterns.

defense in depth

Принцип многоуровневой защиты: компрометация одного слоя не даёт полного доступа, потому что есть следующий слой. Pre-commit hook → CI scan → historical scan — типичный пример для secrets.

Категория B — «защита в глубину». См. Secrets Management.

deliberate practice

Структурированная учебная практика с измеримым outcome и feedback’ом: формулируется учебная цель (артефакт + критерий выполнения), применяется на реальной задаче, ревьюется с peer’ом. Anders Ericsson показал, что 10000 часов работы сами по себе ничего не значат — нужна именно deliberate practice. Противоположность passive consumption (только книги/курсы без применения).

Категория C — двойная форма «осознанная практика (deliberate practice)» при первом упоминании. См. Personal Growth Plan. Источник: Anders Ericsson, Peak: Secrets from the New Science of Expertise (2016).

deployment frequency

Число deploy за период или время между deploy. Одна из трёх метрик пропускной способности в текущей модели DORA. Читается вместе с метриками нестабильности; сама по себе высокая частота не доказывает качество процесса.

Категория A. См. DORA Metrics, CI/CD, Progressive Delivery.

deployment rework rate

Доля незапланированных deploy, выполненных вследствие production-инцидента. С 2024 года входит в текущую модель DORA как одна из двух метрик нестабильности.

Категория A. См. DORA Metrics. Источник: DORA — история метрик.

DORA

DevOps Research and Assessment. Текущая модель включает пять метрик производительности доставки: change lead time, deployment frequency, failed deployment recovery time, change failure rate и deployment rework rate. Первые три образуют throughput, последние две — instability. Reliability модель относит к операционной производительности, шестой метрикой доставки она не стала.

Категория A. См. DORA Metrics. Источники: актуальное руководство DORA, история изменений модели.

dotfiles

Конфигурационные файлы пользователя в HOME, начинающиеся с точки (.zshrc, .config/nvim, .tmux.conf). Industry-стандарт — хранить в git-репозитории с symlink-deployment (GNU stow или собственный install.sh). Без git-репо не переживают переустановку OS / смену машины. Главный способ переносить personal toolkit между environments.

Категория A — пишется без склонения. См. Personal SRE Toolkit. Источник: dotfiles.github.io (community catalog).

DR

Disaster Recovery — стратегия и политика реагирования на катастрофические сценарии (потеря региона, datacenter fire, cyber-attack, cloud account compromise). DR ≠ backup: backup — технологический слой; DR Policy — governance с decision rights, stakeholder map, RTO/RPO на уровне org. AWS-канонические 4 tier (Backup & Restore / Pilot Light / Warm Standby / Multi-Site Active-Active) — trade-off cost × RTO, выбор per service tier.

Категория A — пишется заглавными. См. DR Policy & Stakeholders, Backup & Restore, RPO / RTO.

drift

Расхождение между желаемым состоянием (в git) и фактическим (в кластере / cloud). В GitOps controller непрерывно сводит drift к нулю; click-ops в проде — источник drift и операционный инцидент.

Категория B — «дрейф (конфигурации)». См. GitOps, Infrastructure as Code.

E

EPSS

Exploit Prediction Scoring System (FIRST.org). Data-driven вероятность активной эксплуатации уязвимости в течение 30 дней. Дополняет CVSS при triage уязвимостей.

Категория A. См. Vulnerability Management.

error budget

«Допустимое количество ошибок» — 1 − SLO target. При SLO 99.9% месячный error budget = 0.1% × 30 дней ≈ 43 минуты. Используется как объективный сигнал «можно ли катить новые фичи».

Категория A. См. SLO Engineering, SLO / Budget Review. Источник: Beyer et al., SRE Book, гл. 4.

error budget policy

Заранее согласованные правила: что команда делает при разном расходе бюджета ошибок, кто останавливает релизы, кто разрешает продолжить и по какому условию возвращается работа над фичами. Документ продуктовый: под ним стоит подпись владельца продукта, потому что это он соглашается, что фичи подождут.

Категория C — «политика бюджета ошибок (error budget policy)» при первом упоминании, дальше «политика бюджета». См. Error Budget Gating, SLO / Budget Review. Источник: Beyer et al., SRE Workbook, приложение B. Заготовка — templates/error-budget-policy.md.

executive swoop

Старший по должности приходит в звонок по инциденту и начинает отменять решения IC, торопить команду или требовать отчёт, который в моменте собирать некому. Название взято из открытого руководства PagerDuty. Там же записан ответ: IC спрашивает «вы берёте командование на себя?». Если да, командование передаётся вслух. Если нет, решения остаются за IC.

Категория D — устоявшегося перевода нет; пишется латиницей, смысл раскрывается в предложении. См. Incident Response. Источник: PagerDuty, Incident Commander training.

F

Four Golden Signals

Четыре метрики, которые покрывают подавляющее большинство симптомов сервиса: latency (длительность обработки запроса), traffic (нагрузка — RPS, активные соединения), errors (доля сбоев), saturation (степень загруженности ресурса до отказа). Применяются как первый проход при разборе неизвестной поломки и как baseline-набор дашбордов для нового сервиса. Комплементарны с USE (для ресурсов) и RED (для сервисов).

Категория A. См. Systematic Troubleshooting, SLI-based Alerting. Источник: Beyer et al., SRE Book, гл. 6 «Monitoring Distributed Systems».

failover

Перевод нагрузки с отказавшей площадки, узла или реплики на резервную. Бывает ручным и автоматическим. Автоматическому нужен координатор, который решает, что основной узел мёртв; его ошибка даёт два узла, принимающих запись одновременно. Время переключения входит в RTO.

Категория C — «переключение (failover)» при первом упоминании, дальше «переключение». См. Disaster Recovery, DR Policy & Stakeholders.

feature flag

Toggle, отделяющий момент выкатки кода (deploy) от момента включения функциональности (release). Позволяет катить код в production в выключенном состоянии и включать для cohort / процента трафика. Категории: release / experiment / ops / permissioning.

Категория A. См. Progressive Delivery. Источник: Pete Hodgson, Feature Toggles (martinfowler.com).

G

golden path

Поддерживаемый и намеренно ограниченный способ сделать типовую вещь: собрать сервис, поднять пайплайн, завести хранилище. Ключевое свойство — не обязательность, а разница в поддержке: сойти с пути можно, но дальше команда несёт последствия сама. Синоним, встречающийся в русскоязычной практике, — paved road.

Категория C — «типовой путь (golden path)» при первом упоминании, дальше golden path. См. Golden Paths, Platform as a Product. Источник: Spotify Engineering — How We Use Golden Paths to Solve Fragmentation in Our Software Ecosystem (2020).

GitOps

Pull-based reconciliation модель: git как единый источник истины desired state, controller в кластере (Argo CD / Flux) непрерывно сводит actual state с git. Отличается от push-based CI-applying. Click-ops в проде с этой моделью несовместим.

Категория A. См. GitOps. Источник: OpenGitOps Principles (CNCF).

Goodhart’s law

Закон Гудхарта: когда мера становится целью, она перестаёт быть хорошей мерой. Пока по показателю принимают решения о системе, людям выгодно, чтобы он показывал правду. Когда от него начинает зависеть оценка самих людей, выгодной становится цифра, и её улучшают в обход того, что она измеряла. Назван по имени экономиста Чарльза Гудхарта, который заметил это на инструментах денежно-кредитного контроля; расхожая формулировка взята из статьи антрополога Marilyn Strathern об аудите британских университетов.

Категория B — «закон Гудхарта». См. SLO Engineering, SLO / Budget Review, DORA Metrics, Test Strategy. Источник: Marilyn Strathern, «Improving ratings»: audit in the British University system (European Review, 1997).

graceful degradation

Плавная деградация: при отказе зависимости или перегрузке сервис продолжает выполнять главную функцию и вместо ошибки отдаёт урезанный ответ — устаревшие данные из кеша, заглушку или пустой блок. Работает только тогда, когда заранее решено, чем жертвуют в первую очередь.

Категория C — «плавная деградация (graceful degradation)» при первом упоминании, дальше «деградация». См. Resilience Patterns, Vendor Reliability. Источник: AWS Well-Architected, REL05-BP01.

H

histogram

Тип метрики, который хранит распределение наблюдений по интервалам (бакетам), а не одно число. Перцентиль по гистограмме считается на стороне запроса: за любое окно и по любому набору реплик. Этим она отличается от summary, где квантили посчитаны заранее и между репликами не складываются.

Категория C — «гистограмма (histogram)» при первом упоминании, дальше «гистограмма». См. Metrics. Источник: Prometheus — Histograms and summaries.

I

IAM

Identity and Access Management — централизованная система управления тем, кто (human или service) есть в системе и что им разрешено. Включает authentication (login + MFA / federation) и authorization (RBAC / ABAC / ReBAC). У cloud-провайдеров — нативная (AWS IAM, GCP IAM, Microsoft Entra ID); у workforce — обычно отдельный IdP (Okta, Entra ID, JumpCloud) поверх облачных IAM.

Категория A — пишется заглавными. См. Access Control & IAM, Secrets Management, Workload Identity.

IaC

Infrastructure as Code — production-инфраструктура (cloud resources, k8s манифесты, IAM, network) описана как версионируемый код и применяется через автоматизированный pipeline. Никакого click-ops в console облака.

Категория A. См. Infrastructure as Code. Источник: Kief Morris, Infrastructure as Code (O’Reilly, 2-е изд., 2020).

IC

Incident Commander — координатор инцидента. Не делает руками, а принимает решения и держит структуру: распределение ролей, sitrep cadence, decision log. После 2–4 часов передаёт роль (handoff), чтобы не терять качество решений из-за fatigue.

Категория A — допустим перевод «руководитель инцидента» при первом упоминании. См. Incident Response, War Room Patterns.

idempotency

Свойство операции, при котором повторный вызов даёт тот же результат, что и однократный. Пре-условие для retry-safe вызовов — без idempotency каждый retry потенциально создаёт side-effect (double-write, double-charge). Реализуется через idempotency keys, ETags, conditional writes, transaction outbox.

Категория A — устоявшийся англицизм; «идемпотентность» как транслитерация тоже допустима. См. Resilience Patterns.

implicit SLO

Уровень надёжности, который сервис фактически держал до сих пор и к которому привыкли его потребители. Работает как обещание независимо от того, что записано в SLO-документе и записано ли вообще: вокруг него построены чужие кеши, обработка ошибок и повторы. Заметное отклонение от него в любую сторону — изменение, о котором предупреждают заранее.

Категория C — «неявный SLO (implicit SLO)» при первом упоминании, дальше «неявный SLO». См. SLO Engineering. Источник: Niall Murphy, Implicit SLOs and their dangers (2024).

K

KEV

CISA Known Exploited Vulnerabilities — публичный каталог уязвимостей с подтверждённой active exploitation. Federal mandate для US agencies; индустрия следует как best practice — match KEV в стеке = patch вне обычной очереди triage.

Категория A. См. Vulnerability Management.

known error

Проблема, которую разобрали, но не устранили. Под термином живут два состояния: причина понятна и есть обходное решение, исправление в работе; либо исправлять решили не делать, потому что оно дороже жизни с проблемой. В реестре их стоит разводить по разным статусам, у каждого — дата пересмотра.

Категория C — «известная ошибка (known error)» при первом упоминании, дальше как удобнее. См. Problem Tracking. Термин из ITIL; открытый пересказ — Atlassian.

Kubernetes

Container orchestrator, выросший из Google Borg и переданный CNCF в 2015. Де-факто стандарт runtime для container workload’ов в 2026. Архитектурно — набор контроллеров поверх etcd: kube-apiserver / scheduler / controller-manager / kubelet. Core abstractions — Pod (unit scheduling), Service (stable endpoint), Deployment / StatefulSet (управление lifecycle). Доступен как managed-сервис у всех hyperscaler’ов (EKS / GKE / AKS / Yandex Managed Kubernetes).

Категория A — пишется без склонения, иногда как k8s (k + 8 букв + s). См. Containerization & Orchestration, GitOps, Cloud Providers.

L

label

Пара «имя — значение», которая делит метрику на временные ряды. Каждая уникальная комбинация значений меток даёт отдельный ряд, поэтому набор значений у метки конечный и известен заранее; идентификаторы пользователей и запросов в метки не кладут. Число рядов, которое получается в итоге, — кардинальность.

Категория C — «метка (label)» при первом упоминании, дальше «метка». См. Metrics, Telemetry Economics. Источник: Prometheus — Metric and label naming.

lead time for changes

Время от commit изменения в version control до deploy в production. Одна из трёх метрик пропускной способности в текущей модели DORA. Источник начала и конца интервала фиксируется в методике расчёта, чтобы изменения tooling не склеивали несопоставимые периоды.

Категория A. См. DORA Metrics, CI/CD.

least privilege

Принцип, по которому идентичность (человек или сервис) имеет минимальный необходимый набор прав — не больше. Снижает blast radius при компрометации. Реализуется через IAM/RBAC scoping и just-in-time elevation.

Категория B — «(принцип) наименьших привилегий». См. Secrets Management, Vulnerability Management.

M

maturity model

Шкала, по которой команда оценивает, насколько развита практика, и выбирает, чему учиться дальше. Уровень в ней — промежуточный результат; настоящий итог оценки — список следующих шагов. Общепринятой модели зрелости SRE нет: публичные модели совпадают в числе ступеней и расходятся в том, по какому признаку ступени выделены.

Категория C — «модель зрелости (maturity model)» при первом упоминании, дальше «модель зрелости». См. SRE Maturity Assessment. Источник: Martin Fowler, Maturity Model (2014).

mentoring

Регулярная парная связь, в которой более опытный инженер передаёт ученику контекст и навыки, не покрываемые формальным онбордингом и не сводимые к код-ревью. Отличается от коучинга (вопросы без позиции эксперта) и sponsorship (открытие возможностей через рекомендации и защиту) — разные социальные контракты, разные риски, разные эффекты на карьеру. Базовая дисциплина — менторский контракт в начале связи и явное условие выхода.

Категория A — устоявшийся англицизм. См. Mentoring as Practice, Communities of Practice, SRE Onboarding.

metastable failure

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

Категория C — «метастабильный отказ (metastable failure)» при первом упоминании, дальше «метастабильный отказ». См. Resilience Patterns. Источник: Bronson et al., Metastable Failures in Distributed Systems (HotOS ’21).

MFA

Multi-Factor Authentication — требование двух или более независимых факторов для login (что-то, что знаешь / имеешь / есть ты сам). Не равноценны: SMS phish’ится через SIM swap, TOTP — через relay-фишинг, FIDO2/WebAuthn (hardware keys, passkeys) — cryptographic binding на domain делает их phishing-resistant. Для admin/production access baseline — FIDO2; для low-risk — TOTP.

Категория A — пишется заглавными. См. Access Control & IAM. Источник: NIST SP 800-63B.

mTLS

Mutual TLS — TLS с двусторонней аутентификацией: и client, и server предъявляют сертификаты. Используется для service-to-service authentication вместо shared secrets / bearer tokens; в service mesh (Istio, Linkerd) — by default. Certificate provisioning обычно через workload identity (SPIFFE SVID или mesh-native).

Категория A — пишется без склонения. См. Workload Identity, Networking, Service Mesh.

MTBF / MTTF

Mean Time Between Failures — среднее время между двумя отказами восстанавливаемой системы (время работы / число отказов); Mean Time To Failure — то же для невосстанавливаемой, где отказ один и терминальный. Пара к MTTR: MTTR отвечает «как быстро поднимаемся», MTBF — «как часто падаем», и поодиночке обе метрики врут. Низкий MTTR при низком MTBF — встаём быстро, но падаем слишком часто, и пользователю от скорости восстановления не легче; высокий MTBF при высоком MTTR — падаем редко, но болит долго. Рост MTTR при стабильном MTBF читается как деградация on-call и эскалаций; падение MTBF при стабильном MTTR — как деградация качества релизов. Из формулы стационарной доступности A = MTTF / (MTTF + MTTR) следуют два пути: наращивать время до отказа (дорого, упирается в надёжность компонентов) или снижать время восстановления (автоматизация) — в облачных средах второй почти всегда дешевле. Сам MTTF пришёл из hardware-надёжности и к распределённому сервису применяется натянуто: у него нет одного терминального отказа, он постоянно живёт в частичной деградации.

Категория A — пишутся заглавными. См. DORA Metrics, SLO Engineering, Incident Response. Источник: разбор пары MTTR / MTBF в канале автора.

MTTD / MTTA

Mean Time To Detect — время от начала отказа до момента, когда о нём узнали; Mean Time To Acknowledge — время от сигнала до момента, когда инцидент взяли в работу. Первые два отрезка времени инцидента, за ними идут гашение и устранение причины. Если отсчёт идёт от алерта, а не от отказа, MTTD по определению равен нулю и из отчёта пропадает.

Категория A — пишутся заглавными. См. MTTR Optimization, On-Call Rotation. Пара к MTTR.

MTTR

Mean Time To Repair / Resolve / Recovery — семейство метрик, точное начало и окончание которых зависят от принятого определения. DORA использовала MTTR в ранней модели, но в 2023 году заменила его на failed deployment recovery time: время восстановления именно после неудачного deploy, требующего немедленного вмешательства. Общий MTTR инцидентов больше не следует называть DORA-метрикой.

Категория A. См. DORA Metrics, Incident Response, Runbooks, MTTR Optimization. Источник: DORA — история метрик.

N

near miss

Событие, которое могло стать инцидентом и не стало: отказ остановила случайность или последняя линия защиты. Под формальные критерии инцидента не попадает, потому что ущерба нет, а пробел в защите показывает тот же. Разбирать его дешевле настоящего инцидента; в документе постмортема для таких находок есть раздел «Где нам повезло».

Категория D — устоявшегося перевода нет, кандидаты «несостоявшийся инцидент» и «почти-инцидент» не закрепились; пишется латиницей, смысл раскрывается в предложении. См. Blameless Postmortem.

O

observability

Способность отвечать на вопросы о внутреннем состоянии системы через её внешние сигналы (метрики, логи, трейсы). Не «monitoring наоборот», а способность задавать новые вопросы без перевыпуска.

Категория A. См. SLI-based Alerting, Resilience Patterns. Источник: Sridharan, Distributed Systems Observability (O’Reilly, 2018).

OIDC

OpenID Connect — identity layer поверх OAuth 2.0; современный стандарт для federated authentication. В SRE-контексте чаще встречается как OIDC federation: workload (CI runner, k8s pod) предъявляет signed JWT от своего issuer’а (GitHub, GitLab, k8s API server), cloud провайдер (AWS STS, GCP STS) принимает токен и выдаёт ephemeral credentials — без long-lived API key в repository secrets или environment.

Категория A — пишется заглавными. См. Workload Identity, CI/CD, Access Control & IAM. Источник: OIDC Core 1.0.

operator pattern

Kubernetes controller с custom CRD, который управляет complex / stateful workload (DB primary/replica failover, certificate rotation, Kafka cluster). Декларативный API: kubectl apply — остальное operator делает сам (provision / failover / backup / restore / upgrade). Cost: разработка — самостоятельный Go-проект с k8s API expertise, controller-runtime; maintenance — следить за k8s API deprecations. Готовые operators (postgres-operator, cert-manager, external-secrets) покрывают 80% потребностей.

Категория A — пишется без склонения. См. Toil Automation. Источник: CoreOS / Red Hat blog (2016); Operator Capability Levels.

on-call

Дежурство — режим работы, в котором инженер отвечает за реагирование на алерты в нерабочее время (или в смену). Sustainable on-call требует явной компенсации, alert hygiene, runbook на каждый pager.

Категория A — пишется латиницей без склонения. См. On-Call Rotation.

one-on-one

Регулярная (раз в 1–2 недели) встреча engineer’а с manager или tech lead. Не status update — пространство для того, что не покрыто другими ритуалами: личные блокеры, обратная связь, growth conversations, отношения. Andy Grove формализовал в 1983: 1:1 — это встреча сотрудника, не manager’а.

Категория A (термин «1:1» используется без склонения). См. One-on-Ones. Источник: Andy Grove, High Output Management (1983).

OODA

Observe, Orient, Decide, Act — наблюдение, ориентация, решение, действие. Петля принятия решений в неопределённости, которую описал военный лётчик и стратег John Boyd. Главная в ней ориентация: она определяет, что наблюдающий заметит, что решит и что сделает. В инциденте петлёй удобно мерить один синк: общая картина, гипотеза, действие, проверка.

Категория A — пишется заглавными; по-русски «петля OODA» или «петля Бойда». См. Incident Response. Источник: John Boyd, The Essence of Winning and Losing (1995).

OWASP Top 10

Список самых критичных классов уязвимостей веб-приложений от OWASP, обновляется раз в несколько лет. Актуальная редакция — 2025 (первая с 2021 года); №1 по-прежнему broken access control, а среди новых категорий — сбои цепочки поставок ПО. Не чеклист, а словарь классов, на которые смотрят в security-ревью и threat modeling.

Категория A. См. Security Code Review, Threat Modeling.

P

platform engineering

Дисциплина построения внутренней технической платформы для команд-разработчиков: набор возможностей, собранный под нужды пользователей и поданный как внутренний продукт с владельцем, roadmap и обратной связью. Платформа не равна порталу и не равна команде эксплуатации; портал — один из возможных интерфейсов.

Категория A. См. Platform as a Product, Team Topologies. Источники: Evan Bottcher — What I Talk About When I Talk About Platforms (2018), CNCF Platforms White Paper.

playbook

Сценарий реагирования для класса инцидентов: роли (IC / Deputy / Scribe / SME), первые действия, decision points, escalation criteria, comms cadence. Не путать с runbook: runbook = «что делать» для одного симптома; playbook = «что решать и кого звать» для класса инцидентов. Google SRE Workbook использует термины как синонимы; incident-response сообщество после PagerDuty / incident.io в 2020-х закрепило различение.

Категория A. См. Playbooks, Runbooks, Incident Response.

postmortem

Документ, фиксирующий разбор инцидента после его завершения: timeline, contributing factors, action items с владельцем и дедлайном, lessons learned. В SRE-практике норма — blameless постмортем. Тот же ритуал встречается под именами post-incident review (PIR), incident review и learning review.

Категория A как документ; «провести разбор» допустим как процесс. См. Postmortem Culture, Blameless Postmortem, Postmortem Database. Источник: Beyer et al., SRE Book, гл. 15.

principle of least privilege

См. least privilege.

problem

Причина или условие, общее для нескольких инцидентов. Инцидент — то, что сломалось сейчас; проблема — то, из-за чего оно продолжает ломаться. У записи о проблеме свой владелец и свой жизненный цикл, а закрывают её, когда инциденты перестали приходить: выкаченного исправления для этого мало.

Категория B — «проблема». См. Problem Tracking. Термин из ITIL.

PRR

Production Readiness Review — проверка сервиса на рубеже: перед первым выходом в прод, перед передачей под чужое дежурство или после существенной перестройки. Итог — список пробелов, решение по каждому и исключения с владельцем и сроком, а не заполненный чек-лист. У AWS тот же инструмент называется ORR, Operational Readiness Review.

Категория A — пишется заглавными; полное название при первом упоминании. См. Production Readiness Review, Change Governance. Источник: Beyer et al., SRE Book, гл. 32. Заготовка — templates/production-readiness-review.md.

Q

quality SLI

Индикатор, который считает долю ответов, отданных без деградации. Нужен сервису, умеющему отвечать урезанно: такой ответ уходит с кодом успеха и по SLI доступности считается хорошим. Видит только ту деградацию, о которой сервис сообщил сам.

Категория C — «индикатор качества ответа (quality SLI)» при первом упоминании, дальше quality SLI. См. SLO Engineering. Источник: Beyer et al., SRE Workbook, гл. 2, табл. 2-1.

R

RBAC

Role-Based Access Control — модель авторизации, в которой permissions присваиваются ролям, а пользователи получают роли. Простая, audit-friendly, хорошо работает на 5–20 ролях. При scale страдает role explosion (роль на каждую комбинацию permissions) — тогда сдвиг в сторону ABAC или ReBAC (Zanzibar-style relationship model).

Категория A — пишется заглавными. См. Access Control & IAM, Secrets Management.

RED method

Метод первого прохода для сервиса: Rate (rps), Errors (доля сбоев), Duration (распределение latency, обычно через гистограмму с percentile’ями). Application-уровневый аналог USE; вместе с Four Golden Signals формирует базовый набор сервисных метрик. Предложен Tom Wilkie (Weaveworks).

Категория A. См. Systematic Troubleshooting, SLI-based Alerting. Источник: Tom Wilkie, The RED Method (Weaveworks, 2018).

retry budget

Бюджет повторов: ограничение на число или долю повторных запросов. Задержка и разброс разносят повторы во времени, бюджет ограничивает их объём, и при массовых отказах повторы прекращаются сами. В SRE Book описаны два уровня: не больше трёх попыток на запрос и не больше 10% повторов в потоке клиента.

Категория C — «бюджет повторов (retry budget)» при первом упоминании, дальше «бюджет повторов». См. Resilience Patterns, Capacity Planning. Источник: Beyer et al., SRE Book, гл. 21.

RPO / RTO

Recovery Point Objective (сколько данных потерять допустимо) и Recovery Time Objective (сколько времени на восстановление). Фиксируются в SLO-документе сервиса; пересматриваются вместе с SLO.

Категория A. См. Backup & Restore.

runbook

Конкретные инструкции по реагированию на инцидент: симптом → шаги диагностики → mitigation → rollback → escalation. Каждый шаг — actionable команда или явное решение, не «понять и подумать». Алерт без runbook — фоновый шум.

Категория A — пишется латиницей без склонения (если нужно — через апостроф: runbook'ом). См. Runbooks.

S

structured logging

Запись лога как набора именованных полей, а не строки текста: событие названо один раз, контекст лежит в отдельных полях. По такой записи ищут и считают без регулярных выражений. Формат вторичен, первичен набор полей и стабильность их имён.

Категория C — «структурированные логи (structured logging)» при первом упоминании, дальше «структурированные логи». См. Logging. Источник: OpenTelemetry, Logs Data Model.

SAST

Static Application Security Testing — анализ исходного кода на security-дефекты без запуска (pattern-matching + semantic). Ловит SQL-инъекции, слабый crypto, захардкоженные секреты; не видит логику авторизации (broken access control). Инструменты — Semgrep, CodeQL, gosec, Bandit.

Категория A. См. Security Code Review, Vulnerability Management.

SBOM

Software Bill of Materials — список всех dependencies артефакта со связями (transitive deps, версии, hashes). Форматы: SPDX (ISO standard) или CycloneDX (OWASP). Foundation для vulnerability management — нельзя патчить то, чего не знаешь, что есть.

Категория A. См. Supply Chain Security, Vulnerability Management.

SCA

Software Composition Analysis — анализ сторонних dependencies артефакта на known CVE; опирается на SBOM. Отличается от SAST объектом: SAST смотрит свой код, SCA — чужой. Инструменты — govulncheck, Snyk, Dependabot, Trivy.

Категория A. См. Vulnerability Management, Security Code Review, Supply Chain Security.

sampling

Выбор подмножества telemetry для обработки или хранения. Head sampling принимает решение в начале trace и не видит его целиком; tail sampling учитывает завершённый или почти завершённый trace, но требует state и сложнее масштабируется.

Категория A — «сэмплирование (sampling)» при первом упоминании. См. Telemetry Economics. Источник: OpenTelemetry — Sampling.

service mesh

Инфраструктурный слой для service-to-service коммуникации, реализованный через sidecar-прокси (обычно Envoy) рядом с каждым pod’ом + control plane (Istio / Linkerd / Consul Connect). Даёт три функции из коробки: mTLS, traffic management (routing, retry, timeout), L7-observability (RED-метрики, distributed tracing). Альтернатива sidecar — per-node proxy через eBPF (Cilium Service Mesh, Istio Ambient).

Категория A — пишется без склонения. См. Service Mesh, Networking.

severity

Классификация серьёзности инцидента — SEV0..SEV3 (или эквивалент). Выводится из impact × scope; определяет response intensity, audience для customer comms, требования к постмортему. Severity не статична: upgrade/downgrade в ходе инцидента — нормально.

Категория A. См. Severity Classification.

shared responsibility model

Модель распределения ответственности между cloud-провайдером и клиентом для каждого сервиса. Провайдер отвечает за «security/availability of the cloud» (физическая инфра, hypervisor, control plane managed-сервисов); клиент — за «security/availability in the cloud» (конфигурация, IAM, данные, workload-level reliability). Граница смещается между IaaS / PaaS / SaaS — у managed-Kubernetes провайдер берёт control plane, клиент остаётся с worker nodes и workload’ами. Public-документация: AWS / Azure / GCP / Yandex Cloud — у каждого своя версия матрицы.

Категория B — «модель shared responsibility». См. Cloud Providers, DR Policy & Stakeholders.

single source of truth

Архитектурный принцип: данные хранятся в одном месте, все остальные представления выводятся из него или ссылаются на него. Антипод — расползание по wiki / spreadsheet / устным договорённостям.

Категория B — «единый источник истины». См. Service Ownership, GitOps.

sitrep

Sitrep (situation report) — формализованная сводка статуса инцидента, выпускаемая по cadence (каждые 15 мин для SEV0, 30 мин для SEV1). Структура: current status / what we tried / what we're doing now / next step / blockers / next sitrep at HH:MM.

Категория C — «сводка обстановки (sitrep)» при первом упоминании. См. War Room Patterns, Customer Communications.

SLA / SLO / SLI

SLI (Service Level Indicator) — измеряемая метрика, чаще всего отношение good events / valid events. SLO (Objective) — целевое значение SLI на окне (например, 99.9% за 28 дней). SLA (Agreement) — контрактное обязательство с consequences при нарушении (compensation, refund). Сколько простоя стоит за каждой девяткой — таблица в листе SLO Engineering.

Категория A — все три заглавными. См. SLO Engineering, SLI-based Alerting. Источник: Beyer et al., SRE Book, гл. 4.

SLSA

Supply-chain Levels for Software Artifacts (OpenSSF). В актуальной спецификации v1.2 требования разделены на Build и Source tracks. Build track содержит L0–L3: отсутствие гарантий, наличие provenance, hosted build platform с подписанным provenance и hardened build platform. Старая единая шкала SLSA 1–4 относится к версии до 1.0.

Категория A. См. Supply Chain Security. Источник: SLSA specification v1.2.

SOC 2

Service Organization Control 2 — фреймворк сертификации (AICPA) для SaaS-вендоров, доказывающий клиентам, что у вендора есть operating controls по Trust Services Criteria (Security обязательно, остальные четыре — Availability / Processing Integrity / Confidentiality / Privacy — опционально). Type I — control design в момент аудита; Type II — operational effectiveness за период 6–12 месяцев. В B2B SaaS — типичное требование для prospect customers.

Категория A — пишется через пробел. См. Compliance Frameworks. Источник: AICPA Trust Services Criteria.

SPIFFE / SPIRE

SPIFFE (Secure Production Identity Framework For Everyone) — CNCF-стандарт workload identity: формат ID (spiffe://trust-domain/path), SVID (Verifiable Identity Document — X.509 или JWT), attestation framework. SPIRE — reference implementation: SPIRE server выпускает SVIDs, SPIRE agent на ноде проводит attestation workload’ов. Используется в команд с multi-cloud / hybrid scenarios; в одном cloud чаще используют cloud-native альтернативу (IRSA, GCP Workload Identity).

Категория A — пишется заглавными. См. Workload Identity. Источник: SPIFFE Specification.

SRE

Site Reliability Engineering. Дисциплина, родившаяся в Google и сформулированная в SRE Book (Beyer et al., 2016). Главное отличие от классической ops-модели — SRE пишет код и разделяет error budget с продуктовой командой.

Категория A. См. Мотивацию, Методологию.

STRIDE

Threat modeling framework (Microsoft): Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege. Применяется per element of DFD (data flow diagram).

Категория A. См. Threat Modeling. Источник: Shostack, Threat Modeling: Designing for Security (Wiley, 2014).

T

Team Topologies

Диагностическая рамка Matthew Skelton и Manuel Pais: четыре фундаментальных типа команд (stream-aligned, platform, enabling, complicated-subsystem) и три режима взаимодействия (collaboration, X-as-a-Service, facilitating). Применяется в SRE-контексте для сознательного дизайна SRE-функции на уровне org: embedded → enabling → platform — не альтернативы, а разные interaction modes под разные стадии зрелости. Во втором издании platform team уточнена как platform grouping — не одна команда, а фрактальная группировка команд разных типов.

Категория A — пишется без склонения. См. Team Topologies, Platform as a Product. Источник: Skelton & Pais, Team Topologies (IT Revolution, 1-е изд. 2019, 2-е изд. 2025).

threat model

Документ, фиксирующий результат threat modeling: DFD с trust boundaries → identified threats per STRIDE category → mitigations с явным статусом (implemented / planned / accepted). Living document, не «artifact для аудита».

Категория C — «модель угроз (threat model)» при первом упоминании. См. Threat Modeling.

time to market

Время от идеи до момента, когда результат дошёл до клиента. Шире lead time for changes из модели DORA: тот считает только участок от commit до deploy в production, а разбор идеи, приоритизация и дизайн в него не входят. Где теряется время на всём пути, показывает карта потока ценности.

Категория A — латиницей без склонения, сокращение TTM. См. DORA Metrics. Источники: DORA, определение change lead time и Visibility of work in the value stream.

timeline

Хронология событий и решений в инциденте, собранная по timestamp из логов, алертов, Slack-тредов. Главная дисциплина — отделить факты от интерпретаций. «X не справился» — уже интерпретация; «X вернул 503 в 14:23» — факт.

Категория C — «хронология (timeline)» при первом упоминании, дальше можно «timeline». См. Postmortem Culture, Incident Response.

toil

Операционная работа, которая manual, repetitive, automatable, tactical, devoid of enduring value, scales linearly with service growth. Все пять критериев должны выполняться — иначе это не toil, а просто «не любимая работа». Google SRE convention — ≤ 50% времени per engineer.

Категория A. См. Toil Tracking. Источник: Vivek Rau, SRE Book, гл. 5.

tool sprawl

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

Категория D — устоявшегося перевода нет, разговорное «зоопарк инструментов» в тексте не закрепилось; пишется латиницей, смысл раскрывается в предложении. См. Incident Response.

trace / span

Трейс — запись пути одного запроса через систему; спан — одна операция на этом пути с началом, концом, именем и атрибутами. Спаны знают своего родителя и складываются в дерево. Трейс отвечает на вопрос, где запрос потерял время или сломался, и не отвечает на вопрос, сколько таких запросов.

Категория C — «трейс (trace)» и «спан (span)» при первом упоминании, дальше кириллицей. См. Distributed Tracing, Telemetry Economics. Источник: OpenTelemetry, Traces.

trust boundary

Граница, при пересечении которой меняется уровень доверия (network zone, deployment unit, role). На threat model рисуются явно — потому что именно на boundary threats умножаются.

Категория B — «граница доверия». См. Threat Modeling.

U

USE method

Метод первого прохода для ресурсов: для каждого ресурса (CPU, memory, disk, network) проверить три показателя — Utilization (% времени, проведённого в обработке), Saturation (степень очереди / wait time), Errors (drop, retransmit, EIO). Brendan Gregg’s формулировка: «решает 80% проблем server’а 5% усилий». Аналог RED на уровне ресурса; вместе с Four Golden Signals — стандартный набор для systematic troubleshooting.

Категория A. См. Systematic Troubleshooting, Performance & Profiling. Источник: Brendan Gregg, The USE Method (brendangregg.com).

V

value stream

Путь работы от идеи до результата у клиента: все этапы и передачи между ними, от бизнеса и дизайна до эксплуатации и поддержки. Карта потока ценности (value stream mapping) режет этот путь на 5–15 блоков и для каждого записывает lead time, чистое время обработки и долю работы, которую следующий блок принимает без переделки. По карте ищут узкое место: ускорение вне его почти не сокращает общий lead time.

Категория C — «поток ценности (value stream)» при первом упоминании, дальше «поток ценности». См. DORA Metrics. Источник: DORA, Visibility of work in the value stream.

vulnerability management

Дисциплина обнаружения, классификации и устранения software vulnerabilities в собственных артефактах и dependencies. Не CVE-checklist, а измеримый процесс: discovery (SCA / SAST / DAST / pen test / bug bounty) → triage (CVSS + EPSS + asset context) → remediation (patch SLA per severity) → verification.

Категория A (как фраза процесса). См. Vulnerability Management.

W

war room

Канал координации high-severity инцидента, в котором собраны IC / Ops / Comms / Scribe / SME. С 1970-х годов разрабатывается как practice в crisis management (FEMA ICS). Без структуры war room — амплификатор хаоса; со структурой — единственный способ держать координацию при многочасовом инциденте.

Категория C — «оперативный штаб (war room)» при первом упоминании, дальше «war room». См. War Room Patterns.

workaround

Временное решение, которое снижает влияние проблемы или не даёт ей дойти до инцидента, пока нет постоянного исправления. Обходное решение, которое дежурный выполняет руками каждую неделю, — это уже toil с известным источником.

Категория C — «обходное решение (workaround)» при первом упоминании, дальше «обходное решение». См. Problem Tracking.

---

Источник истины

Этот глоссарий — публичный артефакт. Рабочие правила того, как переводить термины и какие графические нормы применять, живут в inventory/terminology.md репозитория (внутренний документ контрибутора). Если в глоссарии и в terminology.md обнаружится расхождение — глоссарий ближе к читателю, исправляется в обе стороны через PR.

Глоссарий пополняется по мере роста проекта. Список того, что ещё не добавлено и стоит в очереди: MITRE ATT&CK, PASTA, OCTAVE, LINDDUN, VAST, Sigstore, ReBAC / Zanzibar, JIT access, PAM, FIDO2 / WebAuthn, ISO 27001, PCI-DSS, HIPAA, GDPR, FedRAMP, Hubot, Taskfile, Backstage, backpressure, load shedding, health gate, blue-green deployment, dark launch, shadow traffic, pull-based / push-based модели, dashboard, pipeline, stakeholder, escalation path, outage, wheel of misfortune, tabletop exercise, game day, engagement contract, embedded SRE / consulting SRE / platform SRE, policy as code, OPA. PR с добавлениями приветствуется.