давайте по порядку:
1. если бы просто принесли историю, вряд ли бы кто-то что-то начал делать, но это от человека скорее зависит. Лично я, может и задумалась бы, но не сильно глубоко
2. В моем ответе — совет, который подойдет для убеждения среднего менеджера, это не то, как в Додо делают дела :-)
3. Как делают в Додо:
— до того падения мало у кого было понимание, чем грозят те или иные изъяны системы, поэтому действовали реактивно — уже после того как упали.
— После того падения мы вместе с продактами и другими менеджерами выработали правило — ко всем событиям (реклама, чемпионаты, февральско-мартовские праздники и прочее) начинаем готовиться за 2 месяца. Это значит — прогнозируем нагрузку, нагружаем, исправляем узкие места
— чуть позже, после еще парочки граблей мы пришли к тому, что НИ ОДИН релиз не выходит на продакшн без успешно пройденного нагрузочного тестирования. До введения этого правила иногда приходилось прибегать к аргументу с деньгами — «новые крутые фичи не имеют смысла, если ничего не будет работать в принципе»
Самое забавное во всем этом, что после появления нагрузочного тестирования, история с починкой найденных там проблем немного изменилась, и приходилось убеждать разработчиков, а не менеджеров, что это надо чинить. Разработчики убеждали, что «на продакшене же нормально работает, это у вас что-то не то». Не от хорошей жизни, конечно…
Хотелось бы верить, что мы это победили
Увольнять людей за ошибки — плохой паттерн:
— человек унесет знания об этой ошибке в новое место работы
— замучаешься менять руководителей — все ошибаются
— человек, рабочее место которого зависит от того совершает он ошибки или нет, будет бояться что-либо менять, вообще хоть что-то делать и за что-то отвечать.
Увольнять нужно людей, которые не учатся на ошибках, не делают выводов и допускают повторение ошибок снова и снова.
А если к сути вашего комментария — все эти проблемы были известны, мы даже начали их решать (тот же асинхронный заказ начали делать задолго до падения), а вот их серьезность недооценили. Не было серьезных опасений, что что-то из этого стрельнет настолько сильно. И не было осознания, насколько сильно реклама поднимет нагрузку.
ну вообще, на продактов и бизнес лучше действуют доказанные цифры. т.е. разложить по полочкам при какой нагрузке сколько будет лежать система — не «я думаю, возможно, что-то упадет» — а конкретно, какая нагрузка на какие системы повлияет, с временными интервалами, кол-вом потерянных заказов и пересчетом этого всего в денежные потери обязательно. Деньги впечатляют больше всего
тут вопрос времени и усилий — иногда выглядит слишком дорого (не всегда это верная оценка, поэтому мы учимся предсказывать и считать выхлоп) или уже не успеешь, если есть дедлайн. Дедлайна в данном случае могло и не быть — плохая коммуникация и согласованность маркетинга и разработки — в этой части тоже были изменения
нагрузочное тестирование должно было выявить эти проблемы.
еще как должно было. Именно поэтому подход к нагрузочному тестированию был пересмотрен и нагрузка вышла на совершенно другой уровень — теперь она системная и стремится максимально походить на продакшн, чтобы выявлять возможные именно на продакшене проблемы
Нет, ошибки тоже компании и ее руководства
ошибок хватало везде, но если искать авторов ошибок вместо их устранения, толку будет мало. Поэтому было очень многое изменено на ВСЕХ уровнях и во всех взаимодействиях, хоть как-то участвовавших в ситуации
Для нашей системы 100 заказов в минуту это примерно 2к rps на данный момент. Это включает в себя:
— все источники заказа — сайт, приложение, кассу ресторана, колл-центр
— трекинг — он помогает пиццамейкерам отслеживать появляющиеся заказы, статус их готовности(на каждую пиццерию нужно примерно 6-8 разных экранов трекинга)
— интерфейс для отправки курьеров с заказами
— интерфейс для менеджера смены, который контролирует показатели смены
— несколько экранов мотивации
— экран выдачи заказов в зал ресторана
— личные кабинеты сотрудников
— учет и списание ингредиентов
— интерфейсы админки для настройки всего этого
— аналитические интерфейсы для франчайзи, маркетологов, инвесторов и менеджеров управлящей компании
Этот показатель не учитывает внутреннюю «кухню» системы — работу с событиями и запросами между сервисами внутри сети.
Теперь про ошибки — о, да, они явно были и некоторые из них приведены в статье. Главные ошибки:
— слишком большой таймаут на базе
— то, как принимается заказ
тут самое мясо :-) заказ из сайта и приложения отправлялся в апи над монолитом — единую точку отказа — где и происходила основная работа. Сначала заказ инсертился в табличку с заказами, потом инсертился список продуктов к заказу, далее инсертилась всякая статистика — по клиентам, по заказам. Далее заказ отправялся на трекинг по апи, на сервис госового оповещения по апи, делалась запись в базу о необходимости отправить смс клиенту о принятом заказе и кидалось событие в шину. И все эти действия происходили СИНХРОННО в одной транзакции. Т.е. если не удалось отправить заказ в сервис голосового оповещения, то транзакция откатывалась и заказ оказывался не создан. Синхронность создавала дедлоки основных таблиц, а транзакционность увеличивала вероятность неудачи при создании заказа.
— размеры таблиц, неоптимальные и просто тяжелые запросы к базе создавали дополнительную нагрузку для базы и увеличивали вероятность дедлоков и падения всей базы
— высокая связность кода в системе приводила к тому, что не особо важные сервисы и части интерфейса при падении тянули за собой половину системы.
— касса ресторана при обработке и создании заказа работала напрямую с мастер-базой, используя неоптимальные запросы и давая на нее дополнительную нагрузку. В некоторых случаях для рассчета заказа было достаточно репилики (подойдут неоперативные данные), но все равно использовался мастер.
— некоторые сервисы были просто не готовы к такой нагрузке — проектировались под другие показатели и требовали серьезного рефакторинга
Я могла перепутать порядок или какие-то проблемы подзабыть, но проблемы были примерно такие
В Хабаровске сейчас 2 пиццерии в стадии проектирования. Одна из них фудкорт. Т.е. скоро с зоной доставки станет лучше
Upd: Центральная пиццерия в Хабаровске будет работать к началу декабря
Есть разные по оформлению, на самом деле. но, помимо стандартных мемов из интернета типа фейспальма от Пикара, там преимущественно лица коллег — это уже никому не интересно)
1. если бы просто принесли историю, вряд ли бы кто-то что-то начал делать, но это от человека скорее зависит. Лично я, может и задумалась бы, но не сильно глубоко
2. В моем ответе — совет, который подойдет для убеждения среднего менеджера, это не то, как в Додо делают дела :-)
3. Как делают в Додо:
— до того падения мало у кого было понимание, чем грозят те или иные изъяны системы, поэтому действовали реактивно — уже после того как упали.
— После того падения мы вместе с продактами и другими менеджерами выработали правило — ко всем событиям (реклама, чемпионаты, февральско-мартовские праздники и прочее) начинаем готовиться за 2 месяца. Это значит — прогнозируем нагрузку, нагружаем, исправляем узкие места
— чуть позже, после еще парочки граблей мы пришли к тому, что НИ ОДИН релиз не выходит на продакшн без успешно пройденного нагрузочного тестирования. До введения этого правила иногда приходилось прибегать к аргументу с деньгами — «новые крутые фичи не имеют смысла, если ничего не будет работать в принципе»
Самое забавное во всем этом, что после появления нагрузочного тестирования, история с починкой найденных там проблем немного изменилась, и приходилось убеждать разработчиков, а не менеджеров, что это надо чинить. Разработчики убеждали, что «на продакшене же нормально работает, это у вас что-то не то». Не от хорошей жизни, конечно…
Хотелось бы верить, что мы это победили
— человек унесет знания об этой ошибке в новое место работы
— замучаешься менять руководителей — все ошибаются
— человек, рабочее место которого зависит от того совершает он ошибки или нет, будет бояться что-либо менять, вообще хоть что-то делать и за что-то отвечать.
Увольнять нужно людей, которые не учатся на ошибках, не делают выводов и допускают повторение ошибок снова и снова.
А если к сути вашего комментария — все эти проблемы были известны, мы даже начали их решать (тот же асинхронный заказ начали делать задолго до падения), а вот их серьезность недооценили. Не было серьезных опасений, что что-то из этого стрельнет настолько сильно. И не было осознания, насколько сильно реклама поднимет нагрузку.
тут вопрос времени и усилий — иногда выглядит слишком дорого (не всегда это верная оценка, поэтому мы учимся предсказывать и считать выхлоп) или уже не успеешь, если есть дедлайн. Дедлайна в данном случае могло и не быть — плохая коммуникация и согласованность маркетинга и разработки — в этой части тоже были изменения
еще как должно было. Именно поэтому подход к нагрузочному тестированию был пересмотрен и нагрузка вышла на совершенно другой уровень — теперь она системная и стремится максимально походить на продакшн, чтобы выявлять возможные именно на продакшене проблемы
ошибок хватало везде, но если искать авторов ошибок вместо их устранения, толку будет мало. Поэтому было очень многое изменено на ВСЕХ уровнях и во всех взаимодействиях, хоть как-то участвовавших в ситуации
— все источники заказа — сайт, приложение, кассу ресторана, колл-центр
— трекинг — он помогает пиццамейкерам отслеживать появляющиеся заказы, статус их готовности(на каждую пиццерию нужно примерно 6-8 разных экранов трекинга)
— интерфейс для отправки курьеров с заказами
— интерфейс для менеджера смены, который контролирует показатели смены
— несколько экранов мотивации
— экран выдачи заказов в зал ресторана
— личные кабинеты сотрудников
— учет и списание ингредиентов
— интерфейсы админки для настройки всего этого
— аналитические интерфейсы для франчайзи, маркетологов, инвесторов и менеджеров управлящей компании
Этот показатель не учитывает внутреннюю «кухню» системы — работу с событиями и запросами между сервисами внутри сети.
Теперь про ошибки — о, да, они явно были и некоторые из них приведены в статье. Главные ошибки:
— слишком большой таймаут на базе
— то, как принимается заказ
тут самое мясо :-) заказ из сайта и приложения отправлялся в апи над монолитом — единую точку отказа — где и происходила основная работа. Сначала заказ инсертился в табличку с заказами, потом инсертился список продуктов к заказу, далее инсертилась всякая статистика — по клиентам, по заказам. Далее заказ отправялся на трекинг по апи, на сервис госового оповещения по апи, делалась запись в базу о необходимости отправить смс клиенту о принятом заказе и кидалось событие в шину. И все эти действия происходили СИНХРОННО в одной транзакции. Т.е. если не удалось отправить заказ в сервис голосового оповещения, то транзакция откатывалась и заказ оказывался не создан. Синхронность создавала дедлоки основных таблиц, а транзакционность увеличивала вероятность неудачи при создании заказа.
— размеры таблиц, неоптимальные и просто тяжелые запросы к базе создавали дополнительную нагрузку для базы и увеличивали вероятность дедлоков и падения всей базы
— высокая связность кода в системе приводила к тому, что не особо важные сервисы и части интерфейса при падении тянули за собой половину системы.
— касса ресторана при обработке и создании заказа работала напрямую с мастер-базой, используя неоптимальные запросы и давая на нее дополнительную нагрузку. В некоторых случаях для рассчета заказа было достаточно репилики (подойдут неоперативные данные), но все равно использовался мастер.
— некоторые сервисы были просто не готовы к такой нагрузке — проектировались под другие показатели и требовали серьезного рефакторинга
Я могла перепутать порядок или какие-то проблемы подзабыть, но проблемы были примерно такие
Upd: Центральная пиццерия в Хабаровске будет работать к началу декабря
Можете свободно добавляться в публичный чатик в телеграме — @dodopizzaiochat.
А что до слака — приходите к нам в команду, будет полный доступ)
Искала — пока не нашла способа массово выгузить смайлы из слака. По одному — как-то муторно)
Есть разные по оформлению, на самом деле. но, помимо стандартных мемов из интернета типа фейспальма от Пикара, там преимущественно лица коллег — это уже никому не интересно)
Вы имеете ввиду кастомные смайлы из слака, используемые как мемы?