Разбор – Алерт без реакции это не алерт, а шум

Привет, %username%! В понедельник спрашивал, сколько алертов вы закрыли, не сделав по ним ничего. 53 голоса: 30% сбились со счёта, ещё 26% насчитали от шести до двадцати. Больше половины канала — шесть и больше холостых за неделю.

«Сбился со счёта» — честный ответ и худший из четырёх: не потому что много, а потому что нет числа. А раз долю полезных никто не считает, то и предъявить нечего: ни цели на квартал, ни аргумента руководителю, зачем тратить спринт на алерты вместо фич.

У меня в листе планка — от 95% полезных. Шесть холостых в неделю при потоке в тридцать штук дают 80%, двадцать — уже треть. На такой доле дежурный перестаёт читать алерты и жмёт ack рефлекторно, а через месяц-другой так же рефлекторно закрывает тот единственный за квартал, который был настоящим. Так инциденты и пропускают.

19% ответили «ни одного», и это по-прежнему два разных ответа: runbook на каждый алерт или алертов нет вовсе. Второй случай — мой.

За одну смену: выпиши три последних холостых и по каждому реши — runbook и владелец или дата, после которой алерт удаляют. Третьего состояния у алерта не бывает.

Всё это из листа Alert Fatigue Management в The Way of SRE — моей карты компетенций SRE. Лист в черновике, так что спорить с ним самое время.

Чего не хватает — напиши в комментариях или заведи issue. Особенно про планку: 95% на твоём контуре — цель или цифра из книжки?

#SRE #DevOps #Observability #AlertFatigue #OnCall #Monitoring #IncidentManagement

Мишка на сервере — про надёжность, инциденты и инженерную практику

В этом посте были ссылки, но мы их удалили по правилам Сетки