Обновить

Инцидент-менеджмент с нуля: практический гайд для растущих команд

Уровень сложностиСредний
Время на прочтение8 мин
Охват и читатели12K
Всего голосов 23: ↑20 и ↓3+20
Комментарии1

Комментарии 1

Артем, раз уж Вы ссылаетесь на ITIL не путайте пожалуйста понятия инцидент и проблема.

Инцидент - это незапланированное прерывание или снижение качества услуги (сервиса), а проблема - причина возникновения одного или нескольких инцидентов. Поэтому если по SLA у нас вход в систему 5 секунд, а окно авторизации висит уже 7 - это инцидент. Также как и сбой у одного только пользователя.

В продуктовом подходе, в отличие от сервисного, оперируют понятием баг. Вот тут два понятия заменяются одним.

Важно понимать также что разбор полетов (post mortem) ближе к практике управления проблемами, хотя и в управлении инцидентами применяется, но для критических инцидентов (major incidents), поскольку уводит от цели практики - скорейшее восстановление, а не предотвращение повторений (для управления проблемами).

Инцидент может быть закрыт как обходным решением (workaround), так и постоянным. Вот тут для сравнения с продуктовым подходом вместо будет упомянуть про технический долг, как совокупность этих обходных решений или компромиссов, которые важно фиксировать на досках в виде отдельных элементов работы. Т.е. при решении бага с помощью обходного решения здорово создавать связанную сущность, как тех. долг. В то время как при постоянном таких телодвижений не потребуется.

Если будет интерес продолжить, то мы друг в друга в контактах LinkedIn 😀

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации