intDataBlog
← ЖурналМаршруты обучения ↗

Надёжность: от сигнала к проверенной гипотезе

Свяжите симптомы, журнал и метрику с пользовательским сценарием.

Практика рассчитана на отдельную учебную среду и вымышленные данные.

Наблюдаемость

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

Метрика показывает агрегированное поведение, журнал — отдельные события, трассировка — путь конкретной операции. Ни один сигнал не объясняет систему в одиночку. Начните с пользовательского симптома, выберите временное окно и сопоставьте сигналы. Совпадение по времени помогает выдвинуть гипотезу, но ещё не доказывает причинность.

  • Логи, метрики и traces
  • Ошибка и задержка
  • Контекст запроса

Попробуйте

  1. Разберите данные: request-42, API 1200 ms, DB 1100 ms, errors 0%.
  2. Сформулируйте гипотезу, не объявляя её причиной.
  3. Предложите следующую проверку запроса БД и сигнал p95 latency.

Объяснено, что отсутствие ошибок не означает хорошую задержку; гипотеза проверяема.

Почему средняя задержка может скрыть проблему?

Небольшая доля очень медленных запросов теряется в среднем; нужны распределение и перцентили.

Продолжить на русском и английском
  • Observability primer EN ↗

    Логи, метрики и трассировки. Открытая документация.

  • Site Reliability Engineering books EN ↗

    SLO, мониторинг и разбор инцидентов. Открытые онлайн-книги; материал для этапа после основ.

  • Linux Labs RU ↗

    Первый практикум раздела «Первые шаги». Браузерные VM; для запуска нужен вход через Google.

Разбор инцидента

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

Во время инцидента отделите восстановление полезной работы от поиска окончательной причины. Запишите симптом, масштаб и время начала; выберите безопасную проверку первой гипотезы. После действия проверьте тот же пользовательский сценарий. Хронология с фактами полезнее уверенного объяснения, которому не соответствует ни одно наблюдение.

  • Симптом и масштаб
  • Гипотеза и проверка
  • Проверка восстановления

Попробуйте

  1. Разберите данные: после релиза ошибки 500 выросли с 1 до 30%; CPU не изменился; журнал сообщает invalid config.
  2. Выберите проверку синтаксиса конфигурации перед новым релизом или откатом.
  3. Запишите: влияние, факты, действие, контрольный запрос после восстановления.

Разбор не приписывает CPU причину; успех подтверждён ответом сервиса, а не только статусом процесса.

Чем mitigation отличается от root cause?

Mitigation уменьшает влияние сейчас; подтверждённая причина объясняет механизм возникновения сбоя и требует отдельного разбора.

Продолжить на русском и английском
  • SadServers EN ↗

    Выберите Easy и проверьте условия запуска. Доступ зависит от сценария: открытый, по email или платный.

  • Site Reliability Engineering books EN ↗

    SLO, мониторинг и разбор инцидентов. Открытые онлайн-книги; материал для этапа после основ.

  • Linux Labs RU ↗

    Первый практикум раздела «Первые шаги». Браузерные VM; для запуска нужен вход через Google.

Надёжность SRE

Цель надёжности должна описывать полезное пользователю поведение за понятное окно. Ошибочный бюджет помогает обсуждать риск, но не заменяет диагностику.

Надёжность измеряют через действие пользователя: долю успешных запросов, доступность нужной функции или время ответа. SLO задаёт цель для такого показателя на выбранном окне. Бюджет ошибок выводится из цели и наблюдений; он помогает обсуждать темп изменений, но не разрешает сознательно тратить доступность без контекста.

  • SLI и SLO
  • Окно измерения
  • Бюджет ошибок

Попробуйте

  1. Для учебных 10 000 запросов считайте успешными 9 950; вычислите долю.
  2. Сравните 99,5% с целью 99,9% за то же окно.
  3. Объясните, почему замер за пять минут нельзя напрямую сравнить с месячной целью.

Расчёт даёт 99,5%; окно и определение успешного запроса записаны явно.

Какой бюджет ошибок при SLO 99,9% из 10 000 запросов?

Десять неуспешных запросов при таком определении SLI и окне. Это не автоматически бюджет времени.

Продолжить на русском и английском
  • Site Reliability Engineering books EN ↗

    SLO, мониторинг и разбор инцидентов. Открытые онлайн-книги; материал для этапа после основ.

  • Introduction to DevOps and SRE EN ↗

    Прочитайте вводную часть после общей базы. Бесплатный курс; сначала основы Linux, сетей и скриптов.