Skip to content

ML-ZoneReaper/sre

Repository files navigation

Материалы и подготовка

  1. Вопросы на собеседовании
  2. Основные принципы SRE
  3. Пример хронологии инцидента с ключевыми метриками
  4. Паттерны надежности
  5. Четыре столпа наблюдаемости
  6. Создание неуязвимого мониторинга
  7. Внедрение STAMP в Google
  8. Критика MTTx метрик

Основные термины SRE

Термин Значение
SLI Индикатор уровня обслуживания — конкретная измеримая метрика, отражающая качество работы сервиса. Примеры: доля успешных HTTP-запросов (не 5xx) за скользящее окно; доля запросов, обработанных менее чем за 1 секунду. SLI — это всегда число от 0 до 100%
SLO Цель уровня обслуживания — целевое пороговое значение для SLI, которое команда обязуется соблюдать. Примеры: 99% запросов обрабатываются быстрее 1 секунды; сервис доступен 99,5% времени в месяц. SLO — внутренняя договорённость команды, не несущая юридических последствий
SLA Соглашение об уровне обслуживания — юридически обязывающий договор с потребителями или партнёрами, закрепляющий набор SLO с последствиями за их нарушение (штрафы, кредиты, компенсации). SLA как правило мягче SLO: если команда не выполняет внутренний SLO, до нарушения SLA ещё есть запас
Error Budget Бюджет ошибок — допустимый объём ненадёжности за расчётный период: Error Budget = (1 − SLO) × длительность периода. Пример: при SLO 99,9% за 30 дней бюджет = 0,1% × 43 200 мин = 43,2 минуты простоя. Пока бюджет не исчерпан — можно деплоить фичи; когда исчерпан — приоритет отдаётся стабильности
Состояние Опасности Свойство системы или набор условий, которые вместе с определённым набором наихудших обстоятельств окружающей среды приведут к инциденту
Инцидент Ситуация, при которой сервис выходит из нормального (стабильного) состояния. Примеры: диск БД заполняется в 10× быстрее обычного и закончится через месяц; время ответа выросло с 1 до 2 сек; процент ошибок вырос с 0,06% до 0,4%
Postmortem Анализ произошедшего инцидента и планирование мероприятий по предотвращению повторения или уменьшению его последствий. Проводится без поиска виновных (blameless)
MTTD Mean Time To Detect — время с начала инцидента до его обнаружения (сработавший алерт, сообщение от пользователя и т. д.)
MTTA Mean Time To Acknowledge — время с момента алерта до подтверждения дежурным инженером, что он принял инцидент в работу
MTTI Mean Time To Identify — время с обнаружения инцидента до изоляции места поломки. Пример: «Сломан сервис X» или «Проблемы на балансировщике Y»
MTTM Mean Time To Mitigate — время от изоляции проблемы до устранения её воздействия на пользователей (переключение трафика, включение обходного пути и т. д.), без обязательного устранения первопричины
MTTR Mean Time To Resolve (или Repair) — время с начала инцидента до полного устранения первопричины и восстановления нормальной работы сервиса. MTTR ≥ MTTM
RTO Recovery Time Objective — максимально допустимое время простоя до восстановления сервиса (определяется исходя из критичности системы для бизнеса)
RPO Recovery Point Objective — максимально допустимая потеря данных, измеряемая во времени. Пример: RPO = 15 мин означает, что данные за последние 15 минут могут быть утрачены
STAMP Systems-Theoretic Accident Model and Processes — подход к анализу инцидентов, основанный на теории управления. Вместо поиска «сломанного компонента» исследует, какие управляющие воздействия и обратные связи оказались неэффективными. Цель — перейти от реактивного «тушения пожаров» к проактивному проектированию систем, которые не могут войти в Состояние Опасности

About

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

Topics

Resources

Stars

Watchers

Forks

Contributors