Итак, вы гиперскейлер, давайте отталкиваться от этого. Потому что если нет — собирайте хоть 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. Этот момент и будем считать отправной точкой в нашей истории.

Привет, я Василий Коровин, аналитик в Yandex Infrastructure. Уже три года в команде видеоплатформы я занимаюсь аналитикой нашего плеера. Это тот самый веб‑плеер, который используется для воспроизведения видео на разных сервисах Яндекса (например, на Кинопоиске, Диске, Практикуме и Погоде). А также с этого года он доступен в облачном сервисе для хранения, обработки и трансляции видео Cloud Video.

Мы подробно рассказывали о разработке плеера тут и тут. Сегодня же хочу рассказать, как мы понимаем, нравится или не нравится людям им пользоваться. Для этого нам пригодится аббревиатура QoE — с английского она расшифровывается как «quality of experience», и переводится как «метрика качества восприятия» пользователями нашего сервиса.

Привет, Хабр! Меня зовут Виктор Плошихин, я руковожу ML‑лабораторией в Yandex Infrastructure, команде, которая создаёт платформу для разработчиков Яндекса. Мой коллега Константин Моксин @kamoksin работает разработчиком‑аналитиком в этой же лаборатории — и мы сами пишем очень много кода. Этой осенью мы запустили Yandex Code Assistant — помощник для работы с кодом — и открыли к нему бесплатный доступ в режиме тестирования на платформе Yandex Cloud. И нам было важно не просто научить нейросеть писать код, но и сделать так, чтобы разработчики были довольны работой этого помощника.

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

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

Сбор, очистка и агрегация данных занимают большую часть времени и вычислительных ресурсов, а эти затраты хочется оптимизировать. В статье покажем, как мы ускорили построение пайплайнов обработки данных с помощью связки DataSphere Jobs и Apache Airflow®.

Привет! Я Александр Хренников — руководитель DevOps-юнита в KTS. Первый коммит в репозиторий kubernetes был сделан 10 лет назад, 6 июня 2014 года. За это время kubernetes прошёл большой путь и стал самым популярным средством оркестрации контейнеров. 

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

Заодно приглашаем принять участие в челлендже по запуску kubernetes из самого первого коммита. Это продолжение нашего совместного челленджа c Yandex Cloud на KuberConf / 24, где мы запускали приложение без ошибок на инфраструктуре облака.

Если собирать компоненты с нуля желания нет, а запустить их хочется уже сейчас, участвуйте в Kube01 Challenge по запуску k8s v.0.1 на инфраструктуре Yandex Cloud. Принять участие и выиграть мерч с Котзиллой можно по ссылке.

Привет, меня зовут Борис Литвиненко, я занимаюсь SRE и DevOps в Yandex Infrastructure. Такие задачи я решаю уже очень давно, последние 10 лет — в Яндексе.

Естественно, в инфраструктурных подразделениях мы не гнушаемся и разработкой: все описанные в этом материале события происходят в группе разработки сетевой инфраструктуры и мониторинга, где мы делаем всё, что касается сети и какой‑то автоматизации. А как вы понимаете, сетевая инфраструктура большей своей частью не может зависеть от остальных сервисов.

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

21 августа команда Yandex Cloud в формате Technical Preview открыла пользователям облака доступ к сервису для хранения, обработки и трансляции видео Cloud Video. Это инфраструктура для работы с видео, которая включает хранилище для контента и метаданных, видеоплеер, сервисы мониторинга и аналитики, CDN, а также возможности автоматической генерации субтитров и перевода. Сервис разработан на базе видеоплатформы Яндекса, которую компания запустила в 2016 году для использования во внутренних продуктах.

Меня зовут Константин Петряев, я разработчик в Yandex Infrastructure, и в команде видеоплатформы я 6 лет занимаюсь разработкой плеера. Моя коллега Оля Попова уже рассказала об истории его создания с нуля. А в этой статье я подробнее расскажу про задачу повышения качества видео в плеере. Остановлюсь на том, как мы боролись с тем, что стандартные прогнозы качества потокового видео всем нам «врут», и как научили плеер выдавать наилучшее возможное качество видео для пользователя, с учётом параметров сети и других менее очевидных вводных.

Привет! Я Евгений Антонов, ведущий технический менеджер проектов в Yandex Infrastructure. В ИТ‑индустрии за 17 лет успел поадминистрировать, поразрабатывать и поруководить. Работал на многих позициях в разных компаниях — аутсорсных и продуктовых.

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

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