Как у вас между SRE и разработчиками были не очень хорошие отношения, они же бок о бок работать должны? Т.е. они как бы opposite у вас?
По идее, должны работать вместе, но это не так. Во-первых, это разные команды: SRE живут отдельно, в своем маленьком мирке, делая свои задачи, имея свои приоритеты, а разработчики разделены на команды, и каждая из них тоже живет в своем маленьком мирке со своими задачами и приоритетами. Во-вторых, взаимодействия случались в основном через те самые просьбы и на инцидентах. Ведь разработчики почти не лезли в домен SRE - не хватало ни прав, ни экспертизы. Наличие каких-то границ между мирками разобщало, а при наличии проблем противопоставляло людей. У одних не работает, у других все пули вылетели, а где искать концы не понятно. Только сейчас начинаем устранять причину разделения - выдаем разработчикам права и потихоньку выдаем им экспертизу. Но это еще далеко не конец пути к полноценной самостоятельности разработчиков.
Как они могли не знать о проблемах разработчиков, если должны работать бок о бок?
кажется, ответ был дан в абзаце выше. Если остались вопросы - спрашивайте)
Я так понял, что SRE в основном у вас занимаются тестовыми стендами. В этом свете я не очень понял, как они дают консультации по поводу дизайна отказоустойчивых сервисов.
SRE занимаются далеко не только тестовыми стендами, просто в декабре 2019 тестовые стенды болели больше всего, поэтому в статье так много сказано про них. Мы говорили в основном про тойл команды (но и он состоит не только из тестовых стендов), но кроме тойла есть еще инженерная работа (когда ты не на дежурстве), которая составляет сейчас примерно 60-70% деятельности наших SRE: создание или внедрение новых инструментов, автоматизация рутинных, сложных, скучных задач, построение более отказоустойчивой инфраструктуры для продакшена и много чего еще. Это те задачи, которые ребятам хочется делать, то, за что они любят свою работу. И т.к. у ребят есть понимание системы целиком, ее инфраструктуры, возможностей этой инфраструктуры, как это все работает, они могут дать дельный совет разработчикам. К тому же в команде есть прокачанные в прошлом разработчики, которые сами писали качественные высоконагруженные сервисы.
Эти вещи нужно обеспечивать техническими средствами, о которых не нужно думать и вспоминать
мне тут пока не очень понятно, как можно техническими средствами обеспечить осведомленность о новых инструментах?
Кстати, а зачем тестовые стенды? Почему не получается нужные куски локально развернуть?
можно, и разработчики постоянно так делают, но локальное окружение гораздо сложнее показать кому-то еще - например, продакту или тестировщику. Ну и локальное окружение сильно дальше от продакшена, чем тестовый стенд - нет большей части инфраструктуры и состояние локальной машины почти невозможно сматчить с продакшен-серверами. Если запускать сервисы в докере, то становится лучше, но у нас, к сожалению, пока есть легаси-монолит, который еще не контейнеризирован, а без него можно очень мало чего запустить и проверить.
Тезисы про SRE из "SRE book" от Google (авторов термина и подхода):
Таким образом, SRE - это разработческий подход к операционке (не к разработке бизнес-приложений). Т.е. эти инженеры делают так, чтобы рутинные ручные операционные задачи за людей делала автоматика. Они могут контрибьютить в бизнес-приложения, но не это их основная работа, и чаще они выступают центром экспертизы в том, как писать надежные бизнес-приложения.
А операционные задачи - это поддержка продакшена, инфраструктуры, инциденты, их устранение и предотврадщение и т.д.
Вот как раз о поддержке в основном и идет речь в статье.
Хочу обратить ваше внимание на то, что все аспекты, описанные в статье - это тойл. И занимается им только один (реже 2) человек из команды в каждый момент времени. Что делают остальные? Занимаются инженерной работой - автоматизируют тойл, внедряют или сами пишут новые инструменты.
Есть еще, конечно, SRE-SWE, но это уже более глубокая специализация, о которой мы пока только задумываемся (хотя у нас по факту есть даже такая команда).
Насчет непонимания того, как код работает в проде, абсолютно с вами согласна. Но чтобы полностью отдать поддержку разработчикам, нужно ого-го сколько всего сделать и в техническом, и в процессном плане, это не сделаешь по щелчку пальцев.
Прямо сейчас мы гораздо активнее занимаемся именно этим вопросом. Например, где-то с марта-апреля 2021 некоторые команды разработки сами дежурят по своим сервисам днем. И, надо сказать, довольно успешно)
1. Это очень дорого. 600 виртуалок с полноценной системой, пусть даже маленьких, против 3-4 пожирнее сейчас.
2. Как вписать в вашу модель сайт и мобильное приложение, раз уж всё — один сплошной монолит?
3. Конкретно в нашем случае система не сможет так работать, под это надо затачивать
4. Чисто по бизнес-логике многими настройками пиццерии заведует Управляющая Компания централизованно, а если делить настройки, то постоянно придется тасовать их туда-сюда — накладно в разработке
5. Сейчас при ошибках в релизе или от падения мы можем руками быстренько подхачить данные сразу во всех пострадавших пиццериях. Если будет по виртуалке на пиццерию, это превратится в неподъемную задачу.
6. Ну очень долгий релиз, да к тому же с даунтаймом (если по одной виртуалке на пиццерию).
7. Обслуживать такое кол-во виртуалок надо уметь. Мы пока не готовы.
Надежность — все обращения в рамках одного «физического» компьютера, нет обращений по сети. Опционально можно разве что разбить сервер-приложений и сервер-БД
У нас проблемы очень редко связаны с сетью, чаще с БД или ресурсами на самой виртуалке. К тому же сеть останется, бэкэнд же не прямо на планшете загружен — за ним еще по сети сходить надо.
Это места стыковки с остальной системой. Само по себе взаимодействие клиента с сервером не изменилось, изменился путь данных от бекэнда трекера до других частей системы. И тут было много нового, но не критично.
Логические проблемы будут примерно такие же
Тут не соглашусь. Чтобы выделить сервис, вовсе не обязательно выковыривать код его бизнес-логики из старой системы. Нам хорошо известны сценарии работы трекера, поэтому его просто написали с нуля. Т.е. тут мы с легаси кодом поступили как с черным ящиком — нам не нужно знать, как он устроен внутри, чтобы понять, какой результат получится при определенных действиях. Подсматривали, конечно, но не занимались копи-пастой.
в свежем стартапе на 3-5 пиццерий никто не задумывается, как это будет работать на 100 пиццериях. Отсюда проблемы с архитектурой. У монолита с архитектурой плохо, и это одна из главных проблем. Если бы первоначальные авторы системы могли придумать сходу архитектуру, рассчитанную на 600 пиццерий, то они бы не были разработчиками для маленького стартапа — таких людей только в больших корпорациях найдешь. Но даже если бы они, все же, писали ее для Федора в далеком 2011 году, они бы не успели ее в срок. Тогда скорость разработки была сильно важнее задела на будущее.
Мой 15 летний опыт работы говорит о том, что так думают только оптимисты.
А мы оптимисты! Вот как оценивать рефакторинг монолита с высокой связностью кода и кучей мест, в которых даже старожилы уже не разбираются? Может, у вас есть проверенный подход, занимающий не больше недели?
обычно используют фильтры, ограничивая выборку
Посыл был в том, что загруженность БД не принципиально меняется, если после разделения таблицы джойнить все обратно — фильтровать по 1кк заказам с 30 столбцами или фильтровать 10 табличек по 1кк строк и 3 столбцами каждая и джойнить результат друг на друга.
Также вообще непонятно, как ошибка в коде бизнес-логики влияет на падение базы
плохой запрос в базу, ошибка в политике ретраев, ддосящая базу, и да, дедлоки
Отчеты никогда не должны строится извините за расизм с мастер-реплики
да, тут разночтений нет, но отдельная БД появилась не сразу
Когда у тебя есть понятный и, главное, сильно ограниченный бизнесовый домен, ты один раз его задизайнил и тебе понятно, что делать, где могут быть подводные камни, тебе не нужно разбираться в чужом коде, в чужой логике мышления. У тебя есть ожидаемое бизнесом поведение и места стыковки с остальной системой. Остается реализовать план. На пути реализации тоже бывают сложности, конечно, но в них ты редко зависишь от внешних акторов.
Когда у тебя огромный комок сильно связанного кода написанного на основе разных подходов к проектированию и разработке, в котором никто не знает всех нюансов, то очень трудно предсказать, где что отвалится, когда ты потянешь за ниточку, о каких бизнес-процессах ты еще не знаешь, и сколько времени тебе понадобится, чтобы разобраться во всей паутине.
Здравствуйте!
Приятно снова читать комментарии матерого архитектора! (если что, ни разу не сарказм)
Зачем в БД хранить все поля заказа в одной таблице? Что мешает разделить их по таблицам и джойнить в нужных сервисах нужные таблицы?
— объем кода, завязанного на эти поля. чтобы свести таблицу до рабочего состояния надо переписать пол системы. и это при том, что большая часть разработчиков продолжает писать в ней код с бизнес-фичами. Если всех бросить на переписывание, бизнес взвоет — он не может себе позволить не делать новых фич так долго.
— Был определенный технический дедлайн, особенно на выделение трекера — к лету 2017 база перестала бы справляться, а скейлить вверх машины под ней было уже некуда. Оценка выделения сервиса из монолита более предсказуема и надежна, чем оценка рефакторинга того же монолита, поэтому сделали, что успели.
— это же не спасет от тяжелых операций — придется джойнить все ту же гигантскую таблицу с заказами на такие же по размеру таблицы с другими полями. Тут надо скорее паттерн использования полей менять, а это значит, что надо проектировать всю систему или значительную ее часть заново.
— отказоустойчивость системы — очень плохо когда слишком жирный отчет (для этого, конечно, есть АХД) или ошибка в коде какого-нибудь экрана выдачи заказов кладут мастер базу и перестает работать вся система. Если же экран выдачи заказов выделен в отдельный сервис, то его баги влияют только на него и позволяют пиццерии и дальше обрабатывать заказы. Маленькие сервисы и откатывать проще в случае проблем. Большой монолит деплоится и откатывается сильно дольше.
Очереди должны быть отказоустойчивыми с гарантией доставки.
Да, и это быстро стало проблемой, но она была довольно быстро решена и все новые сервисы сразу закладывают и гарантию доставки, и коммутативность событий, и еще несколько важных пунктов.
вместо того, чтобы оптимизировать структуру данных в БД и переписать говнокод, вы создали кучу новых проблем
Новые проблемы появлялись постепенно, не влияли или сильно меньше влияли на здоровье мастер-базы, их было проще исправить, чем старые проблемы, потому что код был локализован и более качественно написан.
и с которыми также нужно уметь работать.
Вот тут закрался главный сюрприз для нас после начала массового отделения сервисов. На продакшене мы особых проблем не испытываем, а вот тестовые стенды для разработчиков получили удар откуда не ждали — необходимость синхронизировать локальные хранилища привела к тому, что стенды стали разваливаться, а команды, работавшие с ними, не понимали, почему, и что с этим делать. Сейчас мы лучше умеем с этим работать, но определенно еще есть куда стремиться.
По остальным пунктам, считаю, что мне не хватает экспертизы, чтобы поддержать дискуссию. Извините :-)
Кэш, даже, допустим, в 5 сек. + обновление раз в 10 сек может привести к тому, что продукт не выйдет на нужный трекер в течение 20 сек. Умножаем на кол-во планшетов в пиццерии и получаем 100 сек промедления только на стороне Dodo IS. На кухне за это время можно приготовить парочку пицц. А для пользователя это будет выглядеть как "пицца не протыкивается" — не переходит с одного планшета на другой. Кроме того, если заказ отменяют, кухне надо знать об этом максимально быстро, ччтобы лишнего не наготовить.
В комментарии ниже автор статьи говорит о том, что инвалидация кэша была нетривиальной задачей. Без разматывания клубка тут как-то сложновато.
Кэш в памяти в распределенной системе без инвалидации — отсутствие консистентности. На одной машине кэш обновился, на другой еще нет, в итоге получаем, что пицца на планшете скачет — то есть, то нет. Это очень критичная проблема для кухни.
Использование рэдиса в качестве распределенного кэша приводит к проблемам производительности. Если рэдис заэвиктит еще актуальную запись (а он это делает регулярно), снова начинаются скачки, но теперь уже лейтенси.
Но рэдис тут больше по надежности не подходит.
В плане трекера вы получили бы абсолютно то же быстродействие просто используя кэш в оперативке
Но трекер нельзя кэшировать, ему нужны самые оперативные данные
Просто банальная выборка из ОЧЕНЬ маленькой базы Редиса
Редис подходит только для кэша, который вы не боитесь потерять — он не гарантирует сохранность всех данных, которые содержит. Пиццерии нельзя терять заказы и продукты в заказах. Да и в сам Редис данные должны сначала попасть :-)
Самый простой пример — сервис, который мы планируем ретраить, крутится на n серверах. В какой-от момент один из серверов начинает плохо себя чувствовать (память кончилась, в рестарт ушел — в облаке часто что-то случается). В такой ситуации запрос, пришедший на умирающий сервер, после ретрая с большой вероятностью (nginx выводит плохие сервера из апстима) попадет на здоровую машину и пользователь не заметит проблемы.
У нас такое случается постоянно, по разным причинам.
все должны искать друг с другом общий язык, поэтому и сетую, что в менеджерской среде мало статей про факапы с надежностью. Продакты и менеджеры вникают на базовом уровне в технические сложности, разработчики объясняют чем обернется то или иное решение в терминах потеряных минут\клиентов\заказов\денег
если я правильно помню, перед рекламой нагрузили только апи для мобильного приложения, просто создавая там заказы — кол-во и сценарии были взяты практически наобум, экспертно.
сейчас мы раз в неделю снимаем распределение эндпоинтов в пересчете на один заказ с продакшена и корректируем нагрузку по этим данным. А кол-во заказов экстраполируем на основе прошлого года.
Что касается других частей системы — там смотрели метрики на продакшене в пятницу (по пятницам самая большая нагрузка) и пытались понять, в каких местах тоньше всего. Но понять, насколько фикс того или иного узкого места увеличивает порог системы, мы не могли
нагрузочное тестирование до инцидента было, но на рудиментарном уровне — его использовали разово для одного сервиса и оно обнаружило только маленький кусочек всех имевшихся проблем. Под появлением я имела ввиду системное, полноценное нагрузочное тестирование, результатам которого можно доверять.
а откуда вы взяли про прогноз нагрузки? этим просто не занимался никто перед ФРК, к нашему стыду, поэтому не было прогноза
а про самообразование продактов — они обычно не в технических статьях ищут, а в менеджерских. там таких историй как раз не хватает. Написанных продактами для продактов
сколько интересных вопросов! отвечаю:
По идее, должны работать вместе, но это не так. Во-первых, это разные команды: SRE живут отдельно, в своем маленьком мирке, делая свои задачи, имея свои приоритеты, а разработчики разделены на команды, и каждая из них тоже живет в своем маленьком мирке со своими задачами и приоритетами. Во-вторых, взаимодействия случались в основном через те самые просьбы и на инцидентах. Ведь разработчики почти не лезли в домен SRE - не хватало ни прав, ни экспертизы. Наличие каких-то границ между мирками разобщало, а при наличии проблем противопоставляло людей. У одних не работает, у других все пули вылетели, а где искать концы не понятно. Только сейчас начинаем устранять причину разделения - выдаем разработчикам права и потихоньку выдаем им экспертизу. Но это еще далеко не конец пути к полноценной самостоятельности разработчиков.
кажется, ответ был дан в абзаце выше. Если остались вопросы - спрашивайте)
SRE занимаются далеко не только тестовыми стендами, просто в декабре 2019 тестовые стенды болели больше всего, поэтому в статье так много сказано про них. Мы говорили в основном про тойл команды (но и он состоит не только из тестовых стендов), но кроме тойла есть еще инженерная работа (когда ты не на дежурстве), которая составляет сейчас примерно 60-70% деятельности наших SRE: создание или внедрение новых инструментов, автоматизация рутинных, сложных, скучных задач, построение более отказоустойчивой инфраструктуры для продакшена и много чего еще. Это те задачи, которые ребятам хочется делать, то, за что они любят свою работу.
И т.к. у ребят есть понимание системы целиком, ее инфраструктуры, возможностей этой инфраструктуры, как это все работает, они могут дать дельный совет разработчикам. К тому же в команде есть прокачанные в прошлом разработчики, которые сами писали качественные высоконагруженные сервисы.
мне тут пока не очень понятно, как можно техническими средствами обеспечить осведомленность о новых инструментах?
можно, и разработчики постоянно так делают, но локальное окружение гораздо сложнее показать кому-то еще - например, продакту или тестировщику. Ну и локальное окружение сильно дальше от продакшена, чем тестовый стенд - нет большей части инфраструктуры и состояние локальной машины почти невозможно сматчить с продакшен-серверами. Если запускать сервисы в докере, то становится лучше, но у нас, к сожалению, пока есть легаси-монолит, который еще не контейнеризирован, а без него можно очень мало чего запустить и проверить.
Добавили метрики Lead Time в конец статьи - выбросы есть, но тренд на снижение заметен
Хорошая мысль, откопаем метрики, добавим в статью
Спасибо за идею!
К теме токсичности еще вернемся.
В процессе борьбы ни один сотрудник не был уволен ;-)
Определение SRE из википедии:
Тезисы про SRE из "SRE book" от Google (авторов термина и подхода):
Таким образом, SRE - это разработческий подход к операционке (не к разработке бизнес-приложений). Т.е. эти инженеры делают так, чтобы рутинные ручные операционные задачи за людей делала автоматика. Они могут контрибьютить в бизнес-приложения, но не это их основная работа, и чаще они выступают центром экспертизы в том, как писать надежные бизнес-приложения.
А операционные задачи - это поддержка продакшена, инфраструктуры, инциденты, их устранение и предотврадщение и т.д.
Вот как раз о поддержке в основном и идет речь в статье.
Хочу обратить ваше внимание на то, что все аспекты, описанные в статье - это тойл. И занимается им только один (реже 2) человек из команды в каждый момент времени. Что делают остальные? Занимаются инженерной работой - автоматизируют тойл, внедряют или сами пишут новые инструменты.
Есть еще, конечно, SRE-SWE, но это уже более глубокая специализация, о которой мы пока только задумываемся (хотя у нас по факту есть даже такая команда).
Насчет непонимания того, как код работает в проде, абсолютно с вами согласна. Но чтобы полностью отдать поддержку разработчикам, нужно ого-го сколько всего сделать и в техническом, и в процессном плане, это не сделаешь по щелчку пальцев.
Прямо сейчас мы гораздо активнее занимаемся именно этим вопросом. Например, где-то с марта-апреля 2021 некоторые команды разработки сами дежурят по своим сервисам днем. И, надо сказать, довольно успешно)
Коммент удален
А что такие SRE разрабатывают?
2. Как вписать в вашу модель сайт и мобильное приложение, раз уж всё — один сплошной монолит?
3. Конкретно в нашем случае система не сможет так работать, под это надо затачивать
4. Чисто по бизнес-логике многими настройками пиццерии заведует Управляющая Компания централизованно, а если делить настройки, то постоянно придется тасовать их туда-сюда — накладно в разработке
5. Сейчас при ошибках в релизе или от падения мы можем руками быстренько подхачить данные сразу во всех пострадавших пиццериях. Если будет по виртуалке на пиццерию, это превратится в неподъемную задачу.
6. Ну очень долгий релиз, да к тому же с даунтаймом (если по одной виртуалке на пиццерию).
7. Обслуживать такое кол-во виртуалок надо уметь. Мы пока не готовы.
У нас проблемы очень редко связаны с сетью, чаще с БД или ресурсами на самой виртуалке. К тому же сеть останется, бэкэнд же не прямо на планшете загружен — за ним еще по сети сходить надо.
Это у нашего монолита все плохо, а не у у монолита как класса
Это возможно реализовать с managed базами? Что-то мне подсказывает, что не будет нужного уровня управляемости…
Ошибка разработчика — не учел размеры таблицы, индексы, в назании поля ошибся, да мало ли что — Со всяким бывает.
До разделения базы на мастер, рид и АХД и такое бывало. Но это не относится к вопросу разделения на сервисы
Это места стыковки с остальной системой. Само по себе взаимодействие клиента с сервером не изменилось, изменился путь данных от бекэнда трекера до других частей системы. И тут было много нового, но не критично.
Тут не соглашусь. Чтобы выделить сервис, вовсе не обязательно выковыривать код его бизнес-логики из старой системы. Нам хорошо известны сценарии работы трекера, поэтому его просто написали с нуля. Т.е. тут мы с легаси кодом поступили как с черным ящиком — нам не нужно знать, как он устроен внутри, чтобы понять, какой результат получится при определенных действиях. Подсматривали, конечно, но не занимались копи-пастой.
в свежем стартапе на 3-5 пиццерий никто не задумывается, как это будет работать на 100 пиццериях. Отсюда проблемы с архитектурой. У монолита с архитектурой плохо, и это одна из главных проблем. Если бы первоначальные авторы системы могли придумать сходу архитектуру, рассчитанную на 600 пиццерий, то они бы не были разработчиками для маленького стартапа — таких людей только в больших корпорациях найдешь. Но даже если бы они, все же, писали ее для Федора в далеком 2011 году, они бы не успели ее в срок. Тогда скорость разработки была сильно важнее задела на будущее.
А мы оптимисты! Вот как оценивать рефакторинг монолита с высокой связностью кода и кучей мест, в которых даже старожилы уже не разбираются? Может, у вас есть проверенный подход, занимающий не больше недели?
Посыл был в том, что загруженность БД не принципиально меняется, если после разделения таблицы джойнить все обратно — фильтровать по 1кк заказам с 30 столбцами или фильтровать 10 табличек по 1кк строк и 3 столбцами каждая и джойнить результат друг на друга.
плохой запрос в базу, ошибка в политике ретраев, ддосящая базу, и да, дедлоки
да, тут разночтений нет, но отдельная БД появилась не сразу
Когда у тебя огромный комок сильно связанного кода написанного на основе разных подходов к проектированию и разработке, в котором никто не знает всех нюансов, то очень трудно предсказать, где что отвалится, когда ты потянешь за ниточку, о каких бизнес-процессах ты еще не знаешь, и сколько времени тебе понадобится, чтобы разобраться во всей паутине.
Приятно снова читать комментарии матерого архитектора! (если что, ни разу не сарказм)
— объем кода, завязанного на эти поля. чтобы свести таблицу до рабочего состояния надо переписать пол системы. и это при том, что большая часть разработчиков продолжает писать в ней код с бизнес-фичами. Если всех бросить на переписывание, бизнес взвоет — он не может себе позволить не делать новых фич так долго.
— Был определенный технический дедлайн, особенно на выделение трекера — к лету 2017 база перестала бы справляться, а скейлить вверх машины под ней было уже некуда. Оценка выделения сервиса из монолита более предсказуема и надежна, чем оценка рефакторинга того же монолита, поэтому сделали, что успели.
— это же не спасет от тяжелых операций — придется джойнить все ту же гигантскую таблицу с заказами на такие же по размеру таблицы с другими полями. Тут надо скорее паттерн использования полей менять, а это значит, что надо проектировать всю систему или значительную ее часть заново.
— отказоустойчивость системы — очень плохо когда слишком жирный отчет (для этого, конечно, есть АХД) или ошибка в коде какого-нибудь экрана выдачи заказов кладут мастер базу и перестает работать вся система. Если же экран выдачи заказов выделен в отдельный сервис, то его баги влияют только на него и позволяют пиццерии и дальше обрабатывать заказы. Маленькие сервисы и откатывать проще в случае проблем. Большой монолит деплоится и откатывается сильно дольше.
Да, и это быстро стало проблемой, но она была довольно быстро решена и все новые сервисы сразу закладывают и гарантию доставки, и коммутативность событий, и еще несколько важных пунктов.
Новые проблемы появлялись постепенно, не влияли или сильно меньше влияли на здоровье мастер-базы, их было проще исправить, чем старые проблемы, потому что код был локализован и более качественно написан.
Вот тут закрался главный сюрприз для нас после начала массового отделения сервисов. На продакшене мы особых проблем не испытываем, а вот тестовые стенды для разработчиков получили удар откуда не ждали — необходимость синхронизировать локальные хранилища привела к тому, что стенды стали разваливаться, а команды, работавшие с ними, не понимали, почему, и что с этим делать. Сейчас мы лучше умеем с этим работать, но определенно еще есть куда стремиться.
По остальным пунктам, считаю, что мне не хватает экспертизы, чтобы поддержать дискуссию. Извините :-)
Кэш, даже, допустим, в 5 сек. + обновление раз в 10 сек может привести к тому, что продукт не выйдет на нужный трекер в течение 20 сек. Умножаем на кол-во планшетов в пиццерии и получаем 100 сек промедления только на стороне Dodo IS. На кухне за это время можно приготовить парочку пицц. А для пользователя это будет выглядеть как "пицца не протыкивается" — не переходит с одного планшета на другой. Кроме того, если заказ отменяют, кухне надо знать об этом максимально быстро, ччтобы лишнего не наготовить.
В комментарии ниже автор статьи говорит о том, что инвалидация кэша была нетривиальной задачей. Без разматывания клубка тут как-то сложновато.
Кэш в памяти в распределенной системе без инвалидации — отсутствие консистентности. На одной машине кэш обновился, на другой еще нет, в итоге получаем, что пицца на планшете скачет — то есть, то нет. Это очень критичная проблема для кухни.
Использование рэдиса в качестве распределенного кэша приводит к проблемам производительности. Если рэдис заэвиктит еще актуальную запись (а он это делает регулярно), снова начинаются скачки, но теперь уже лейтенси.
Но рэдис тут больше по надежности не подходит.
Но трекер нельзя кэшировать, ему нужны самые оперативные данные
Редис подходит только для кэша, который вы не боитесь потерять — он не гарантирует сохранность всех данных, которые содержит. Пиццерии нельзя терять заказы и продукты в заказах. Да и в сам Редис данные должны сначала попасть :-)
У нас такое случается постоянно, по разным причинам.
сейчас мы раз в неделю снимаем распределение эндпоинтов в пересчете на один заказ с продакшена и корректируем нагрузку по этим данным. А кол-во заказов экстраполируем на основе прошлого года.
Что касается других частей системы — там смотрели метрики на продакшене в пятницу (по пятницам самая большая нагрузка) и пытались понять, в каких местах тоньше всего. Но понять, насколько фикс того или иного узкого места увеличивает порог системы, мы не могли
а откуда вы взяли про прогноз нагрузки? этим просто не занимался никто перед ФРК, к нашему стыду, поэтому не было прогноза