День инцидентов
Бывают такие дни, когда по ряду проектов одновременно возникают инциденты. Чем больше релизов в один день - тем сильнее вероятность наступления этого прекрасного дня. С другой стороны - чем меньше релизов - тем меньше полезных фич получает бизнес. 🤔
Я сторонник частых релизов и обновлений по проектам. И если инциденты можно оперативно разрулить без ущерба для бизнеса - предлагаю в такие моменты выстраивать обратную связь по инцидентам в очередь и методично их решать.
Если критичность инцидента высока, то здесь без вариантов - откатываемся на предыдущую версию. Но, если можно в разумное время сделать хотфиксы и оставить обновление с новыми фичами - предпочитаю этот вариант.
Как же сводить инциденты к минимуму, а если они случились - быть максимально готовым?
- Релизный день.
Есть мнение, что релизы лучше проводить в четверг вечером, чтобы в пятницу можно было в рабочем режиме или устранить инциденты, или откатиться (пока не поздно) на предыдущую версию. Релизный день для разных бизнесов может быть свой, а иногда их может быть 2 или 3. Редко кто релизится каждый день - для этого нужно иметь армию разработчиков и девопс-инженеров. - Поспешай не торопясь.
Не выпускать большие релизы перед возможным отсутствием ключевых специалистов по проекту. Как говорится - лучше подстраховаться, если, конечно у Вас нет отдела из разработчиков-ниндзя 🥷, который решает инциденты. - Тестировать, тестировать и ещё раз тестировать. В наших проектах мы проводим 2 уровня тестов - на стороне разработчиков и на стороне PM. Тестировать нужно не только изменённый фунционал, но и зависимости, которые он затрагивает. В таких кейсах помогают логические схемы по функционалу проекта.
- Отдыхать.
Чем лучше себя чувствует проектная команда - тем меньше она косячит. - Рефлексировать.
После устранения инцидентов обязательно делать выводы - что мы будем делать или не делать в дальнейшем, чтобы исключить подобные ситуации.