КАТЕГОРИЯ
Надежность и SRE
198 материалов
SLAВнешнее соглашение фиксирует обязательства по уровню сервиса.SLIНаблюдаемый показатель измеряет конкретный аспект качества сервиса.Error BudgetДопустимая ненадежность балансирует скорость изменений и стабильность.TimeoutКаждое удаленное ожидание должно иметь ограничение времени.Exponential BackoffПауза между повторами увеличивается после каждого отказа.Full JitterСлучайность в задержках предотвращает синхронные волны повторов.Retry BudgetКоличество повторов ограничивается долей общего трафика.Load SheddingСистема отбрасывает часть работы, сохраняя критические функции.Fail FastНевалидное состояние отвергается как можно раньше.Fail SafeПри отказе система переходит в безопасное состояние.FailoverНагрузка переключается на резервный компонент.RedundancyНезависимые резервные компоненты уменьшают вероятность полной потери функции.Single Point of FailureОдин компонент способен остановить всю систему.Four Golden SignalsLatency, traffic, errors и saturation дают базовый обзор здоровья сервиса.Retry StormПовторы запросов усиливают перегрузку зависимого сервиса.Cache StampedeИстечение популярного ключа вызывает массовое вычисление одного значения.Alert FatigueИзбыточные сигналы снижают внимание к реальным инцидентам.Monitoring the MeansКоманда следит за внутренними ресурсами, но не за пользовательскими симптомами.Silent FailureОшибка скрывается без сигнала и накапливает неверное состояние.Gray FailureКомпонент частично работает и наблюдается по-разному разными узлами.Split BrainНесколько узлов одновременно считают себя активным лидером.Zombie ProcessУстаревший или потерявший координацию процесс продолжает выполнять действия.SLI — индикатор уровня сервисаИзмеряет наблюдаемое свойство сервиса, важное пользователю.SLO — цель уровня сервисаЗадает целевой диапазон надежности для выбранного индикатора.SLA — соглашение уровня сервисаЗакрепляет внешние обязательства и последствия их нарушения.MTTR — среднее время восстановленияПоказывает, насколько быстро система возвращается в рабочее состояние.MTTF — среднее время до отказаОценивает ожидаемую продолжительность работы до следующего сбоя.RTO — целевое время восстановленияОпределяет, сколько времени бизнес может ждать восстановления.RPO — допустимая потеря данныхОпределяет, какой объем последних данных допустимо потерять.Четыре золотых сигнала SREФокусирует наблюдение на задержке, трафике, ошибках и насыщении.Метод REDОценивает сервис по частоте запросов, ошибкам и длительности.Метод USEИщет проблемы ресурса через использование, насыщение и ошибки.Rate LimitingОграничивает скорость запросов для защиты ресурса и справедливого доступа.Hedged RequestsЗапускает резервный запрос при аномальной задержке первого.Canary ReleaseПроверяет новую версию на малой доле реального трафика.Blue-Green DeploymentСнижает риск релиза переключением между двумя готовыми средами.Feature FlagsОтделяет развертывание кода от включения пользовательской функции.RunbookФиксирует воспроизводимую процедуру диагностики и восстановления.Blameless PostmortemРазбирает механизм сбоя без поиска виноватого, чтобы улучшить систему.Toil в SREРучная повторяющаяся работа должна измеряться и постепенно автоматизироваться.Observability CardinalityСлишком много уникальных значений меток резко увеличивает стоимость метрик.Sampling StrategyВыборка сокращает объем телеметрии, сохраняя полезные сигналы.Correlation IDЕдиный идентификатор связывает операции одного запроса между сервисами.Synthetic MonitoringРегулярные искусственные сценарии проверяют доступность глазами пользователя.Real User MonitoringСобирает показатели производительности из реальных пользовательских сессий.Apdex ScoreСводит время ответа к доле удовлетворенных, терпящих и неудовлетворенных пользователей.Дрейф к отказуКатастрофа может возникать из постепенной адаптации к давлению, когда каждое локальное решение выглядит разумным.Принцип локальной рациональностиДействия людей обычно имели смысл с учётом доступной им информации, целей и ограничений в тот момент.Нормализация отклоненийПовторяющееся отклонение от нормы без немедленного ущерба постепенно начинает считаться безопасным и приемлемым.STAMP: системно-теоретическая модель аварийБезопасность рассматривается как задача управления ограничениями, а авария — как результат неадекватного контроля взаимодействий.Safety-IIБезопасность повышают не только устранением отказов, но и пониманием того, как система ежедневно успешно адаптируется к изменчивым условиям.Метод анализа функционального резонансаНебольшая изменчивость нескольких нормальных функций может резонировать и создавать неожиданно большой системный эффект.Указание времени повторного запросаRetry-After сообщает клиенту, когда имеет смысл повторить запрос после временной недоступности или ограничения частоты.Корректное завершение сервисаКорректное завершение прекращает приём новой работы, даёт текущим операциям закончиться и только затем останавливает процесс.Проверка готовностиReadiness probe отвечает, готов ли экземпляр прямо сейчас принимать пользовательский трафик.Проверка работоспособности процессаLiveness probe определяет, способен ли процесс продолжать работу или его следует перезапустить.Проверка запускаStartup probe даёт медленно запускающемуся приложению отдельное окно времени до включения liveness и readiness проверок.Стандарт передачи контекста трассировкиTrace Context стандартизирует заголовки traceparent и tracestate для передачи идентичности трассы между сервисами.Контекстные метаданные BaggageBaggage передаёт произвольные пары ключ-значение вместе с распределённым контекстом между сервисами.Распределённая трассировкаРаспределённая трассировка связывает участки одного запроса в разных процессах и показывает их порядок, длительность и ошибки.Экземпляры наблюдений в метрикахExemplar связывает агрегированную метрику с конкретным наблюдением, например trace id запроса, который попал в histogram bucket.Выборка трасс после завершенияTail-based sampling принимает решение сохранить трассу после того, как увидит её результат или значительную часть.Структурированное журналированиеСтруктурированный лог хранит событие как набор типизированных полей, а не только как готовую строку.Дублирующий запрос для снижения хвостовой задержкиRequest hedging запускает дополнительную копию медленного запроса и использует первый успешный ответ.Адаптивный предел параллелизмаАдаптивный лимит меняет допустимое число одновременных запросов по наблюдаемой задержке и признакам насыщения.Перемешанное шардированиеShuffle sharding назначает каждому клиенту небольшую комбинацию ресурсов из общего пула, уменьшая число клиентов с одинаковой зоной отказа.Очередь недоставленных webhookСобытия, исчерпавшие политику повторов, сохраняются отдельно для диагностики и управляемой повторной отправки.Спецификация SLIИндикатор уровня сервиса формально задаёт событие, критерий хорошего результата, источник данных и окно измерения.Многооконный burn rateАлерт сравнивает быстрое и медленное расходование error budget, чтобы сочетать скорость реакции и устойчивость к шуму.Предел операционной рутиныКоманда устанавливает максимальную долю повторяемой ручной работы и направляет превышение в автоматизацию или упрощение.Проверка эксплуатационной готовностиДо запуска проверяются наблюдаемость, ёмкость, зависимости, откат, дежурство и известные режимы отказа.Качество runbookИнструкция инцидента содержит проверяемые симптомы, безопасные действия, точки остановки и путь эскалации.Ролевая модель управления инцидентомВо время инцидента явно назначаются координация, техническое выполнение, коммуникация и ведение хронологии.Модель серьёзности инцидентаУровень инцидента определяется по влиянию, масштабу и срочности, а не по громкости отдельного сигнала.Контроль действий после инцидентаКорректирующие действия получают владельца, срок, критерий завершения и проверку фактического снижения риска.SLO зависимостиОжидания от внешней зависимости формализуются и сопоставляются с собственным SLO и запасом устойчивости.Мониторинг синтетических пользовательских путейПлановые проверки воспроизводят ключевые пользовательские пути из контролируемых точек и фиксируют доступность каждого шага.Контроль высокой кардинальностиСистема ограничивает метки и атрибуты с почти уникальными значениями, чтобы сохранить стоимость и управляемость телеметрии.Политика выборки логовЧастые однотипные события уменьшаются по явному правилу, сохраняя ошибки, редкие случаи и возможность оценки исходного объёма.Бюджет стоимости телеметрииОбъём логов, метрик и трасс ограничивается по сервисам и ценности диагностического сигнала.