Как определить, что сервис возвращает ошибки 500
Что проверяют
Узнаёте ли вы о проблеме раньше пользователей и умеете ли отличать всплеск от единичного случая.
Как отвечать
Перечислите источники, от быстрых к медленным:
- метрики: доля ответов 5xx по сервисам и ручкам, с оповещением при превышении порога. Это основной способ узнать о проблеме за минуты. Смотрят долю, а не абсолютное число, потому что трафик меняется;
- логи: поиск по уровню ошибки за интервал, группировка по тексту, чтобы понять, одна это причина или несколько;
- трассировка: по идентификатору запроса видно, какой именно сервис в цепочке вернул ошибку, а не тот, что просто передал её дальше;
- система сбора ошибок (Sentry и подобные) с группировкой по стектрейсу и версии сборки;
- синтетические проверки: сценарий, который раз в минуту ходит по ключевым ручкам и падает раньше, чем заметит пользователь;
- проверка после релиза: сравнение доли ошибок до и после выката, потому что большинство всплесков рождается именно там.
Со стороны тестировщика добавьте своё: в автотестах API стоит проверять не только успешный сценарий, но и что при неверных данных приходит 4xx, а не 5xx. Пятисотка на кривой ввод это дефект: сервер обязан объяснить ошибку, а не падать.
И отдельно про разбор: 500 всегда означает дефект на сервере, даже если запрос был странным. Первое, что нужно приложить, это идентификатор запроса и время, дальше причина ищется в логах.
Где спотыкаются
Смотрят абсолютное число ошибок и не видят проблемы при падении трафика.
Считают 500 на некорректный запрос нормой.
Узнают о проблеме из обращений пользователей, потому что оповещений нет вовсе.