Мы - это компания "Human+", как генподрядчик разработки и ответственные за "железную часть", и "Спринт-Ф", как основной разработчик бэкенда и фронтенда системы.
Альтернатива Редмайну существует ровно одна - это Jira. На своем сервере с «китайской» лицензией. Всё остальное - это попыики имитировать часть функций Jira, причем самую неважную часть.
Очень интересно, зачем каждый раз это разрабатывать заново, если еще 8 лет назад мы на Ямале внедрили в эксплуатацию полностью функциональное решение, причем по функциям на порядок более богатое, чем вы описываете?
>> Чистая архитектура независима от информационных хранилищ. Можно поменять PostgreSQL на MongoDB или на любую другую СУБД. При этом работа бизнес-правил не изменится.
Сложно представить себе более вредное утверждение. В реальности оно звучит так:
- Откажитесь от всех преимуществ специализированных хранилищ ради нулевого шанса на их смену.
Ни один подобный проект никогда не приводил к бизнес-успеху. И этот не приведет. Будет потрачен охулиард денег, чтобы сделать плохую и неточную копию того, что уже давно было сделано.
А учитывая, что позиции уровня архитекторов в ВК зачищены от ненужных людей, и учитывая, что ВК отказывается нанимать разработчиков в штат, предпочитая договора с региональными однодневными аутстафф-агентствами - можно себе представить качество этого нового кода.
Запуск делается через менеджер процессов, тоже написанный на PHP. Он следит за тем, чтобы число активных процессов-воркеров не превышало заданный лимит, получает задание для каждого воркера, запускает его, пишет метрики - когда запущен, когда закончился, какой результат.
А как вам поможет супервизор в случае "залипания" процесса на какой-нибудь логической ошибке, вводящей его в бесконечный цикл? Процесс работает, живой. Супервизор не видит проблем, процесс не перезапускает.
Вам в любом случае для долгоживущих процессов нужен свой мониторинг их работы, основанный не на "работает/не работает", но на учете бизнес-логики таких процессов.
Живой пример - делали на таких "управляемых процессах" обработку прайс-листов. Десятков тысяч в сутки, на миллионы позиций каждый (если что - это торговля запчастями). Там естественной метрикой была строка прайс-листа. Пишем в редис раз в секунду инфу, на какой мы сейчас строке файла. Отличная метрика, позволяет сразу же понять, работает ли процесс так, как нам надо, или нет.
Ну и вторая принципиальная разница по сравнению с супервизором - когда вам нужен интерфейс мониторинга и управления процессами, которым сможет пользоваться вторая линия поддержки, вам супервизор не подойдет. Он не наглядный. А нам пришлось делать наглядную панель управления.
В комментарии поделиться не получится - места мало. Но в целом да, делали такое и не раз. Банально на тики, или чуть сложнее - на SIGALRM вешаем хэндлер, который в очень быстрое хранилище, например Redis, записывает идентификатор процесса и прогресс работы. Нет записи три секунды подряд - желтый статус, пять сек - красный.
Это не проблематично, совершенно реально, делалось сотни раз, работает в проде и PHP прекрасно для такой задачи "предназначен", чтобы вы ни имели в виду.
Вот здесь я с вами категорически не согласен. Они не "не нужны", их просто приходится придумывать самим. Силами программистов, чья квалификация по определению ниже, чем квалификация тех, кто создавал nginx или PHP-FPM.
>> очень низкая у apache+php, это когда сервер апач при каждом запросе читает с диска php-скрипт и выполняет его
Простите за резкость, но зачем этот бред в статье? Никто уже не использует Apache + PHP таким образом. Для работы PHP стандартное решение это FPM (Fast CGI Process Manager) плюс, к примеру, nginx перед ним. И поверьте, это ничуть не медленнее и ничуть не уже по пропускной способности, чем условная NodeJS в задачах "Сделать запрос к БД, отдать JSON". А уж про память и говорить нечего - разница будет на порядок не в пользу NodeJS.
Никогда не понимал, в чем же на самом деле преимущество, за которое так топят сторонники node, go и прочих альтернативных технологий: запихнуть в одно целое сервер приложений, менеджер процессов/потоков и прикладной код. да еще и заставить одних и тех же людей их писать? Вы действительно считаете, что напишете nginx лучше Сысоева? )))
Выбирать нужно не ту систему, которая "строится вокруг канбан-доски", а ту, где эти доски - лишь один из бесконечных вариантов визуализации процессов.
И тут, конечно, никакие поделки не сравнятся с Jira. Просто потому, что поделки строят свои системы "вокруг доски", то есть на неправильном изначально фундаменте.
Методику. Блин, ме-то-ди-ку! Методология - это наука, изучающая методики и, одновременно, научный подход к изучению мыследеятельности и огранизационной работы школы Щедровицкого.
Нет никаких "методологий управления проектами", вашу же мать!
Как можно хотя бы минимально доверять статье, в которой применяются junk-термины?
Мы - это компания "Human+", как генподрядчик разработки и ответственные за "железную часть", и "Спринт-Ф", как основной разработчик бэкенда и фронтенда системы.
Нашел для вас статью: https://vc.ru/tribuna/75525-kak-optimizirovat-krupnoe-proizvodstvo-kontroliruya-rabotu-sotrudnikov , там как раз вспоминают про наш опыт на Ямале и дальнейшее развитие темы.
Альтернатива Редмайну существует ровно одна - это Jira. На своем сервере с «китайской» лицензией. Всё остальное - это попыики имитировать часть функций Jira, причем самую неважную часть.
Очень интересно, зачем каждый раз это разрабатывать заново, если еще 8 лет назад мы на Ямале внедрили в эксплуатацию полностью функциональное решение, причем по функциям на порядок более богатое, чем вы описываете?
>> Чистая архитектура независима от информационных хранилищ. Можно поменять PostgreSQL на MongoDB или на любую другую СУБД. При этом работа бизнес-правил не изменится.
Сложно представить себе более вредное утверждение. В реальности оно звучит так:
- Откажитесь от всех преимуществ специализированных хранилищ ради нулевого шанса на их смену.
Дико тормозить и иметь целый букет ляпов он начал примерно в то же время, когда была разогнана старая команда.
Ну вот и всё, можно начинать отсчет конца ВК.
Ни один подобный проект никогда не приводил к бизнес-успеху. И этот не приведет. Будет потрачен охулиард денег, чтобы сделать плохую и неточную копию того, что уже давно было сделано.
А учитывая, что позиции уровня архитекторов в ВК зачищены от ненужных людей, и учитывая, что ВК отказывается нанимать разработчиков в штат, предпочитая договора с региональными однодневными аутстафф-агентствами - можно себе представить качество этого нового кода.
Запуск делается через менеджер процессов, тоже написанный на PHP. Он следит за тем, чтобы число активных процессов-воркеров не превышало заданный лимит, получает задание для каждого воркера, запускает его, пишет метрики - когда запущен, когда закончился, какой результат.
А как вам поможет супервизор в случае "залипания" процесса на какой-нибудь логической ошибке, вводящей его в бесконечный цикл? Процесс работает, живой. Супервизор не видит проблем, процесс не перезапускает.
Вам в любом случае для долгоживущих процессов нужен свой мониторинг их работы, основанный не на "работает/не работает", но на учете бизнес-логики таких процессов.
Живой пример - делали на таких "управляемых процессах" обработку прайс-листов. Десятков тысяч в сутки, на миллионы позиций каждый (если что - это торговля запчастями). Там естественной метрикой была строка прайс-листа. Пишем в редис раз в секунду инфу, на какой мы сейчас строке файла. Отличная метрика, позволяет сразу же понять, работает ли процесс так, как нам надо, или нет.
Ну и вторая принципиальная разница по сравнению с супервизором - когда вам нужен интерфейс мониторинга и управления процессами, которым сможет пользоваться вторая линия поддержки, вам супервизор не подойдет. Он не наглядный. А нам пришлось делать наглядную панель управления.
В комментарии поделиться не получится - места мало. Но в целом да, делали такое и не раз. Банально на тики, или чуть сложнее - на SIGALRM вешаем хэндлер, который в очень быстрое хранилище, например Redis, записывает идентификатор процесса и прогресс работы. Нет записи три секунды подряд - желтый статус, пять сек - красный.
Где хоть он "популярен"? В статьях на хабре? ))
Это не проблематично, совершенно реально, делалось сотни раз, работает в проде и PHP прекрасно для такой задачи "предназначен", чтобы вы ни имели в виду.
Без всяких "супервизоров, роадраннеров и свулов".
Мне доводилось переписывать достаточно сложный проект с nodejs на php. Но хайпа на этом не словишь, тут вы правы.
Учитывая, что я статью писал с объяснением этого понятия для начинающих, нет, наверное, пока до конца еще не знаю ))
Вот здесь я с вами категорически не согласен. Они не "не нужны", их просто приходится придумывать самим. Силами программистов, чья квалификация по определению ниже, чем квалификация тех, кто создавал nginx или PHP-FPM.
>> очень низкая у apache+php, это когда сервер апач при каждом запросе читает с диска php-скрипт и выполняет его
Простите за резкость, но зачем этот бред в статье? Никто уже не использует Apache + PHP таким образом. Для работы PHP стандартное решение это FPM (Fast CGI Process Manager) плюс, к примеру, nginx перед ним. И поверьте, это ничуть не медленнее и ничуть не уже по пропускной способности, чем условная NodeJS в задачах "Сделать запрос к БД, отдать JSON". А уж про память и говорить нечего - разница будет на порядок не в пользу NodeJS.
Никогда не понимал, в чем же на самом деле преимущество, за которое так топят сторонники node, go и прочих альтернативных технологий: запихнуть в одно целое сервер приложений, менеджер процессов/потоков и прикладной код. да еще и заставить одних и тех же людей их писать? Вы действительно считаете, что напишете nginx лучше Сысоева? )))
Вы просто не умеете ее готовить.
Да и аналогов всё равно нет - с чем сравниваете-то?
Выбирать нужно не ту систему, которая "строится вокруг канбан-доски", а ту, где эти доски - лишь один из бесконечных вариантов визуализации процессов.
И тут, конечно, никакие поделки не сравнятся с Jira. Просто потому, что поделки строят свои системы "вокруг доски", то есть на неправильном изначально фундаменте.
Вы проделали неплохую работу. Но совершенно забыли указать среди аналогов https://symfony.com/doc/current/components/expression_language.html
Методику. Блин, ме-то-ди-ку! Методология - это наука, изучающая методики и, одновременно, научный подход к изучению мыследеятельности и огранизационной работы школы Щедровицкого.
Нет никаких "методологий управления проектами", вашу же мать!
Как можно хотя бы минимально доверять статье, в которой применяются junk-термины?
>> А разницу в коде на Симфе на Яве вы не враз заметите
Замечу. Код на Symfony современных версий будет короче и значительно чище.