Как установить SLO и оповещения для этих SLO для чайников
Когда я начал заниматься SRE, я не осознавал, сколько времени уходит на правильную настройку SLO. На первый взгляд это довольно легко. Выберите процент, выберите порог и вперед.
Затем вы начинаете настраивать оповещения для этого SLO, и ваш пейджер начинает постоянно отключаться. Или, что еще хуже, вовсе нет.
Что такое SLO
SLO, или цели уровня обслуживания, — это то, что мы используем для описания того, что означает, что наша служба работает, и какой процент времени мы хотим соответствовать этому определению.
SLO помогают нам сосредоточиться на том, что нам нужно для улучшения наших услуг, но их может быть сложно установить, поскольку вам обычно предоставляется только процент времени безотказной работы, который вы должны соблюдать, как это определено отделом продаж и юридического отдела.
Предположим, что в связи с договорами с клиентами нам необходимо иметь минимум 99% доступности. Это наш SLA, наше соглашение об уровне обслуживания. Мы установили более агрессивную цель SLO: 99,9%. Таким образом, если мы нацелимся на 99,9%, мы можем потерпеть большой промах и все же выполнить наши соглашения.
Но 99,9% — это просто процент, а не SLO. Чтобы создать SLO, нам нужно что-то вроде:
99,9% всех публичных запросов к нашему приложению будут выполняться менее чем за 500 мс.
Это говорит нам, что именно должно происходить и как часто, чтобы добиться успеха. Мы можем установить оповещения, которые сообщат нам о нарушении нашего SLO; когда наш сервис уже не работает. Теоретически у нас будет достаточно времени между нашим SLO и нашим SLA, чтобы исправить все, что не так, и не нарушать наши соглашения с клиентами.
Установка наших SLO для успеха
Чтобы установить 500ms часть SLO, мы можем либо собрать большой объем данных (примерно 6 месяцев времени отклика, чтобы убедиться, что мы не видим моментальный снимок во времени, который не отражает фактическую производительность службы), или вы можете имитировать данные о производительности за 6 месяцев с помощью K6, как описано здесь.
Если бы мы обнаружили, что 95% запросов к нашему сервису отвечают менее чем за 200 мс, мы бы не хотели устанавливать для нашего SLO это число, потому что мы уже нарушаем наш SLO из-за того, как наш сервис работает в обычный день.
Мы могли бы выбрать случайное число для установки SLO или добавить 100 или 200 мс к 95-му процентилю задержки, но это может привести к тому, что мы установили слишком низкое значение, и мы будем получать оповещения слишком часто, или что мы установили его слишком часто. слишком высока, и мы не получим своевременного уведомления о восстановлении нашего приложения, прежде чем мы нарушим наше соглашение об уровне обслуживания.
Проблема с оповещением о SLO
Единственная проблема со стратегией, о которой мы говорили выше, заключается в том, что она требует, чтобы мы поставили цель, а затем не были предупреждены, пока мы уже не достигли этой цели. Даже если мы идеально настроим SLO, мы все равно обречены на неудачу.
Возникает вопрос: что нам нужно настроить для наших предупреждений, чтобы нас не предупреждали слишком рано или слишком поздно? Как мы можем убедиться, что наши оповещения настроены правильно, чтобы мы знали, когда у нас возникла проблема?
В дополнение к оповещениям, как мы узнаем, какой должна быть производительность нашего сервиса, чтобы убедиться, что у нас есть какие-либо шансы на соблюдение нашего SLO?
В этой статье я покажу вам, как настроить оповещение о задержке на основе SLO, как выяснить, какое время отклика нам нужно от нашего сервиса, чтобы иметь шансы на соответствие нашему SLO, и как установить время отклика нашего SLO. на основе существующей производительности нашего приложения, если у нас уже есть базовый уровень, но нет требуемого времени отклика.
За годы работы SRE я обнаружил, что существует эмпирическое правило. Величина, на которую вы должны изменять SLO и пороговые значения предупреждений, немного отличается для каждого уровня доступности (99 %, 99,9 %, 99,99 %, 99,999 % и т. д.), который вы соглашаетесь установить.
Когда у вас есть только 4,32 минуты простоя в месяц до нарушения SLO, вы должны получать оповещения гораздо раньше и гораздо быстрее реагировать на ухудшение качества обслуживания, чем если бы у вас было 43,2 минуты простоя в месяц для реагирования на проблемы с сервисом. . В случае SLO 99,99% нам нужно было бы установить наши оповещения ниже, а порог SLO выше, чтобы убедиться, что мы можем достичь поставленных целей.
Хотя это обычно делается по ощущениям или опыту, я решил использовать удобную диаграмму, которую я составил, которая описывает, каким должно быть целевое время отклика моей службы, и где я буду устанавливать свое оповещение, чтобы убедиться, что мы можем выполнить обязательство, которое мы взяли на себя в наших SLO.
Как вы можете видеть выше, есть некоторые вещи, которые необходимо учитывать на каждом уровне доступности, и в сервисах с большим разнообразием вы можете захотеть использовать дисперсию более высокого SLO, чем тот, который вы используете.
Пример 1
На основе этой диаграммы, если нам дали SLO с обязательным временем отклика, который выглядит следующим образом:
99,9% всех публичных запросов к нашему приложению будут выполняться менее чем за 500 мс.
Я хотел бы убедиться, что у меня есть 15% буфер между моментом срабатывания моего предупреждения и превышением порога. Итак, мое предупреждение сработает через 425 мс.
Мне также нужен 15-процентный буфер между моим порогом оповещения и фактическим временем отклика моей службы. Поэтому 95-й процентиль моих запросов должен выполняться за 350 мс, чтобы у этого SLO был хоть какой-то шанс быть поддерживаемым.
Если моя служба не может ответить в течение этого периода времени, мне нужно либо быть уверенным, что я автоматизировал почти все сбои моей службы, либо увеличить количество экземпляров моих служб в нескольких регионах, чтобы гарантировать, что одна из них не выйдет из строя, либо масштабировать моя способность учитывать более высокий рост трафика.
Пример 2
Мы также можем работать в обратном направлении от нашего существующего времени отклика, если нам задан целевой процент SLO. Если мы знаем, что должны соответствовать SLO 99,99%, а наше время отклика 95-го процентиля для нашего сервиса составляет 200 мс, я могу сделать следующее:
99,99% = 25% дисперсия
200 * .25 = 50
поэтому наше оповещение должно сработать на 250.
250 + 50 = 300, поэтому мы хотели бы установить SLO как минимум:
99,99% всех публичных запросов к нашему приложению будут выполняться менее чем за 300 мс.
Некоторые вещи, которые следует учитывать
Примечание: при доступности 99,99 %, в отличие от доступности 99,9 %, предполагается, что у вас будет мультирегиональный или какой-то отказоустойчивый режим, а также начало самовосстановления. Ваше тестирование также должно быть очень хорошим.
По мере того, как вы поднимаетесь по диаграмме в процентах доступности, то, что требуется для достижения каждого из этих пороговых значений, становится все более дорогостоящим с точки зрения рабочей силы и инфраструктуры. На этой диаграмме предполагается, что вы предпринимаете шаги, необходимые для восстановления в течение требуемого времени.
На диаграмме также не учитываются сервисы с очень резким временем отклика, и, как описано в моей предыдущей статье SLO, иногда сервисам нужны SLO, состоящие из нескольких частей, чтобы убедиться, что все настроено правильно.
Спасибо, что провели здесь время, и, пожалуйста, обращайтесь, если у вас есть какие-либо вопросы, и я надеюсь, что это кому-то поможет!
Ресурсы
https://medium.com/@sazipkin/what-is-my-slo-and-how-do-i-test-it-bd3d1ac38d88
