Site Reliability Engineering я прочитал несколько раз с перерывом в год с лишним. Подобное “перепрочтение” позволяет еще раз по мере роста опыта взглянуть на ту или иную задачу.
По схожей причине сейчас перечитываю SRE Workbook, а конкретно главу Alerting on SLOs. От того интереснее еще раз пройтись по термину burn rate.
Полностью все описывать нет смысла, прочитайте по ссылке, там очень интересно, даже если вы далеки от SRE практик.
Подход SLO и error budget привносит в работу операций нотку экономики. И именно таким образом авторы из Google предлагают реагировать на нездоровость системы.
Возьмем SLO по успешным ответам (2ХХ) 99.9%. Иными словами, только 0.1% запросов или 1 из 1000 не будут корректно обработаны системой. SLO растягивается на часы, дни, кварталы, месяцы и так до года. Каким образом выбрать временнОе окно для замеров и логику уведомлений?
В Google решили применить способ расчета под названием Burn Rate - в каком темпе “съедается” наш заделанный на год бюджет ошибок, в искомой главе есть небходимые значения. Расчет самого burn rate я не понял, если кто понял, напишите в комментариях, обучите уму разуму, мне под конец года уже лень.
А поскольку “гореть” можно слабо, но продолжительно, а можно ярко, но недолго, умные ребята предложили интересную математику: возьмем несколько окон, несколько burn rate’ов, Булеву Алгебру и получим удобные и своевременные уведомления, на которые можно реагировать.
Наглая копия из книги:
expr: (
job:slo_errors_per_request:ratio_rate1h{job=“myjob”} > (14.4*0.001)
and
job:slo_errors_per_request:ratio_rate5m{job=“myjob”} > (14.4*0.001)
)
or
(
job:slo_errors_per_request:ratio_rate6h{job=“myjob”} > (6*0.001)
and
job:slo_errors_per_request:ratio_rate30m{job=“myjob”} > (6*0.001)
)
severity: page
Итого ловим судорожные звонки от робота, когда система сбоит жестко в течение пяти минут И часа ИЛИ чуть помягче в течение получаса И 6 часов.
Сложно, да. А вы как хотели?