Глоссарий

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

В каждой записи указана категория по принципу из 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.

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’.

burn rate

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

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

C

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).

change failure rate

Доля изменений в production, которые приводят к degraded service: rollback, hotfix или customer-facing incident. Одна из четырёх DORA-метрик. Считается из связи deploy ↔ incident; требует явного определения «failure» на команду, чтобы цифры разных команд были сопоставимы.

Категория 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.

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, 2019).

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.

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.

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

Как часто команда успешно выкатывает изменения в production. Одна из четырёх DORA-метрик. Считается из CI/CD-логов: число успешных prod-deploys за период. Главная ловушка — vanity-улучшение через дробление коммитов на микро-изменения без бизнес-смысла; читается только в связке с change failure rate.

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

DORA

DevOps Research and Assessment — исследование (Forsgren / Humble / Kim), которое выделяет 4 ключевые метрики: deployment frequency, lead time for changes, change failure rate, MTTR. Используются вместе; оптимизация одной метрики за счёт другой — Goodhart’s law.

Категория A. См. DORA Metrics. Источник: Forsgren et al., Accelerate (IT Revolution, 2018).

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.

F

feature flag

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

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

G

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).

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.

K

KEV

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

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

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

lead time for changes

Время от первого коммита изменения до его выкатки в production. Одна из четырёх DORA-метрик. Считается из git-истории: prod-deploy timestamp − first commit timestamp. Растущий lead time чаще всего указывает на heavy approval gates (change governance) или медленный pipeline; короткий lead time при низкой deployment frequency — сигнал, что блокирует release decision, а не pipeline.

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

least privilege

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

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

M

mentoring

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

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

MFA

Multi-Factor Authentication — требование двух или более независимых факторов для login (что-то, что знаешь / имеешь / есть ты сам). Не равноценны: SMS phish’ится через SIM swap, TOTP — через relay-фишинг, FIDO2/WebAuthn (hardware keys, passkeys) — cryptographic binding на domain делает их phishing-resistant. Для admin/production access баseline — 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. Sertificate provisioning обычно через workload identity (SPIFFE SVID или mesh-native).

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

MTTR

Mean Time To Repair / Resolve / Recovery (зависит от источника). Среднее время от обнаружения инцидента до восстановления сервиса. Одна из четырёх DORA-метрик. Как KPI с премией — путь к манипуляции (инциденты закрываются как resolved до реальной mitigation); как индикатор тренда — полезен.

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

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).

OWASP Top 10

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

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

P

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 постмортем.

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

principle of least privilege

См. least privilege.

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.

RPO / RTO

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

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

runbook

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

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

S

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.

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).

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

SLSA

Supply-chain Levels for Software Artifacts (OpenSSF). Фреймворк уровней зрелости supply chain security: Level 1 (provenance), Level 2 (hosted build), Level 3 (non-forgeable provenance), Level 4 (hermetic + two-party review).

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

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 (2019): четыре фундаментальных типа команд (stream-aligned, platform, enabling, complicated-subsystem) и три режима взаимодействия (collaboration, X-as-a-Service, facilitating). Применяется в SRE-контексте для сознательного дизайна SRE-функции на уровне org: embedded → enabling → platform — не альтернативы, а разные interaction modes под разные стадии зрелости.

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

threat model

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

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

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.

trust boundary

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

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

V

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.

---

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

Этот глоссарий — публичный артефакт. Рабочие правила того, как переводить термины и какие графические нормы применять, живут в 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, paved road / golden path, platform engineering, Taskfile, Backstage, circuit breaker, bulkhead, backpressure, load shedding, graceful degradation, health gate, blue-green deployment, dark launch, shadow traffic, pull-based / push-based модели, dashboard, pipeline, stakeholder, escalation path, outage, near miss, wheel of misfortune, tabletop exercise, game day, production readiness review (PRR), engagement contract, embedded SRE / consulting SRE / platform SRE, error budget policy, policy as code, OPA. PR с добавлениями приветствуется.