Распределённые системы *

Долгое время главным критерием качества данных считалась их чистота и полнота. Компании инвестировали значительные ресурсы в MDM-системы и процессы проверки, стремясь получить «единую версию правды». Однако сегодня этого уже недостаточно. В условиях, когда скорость реакции определяет успех, на первый план выходит новый критерий — актуальность. Способность данных отражать реальное положение дел в момент принятия решения становится решающим фактором. При этом классические архитектуры, основанные на ночных загрузках в DWH, создают временной лаг, который превращает «правду» во «вчерашнюю». 

Привет, Хабр. Меня зовут Александр Шалудин. Я Presale-архитектор Data Services VK Tech. В этой статье я разберу, к чему может приводить работа с неактуальной информацией и как выстроить архитектуру, которая позволит устранить этот разрыв.

Из-за высокой конкуренции и сопутствующих вызовов многие компании стремятся стать Data-Driven, то есть принимать решения, основываясь на данных, чтобы сохранять конкурентоспособность, быстро реагировать на тренды и взвешенно оценивать бизнес-процессы.

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

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

Всем привет! Меня зовут Миша, я разрабатываю платформу Яндекс Еды. В декабре я рассказывал, как Temporal без боли решает привычную проблему распределённой бизнес‑логики.

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

Некоторые части специфичны для разработки на Go, а другие вполне универсальны. Они организованы от общих к частным. Поделюсь практическими советами по архитектуре, тестированию, детерминизму и безопасному развитию Workflow. Покажу, как организованы миграции и эксплуатации в крупном продакшене.

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

Идемпотентность в System Design: полный пример

Идемпотентность часто упоминается при проектировании систем (system design). Ниже будет простыми словами объяснено, что это такое, далее мы разберём основные детали идемпотентности, часто понимаемые неверно и, наконец, проиллюстрируем её на полном примере. 

Что такое идемпотентность?

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

Современные S3-хранилища давно перестали быть «черным ящиком»: от их архитектуры напрямую зависят отказоустойчивость, производительность и экономика сервисов, которые на них опираются. Но за внешне простым API скрывается интересная, сложная, промышленная система — от железа в стойках до многослойного распределенного  приложения.

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

Меня зовут Александр Гришин, я руковожу направлением хранения и обработки данных в Selectel. Отвечаю за развитие облачных баз данных, S3-хранилища, аппаратных СХД и сервисов для построения DLH. Материал будет полезен CTO, CIO и архитекторам, которые выбирают или проектируют собственное S3-совместимое хранилище. Или инженерам которые хотят просто лучше понимать, что же происходит у нашего сервиса под капотом.

Кажется, что время — это просто. Но мы, инженеры, теряем сон из-за такой простой задачи, как синхронизация часов.

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

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

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

Меня зовут Никита, и мне как инженеру по информационной безопасности Алисы и Умных Устройств Яндекса приходится быть по обе стороны баррикад: думать, как сделать устройства безопасными и знать, как их «ломать». Всегда нужно рассматривать потенциальные векторы атак и способы защиты от них. В этом во многом помогает наша программа «Охота за ошибками». А сегодня я расскажу о том, как смотреть на смарт-девайсы с точки зрения информационной безопасности, какие есть реальные риски и как их минимизировать.

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

Агент «Исследовать» в Алисе AI может работать до 20 минут. За это время он успевает обойти десятки сайтов, запустить модели, вызвать инструменты — и сделать всё это параллельно на нескольких хостах. И если в середине цепочки что-то упадёт (а практика показывает, что если может упасть — когда-нибудь упадёт: релизы, сети, «луна не в той фазе»), агент должен уметь продолжить работу с того же места, а не начать всё заново, сжигая часы и LLM-токены. Ещё год назад никакой инфраструктуры для этого у нас не было.

Меня зовут Алексей Логинов, я ведущий разработчик в команде, которая отвечает за инфраструктуру нашего ассистента. В этой статье я покажу, какой путь мы прошли от наивного SDK до полноценной платформы Agent Transport System (ATS) — и как при этом упирались в различные ограничения и преодолевали их.

Чем покупка букета на 8 Марта через Яндекс Еду отличается от покупки, собственно, еды? С точки зрения пользователя — ничем. Выбрал, оплатил, доставили. А вот с точки зрения разработчика бэкенда заказ уникальных букетов превращается в нетривиальную инженерную задачу синхронизации складских запасов. Задержка синхронизации хотя бы в 10 минут трансформируется в звонок и сборщиков заказов, сообщающих о том, что именно такого букета на складе больше нет. 

Меня зовут Виталий Московкин, я занимаюсь ритейлом в Яндекс Еде. В статье я расскажу, как мы синхронизировали состояние складов с 18 миллионами уникальных товаров: сначала с помощью PostgreSQL, а затем с помощью YDB. Такое количество товаров превращается на бэкенде в 4 миллиарда записей о ценах и стоках, которые нельзя просто так кешировать. Но и замена монолитной СУБД на распределённую тоже задача не на десять минут. Подробности — под катом.

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

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

Привет! Меня зовут Дмитрий Ивахненко из команды Автономного транспорта Яндекса. В этой статье я подробно разберу, как устроены сервисы удалённого управления автономными юнитами — роботакси, роботами‑доставщиками и грузовиками. 

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

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

Когда у компании много сервисов и данных, то лучше всего иметь план Б на любую ситуацию, например когда нужно быстро оптимизировать ресурсы и работать в режиме «минус один дата‑центр» без просадок, в то время как утилизация серверов при этом стремится к 100%. Смертельный номер? Вполне посильная задача, с которой справилась команда Яндекс Go. 

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

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

Меня зовут Алексей Терентьев, я руководитель одной из служб отдела эффективности Яндекс Go. В этой статье я расскажу, как мы прошли путь от простого «прочитал — обработал — закоммитил» к по‑настоящему масштабной архитектуре: со всеми граблями, факапами и конкретными решениями.

Привет, Хабр! Я — Сева, разработчик в Yandex Infrastructure. Уже больше десяти лет я занимаюсь разработкой внутреннего облака Яндекса, которое охватывает около 150 000 физических хостов и поддерживает все сервисы платформы.

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

В последнее время из общего ИИ-пузыря выделилось несколько хайповых тем:

• автономные ИИ-агенты и другие инструменты, которые якобы помогают человеку выполнять рутинные задачи и экономить время (это обман, на самом деле всё наоборот: загруженность человека с ИИ сильно возрастает — увеличивается интенсивность труда, усталость, риски выгорания и требования к производительности),
• частные облака для «локального» инференса,
• децентрализованный ИИ, который будет работать на компьютерах пользователей.

С агентами всё понятно, а вот частные облака и P2P-суперинтеллект можно рассмотреть внимательнее.

Допустим, вы — типичный обитатель этого ресурса. Сидите по 10 часов перед экраном, компенсируете магнием и омегой-3, мониторите HRV через Oura или Apple Watch, слушаете Хабермана, ходите в зал три раза в неделю, спите по трекеру. Вы, возможно, даже знаете, что такое глимфатическая система и зачем нужен глубокий сон. И всё равно — что-то не складывается. Может энергии не хватает, или шея хронически зажата, сон нестабилен, тревога фоновая, а последний ОРВИ длился три недели вместо пяти дней.

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

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

Я потратил изрядное количество времени на то, чтобы собрать воедино результаты шести независимых областей нейронауки, которые последние 30 лет, каждая по-своему, приходят к одному и тому же выводу: информационные состояния высшего порядка реально, измеримо, через конкретные биохимические каскады влияют на физиологию. И написал научную статью (PDF на английском), в которой эти разрозненные наблюдения собраны в единый фреймворк.

Эта статья на Хабре — попытка рассказать о том же самом человеческим языком, с IT-аналогиями, практическими выводами и без единой мантры.

«Значит, смотрите. Payment-service ходит в booking-service, но только через API gateway, который дёргает auth-service, а тот валидирует токен в Redis, который шарит с notification-service…» — вы, объясняя архитектуру новому разработчику.

Десять лет мы разматывали нитки между сервисами на доске, как Чарли из «В Филадельфии». 42% компаний уже тихо сворачивают микросервисы обратно. Istio не осилил микросервисную архитектуру собственного control plane. Бывший CTO GitHub называет это «главной архитектурной ошибкой десятилетия».

А потом пришёл AI, которому не нужны ни митинг на 15 человек, ни три года в проекте, чтобы понять, почему бронирование — это цепочка из 12 HTTP-вызовов вместо одного function call.

Разбираю шесть причин дробления монолитов. Спойлер: половину из них AI уже отменил.

Привет, Хабр! Меня зовут Сергей, я работаю в компании InfoWatch разработчиком на продукте ARMA Стена (NGFW). Подробнее о том, что такое ARMA Стена, можно прочитать тут.

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

Сразу оговорюсь, что в статье используется TLA+, без введения в инструмент, чтобы не увеличивать объём статьи. Подробнее про инструмент вы можете почитать на сайте создателя, тут и тут. Необходимые объяснения даются по ходу изложения.

Статья состоит из двух частей:

1) Что такое формальная верификация и где она применятся

2) Решение бизнес-задачи в NGFW

Когда у вас 50+ узлов Tarantool в кластере, ручное управление соединениями превращается в боль. Узлы падают, реплики становятся мастерами, новые инстансы добавляются — и все это нужно отслеживать в реальном времени. 

Рассказываем, как мы спроектировали go-discovery — библиотеку для автоматического обнаружения узлов кластера Tarantool 3.0.

Привет, Хабр. Меня зовут Олег Жуковец. Я руководитель команды «Экосистема» в Tarantool R&D компании VK Tech.

Многие разработчики сталкивались с ситуацией, когда запросы к базе данных выполняются быстро, индексы настроены, оборудование справляется с нагрузкой, но конечное приложение все равно работает медленно. Нередко проблема кроется не в самой базе данных, а в некорректно реализованном клиенте, который может стать «бутылочным горлышком» для всего ИТ-ландшафта. Именно поэтому оптимизация клиентов для работы с БД имеет важное значение.

В этой статье я на примере коннектора к Tarantool расскажу о доступных и простых оптимизациях клиента для БД, которые позволяют минимизировать аллокации и число горутин, чтобы выкрутить скорость обработки запросов (RPS) на максимум.