Комментарии 5
очитался: shit manager. Мастер над инцидентами
Годно, совпадает с нашим опытом:
Мы начинали вести постмортемы на wiki, со скриншотами и развернутым описанием — показалось слишком громоздко. Банально никто их потом не читал.
Пришли к выводу, что самое ценное в этой практике — план действий, позволяющий решить проблему системно и избежать повторения.
Сейчас на каждую аварию мы заводим LT/US с датой, контуром и кратким описанием проблемы. В рамках нее создаем задачи на:
1. Временное решение (чтобы быстро исправить ситуацию)
2. Настройку / доработку мониторинга (если мы проморгали проблему)
3. Исследование корневой причины
4. Задачи для системного решения проблемы (по результатам исследования)
Пару раз натыкались на повторение проблемы, так как не успевали реализовать системное решение (откладывали из-за недостатка времени). Это всегда очень обидно :)
Мы начинали вести постмортемы на wiki, со скриншотами и развернутым описанием — показалось слишком громоздко. Банально никто их потом не читал.
Пришли к выводу, что самое ценное в этой практике — план действий, позволяющий решить проблему системно и избежать повторения.
Сейчас на каждую аварию мы заводим LT/US с датой, контуром и кратким описанием проблемы. В рамках нее создаем задачи на:
1. Временное решение (чтобы быстро исправить ситуацию)
2. Настройку / доработку мониторинга (если мы проморгали проблему)
3. Исследование корневой причины
4. Задачи для системного решения проблемы (по результатам исследования)
Пару раз натыкались на повторение проблемы, так как не успевали реализовать системное решение (откладывали из-за недостатка времени). Это всегда очень обидно :)
Филипп, привет.
Можешь рассказать что такое LT/US? И как вы приоритизируете эти задачи и трекаете их выполнение?
Можешь рассказать что такое LT/US? И как вы приоритизируете эти задачи и трекаете их выполнение?
Зарегистрируйтесь на Хабре , чтобы оставить комментарий
Зачем и как мы пишем постмортемы по критичным багам