Меня зовут Алексей Афонин, я старший дизайнер продукта в Yandex Cloud. В прошлом году нам понадобилось полностью изменить внешний вид нашего сервиса для бизнес‑аналитики DataLens перед его выходом в опенсорс. Разработчики и дизайнеры интерфейсов часто сталкиваются с подобными задачами: есть уже работающий сервис, но его нужно стилизовать, например, в случае ребрендинга или при необходимости учесть специфический пользовательский опыт.

В наших продуктах мы пользуемся дизайн‑системой и библиотекой компонентов Gravity UI — это проект Yandex Cloud, который не так давно тоже вышел в опенсорс. В этой статье я поделюсь опытом, как мы решили задачу «перекрашивания DataLens» с её помощью. Но даже если вы не используете DataLens и ещё не знакомы с Gravity UI, наши наработки могут пригодиться командам разработчиков и дизайнеров, которые хотят стилизовать свои продукты быстрее и удобнее.

Yandex Query Language (YQL) — универсальный декларативный язык запросов к системам хранения и обработки данных, разработанный в Яндексе. А ещё это один из самых нагруженных сервисов: YQL ежедневно обрабатывает около 800 петабайт данных и 600 000 SQL-запросов, и эти показатели постоянно растут. 

Изначально YQL основывался на операциях MapReduce, которые эффективны для больших данных. Но для средних объёмов данных (до 50 Гб, которые составляют около 60% запросов) этот подход оказался неоптимальным, потому что нужно было обмениваться данными между операциями через диск. Поэтому разработчики создали новый более гибкий стриминговый движок, который значительно ускоряет обработку данных за счёт выполнения всех вычислений в памяти.

В этой статье я хочу рассказать о подходах и технологиях в разработке систем для обработки данных на примере YQL. Основное внимание я уделил переходу от MapReduce к стриминговому движку, который обеспечивает более эффективную обработку данных, вмещающихся в память, и который доступен в опенсорсе.

Меня зовут Александр, я руковожу направлением больших данных в Битрикс24. Клиенты нашего сервиса хранят миллиарды файлов: от документов до фотографий, — а моя команда предоставляет возможность строить бизнес-аналитику на основе этого множества данных. И нам важно позаботиться об их сохранности.

Более 10 лет назад мы продумали необходимую нам схему репликации объектного хранилища в облаке. Затем файлы клиентов потребовалось перенести в другое облако, и нам очень хотелось также перенести все наши наработки в режиме «Ctrl+C, Сtrl+V».

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

Traffic Engineering помогает нам решать проблемы оценки и оптимизации производительности IP‑сетей, но при этом требует недюжинного понимания сетевых технологий и протоколов, которые используются в больших сетях. В прошлый раз мы остановились на магии работы PCE-контроллера и затронули Stateless и Stateful PCE. Как здесь не вспомнить комикс от Go Chronicles, посвящённый Stateful.

Конечно, на самом деле PCE-контроллер общается не так, а с использованием PCEP — Path Computation Element Communication Protocol, который описан в RFC 5440. Так что самое время начать с него вторую часть нашей истории про Traffic Engineering. 

В Yandex Cloud с сегодняшнего дня открыт доступ к тестированию API YandexART — нейросети для генерации изображений и анимаций, которая лежит в основе приложения Шедеврум. Протестировать API можно в сервисе Foundation Models, в котором доступно несколько моделей машинного обучения, включая YandexGPT для генерации текстов и эмбеддинги для задач семантического поиска. 

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

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

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

Привет, я Паша, разработчик в Yandex Infrastructure, и я катаю гусей. С 2019 года я развиваю S3-хранилище как для внутренних пользователей Яндекса, так и для клиентов Yandex Cloud. А «гусём» называется наш бэкенд S3 API: он написан на Go, а из словосочетания Go + S3 получился goose. Возможно, вы также слышали про GeeseFS — это наш высокопроизводительный FUSE-клиент для S3. C его помощью вы можете на своём ноутбуке или виртуалке подмонтировать папку, которая будет работать с бакетом S3. 

Для чего нам «гуси» и прочая орнитология? Яндексовая инсталляция хранилища S3 хранит миллиарды файлов. Это огромные объёмы данных, а также метаданных. Для хранения метаданных мы научились использовать умное шардирование, и теперь сами управляем распределением занятого места и нагрузкой между шардами баз.

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

Меня зовут Егор Литвиненко. Я старший разработчик Yandex Observability Platform. Летом 2023 года я рассказывал на Saint Highload в Санкт-Петербурге про наш путь внедрения YDB CDC для обновления данных в сервисах, чтобы решить проблему инвалидации кешей.

В этой статье будет вся история внедрения с теорией, вопросами, ответами, ошибками, о которых я говорил на выступлении. Но кроме того, в конце есть обновления: что произошло и изменилось за это время. Мы рассмотрим весь процесс от появления задачи до результата:

• Какие подходы к доставке изменений мы использовали.

• Почему выбрали переход на CDC и в чём были сложности в работе с изменениями до этого. 

• Чем YDB CDC отличается от других решений, как настроить правильно, и на какие грабли мы наступили в процессе.

• Какую модель данных выбрать, чтобы решить проблемы с конкурентными изменениями.

• Как поддерживать решение после внедрения.

Всем привет! Меня зовут Максим, я работаю системным инженером в Yandex Cloud и в Яндекс Практикуме на курсе «Системный администратор». В этой статье я опишу свой субъективный взгляд на путь развития системного инженера (DevOps‑инженера, SRE, системного администратора).

Системный инженер — ключевой игрок в создании и поддержании сложных информационных систем. Он объединяет в себе знания из различных областей: от аппаратной части и инфраструктуры до программного обеспечения и сетей.

В дополнение к этой статье я создал:

- диаграмму на roadmap.sh;

- git‑репозиторий со ссылками на ресурсы для изучения (жду ваших пул‑реквестов).

Извечный вопрос: должен ли тимлид обладать самой крутой технической экспертизой в команде? Споры будут идти ещё много тысячелетий, но где, как не в крупной компании, лучше в этом разобраться?

Сегодня поговорим о техническом лидерстве, где оно может лежать в команде разработки, обязательно ли это тимлид или всё-таки не обязательно. А поможет нам в этом Анастасия Абрашитова, руководитель службы инструментов репозитория в Yandex Infrastructure.

На территории России насчитывается от 200 до 300 вулканов. Около 13 из них находятся под особым наблюдением: это действующие вулканы, которые извергались в течение последних 25 лет. Самые активные расположены на территории Камчатки и Курильских островов, так что экстренные службы в этих регионах живут в постоянной готовности к последствиям извержений. 

Оценкой вулканической активности на Камчатке занимается подразделение Единой геофизической службы РАН. В прошлом году её вулканологи совместно с командами Яндекс Погоды, Yandex Cloud, Школы Анализа Данных (ШАД) и Геоинтеллекта запустили проект, который позволяет визуализировать данные по результатам извержений и предсказывать пеплопады в конкретных населённых пунктах. В дальнейшем разработанный сервис можно будет использовать для других подобных задач, например, прогнозировать пеплопады в регионах за пределами Камчатского края.   

Как оптимизировать путь данных внутри чёрного ящика под названием «сеть» и гарантировать необходимый уровень сервиса пользователям своего приложения? Эта задача может волновать не только сетевых инженеров и архитекторов, но и разработчиков, и DevOps-команды. Для глубокого понимания вопроса потребуется разобраться, что такое Traffic Engineering и как он эволюционировал в современных сетях.  

Как сетевой архитектор в Yandex Infrastructure я не раз возвращался к этой теме и в роли спикера на отраслевых конференциях, и в роли преподавателя. С 2017 года я также участвую в разработке черновиков стандартов в рабочих группах IETF и могу сказать, что за каждым черновиком стоит выдающаяся работа коллег из индустрии. Так что в этой статье я буду часто опираться на уже полюбившийся мне своей логикой RFC 9522 и другие связанные документы.

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

Помочь в решении этих задач могут инструменты для удалённого исполнения кода в ML. Сегодня на конкретном примере покажу, как устроен и как работает один из таких инструментов, созданный нами для пользователей облака, — DataSphere Jobs. А в следующий раз вместе с моими коллегами рассмотрим опенсорс-инструменты для подобных задач.

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

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

В этой статье разберёмся, как работает xor-фильтр, в чём особенность чанкового хеш-индекса и как overload controller повышает стабильность работы. Все примеры разберём на примере YTsaurus, но они будут полезны любому разработчику СУБД.

Чем раньше команда задумается о проблеме безопасности, тем лучше. В этой статье обсудим, какие проблемы ИБ есть в стандартном контейнерном приложении, поговорим о безопасности использования Docker, Kubernetes и Terraform и разберём, как можно встроить проверки в стандартный пайплайн деплоя.

Материал написан и дополнен по мотивам выступления Любови Гринкевич и Алексея Миртова из Yandex Cloud на DevOpsConf. Он будет интересен DevOps-инженерам, специалистам по безопасности, владельцам продуктов и всем, кто хочет:

Снежный барс (ирбис) — один из самых редких видов больших кошачьих, который обитает в горных районах. С 2000 года снежный барс занесён в Красный список МСОП как «находящийся под угрозой исчезновения», а с 2017 года ирбисам присвоен статус уязвимого вида.

Такие животные нуждаются в особом наблюдении. Для мониторинга их поведения, состояния и численности учёные используют фотоловушки — автоматические камеры, которые устанавливаются на звериных тропах. Но чтобы отсмотреть и отсортировать все изображения c ловушек вручную, исследователи могут потратить несколько недель.

Меня зовут Михаил Добрицын, я учусь в Школе Анализа Данных Яндекса. В 2023 году совместно с Сайлюгемским национальным парком и другими студентами мы обучили нейросеть, которая поможет учёным быстрее находить снежных барсов и других животных на снимках и узнавать больше об их маршрутах. В этой статье расскажем, как создали собственный датасет для обучения такой нейросети, как тренировали модель, какие результаты получили сейчас и как планируем развивать это решение.

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

Привет, меня зовут Антон Кортунов, я техлид Yandex Infrastructure. В 2017 году мы запустили новый для Яндекса проект — платформу потокового видео Яндекс Эфир. Сам проект закрылся, но на основе платформы работают Кинопоиск, видеокарточки товаров в Яндекс Маркете, Реклама и множество других сервисов.

Как разработчик тогда я столкнулся с чудным дивным миром телевидения и кино, и понял, что видео — не просто последовательность кадров на фоне звуковой дорожки. Под катом расскажу о тонкостях, о которых я узнал от видеоинженеров за последние 5 лет.

За последние пару десятилетий с ростом объёма данных на рынке СУБД сложился интересный ландшафт. Появились новые СУБД, при этом старые продолжали развиваться — и сориентироваться среди них становилось всё сложнее. 

В этой статье предлагаем рассмотреть эволюцию разных СУБД и сравнить их между собой. Поможет нам в этом Олег Бондарь, директор по продукту в Yandex Cloud, который отвечает за развитие YDB — это транзакционная реляционная база данных с открытым исходным кодом. Статья написана по материалам его доклада на Saint Highload++.

Как менеджер продукта и один из амбассадоров serverless я регулярно рассказываю о преимуществах этого подхода и показываю, как с помощью бессерверных вычислений повысить эффективность затрат на инфраструктуру. Но как и у любого подхода, у serverless есть свои ограничения, которые важно учесть в своей IT-стратегии.

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

Привет, меня зовут Мария Карпенко, я разработчик в команде Yandex Tracker — сервиса для управления процессами и проектами. Внутри Яндекса сервис  используется для постановки задач практически во всех командах, так что общее количество событий по задачам исчисляется уже миллиардами. 

Как внутренний сервис Tracker существует с 2012 года, и старые инстансы исторически использовали базы данных on-premise. Но к 2023 году многие части даже из списка легаси должны были переехать в облако — и нам понадобилось продумать бесшовный переезд для достаточно объёмных БД.

В этой статье расскажу, как мы решили эту задачу, — рассказ будет интересен всем, кто планирует переезд в облачную инфраструктуру.