Comments 54
Два очень важных вопроса пропущены.
1. Залатали героически и всё? Никаких изменений в архитектуре и структуре бизнеса? Там всё верно и ошибки были только в коде?
2. Как отразился сей героический апрельский поход на доходах IT спецов, какие бонусы, опционы и просто достойные плюшки последовали? Кроме авторской и R/D пиццы?
Есть конкретика по этим вопросам?
1. Залатали героически и всё? Никаких изменений в архитектуре и структуре бизнеса? Там всё верно и ошибки были только в коде?
2. Как отразился сей героический апрельский поход на доходах IT спецов, какие бонусы, опционы и просто достойные плюшки последовали? Кроме авторской и R/D пиццы?
Есть конкретика по этим вопросам?
1. Поменяли всё. Поменяли структуру, начали внедрять LeSS. Изменили продуктовую структуру. Определили, что будем отпиливать куски монолита в рамках бизнес-задач, изменения не идут без распила, сделали систему нагрузки (не идеально, потом переделали).
2. С точки зрения бонусов/наказаний не было ничего. Но когда увидели отношение ребят к делу, стало проще принимать решение о выдаче опционов.
2. С точки зрения бонусов/наказаний не было ничего. Но когда увидели отношение ребят к делу, стало проще принимать решение о выдаче опционов.
Т.е. люди работали бесплатно в выходной день? Про ТК РФ в додо, похоже, не слышали?
у них там немного другое отношение к работе, это больше как сообщество. она из лучших команд
Руководители не закладывают достаточно времени на закрытие техдолга и тестирование (в т.ч. нагрузочное) и подгоняет разработку, зато запускает рекламную компанию по ТВ (ну да, бабки-то рубить надо, новая тачка сама себя не купит). После чего эти же руководители истерят в рабочем чате про «военное положение» и «нет пути назад». А разработка выходит работать бесплатно в выходной день, что бы прикрыть собой горящие жопы руководства, разумеется «Никого не нужно было уговаривать или просить прийти в свой выходной день». Про нарушение законодательства я вообще молчу.
Да, одна из лучших команд, ничего не скажешь. Просто работа мечты.
Да, одна из лучших команд, ничего не скажешь. Просто работа мечты.
так не совсем корректно рассуждать не видя код. есть проблемы которые невозможно заранее предусмотреть независимо от того какие задачи поставлены. и если люди понимают что их зарплата зависит от этой рекламной кампании то можно и выйти разок исправить свои ошибки чтобы сэкономить деньги компании опцион которой ты держишь. есть компании где начальство отдельно работники отдельно, а есть где все в одной лодке
есть проблемы которые невозможно заранее предусмотретьЛюбые проблемы можно предусмотреть. В данном случае нагрузочное тестирование должно было выявить эти проблемы.
то можно и выйти разокЕсли компания не стала платить сотрудникам за работу (еще раз, это их обязанность по ТК РФ, они нарушили закон) даже в такой экстренной ситуации, я уверен на 100%, что это не единичный случай и никакой оплаты переработок по ТК РФ в компании не бывает.
исправить свои ошибки чтобы сэкономить деньги компанииОшибки значит свои, а деньги компании? Нет, ошибки тоже компании и ее руководства.
Любые проблемы можно предусмотреть
тут вопрос времени и усилий — иногда выглядит слишком дорого (не всегда это верная оценка, поэтому мы учимся предсказывать и считать выхлоп) или уже не успеешь, если есть дедлайн. Дедлайна в данном случае могло и не быть — плохая коммуникация и согласованность маркетинга и разработки — в этой части тоже были изменения
нагрузочное тестирование должно было выявить эти проблемы.
еще как должно было. Именно поэтому подход к нагрузочному тестированию был пересмотрен и нагрузка вышла на совершенно другой уровень — теперь она системная и стремится максимально походить на продакшн, чтобы выявлять возможные именно на продакшене проблемы
Нет, ошибки тоже компании и ее руководства
ошибок хватало везде, но если искать авторов ошибок вместо их устранения, толку будет мало. Поэтому было очень многое изменено на ВСЕХ уровнях и во всех взаимодействиях, хоть как-то участвовавших в ситуации
С чем связаны локи? У вас множественный конкурентный доступ к одной строке происходит? Если да, то с чем это связано? Какие-то счетчики на триггерах?
Причин может быть много. Приведу пару примеров.
Первый пример: В mysql innodb локи могут быть вызваны не только конкурентным доступом к одной строке. Достаточно сделать апдейт с условием не по уникальному ключу, а по какому-то другому индексируемому полю или по полю без индекса (не надо так). В случае с индексируемым полем мы получим gap lock, который может не дать в инсертить. Это можно отключить, но чтобы это сделать, надо понимать что ты делаешь.
Второй пример: тогда очень много интересного делалось в рамках одной транзакции. Даже вещи, которые могли бы перетерпеть eventual consistency происходили разом. И тут может стрельнуть AUTO-INC лок. Если транзакций много и все они хотят сделать инсерт в одну таблицу (а именно это они хотят сделать), то auto-inc заставляет их ждать своей очереди. Хотя это и не сильно страшно, если транзакции шустрые. Ужасное случится, если частота появления новых записей станет выше, чем частота вставки. Тогда проблема вырастет в снежный ком и посыпятся таймауты. Вот такие вещи хорошо или оптимизировать (например, заменить autoincrement на внешнюю генерацию Uuid) или делать асинхронными, а лучше и то и другое.
Первый пример: В mysql innodb локи могут быть вызваны не только конкурентным доступом к одной строке. Достаточно сделать апдейт с условием не по уникальному ключу, а по какому-то другому индексируемому полю или по полю без индекса (не надо так). В случае с индексируемым полем мы получим gap lock, который может не дать в инсертить. Это можно отключить, но чтобы это сделать, надо понимать что ты делаешь.
Второй пример: тогда очень много интересного делалось в рамках одной транзакции. Даже вещи, которые могли бы перетерпеть eventual consistency происходили разом. И тут может стрельнуть AUTO-INC лок. Если транзакций много и все они хотят сделать инсерт в одну таблицу (а именно это они хотят сделать), то auto-inc заставляет их ждать своей очереди. Хотя это и не сильно страшно, если транзакции шустрые. Ужасное случится, если частота появления новых записей станет выше, чем частота вставки. Тогда проблема вырастет в снежный ком и посыпятся таймауты. Вот такие вещи хорошо или оптимизировать (например, заменить autoincrement на внешнюю генерацию Uuid) или делать асинхронными, а лучше и то и другое.
И все же 100 заказов в минуту не похоже на highload. У вас сотни триггеров и десятисекундые транзакции на каждый заказ?
Как 100 заказов смогли оказаться highload наш инженер рассказывает чуть ниже. Если вам интересны ещё какие-то детали – пишите.
С помощью тестов производительности провели анализ уязвимостей.
Отсутствие performance-тестов стало приговором для нашей системы
Так проводились или нет? Или было отсутствие именно Load Testing ?
Взглянуть на метрики до-после в статье тоже было бы интересно.
«С помощью тестов производительности провели анализ уязвимостей.» — тут явно автор напутал.
Анализ уязвимостей, aka Penetration test мы делали перед ФРК, а вот лоад-тесты лежали на полке с момента запуска мобильного приложения шестью месяцами ранее. На следующий день после падения эти тесты достали, актуализировали и стали использовать для оценки состояния DodoIS. Но у них было несколько фатальных недостатков и еще через пять месяцев мы их окончательно выкинули и позвали PerformanceLab, чтобы сделать хорошо.
Анализ уязвимостей, aka Penetration test мы делали перед ФРК, а вот лоад-тесты лежали на полке с момента запуска мобильного приложения шестью месяцами ранее. На следующий день после падения эти тесты достали, актуализировали и стали использовать для оценки состояния DodoIS. Но у них было несколько фатальных недостатков и еще через пять месяцев мы их окончательно выкинули и позвали PerformanceLab, чтобы сделать хорошо.
Как же так вышло, что ожидая большой скачок заказов никто не задумался о нагрузочных тестах?
Профессионализм
Помноженный на:
— «у них там немного другое отношение к работе, это больше как сообщество»
— непомерный PR с хайпом
— неграмотное управление
Почему тогда «Профессионализм»? — коэффициент умножения просто меньше единицы…
Наверняка кто-то из админов или разрабов говорил про все проблемы руководству.
Я даже ответ знаю «Вы с ума сошли, мы ФРК запустили с завтрашнего дня — это огромные деньги — как хотите так и делайте, быстро!».
«зато пентесты провели»…
Проблема как всегда в том, что перед любыми действиями, ведущими к росту оборотов надо сначала разобраться с техническими долгами или хотя-бы поинтересоваться про все это у технарей, а потом уже «творить бизнес».
Но бизнес требует скорости, а тех.отдел, наоборот, ее снижает — это хорошо понимают менеджеры и управленцы, но плохо понимают почему.
Давно известно, что все можно ускорить — более хорошими, но более высокооплачиваемыми кадрами, масштабированием, аутсорсом и т.д. Но это все — затраты. Большинство тех, кто развивают свой бизнес ради того чтобы он работал и развивался, это понимают и считаются с этим. Те, кому надо хайпануть и быстро продаться на хайпе — нет. Они не хотят про будущее думать, не хотят платить за переработки и т.д. — им не интересно строить на долгий срок. Им надо как можно быстрее и дешевле залететь на пик стоимости и спихнуть это инвестору. Вот и ответ.
Расплата за тех.долги и увеличении скорости бизнеса при забивании на тех.отдел всегда факапы. Потом белые и пушистые менеджеры говорят технарям, чтобы те работали и разгребали все за них, потому как «это все вы виноваты» :)
Помноженный на:
— «у них там немного другое отношение к работе, это больше как сообщество»
— непомерный PR с хайпом
— неграмотное управление
Почему тогда «Профессионализм»? — коэффициент умножения просто меньше единицы…
Наверняка кто-то из админов или разрабов говорил про все проблемы руководству.
Я даже ответ знаю «Вы с ума сошли, мы ФРК запустили с завтрашнего дня — это огромные деньги — как хотите так и делайте, быстро!».
«зато пентесты провели»…
Проблема как всегда в том, что перед любыми действиями, ведущими к росту оборотов надо сначала разобраться с техническими долгами или хотя-бы поинтересоваться про все это у технарей, а потом уже «творить бизнес».
Но бизнес требует скорости, а тех.отдел, наоборот, ее снижает — это хорошо понимают менеджеры и управленцы, но плохо понимают почему.
Давно известно, что все можно ускорить — более хорошими, но более высокооплачиваемыми кадрами, масштабированием, аутсорсом и т.д. Но это все — затраты. Большинство тех, кто развивают свой бизнес ради того чтобы он работал и развивался, это понимают и считаются с этим. Те, кому надо хайпануть и быстро продаться на хайпе — нет. Они не хотят про будущее думать, не хотят платить за переработки и т.д. — им не интересно строить на долгий срок. Им надо как можно быстрее и дешевле залететь на пик стоимости и спихнуть это инвестору. Вот и ответ.
Расплата за тех.долги и увеличении скорости бизнеса при забивании на тех.отдел всегда факапы. Потом белые и пушистые менеджеры говорят технарям, чтобы те работали и разгребали все за них, потому как «это все вы виноваты» :)
О тестах конечно задумывались. Но построить полноценную систему нагрузочного тестирования для системы таких размеров — это несколько месяцев работы опытной команды (чем в итоге все и закончилось: наняли PerformanceLab на старте, а затем постепенно прокачали экспертизу внутри) и много миллионов рублей на железо. Увы, тогда таких ресурсов не было.
Были только написаные на коленке тесты, которые создавали заказы через апи для мобильного приложения на дев-стендах и все. А ведь создание заказа, как ниже отписались — это только небольшая часть реальной нагрузки, поэтому доверия к тем тестам было немного.
Это как в шутке: лучше быть здоровым и богатым, чем бедным и больным. Увы, в реальной продуктовой компании все обычно сложнее и приходится выбирать: доделывать функционал, на который будет направлена уже оплаченная несколько месяцев назад реклама на федеральном ТВ или учиться грамотно писать лоадтесты (разработчиков тогда было в несколько раз меньше чем сейчас).
В тот раз риски упасть под нагрузкой недооценили, бывает.
система легла от нескольких десятков тысяч заказов в день?! и над ней трудились пол-сотни человек? у нас пять человек разработчиков занимались системой с сотнями тысяч заказов в день. в каждом заказе — десятки позиций. и да, склад, кол-центр, доставка — всё было.
всё ещё считаете себя профи?
всё ещё считаете себя профи?
Извините, а с кем воевали? С собственной некомпетентностью?
Можно сказать что да, с собственными ошибками. Ошибочные решения прошлых лет, ошибки технических решений, ошибки в приоритизации работы с техдолгом собрались в снежный ком и стрельнули. Это история о том что бывает, если не отдавать техдолг вовремя.
Мораль не в некомпетентности. Если когда-нибудь у вас будет спор с бизнесом и продактами на тему техдолга — просто покажите ему эту историю.
Мораль не в некомпетентности. Если когда-нибудь у вас будет спор с бизнесом и продактами на тему техдолга — просто покажите ему эту историю.
Про «покажите ему эту историю» смешная шутка. Давайте начистоту, если бы Вам показали подобную историю, Вы бы пошли в авральном порядке всё менять и возвращать техдолг? А ведь таких историй целый интернет, включая «громкие», приводящие к потере данных/пользовательской базы/бизнеса. Или бизнес и продакты не умеют искать материал для чтения самостоятельно, а читают только то, что ему показывают?
ну вообще, на продактов и бизнес лучше действуют доказанные цифры. т.е. разложить по полочкам при какой нагрузке сколько будет лежать система — не «я думаю, возможно, что-то упадет» — а конкретно, какая нагрузка на какие системы повлияет, с временными интервалами, кол-вом потерянных заказов и пересчетом этого всего в денежные потери обязательно. Деньги впечатляют больше всего
Эти общие слова мне хорошо известны. Тем не менее, я задал два конкретных вопроса и всё ещё не получил ни одного ответа. Хотя там отвечать-то — «да»/«нет».
Общие слова эти, тем временем, очень тоскливые. Почему-то считается, что это мы (технические специалисты) должны какому-то полумифическому бизнесу всё объяснять так, чтобы ему было понятно (деньги, прибыль). Но вот конкретно Додо Пицца позиционирует себя как ИТ-компания, то есть этот бизнес и есть технологии. На каком ещё языке мне нужно разговаривать с продактом, чтобы он меня понял? Зачем мне вообще разговаривать с человеком, который отвечает за успех продукта и не понимает, что ни одна его прекрасная фича не принесёт ни рубля, если не будет работать? Причём работать не на демо в конце спринта, а у пользователя.
давайте по порядку:
1. если бы просто принесли историю, вряд ли бы кто-то что-то начал делать, но это от человека скорее зависит. Лично я, может и задумалась бы, но не сильно глубоко
2. В моем ответе — совет, который подойдет для убеждения среднего менеджера, это не то, как в Додо делают дела :-)
3. Как делают в Додо:
— до того падения мало у кого было понимание, чем грозят те или иные изъяны системы, поэтому действовали реактивно — уже после того как упали.
— После того падения мы вместе с продактами и другими менеджерами выработали правило — ко всем событиям (реклама, чемпионаты, февральско-мартовские праздники и прочее) начинаем готовиться за 2 месяца. Это значит — прогнозируем нагрузку, нагружаем, исправляем узкие места
— чуть позже, после еще парочки граблей мы пришли к тому, что НИ ОДИН релиз не выходит на продакшн без успешно пройденного нагрузочного тестирования. До введения этого правила иногда приходилось прибегать к аргументу с деньгами — «новые крутые фичи не имеют смысла, если ничего не будет работать в принципе»
Самое забавное во всем этом, что после появления нагрузочного тестирования, история с починкой найденных там проблем немного изменилась, и приходилось убеждать разработчиков, а не менеджеров, что это надо чинить. Разработчики убеждали, что «на продакшене же нормально работает, это у вас что-то не то». Не от хорошей жизни, конечно…
Хотелось бы верить, что мы это победили
1. если бы просто принесли историю, вряд ли бы кто-то что-то начал делать, но это от человека скорее зависит. Лично я, может и задумалась бы, но не сильно глубоко
2. В моем ответе — совет, который подойдет для убеждения среднего менеджера, это не то, как в Додо делают дела :-)
3. Как делают в Додо:
— до того падения мало у кого было понимание, чем грозят те или иные изъяны системы, поэтому действовали реактивно — уже после того как упали.
— После того падения мы вместе с продактами и другими менеджерами выработали правило — ко всем событиям (реклама, чемпионаты, февральско-мартовские праздники и прочее) начинаем готовиться за 2 месяца. Это значит — прогнозируем нагрузку, нагружаем, исправляем узкие места
— чуть позже, после еще парочки граблей мы пришли к тому, что НИ ОДИН релиз не выходит на продакшн без успешно пройденного нагрузочного тестирования. До введения этого правила иногда приходилось прибегать к аргументу с деньгами — «новые крутые фичи не имеют смысла, если ничего не будет работать в принципе»
Самое забавное во всем этом, что после появления нагрузочного тестирования, история с починкой найденных там проблем немного изменилась, и приходилось убеждать разработчиков, а не менеджеров, что это надо чинить. Разработчики убеждали, что «на продакшене же нормально работает, это у вас что-то не то». Не от хорошей жизни, конечно…
Хотелось бы верить, что мы это победили
У меня была возможность самостоятельно убедиться, как в Додо делают некоторые дела, Вы мне этого слона не продадите. Опять же, судя по скрину сообщения про «военное положение» и Вашим же сообщениям за сегодня, и перед инцидентом у Додо было и нагрузочное тестирование, и прогноз нагрузки, только они были неудачные. Отдельно доставляет наличие отдельного же продакта на нефункциональные требования (даже больше, чем сам этот термин).
нагрузочное тестирование до инцидента было, но на рудиментарном уровне — его использовали разово для одного сервиса и оно обнаружило только маленький кусочек всех имевшихся проблем. Под появлением я имела ввиду системное, полноценное нагрузочное тестирование, результатам которого можно доверять.
а откуда вы взяли про прогноз нагрузки? этим просто не занимался никто перед ФРК, к нашему стыду, поэтому не было прогноза
а откуда вы взяли про прогноз нагрузки? этим просто не занимался никто перед ФРК, к нашему стыду, поэтому не было прогноза
«Реклама! Они заряжают рекламу… Зачем? А! Они будут привлекать клиентов!»
Последнее предложение из https://habr.com/ru/company/dodopizzadev/blog/498280/#comment_21531642 я трактовал как промашку с прогнозом, а его вовсе не было. Тогда если прогноза нагрузки не было, как вы к ней готовились (про подготовку к трафику вот прямо на скрине сообщения первым делом)?
если я правильно помню, перед рекламой нагрузили только апи для мобильного приложения, просто создавая там заказы — кол-во и сценарии были взяты практически наобум, экспертно.
сейчас мы раз в неделю снимаем распределение эндпоинтов в пересчете на один заказ с продакшена и корректируем нагрузку по этим данным. А кол-во заказов экстраполируем на основе прошлого года.
Что касается других частей системы — там смотрели метрики на продакшене в пятницу (по пятницам самая большая нагрузка) и пытались понять, в каких местах тоньше всего. Но понять, насколько фикс того или иного узкого места увеличивает порог системы, мы не могли
сейчас мы раз в неделю снимаем распределение эндпоинтов в пересчете на один заказ с продакшена и корректируем нагрузку по этим данным. А кол-во заказов экстраполируем на основе прошлого года.
Что касается других частей системы — там смотрели метрики на продакшене в пятницу (по пятницам самая большая нагрузка) и пытались понять, в каких местах тоньше всего. Но понять, насколько фикс того или иного узкого места увеличивает порог системы, мы не могли
а про самообразование продактов — они обычно не в технических статьях ищут, а в менеджерских. там таких историй как раз не хватает. Написанных продактами для продактов
О как. А технические товарищи читают преимущественно технические статьи. Так ещё раз, почему не продакт должен искать общий язык с технарями, а технарь с продактом?
все должны искать друг с другом общий язык, поэтому и сетую, что в менеджерской среде мало статей про факапы с надежностью. Продакты и менеджеры вникают на базовом уровне в технические сложности, разработчики объясняют чем обернется то или иное решение в терминах потеряных минут\клиентов\заказов\денег
Ребята, короче мы влили бабла дофига
Разрабам задача была накидать быстренько
Думали ща бабла еще поднимем
Но мы обосрались
Заставили всех работать сверх-урочно, конечно не заплатили
Нам конечно плевать на будущее, мы ща бабла поднимем наверное и как пойдет
Ну как то так ребята
Вот краткий пересказ статьи
Куча бесполезных действий вместо того что бы инвестировать в масштабирование проекта
Это как в приору загрузить много мешков цемента, а потом удивляться что подвеска RIP
Можно больше технических подробностей? 100 заказов в минуту не выглядит как сильный highload. Следовательно в архитектуре системы или в настроках имелись серьёзные ошибки. Хотелось бы почитать о причинах падений.
Для нашей системы 100 заказов в минуту это примерно 2к rps на данный момент. Это включает в себя:
— все источники заказа — сайт, приложение, кассу ресторана, колл-центр
— трекинг — он помогает пиццамейкерам отслеживать появляющиеся заказы, статус их готовности(на каждую пиццерию нужно примерно 6-8 разных экранов трекинга)
— интерфейс для отправки курьеров с заказами
— интерфейс для менеджера смены, который контролирует показатели смены
— несколько экранов мотивации
— экран выдачи заказов в зал ресторана
— личные кабинеты сотрудников
— учет и списание ингредиентов
— интерфейсы админки для настройки всего этого
— аналитические интерфейсы для франчайзи, маркетологов, инвесторов и менеджеров управлящей компании
Этот показатель не учитывает внутреннюю «кухню» системы — работу с событиями и запросами между сервисами внутри сети.
Теперь про ошибки — о, да, они явно были и некоторые из них приведены в статье. Главные ошибки:
— слишком большой таймаут на базе
— то, как принимается заказ
тут самое мясо :-) заказ из сайта и приложения отправлялся в апи над монолитом — единую точку отказа — где и происходила основная работа. Сначала заказ инсертился в табличку с заказами, потом инсертился список продуктов к заказу, далее инсертилась всякая статистика — по клиентам, по заказам. Далее заказ отправялся на трекинг по апи, на сервис госового оповещения по апи, делалась запись в базу о необходимости отправить смс клиенту о принятом заказе и кидалось событие в шину. И все эти действия происходили СИНХРОННО в одной транзакции. Т.е. если не удалось отправить заказ в сервис голосового оповещения, то транзакция откатывалась и заказ оказывался не создан. Синхронность создавала дедлоки основных таблиц, а транзакционность увеличивала вероятность неудачи при создании заказа.
— размеры таблиц, неоптимальные и просто тяжелые запросы к базе создавали дополнительную нагрузку для базы и увеличивали вероятность дедлоков и падения всей базы
— высокая связность кода в системе приводила к тому, что не особо важные сервисы и части интерфейса при падении тянули за собой половину системы.
— касса ресторана при обработке и создании заказа работала напрямую с мастер-базой, используя неоптимальные запросы и давая на нее дополнительную нагрузку. В некоторых случаях для рассчета заказа было достаточно репилики (подойдут неоперативные данные), но все равно использовался мастер.
— некоторые сервисы были просто не готовы к такой нагрузке — проектировались под другие показатели и требовали серьезного рефакторинга
Я могла перепутать порядок или какие-то проблемы подзабыть, но проблемы были примерно такие
— все источники заказа — сайт, приложение, кассу ресторана, колл-центр
— трекинг — он помогает пиццамейкерам отслеживать появляющиеся заказы, статус их готовности(на каждую пиццерию нужно примерно 6-8 разных экранов трекинга)
— интерфейс для отправки курьеров с заказами
— интерфейс для менеджера смены, который контролирует показатели смены
— несколько экранов мотивации
— экран выдачи заказов в зал ресторана
— личные кабинеты сотрудников
— учет и списание ингредиентов
— интерфейсы админки для настройки всего этого
— аналитические интерфейсы для франчайзи, маркетологов, инвесторов и менеджеров управлящей компании
Этот показатель не учитывает внутреннюю «кухню» системы — работу с событиями и запросами между сервисами внутри сети.
Теперь про ошибки — о, да, они явно были и некоторые из них приведены в статье. Главные ошибки:
— слишком большой таймаут на базе
— то, как принимается заказ
тут самое мясо :-) заказ из сайта и приложения отправлялся в апи над монолитом — единую точку отказа — где и происходила основная работа. Сначала заказ инсертился в табличку с заказами, потом инсертился список продуктов к заказу, далее инсертилась всякая статистика — по клиентам, по заказам. Далее заказ отправялся на трекинг по апи, на сервис госового оповещения по апи, делалась запись в базу о необходимости отправить смс клиенту о принятом заказе и кидалось событие в шину. И все эти действия происходили СИНХРОННО в одной транзакции. Т.е. если не удалось отправить заказ в сервис голосового оповещения, то транзакция откатывалась и заказ оказывался не создан. Синхронность создавала дедлоки основных таблиц, а транзакционность увеличивала вероятность неудачи при создании заказа.
— размеры таблиц, неоптимальные и просто тяжелые запросы к базе создавали дополнительную нагрузку для базы и увеличивали вероятность дедлоков и падения всей базы
— высокая связность кода в системе приводила к тому, что не особо важные сервисы и части интерфейса при падении тянули за собой половину системы.
— касса ресторана при обработке и создании заказа работала напрямую с мастер-базой, используя неоптимальные запросы и давая на нее дополнительную нагрузку. В некоторых случаях для рассчета заказа было достаточно репилики (подойдут неоперативные данные), но все равно использовался мастер.
— некоторые сервисы были просто не готовы к такой нагрузке — проектировались под другие показатели и требовали серьезного рефакторинга
Я могла перепутать порядок или какие-то проблемы подзабыть, но проблемы были примерно такие
если деталей не достаточно — уточните, какие именно подробности интересуют)
очень хорошие статьи "когда Додо остановилась — синхронный и асинхронный сценарий" — там все технические подробности и решения
Спасибо! Оставлю ссылки на них, чтобы проще было найти:
День, когда Dodo IS остановилась. Синхронный сценарий.
День, когда Dodo IS остановилась. Асинхронный сценарий.
День, когда Dodo IS остановилась. Синхронный сценарий.
День, когда Dodo IS остановилась. Асинхронный сценарий.
Все совершают ошибки. Хорошо, что вы их признаёте и учитесь на них. Успехов вашей команде разработчиков! :)
Спасибо большое за добрые слова! Команде передам — у них как раз сейчас жаркое время, так что поддержка будет очень кстати.
Спойлер
А ещё мы в ближайшие месяцы планируем выпуск серии статей про Dodo IS под разными ракурсами: эволюция системы, архитектура, подходы. Там тоже без описания ошибок не обойдётся. Но лично я верю в выражение «Кто никогда не ошибается, тот просто ничего не делает».
один из главных фейлов — делать конец спринта на конец недели =) если деплоить/запускать акции в условный вторник или среду, то к выходным всегда будет время на фиксы без простоя бизнеса и переработок в выходные)
а вообще додо молодцы) верните салатики в меню!
а вообще додо молодцы) верните салатики в меню!
Конец спринта не в конце недели? Вот это вы сейчас просто все мои шаблоны порвали! Вынесу идею на обсуждение спринта в пятницу.
Что касается деплоя и запуска акции, насколько я знаю, ФРК запустили не в пятницу, и не в субботу. То есть к моменту падения кампания уже примерно неделю крутилась. Но тут уже наша специфика наложилась, что пики заказов всегда приходятся на выходные. В этом году нам удалось учесть все прошлые шишки, уроки и т.д. и пройти 14 февраля, 23 февраля и 8 марта без факапов. Коротенький эмоциональны пост о подготовке тут.
Спасибо за поддержку!
Что касается деплоя и запуска акции, насколько я знаю, ФРК запустили не в пятницу, и не в субботу. То есть к моменту падения кампания уже примерно неделю крутилась. Но тут уже наша специфика наложилась, что пики заказов всегда приходятся на выходные. В этом году нам удалось учесть все прошлые шишки, уроки и т.д. и пройти 14 февраля, 23 февраля и 8 марта без факапов. Коротенький эмоциональны пост о подготовке тут.
Спасибо за поддержку!
Так акцию запустили в начале недели, но в выходные как всегда выросли заказы. :)
А салатики вернём как только улучшится ситуация с пандемией. Сейчас убрали, так как они не проходят тепловую обработку в печи.
А салатики вернём как только улучшится ситуация с пандемией. Сейчас убрали, так как они не проходят тепловую обработку в печи.
Извините, но прочитав все комментарии и разъяснения, я не очень понимаю с какой целью написана статья. Т.е. статьи в корпоративном блоге пишутся с целью либо рекламы собственного продукта, либо для привлечения специалистов в проект. В статье же описаны очень грубые ошибки, которые опытному специалисту должны были сразу броситься в глаза. Но ваш главный инженер/архитектор не только не увидел их, но и даже не настоял на нагрузочном тестировании перед ожидаемой высокой нагрузкой. Это ставит серьёзные вопросы к его квалификации. И именно из за этих ошибок команде пришлось пару недель работать круглосуточно и без выходных, но даже после этого команда не смогла написать нагрузочные тесты своими силами и заказала их у стороннего подрядчика.
После всей этой истории, учитывая что руководят разработкой всё те же люди, встаёт вопрос, а много ли людей захотят работать в такой команде?
После всей этой истории, учитывая что руководят разработкой всё те же люди, встаёт вопрос, а много ли людей захотят работать в такой команде?
Увольнять людей за ошибки — плохой паттерн:
— человек унесет знания об этой ошибке в новое место работы
— замучаешься менять руководителей — все ошибаются
— человек, рабочее место которого зависит от того совершает он ошибки или нет, будет бояться что-либо менять, вообще хоть что-то делать и за что-то отвечать.
Увольнять нужно людей, которые не учатся на ошибках, не делают выводов и допускают повторение ошибок снова и снова.
А если к сути вашего комментария — все эти проблемы были известны, мы даже начали их решать (тот же асинхронный заказ начали делать задолго до падения), а вот их серьезность недооценили. Не было серьезных опасений, что что-то из этого стрельнет настолько сильно. И не было осознания, насколько сильно реклама поднимет нагрузку.
— человек унесет знания об этой ошибке в новое место работы
— замучаешься менять руководителей — все ошибаются
— человек, рабочее место которого зависит от того совершает он ошибки или нет, будет бояться что-либо менять, вообще хоть что-то делать и за что-то отвечать.
Увольнять нужно людей, которые не учатся на ошибках, не делают выводов и допускают повторение ошибок снова и снова.
А если к сути вашего комментария — все эти проблемы были известны, мы даже начали их решать (тот же асинхронный заказ начали делать задолго до падения), а вот их серьезность недооценили. Не было серьезных опасений, что что-то из этого стрельнет настолько сильно. И не было осознания, насколько сильно реклама поднимет нагрузку.
Sign up to leave a comment.
История о птице Додо из рода Фениксов. Великое падение Dodo IS