Термины и определения

Индексы и производные метрики

FS

Fragility — индекс хрупкости системы: насколько сильно она ломается и каков масштаб последствий с учётом итоговой тяжести последствий (FS_impact). §2.6–2.7.

FS_base

Базовая хрупкость по факторам F1–F4. §2.6.1.

FS_impact

Итоговая тяжесть последствий сбоя (в формулах — FS_impact): объединяет TI и BI. §2.6.4.

TI

Technical Impact (тяжесть технических последствий сбоя): как система ломается по шкалам C, BR, RC. §2.6.2.

BI

Business Impact (тяжесть бизнес-последствий); в методологии BI = L. §2.6.3.

MS

Manageability — индекс управляемости системы. §3.

AS

Antifragility — индекс антихрупкости (обучение и усиление после стрессов). §4.

RS

Resilience — индекс устойчивости (сохранение функции и восстановление при стрессе). §5.

SQI

System Quality Index — баланс управляемости и хрупкости: MS/FS. §6.1.

SEI

Systemic Evolution Index — индекс эволюционного развития: AS×MS/FS (эквивалентно AS×SQI). §6.2.

EX

Exposure — подверженность (риску / потерям); произведение FS на L. §2.8.

GM

Governance Multiplier — коэффициент (1.0 или 1.5), учитывающий наличие «шкуры на кону» у CEO/CFO. §2.9.

EX_adjusted

Реальная подверженность (риску / потерям) с учётом Governance Multiplier (GM). Формула: EX × GM. §2.9.

Факторы хрупкости и последствий (оценка 1–5)

F1

Концентрация / SPOF — единые точки отказа. §2.3.

F2

Прозрачность зависимостей. §2.3.

F3

Связанность (Coupling). §2.3.

F4

Архитектурная восстанавливаемость (в т.ч. self-healing). §2.3.

C

Cascade — каскадный эффект (распространение сбоя). §2.4.1.

BR

Blast Radius — радиус поражения (масштаб затронутых функций/систем). Не путать с факторами R1–R5 устойчивости и с RS. §2.4.2.

RC

Recovery Cost — стоимость восстановления (ресурсы, время, риски). §2.5.1.

L

Loss — стоимость потерь / простоя для бизнеса. §2.5.2.

Факторы управляемости M1–M5

M1

Наблюдаемость (метрики, логи, трейсы, алерты). §3.2.

M2

Контроль (feature flags, admin API, runtime-конфигурация и т.п.). §3.2.

M3

Ответственность (владельцы, зоны). §3.2.

M4

Обратная связь о результатах изменений. §3.2.

M5

Изменяемость (CI/CD, тесты, откаты). §3.2.

Факторы антихрупкости A1–A5

A1

Постмортемы → конкретные изменения. §4.2.

A2

Тесты после инцидентов. §4.2.

A3

Эксперименты (Chaos Engineering, GameDays). §4.2.

A4

Data-driven решения по данным инцидентов. §4.2.

A5

Устранение классов проблем, а не точечных багов. §4.2.

Факторы устойчивости R1–R5

R1

Запас и избыточность. §5.2.

R2

Контролируемая деградация (fallback, circuit breaker, ограничение blast radius). §5.2.

R3

Восстановление и DR, RTO/RPO, backup/restore, учения. §5.2.

R4

Инцидентная готовность (runbooks, алерты, SLO/SLI как триггеры). §5.2.

R5

Организационная устойчивость (on-call, эскалации). §5.2.

Режимы оценки и контекст

RS_full

Полная оценка по R1–R5 с обоснованиями (критичные системы, Due Diligence). §5.5.

RS_quick

Укороченный чек-лист §8.4 с переводом ответов в ориентир RS. §5.5, §8.4.

Tier 0 / 1 / 2

Уровни критичности системы для бизнеса (в примерах и рекомендациях по режиму оценки). §5.5, часть 9.

Профиль системы

Совокупность индексов FS, MS, RS, AS (и при необходимости детализация по факторам); не сводится к одному ярлыку. §1.1–1.2.

Категории итоговой диагностики (§7.3)

Отраслевые и общие термины (кратко)

TODOIT: System Exposure

Название методологии (на английском — Framework), описывающей процесс диагностики фундаментальных изъянов архитектуры систем и оценки их подверженности риску (Exposure) с точки зрения масштабов бизнес-последствий.

CC BY‑NC‑ND 4.0

Лицензия Creative Commons 4.0: BY (Attribution) — требуется указание авторства (TODOIT); NC (Non-Commercial) — запрещено коммерческое использование; ND (No Derivatives) — запрещено создание производных работ (изменение, адаптация).

Методика

Совокупность конкретных методов, приёмов и алгоритмов, описывающая последовательность действий для выполнения определённой работы и достижения предсказуемого результата. Отвечает на вопрос «Как делать?»

Методология

Учение о методах, принципах и способах организации деятельности. Это система взглядов, теоретическая база и логика, которая определяет, какие методики выбирать и почему они работают. Отвечает на вопросы «Почему мы делаем именно так?» и «На чём основан подход?»

IT Strategy

ИТ-стратегия — долгосрочный план развития технологий в компании, который отвечает на один главный вопрос: «Как ИТ поможет бизнесу заработать больше денег или сэкономить их?». Это не просто список серверов и программ, которые нужно купить, а связующее звено между целями бизнеса и возможностями ИТ-отдела.

Executive Diagnostic

Экспертная диагностика для руководителей — быстрый, высокоуровневый аудит ИТ-функции, проводимый опытным экспертом (CIO или Board Advisor) специально для собственников и топ-менеджмента. В отличие от классического глубокого аудита, который может длиться месяцы, Executive Diagnostic фокусируется на «болевых точках» бизнеса и даёт ответ на вопрос: «Насколько наше ИТ соответствует амбициям компании?»

Target Architecture

Целевая архитектура — детальный «образ будущего» ИТ-систем компании, к которому она хочет прийти через 2–3 года для реализации своей бизнес-стратегии. Если ИТ-стратегия — это направление (куда идём), то целевая архитектура — это чертёж здания, которое мы строим.

Architecture Review

Архитектурный надзор / аудит архитектуры — процесс критической оценки текущей или проектируемой ИТ-архитектуры на соответствие целям бизнеса и техническим стандартам. Если Target Architecture — это чертёж будущего здания, то Architecture Review — это проверка этого чертежа (или уже построенного здания) опытным архитектором на наличие ошибок, рисков и «костылей».

Cost of Failure Model

Модель стоимости отказа/неудачи — финансовый инструмент, который помогает рассчитать, во сколько компании обойдётся сбой в ИТ-системе, утечка данных или провал стратегического проекта.

Framework

Фреймворк — готовый «каркас» или структура, включающая набор правил, библиотек, компонентов и соглашений, который служит основой для создания конечного продукта, системы или процесса. Framework задаёт архитектуру, но требует наполнения конкретным содержанием.

SPOF

Single Point of Failure — единая точка отказа.

DR

Disaster Recovery — аварийное восстановление, планы и учения.

IT Resilience

ИТ-устойчивость — способность ИТ и критичных цифровых сервисов поддерживать непрерывность бизнеса и восстанавливаться после сбоев: Business Continuity, Disaster Recovery и киберустойчивость для минимизации ущерба.

Business Continuity

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

Disaster Recovery

Аварийное восстановление — технические регламенты и меры, позволяющие быстро вернуть системы в строй после инцидентов (хакерская атака, пожар, авария): backup/restore, резервирование, переключение, целевые RTO/RPO и регулярные учения.

Skin in the Game

Принцип, при котором лица, принимающие решения, несут личные последствия своих решений (в контексте TODOIT — наличие KPI по надёжности у CEO/CFO).

Киберустойчивость (Cyber resilience)

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

DRP

DRP (Disaster Recovery Plan) — детальный план аварийного восстановления ИТ-инфраструктуры, данных и бизнес-процессов после катастроф или сбоев. Его цель — минимизировать простой (RTO) и потерю данных (RPO), обеспечивая непрерывность бизнеса.

BCP

BCP (Business Continuity Plan) — план обеспечения непрерывности бизнеса: сценарии, роли и действия, чтобы критичные процессы продолжали работать при сбоях и кризисах (в т.ч. в связке с DR/DRP для ИТ-восстановления).

RTO / RPO

Recovery Time Objective / Recovery Point Objective — целевые время и точка восстановления.

ИБ

ИБ (информационная безопасность) — защита информации и ИТ-систем от несанкционированного доступа, утечек и нарушений целостности/доступности; включает процессы, меры и контроль рисков.

КИИ

КИИ (критическая информационная инфраструктура) — информационные системы и сети, значимые для устойчивости/безопасности государства и экономики; к ним обычно предъявляются повышенные требования по защите и устойчивости.

ROI

ROI (Return on Investment) — показатель окупаемости инвестиций: отношение полученного эффекта (выгоды) к вложенным затратам, обычно в процентах.

CIO

CIO (Chief Information Officer) — ИТ-директор: отвечает за стратегию и управление ИТ-функцией, ландшафтом систем, бюджетом, рисками и ценностью ИТ для бизнеса.

Board Advisor

Советник совета директоров — помогает совету директоров (Board of Directors) понимать риски и возможности цифровизации. Участвует в принятии стратегических решений: стоит ли покупать технологическую компанию, внедрять ИИ или менять основную ИТ-систему. Оценивает эффективность текущего ИТ-отдела и самого штатного CIO (аудит).

Board-trigger

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

CDTO

CDTO (Chief Digital Transformation Officer) — руководитель цифровой трансформации: отвечает за изменения бизнес-модели, процессов и продуктов через цифровые инициативы, часто на стыке бизнеса и ИТ.

VP level

Уровень вице-президента — одна из высших руководящих должностей в иерархии западных и крупных технологических компаний.

Independent CIO

Независимый ИТ-директор — выступает как «арендованный» топ-менеджер для компаний, которым не нужен дорогой CIO в штате постоянно (например, в период трансформации). Действует независимо: он не связан корпоративными интригами или лоббированием конкретных вендоров программного обеспечения. Помогает в кризисных ситуациях или при слиянии/поглощении компаний для интеграции их ИТ-ландшафтов.

Interim CIO

Временный ИТ-директор — высококвалифицированный руководитель, который нанимается в компанию на короткий, заранее определённый срок (обычно от 3 до 12 месяцев). В отличие от «Independent CIO & Board Advisor», который чаще выступает как внешний эксперт-консультант, Interim CIO полностью берёт на себя операционное управление ИТ-департаментом и персоналом на период своего контракта.

Crisis Management

Кризис-менеджмент — система мер по управлению компанией в условиях чрезвычайной ситуации, когда под угрозой оказывается её репутация, финансы или само существование. Если IT Resilience — это подготовка к сбоям, то Crisis Management — это то, что происходит, когда «рвануло», и нужно спасать ситуацию здесь и сейчас.

Risk Advisory

Консультирование по рискам — идентификация угроз и слабых мест в ИТ-инфраструктуре, коде и процессах; проверка соответствия нормам и стандартам (compliance); ИТ-аудит эффективности текущих контролей и безопасности.

Compliance

Соответствие нормам — проверка и подтверждение того, что ИТ-системы и процессы соответствуют законам (например, о персональных данных) и/или отраслевым стандартам; включает требования, доказательства и контроль выполнения.

ИТ-аудит (IT audit)

Независимая проверка и оценка всей информационной системы компании (инфраструктуры, безопасности, процессов и людей), чтобы понять, насколько эффективно и безопасно она работает. Простыми словами: это «диспансеризация» для айти-отдела, которая показывает, где есть дыры в защите, куда зря уходят деньги и почему всё тормозит.

IT Resilience & Risk Advisory

Услуги стратегического консультирования, направленные на то, чтобы ИТ-системы компании не только были защищены от угроз, но и могли быстро восстановиться после любых сбоев. В отличие от Interim CIO, который управляет людьми, этот тип адвайзеров работает с «живучестью» технологий и процессами управления рисками.

TOGAF

TOGAF (The Open Group Architecture Framework) — фреймворк корпоративной архитектуры (Enterprise Architecture): метод и набор практик для описания целевого состояния, перехода и управления архитектурой организации.

CAPEX

CAPEX (Capital Expenditures) — капитальные затраты: инвестиции в создание/приобретение долгосрочных активов (оборудование, лицензии, внедрения), обычно с амортизацией во времени.

OPEX

OPEX (Operating Expenditures) — операционные затраты: регулярные расходы на поддержку и эксплуатацию (персонал, облако, связь, сопровождение, подписки).

ERP

ERP (Enterprise Resource Planning) — класс корпоративных систем для управления ресурсами предприятия (финансы, закупки, склад, производство, продажи) и их сквозными процессами.

DWH

DWH (Data Warehouse) — хранилище данных: централизованный слой для накопления, консолидации и аналитической обработки данных из разных источников.

ELK

ELK — стек для логирования и поиска: Elasticsearch (хранилище/поиск), Logstash (сбор/обработка), Kibana (визуализация).

SSO

SSO (Single Sign-On) — единый вход: механизм аутентификации, позволяющий пользователю получать доступ к нескольким системам после одного входа.

OLA

OLA (Operational Level Agreement) — внутреннее соглашение об уровне обслуживания между командами/подразделениями, которое обеспечивает выполнение внешнего SLA.

SLA/OLA

SLA/OLA — связка внешнего SLA (обязательства перед потребителем услуги) и внутреннего OLA (договорённости между командами), которая делает SLA исполнимым на практике.

SLA / SLI / SLO

Соглашение об уровне сервиса / индикатор / целевой уровень (в т.ч. как основа для алертов и реакции).

Circuit breaker

Паттерн ограничения вызовов к сбойному компоненту. §5.2 (R2), §8.4.

Fallback

Запасной сценарий ответа при деградации. §5.2 (R2).

Blast radius

Радиус поражения — см. фактор BR в §2.4.2 и R2 в §5.2.

Chaos Engineering

Инженерия хаоса — дисциплина, в основе которой лежит идея: чтобы построить надёжную систему, нужно научиться ломать её специально. Суть: вы намеренно вносите неисправности в работающую систему (отключаете сервер, обрываете сетевое соединение, имитируете резкий наплыв пользователей) и смотрите, как она на это реагирует. Цель: убедиться, что система «выживет» автоматически, без вмешательства людей, или понять, где она сломается, до того, как это случится по-настоящему. Известный пример: Chaos Monkey от Netflix — программа, которая случайным образом выключает рабочие серверы в «боевом» режиме, заставляя инженеров строить максимально живучую архитектуру.

GameDay

Игровой день — формат командных учений, когда ИТ-отдел (а иногда и бизнес-подразделения) моделирует критическую ситуацию и отрабатывает реакцию на неё. Как это проходит: выбирается день, назначается «ведущий» (который в секрете от команды готовит проблему) и «игроки» (инженеры, поддержка, менеджеры). Сценарии: «У нас зашифрована база данных», «Дата-центр в Москве сгорел», «Главный разработчик уволился и удалил доступ». Цель GameDay: проверить, работают ли регламенты восстановления на самом деле; посмотреть, как команда взаимодействует в стрессе (кто паникует, кто берёт лидерство); найти «слепые зоны» в мониторинге (видим ли мы вообще, что система упала?).

Post-mortem

Разбор инцидента; в факторе A1 — с обязательными последующими действиями.

Runbook

Пошаговая инструкция реагирования на сбой. §5.2 (R4).

On-call

Дежурство и дежурные роли при инцидентах. §5.2 (R5).

IT Due Diligence

Оценка IT-активов при сделках или аудите портфеля.

Mermaid

Mermaid — текстовый формат описания диаграмм, который позволяет вставлять схемы в markdown и генерировать визуализацию из кода (в документе используется для иллюстративных схем).

ASCII

ASCII — текстовое представление схем/деревьев символами (plain text), удобное для ревью и обсуждения без графики; в документе используется как альтернативное представление логики.

HTML

HTML — язык разметки для представления контента в вебе (структура документа, заголовки, таблицы и т.п.); в документе упоминается как формат оформления отдельных блоков.

Хрупкая система (Fragile по TODOIT)

Ломается. При стрессе система теряет ключевую функцию и создаёт непропорционально большой ущерб. Для хрупких систем характерны каскадные отказы, большой blast radius, высокая стоимость/сложность восстановления и зависимость от скрытых SPOF. При росте нагрузки или при сбое ущерб растёт быстрее, чем сама нагрузка, а восстановление часто требует ручных действий и «пожарного» режима.

Устойчивая система (Resilient по TODOIT)

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

Устойчивость (Resilience, по TODOIT)

Способность системы выдерживать стресс: сохранять ключевую функцию (при необходимости с контролируемой деградацией), ограничивать распространение сбоя (blast radius) и восстанавливаться до приемлемого уровня в прогнозируемые сроки. В TODOIT формализована индексом RS и факторами R1–R5. Отличается от антихрупкости (AS): устойчивость — про «выжить и вернуться в норму», антихрупкость — про усиление и обучение после стресса. См. также «устойчивая система».

Антихрупкая система (Antifragile по TODOIT)

Улучшается. Использует стресс для роста. В контексте системы это означает, что после инцидентов и нагрузок она не только восстанавливается, но и повышает свою способность избегать повторения классов проблем: укрепляет практики, автоматизацию и архитектурные ограничения (например, снижает каскады и blast radius), сокращает время обнаружения/восстановления и делает изменения безопаснее.

Хрупкость (Fragility, по Талебу)

Свойство системы ухудшаться при росте вариативности/стресса: чем сильнее стресс, тем непропорционально больше ущерб; система «не любит» волатильность.

Антихрупкость (Antifragility, по Талебу)

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

Устойчивые/Робастные (Robust, по Талебу)

Способны выдерживать стресс, оставаясь в прежнем состоянии. Они мало чувствительны к хаосу (пример: камин, феникс в мифологии, сильные государственные институты).

Неопределённость (по TODOIT)

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

Непредсказуемость (по TODOIT)

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

Стресс

Нагрузка, сбой или иное воздействие, проверяющее устойчивость системы. §1.1, §1.1.1.

Термины AI / LLM (AI-assisted диагностика)

AI-Ready

Свойство методологии быть пригодной для эффективной совместной работы с большими языковыми моделями. Формализованная структура факторов, унифицированные шкалы 1–5, прозрачные формулы и чёткие правила интерпретации позволяют LLM проводить оценку, рассчитывать индексы, моделировать сценарии «что если» и готовить черновики отчётов с высокой воспроизводимостью.

LLM (Large Language Model)

Большая языковая модель — класс искусственного интеллекта, способный обрабатывать текстовые описания систем, отвечать на чек-листы TODOIT и выполнять расчёты по заданным правилам.

AI-assisted диагностика

Подход, при котором LLM помогает проводить предварительную оценку по факторам и чек-листам, рассчитывать индексы и формировать черновики рекомендаций. Финальная ответственность и интерпретация остаются за экспертом.

Машиночитаемая структура

Представление методологии в виде чётко определённых факторов, шкал и формул, удобное для автоматической обработки искусственным интеллектом.

Сценарий «что если»

Моделирование влияния изменений отдельных факторов или групп факторов на интегральные показатели (EX_adjusted, SQI, SEI) и последующие приоритеты улучшений.

Смежные методологии и аббревиатуры (кратко)

ITSM

ITSM (IT Service Management, управление ИТ-услугами) — это подход к организации работы ИТ-отделов, ориентированный на потребности бизнеса и предоставление качественных услуг, а не просто обслуживание техники. Он включает внедрение процессов, методов и инструментов для планирования, поддержки и улучшения ИТ-сервисов.

FAIR

FAIR (Factor Analysis of Information Risk) — количественная модель киберриска: оценка частоты и величины потерь, выражение риска в денежных единицах для обсуждения с бизнесом.

VaR

VaR (Value at Risk) — метрика оценки риска в денежных единицах: величина потенциальных потерь при заданном уровне доверия за период (в документе приводится как пример результата подхода FAIR).

NIST RMF

NIST RMF (Risk Management Framework) — рамка управления рисками для систем и организаций: категоризация, выбор контролей, непрерывный мониторинг в жизненном цикле.

Google SRE Maturity

Google SRE Maturity — подход к оценке зрелости операционных практик надёжности: SLO/SLI, error budget, инциденты и другие практики Site Reliability Engineering (в документе — как объект сравнения в §10.5).

HA

High Availability — высокая доступность: избыточность, репликация, переключение при отказе, чтобы сервис оставался доступен в заданных пределах.

BCM

Business Continuity Management — управление непрерывностью бизнеса; рядом в тексте часто ISO 22301.

DDD

Domain-Driven Design — проектирование от модели предметной области и границ контекстов.

DevOps

Культура и практики совместной работы разработки и эксплуатации; CI/CD, автоматизация, общая ответственность за продакшен.

DORA

Набор метрик зрелости доставки ПО (частота деплоев, время восстановления и др.) — внешний ориентир, не часть формул TODOIT.

ITIL

ITIL (IT Infrastructure Library) — это всемирно признанный фреймворк, содержащий лучшие практики по управлению ИТ-услугами (ITSM). Он помогает организациям наладить процессы так, чтобы ИТ-отдел не просто «чинил компьютеры», а создавал реальную ценность для бизнеса.

ISO / IEC 20000

Международный стандарт на систему менеджмента ИТ-услуг.

ISO 22301

Стандарт на систему менеджмента непрерывности бизнеса.

Observability

Наблюдаемость: метрики, логи, трейсы; вывод о внутреннем состоянии по внешним следам.

Resilience Engineering

(инж. смысл) паттерны сдерживания сбоя: circuit breaker, bulkhead, таймауты, лимиты.

SRE

Site Reliability Engineering — инженерная дисциплина надёжности сервисов (SLO/SLI, инциденты, баланс изменений и стабильности).

SRM

В этом документе, если речь о поставщиках — Supplier Risk Management (риски поставщиков). Не смешивать с HA и внутренней архитектурой.

Подробные нейтральные определения и колонка «в контексте TODOIT» — §10.6, подраздел «Справочник методологий».

Практики и метрики управляемости (M1–M5, кратко)

Ниже — расшифровки терминов и метрик, которые встречаются в §10.6 (детальная карта по осям MS). Смысл факторов M1–M5 в методологии — §3.2.

Золотые сигналы (Golden Signals)

В традиции SRE — четыре базовых показателя состояния сервиса: Latency (задержка ответа), Traffic (нагрузка, запросы), Errors (ошибки), Saturation (насыщение ресурсов).

MTTD

Mean Time to Detect — среднее время от начала инцидента до обнаружения (по алертам, логам и т.д.).

SLO

Service Level Objective — целевой уровень надёжности или качества по выбранным SLI (например, доля успешных запросов за период).

Feature Flags

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

Kill Switch

Аварийное отключение функции или пути в системе (быстро убрать рискованное поведение).

Runtime Config

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

Feature Management

Практика управления включением возможностей (часто на базе feature flags) как продуктом: кто, когда и для кого включает функцию.

RACI

Матрица ролей: Responsible (исполняет), Accountable (ответственный за результат), Consulted (консультируют), Informed (информируют).

Service Owner

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

Error budget

Error budget — «бюджет ошибок» в SRE: допустимая доля/объём недоступности или ошибок относительно SLO, который помогает балансировать скорость изменений и стабильность.

Prometheus

Prometheus — система сбора и хранения метрик, часто используемая как базовый слой наблюдаемости (M1) и алертинга.

Grafana

Grafana — инструмент визуализации метрик и дашбордов; используется для наблюдаемости (M1) и контроля трендов/инцидентов.

Distributed Tracing

Distributed Tracing — распределённая трассировка запросов между компонентами: помогает находить узкие места и причины деградации, повышает наблюдаемость (M1).

GitOps

GitOps — подход к управлению деплоем и конфигурацией через Git как источник истины: изменения поставляются декларативно и воспроизводимо через конвейер.

API Gateway

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

Bulkhead

Bulkhead — паттерн изоляции ресурсов/пулами, чтобы сбой или перегрузка одного контура не «утянули» весь сервис; используется для снижения каскадов и controlled degradation (R2).

CI/CD

Continuous Integration / Continuous Delivery (или Deployment) — автоматизированная сборка, тесты, поставка и развёртывание изменений.

Automated Testing

Автоматические тесты (unit, integration, e2e и т.д.) в конвейере — снижают риск регрессий при изменениях.

Canary Release

Постепенный выкат версии на часть пользователей или трафика (или на отдельный пул), чтобы откатить при проблемах.

Lead Time for Changes

Lead time for changes — время от коммита (или готовности изменения) до работы в продакшене; одна из метрик DORA.

Deployment Frequency

Как часто выкатывают в продакшен (релизы/деплои); метрика DORA.

Blue-Green

Схема развёртывания с двумя средами (синяя/зелёная): переключение трафика на новую версию после проверки; снижает простой при выкате.

Auto-rollback

Автоматический откат на предыдущую версию при сбоях по заданным условиям (метрики, health-checks).

Infrastructure as Code

Инфраструктура описана кодом в репозитории; воспроизводимые окружения и изменения через конвейер.