Спасибо за обратную связь и вопросы! Отвечу на ваши вопросы.
Таких проблем не должно быть, если Тимлид синхронизирован с командой, понимает ее темп и возможности. Опытный Тимлид имеет хороший уровень экспертизы и погружение в контекст команды разработки – это позволяет дать наиболее адекватную оценку по срокам. Но конечно же Тимлид берет на себя ответственность за сроки, которые он назвал. Если сроки на каком то из этапов разработки начнут расходиться, важно погрузить в это бизнес заказчика и вместе проговорить компромиссное решение.
К оценке трудозатрат командой я отношусь нейтрально. Собираться всей командой и пытаться оценивать проект я бы не стал. Как правило, разработчики сильно погружаются в детали, и весь процесс оценки сильно усложняется, не просто фасилитировать такое обсуждение. Гораздо проще накидать предварительную декомпозицию проекта на отдельные модули/этапы, и там где меньше экспертизы посинкаться с экспертами в направлении – это сделать гораздо быстрее и проще. Когда то давно мы также пробовали внедрять покер планирование, но спустя небольшое время отказались, тк большой пользы не увидели. Но даже покер планирование требует предварительной проработки и декомпозиции проекта на задачи.
Архитектурные ревью мы проводим в рамках процесса с RFC и ADR. Когда прорабатывается какой либо проект, разработчик или системный аналитик готовит RFC, который должны посмотреть люди из состава архитектурного комитета, но при этом. любой член команды может также посмотреть RFC и оставить свои замечания/предложения. Архитектурный комитет состоит из старших и ведущих разработчиков.
Необязательно быть рок старом или архитектором, чтобы пройти собеседование по system design, достаточно быть технически эрудированным и иметь соответствующий опыт. Быть просто менеджером и отвечать за команду разработки, конечно же, не получится
Причиной нашего перехода на k8s было не обеспечение надежной бесперебойной работы бэкэнда, все прекрасно работало и на виртуалках, и с этим было довольно просто работать, бесшовно релизить, оперативно устранять неисправности и т.д.
Kubernetes нам существенно облегчил жизнь, когда вместо одного приложения, работающего на двух машинах у нас стало 10+ сервисов, часть из которых являются горизонтально масштабируемыми. Главная причина использования оркестратора это избежать обслуживания большого количество виртуалок и докер контейнеров.
А для повышения надежности можно использовать два физически разделенных k8s кластера с установленной рабочей версией приложения, а внешний балансировщик будет форвардить трафик на один исправный кластер, мы сейчас думаем переходить на такое решение.
Мы посторались реализовать простое легко масштабируемое решение с минимальной конфигурацией. Возможно мы не учли всех узких мест в реализации, но цель мы достигли, производительность сохранили, согласованность не потеряли. А решение можно доработать в случае обнаружения потенциальных проблем.
А как быть, если мобильный клиент использует десятки различных сервисов и берет данные из сотен методов. Если несколько серверов отваливается, то клиент будет их опрашивать какое то время, расходуя трафик и ресурс. Тут нужен контракт сколько раз опрашивать, с какой периодичностью, как понять, что сервис лежит, что при этом показывать клиенту. Кажется что в таком решении ещё множество подводных камней. Проще и правильнее на мой взгляд поддерживать бесперебойную работу бэкэнда и бесшовно релизить новые версии.
К тому же большинство клиентов как только не увидят какую то информацию сразу же пишут в поддержку, а это уже влечёт расход человек часов на обслуживание таких претензий.
Я имер ввиду репликацию IMDG кластеров.
Репликация в Hazelcast довольно сложно устроена, конечно она учитывает множество тех самых "тонких мест". Но судя по отзыву коллег, использование Hazelcast влечёт за собой существенное увеличение потребления CPU и памяти. После выпиливания Hazelcast тесты показали существенное уменьшение этих показателей. Всё таки обычная реализация кэша выигрывает, как минимум отсутствует необходимость постоянной сериализации/десериализации. Также ввиду сложности устройства IMDG решений, люди сталкивались с проблемой конфигурации, когда количество узлов приложения >2. Сталкивались с проблемой дублирования и потерей информации при выкатывании новых версий приложения.
При нагрузке в 500 rps за 2 секунды мы потеряем 1000 запросов от клиентов. Клиенты, которые не получат свои данные, открыв мобильное приложение, будут жаловаться на нестабильную работу. Недоступность сервиса приведёт к недовольным клиентам
Резонное замечание. Мы с таким еще не сталкивались. Предполагаю, что в таком случае либо readiness-проба настроена недолжным образом, либо неправильно настроен health-check приложения. Хотя, кажется, что под может убить только liveness-проба
Тормоза в приложениях зачастую бывают если на каком то участке образуется узкое горлышко, например образуется очередь ожидания в пуле соединений к БД или очередь потоков в пуле вебсервера. В этом случае может помочь Readiness проба, временно отключив трафик на проблемный узел. Тормоза могут возникнуть также если на узле отвалился внешний кэш или же проблема с самой виртуалкой, на которой создан под, переполнился heap, и тд, мы можем дать узлу приложения какое то время чтобы придти в себя, а если это не помогло просто поднять новый под сервиса и перевести часть трафика на него. Конечно если проблема в самом приложении нас это не спасет. Но если вдруг достигнут предел пропускной способности можно так же использовать механизм Autoscaling (HorizontalPodAutoscaler) в k8s
Об этой проблеме мы знаем и сейчас ищем пути как это разрешить. Например, есть категория «Популярное» с 10-20 спецпредложениями. Еще мы пытаемся проанализировать, что клиент может потенциально хотеть и в скором времени будем также рекомендовать 10-20 спецпредложений индивидуально для каждого
Ну смотри, у тебя есть бизнес и ты хочешь увеличить продажи и решил давать кэшбэк за покупки. Тебе же будет лучше, если люди, прежде чем что то у тебя купить, зайдут в мобильный банк и посмотрят на твое спецпредложение (нажмут кнопку активировать), или лучше чтоб люди пост факт получили от тебя кэшбэк и узнали, что у тебя было спецпредложение (это и есть слепой отклик)? С активацией ты сам можешь выбирать как давать людям кэшбэк
Для работы с питоном Jupiter определенно лучше, но Zeppelin более гибкий инструмент, и относительно легко кастомизируемый под свои нужды. А еще у Zeppelin более удобное REST API
Активация дает некоторую гибкость партнеру при выборе трансляции его спецпредложений. Если у спецпредложения автоактивация, возникает риск слепого отклика
Спасибо за обратную связь и вопросы! Отвечу на ваши вопросы.
Таких проблем не должно быть, если Тимлид синхронизирован с командой, понимает ее темп и возможности. Опытный Тимлид имеет хороший уровень экспертизы и погружение в контекст команды разработки – это позволяет дать наиболее адекватную оценку по срокам. Но конечно же Тимлид берет на себя ответственность за сроки, которые он назвал. Если сроки на каком то из этапов разработки начнут расходиться, важно погрузить в это бизнес заказчика и вместе проговорить компромиссное решение.
К оценке трудозатрат командой я отношусь нейтрально. Собираться всей командой и пытаться оценивать проект я бы не стал. Как правило, разработчики сильно погружаются в детали, и весь процесс оценки сильно усложняется, не просто фасилитировать такое обсуждение. Гораздо проще накидать предварительную декомпозицию проекта на отдельные модули/этапы, и там где меньше экспертизы посинкаться с экспертами в направлении – это сделать гораздо быстрее и проще. Когда то давно мы также пробовали внедрять покер планирование, но спустя небольшое время отказались, тк большой пользы не увидели. Но даже покер планирование требует предварительной проработки и декомпозиции проекта на задачи.
Архитектурные ревью мы проводим в рамках процесса с RFC и ADR. Когда прорабатывается какой либо проект, разработчик или системный аналитик готовит RFC, который должны посмотреть люди из состава архитектурного комитета, но при этом. любой член команды может также посмотреть RFC и оставить свои замечания/предложения. Архитектурный комитет состоит из старших и ведущих разработчиков.
Необязательно быть рок старом или архитектором, чтобы пройти собеседование по system design, достаточно быть технически эрудированным и иметь соответствующий опыт. Быть просто менеджером и отвечать за команду разработки, конечно же, не получится
Все верно, и не противоречит написанному в статье 😊
Считаете этого будет достаточно? 😊
Kubernetes нам существенно облегчил жизнь, когда вместо одного приложения, работающего на двух машинах у нас стало 10+ сервисов, часть из которых являются горизонтально масштабируемыми. Главная причина использования оркестратора это избежать обслуживания большого количество виртуалок и докер контейнеров.
А для повышения надежности можно использовать два физически разделенных k8s кластера с установленной рабочей версией приложения, а внешний балансировщик будет форвардить трафик на один исправный кластер, мы сейчас думаем переходить на такое решение.
Мы посторались реализовать простое легко масштабируемое решение с минимальной конфигурацией. Возможно мы не учли всех узких мест в реализации, но цель мы достигли, производительность сохранили, согласованность не потеряли. А решение можно доработать в случае обнаружения потенциальных проблем.
А как быть, если мобильный клиент использует десятки различных сервисов и берет данные из сотен методов. Если несколько серверов отваливается, то клиент будет их опрашивать какое то время, расходуя трафик и ресурс. Тут нужен контракт сколько раз опрашивать, с какой периодичностью, как понять, что сервис лежит, что при этом показывать клиенту. Кажется что в таком решении ещё множество подводных камней. Проще и правильнее на мой взгляд поддерживать бесперебойную работу бэкэнда и бесшовно релизить новые версии.
К тому же большинство клиентов как только не увидят какую то информацию сразу же пишут в поддержку, а это уже влечёт расход человек часов на обслуживание таких претензий.
Я имер ввиду репликацию IMDG кластеров.
Репликация в Hazelcast довольно сложно устроена, конечно она учитывает множество тех самых "тонких мест". Но судя по отзыву коллег, использование Hazelcast влечёт за собой существенное увеличение потребления CPU и памяти. После выпиливания Hazelcast тесты показали существенное уменьшение этих показателей. Всё таки обычная реализация кэша выигрывает, как минимум отсутствует необходимость постоянной сериализации/десериализации. Также ввиду сложности устройства IMDG решений, люди сталкивались с проблемой конфигурации, когда количество узлов приложения >2. Сталкивались с проблемой дублирования и потерей информации при выкатывании новых версий приложения.
Если есть решение без использования репликации, почему бы не использовать его?)
При нагрузке в 500 rps за 2 секунды мы потеряем 1000 запросов от клиентов. Клиенты, которые не получат свои данные, открыв мобильное приложение, будут жаловаться на нестабильную работу. Недоступность сервиса приведёт к недовольным клиентам
Уже нет) разворачивали инфраструктуру в Google Cloud, а там все платно