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

[sergekby]

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

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

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

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

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

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

[antivoland]

Совсем не раскрыта тема компенсации "24/7 доступность". Или она перекрывается через "не дозвонился за 20 минут - следующий в цепочке"?

При таком построении "следующий" закончится в какой-то момент.

В целом статья отличная.