Как «неудавшийся» релиз привёл к изменению в процессах
– рассказывает Екатерина Ремизова, наш директор по качеству

Безмятежное начало
Мы работали над классным проектом – приложением для online-тренировок. Под него собрали команду из аналитика, дизайнера, backend-, Android- и iOS-разработчиков, QA-специалиста и проектного менеджера. Первый релиз состоялся 20 октября. И только за первый месяц работы уже было 50+ тысяч скачиваний.

«А всё, а всё! А надо было раньше…» – никто тогда не знал
К Новому году мы с клиентом запланировали релиз дополнительных функций приложения и публикацию нового курса тренировок, рекламная кампания которого уже была в разгаре. Для самых быстрых предложили скидки, поэтому много пользователей уже были на низком старте. Всё подготовили, осталось дождаться окончания проверок от AppStore и Google Play. И вот 30 декабря проверки закончились, а на 31 декабря клиент запланировал релиз – ему хотелось побыстрее запустить его. Мы пошли у него на поводу...

Запах мандаринов покинул чат
Вечер 31 декабря, обновление выпущено в прод, команда расслабилась и ушла нарезать оливье и смотреть «Иронию судьбы». В 19:54 появилось первое предупреждение о высокой нагрузке на базу данных. А спустя ещё час некоторые видео перестали открываться или прогружались долгое время. Суммарные загруженные данные вышли за предел, который был заложен в приложении и учтён в аналитике.
Вся команда была на телефонах, бросила дела и начала разбираться в ситуации. Backend-разработчик связался с DevOps и предложил донастроить кеширование на стороне СУБД.В 21:53 поняли, что дело плохо: на экранах пользователей появилась ошибка. В итоге за несколько часов до Нового года мы получили срыв запуска продукта.

Как потушили пожар
В 22:46 команда настроила кеширование и увеличила производительность сервера. Приложение начало работать. Но мы понимали, что это временно: принятые меры не решали проблему. Поэтому Новый год все члены команды встречали у компьютера, чтобы подключиться к работе в нужный момент. А с 1 января приступили к исправлению ситуации и подкорректировали код. До 5 января мониторили работу продукта: в процессе выскакивали проблемы с кешем Redis. После этого продукт работал без инцидентов, а мы смогли выдохнуть и начать работу над ошибками.