Автоматические тесты — это наше с вами всё, чтобы случайно не уронить продакшен. Необходимость тестов, думаю, никому объяснять не надо.

Есть такой термин как "flaky tasks" (тесты-снежинки), то есть тесты, исполнение которых в разное время приводит к разным результатам. Тест не выполнился, ты ищешь причину почему, а ответ оказывается "покачену, попробуйте снова запустить, авось и выполнится."

Сегодня заметил у нас такую проблему с тестами, где выставлен слишком чувствительный time-out. Код ещё не выполнился, а тест уже решил, что он не работает (скриншот в комменте).

Разработчики не доверяют таким тестам и перестают тестировать код перед деплоями (если конечно деплой не заблокирован пайплайном CI/CD). В итоге когда-нибудь уронят продакшн и заметят это только по дашбордам, если конечно дашборды тоже не "снежинки."

Noisy (шумные) операционные дашборды показывают проблемы, где их нет. Разработчики ищут причину в коде только, чтобы увидеть, что проблемы на самом деле не было. Такое бывает, когда критические и некритические метрики смешаны вместе. К агрегированным метрикам применим закон органической химии — "если добавить в бочку меда ложку говна, получаем бочку говна."

Мораль здесь такая.

Чётко осознавайте какие метрики и косяки критичны для ваших систем и трекайте только их. Less is more, когда дело касается критических модулей и пожаротушений в случае поломки.