Телеграм канал «Клуб CDO»

Uber в своем блоге очень часто радует хорошим контентом. Вот интересная статья про управление нагрузкой на BD - показывает хороший кейс классического подхода интеллектуального управления нагрузкой - когда мы распределяем запросы базируясь на алгоримах, которые учитывают текущее состояние системы. Важно тут отметить, что без хорошего observability, то есть сбора метрик и данных о состояние и происходящих в системе процессов, никакого интеллектуального управления или, тем более, модного сейчас self healing - не будет. Все основывается на данных.

Авторы статьи из Uber описывают эволюцию подхода к управлению нагрузкой в высоконагруженной распределённой системе и проблему, с которой они столкнулись по мере роста платформы. Классический static rate limiting, основанный на жёстко заданных лимитах запросов, перестал работать эффективно: он либо слишком агрессивно «душил» легитимный трафик в пиковые моменты, либо, наоборот, не спасал систему от перегрузок в случае каскадных сбоев и неравномерного распределения нагрузки между сервисами.

В статье рассматривается типичный для Uber технологический стек: микросервисная архитектура, тысячи сервисов, интенсивное RPC-взаимодействие, сложные dependency graph’ы и постоянные колебания нагрузки. В такой среде простые лимиты на уровне edge или отдельных сервисов не учитывают реальное состояние системы — латентность, насыщение CPU, очереди, backpressure и влияние одного сервиса на другой. В результате rate limiting превращается в грубый инструмент, плохо отражающий фактическую «здоровость» системы.

Инженерное решение, к которому пришли авторы, — переход от статических лимитов к intelligent load management. Вместо фиксированных порогов система начинает принимать решения на основе сигналов реального времени: latency, error rate, saturation, а также информации о критичности конкретных запросов. Нагрузка регулируется динамически, с учётом приоритетов, graceful degradation и возможности частично обслуживать трафик, не доводя систему до отказа. По сути, rate limiting эволюционирует в адаптивный механизм управления нагрузкой, встроенный в общую observability- и resilience-стратегию платформы.

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

https://www.uber.com/en-GB/blog/from-static-rate-limiting-to-intelligent-load-management/

Вышла новая публикация от RussianBI — о том, как протокол Model Context Protocol (MCP) становится ключевым элементом в современной архитектуре ETL/ELT систем.

В основе — MCP Хост — ИИ-продукт, реализующий интерактивное взаимодействие с пользователями и внешними программами, который чаще всего использует большие языковые модели (LLM) для обработки запросов и управления данными.


Статья показывает, как MCP вписывается в новый ETL/ELT-стек, обеспечивая:
• стандартизированный обмен контекстом между моделями и сервисами;

• расширяемость и совместимость с различными источниками данных;

• гибкое взаимодействие с BI/аналитическими движками.


Традиционные ETL-архитектуры часто растут в сложность с ростом данных и инструментов. Протокол MCP предлагает унифицированный способ интеграции LLM и внешних данных, что позволяет построить более адаптивные, интеллектуальные и автоматизированные пайплайны.

https://russianbi.ru/articles/detail.php?ID=964

Команда Cursor опубликовала практическое руководство по лучшим практикам работы с агентами при написании кода.

Агенты для программирования меняют то, как создаётся софт. Не потому, что они пишут код. А потому, что они меняют само понимание «хорошей инженерии»

Вот паттерны, которые стоит позаимствовать:

- Результаты работы агента зависят от трёх вещей: инструкций, инструментов и ваших промптов. Если результаты нестабильны, не спешите винить модель. Исправляйте harness.

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

- Не пытайтесь «допромптить» неверное направление. Откатитесь назад, уточните план, запустите заново. В итоге — более чистые диффы и меньше странных edge case’ов.

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

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

https://cursor.com/blog/agent-best-practices

Дайджест статей

📰: Как мы сократили объем данных в 10 раз, не повредив пользовательскому опыту, или переезд Postgres → ClickHouse
Ссылка: https://habr.com/ru/companies/kts/articles/988510/
Вывод одной строкой: При переходе с Postgres на ClickHouse важно учитывать не только сокращение объема данных, но и влияние на пользовательский опыт и производительность системы.


📰: Предиктивная аналитика в финтехе: модели, конвейер данных и риски внедрения
Ссылка: https://habr.com/ru/companies/sberbank/articles/986672/
Вывод одной строкой: При внедрении предиктивной аналитики в финтехе важно тщательно оценить модели, конвейер данных и потенциальные риски, чтобы обеспечить надежность и точность прогнозов.


📰: Как мы автоматизировали процесс найма с помощью LLM и сократили ручной труд HR на 70%
Ссылка: https://habr.com/ru/companies/yoomoney/articles/986874/
Вывод одной строкой: Автоматизация процесса найма с использованием LLM значительно снижает ручной труд HR и повышает эффективность, что делает её привлекательным решением для оптимизации кадровых процессов.


📰: Разбираемся с GlowByte, как выбрать BI-платформу в 2026: от универсальных критериев к сценарному подходу
Ссылка: https://habr.com/ru/companies/glowbyte/articles/986846/
Вывод одной строкой: При выборе BI-платформы в 2026 году важно ориентироваться на сценарный подход, учитывающий уникальные потребности бизнеса и специфические задачи анализа данных.


📰: Ключевые метрики базы знаний: как измерить эффективность
Ссылка: https://habr.com/ru/companies/teamly/articles/986508/
Вывод одной строкой: Для оценки эффективности базы знаний следует использовать ключевые метрики, такие как точность, полнота и скорость обработки запросов, что позволит оптимизировать работу системы и улучшить пользовательский опыт.


📰: Apache Hudi™ at Uber: Engineering for Trillion-Record-Scale Data Lake Operations | Uber Blog
Ссылка: https://www.uber.com/blog/apache-hudi-at-uber/
Вывод одной строкой: При разработке систем обработки данных на основе Apache Hudi важно учитывать масштабируемость, производительность и возможности интеграции для эффективной работы с триллионами записей.


📰: LangGrant Unveils LEDGE MCP Server to Enable Agentic AI on Enterprise Databases
Ссылка: https://www.infoq.com/news/2026/01/langgrant-ledge-mcp-server/
Вывод одной строкой: Выбор сервера LEDGE MCP от LangGrant для агентного ИИ в корпоративных базах данных может значительно повысить эффективность обработки данных и интеграции с существующими системами.


📰: The Best GitHub Repos for Data Engineers in 2025!
Ссылка: https://medium.com/@aminsiddique95/the-best-github-repos-for-data-engineers-in-2025-b2f02d7c1833
Вывод одной строкой: При выборе репозиториев на GitHub для инженеров по данным в 2025 году важно ориентироваться на актуальные инструменты, технологии и практики, которые способствуют повышению эффективности работы с данными.


📰: From BI to AI: A Modern Lakehouse Stack with Lance and Iceberg
Ссылка: https://lancedb.com/blog/from-bi-to-ai-lance-and-iceberg/
Вывод одной строкой: При переходе от бизнес-аналитики к искусственному интеллекту важно использовать современные технологии, такие как Lakehouse, чтобы обеспечить гибкость, масштабируемость и эффективную обработку данных.

Вышла статья от Cursor про практику проектирования AI-агентов.

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

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

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

Будет полезно тем, кто рассматривает использование AI-агентов в продакшене и внутренних инструментах.

Я вот в основном код пишу все таки в Cursor, всякие CLI агенты и Антиграфитацию пока я так и не оценил. А у кого какая практика?

https://cursor.com/blog/agent-best-practices

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

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

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

Отдельный восторг — софт. Для сложных операций с векторами и матрицами инженеры MIT написали собственный интерпретатор (по сути, предок современных скриптовых языков), который работал поверх ассемблера в условиях всего 72 КБ памяти. Эту часть разработки возглавляла Margaret Hamilton, и именно тогда родился сам термин software engineering — потому что писать такой код «по-дилетантски» было просто невозможно.

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

https://www.youtube.com/watch?v=i1VJ03SWe5M

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

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

С удовольствием читаем и делимся здесь.

https://t.me/ai_for_devs