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

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

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

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

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

Сетевой стек Linux не прост даже на первый взгляд: приложение — в юзерспейсе, а всё, что после сокета, — в ядре операционки. И там тысяча реализаций TCP. Любое взаимодействие с сетью — системный вызов с переключением контекста в ядре.

Чтобы лишний раз не дёргать ядро прерываниями, придумали DMA — Direct Memory Access. И это дало жизнь классу софта с режимом работы kernel bypass: например при DPDK (Intel Data Plane Development Kit). Потом был BPF. А за ним — eBPF. 

Но даже помимо хаков работы с ядром есть такие штуки, как sk_buff, в которой хранятся метаданные всех миллионов протоколов. Есть NAPI (New API), которая призвана уменьшить число прерываний. Есть 100500 вариантов разных tables.

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

Привет, Хабр! Меня зовут Вадим Владимиров, я разработчик и у меня есть свой канал в Телеграме. Как и многие уважающие себя телеграм‑админы, я хочу следить за статистикой: оценивать эффективность, когда что‑то делаю для привлечения подписчиков, мониторить прирост аудитории и знать, какие именно пользователи и когда подписались/отписались.

В Телеграме из коробки можно посмотреть какие‑то графики. Но, например, количество подписчиков отображается с точностью до дня, что не очень удобно. Сделать оттуда drill down до конкретного действия тоже нельзя.

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

Всем привет, я Алексей Сизиков, руководитель отдела User Experience в Yandex Cloud. В этой статье я хочу поделиться новостью: мы выпустили нашу дизайн-систему и библиотеку компонентов Gravity UI в опенсорс. 

Под катом — рассказ, зачем мы сделали Gravity UI, как его используем, в чём особенности и преимущества нашего подхода и как мы планируем развивать его дальше. А ещё — как настроить разные цветовые схемы в своих проектах и почему у нас четыре темы вместо двух стандартных.

Привет, меня зовут Максим Качинский, я ведущий DevOps-инженер в компании RocketData. Более 6 лет мы развиваем одноимённую платформу для управления репутацией — за это время она выросла с монолитного MVP на единственном сервере до 15+ микросервисов с пятью разными видами баз данных. И всё это в гибридной инфраструктуре. 

Чем больше рос проект, тем сложнее нам было его поддерживать. Чтобы облегчить жизнь DevOps-инженерам, мы начали постепенно переходить на managed-решения. Но этот путь не был идеально прямым, и нам пришлось пересмотреть многие привычные рабочие инструменты. 

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

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

Ещё с университетских времён я исследую распределённые системы, а последние два года в Яндексе адаптирую Apache Spark к внутренней инфраструктуре. Эта статья посвящена Apache Spark, а именно: как мы в рамках YTsaurus делали его ещё эффективнее. Написана она по мотивам моего доклада для «Онтико».

Меня зовут Настя, я руководитель службы инструментов репозитория в Yandex Infrastructure. Больше 15 лет я проработала в IT-индустрии: сначала как разработчик, потом тимлид, техлид, менеджер проектов и руководитель службы. За это время несколько сотен человек рассказали мне о своём карьерном пути: кто-то собеседовался со мной как с нанимающим менеджером, кто-то приходил ко мне на менторинг, кто-то расширял свой нетворк, как теперь модно говорить. Из этих разговоров можно выделить причины недовольства работой, которые я вижу у людей чаще остальных. Одна из главных причин — ошибка выбора вакансии.  

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

Привет! Предлагаю поговорить о том, почему крупные IT‑компании так любят создавать в своей инфраструктуре собственные решения. Казалось бы, напрашивается ответ: NIH‑синдром и ничего более. Но такой ответ вряд ли может считаться сколько-нибудь полным, а тем более претендующим на объективность.

Меня зовут Дмитрий, я CTO в команде Yandex Platform Engineering. Наша задача — помогать инженерам выстраивать весь цикл разработки от написания кода до эксплуатации сервисов и делать его эффективнее. Такая работа включает настройку процессов: мы не просто делаем нечто as a service, но и помогаем эти самые as a service внедрять внутри компании. И всё это работает на масштабах Яндекса: нашими сервисами пользуются тысячи разработчиков по всей компании.

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

Всем привет, меня зовут Женя Колесников, я из команды Yandex Infrastructure. Сегодня я расскажу, как мы пришли к написанию документации в концепции Docs as Code, придумали для этого набор инструментов, назвали его красивым именем Diplodoc и выложили в опенсорс — теперь вы тоже можете им воспользоваться.

Если вкратце, Docs as Code — это подход к написанию технической документации, который рассматривает её не как набор текстов, а как код. Исходя из этой концепции, к документации могут применяться все те же принципы, инструменты и процессы, что и к самому коду. Расскажу, как это происходит на примере Diplodoc — и чем он может облегчить вам жизнь.

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

Помимо работы в IT я увлекаюсь звукорежиссурой — и в сфере звука формат юнита открылся новыми гранями. Приборы обработки аудио закономерно унаследовали немало из области связи, в том числе и 19-дюймовый юнит. Но развитие звукового оборудования привело к тому, что юниты здесь зажили своей жизнью — и появились любопытные детали, которые могут заинтересовать даже инженеров дата-центров.

Взглянем на историю юнита вместе с Антоном Кортуновым, экспертом по видеопроизводству и техлидом Yandex Infrastructure — команды, которая создаёт платформу для работы разработчиков Яндекса, от ЦОДов до внутреннего облака. И в конце покажем несколько параллелей с эволюцией этого формата в дата-центрах.   

Год назад у Битрикс24 появилась нативная интеграция с BI-сервисом DataLens: теперь пользователи CRM могут строить дашборд с бизнес-аналитикой за несколько кликов. Для создания таких аналитических отчётов бизнес обычно объединяет все данные в единую базу. При таком подходе можно накладывать данные друг на друга, искать пересечения и строить обобщённые визуализации. Но в интерфейсе Битрикс24 такой возможности нет, а значит для создания единой базы нужны программисты.

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

Дисклеймер: Это бета-версия скрипта для импорта лидов, сделок, контактов и компаний из Битрикс24 от участника сообщества DataLens.

25–26 сентября состоялся Yandex Scale — ежегодное мероприятие Yandex Cloud, посвящённое новым технологиям облачной платформы. Если хотите узнать, зачем пользователи платформы данных вращали барабан и как Алиса справляется с удалением контейнеров, — этот пост для вас.

Меня зовут Вера, я редактор блога Yandex Cloud & Yandex Infrastructure, и в этом репортаже собрала самое главное с офлайн-площадки конференции для тех, кто не смог присоединиться очно.

Сегодня мы опубликовали на GitHub под открытой лицензией Apache 2.0 исходный код Yandex DataLens — сервиса для анализа и визуализации данных. Теперь использовать опенсорс-версию DataLens может любой желающий и в любой инфраструктуре. 

Меня зовут Павел Дубинин, вместе с Гаджи Гаджиевым мы в Yandex Cloud занимаемся развитием DataLens. Сегодня расскажем, какие задачи он помогает решать разным пользователям, какие возможности открываются с выходом в опенсорс и что можно развернуть у себя прямо сейчас.   

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

Но что делать, если тот самый человек, которому нужно всё настроить — это вы сами? Для этого разберёмся с базовыми особенностями ресурсной модели в Yandex Cloud.

Привет!
Меня зовут Руслан Качмазов, я стажёр-инженер Yandex Cloud Security, занимаюсь детектированием инцидентов. Вместе с коллегами Алибеком Епхиевым и Дмитрием Пикушем, выпускниками Школы ИБ Яндекса 2023 года, мы расскажем о методах защиты от supply-chain-атак, которые реализованы в группе проектов Sigstore. Поговорим о SLSA, Cosign, Fulcio и Rekor — методологии и инструментах, позволяющих снизить риск таких атак, их гарантиях и тонких местах.

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

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

Поможет нам в этом Дмитрий Смаль, руководитель подразделения Managed MySQL и SQL Server в Yandex Cloud. Каждый день он занимается эксплуатацией и автоматизацией СУБД, а до этого делал нагруженные и не очень web-приложения. В целом любит делать разные интересные штуковины, которые работают! Сегодня мы с ним будем говорить про решение для высокодоступного MySQL.

Привет. Я Марат Сибгатулин — сетевик в Яндексе, работаю в команде Yandex Infrastructure. И сегодня я расскажу вам одну поучительную историю.

Жили были два сервера. Да и не сервера вовсе, а виртуальные машины. Жили не тужили, добро наживали, скриптами разными обрастали. Три года они трудились на славу облака да во имя автоматизации. Пока не наступили чёрные дни для RAID-массива на гипервизоре.