К сожалению, не каждый рефакторинг приводит к ускорению разработки ) Иногда даже бывает наоборот — к замедлению. Поэтому и для самой разработки важно осознанно подходить к тому что и зачем мы рефакторим.
И, кстати, ADR, о котором писали выше, сильно помогает эту осознанность повысить
Согласен, часто бывают такие проблемы. Но это проблема в другой плоскости — какие цели у менеджмента, какие цели у вас и как они между собой согласуются. Если не согласуются или даже противоречат друг другу, то вам не то, что о тех.долге не получится договориться, а в целом по всем вопросам будут конфликты.
Что можно сделать? 1) Эскалировать минимальному общему руководителю; 2) договориться 1:1 об общей цели; 3) внедрить единую систему каскадного целеполагания типа OKR; 4) уволить такого менеджера к чертям собачьим. По своему опыту могу сказать, что эти способы работают. Но конечно не всегда 🤷♂️
Спасибо! DoD действительно хорошая и полезная штука, особенно если он составлен совместно разработкой и заказчиком и когда он выполняется. DoD еще и многие другие проблемы позволяет решить
Всё так. Задача менеджера совместить эти желания — дать сотруднику то, что он хочет и получить от него то, что нужно компании. Об этом и говорит цикл перформанс менеджмента. А уж какие инструменты использовать внутри него, не важно, будь это kpi, okr или устные договоренности.
Мы же говорим про тимлидов, которые являются руководителями разработки. А значит, у них обязательны компетенции управления людьми и командой, иначе какие же они руководители? Далее, т.к. у них уже есть команда в подчинении и ряд сервисов в зоне ответственности, появляется необходимость в управлении и развитии этих сервисов: повышение стабильности, эффективности, снижение тех.долга и т.д. Именно тимлид отвечает за технический беклог, отсюда целеполагание и планирование. Кроме того, тимлид отвечает за процессы поставки или процессы разработки: насколько предсказуемо, быстро и качественно его команда поставляет изменения в прод. Вот вам и компетенция по управлению процессами.
Я считаю, что самое важное все же это сильная команда и поэтому компетенции по управлению людьми и командой считаю более важными. Ибо сильная команда и без процессов может хорошо существовать, а слабая команда при хороших процессах будет регулярно постоянно в режиме пожаров
Hadoop рассматривали. Не подошел, аргументов много, в частности нам нужен был инструмент анализа, позволяющий объединять большие разнородные данные (JOIN друг с другом дюжины многомиллиардных таблиц).
Поднимаем docker-образы в minikube-окружении на ноутбуках разработчиков. Чтобы упростить и облегчить окружение многие вещи поднимаются в kubernetes-кластере в датацентре, например снепшоты баз данных, индексы sphinx, staging-версии микросервисов.
Ну и конечно набор самописных скриптов, которые помогают все это развернуть и актуализировать.
Деплой кода хранимых процедур и выкатка миграций – тема для отдельной статьи, когда-нибудь мы её напишем и опубликуем :)
В двух словах, хранимые процедуры выкатываются в новую схему, создаётся пользователь БД у которого в search_path указана эта новая схема. Новый PHP код соединяется с базой под этим новым пользователем и использует код новых хранимых процедур. Это позволяет в любой момент безболезненно откатиться.
Для наката миграций на схемы данных используются небольшие самописные библиотеки. Но автоматически они накатываются только в микросервисах, в большом Avito – только в test и dev средах. Сначала схемы, потом код, чтобы была возможность откатиться.
У нас 20000rps к бекенду, 65 железных серверов с php-монолитом, 300rps на каждый. С переходом на PHP7 каждый сервер смог держать в три раза больше, т.е. до 1000rps держать можем. Подробнее про переход на 7.0 писали тут: https://habrahabr.ru/company/avito/blog/338140/.
В зависимости от задачи. В большинстве случаев сразу, в особо тяжелых – через RabbitMQ, либо через pgq. В кэши пишем сразу, в кэши пишем много.
У нас нет MySQL. Мы используем PostgreSQL с PgBouncer'ами, которые эту проблему решают.
Работаем, у нас более 70Тб в Вертике. Храним и анализируем все, что можем. Тут про это писали: https://habrahabr.ru/company/avito/blog/322510/
Нейросети используются для распознавания изображений. Предсказываем всякое, например вероятность клика пользователем по рекламному объявлению в Авито.Контекст.
Распознавание изображений только начинает внедряться и обкатываться, куда именно пока сказать не могу.
Эффективность рекомендаций измеряется конечно автоматически, в т.ч. через A/B-тесты
Один контейнер с nginx, второй контейнер с php-fpm, где располагается и код.
В качестве API Gateway в данный момент используется сам монолит Avito :) Но есть отдельные кейсы, когда перед пачкой однотипных микросервисов стоит прослойка-gateway. Например у нас есть несколько разных рекомендательных сервисов, ответы которых собираются такой вот прослойкой и отдаются в Avito.
Интересный взгляд на эту проблему, спасибо! Есть о чем задуматься
К сожалению, не каждый рефакторинг приводит к ускорению разработки ) Иногда даже бывает наоборот — к замедлению. Поэтому и для самой разработки важно осознанно подходить к тому что и зачем мы рефакторим.
И, кстати, ADR, о котором писали выше, сильно помогает эту осознанность повысить
Согласен, часто бывают такие проблемы. Но это проблема в другой плоскости — какие цели у менеджмента, какие цели у вас и как они между собой согласуются. Если не согласуются или даже противоречат друг другу, то вам не то, что о тех.долге не получится договориться, а в целом по всем вопросам будут конфликты.
Что можно сделать? 1) Эскалировать минимальному общему руководителю; 2) договориться 1:1 об общей цели; 3) внедрить единую систему каскадного целеполагания типа OKR; 4) уволить такого менеджера к чертям собачьим. По своему опыту могу сказать, что эти способы работают. Но конечно не всегда 🤷♂️
Спасибо! DoD действительно хорошая и полезная штука, особенно если он составлен совместно разработкой и заказчиком и когда он выполняется. DoD еще и многие другие проблемы позволяет решить
А когда прижмет, тогда нужно выскочить и гордо произнести: "Ну я же говорил 🤌".
А если серьезно, то конечно бывает и так. Все зависит от степени доверия бизнеса к разработке, которое на 95% зависит от умения укладываться в сроки
Всё так. Задача менеджера совместить эти желания — дать сотруднику то, что он хочет и получить от него то, что нужно компании. Об этом и говорит цикл перформанс менеджмента. А уж какие инструменты использовать внутри него, не важно, будь это kpi, okr или устные договоренности.
Мы же говорим про тимлидов, которые являются руководителями разработки. А значит, у них обязательны компетенции управления людьми и командой, иначе какие же они руководители? Далее, т.к. у них уже есть команда в подчинении и ряд сервисов в зоне ответственности, появляется необходимость в управлении и развитии этих сервисов: повышение стабильности, эффективности, снижение тех.долга и т.д. Именно тимлид отвечает за технический беклог, отсюда целеполагание и планирование. Кроме того, тимлид отвечает за процессы поставки или процессы разработки: насколько предсказуемо, быстро и качественно его команда поставляет изменения в прод. Вот вам и компетенция по управлению процессами.
Я считаю, что самое важное все же это сильная команда и поэтому компетенции по управлению людьми и командой считаю более важными. Ибо сильная команда и без процессов может хорошо существовать, а слабая команда при хороших процессах будет регулярно постоянно в режиме пожаров
Какое оборудование и сколько рассказать не можем.
Postgres, Redis, Tarantool, Memcache, Sphinx шардируется во многих случаях. Про обслуживание Postgres рассказывали на разных конференциях, например https://habrahabr.ru/company/oleg-bunin/blog/311472/
Hadoop рассматривали. Не подошел, аргументов много, в частности нам нужен был инструмент анализа, позволяющий объединять большие разнородные данные (JOIN друг с другом дюжины многомиллиардных таблиц).
Можно использовать ваши исторические данные о товарах, это уже хорошая база. Можно использовать простые эвристики.
Поднимаем docker-образы в minikube-окружении на ноутбуках разработчиков. Чтобы упростить и облегчить окружение многие вещи поднимаются в kubernetes-кластере в датацентре, например снепшоты баз данных, индексы sphinx, staging-версии микросервисов.
Ну и конечно набор самописных скриптов, которые помогают все это развернуть и актуализировать.
Мы используем глубокие сверточные нейросети аля-imagenet для классификации изображений и рекуррентные нейросети для анализа текста.
Про резервное копирование БД подробно рассказывали на HighLoad++ https://habrahabr.ru/company/oleg-bunin/blog/311472/. Для управления бекапами используем Bacula.
Деплой кода хранимых процедур и выкатка миграций – тема для отдельной статьи, когда-нибудь мы её напишем и опубликуем :)
В двух словах, хранимые процедуры выкатываются в новую схему, создаётся пользователь БД у которого в search_path указана эта новая схема. Новый PHP код соединяется с базой под этим новым пользователем и использует код новых хранимых процедур. Это позволяет в любой момент безболезненно откатиться.
Для наката миграций на схемы данных используются небольшие самописные библиотеки. Но автоматически они накатываются только в микросервисах, в большом Avito – только в test и dev средах. Сначала схемы, потом код, чтобы была возможность откатиться.
Коллеги подсказывают, что у меня сильно старые данные. На сегодняшний день в Вертике 142Тб.
Работаем, у нас более 70Тб в Вертике. Храним и анализируем все, что можем. Тут про это писали: https://habrahabr.ru/company/avito/blog/322510/
Нейросети используются для распознавания изображений. Предсказываем всякое, например вероятность клика пользователем по рекламному объявлению в Авито.Контекст.
Распознавание изображений только начинает внедряться и обкатываться, куда именно пока сказать не могу.
Эффективность рекомендаций измеряется конечно автоматически, в т.ч. через A/B-тесты
Про нашу систему мониторинга есть подробная статья: https://habrahabr.ru/company/avito/blog/335410/
Если кратко, то collectd+heapster+brubeck+graphite+grafana+moira