Выручка сети не равно прибыль управляющей компании, не говоря уже о приоритетах фич перед техдолгом для бизнеса.
Стартапу на этом этапе развития жизненно важен быстрый рост и фичи, а не стабильность или производительность софта, и монолитная архитектура в такое время вполне разумное решение.
А толковый СТО у нас появился в 2017м, после чего почти на год была заморожена разработка большинства продуктовых фич и мы активно приводили в порядок то, что написали за предыдущие годы. Думаю, об этом Паша еще расскажет в следующих статьях.
Напомню, что это был 2011й год, стартап без денег, и пара программистов, вписавшихся работать за долю в бизнесе: не до найма СТО было))
Конечно, тогда уже многие в индустрии догадывались что хранимки с бизнес-логикой это зло, но не все. А некоторые и сейчас такой подход продвигают…
Весь мой опыт разработки говорит ровно об обратном. Каждый раз проводить полный ручной регресс для большой системы просто нереально: он затягивается на дни, недели, а с учетом фикса багов — иногда и месяцы, и при этом благодаря человеческому фактору всегда что-то пропускается. Ручной тестировщик в этом процессе — самый ненадежный элемент просто потому что он человек)
Если все старые фичи и баги тестируются автоматически, то и пользователи их никогда снова не увидят. Ручное тестирование нужно только в исследовательской части, как я и написал выше: новые фичи, исследования безопасности и т.п.
В Додо, кстати, мы тоже проходили этот путь: была отдельная команда тестировщиков, которая целыми днями занималась регресом монолита, в результате чего релизы были раз в неделю по средам, а все наши франчайзи в этот день надевали шапочки из фольги и молились.
Да, автоматизация процессов тестирования требует намного более высоких скилов и дисциплины от разработчиков, но таков путь.
Вообще, если сервис активно разрабатывается, то единственный способ спать спокойно — это пресловутый CI/CD, и в нем просто нет места ручному тестированию, т.к. оно слишком медленное, но это тема для отдельной большой статьи.
1:3 — это ооочень старое «классическое» соотношение для аутсорс-разработки. В современной продуктовой разработке, когда ты можешь годами вкладываться в качество и автоматизацию, такое количество QA просто не нужно. В идеале все сервисы должны релизиться по зеленым тестам без ручного тестирования, а QA — заниматься тем, что написано в названии должности, т.е. обеспечением качества: выстраивать процессы и писать ту самую автоматизацию.
Ручное тестирование должно сводиться только к исследовательскому тестированию, а для него столько людей не нужно.
В реальности же есть несколько областей, где с автоматизацией пока сложно: это в первую очередь мобильные приложения и иногда веб-UI. Остальное мы как правило релизим без тестирования руками, а автотесты пишут сами разработчики.
Насколько я помню, мы вляпывались только в лимиты по Resource Manager API, но это не фатально.
По остальным вроде пока все ОК, по необходимости договариваемся с Ажуром и хватает одной подписки.
За всех не скажу, но в моем случае это было ощущение того что «здесь я неплохо понимаю и умею, пилить фичи уже скучно, да и без меня полно народу — справятся» и «там у этих ребят Дикий Запад, все в огне, есть где развернуться». Мне нравится заниматься проблемами, решение которых потенциально может принести огромный профит.
А «админскую» часть здесь я воспринимаю скорее как неизбежное зло для того чтобы получить знания, необходимые для нанесения непоправимой пользы окружающим. Хотя конечно иногда возникают мысли «зачем я в это все вляпался?»)
Полностью согласен, погорячился.
Идея была в том, что мы получили от новой команды то, что ожидали — и это круто.
При этом у меня лично возникла другая проблема: с одной стороны за суммарно полтора года я капитально растерял навыки работы в привычной среде .NETа, а с другой стороны стал «SRE конкретного окружения конкретной компании» и понимаю что мне еще расти и расти. И это вызывает серьезный психологический дискомфорт.
Легко)
Само приложение и бекенд к нему выкатывается задолго до публичного анонса: распространяется на небольшую группу лояльных бета-пользователей и постепенно дорабатывается. А в какой-то момент бизнес принимает решение что все ОК – и публикует пост в соцсетях с призывом скачать приложение и получить пиццу в подарок за первый заказ. Profit.
Это сейчас мы все умные и синхронизируем все маркетинговые активности со всеми причастными техническими командами, оцениваем нагрузку и т.п., а тогда, увы, этого не было. Плюс никто не ожидал такого наплыва пользователей именно в приложение: никому и в голову не могло прийти что через несколько месяцев оно станет популярнее сайта.
Было бы очень интересно почитать, как это организовано — мы тоже рано или поздно придем к другим облакам. Но и собирать логи и прочую аналитику в условный Эластик после Azure Data Explorer уже кажется крайне плохой идеей)
Не нужно возводить все в абсолют.
Ограничение внешней системы можно и прокомментировать, только в случае с прикладным кодом таких систем и таких ограничений относительно мало, а в случае с инфраструктурным — на каждом шагу.
Хотя в примере с OpenShift я бы просто вынес «24» в константу с именем OpenShiftMaxNameLength и не потерял бы ничего. Магические константы это еще один code smell наравне с повсеместными комментариями.
И при этом вы можете легко переключить весь трафик только на Ажур или только на AWS если у второго облака что-то сломается? Или в разных облаках просто разные части системы?
По моему опыту, если хочется получать максимум пользы от облачной инфраструктуры и при этом не платить за это космические деньги, то ты вынужден использовать специфичные для конкретного облака сервисы и писать заточенный специально под них код.
Это касается и прикладного софта (мы используем CosmosDB, Kusto, менеджед MySQL базы), так и инфраструктурного: например когда мы брали в стек тот же Terraform, то мечтали абстрагироваться от облачного провайдера, но по факту это конечно не так — для развертывания той же инфраструктуры в другом облаке придется очень много переписывать.
Если это ограничение техническое и кроется в сторонней системе, а ты пишешь какой-нибудь баш-скрипт (что очень часто встречается как раз в мире инфраструктуры или каких-то низкоуровневых языках/доменах), то да, комментарий здесь будет полезен. Хотя даже тут он рано или поздно устареет, но все последующие поколения разработчиков об этом не узнают.
А вот если ограничение бизнесовое, а пишешь ты на полноценном ЯП, то комментарий тут скорее вреден: гораздо правильнее написать понятный тест, описывающий человеческим DSL'ем конкретный бизнесовый сценарий. И когда это ограничение поменяется, то вместе с ним разработчик будет вынужден поменять и тест, объясняющий зачем это здесь.
Т.е. есть множество способов решить ту же проблему, которую решают комментарии, но без их недостатков. Но чем дальше ты уходишь от высокоуровневых абстракций и чем больше у тебя неподвластных тебе ограничений, тем сложнее эти способы применять, имхо.
Саша, привет!
Проблемы, конечно, не в одном трекере — с него начали т.к. он один из самых критичных для бизнеса. Будучи выделенным в полноценный микросервис он прекрасно держит нагрузки.
Основные проблемы описаны в начале статьи отдельным списком: единая база, очень сложный процесс релиза, сильная связность кода разных сервисов внутри монолита и как следствие большое количество критичных багов, регулярно ломающих всю систему.
Например, сложности возникают в тот момент когда два десятка сервисов (в статье упомянуты только самые крупные) ходят в одну и ту же неоптимальную для каждого из них базу и она становится единой точкой отказа. При этом в ней появляются огромные таблицы типа списка заказов с кучей полей, бОльшая часть из которых нужна лишь какому-то небольшому количеству клиентов.
И кеши тут уже не сильно помогут, особенно когда критична скорость обновления и консистентность данных: в идеале они должны прилететь на соответствующий планшет до того как пиццамейкер физически передаст раскатанное тесто со станции раскатки на станцию начинения.
Отдельная беда — когда какой-нибудь из сервисов неудачным запросом лочит лишние строки в этой гигантской таблице с заказами: вся система начинает складываться как карточный домик.
Кстати, от Редиса, который у нас используется повсеместно (на картинках в статье далеко не все уместилось), мы в последнее время отказываемся, т.к. с ним внезапно всплывает много проблем: SLA в Ажуре всего 99.9, высокая стоимость, плюс куча способов выстрелить себе в ногу, чем регулярно пользуются разработчики (например случайно засовывая туда большие объекты в перемешку с мелкими).
Ну и не забывай что это все создавалось не в 2020м году крупной международной компанией, а в 2011м в режиме стартапа, когда было важно не держать 5к RPS, а быстро реализовать критичные для выживания бизнеса фичи)
О тестах конечно задумывались. Но построить полноценную систему нагрузочного тестирования для системы таких размеров — это несколько месяцев работы опытной команды (чем в итоге все и закончилось: наняли PerformanceLab на старте, а затем постепенно прокачали экспертизу внутри) и много миллионов рублей на железо. Увы, тогда таких ресурсов не было.
Были только написаные на коленке тесты, которые создавали заказы через апи для мобильного приложения на дев-стендах и все. А ведь создание заказа, как ниже отписались — это только небольшая часть реальной нагрузки, поэтому доверия к тем тестам было немного.
Это как в шутке: лучше быть здоровым и богатым, чем бедным и больным. Увы, в реальной продуктовой компании все обычно сложнее и приходится выбирать: доделывать функционал, на который будет направлена уже оплаченная несколько месяцев назад реклама на федеральном ТВ или учиться грамотно писать лоадтесты (разработчиков тогда было в несколько раз меньше чем сейчас).
В тот раз риски упасть под нагрузкой недооценили, бывает.
«С помощью тестов производительности провели анализ уязвимостей.» — тут явно автор напутал.
Анализ уязвимостей, aka Penetration test мы делали перед ФРК, а вот лоад-тесты лежали на полке с момента запуска мобильного приложения шестью месяцами ранее. На следующий день после падения эти тесты достали, актуализировали и стали использовать для оценки состояния DodoIS. Но у них было несколько фатальных недостатков и еще через пять месяцев мы их окончательно выкинули и позвали PerformanceLab, чтобы сделать хорошо.
Стартапу на этом этапе развития жизненно важен быстрый рост и фичи, а не стабильность или производительность софта, и монолитная архитектура в такое время вполне разумное решение.
А толковый СТО у нас появился в 2017м, после чего почти на год была заморожена разработка большинства продуктовых фич и мы активно приводили в порядок то, что написали за предыдущие годы. Думаю, об этом Паша еще расскажет в следующих статьях.
Конечно, тогда уже многие в индустрии догадывались что хранимки с бизнес-логикой это зло, но не все. А некоторые и сейчас такой подход продвигают…
Если все старые фичи и баги тестируются автоматически, то и пользователи их никогда снова не увидят. Ручное тестирование нужно только в исследовательской части, как я и написал выше: новые фичи, исследования безопасности и т.п.
В Додо, кстати, мы тоже проходили этот путь: была отдельная команда тестировщиков, которая целыми днями занималась регресом монолита, в результате чего релизы были раз в неделю по средам, а все наши франчайзи в этот день надевали шапочки из фольги и молились.
Да, автоматизация процессов тестирования требует намного более высоких скилов и дисциплины от разработчиков, но таков путь.
Вообще, если сервис активно разрабатывается, то единственный способ спать спокойно — это пресловутый CI/CD, и в нем просто нет места ручному тестированию, т.к. оно слишком медленное, но это тема для отдельной большой статьи.
Ручное тестирование должно сводиться только к исследовательскому тестированию, а для него столько людей не нужно.
В реальности же есть несколько областей, где с автоматизацией пока сложно: это в первую очередь мобильные приложения и иногда веб-UI. Остальное мы как правило релизим без тестирования руками, а автотесты пишут сами разработчики.
По остальным вроде пока все ОК, по необходимости договариваемся с Ажуром и хватает одной подписки.
А «админскую» часть здесь я воспринимаю скорее как неизбежное зло для того чтобы получить знания, необходимые для нанесения непоправимой пользы окружающим. Хотя конечно иногда возникают мысли «зачем я в это все вляпался?»)
Идея была в том, что мы получили от новой команды то, что ожидали — и это круто.
При этом у меня лично возникла другая проблема: с одной стороны за суммарно полтора года я капитально растерял навыки работы в привычной среде .NETа, а с другой стороны стал «SRE конкретного окружения конкретной компании» и понимаю что мне еще расти и расти. И это вызывает серьезный психологический дискомфорт.
Само приложение и бекенд к нему выкатывается задолго до публичного анонса: распространяется на небольшую группу лояльных бета-пользователей и постепенно дорабатывается. А в какой-то момент бизнес принимает решение что все ОК – и публикует пост в соцсетях с призывом скачать приложение и получить пиццу в подарок за первый заказ. Profit.
Это сейчас мы все умные и синхронизируем все маркетинговые активности со всеми причастными техническими командами, оцениваем нагрузку и т.п., а тогда, увы, этого не было. Плюс никто не ожидал такого наплыва пользователей именно в приложение: никому и в голову не могло прийти что через несколько месяцев оно станет популярнее сайта.
Ограничение внешней системы можно и прокомментировать, только в случае с прикладным кодом таких систем и таких ограничений относительно мало, а в случае с инфраструктурным — на каждом шагу.
Хотя в примере с OpenShift я бы просто вынес «24» в константу с именем OpenShiftMaxNameLength и не потерял бы ничего. Магические константы это еще один code smell наравне с повсеместными комментариями.
По моему опыту, если хочется получать максимум пользы от облачной инфраструктуры и при этом не платить за это космические деньги, то ты вынужден использовать специфичные для конкретного облака сервисы и писать заточенный специально под них код.
Это касается и прикладного софта (мы используем CosmosDB, Kusto, менеджед MySQL базы), так и инфраструктурного: например когда мы брали в стек тот же Terraform, то мечтали абстрагироваться от облачного провайдера, но по факту это конечно не так — для развертывания той же инфраструктуры в другом облаке придется очень много переписывать.
А вот если ограничение бизнесовое, а пишешь ты на полноценном ЯП, то комментарий тут скорее вреден: гораздо правильнее написать понятный тест, описывающий человеческим DSL'ем конкретный бизнесовый сценарий. И когда это ограничение поменяется, то вместе с ним разработчик будет вынужден поменять и тест, объясняющий зачем это здесь.
Т.е. есть множество способов решить ту же проблему, которую решают комментарии, но без их недостатков. Но чем дальше ты уходишь от высокоуровневых абстракций и чем больше у тебя неподвластных тебе ограничений, тем сложнее эти способы применять, имхо.
Проблемы, конечно, не в одном трекере — с него начали т.к. он один из самых критичных для бизнеса. Будучи выделенным в полноценный микросервис он прекрасно держит нагрузки.
Основные проблемы описаны в начале статьи отдельным списком: единая база, очень сложный процесс релиза, сильная связность кода разных сервисов внутри монолита и как следствие большое количество критичных багов, регулярно ломающих всю систему.
Например, сложности возникают в тот момент когда два десятка сервисов (в статье упомянуты только самые крупные) ходят в одну и ту же неоптимальную для каждого из них базу и она становится единой точкой отказа. При этом в ней появляются огромные таблицы типа списка заказов с кучей полей, бОльшая часть из которых нужна лишь какому-то небольшому количеству клиентов.
И кеши тут уже не сильно помогут, особенно когда критична скорость обновления и консистентность данных: в идеале они должны прилететь на соответствующий планшет до того как пиццамейкер физически передаст раскатанное тесто со станции раскатки на станцию начинения.
Отдельная беда — когда какой-нибудь из сервисов неудачным запросом лочит лишние строки в этой гигантской таблице с заказами: вся система начинает складываться как карточный домик.
Кстати, от Редиса, который у нас используется повсеместно (на картинках в статье далеко не все уместилось), мы в последнее время отказываемся, т.к. с ним внезапно всплывает много проблем: SLA в Ажуре всего 99.9, высокая стоимость, плюс куча способов выстрелить себе в ногу, чем регулярно пользуются разработчики (например случайно засовывая туда большие объекты в перемешку с мелкими).
Ну и не забывай что это все создавалось не в 2020м году крупной международной компанией, а в 2011м в режиме стартапа, когда было важно не держать 5к RPS, а быстро реализовать критичные для выживания бизнеса фичи)
О тестах конечно задумывались. Но построить полноценную систему нагрузочного тестирования для системы таких размеров — это несколько месяцев работы опытной команды (чем в итоге все и закончилось: наняли PerformanceLab на старте, а затем постепенно прокачали экспертизу внутри) и много миллионов рублей на железо. Увы, тогда таких ресурсов не было.
Были только написаные на коленке тесты, которые создавали заказы через апи для мобильного приложения на дев-стендах и все. А ведь создание заказа, как ниже отписались — это только небольшая часть реальной нагрузки, поэтому доверия к тем тестам было немного.
Это как в шутке: лучше быть здоровым и богатым, чем бедным и больным. Увы, в реальной продуктовой компании все обычно сложнее и приходится выбирать: доделывать функционал, на который будет направлена уже оплаченная несколько месяцев назад реклама на федеральном ТВ или учиться грамотно писать лоадтесты (разработчиков тогда было в несколько раз меньше чем сейчас).
В тот раз риски упасть под нагрузкой недооценили, бывает.
Анализ уязвимостей, aka Penetration test мы делали перед ФРК, а вот лоад-тесты лежали на полке с момента запуска мобильного приложения шестью месяцами ранее. На следующий день после падения эти тесты достали, актуализировали и стали использовать для оценки состояния DodoIS. Но у них было несколько фатальных недостатков и еще через пять месяцев мы их окончательно выкинули и позвали PerformanceLab, чтобы сделать хорошо.