Что делать, если у вас интеграция со сторонней системой, которая в случае критических ошибок отдает только код ошибки или непонятный текст "Всё сломалось"? А если таких интеграций много и каждая ошибка может негативно повлиять на клиента и продукт в целом?

Зачастую логирование и обработку ошибок оставляют на уровне кода. Но бизнес-процессы меняются, а вместе с ними и ошибки. Каждый раз искать их в коде и переписывать — сложно и долго. Из-за этого на устранение критической ошибки уходит много сил и времени: разработчик идёт к аналитику, аналитик к бизнесу, бизнес говорит, что делать, и так обратно по цепочке. Повторения таких ошибок могут негативно влиять на репутацию компании.

Возникает задача: как быстро решать проблемы пользователей, и кто этим должен заниматься.

В докладе расскажу, как технические инструменты помогают в мониторинге бизнес-ошибок. Обсудим, как при помощи связки логирования, Графаны и автоматических алертов быстро получать понятные и структурированные требования по обработке ошибок. Сравним несколько подходов мониторинга и рассмотрим примеры, где аналитик сам настраивает мониторинг.