Процесс выкатки фичи в прод может сильно отличаться от компании, ее процессов и оргструктуры. То что выглядит странно для вашей компании, может быть довольно стандартным процессом в другой компании.
Это и есть одна из проблем коммуникации и разного взгляда на вещи участников одного процесса. Что я и постарался описать в данной статье и привести пример, как эту проблему (проблему коммуникации) можно решать. Как выше в комментариях отметили - это можно решить и другим способом, например сильно разграничив зоны ответственности и выстроить waterfall. У каждого подхода есть свои плюсы и минусы, и нужно выбирать инструмент и подход в зависимости от вашей конкретной ситуации.
Если построить граф связей компонентов между собой в системе, то мы увидим, что связность системы уменьшится, так как для компонента Б будет единая точка входа - очередь сообщений.
P.S. Картинки рисовал от руки на айпаде, в приложении Concepts
В SnF процессе задействована вся кроссфункциональная команда, есть вспомогательные для дежурной команды инструменты, в том числе инструменты мониторингов, например с rollbar (инструмент отлова runtime ошибок) работают только разработчики. Проблема возникла с замусоренностью этого инструмента, поэтому параллельно с основной SnF командой, мы создали временную техническую команду, которая решила конкретно эту проблему.
Mutex в текущей реализации имеет свой TTL, соответственно при падении процесса лок снимается, как только истечет TTL, не обязательно ждать прихода сисадмина.
По поводу Rate Limit, спасибо за замечание, там действительно нужно выставить TTL ключу через команду EXPIRE, чтобы не накапливать неактуальные ключи.
В качестве основной БД у нас используется Postgres, и сессии хранятся в нем, но сессии кэшируются в Redis и соответственно Redis выступает в качестве горячего хранилища.
Представленные реализации, скорее некий Proof of Concept, на основе которого можно допилить ту или иную реализацию по своим требованиям.
Касаемо лока в цикле — это стандартный механизм retry. Если посмотреть на внутренности готовых реализаций по Вашей ссылке, там будет ретрай лока также выставляться в цикле.
По поводу rate limiter так же может быть большее количество различных реализаций, в моем посте представлен базовый вариант, который решает большую часть кейсов. Если же вам нужно что-то более кастомное и сложное, с равномерным распределением нагрузки — можно реализовать более сложные алгоритмы.
Достаточно часто встречаю подход (из общения с другими людьми, и самому тоже доводилось работать в подобных командах), когда каждый сосредоточен на решении своего участка работы, без попытки вникнуть в то, какая именно задача (в широком смысле этого слова) и для кого решается. Условно говоря, кто-то придумал решение, мы взяли и реализовали, для кого, зачем и почему — не наша проблема. Не сомневаюсь, что и при проектном подходе, бывает иначе. Но на моем опыте, и опыте тех людей с кем доводилось общаться, довольно часто получается так, что разработчики пилят код (и делают это хорошо), но без глубокого понимания для кого и зачем. Я рад, что у вас есть другой опыт в этом плане :)
Мне кажется не совсем корректно противопоставлять один подход другому — каждый из них хорошо работает в своем конкретном случае. Может быть несколько путей развития как профессионала, например глубокая узкая специализация, или тот путь, который описан в данном посте. Кому-то ближе одно, кому-то другое, «правильного» пути, на мой взгляд, не существует.
Чаще всего, домик на второй картинке получается если пытаться заложить железобетонную архитектура в самом начале, и пытаться вписать в ее рамки, быстро меняющееся реалии. Наш подход — идти маленькими итерациями, не пытаясь в самом начале архитектурно заложить всё и вся, так как архитектура меняется и развивается итеративно, исходя из полученного от рынка фидбека.
Конечно, задачи связанные с архитектурой есть всегда. В предыдущем комментарии я говорил о непосредственно роли архитектора, сконцентрированной на конкретном человеке. В нашей компании, каждый разработчик в продуктовой команде является архитектором той фичи, которую разрабатывает его команда. А для этого уже требуется более широкий взгляд на продукт и соответствующие скилы.
Как мне кажется, основная разница между проектной и продуктовой разработкой отличается степенью неопределенности конечного результата. Обычно проектная разработка идет по ТЗ и есть достаточно полное понимание того, что мы хотим получить в итоге. Продуктовая же разработка, по большей части, построена на тестировании большого количества гипотез, которые могут не выстрелить, или в ходе экспериментов кардинально поменять свою суть, так как создается что-то новое, и важно понимать отклик рынка. На мой взгляд, роль архитектора перестает быть актуальной, в тот момент, когда продукт становится большим и сложным, когда тестируется большое количество гипотез, когда над ним работают хотя бы больше 3 команд. Да, можно иметь человека, который будет заниматьс продумыванием высокоуровневой архитектуры продукта, но он не будет погружен в детали реализации каждой фичи. И в этой ситуации принятие тех или иных продуктовых и архитектурно-технических решений уходит в зону ответственности команд. А для того, чтобы принимать эти самые решения, как раз таки и нужен этот самый T-shape и выход за рамки своей основной специализации (непосредственное написание кода).
Отдельные задачи, действительно, мало чем отличаются: дизайнер — рисует макеты, разработчик — пишет код, аналитик — работает с данными. На мой взгляд, основное отличие между продуктовой и проектной разработкой заключается в подходе к этим задачам. Насколько участник команды разработки (не зависимо от специализации) широко смотрит на любую реализуемую им фичу, понимает и принимает участие в проработке не только своей отдельной задачи (по основной специализации), но и вовлечен в общий процесс. Участвуя и помогая на всех этапах разработки. Например на этапе проработки макетов — помогая дизайнеру в проработке UX. Прокачивая T-shaped скилы, становясь более ценным для разрабатываемого продукта специалистом. Понятное дело, что целью не является стать профессионалом в абсолютно всех направлениях и специализациях. Но понимание и навыки в смежных областях помогают решать более глобальные вопросы и задачи, чем написание кода по четкому ТЗ
Это вопрос инструментария, данный архитектурный подход можно использовать с любыми инструментами. Мы используем redis, так как у нас в компании достаточно высокая компетенция по нему, так же он позволяет нам очень гибко оперировать сырыми данными, реализуя кастомную логику очередей, как на стандартных типах данных, реализованных в redis, так и расширяя возможности redis через Lua скрипты.
В представленной схеме, внутри FPM процесса у нас разгребается определенная очередь и поочередно процессятся задачи из нее, в одном потоке. Соответственно если скрипт упадет в процессе обработки очередной задачи, не подтвердив ее, следующая отправка обработки этой очереди в internal API начнет обработку с этого же сообщения.
Здесь все зависит от конкретной реализации на уровне обработки очереди, если очередь поддерживает механизм подтверждения (ack), то можно обеспечить атаморность с помощью такого механизма. Можно обеспечивать ее на уровне кода, с использованием дополнительных буферов, систем ретраев и других подходов
Процесс выкатки фичи в прод может сильно отличаться от компании, ее процессов и оргструктуры. То что выглядит странно для вашей компании, может быть довольно стандартным процессом в другой компании.
Это и есть одна из проблем коммуникации и разного взгляда на вещи участников одного процесса. Что я и постарался описать в данной статье и привести пример, как эту проблему (проблему коммуникации) можно решать. Как выше в комментариях отметили - это можно решить и другим способом, например сильно разграничив зоны ответственности и выстроить waterfall. У каждого подхода есть свои плюсы и минусы, и нужно выбирать инструмент и подход в зависимости от вашей конкретной ситуации.
Если построить граф связей компонентов между собой в системе, то мы увидим, что связность системы уменьшится, так как для компонента Б будет единая точка входа - очередь сообщений.
P.S. Картинки рисовал от руки на айпаде, в приложении Concepts
Отличный дизайн и UX. Мне нравится.
По поводу Rate Limit, спасибо за замечание, там действительно нужно выставить TTL ключу через команду EXPIRE, чтобы не накапливать неактуальные ключи.
Касаемо лока в цикле — это стандартный механизм retry. Если посмотреть на внутренности готовых реализаций по Вашей ссылке, там будет ретрай лока также выставляться в цикле.
По поводу rate limiter так же может быть большее количество различных реализаций, в моем посте представлен базовый вариант, который решает большую часть кейсов. Если же вам нужно что-то более кастомное и сложное, с равномерным распределением нагрузки — можно реализовать более сложные алгоритмы.