«Баннерная крутилка» —  один из самых высоконагруженных сервисов в Яндексе. Он умеет переживать 700 тысяч RPS, а иногда и больше. Каждый раз, когда приходит запрос, крутилка должна просмотреть базу из миллиарда документов и выбрать из них самые релевантные для пользователя. При этом выдерживаются весьма жесткие временные рамки: 99% всех запросов обрабатываются менее чем за 200 миллисекунд.

Какими принципами стоит руководствоваться при построении подобных высоконагруженных систем? Как устроены стадии отбора документов? Какое участие в ранжировании принимает ML? Обо всём этом на недавнем мероприятии для разработчиков в Ереване рассказал Артём Ваншулин, руководитель разработки ранжирования в команде баннерной системы. Сегодня мы делимся с сообществом текстовой версией его доклада. Передаём ему слово.

Всем привет! Я Виктор Брыксин, руковожу разработкой Яндекс Телемоста. В статье поговорим про декомпозицию задач в проекте и как можно получить реальные сроки его выполнения.

Спойлер: вы все равно ошибетесь, прогнозируя сроки. Но что можно сделать? Минимизировать шанс на ошибки и сделать их менее фатальными. Я расскажу про рабочие инструменты, которые помогли мне в свое время, — брать их на вооружение или нет, решайте сами. Если вы не знаете, как подступиться к декомпозиции сложного проекта и с чего начать, — эта статья вам в помощь.

В этой статье рассказываю, что побудило меня создать свой API для конвертации валют и получения актуального курса от различных источников. Начиная от анализа потребностей в онлайн-платежах и заканчивая разработкой гибкого и эффективного микросервиса. Демонстрирую вызовы, с которыми столкнулся в процессе разработки, а также описываю функциональности и возможности созданного сервиса. Приглашаю к обсуждению и обмену опытом в этой области.

Пишем синхронный сервер

void naive_accept() {
  for (;;) {
    auto new_socket = accept(listener);

    std::thread thrd([socket = std::move(new_socket)] {
      auto data = socket.receive();
      process(data);
      socket.send(data);
    });

    thrd.detach();
  }
}

Привет, меня зовут Панов Михаил, я DevOps‑инженер МТС Digital. Хочу поделиться с вами опытом построения «модульных» pipelines на основе gitlab-ci. В этой статье я расскажу, что такое модульный CI/CD, из чего он состоит, для чего нужен и как поможет командам, поддерживающим большой список нетиповых репозиториев.

У технологии eBPF много поклонников. Она предлагает множество плюсов, но в работе с ней есть и некоторые минусы, сложности и ограничения. Давайте разберемся со всем этим.

Данный материал подготовлен на базе выступления “eBPF в production-условиях” от Дмитрия Евдокимова и Александра Трухина из компании Luntry с конференции HighLoad++ 2022. Он будет полезен как компаниям, что используют внутри себя решения на базе eBPF, так и разработчикам, которые что-то пишут или планируют писать с использованием данной технологии.

Привет, Хабр!

Технология eBPF становится все более популярной и используются во многих приложениях для Linux. В нашей статье Анализ и обнаружение Dirty Pipe мы коснулись темы eBPF и как он может помочь при обнаружении эксплуатации уязвимостей ядра. Но инструмент с такими возможностями непременно заинтересует и злоумышленников. В этой статье мы рассмотрим, каким образом атакующие могут использовать eBPF и как можно их обнаружить.

Для загрузки eBPF модуля необходимы права root или привилегии CAP_BPF. Поэтому в основном злоумышленники используют данные программы для закрепления или сокрытия вредоносного ПО в системе. Для этого используются различные наборы инструментов, основанных на eBPF. В данной статье мы рассмотрим известные вредоносные eBPF инструменты и возможные способы детектирования.

В открытом доступе есть различное вредоносное ПО, основанное на eBPF, мы выбрали наиболее многофункциональные:

https://github.com/Gui774ume/ebpfkit
https://github.com/pathtofile/bad-bpf
https://github.com/krisnova/boopkit
https://github.com/h3xduck/TripleCross

Данные инструменты имеют множество различных функций, которые вы бы вряд ли хотели увидеть у себя в инфраструктуре. Их возможности могут вас удивить, так как они могут:

Всем привет! Я Сергей, работаю в B2B-команде Яндекс Маркета последние 3,5 года. Как уже понятно из заголовка, сейчас я вам расскажу про yet-another-миграцию с базы на базу, которая началась в середине 2021 года и заняла почти год. Получается, мемуары.

Вас ждёт рассказ о том, как мы:

- несколько месяцев чинили тесты и делали трансформер;

- десятки раз переливали данные;

- чинили баги незаметно для пользователей;

- заставили сервис работать на PostgreSQL быстрее, чем он работал на Oracle.

Задумывались ли вы о том, как изменить конфигурацию сразу на нескольких сетевых устройствах? Что, если нужно сделать это на всей сети с сотнями и тысячами единиц оборудования? А что, если приходится делать это каждый месяц на железе от пяти разных производителей? Очевидное решение для подобных задач — автоматизация. Но реализовать её можно не одним способом, а в процессе наткнуться не на одни грабли.

Меня зовут Вадим Воловик, и я руковожу проектами разработки в Yandex Infrastructure. Наша команда NOCDEV отвечает за автоматизацию сетей всего Яндекса. Давно хотелось рассказать о задачах такого масштаба, но по ходу написания материала стало понятно, что тема тянет на целый цикл. Так что мы с коллегами расскажем о самых интересных примерах автоматизации в отдельных постах.

В этой статье проведём небольшую экскурсию по нашему сетевому «хозяйству» в десятки тысяч устройств и остановимся подробнее на том, как при таком объёме мы автоматически обновляем конфигурации.

Эта статья основана на истории об одном личном челлендже. Задача звучала так: помочь с реализацией взаимодействия компонентов в программном комплексе заказчика. Иными словами, понадобилось IPC для дальнейшего развития продукта. Вызов заключался в том, что в обязательных требованиях стояло использование чистого С. Другие языки, включая С++ и Go, не рассматривались. 

В итоге я получил интересный опыт в рамках системного и параллельного программирования. Меня зовут Алексей Буреев, я работаю старшим инженером по разработке ПО в YADRO, сейчас мой основной рабочий язык программирования — Golang. В этой статье я проведу небольшой эксперимент: покажу, как можно решить одну задачу с помощью разных языков программирования. Языку С я противопоставлю Go, в основе которого есть исторические наработки проектирования языка С. Для этого немного заглянем «под капот» стандартных типов данных, которые уже были заботливо созданы для нас разработчиками языка.

Всех заинтересованных прошу под кат.

Привет, Хабр!

Golang как ЯП очень хорош для разработки высокопроизводительных приложений. В любом проекте наступает момент, когда нужно проверить, насколько хорошо все работает на самом деле, это можно сделать с помощью тестирования.

Тестирование в Go можно выполнять с помощью mock-объектов, fuzzing и property-based testing. В этой статье мы рассмотрим эти механизмы.

В подробном лонгриде к старту курса по анализу данных вы найдёте авторские визуализации, пояснения и комментарии об искусстве сравнивать распределения и делать выводы.

Статистические исследования и эксперименты являются краеугольным камнем развития любой компании. Особенно это касается интернет-проектов, где учёт количества пользователей в день, времени нахождения на сайте, нажатий на целевые кнопки, покупок товаров является обычным и необходимым явлением. Любые изменения в пользовательском опыте на сайте компании (внешний вид, структура, контент) приводят к изменениям в работе пользователя и, как результат, изменения наблюдаются в собираемых данных. Важным элементом анализа изменений данных и его фундаментом является использование основных типов распределений случайных величин, от понимания которых напрямую зависит качество оценки значимости наблюдаемого изменения. Рассмотрим их подробнее на наглядных примерах.

TL;DR В статье рассказывается о том, как мне удалось перевести чтение лент в ВКонтакте**, Telegram, Facebook*, Instagram**, Reddit и почтовых рассылок в единый сервис InoReader. Причем почти без написания своих велосипедов.

Привет, Хабр! Меня зовут Николай Суворов. Я – профессиональный менеджер, руководитель направления Delivery Management в МТС Digital. Занимаюсь Enablement Platform – единой платформой для быстрого создания продуктов в экосистеме МТС. Сегодня я расскажу о своем pet-проекте и о том, как я заменил привычный, но такой недоступный Evernote прекрасным менеджером заметок Obsidian. Статья будет интересна прежде всего тем, кто хочет обладать «вторым мозгом» и ни о чем не забывать.

Вот я и дописал свою четвёртую статью на хабр (А ведь в начале года поставил себе цель написать хотя бы одну статью, а тут аппетит пришёл во время еды и вот четвёртая). Предыдущие раз, два и три.

Вообще бесит когда в современном мире пишут статьи-гайды или снимают видео-гайды, где самое интересное в конце. "Вы сначала дайте посмотреть что я приобрету прочитав вашу статью или посмотрев видео, а я уже приму решение смотреть или нет".

Поэтому вот сразу ссылка на мой сетап хранилища Обсидиана на гитхабе (о котором и пойдёт речь в данной статье), можно сразу его качать и тыкаться самому и если что-то не понятно подглядывать в статью. (Надо распаковать zip-файл в папку, а потом открыть открыть обсидиан и при выборе хранилища выбрать эту папку, куда распаковали zip-файл. Если у вас одно хранилище, то тогда жмём в левом нижнем углу кнопку сейфа)

В моём сетапе я попытался реализовать возможность управлять проектами, годовыми и месячными целями, ставить себе задачи, смотреть по ним статистику в разрезе ролей.

В этом хранилище используются 10 плагинов, основные:

- Calendar - для календаря справа.

- Dataview - для статистики и для проектов.

- Tasks - для задач.

- Templater - для шаблонов и чтобы нужные заметки с запросами создавались в нужных папках и с нужными данными в запросах.

К такой настройке я шёл целый год используя обсидиан, постоянно дорабатывал её и искал "совершенство", в ней собраны разные подходы из разных статьей и книг (GTD, 7 навыков, Джедайские техники, Атомные привычки), данные подходы большинству могут быть знакомы. Но есть метод, до которого я дошёл сам и до этого я нигде его не встречал (возможно просто не попадался) - это метод одной задачи.

Disclaimer1: Мой сетап не претендует на "идеальность", в нём найдутся минусы и неудобности. Я выношу его на общее обсуждение в том числе для того, чтобы кто-то мог предложить ту или иную доработку тут в комментариях, а так же для того, чтобы новички могли сходу вкатиться в этот чудесный обсидиановый мир.
Disclaimer2: Обычно обсидиан ассоциируют с Zettelkasten, графами и прочими атомарными заметками. Я в своём подходе этого не использую, возможно еще не дорос, возможно мой подход немного про другое. В этой статье я пишу не про это.

Без особой помпы вышла новая версия Proxmox Virtual Environment - 7.1. Эта опенсорс-платформа виртуализации, построенная на базе Debian, KVM, LXC, Ceph, давно зарекомендовала себя. Авторы, кстати, говорят о более чем полумиллионе хостов, где она развернута.

Новая версия Proxmox Virtual Environment несёт несколько новых функциональных возможностей и множество улучшений для задач управления через веб-интерфейс: поддержка Windows 11, включая TPM, улучшенный мастер создания ВМ/контейнера, возможность устанавливать политики сохранения резервных копий для каждого задания резервного копирования в графическом интерфейсе, а также новый демон-планировщик, поддерживающий более гибкие расписания.

Вот подборка основных моментов (и видео с показом):