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

Меня зовут Егор Щербин, я работаю в Yandex Infrastructure, в команде планировщика YTsaurus. О нём и расскажу в этой статье. А также о запуске вычислений в кластере YTsaurus, распределении ресурсов между вычислениями и о том, как управлять распределением, чтобы все операции получали ровно столько, сколько требуется.

С начала декабря в режиме технического превью мы открыли доступ к Yandex BareMetal — сервису по аренде выделенных серверов.

Меня зовут Дмитрий Кравцов, я работаю в Yandex Infrastructure, разрабатываю инфраструктурные сервисы и сегодня покажу, как наши внутренние инструменты помогли нам лучше понять потребности клиентов облака. А также какие задачи нам нужно было решить, чтобы вывести сервис в продакшн, какие сценарии уже доступны для реализации, и какие возможности появятся дальше.

Хабр, привет! Я работаю в департаменте бизнес‑аналитики ППР — компании, которая создаёт экосистему сервисов для автопарка. Зимой 2024 года нам пришлось в короткий срок мигрировать на новый для нас BI‑сервис DataLens: подготовить инфраструктуру, развернуть три новых инструмента и мигрировать 100+ витрин и дашбордов.

Сейчас у нас больше 150+ витрин данных, стоящих на расписании, и дашбордов над ними, а также более 150 пользователей, которые на регулярной основе используют аналитические данные.

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

Привет, Хабр! Меня зовут Ольга Лукьянова, я работаю в Yandex Infrastructure, в команде, которая делает системы, сервисы и инструменты для разработчиков. Недавно Яндекс анонсировал новый продукт SourceCraft, который уже собирает вокруг себя сообщество. Последний год я руковожу группой навигации по коду этого проекта.

Мои коллеги на конференциях уже рассказывали про планы развития SourceCraft — платформы от Яндекса для создания исходного кода, управления версиями, тестирования, сборки, развёртывания и сопровождения программных продуктов. А также показывали первый доступный компонент — интеллектуальный помощник для работы с кодом Yandex Code Assistant.
Я открою чуть больше деталей про возможности навигации в нашей платформе, которые появятся в публичном доступе в следующем году и помогут разработчикам не переключаться в IDE, а решать наиболее типовые задачи в одном интерфейсе. В статье — рассказ о том, как мы искали способы добавить функциональность навигации по коду при ревью пул-реквестов и каких результатов уже достигли. 

Event Driven Architecture, или EDA — довольно популярный архитектурный подход, в буквальном переводе «архитектура на основе событий», где мы строим приложение вокруг событий, которые генерируются в системе. В самом распространённом случае, у нас есть много пользователей, которые генерируют много событий, и эти события маршрутизируются в сервисы‑потребители.

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

Киберинциденты в облаках отличаются своей спецификой: источников угроз больше, классические векторы атак и техники сочетаются с тонкостями cloud computing, но зато гораздо проще собирать артефакты для расследований. При этом со стороны может показаться, что самым значимым риском для облачных платформ являются DDoS‑атаки, — но на самом деле всё гораздо интереснее.

Меня зовут Юрий Наместников, я руковожу Cloud Security Operations в Yandex Cloud и в этой статье поделюсь нашей внутренней облачной кухней. Расскажу, с какими интересными задачами сталкиваются команды безопасности облачных платформ сегодня, и разберу кейсы с наиболее запоминающимися решениями.

Меня зовут Константин Бражников, я заместитель директора департамента развития клинических и образовательных проектов в Сеченовском Университете. Сегодня это исследовательский медицинский университет мирового уровня, и у него три направления деятельности: наука, образование и медицинская практика.

В структуре университета работает пять университетских клинических больниц, где ежегодно проходят лечение около 500 000 пациентов. Накопленная статистика по клиническим случаям — один из источников для научных работ наших сотрудников.

В прошлом году мы уже кратко рассказали на Хабре, как с использованием сервисов Yandex Cloud мы разработали платформу анализа медицинских данных — это сервис, который позволяет сотрудникам Сеченовского Университета получить доступ к клиническим данным. Пользователи системы — наши врачи‑исследователи, аспиранты и ординаторы — профессиональные научные сотрудники, которые двигают вперёд медицинскую науку. В этой статье покажу подробнее, как мы реализовали этот проект, как это решение живёт сейчас и помогает преподавателям и врачам‑исследователям в их работе.

Итак, вы гиперскейлер, давайте отталкиваться от этого. Потому что если нет — собирайте хоть 3-tier на OSPF. А гиперскейлер вы в том случае, если у вас большая сеть на тысячи хостов, а лучше стоек. Вы уже попробовали топологию Клоза. Сначала вам очень нравилось. Она вся такая плотная, регулярная и масштабируемая — просто прелесть.

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

Но отчего‑то вы несчастливы. Вам плохо спится. Гложут сомнения и дурные мысли.
А всё дело в эпохе 400G! Вы долгие годы строили свою сеточку на 25+100, и всего всегда хватало. Раньше. А теперь надо на хосты соточку спустить. А значит и аплинки надо расширять, да вы и сами уже понимаете, что пора: ещё несколько лет — и эта сеть станет устаревшей. 200G, 400G, SerDes по 100 Гб/с на PSM4. Тут думать надо.

И новая сетка выглядит действительно привлекательной, даже почти изумительной.Но как только вы подумаете, что её, такую красивую, нужно как‑то интегрировать с существующей, уже немного опостылевшей сетью, настроение сразу портится — фактически это означает, что нужно менять уровень S2 или строить ещё одну сетку рядом с нужной ёмкостью и каким‑то ужасным образом скрещивать их друг с другом иначе.

Привет, Хабр! Я Алексей Колосков, DevOps‑инженер Hilbert Team. Сегодня я расскажу вам историю о компании, которая из маленькой облачной инфраструктуры выросла до сложного решения с использованием Infrastructure as Code (IaC) и Terraform. И, как это часто бывает, в процессе роста учли не всё. Все персонажи вымышлены и любые совпадения случайны (ну, почти).

В этой статье покажу грабли, на которые можно наступить при росте облачной инфраструктуры, и расскажу, как их обойти.

Меня зовут Александр Азимов, я руковожу группой сетевого R&D в Yandex Infrastructure — команде, которая в том числе создаёт системы управления трафиком всего Яндекса. Cегодня мы поговорим о том, как почти полностью избавиться от стейтов на L4-балансировщике.

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

Динамические таблицы — это распределённая база данных, key‑value‑пары которой объединяются в привычные пользователям реляционных СУБД таблицы. В YTsaurus в них можно хранить огромные массивы данных, при этом их можно быстро читать — поэтому YTsaurus используют почти все сервисы Яндекса: Реклама, Маркет, Такси, даже Поиск при построении поисковой базы, и другие.

Я руковожу службой разработки динамических таблиц в Yandex Infrastructure и раньше уже рассказывал, как мы оптимизировали чтение, улучшали выборку строк в SQL‑запросах и защищались от перегрузок. Сегодня вышла новая версия YTsaurus 24.1.0, в которой динамические таблицы получили ещё несколько долгожданных доработок. В статье расскажу про них подробнее.

Привет, меня зовут Всеволод, я разработчик в Yandex Infrastructure — команде, которая создаёт платформу для разработчиков Яндекса. Последние 12 лет я занимаюсь внутренним облаком и за это время писал самые разные его компоненты: от базовой инфраструктуры хостов и до Control Plane.

Сегодня расскажу про то, как мы организуем для наших пользователей единое управление всей инфраструктурой и как добились на этом пути надёжности, скорости разработки, простоты поддержки и масштабируемости — хоть и нарушили при этом некоторые руководства и лучшие практики Kubernetes.

Привет, меня зовут Вова Тимофеев, я менеджер технических проектов Yandex Cloud. В статье поделюсь тем, как мы делали сайт облачной платформы доступнее, сколько итераций прошли и какую роль в этом сыграл Gravity UI.

В основе доступности всех сервисов — то, насколько хорошо они поддерживают работу с программами экранного доступа (Screen reader). Через эти программы пользователи с ограничениями воспринимают интерфейс и взаимодействуют с ним.

Сайты — не исключение. И нам предстояло выяснить, насколько доступен Yandex Cloud для всех пользователей.

В Яндексе под доступностью мы подразумеваем то, что наши сервисы должны с комфортом использовать все, вне зависимости от временных или постоянных физических ограничений. Например, сейчас для незрячих пользователей адаптировано 16 сервисов Яндекса: Лавка, Go, Поиск, Браузер, Почта и другие. В работе над доступностью каждого сервиса помогает команда невизуального тестирования — и в кейсе, о котором расскажу в этой статье, без их помощи тоже не обошлось.

Сегодня мы открываем доступ к четвёртому поколению наших больших языковых моделей: более мощная YandexGPT 4 Pro и облегчённая YandexGPT 4 Lite уже доступны через API в Yandex Cloud. Постепенно пользователям платформы станут доступны все их возможности. А первым сервисом Яндекса, где появится YandexGPT 4, станет Алиса с опцией «Про».

Новое семейство моделей умеет обрабатывать более сложные запросы, работать с расширенным контекстом, поддерживает скрытые рассуждения и вызов функций для работы с внешними инструментами. Нашей команде удалось значительно улучшить качество ответов: YandexGPT 4 Pro в 70% случаев отвечает лучше своей прошлой версии, а YandexGPT 4 Lite в среднем отвечает не хуже, чем самая мощная модель предыдущего поколения.

Вместе с Андреем Бутом @andbout, руководителем команды YandexGPT Alignment, кратко расскажем, что мы сделали для улучшения ответов и решения более сложных запросов, покажем результаты замеров качества и сравнения с другими моделями.

Меня зовут Вадим Осипов, я security‑инженер в команде Yandex Cloud. Вместе с моим коллегой Дмитрием Руссаком, тимлидом команды SOC‑инжиниринга, мы занимаемся комплексной безопасностью облака. Архитектура нашей облачной платформы построена так, чтобы не бояться уязвимостей Remote Code Execution в managed‑сервисах. Но мы всё ещё не хотим, чтобы злоумышленник находил RCE и эксплуатировал их.

Так что сегодня расскажем про RCE в Managed ClickHouse глазами SOC в Yandex Cloud.

Как технический менеджер в Яндексе я отвечаю за эксплуатацию больших кластеров, через которые мы передаём данные, — для этого мы используем YDB Topics, собственный аналог Apache Kafka, о котором я уже рассказывал.

Но если посмотреть не только на нас, но и на примеры других крупных систем, то становится понятно, почему энтерпрайзу сложно брать готовые опенсорс‑решения. Стоит лишь представить, что бывает, если команда с большими масштабами начинает использовать Apache Kafka.

В этой статье я покажу собирательный образ такой крупной системы из нашего опыта общения с большими распределёнными командами, и мы увидим разницу в TCO Apache Kafka и YDB Topics на конкретных цифрах.

Красные карлики — наиболее распространённый тип звёзд в нашей Галактике. Это не самые яркие объекты: они меньше нашего Солнца и светят слабее. Однако большинство планетных систем обнаружено именно вокруг звёзд этого класса.

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

В этом году мы запустили совместный проект со специалистами Государственного астрономического института имени П. К. Штернберга МГУ, Факультета Космических Исследований МГУ и Университета Карнеги‑Меллона, которые работают в международной команде SNAD. Центр технологий для общества Yandex Cloud помог учёным выстроить пайплайн машинного обучения для поиска звёздных вспышек с помощью облачного сервиса Yandex DataSphere и в итоге создать самую крупную выборку вспышек на красных карликах по данным наземных наблюдений.

Совместно с исследователями Анастасией Лаврухиной, Борисом Демковым, Константином Маланчевым @hombitи Марией Пружинской расскажем, как именно машинное обучение помогает астрофизикам, и какие новые научные прорывы это может обещать.

25 сентября состоялась конференция Yandex Scale — большое ежегодное мероприятие Yandex Cloud для тех, кто создаёт цифровые продукты и решения. Событие прошло в гибридном формате: доклады о новинках облака транслировались онлайн, в прямом эфире из МХАТ им. Горького, а на офлайн-площадке команда организовала демо-зоны для живого знакомства с сервисами. 

В репортаже покажем немного закулисья Yandex Scale: какие технологии помогли познакомиться с обновлениями облачной платформы тысячам участников и что интересного будет доступно разработчикам для тестирования в ближайшее время. 

Привет, Хабр! Меня зовут Сергей Махнаткин, я работаю разработчиком в отделе User Experience в Yandex Cloud. В прошлом году мы писали о нашей дизайн-системе и библиотеке компонентов Gravity UI. С тех пор система не раз обновлялась и обрастала новыми функциями, и сегодня я хочу рассказать о новом инструменте — Markdown Editor, который значительно упрощает процесс работы с документацией.

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

Всем привет! Это Сергей Качеев, старший разработчик в отделе сетевой инфраструктуры Yandex Infrastructure. Наша команда создаёт технологии, на которых работают сервисы Яндекса. В прошлый раз я рассказал целый сетевой детектив о том, как мы искали баг, который убивал DNS‑сервер Unbound. И сегодня я расскажу не менее интересную историю.

Мне на развитие попала XDP eBPF‑программа, которая защищает DNS‑серверы от выхода из строя под слишком большой нагрузкой (другими словами, от DDoS). На ядре 5.4 алгоритм защиты был основан на EWMA‑статистике с вероятностными дропами, которые постоянно контролировались из Control Plane. Это делало eBPF‑программу неавтономной. К тому же если Control Plane падал, то сервер оставался в состоянии последнего удачного обновления eBPF. Это нужно было исправлять — было решено заменить это всё на Token Bucket. Этот момент и будем считать отправной точкой в нашей истории.