Комментарии 20
К новому году команда запланировала релиз новых фич и публикацию нового курса тренировок
Это, похоже, была первая ошибка. Знающие люди такое не то что на Новый Год, а даже просто на пятницу никогда не планируют :)
Что в итоге мы изменили у себя в процессах
забавно что я работал в компании которая ходит по кругу вокруг этих косяков
1) начинали они также как описанный кейс
2) ввели все исправления предложенные вами
3) начали отменять эти "исправления" потому что они задерживают релизы, жрут время и деньги
4) идем к п.1 и далее по кругу
а релиз в пятницу это святое, также как бекапы (точнее их отсутствие/хранение рядом с бекапируемым сервисом/отсутствие тестов на развертывание/отсутствие плана восстановления)
ничто не меняется в этом мире..
Ввели архитектурный надзор в каждом производственном направлении разработки.
вы это отмените как только у архитектора и топовых сеньоров кончатся свободные слоты в календаре...sad but true
кстати добавте пункт в план — не выкатывать новый и очень востребованный (или существенно измененный) сервис сразу на 100% аудитории даже после всех тестов…
у меня прям свежее впечатление
(строгий b2b ентерпрайз внутри сложной бюрократической структуры) в пятницу потестили на 5 клиентах… в понедельник выкатили на 5000 человек… разом… люди в поддержке через полчаса начали писать что готовы из окна выпрыгивать уже от звонков из-за того что все работает не совсем так как клиенты думали и есть кейсы которые тестирование не покрыло… но фарш обратно уже не провернуть… я прям вспомнил молодость, затыкая дырки по горячему в проде
Плавный раскат через A/B тест под контролем метрик действительно спасает. Далеко не все проекты готовы к этому инфраструктурно и не все готовы за это платить.
Далеко не все проекты готовы к этому инфраструктурно и не все готовы за это платить.
1) далеко не все проекты архитектурно готовы к полноценному ревью кода
2) далеко не все проекты могут себе позволить нагрузочное тестирование
а про не готовы платить… ну вот тут заплатили за это таким авралом
это все понятно почему так происходит, просто надо стремится к идеалу
1) далеко не все проекты архитектурно готовы к полноценному ревью кода
2) далеко не все проекты могут себе позволить нагрузочное тестирование
Согласен и с первым и со вторым, но надо понимать что не всем это и нужно.
просто надо стремится к идеалу
А тут надо очень аккуратно определять что мы делаем и зачем. Делая Опель не нужно пытаться получить качество Мерседеса, а делая Мерседес E класса не нужно пытаться сделать Майбах. Потому что у всего есть своя цена, и не всем нужно платить за Майбах. Нужно управлять качеством и понимать что магии за 3 рубля не бывает. Есть решения, есть затраты и прибыль, и куча ситуаций когда понятно как, но по деньгам продукт не вывезет.
конечно
у сожалению мое текущее nda не позволяет мне привести очень жизненный пример на тему "не всем это нужно"
скажем так произошла авария, и из за того что сервис был неважный, качество никому не нужно, тестирование тоже и т.п. были потеряны практически все данные внутри него, а в процессе восстановления данных часть данных не может быть восстановлена правильно потому что архитектуру делали какието наркоманы… ну прально этож не майбах ;)
Есть решения, есть затраты и прибыль, и куча ситуаций когда понятно как, но по деньгам продукт не вывезет.
ну как грится, не можешь… ть не мучай попу.
С проблемой нехватки слотов у архитекторов/senior мы тоже сталкивались. Но процедура проходит по новым процессам железно, не отменяем.
А замечание про выкатку на ограниченную аудиторию дельное. Спасибо!)
Позвольте свои мнение на ваше "пике":
0. Никогда не релизиться, если на дату релиза, + несколько следующих дней, у ключевых сотрудников есть планы. Вижу как вы осознали это через боль.
1. Ответы на запросы могут включать дополнительные сущности, просто вы, на тот момент, это реализовали некоррекно. Посмотрите в сторону GraphQL, очень распространенное решение, в котором из коробки есть возможность в одном запросе вернуть все что нужно. Если они смогли - и вы у себя сможете.
2. Тут я вижу проблему в отсутствии нагрузочного тестирования. Субъективно - если у вас клиентов больше пару сотен, это уже мастхев. Ну вы уже внедрили, да.
3. Извечная проблема инвалидации кэша, вроде как волшебной таблетки тут нет, зато есть куча чужих опытов, на которых можно научиться делать как нужно. Прогрев кеша решает только часть проблем, при росте сущностей в проекте, он не поможет.
Вообще было бы интересно посмотреть на цифры - потеряли ли вы клиентов, количество обращений в ТП лавинообразно выросло и т.п., на чем отразились эти неправильные решения, иначе не совсем понятно в чем тут "пике"? Плохие релизы бывают у всех =D
Вопрос в том какой это продукт и какая фаза его развития. Когда это новый продукт в стадии начала стартапа и пользователей мало, можно релизить когда хочешь, перед отпуском, во время, можно положить продукт на денёк, ничего страшного. Потому что в начале важна скорость разработки и обратной связи, а не надёжность, с ростом продукта растут и требования к надёжности. А надёжность стоит довольно дорого, именно поэтому от неё проще отказываться на ранних этапах. Да потом завести её сложнее, но зато потом она будет заводиться в зарабатывающий продукт, который будет окупать затраты на достижение этой надёжности. Инвестору проще платить за проверку гипотезы нового продукта тогда, когда плата меньше. Надёжность почти никогда не входит в ценность раннего этапа.
Раскатывать релиз на 5% трафика, не?
Backend-разработчик должен был отстоять свое мнение, привести аргументы. А еще лучше — совместно с командой сформировать плюсы и минусы двух решений, возможные риски
Это похоже на finger pointing, что не конструктивно.
Во-первых, авария это штука вероятностная, и поэтому она неизбежна. Ключевых вопросов три: как снизить риски ее возникновения, как минимизировать последствия если когда они сработают и где взять на это деньги как не продолбать впустую полученный опыт. Команда, у которой ещё не было нормальных аварий, это ньюбы.
Во-вторых, в любой нетривиальной системе у аварии не бывает какой-то одной причины, это всегда стечение разных обстоятельств. Конечно, есть соблазн тыкнуть пальцем в крайнего кто был ближе к рубильнику и на этом остановиться. Но такой подход не вскроет корней и в следующий раз опять все повторится. Сотрудники же вместо решения проблем начинают от них дистанцироваться - если крайний найден, то остальные могут расслабиться или творить ещё какие-нибудь дичь. То факт, что менеджмент продолжал дрючить разработку во время праздников, когда ситуация с обновлением была уже определена, тому хороший пример.
Мы в компании развиваем культуру качества, когда открыто говорим об ошибках без последующих наказаний и каких-то санкций. И по поводу “отстоять свое мнение, привести аргументы” — это мнение разработчика. Собственная ретроспектива.
Согласна с вами, что одной причины аварий/неудачных релизов не бывает, это чаще всего сочетание причин, упущений на разных этапах. Здесь как раз упущения были на нескольких направлениях.
Если бы не усложнение иерархии новых реальных тренировок, то система возможно выдержала бы нагрузку.
Если бы примеры данных актуализировали раньше, то возможно проблему бы выявили уже на тестировании.
Если бы изначально правильно выстроили запросы, то возможно усложнение иерархии данных не положило приложение.
Если бы сразу провели нагрузочные испытания, то проблему выявили бы раньше, а не на проде.
Ключевое слово “возможно”, сейчас мы это уже никак не можем проверить. И наша главная цель — снизить вероятность повторения подобных ситуаций. Для этого мы исправляем процессы, а не назначаем виновных.
Что нужно было сделать на самом деле:
- Поговорить с клиентом и выкатывать релиз после праздников, когда вся команда будет на рабочем месте.
- Перед релизом на широкую аудиторию проводить нагрузочное тестирование, чтобы понимать, сколько пользователей потянет текущая инфраструктура. При внезапном взлёте скачиваний, например, где-то была реклама этого приложения, иметь план по оперативному увеличению ресурсов.
- Выкатить приложение в прод с новым функционалом, но скрыть его временно от пользователя. Подтянуть до нужной версии инфраструктуру. Проверить, что функционал успешно работает.
- Постепенно включать новый функционал новым группам пользователей и смотреть, как всё работает. Смотреть системы мониторинга и анализировать возможные узкие места. Через несколько этапов включить функционал всем пользователям.
- Нанять на работу DBA, т.е. администратора баз данных, который будет находить все кривые и большие запросы к базе данных и будет бить по рукам отдельных разработчиков. Базами данных и их оптимизацией должны заниматься DBA, а не backend разработчик.
Часть пунктов из вашего списка как раз у нас в выводах.
Про плавную раскатку согласна. Но не всегда ее можно провести. И даже не всегда есть возможность отказаться от релиза в выходной. Есть разные продукты и требования бизнеса. Есть продукты, когда релиз проводится только в выходной и ночью. Потому что есть определенные требования к доступности сервиса.
То есть все пункты здравые и нужно “примерять” их к конкретному продукту для минимизации рисков при проведении релизов.
Проводим ревью разрабатываемой архитектуры на контрольных точках проекта, которые определяют PM.
Архитектура проекта закладывает ещё до начала работ на нём. Делает это системный архитектор или группа из самых опытных разработчиков + кто-то от бизнеса. Никакой PM в середине проекта при всё своём желании не сможет как-то существенно эту архитектура изменить.
Большинство проектов чаще всего имеют организационные, а не технические проблемы, поэтому имеет смысл сосредоточиться на улучшении рабочего климата, уменьшении бюрократии, упрощении бизнес процессов и налаживании постоянного диалога внутри компании.
Когда неудачные решения в IT-проекте приводят к крутому пике: как не допустить катастрофы