Нажать нельзя подождать

Когда выкатывать релиз? Да кто его знает. Зато мы на своем опыте поняли, когда этого делать точно не стоит. Сегодня об этом расскажет Оксана Новицкая, директор по развитию Облакотеки. И заодно объяснит, как снизить риск того, что все пойдет не по плану.

У нас нет тяжелого этапа согласований релизов с протоколами, обоснованиями и подписями. Но есть четкий ритм: обновления выходят примерно раз в две недели.

Дату, как правило, определяет руководитель команды разработки, но не единолично. Она согласовывается с продуктовыми владельцами, в том числе со мной. Это важный момент. Я смотрю не только на техническую сторону, но и на контекст: кто из клиентов может почувствовать изменение, нет ли у них сейчас горячего периода (закрытие месяца, например).

Когда лучше подождать?

Это самая живая часть нашей практики, потому что ответы мы получили не из учебника.

Пятница. Это почти табу. Если что-то пойдет не так, то в субботу команде придется весь день тушить пожары. Классика жанра, которую хочется избежать.

Перед горячим периодом (в том числе и у клиентов). Конец месяца, праздники, высокая нагрузка у партнера — не время для экспериментов с продакшном.

Когда мониторинг показывает «что-то красное». Добавлять изменение поверх нестабильной системы — все равно что чинить машину на ходу. Сначала стабилизируем, потом двигаемся.

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

Небольшие исправления, не затрагивающие глобальную логику, могут выходить чаще и без оповещений клиентов.

Зачем нужен план отката?

Конечно, перед выкаткой на релиз мы бэкапим все, что может быть затронуто. Базы, сервисы, микрофронты и так далее.

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

Как минимизируем риски?

Со временем у нас выработалось несколько привычек:

Сначала песочница. Любое изменение проходит через тестовую среду, близкую к боевой. Соблазн «да там ничего сложного» велик, но мы его давим. Есть, конечно, некоторые моменты, которые мы не можем воспроизвести в песочнице, но это какие-то совсем исключительные случаи.

Обязательная проверка в релизе основных функциональных элементов. Сразу после выкатки релиза все проверяем. Не обновили и пошли спать, а запустили автотесты, проверили все элементы, отследили отсутствие ошибок в логах.

Клиент всегда знает заранее. О дате и времени выкладки обновлений обязательно оповещаем. Клиент, которого предупредили, реагирует совсем иначе, чем тот, которого просто накрыло.

Хороший процесс управления изменениями — это не про бюрократию, а про понимание: что меняем, почему сейчас, что делаем, если все пойдет не так. Когда это понимание есть, то можно двигаться быстро и не бояться каждого деплоя .

#Оксана_объясни