Как лечить 500тки

Ключевой подход

Минимизировать стоимость поиска, воспроизведения и лечения ошибок

Для этого:

1. Репорты по 500-ткам должны быть доступны всем, лежать в каком-то лёгком доступе.

2. Репорты должны быть максимально-полными.

3. Репорты должны быть свежими.

БОНУСОМ:
На бетах - эти 500тки показываются прямо в окно браузера, чем очень облегчают отладку.

Логирование

Идеальная ситуация - когда из репорта 500-тки ты понимаешь, что произошло, почему и что нужно исправить.

в общем - не стоит скупиться на добавление данных в репорт 500.

Чего надо написать:

1. Что случилось.

2. Где случилось (в смысле страница или что-то в этом роде)

3. У кого случилось (пользователь, роль, и прочие важные данные (граждантство например, включена монетизация и т.п.)

4. С чем случилось (статья? страница?)

5. Как случилось (в смысле стектрейс)

6. В каком окружении случилось (что было вокруг)

Важные детали

* SQL-Запрос к базе, если упал он - должен быть приведён полностью в собранном виде.

* Логин пользователя и прочие объекты, которые могут быть важны: статья, кампания, канал и т.п.

* Браузер, устройство, куки и прочее.

* Фронт-энд машинку, реплику базы и т.п.

Транспорт

* Фронты, если случается 500 - создают или дописывают (append) в файлик прям свёрстанную длинную HTML-простыню с ошибкой.

* Раз в 2 минуты по крону на фронте - этот файлик куда-то перекладывается, например - в почту или ещё куда-то. И обнуляется.

* На случай глобальных поломок - отключаем дописывание в файлик, если он уже больше, чем 1МБ (настраиваемо).