| SRE (Site Reliability Engineer) | Инженер по надежности | Следит, чтобы разработка и работа сервиса или продукта шла по правилам и никто не сделал себе больно. |
| SLO (Service Level Objective) | Целевой уровень обслуживания | План по надою молока. Ты не ждешь от буренки 100 литров в день, это тупо. Ты ставишь реалистичную цель: 20 литров. Если буренка дает 20 — ты доволен. SLO это та цифра, на которую вы договорились с бизнесом, чтобы считать, что сервис «работает хорошо». |
| SLI (Service Level Indicator) | Индикатор качества обслуживания | Счетчик надоя. Это не план, это фактическое значение. Та самая цифра, которую ты видишь на датчике доильного аппарата. |
| SLA (Service Level Agreement) | Соглашение об уровне обслуживания | Официальное обещание с последствиями. Это SLO, за которое ты отвечаешь рублем перед клиентом. |
| Error Budget | Бюджет ошибок | Бюджет на шалости. Пока лимит простоя не исчерпан — можно выпускать кривые фичи. Закончился? Чини ошибки. |
| Toil | Ручные действия | Перекладывание бумажек. Работа, которую инженеры делают вручную, и она не приносит пользы. Нормальные SRE это автоматизируют. |
| Reliability | Надежность | Старый дедушкин холодильник ЗиЛ. Включаешь — гудит. Выключаешь — гудит. Морозит всегда. Уже сорок лет. |
| Availability | Доступность | Работает ли кофемашина прямо сейчас? Бинарный показатель: можешь налить кофе или нет. |
| Latency | Задержка | Время ожидания кофе. Не про то, сломана кофемашина, а про то, как долго ты стоишь в очереди. |
| p^95 / p^99 latency | 95-й / 99-й процентиль задержки | Сколько ждут самые нетерпеливые. 95% ждут не больше 5 минут, а 5% самых невезучих — дольше. |
| Postmortem | Разбор полетов | После того, как самолет упал, собирается комиссия и разбирает: почему это произошло, что сделать, чтобы не повторилось. |
| MTTR (Mean Time To Recover) | Среднее время восстановления | От момента «всё пропало» до момента «фух, заработало». Чем меньше — тем круче. |
| MTBF (Mean Time Between Failures) | Среднее время между отказами | Сколько система работает без поломок. Если MTBF большой — сервис стабильный. |
| Capacity Planning | Планирование мощностей | Закупка продуктов на Новый год. Ты знаешь, что обычно приходит 10 гостей, а будет 20. Нужно закупить в 2 раза больше. |
| Scalability | Масштабируемость | Резиновые штаны. Когда приходит много клиентов — система подключает доп-мощности. Когда уходят — отключает. |
| Idempotency | Идемпотентность | Кнопка закрытия дверей в лифте. Можно нажать один раз, можно десять — результат будет один и тот же. |
| Feature Flag | Функциональный флаг | Скатерть-самобранка с секретом. Вы ставите на стол новое блюдо, но оно под колпаком. Если не понравилось — накрываете колпаком обратно за секунду. |
| Rollback | Откат | Ctrl+Z. Выпустили обновление — всё сломалось. Жмете Ctrl+Z, и сервис снова работает. |
| Blameless Culture | Культура без обвинений | Когда что-то ломается, ищут не фамилию для наказания, а слабое место в системе. |
| Burn Rate | Скорость сгорания бюджета | Как быстро тает ваш бюджет ошибок. Если бюджет на месяц сгорает за два дня — всё плохо. |
| Blast Radius | Радиус поражения | Если компонент упал, сколько ещё сервисов он утащит за собой. |
| Canary Deployment | Канареечное развертывание | Сначала пускаем 1% трафика на новую версию. Если не взорвалось — пускаем 100%. |
| Chaos Engineering | Хаос-инжиниринг | Намеренно ломаем систему (в контролируемых условиях), чтобы узнать её слабые места до реального сбоя. |
| Circuit Breaker | Предохранитель | Если сервис начал падать — автоматически перестаём слать ему запросы, даём отдохнуть и пробуем снова. |
| Daemon Set | Демон-сет | Запускаем ровно один экземпляр сервиса на каждом узле кластера. Например, для сбора логов. |
| GameDay | Учебная тревога | Запланированный день, когда команда deliberately ломает систему и тренируется её чинить. |
| Headroom | Запас ёмкости | Сколько свободных ресурсов у системы сверх текущей нагрузки. |
| Idempotency | Идемпотентность | Повтор одной и той же операции не меняет результат. |
| On-Call | Дежурство | Инженер (или группа), который отвечает за реагирование на инциденты прямо сейчас. |
| Runbook | Инструкция | Чек-лист действий для типовой аварии: шаг 1, шаг 2, эскалация. |
| Service Mesh | Сервисная сетка | «Регулировщик» для микросервисов: сам в трафике не участвует, но управляет им — ретраи, таймауты, шифрование. |
| Sidecar | Сайдкар | Вспомогательный контейнер, который запускается рядом с основным и берёт на себя инфраструктурную работу. |
| Rolling Update | Постепенное обновление | Обновляем сервис по одному экземпляру, а не все сразу. |
| Strangler Fig | Паттерн «удушение» | Новый функционал пишется рядом со старым, старый постепенно вытесняется — без big-bang переписывания. |
| RTO (Recovery Time Objective) | Целевое время восстановления | Сколько времени у вас есть, чтобы поднять упавший сервис, пока бизнес не разорился. |
| RPO (Recovery Point Objective) | Целевая точка восстановления | Сколько данных вы готовы потерять при сбое. Час? День? Неделя? |
| Triage | Триаж | Сортировка инцидентов по критичности. Что чинить первым, что может подождать. |
| Health Model | Модель здоровья | 5–10 ключевых сигналов, которые дают один ответ: «система жива» или «система умирает». |
| Thundering Herd | Бегущее стадо | Когда упавший сервис поднялся, и все клиенты одновременно ломятся к нему — он падает снова. Лечится jitter-ом. |
| Split-brain | Разделение сознания | Два сервера думают, что они главные, и данные расходятся. Опасная ситуация. |
| Tail Latency | Хвостовая задержка | Самые медленные запросы. Если 99% запросов выполняются за 10 мс, а 1% — за 2 секунды, проблема в хвосте. |
| Rate Limiting | Ограничение частоты | Если клиент шлёт 1000 запросов в секунду, а сервис держит только 100 — лишние отклоняем. |
| Zero-downtime Deployment | Деплой без даунтайма | Обновляем код так, чтобы пользователи ничего не заметили. |
| Wide Events | Широкие события | Когда в одно событие (например, HTTP-запрос) записывается вся связанная информация: user_id, latency, ошибка, версия кода. Основа observability 2.0. |