Ключевой подход
Минимизировать стоимость поиска, воспроизведения и лечения ошибок
Для этого:
1. Репорты по 500-ткам должны быть доступны всем, лежать в каком-то лёгком доступе.
2. Репорты должны быть максимально-полными.
3. Репорты должны быть свежими.
БОНУСОМ:
На бетах - эти 500тки показываются прямо в окно браузера, чем очень облегчают отладку.
Логирование
Идеальная ситуация - когда из репорта 500-тки ты понимаешь, что произошло, почему и что нужно исправить.
в общем - не стоит скупиться на добавление данных в репорт 500.
Чего надо написать:
1. Что случилось.
2. Где случилось (в смысле страница или что-то в этом роде)
3. У кого случилось (пользователь, роль, и прочие важные данные (граждантство например, включена монетизация и т.п.)
4. С чем случилось (статья? страница?)
5. Как случилось (в смысле стектрейс)
6. В каком окружении случилось (что было вокруг)
Важные детали
* SQL-Запрос к базе, если упал он - должен быть приведён полностью в собранном виде.
* Логин пользователя и прочие объекты, которые могут быть важны: статья, кампания, канал и т.п.
* Браузер, устройство, куки и прочее.
* Фронт-энд машинку, реплику базы и т.п.
Транспорт
* Фронты, если случается 500 - создают или дописывают (append) в файлик прям свёрстанную длинную HTML-простыню с ошибкой.
* Раз в 2 минуты по крону на фронте - этот файлик куда-то перекладывается, например - в почту или ещё куда-то. И обнуляется.
* На случай глобальных поломок - отключаем дописывание в файлик, если он уже больше, чем 1МБ (настраиваемо).