Про баги, алерты и басню «Волки, волки». Я довольно часто сс | Shoo and Endless Agony

Про баги, алерты и басню «Волки, волки».

Я довольно часто ссылаюсь на Федю Борщева, что несмотря на то, что в некоторых моментах мы исповедуем совсем разные подходы.
Один из недавних его постов был про вред избыточного алертинга.
Здесь и про false positive срабатывания и про желание видеть алерты на всё, даже на то, что не требует мгновенного реагирования.
Это проблема, которая ощутимо вредит и комфорту команды, и продукту.
Учитывая, что мало кто умеет строить системы мониторинга и алертов - проблема ещё и часто встречающаяся.

Но сегодня хочется взглянуть на эту ситуацию в чуть большем масштабе.
Эта проблема актуальна не только для алертов.
Она касается всей информации о качестве продукта, ошибках и проблемах.
Если на каждый баг в продакшене C-level executive врывается в слак-чат разработки и устраивает филиал ада - то очень скоро команда перестанет на это реагировать.
Потому что в какой-то момент это сведётся к «о, K опять нашёл баг». Просто шум.
Если на каждый тикет разработчик говорит «да там вообще все рефакторить надо, давайте больше времени», то со временем вместо реальной оценки это превратится в «о, В просто любит рефакторить».
Если с каждым релизом QA инженер приходит с возгласом «такое говно катить нельзя», а там ни одного блокера - то оценка качества этим инженером будет обесцениваться в глазах команды.
Если из любой проблемы создавать critical issue - то ценность критикала падает до regular.
Если команда работает по Zero Bug Policy - десять незакрытых дефектов в бэклоге это проблема, а для команды которая просто штампует дефекты сотнями - никто даже не будет этот список смотреть, потому что найти там что-то полезное слишком сложно.

Рано или поздно все ситуации выше приводят к тому, что вы стреляете себе в ногу, игнорируя проблему которая действительно важна.
Пропускаете баг в прод, позже реагируете на алерты, ещё больше делаете больно C-level executive и просто испытываете лишний стресс.

Это не значит, что ошибки надо игнорировать.
И тем более, не значит что об ошибках или проблемах надо молчать.
Это значит, что надо здраво оценивать приоритеты для команды и бизнеса.
Даже если лично тебя вот эта фигня очень бесит.
Это значит, что эскалация тикетов и проблем должна использоваться тогда, когда обычные флоу не сработали.
В конце концов, это значит, что в общении и работе с командой не всегда нужно настаивать на своём и сражаться насмерть за чистоту продакшена или кода (это вообще очень дурная практика).
Что некоторые проблемы действительно требует срочной реакции, а некоторые окей будет посмотреть в течении суток - и разные проблемы требуют разных флоу оповещения и работы.