Как мы забыли про релиз фриз и выкатили новый функционал, когда не надо
А началось все с того, что мы почти полгода готовили переход с html на react. Переход на новый технологический стек должен был быть одновременно с переходом на новый дизайн всего сервиса. Также под один релиз мы решили впихнуть еще и переход с одной версии Jango на другую — ну что мелочиться то)) Читая это сейчас, любой нормальный руководитель разработки просто бы ужаснулся и сказал, что так делать не стоит. Но в моменте мы все были настолько увлечены и хотели порадовать пользователей обновленной версией, что про расчет рисков никому, собственно, думать не хотелось. Как в мультике Смешарики, где Крош говорит: «Давайте о скучном думать не будем!».
Еще один из факторов, который точно забыла команда разработки, — сезонность в использовании сервиса пользователями. Наш сервис предоставляет автоматизацию процесса поиска работы, поэтому им чаще всего пользуются весной и осенью. Мы поставили дату релиза на утро 1 апреля.
1 апреля — Международный день смеха, вот только к концу дня нам было не до смеха. После релиза сервис упал полностью. Пользователи не могли войти, все авто рассылки обвалились. Когда на следующий день все по-прежнему не работало, команда маркетинга уже экстренно выпустила коммуникацию о проблемах на основном лендинге и в рассылке, добавив контакт для экстренной связи.
Последующие две недели были тяжелыми. Откатить до старой версии не получалось, поэтому приходилось разбираться, где именно произошел сбой «наживую». И когда нам показалось, что мы восстановились, начиналась локальная деградация по всему сервису. Тестировщики фиксировали баги нон-стоп, заваливая и без того загруженную разработку. А пользователи в это время уже кипели праведным гневом.
Через 2 недели кропотливой работы сервис восстановился и начал работать. Это стоило очень много нервов и седых волос в бороде у технического директора. Опыт получился сложный, но поучительный.
С тех пор мы стараемся улучшать процессы и ввели релиз-фризы. Теперь в пик сезона мы стараемся не делать релизы нового функционала, который касается ключевой активности. А также делаем микросервисную архитектуру, чтобы достигать большей устойчивости и определенной антихрупкости. Иногда, конечно, мы увлекаемся и снова ставим плановую дату релиза на пик сезона, но вовремя тормозимся и вспоминаем, что новый функционал — это, конечно, хорошо, но не подвести пользователей в период, когда они ищут работу, обеспечить их стабильно и предсказуемо работающим ключевым сервисом на много важнее!
