Всё так. Задача менеджера совместить эти желания — дать сотруднику то, что он хочет и получить от него то, что нужно компании. Об этом и говорит цикл перформанс менеджмента. А уж какие инструменты использовать внутри него, не важно, будь это 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.
А у нас в Avito нормальный бюджет. И PHP-шники получают не меньше коллег с других языков. Да и вообще мы стараемся развивать и брать разработчиков-полиглотов.
Дело же не в языке, а в умении решать задачи.
Советовать что-то очень сложно. Авторизация нужна, само собой. Как ее делать – решать только вам, исходя из вашей специфики. Сейчас всё идет в сторону "социализации" – авторизации через соц.сеточки, посмотрите в эту сторону.
Для нас это не трудоемко. Решение, которое реализовали в самом начале зарождения Avito, работает до сих пор, особо не меняясь, потому что использовались максимально простые и эффективные решения. Когда-нибудь про хранение и обработку фоточек будет отдельный рассказ. Очень-очень кратко есть в докладике на 28-м слайде https://www.slideshare.net/pavlushko/avito-2013. Хранить ли на своих серверах или отдавать на сторонний хостинг – решать опять же только вам, что будет вам будет выгоднее и надежнее. Мы всегда придерживались первого.
Личные обсуждения продавца с покупателем конечно нужны. Реализация публичного обсуждения кажется сомнительной.
Сложных технических задач очень много и это не только борьба со спамом, с мошенниками или релевантность поиска. Идей про поиск и релевантность у нас было очень много, причин не отдавать это на "аутсорс" тоже много.
Тут все зависит от вашей специфики: публикации, редактирования, платные/бесплатные поднятия и многое другое.
Всё так. Задача менеджера совместить эти желания — дать сотруднику то, что он хочет и получить от него то, что нужно компании. Об этом и говорит цикл перформанс менеджмента. А уж какие инструменты использовать внутри него, не важно, будь это 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
Все, что связано с машинным обучением в Avito – это все сплошная история успеха Python: антифрод, распознавание изображений, сервисы рекомендаций.
Про API думаем и даже делаем. Пока обкатываем на внутренних проектах. А расскажите, какие у вас потребности в открытом API Авито?
В первую очередь стоит изучить документацию https://www.postgresql.org/docs/, она написана очень хорошо и подробно. Много полезной информации обсуждается в рассылках: https://www.postgresql.org/list/. Также советуем посмотреть обучающие видео или пройти курсы от Postgres Pro: https://postgrespro.ru/education/courses
А у нас в Avito нормальный бюджет. И PHP-шники получают не меньше коллег с других языков. Да и вообще мы стараемся развивать и брать разработчиков-полиглотов.
Дело же не в языке, а в умении решать задачи.
Советовать что-то очень сложно. Авторизация нужна, само собой. Как ее делать – решать только вам, исходя из вашей специфики. Сейчас всё идет в сторону "социализации" – авторизации через соц.сеточки, посмотрите в эту сторону.
Для нас это не трудоемко. Решение, которое реализовали в самом начале зарождения Avito, работает до сих пор, особо не меняясь, потому что использовались максимально простые и эффективные решения. Когда-нибудь про хранение и обработку фоточек будет отдельный рассказ. Очень-очень кратко есть в докладике на 28-м слайде https://www.slideshare.net/pavlushko/avito-2013. Хранить ли на своих серверах или отдавать на сторонний хостинг – решать опять же только вам, что будет вам будет выгоднее и надежнее. Мы всегда придерживались первого.
Личные обсуждения продавца с покупателем конечно нужны. Реализация публичного обсуждения кажется сомнительной.
Сложных технических задач очень много и это не только борьба со спамом, с мошенниками или релевантность поиска. Идей про поиск и релевантность у нас было очень много, причин не отдавать это на "аутсорс" тоже много.