Мы любим вызов, но…

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

Итак, мы стремились создать систему оповещения, отвечающую следующим требованиям:

  • Будьте активны (без ложных срабатываний)
  • Триггер на краткосрочные и долгосрочные проблемы
  • Работа с интеграциями с низким и высоким трафиком
  • Работа в пиковые и непиковые часы

Работа из «Хорошей книги».

В качестве основы мы решили использовать методологию Google SRE из SRE Workbook. Это решило многие из наших требований из коробки. Вот как это выглядело.

В первую очередь здесь нужно определить, что представляет собой действующее оповещение. Должно ли такое оповещение срабатывать в случае 30% ошибок в течение 5 минут? Или 80%? Это зависит от. Без каких-либо долгосрочных ожиданий сами по себе цифры ничего не значат. Поэтому мы использовали концепцию SRE Workbook SLO (цель уровня обслуживания), которая представляет собой показатель успешности (1 минус коэффициент ошибок), который мы хотим иметь в конце месяца (мы работаем ежемесячно, но можно выделить любую единицу времени). Вместе с SLO приходит понятие Бюджет ошибок — пороговое значение ежемесячных ошибок, в пределах которого мы должны оставаться, чтобы соответствовать SLO (например, в случае SLO 99 %, 100 000 бронирований в месяц бюджет ошибок составляет 1 000). .

В рамках этой структуры под действенным оповещением понимается оповещение, которое срабатывает, если SLO находится под угрозой.

Запуск по краткосрочным и долгосрочным проблемам

Прежде всего, зачем запускать долгосрочные проблемы? Не являются ли крупные отключения через более короткие интервалы более серьезной проблемой? Не на самом деле нет. Допустим, у нас есть интеграция со 100 тысячами событий в месяц (~ 140 событий в час) и 99% SLO (1 тысяча ошибок). 30-минутный полный сбой со 100-процентной частотой ошибок приведет к сбою 70 событий, что съест 7% нашего бюджета ошибок. Частота ошибок 5 % за 6 дней приводит к сбою примерно 1 000 событий. Таким образом, весь бюджет ошибок сгорает. Так что оба имеют значение. Каждый расходует бюджет ошибок с разной скоростью. Этот темп представлен постоянной величиной Burn Rate.

Уровень сжигания калорий в нескольких временных окнах

Когда дело доходит до фиксации краткосрочных и долгосрочных проблем, Рабочая тетрадь SRE предлагает использовать 3 временных окна. Каждый из них применяет разную скорость сжигания калорий. Конфигурация может выглядеть следующим образом для 99% SLO:

  • Более 2 часов: частота ошибок 7,2% (= 7,2 * (1-SLO))
  • Более 12 часов: 3 % коэффициента ошибок (= 3 * (1-SLO))
  • Более 3 дней: 1% коэффициент ошибок (= 1 * (1-SLO))

Формула для коэффициента ошибок: Burn Rate* (1 — SLO), например. 7,2*(1-СЛО).

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

  • 2 часа: Дежурство по вызову
  • 12 часов: Дежурство по вызову
  • 3 дня: Slack-уведомление/тикет Jira

Определение подходящей скорости оповещения

Достаточно ли быстро такое оповещение? Это можно рассчитать довольно просто, используя формулы из книги SRE. Для нашей модели (99% SLO, 100 тыс. бронирований/месяц) поведение каждого окна в случае полного простоя (100% вероятность ошибок) выглядит следующим образом:

Приведенный выше расчет показывает, когда это первое 2-часовое окно вызовет оповещение через 8 минут. 12-часовое окно сработает через 13 минут, а 3-дневное окно сработает к северу от 43 минут. Итак, давайте посмотрим на поведение всего решения (работа только с первым случаем предупреждения).

Эта структура отлично справляется с выявлением проблем, влияющих на SLO, независимо от их размера.

Скорость перехода в состояние ОК

Вышеупомянутые оповещения создают небольшую проблему, поскольку они остаются в состоянии оповещения дольше, чем это необходимо или даже целесообразно (например, целых 3 дня, даже для инцидента, который длился 5 часов). Чтобы компенсировать это, книга SRE предлагает использовать подокна. Каждое окно разбито на основную (например, 12 часов) и второстепенную (например, 1 час) части. Для предупреждения частота ошибок должна превышать предел в обоих подразделах.

К сожалению, на этом подробные советы из SRE Book заканчиваются, поэтому нам пришлось разрабатывать собственные решения, специфичные для нашего варианта использования.

Решение проблемы интеграции с низким и высоким трафиком

Для сервисов с высокой посещаемостью (1000 событий в час и более) вышеупомянутое решение работает сразу после установки. Книга SRE даже предлагает работать с более короткими окнами (1 час, 6 часов, 3 дня). Наши интеграции бронирования могут сильно различаться; некоторые генерируют относительно низкий трафик — от сотен бронирований в час до нескольких в день. Это создает проблему. Чтобы рассчитать разумный коэффициент ошибок, вам нужен определенный объем бронирований. У вас может быть 50% ошибок из-за 5 сбоев из 10, но это может быть просто один постоянный пользователь, повторяющий попытку снова и снова.

К чему мы пришли, так это к разным комбинациям временных окон в зависимости от трафика конкретных интеграций. Самые большие интеграции имеют 3 окна (2 часа/6 часов/3 дня), а самые маленькие интеграции имеют 2 окна (10 дней/30 дней). В завершение у нас есть несколько комбинаций для интеграции среднего размера.

Ограничение SLO на основе трафика

Очевидно, что название игры ограничивает максимально возможный SLO. Таким образом, в то время как наши самые большие интеграции могут иметь 99%+ SLO, более мелкие (10 бронирований в день) имеют ограничение в 80%. Это важно по нескольким причинам. Во-первых, если у нас недостаточно бронирований в окне, вы не можете получать оповещения о высоком SLO. Представьте SLO 99%, окно 30 дней, 10 бронирований в день (300 бронирований в месяц). В этом сценарии 3 сбоя вызовут оповещение. Но опять же, это может быть повторная попытка только одного пользователя. Во-вторых, интеграция с высоким трафиком оказывает гораздо большее влияние на пользователей. Таким образом, цель состоит в том, чтобы иметь как можно более высокий SLO, а затем получать оповещения о небольших интеграциях, если влияние на клиентов сравнимо с нашими более крупными интеграциями.

Небольшие интеграции не мешают пейджеру

Учитывая структуру SLO, мы установили дежурство для средних и крупных интеграций, в то время как для небольших интеграций используются только оповещения о сообщениях Slack/тикетах Jira. Это является приоритетом, когда речь идет о необходимых действиях.

Пиковые и внепиковые периоды

В Omio большинство интеграций бронирования имеют большие различия между пиковыми и непиковыми часами. Например, интеграция может иметь 100 бронирований в час днем ​​и менее 10 бронирований в час ночью.

Отключение оповещений в ночное время недопустимо, потому что незамеченное отключение в течение нескольких часов в ночное время оказывает серьезное влияние на клиентов и может привести к сбою SLO. С другой стороны, полное отключение ночью (10 бронирований в час) оказывает гораздо меньшее влияние, чем днем ​​(100 бронирований в час). Итак, мы отключили оповещение о самом коротком окне ночью.

Мы рассчитали влияние ночных отключений на бюджет ошибок. См. таблицу ниже для нашего примера (99% SLO, 100 тыс. бронирований/месяц) при полном отключении на 1 час:

Было ясно, что самое короткое окно (2 часа) должно быть отключено ночью, но 12-часовое окно все равно должно активировать дежурство по вызову. На изображении ниже показаны 2 оповещения, активирующие дежурство по вызову.

Слишком мало бронирований? Не обращайте внимания на Окно.

Для простоты мы требуем не менее 50 бронирований в период временного окна, в противном случае окно игнорируется.

Техническое решение

Ключевым аспектом этого решения является не создание чего-то специального (например, настраиваемых оповещений), а повторное использование существующих инструментов оповещений, уже представленных на рынке. Мы реализовали вышеупомянутое оповещение, используя исходный код Graphite и Grafana for Dashboards. Для таких сложных запросов Graphite необходимо использовать платформу шаблонов — мы используем Terraform. Для хранения SLO и других конфигураций мы используем Directus CMS.

В итоге.

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