Привет, меня зовут Руслан Савченко, я руководитель службы разработки динамических таблиц в Yandex Infrastructure и преподаватель в Школе анализа данных. Сегодня я поделюсь актуальными инсайтами о том, как ломаются большие системы и как их траблшутить. Думаю, это будет полезно разработчикам и студентам, которые интересуются Site Reliability Engineering. Вообще, мало где сейчас обучают SRE, хотя в индустрии такие задачи очень востребованы.

В основе статьи — материалы SRE Week, открытого интенсива ШАДа по работе с большими нагруженными системами.

В начале апреля мы запустили первую программу сертификации специалистов по облачным технологиям — до этого не было экзаменов по работе с российскими облачными платформами, которые созданы в соответствии с отечественными и международными стандартами тестирования. За 3 месяца с момента запуска состоялось 12 экзаменов, в них участвовали 88 специалистов разного профиля. Большинство участников — инженеры DevOps.

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

Работа в Яндексе ставит огромное количество технических вызовов, которые интересно решать. И один из них — это производительность основной очереди сообщений YDB Topics. Посмотрим, может ли опенсорсный продукт от Яндекса конкурировать с Apache Kafka по производительности.

Меня зовут Зевайкин Александр. Я уже практически 20 лет в IT. Начинал с преподавания в вузе, запускал множество стартапов, руководил командами разработки. В текущий момент я работаю в Яндексе в отделе, занимающимся одной из высоконагруженных систем. Это разработка распределённой базы YDB, в частности, функциональности YDB Topic.

4 июня состоялась infra.conf 2024 — конференция про создание инфраструктуры и эксплуатацию высоконагруженных систем от команды Yandex Infrastructure. На мероприятии мы попросили поделиться своими инфраструктурными историями инженеров не только Яндекса, но и Ozon.Tech, T1, MTS Web Services, Т‑Банка, SberDevices, Альфа‑банка, «Лаборатории Касперского», Selectel, Postgres Pro, СберМаркета и Авито. В результате, по отзывам участников, «хардкор‑концентрат железа и DevOps зашкаливал и летал прямо в воздухе».

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

В среду 29 мая мы провели ML2Business — первую конференцию от Yandex Cloud, посвящённую кейсам применения GenAI, NLP, CV и других технологий ML в бизнесе.

Реальный опыт внедрения машинного обучения был представлен в двух треках: GenAI&NLP и GenAI&CV. Их программа была полностью посвящена историям использования ML в разных компаниях. В этой статье мы собрали инсайты спикеров из компаний «Инфосистемы Джет», «ВкусВилл» и Банки.ру, которые могут быть интересны техническим специалистам.

Вот есть у вас сотня коммутаторов или маршрутизаторов. Это много или мало?

Ну вроде как мало. А если надо на всех разом нового сотрудника добавить? А потом удалить уволившегося? А потом поротировать скомпрометированные пароли и ключи?

И тут приходит служба безопасности, которая, во-первых, хочет централизованно контролировать, у кого какие доступы, во-вторых, актуальны ли они на железках, в-третьих, ещё и смотреть, кто что когда запускал, да ещё и разрешать или запрещать это делать («Просто продолжай, не останавливайся» © СИБ).

Ну вот совсем уже и не мало. Чувствуете, чем это пахнет? Даааа, TACACS-ом.

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

Технологии MPLS более двадцати лет. Всё это время она широко использовалась операторами связи, а также в больших корпоративных сетях. Казалось бы, стоит ли искать «лучшее вместо хорошего»? Так, да не так.

В завершающей части нашего цикла про Traffic Engineering обсудим подробнее тему Segment Routing, к которой мы подошли в прошлый раз. И для этого нам будет нужно разобраться, что же не хватало в MPLS.

Всем привет. На связи Артём Гойлик @ArtoLord и Владислав Волох @Chillintano из команды DataSphere в Yandex Cloud. Мы создаём инфраструктуру для ML-разработчиков. И сегодня расскажем про одну задачу, которая, как и многие другие, начиналась с болей наших пользователей.

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

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

Меня зовут Алексей Афонин, я старший дизайнер продукта в 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, Школы Анализа Данных (ШАД) и Геоинтеллекта запустили проект, который позволяет визуализировать данные по результатам извержений и предсказывать пеплопады в конкретных населённых пунктах. В дальнейшем разработанный сервис можно будет использовать для других подобных задач, например, прогнозировать пеплопады в регионах за пределами Камчатского края.