🌞 Когда на улице солнечно — начинаю день с велотренировки.
Вместо пробежки — лёгкий выезд: тот же заряд бодрости, но без избыточной нагрузки. Особенно круто, когда солнце греет, а в наушниках разбирают, как работает RAG или как построить инфраструктуру, чтобы микросервисы падали реже.
Велосипед = мягкий старт, меньше стресса, больше энергии.
Попробуйте — даже 30 минут могут задать тон всему дню. 🚴♂️💡
Всем — лёгкого кода, стабильных деплоев и классного рабочего дня!
(И пусть PR проходит без многочисленных правок 😄)
Вместо пробежки — лёгкий выезд: тот же заряд бодрости, но без избыточной нагрузки. Особенно круто, когда солнце греет, а в наушниках разбирают, как работает RAG или как построить инфраструктуру, чтобы микросервисы падали реже.
Велосипед = мягкий старт, меньше стресса, больше энергии.
Попробуйте — даже 30 минут могут задать тон всему дню. 🚴♂️💡
Всем — лёгкого кода, стабильных деплоев и классного рабочего дня!
(И пусть PR проходит без многочисленных правок 😄)
👍8
AI-инфраструктура без иллюзий или почему генеративный ИИ — это новый радий в стакане воды
Сегодня — не про сложность, убивающую микросервисы, и не про схожесть отделов банка со средневековой Чехией, а про то, как ИИ приходит в бизнес. И почему почти все начинают с научной фантастики в реальной жизни, а заканчивают… инфраструктурой.
Видео: «AI-инфраструктура без иллюзий» — Игорь Зарубинский и Михаил Тутаев на True Tech Day 2025.
👉 В этом докладе — один из самых честных разговоров об ИИ, который я слышал за последнее время.
Без рекламного шоу. Без слайдов с «10x ростом эффективности». Только реальные вызовы, провалы и архитектура, которую приходится строить самим.
🔍 О чём говорят?
▪️Почему 50% ИИ-пилотов (а по их личному мнению и все 80%) не доходят до продакшна?
▪️Что такое Lake House — и почему это новая основа для данных в эпоху LLM?
▪️Как устроена цепочка данные → модели → API — и где чаще всего всё ломается?
💡 Что особенно цепляет:
🔹 Говорят не маркетологи, а практики, которые внедряют ИИ в реальные системы.
🔹 Есть реальные кейсы провалов — и, что важнее, выводы из них.
🔹 Обсуждают российскую инфраструктуру, GPU, MVS и будущее data-платформ.
🔹 Поднимают тему: когда ИИ — это решение, а когда — просто новый источник технического долга.
🔹 Понравилась мысль что генеративный ИИ — это новыйрэп радий.
🔹 Сейчас с ИИ — похожая история.
Его используют везде, не понимая до конца, чем это может обернуться.
Но эксперименты, честность о неудачах и готовность учиться — вот как мы найдём настоящее, эффективное применение.
🧠 Главный вывод:
ИИ — это не волшебная таблетка. Это система.
Это не «подключил Llama — и заработало». Это:
● Сбор и очистка данных,
● Векторизация,
● Безопасность,
● Мониторинг,
● Готовность учиться на ошибках.
Тот, кто думает, что можно просто вставить ИИ и ждать шикарные результаты — получит убытки.
Тот, кто строит архитектуру — получит преимущество.
🔧 И вот как может выглядеть такая архитектура — по шагам:
✅ Сбор, хранение и управление данными
Без данных — нет модели. Lake House здесь не роскошь, а необходимость.
✅ Очистка и подготовка
Мусор на входе = мусор на выходе. 80% работы — до обучения.
✅ Обучение и fine-tune моделей
Off-the-shelf LLM (предобученная модель) — это база, но под задачу бизнеса модель нужно дообучить.
✅ Векторизация и RAG
Превращаем знания компании в векторы, чтобы ИИ отвечал по нашим данным.
✅ Инференс и масштабируемость
Как модель будет работать под нагрузкой? GPU, latency, cost — всё важно.
✅ MLOps и CI/CD
Обновления моделей без простоев, тестирование, rollback. Как у нормальных инженеров😁.
✅ Интеграция с API
Модель в изоляции — никому не нужна. Она должна жить в продукте.
✅ Безопасность и контроль
Данные, доступ, аудит, промпты. Особенно — если это B2B или госсектор.
✅ ИИ-агенты и автоматизация
От чат-бота к агенту, который сам принимает решения, планирует действия, взаимодействует с системами.
👉 https://vkvideo.ru/video-38818370_456239292
💬 А как вы относитесь к стремительному, почти реактивному росту LLM в нашей жизни?
Они уже пишут стихи и письма, генерируют код и песни, безупречно рисуют… Ожидали ли Вы что мы так быстро окажемся в раннем киберпанке?
Делитесь в комментариях — интересно собрать разные точки зрения.
🔔 Это выпуск #6 рубрики «IT & Инсайты» — разборы, которые помогают понимать современные технологии и как они создаются — глубже.
#ITИнсайты
Сегодня — не про сложность, убивающую микросервисы, и не про схожесть отделов банка со средневековой Чехией, а про то, как ИИ приходит в бизнес. И почему почти все начинают с научной фантастики в реальной жизни, а заканчивают… инфраструктурой.
Видео: «AI-инфраструктура без иллюзий» — Игорь Зарубинский и Михаил Тутаев на True Tech Day 2025.
👉 В этом докладе — один из самых честных разговоров об ИИ, который я слышал за последнее время.
Без рекламного шоу. Без слайдов с «10x ростом эффективности». Только реальные вызовы, провалы и архитектура, которую приходится строить самим.
🔍 О чём говорят?
▪️Почему 50% ИИ-пилотов (а по их личному мнению и все 80%) не доходят до продакшна?
▪️Что такое Lake House — и почему это новая основа для данных в эпоху LLM?
▪️Как устроена цепочка данные → модели → API — и где чаще всего всё ломается?
💡 Что особенно цепляет:
🔹 Говорят не маркетологи, а практики, которые внедряют ИИ в реальные системы.
🔹 Есть реальные кейсы провалов — и, что важнее, выводы из них.
Например, Klarna неудачно заменила команду поддержки на ИИ — результат оказался хуже.
Но компания не отказалась от ИИ, а перешла к модели co-pilots: нейросеть теперь помогает человеку-оператору корректно ответить.
🔹 Обсуждают российскую инфраструктуру, GPU, MVS и будущее data-платформ.
🔹 Поднимают тему: когда ИИ — это решение, а когда — просто новый источник технического долга.
🔹 Понравилась мысль что генеративный ИИ — это новый
"Напомним: в начале XX века радий считался чудо-элементом.
Из него делали косметику, игрушки, лекарства, часы…
Люди не понимали рисков — и использовали везде.
В итоге — ушёл из быта, но остался в медицине, где его применение оказалось по-настоящему ценным. "
🔹 Сейчас с ИИ — похожая история.
Его используют везде, не понимая до конца, чем это может обернуться.
Но эксперименты, честность о неудачах и готовность учиться — вот как мы найдём настоящее, эффективное применение.
🧠 Главный вывод:
ИИ — это не волшебная таблетка. Это система.
Это не «подключил Llama — и заработало». Это:
● Сбор и очистка данных,
● Векторизация,
● Безопасность,
● Мониторинг,
● Готовность учиться на ошибках.
Тот, кто думает, что можно просто вставить ИИ и ждать шикарные результаты — получит убытки.
Тот, кто строит архитектуру — получит преимущество.
🔧 И вот как может выглядеть такая архитектура — по шагам:
✅ Сбор, хранение и управление данными
Без данных — нет модели. Lake House здесь не роскошь, а необходимость.
✅ Очистка и подготовка
Мусор на входе = мусор на выходе. 80% работы — до обучения.
✅ Обучение и fine-tune моделей
Off-the-shelf LLM (предобученная модель) — это база, но под задачу бизнеса модель нужно дообучить.
✅ Векторизация и RAG
Превращаем знания компании в векторы, чтобы ИИ отвечал по нашим данным.
✅ Инференс и масштабируемость
Как модель будет работать под нагрузкой? GPU, latency, cost — всё важно.
✅ MLOps и CI/CD
Обновления моделей без простоев, тестирование, rollback. Как у нормальных инженеров😁.
✅ Интеграция с API
Модель в изоляции — никому не нужна. Она должна жить в продукте.
✅ Безопасность и контроль
Данные, доступ, аудит, промпты. Особенно — если это B2B или госсектор.
✅ ИИ-агенты и автоматизация
От чат-бота к агенту, который сам принимает решения, планирует действия, взаимодействует с системами.
Это не путь из 9 шагов — это непрерывный цикл.
И пропуск любого этапа — прямая дорога к провалу пилота.
👉 https://vkvideo.ru/video-38818370_456239292
💬 А как вы относитесь к стремительному, почти реактивному росту LLM в нашей жизни?
Они уже пишут стихи и письма, генерируют код и песни, безупречно рисуют… Ожидали ли Вы что мы так быстро окажемся в раннем киберпанке?
Делитесь в комментариях — интересно собрать разные точки зрения.
🔔 Это выпуск #6 рубрики «IT & Инсайты» — разборы, которые помогают понимать современные технологии и как они создаются — глубже.
#ITИнсайты
VK Видео
AI-инфраструктура без иллюзий. Игорь Зарубинский и Михаил Тутаев на True Tech Day 2025
Игорь Зарубинский в ИТ более 15 лет. Начинал карьеру в Сбере, где прошел путь от старшего экономиста отдела клиентской базы до директора дивизиона. В мае 2023 года занял должность вице-президента МТС. Под руководством Игоря Зарубинского была полностью пересмотрена…
👍2
🧱 Я перестал ждать всплеска эмоций. Теперь я просто делаю
Раньше мне было сложно выполнять рутинную работу.
Казалось, что вот-вот нужно во что-то включиться — и всё изменится: продуктивность взлетит, идеи хлынут, всё пойдёт как по маслу.
Но ничего не менялось.
Только тревожное чувство: «Я должен делать больше».
И в то же время — усталость от действий, которые не приносят результата.
И ком, который рос: технический и моральный долг, вопросы к самому себе.
Со временем пришло понимание:
Рутинная работа — это не про вдохновение.
Она требует другого подхода.
Не всплеска энергии, а устойчивости.
Не гениального решения, а монотонного следующего шага.
⏱ Мне лично помогла техника Pomodoro:
25 минут — фокус на задаче, таймер включен.
И в эти 25 минут я не герой, не гений, я просто — работник.
Именно так я пишу код.
Именно так расписываю задачу по шагам, чтобы разобраться в незнакомой области.
Именно так научился не бояться скучных, но нужных дел.
Маленькие шаги превращаются в большой результат.
Например:
❇️ Отключаешь уведомления → Больше фокуса. Меньше утечек энергии.
❇️ Коммитишь и пушишь код каждый день → Через пару месяцев проект обретает осмысленность и видна чёткая история прогресса.
❇️ Вводишь процесс мерджреквеста и ревью в команде → Через полгода — меньше хаоса, через год — рост продуктивности.
❇️ Стабилизируешь сон, находишь баланс между тренировками и отдыхом, начинаешь считать и контролировать калории → Через 3–6 месяцев чувствуешь себя заряженным энергией.
❇️ Учишь новое и постепенно применяешь → Навык закрепляется, а не исчезает в «я потом».
Да, это сложно — делать снова и снова,
когда уже не интересно,
когда хочется бросить,
когда «всё и так понятно».
Если сейчас тебе тяжело или скучно,
но ты знаешь, что это движет тебя вперёд —
продолжай.
Терпения.
И — вперёд!🏃♂️➡️➡️
Раньше мне было сложно выполнять рутинную работу.
Казалось, что вот-вот нужно во что-то включиться — и всё изменится: продуктивность взлетит, идеи хлынут, всё пойдёт как по маслу.
Но ничего не менялось.
Только тревожное чувство: «Я должен делать больше».
И в то же время — усталость от действий, которые не приносят результата.
И ком, который рос: технический и моральный долг, вопросы к самому себе.
Со временем пришло понимание:
Рутинная работа — это не про вдохновение.
Она требует другого подхода.
Не всплеска энергии, а устойчивости.
Не гениального решения, а монотонного следующего шага.
25 минут — фокус на задаче, таймер включен.
И в эти 25 минут я не герой, не гений, я просто — работник.
Именно так я пишу код.
Именно так расписываю задачу по шагам, чтобы разобраться в незнакомой области.
Именно так научился не бояться скучных, но нужных дел.
Маленькие шаги превращаются в большой результат.
Например:
Да, это сложно — делать снова и снова,
когда уже не интересно,
когда хочется бросить,
когда «всё и так понятно».
Если сейчас тебе тяжело или скучно,
но ты знаешь, что это движет тебя вперёд —
продолжай.
Терпения.
И — вперёд!🏃♂️➡️➡️
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥3👍1
Последние дни были тревожными.
Появилась задача — развернуть решение на дев-сервере. Планировал спокойно выкатить 8 сентября, в понедельник.
Один коллега вбросил мысль, что реализация должна сразу соответствовать куче избыточных требований. И в этот момент я включил режим «сгорания»: мысленно сижу за ноутом в выходные, пилю с Qwen, как с соавтором, и нервно проверяю работоспособность версии.
На созвоне с тимлидом:
«Выкатывай как есть, рабочее же решение. В процессе будем тестировать и допиливать»
И — бац — паника рассеялась.
Почему я иногда забываю, что другие люди тоже адекватны😁
Идеала не существует, а только монотонная и последовательная работа, как я писал во вчерашнем посте.
Благодарю мир за адекватность! Выходные будут кайфовыми🔥
#БудниПрограммиста
Появилась задача — развернуть решение на дев-сервере. Планировал спокойно выкатить 8 сентября, в понедельник.
Один коллега вбросил мысль, что реализация должна сразу соответствовать куче избыточных требований. И в этот момент я включил режим «сгорания»: мысленно сижу за ноутом в выходные, пилю с Qwen, как с соавтором, и нервно проверяю работоспособность версии.
На созвоне с тимлидом:
«Выкатывай как есть, рабочее же решение. В процессе будем тестировать и допиливать»
И — бац — паника рассеялась.
Почему я иногда забываю, что другие люди тоже адекватны😁
Идеала не существует, а только монотонная и последовательная работа, как я писал во вчерашнем посте.
Благодарю мир за адекватность! Выходные будут кайфовыми🔥
#БудниПрограммиста
❤2👍2
Выкладываю это видео уже после 23:00, но в субботу — значит, в дедлайн уложился🔥
Это 11 видео — и в нём я покажу как полностью уйти от WSL и зависимостей.
Запустим вместе Airflow в Docker — один файл, одна команда, и Airflow, PostgreSQL, MinIO — всё в одном стеке.
Показываю:
❇️ Как настроить WSL в Windows
❇️ Как устроен docker-compose.yml построчно
❇️ Как запустить Airflow в Docker
❇️ Где и как задаются логин/пароль для Airflow
❇️ Как добавить свой DAG и увидеть его в UI
Это идеальный способ быстро поднять окружение для обучения, тестов или CI.
Приятного просмотра — и пусть ваш docker-compose up будет зелёным в трее! 🐳
🎥 Смотреть видео:
▶️ VK: https://vkvideo.ru/video-231048746_456239028
▶️ Youtube: https://youtu.be/x1KlJJzHU-o?si=0NN-uWJUosu4MW2H
P.S. Как Вам новая обложка к видео?☺️
#КакРаботаютДанные #Airflow
Это 11 видео — и в нём я покажу как полностью уйти от WSL и зависимостей.
Запустим вместе Airflow в Docker — один файл, одна команда, и Airflow, PostgreSQL, MinIO — всё в одном стеке.
Показываю:
Это идеальный способ быстро поднять окружение для обучения, тестов или CI.
Приятного просмотра — и пусть ваш docker-compose up будет зелёным в трее! 🐳
🎥 Смотреть видео:
▶️ VK: https://vkvideo.ru/video-231048746_456239028
▶️ Youtube: https://youtu.be/x1KlJJzHU-o?si=0NN-uWJUosu4MW2H
P.S. Как Вам новая обложка к видео?☺️
#КакРаботаютДанные #Airflow
Please open Telegram to view this post
VIEW IN TELEGRAM
VK Видео
Airflow: Запуск в Docker (Windows) #11
Это одиннадцатое видео — и оно про свободу от WSL, зависимостей и головной боли. Сегодня мы поднимаем полный стек Airflow в Docker — с PostgreSQL, MinIO и всем, что нужно, — одной командой. Без установки Python, pip, Postgres и кучи зависимостей. Просто docker…
👍3🔥1
Мониторинг ML-систем: как не проспать падение прода
Привет! 🚀
Сегодня в выпуске #ITИнсайты — еженедельная рубрика с разбором докладов, подкастов и практик из мира IT.
Сегодня разбираем доклад Владимира Кочеткова — «Мониторинг ML-систем в production». Неважно, запускаешь ты ML-модели или другой любой API — мониторинг критичен. Этот выпуск — про то, как ничего не пропустить.
О чём доклад?
Мониторинг ML-систем — не просто про метрики, а про то, как на самом деле следить за жизнью модели после запуска.
Почему это важно?
Рабочая система — это не разовый запуск и без мониторинга:
❗️не узнаешь, что сервис уже 3 часа "падает", а ты спишь.
❗️не заметишь дрейф данных,
❗️ пропустишь падение качества,
Жизненный цикл модели
Мониторинг — не опция, а обязательная часть цикла:
1️⃣Тестирование
2️⃣ Внедрение (MVP, альфа-тесты)
3️⃣Мониторинг в продакшне
Что мониторим?
Три кита:
✅Трафик — сколько запросов приходит?
✅Ошибки — по статус-кодам (500, 400 и т.д.), с мета-информацией.
✅Ресурсы — нагрузка на железо в пиковые моменты.
Главные угрозы в ML-системах
По качеству данных и модели:
🔹Аномалии данных: выбросы, битые форматы, пропуски — всё, что ломает предобработку.
🔹Дрейф данных (data drift): распределение входных признаков изменилось (например, пользователи стали младше).
🔹Дрейф концепции (concept drift): связь между признаками и целевой переменной сместилась ("старый" признак перестал быть значимым, например, рекомендация билетов в кино и театр в период пандемии).
👉Без эталонного датасета и анализа на свежих данных — вы слепы. Модель работает, но даёт мусор.
По инфраструктуре и сервису:
🔹Рост латентности: запросы начинают обрабатываться дольше.
🔹Ошибки 5xx/4xx: сбои на уровне API или бэкенда.
🔹Переполнение очередей: Kafka, RabbitMQ — задержки обработки.
🔹Недостаток ресурсов: не хватает CPU, памяти, GPU.
👉 Эти проблемы могут не затрагивать модель напрямую, но делают её бесполезной — сервис просто не отвечает.
Такой подход показывает, что мониторинг ML-систем — это не только про метрики модели, но и про здоровье всей цепочки: от данных до инфраструктуры.
📌 Ключевые выводы по докладу
✅ Мониторинг — это про "когда и где", а не только "что".
✅ Нужен единый интерфейс, а не Python-скрипты и логи в консоли.
✅ Grafana — лучший выбор для внутренних систем.
✅ WhyLabs — сильный в анализе моделей, но не для железа.
💡 Совет от меня☺️
Настройте шаблон логирования для всех систем. Пусть все метрики пишутся одинаково — так будет проще автоматизировать для построения графиков и метрик в Grafana.
🎧 Рекомендую к прослушиванию:
— ML-инженерам
— DevOps
— Тимлидам
— Тем, кто отвечает за стабильность сервисов
📺 Доклад: https://vkvideo.ru/video-164555658_456241612
💬 Делитесь в комментариях — какие инструменты используете вы для мониторинга?
#ITИнсайты
Привет! 🚀
Сегодня в выпуске #ITИнсайты — еженедельная рубрика с разбором докладов, подкастов и практик из мира IT.
Сегодня разбираем доклад Владимира Кочеткова — «Мониторинг ML-систем в production». Неважно, запускаешь ты ML-модели или другой любой API — мониторинг критичен. Этот выпуск — про то, как ничего не пропустить.
О чём доклад?
Мониторинг ML-систем — не просто про метрики, а про то, как на самом деле следить за жизнью модели после запуска.
Почему это важно?
Рабочая система — это не разовый запуск и без мониторинга:
❗️не узнаешь, что сервис уже 3 часа "падает", а ты спишь.
❗️не заметишь дрейф данных,
❗️ пропустишь падение качества,
Жизненный цикл модели
Мониторинг — не опция, а обязательная часть цикла:
1️⃣Тестирование
2️⃣ Внедрение (MVP, альфа-тесты)
3️⃣Мониторинг в продакшне
Что мониторим?
Три кита:
✅Трафик — сколько запросов приходит?
✅Ошибки — по статус-кодам (500, 400 и т.д.), с мета-информацией.
✅Ресурсы — нагрузка на железо в пиковые моменты.
Главные угрозы в ML-системах
По качеству данных и модели:
🔹Аномалии данных: выбросы, битые форматы, пропуски — всё, что ломает предобработку.
🔹Дрейф данных (data drift): распределение входных признаков изменилось (например, пользователи стали младше).
🔹Дрейф концепции (concept drift): связь между признаками и целевой переменной сместилась ("старый" признак перестал быть значимым, например, рекомендация билетов в кино и театр в период пандемии).
👉Без эталонного датасета и анализа на свежих данных — вы слепы. Модель работает, но даёт мусор.
По инфраструктуре и сервису:
🔹Рост латентности: запросы начинают обрабатываться дольше.
🔹Ошибки 5xx/4xx: сбои на уровне API или бэкенда.
🔹Переполнение очередей: Kafka, RabbitMQ — задержки обработки.
🔹Недостаток ресурсов: не хватает CPU, памяти, GPU.
👉 Эти проблемы могут не затрагивать модель напрямую, но делают её бесполезной — сервис просто не отвечает.
Такой подход показывает, что мониторинг ML-систем — это не только про метрики модели, но и про здоровье всей цепочки: от данных до инфраструктуры.
📌 Ключевые выводы по докладу
✅ Мониторинг — это про "когда и где", а не только "что".
✅ Нужен единый интерфейс, а не Python-скрипты и логи в консоли.
✅ Grafana — лучший выбор для внутренних систем.
✅ WhyLabs — сильный в анализе моделей, но не для железа.
💡 Совет от меня☺️
Настройте шаблон логирования для всех систем. Пусть все метрики пишутся одинаково — так будет проще автоматизировать для построения графиков и метрик в Grafana.
🎧 Рекомендую к прослушиванию:
— ML-инженерам
— DevOps
— Тимлидам
— Тем, кто отвечает за стабильность сервисов
💬 Делитесь в комментариях — какие инструменты используете вы для мониторинга?
#ITИнсайты
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥1
Когда IT-шники поют Любэ и угадывают передачи Малышевой
Вчера посетил встречу с людьми, с которыми раньше практически не общался и почти не знал.
Мы из разных департаментов, работаем над разными продуктами — наши пути просто не пересекались.
Удалёнка такая штука: можно годами работать в одной компании и даже жить в одном городе — а о соседе по Уфе узнать только сейчас.
И вот он — сбор команды. Приглашение пришло в духе:
Планировали 18 человек. Пришли 8. Реальность, как всегда, внесла коррективы:
«У кого-то совещание. Или выкладка на прод. Или осень настигла с ОРВИ.»
Нас было 8, но мы в тельняшках☺️
Собрались в классном лаунже — накрыли еду, настроение и квиз с элементами известных шоу 🎤💃
✅ Пели и веселились.
✅ Танцевали под ретро-биты (звучали Иванушки, Леприконсы, Любэ — честно, я не ожидал, что “А пара трупер” снова будет актуален в 2025).
✅ Отгадывали картинки из фильмов… но с кошками. Это было смешно.
Через час разговаривали, как будто знакомы много лет.
Обсудили всё: от хобби до того, где в Уфе лучшее гусиное мясо и кто где видел молодёжные драки😁 (Споры ещё не закончены. Судьбу города пока не решили.)
Потом — вечерняя прогулка по Уфе.
Ночная тишина и прохлада, воздух, компания и ощущение: «О, мы реально существуем вне экранов!»
Завершили вечер в ресторане — заодно согрелись.
Только искренность, смех и пара историй, которые точно не попадут в корпоративный блог.
Удалёнка даёт свободу — можно работать хоть из бани (если там Wi-Fi).
Но такие встречи напоминают: за каждым ником в VkTeams — живой человек.
С чувством юмора, своими привычками и способностью петь, танцевать и радоваться жизни — даже если голос охрип.
P.S. Теперь знаю, что у нас в компании есть:
🔹Коллега, с которым мы провели детство в одном городе,
🔹Куратор, который может рассказать интересную историю про катание на горных лыжах,
🔹 HR, который узнаёт знакомые места из компьютерных игр.
Огромное спасибо команде HR, которая всё это организовала🔥🔥
Классно создали атмосферу, в которой легко раскрыться, посмеяться и почувствовать, что ты — часть чего-то большего.
Вопрос к подписчикам: Когда в последний раз вы видели своих коллег вживую? Делитесь историями совместных встреч и корпоративов — будем греться душевностью!
P.S. Следующий сбор хочу с караоке! Готовьтесь. Я тренирую Чайфов и Чиж'а!☺️
Вчера посетил встречу с людьми, с которыми раньше практически не общался и почти не знал.
Мы из разных департаментов, работаем над разными продуктами — наши пути просто не пересекались.
Удалёнка такая штука: можно годами работать в одной компании и даже жить в одном городе — а о соседе по Уфе узнать только сейчас.
И вот он — сбор команды. Приглашение пришло в духе:
«Приходите, пообщаться и классно провести время. Будет кайф!»
Планировали 18 человек. Пришли 8. Реальность, как всегда, внесла коррективы:
«У кого-то совещание. Или выкладка на прод. Или осень настигла с ОРВИ.»
Нас было 8, но мы в тельняшках☺️
Собрались в классном лаунже — накрыли еду, настроение и квиз с элементами известных шоу 🎤💃
✅ Пели и веселились.
✅ Танцевали под ретро-биты (звучали Иванушки, Леприконсы, Любэ — честно, я не ожидал, что “А пара трупер” снова будет актуален в 2025).
✅ Отгадывали картинки из фильмов… но с кошками. Это было смешно.
Через час разговаривали, как будто знакомы много лет.
Обсудили всё: от хобби до того, где в Уфе лучшее гусиное мясо и кто где видел молодёжные драки😁 (Споры ещё не закончены. Судьбу города пока не решили.)
Потом — вечерняя прогулка по Уфе.
Ночная тишина и прохлада, воздух, компания и ощущение: «О, мы реально существуем вне экранов!»
Завершили вечер в ресторане — заодно согрелись.
Только искренность, смех и пара историй, которые точно не попадут в корпоративный блог.
Удалёнка даёт свободу — можно работать хоть из бани (если там Wi-Fi).
Но такие встречи напоминают: за каждым ником в VkTeams — живой человек.
С чувством юмора, своими привычками и способностью петь, танцевать и радоваться жизни — даже если голос охрип.
P.S. Теперь знаю, что у нас в компании есть:
🔹Коллега, с которым мы провели детство в одном городе,
🔹Куратор, который может рассказать интересную историю про катание на горных лыжах,
🔹 HR, который узнаёт знакомые места из компьютерных игр.
Огромное спасибо команде HR, которая всё это организовала🔥🔥
Классно создали атмосферу, в которой легко раскрыться, посмеяться и почувствовать, что ты — часть чего-то большего.
Вопрос к подписчикам: Когда в последний раз вы видели своих коллег вживую? Делитесь историями совместных встреч и корпоративов — будем греться душевностью!
P.S. Следующий сбор хочу с караоке! Готовьтесь. Я тренирую Чайфов и Чиж'а!☺️
🔥3❤1
Сегодня было почти видео про теоретический минимум по Kafka.
Но мой внутренний перфекционист внезапно проснулся…
и сказал:
— Подожди, а вот это слайд? Как будто непонятно устройство и логика работы.
И вот я, как настоящая жертва собственного "хочу хорошо", сижу и дополняю важные детали.
Презентация стала красивее, воды — меньше, конкретики — больше.
Суббота — намного короче.
Видео выйдет завтра.
Но зато я сам буду доволен им. А это уже класс.
Спасибо, что терпите мои творческие кризисы 💼
Вы лучшие☺️❤️!
А пока — быстро:
👉 Работали с брокерами сообщений?
🔥 — огонёк (Kafka, RabbitMQ или что-то другое)
👏 — если не пользовались
P.S. Если вы задерживаете дедлайны, потому что «ещё чуть-чуть допилю»… то знайте, я такой же))
Но мой внутренний перфекционист внезапно проснулся…
и сказал:
— Подожди, а вот это слайд? Как будто непонятно устройство и логика работы.
И вот я, как настоящая жертва собственного "хочу хорошо", сижу и дополняю важные детали.
Презентация стала красивее, воды — меньше, конкретики — больше.
Суббота — намного короче.
Видео выйдет завтра.
Но зато я сам буду доволен им. А это уже класс.
Спасибо, что терпите мои творческие кризисы 💼
Вы лучшие☺️❤️!
А пока — быстро:
👉 Работали с брокерами сообщений?
🔥 — огонёк (Kafka, RabbitMQ или что-то другое)
👏 — если не пользовались
P.S. Если вы задерживаете дедлайны, потому что «ещё чуть-чуть допилю»… то знайте, я такой же))
🔥6👏2
Да, миссия выполнена!
В сегодняшнем видео разбираем Apache Kafka с нуля:
✅Что такое Producer и Consumer
✅Зачем нужен Topic и Partition
✅Как работает Offset
✅Почему Kafka — это не просто очередь, а журнал событий
А в следующем видео — как Airflow будет реагировать на события из Kafka. Не по таймеру, а по факту события.
Приятного просмотра — и пусть ваши consumer’ы читают с правильным offset’ом 🐳
🎥 Vk: https://vkvideo.ru/video-231048746_456239029
🎥 YouTube: https://youtu.be/YGXFYbT0H7E?si=hDYWLKdjm4-oWYCG
#КакРаботаютДанные #Kafka
В сегодняшнем видео разбираем Apache Kafka с нуля:
✅Что такое Producer и Consumer
✅Зачем нужен Topic и Partition
✅Как работает Offset
✅Почему Kafka — это не просто очередь, а журнал событий
А в следующем видео — как Airflow будет реагировать на события из Kafka. Не по таймеру, а по факту события.
Приятного просмотра — и пусть ваши consumer’ы читают с правильным offset’ом 🐳
🎥 Vk: https://vkvideo.ru/video-231048746_456239029
🎥 YouTube: https://youtu.be/YGXFYbT0H7E?si=hDYWLKdjm4-oWYCG
#КакРаботаютДанные #Kafka
VK Видео
Kafka. Теоретический минимум. (Как работают данные: практические кейсы) #12
Сегодня разбираем Apache Kafka с нуля: Что такое Producer и Consumer Зачем нужен Topic и Partition Как работает Offset и почему его можно перематывать Почему Kafka — это не просто очередь, а журнал событий А в следующем видео — как Airflow будет реагировать…
🔥6
Марат и его записки программиста
Да, миссия выполнена! В сегодняшнем видео разбираем Apache Kafka с нуля: ✅Что такое Producer и Consumer ✅Зачем нужен Topic и Partition ✅Как работает Offset ✅Почему Kafka — это не просто очередь, а журнал событий А в следующем видео — как Airflow будет реагировать…
И вдогонку, мои мысли о прошедшей недели и свои ощущения от выполненных задач на неделе☺️🔥
👍4
Снятся ли хакатоны электроовцам?🐑
В последние несколько недель принимал участие в разработке задания для хакатона по теме разработки в банкинге — типичный кейс: обработка операций, логирование, аналитика в реальном времени…
И ловлю себя на мысли:
На пару минут даже офигел.
🔹 Больше не требуется проектировать задачу для человека.
🔹 Теперь нужно ставить задачу для человека + ИИ.
LLM меняют не только процесс решения, меняется сама логика постановки задачи.
На секунду стало неприятно и внутренне неудобно:
— А что нас ждёт, если за последние лет 5-7 такой скачок?
— Когда мы перестанем понимать, что внутри кода?
Обдумав, вспомнил:
Технологии всегда пугали. Потому что они двигают нас вперёд.
Именно этот дискомфорт — признак того, что развитие продолжается.
Когда-то преследованию подвергались книгопечатание, потом радио, телевидение и интернет. А теперь это классика☺️
Сейчас очередь искусственного интеллекта.
Интересно жить в эпоху ожившего киберпанка.
Но даже в примере с хакатоном, киберпанк добавляет следующие вопросы:
🔸 Как проверить понимание, а не навык генерации?
🔸 Как пройти по грани обдумывания, а не копипаста?
🔸 Как создать задачу, где ИИ — помощник, а не замена?
Это одновременно напрягает и мотивирует. Мир развивается.
Скорость прогресса иногда пугает.
Но чаще — безумно интересно☺️.
📌 А вы в рабочих процессах используете ИИ?
— Если да — поделитесь, как.
— Если нет — поясните, почему.
Делитесь в комментариях 👇
#БудниПрограммиста
В последние несколько недель принимал участие в разработке задания для хакатона по теме разработки в банкинге — типичный кейс: обработка операций, логирование, аналитика в реальном времени…
И ловлю себя на мысли:
Я автоматически увеличиваю объём задания, потому что при решении будет использоваться LLM.
На пару минут даже офигел.
🔹 Больше не требуется проектировать задачу для человека.
🔹 Теперь нужно ставить задачу для человека + ИИ.
LLM меняют не только процесс решения, меняется сама логика постановки задачи.
На секунду стало неприятно и внутренне неудобно:
— А что нас ждёт, если за последние лет 5-7 такой скачок?
— Когда мы перестанем понимать, что внутри кода?
Обдумав, вспомнил:
Технологии всегда пугали. Потому что они двигают нас вперёд.
Именно этот дискомфорт — признак того, что развитие продолжается.
Когда-то преследованию подвергались книгопечатание, потом радио, телевидение и интернет. А теперь это классика☺️
Сейчас очередь искусственного интеллекта.
Интересно жить в эпоху ожившего киберпанка.
Но даже в примере с хакатоном, киберпанк добавляет следующие вопросы:
🔸 Как проверить понимание, а не навык генерации?
🔸 Как пройти по грани обдумывания, а не копипаста?
🔸 Как создать задачу, где ИИ — помощник, а не замена?
Это одновременно напрягает и мотивирует. Мир развивается.
Скорость прогресса иногда пугает.
Но чаще — безумно интересно☺️.
📌 А вы в рабочих процессах используете ИИ?
— Если да — поделитесь, как.
— Если нет — поясните, почему.
Делитесь в комментариях 👇
#БудниПрограммиста
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥1
ИИ в команде: опыт внедрения
В прошлом посте я делился мыслями о том, как LLM меняют саму логику постановки задач — например, на хакатонах. Сегодня — продолжение этой темы, но уже из практики: что происходит, когда ИИ встраивается в повседневную разработку.
На этот раз — разбор доклада разработчика из K2 Cloud, где массово внедряют аналоги GitHub Copilot.
Выделил основные части и краткое МЕМО по ним.
Зачем нужен Copilot?
✅+25% к производительности за $10/мес с пользователя — мощный экономический аргумент. (это, конечно, по словам разработчиков Copilot b и их метрикам, и скорее всего можно смело делить на 2:D)
✅Менеджеры охотно поддерживают внедрение, тогда как разработчики сначала скептически относились к технологии. (я лично, всеми руками за!)
Проблемы безопасности
🔹Компания не может использовать SaaS-решения вроде GitHub Copilot из-за политик информационной безопасности. Поэтому фокус — на open-source аналогах, которые можно развернуть локально.
Среди open-source вариантов был выбран ContinueDev, так как имел большее количество скачиваний среди open-source конкурентов (2 млн против ~100 тыс. у других).
⚙️ Как это работает?
● Система собирает контекст: текущий файл, соседние, недавно открытые.
● Отправляет запрос модели (например, Llama или Villa).
● Получает подсказку по шаблону fill-in-the-middle.
● Выводится прямо в IDE.
ContinueDev добавляет ещё чат и "агентов", которые могут выполнять действия — но они пока слабо используются.
Что показала аналитика?
❇️ За месяц — 185 тыс. запросов на автодополнение.
❇️ Чатом почти не пользовались: контекст часто терялся, ответы были слишком общими.
❇️ При задержке >10 сек — подсказки исчезали, что сильно раздражало.
❇️ Оптимальная скорость для работы при автоподсказке — 2–3 секунды.
Выбор и обучение модели
● В момент сбора статистики использовали Qwen2.5 Code (в видео есть подробное обоснование).
● Полное дообучение требует 124 ГБ VRAM — дорого.
● Широкое распространение получили методы LoRA/QLoRa, которые обучают только небольшую часть весов, экономя ресурсы. (информативно было это послушать)
В итоге отказались от дообучения: ждут выхода Qwen3 Code, который должен быть ещё лучше (и пройспойлерю, так оно и оказалось😁)
Copilot vs Open Source
✅GitHub Copilot явно впереди: больше контекста, ранжирование подсказок, обучение на принятом коде.
❌ Open-source решения пока уступают в удобстве, индексации кодовой базы и стабильности.
Также интересно было узнать, что качество работы зависит от IDE разработки, так как VsCode лучше оптимизирован для работы с ИИ-плагинами. Так как для локальной разработки я сам юзаю VsCode удивился, узнав, что на данный момент это лидер рынка в этом сегменте☺️👍
Выводы
Понравилось видео. Был удивлен что в целом есть противники внедрения, как по мне - это ускоряет разработку и даёт возможность глубже понять архитектуру. Так как в кампании, где я работаю, такого инструмента пока нет, смотрел с небольшой завистью😄
Удивило, что редко пользовались чатом, скорее всего из-за несовершенства модели 2.5 Coder, так как 3 версия эти задачи классно решает. Сам лично считаю чат классной возможностью расширить свои знания.
🔗Полное видео доклада: https://www.youtube.com/watch?v=3IjRw3f8RDo
💬 P.S.
Сам постоянно пользуюсь LLM в качестве быстрого погружения в тему, настройке различных инструментов (например, на днях быстро поправил настройки keycloak для конкретного клиента) и уточнения по логам ошибок.
Как вы используете ИИ в повседневной жизни и работе?
— Если да — чем и как?
— Если нет — что мешает?
#ITИнсайты
В прошлом посте я делился мыслями о том, как LLM меняют саму логику постановки задач — например, на хакатонах. Сегодня — продолжение этой темы, но уже из практики: что происходит, когда ИИ встраивается в повседневную разработку.
На этот раз — разбор доклада разработчика из K2 Cloud, где массово внедряют аналоги GitHub Copilot.
Выделил основные части и краткое МЕМО по ним.
Зачем нужен Copilot?
✅+25% к производительности за $10/мес с пользователя — мощный экономический аргумент. (это, конечно, по словам разработчиков Copilot b и их метрикам, и скорее всего можно смело делить на 2:D)
✅Менеджеры охотно поддерживают внедрение, тогда как разработчики сначала скептически относились к технологии. (я лично, всеми руками за!)
Проблемы безопасности
🔹Компания не может использовать SaaS-решения вроде GitHub Copilot из-за политик информационной безопасности. Поэтому фокус — на open-source аналогах, которые можно развернуть локально.
Среди open-source вариантов был выбран ContinueDev, так как имел большее количество скачиваний среди open-source конкурентов (2 млн против ~100 тыс. у других).
⚙️ Как это работает?
● Система собирает контекст: текущий файл, соседние, недавно открытые.
● Отправляет запрос модели (например, Llama или Villa).
● Получает подсказку по шаблону fill-in-the-middle.
● Выводится прямо в IDE.
ContinueDev добавляет ещё чат и "агентов", которые могут выполнять действия — но они пока слабо используются.
Что показала аналитика?
Выбор и обучение модели
● В момент сбора статистики использовали Qwen2.5 Code (в видео есть подробное обоснование).
● Полное дообучение требует 124 ГБ VRAM — дорого.
● Широкое распространение получили методы LoRA/QLoRa, которые обучают только небольшую часть весов, экономя ресурсы. (информативно было это послушать)
В итоге отказались от дообучения: ждут выхода Qwen3 Code, который должен быть ещё лучше (и пройспойлерю, так оно и оказалось😁)
Copilot vs Open Source
✅GitHub Copilot явно впереди: больше контекста, ранжирование подсказок, обучение на принятом коде.
❌ Open-source решения пока уступают в удобстве, индексации кодовой базы и стабильности.
Также интересно было узнать, что качество работы зависит от IDE разработки, так как VsCode лучше оптимизирован для работы с ИИ-плагинами. Так как для локальной разработки я сам юзаю VsCode удивился, узнав, что на данный момент это лидер рынка в этом сегменте☺️👍
Выводы
Понравилось видео. Был удивлен что в целом есть противники внедрения, как по мне - это ускоряет разработку и даёт возможность глубже понять архитектуру. Так как в кампании, где я работаю, такого инструмента пока нет, смотрел с небольшой завистью😄
Удивило, что редко пользовались чатом, скорее всего из-за несовершенства модели 2.5 Coder, так как 3 версия эти задачи классно решает. Сам лично считаю чат классной возможностью расширить свои знания.
🔗Полное видео доклада: https://www.youtube.com/watch?v=3IjRw3f8RDo
💬 P.S.
Сам постоянно пользуюсь LLM в качестве быстрого погружения в тему, настройке различных инструментов (например, на днях быстро поправил настройки keycloak для конкретного клиента) и уточнения по логам ошибок.
Как вы используете ИИ в повседневной жизни и работе?
— Если да — чем и как?
— Если нет — что мешает?
#ITИнсайты
Please open Telegram to view this post
VIEW IN TELEGRAM
YouTube
Мы прожили с Copilot год, и вот что из этого вышло. Игорь Анохин, К2 Cloud
Мы прожили с Copilot год, и вот что из этого вышло
Игорь Анохин
Руководитель платформенной разработки, К2 Cloud
В нашей компании с более чем 600 разработчиками мы провели годовой эксперимент c on-premise Copilot решением, чтобы понять, действительно ли…
Игорь Анохин
Руководитель платформенной разработки, К2 Cloud
В нашей компании с более чем 600 разработчиками мы провели годовой эксперимент c on-premise Copilot решением, чтобы понять, действительно ли…
❤2🔥1
🚀 Новое видео: Airflow и Kafka — интеграция для надежной обработки данных!
Приветствую! Подготовил для вас практический гайд по интеграции двух мощных инструментов — Apache Airflow и Apache Kafka.
📌 Что вас ждет в этом видео:
● Настройка Kafka в Docker-окружении с правильной конфигурацией
● Создание Producer DAG для генерации и отправки событий в Kafka
● Consumer DAG для чтения и обработки сообщений с гарантированной доставкой
● Практическая демонстрация работы всей системы
🎥Ссылки на видео:
Vk: https://vkvideo.ru/video-231048746_456239030
Youtube: https://youtu.be/fAhoNLrSzGo?si=jLkbDa2Sz2DRSIFE
Все материалы и код уже ждут вас в репозитории. Не пропустите разбор важнейших аспектов работы с Kafka и Airflow!
Github: https://github.com/MaratNotes/marat_notes/tree/master/how_data_works-practice_cases/13_kafka_airflow
P.S. В комментариях жду ваши вопросы по теме! Какие аспекты работы с Kafka и Airflow вам бы хотелось разобрать подробнее?
#КакРаботаютДанные
Приветствую! Подготовил для вас практический гайд по интеграции двух мощных инструментов — Apache Airflow и Apache Kafka.
📌 Что вас ждет в этом видео:
● Настройка Kafka в Docker-окружении с правильной конфигурацией
● Создание Producer DAG для генерации и отправки событий в Kafka
● Consumer DAG для чтения и обработки сообщений с гарантированной доставкой
● Практическая демонстрация работы всей системы
🎥Ссылки на видео:
Vk: https://vkvideo.ru/video-231048746_456239030
Youtube: https://youtu.be/fAhoNLrSzGo?si=jLkbDa2Sz2DRSIFE
Все материалы и код уже ждут вас в репозитории. Не пропустите разбор важнейших аспектов работы с Kafka и Airflow!
Github: https://github.com/MaratNotes/marat_notes/tree/master/how_data_works-practice_cases/13_kafka_airflow
P.S. В комментариях жду ваши вопросы по теме! Какие аспекты работы с Kafka и Airflow вам бы хотелось разобрать подробнее?
#КакРаботаютДанные
VK Видео
Airflow: Практическое руководство по обработке Kafka-событий (Как работают данные: практические кейсы) #13
Демонстрирую практическую реализацию обработки Kafka-событий в Airflow Материалы по видео : https://github.com/MaratNotes/marat_notes/blob/master/how_data_works-practice_cases/13_kafka_airflow Подписывайся на мой телеграм об IT, разработке и инженирии данных:…
👍6🔥1
Парадокс судей: как бутерброд решает судьбы людей
Всем салют! 👋 Сегодня хочу рассказать о когнитивном искажении из «Думай медленно, решай быстро», которое меня впечатлило и немного шокировало - Парадокс судей.
Суть парадокса
В книге упоминается исследование, где анализировались решения судей по ходатайствам об условно-досрочном освобождении (УДО):
🔹 Вероятность положительного решения (разрешить УДО) была высокой в начале рабочего дня — около 65%.
🔹 Затем она постепенно снижалась почти до 0% к обеду.
🔹 После перерыва на еду вероятность снова резко возрастала до исходного уровня.
То есть судьба человека зависела… от того, успел ли судья поесть и отдохнуть😳.
Почему это парадокс?
Как хочется в идеальном мир: судебные решения должны основываться на фактах, законах и обстоятельствах дела, а не на том, голоден ли судья или устал. Но на практике: эмоциональное и физическое состояние человека оказывает огромное влияние на его решения. В данном случае, усталые и голодные судьи склоняются к более легкому решению по умолчанию и отказывают в УДО.
Личный опыт
Читая про этот парадокс, вспомнил, как на заре карьеры работал в маленьком коллективе на 4-5 человек, и директор все самые важные переговоры с заказчиками назначал аккурат после их обеда😁. Теперь я понимаю, что он, сам того не зная, использовал знание о «парадоксе судьи». И, видимо, это работало, так как договоры заключались!
Lifehack. Как использовать это знание (без нарушения УК😉)
✅ Важные решения, «архитектурные», моральные выборы — буду принимать утром или после полноценного отдыха. Реализовать важную часть логики в конце рабочего дня — плохая идея, шанс на баг вырастает.
✅ Если мне нужно «продать» сложную идею начальнику или коллегам, буду стараться назначать встречу на время, когда они с большей вероятностью будут в ресурсе (не перед обедом и не в пятницу вечером). Это повышает шанс на положительное решение.
💭 Финал
Получается, справедливость — понятие не только юридическое, но и биохимическое. Осознание этого парадокса не делает мир несправедливее. Можно осознать дополнительный факт, который стоит учитывать👍.
📌 А Вы замечали, что Ваши решения зависят от времени суток, голода или усталости?
#ОшибкиМышления #Книги
Всем салют! 👋 Сегодня хочу рассказать о когнитивном искажении из «Думай медленно, решай быстро», которое меня впечатлило и немного шокировало - Парадокс судей.
Суть парадокса
В книге упоминается исследование, где анализировались решения судей по ходатайствам об условно-досрочном освобождении (УДО):
🔹 Вероятность положительного решения (разрешить УДО) была высокой в начале рабочего дня — около 65%.
🔹 Затем она постепенно снижалась почти до 0% к обеду.
🔹 После перерыва на еду вероятность снова резко возрастала до исходного уровня.
То есть судьба человека зависела… от того, успел ли судья поесть и отдохнуть😳.
Почему это парадокс?
Как хочется в идеальном мир: судебные решения должны основываться на фактах, законах и обстоятельствах дела, а не на том, голоден ли судья или устал. Но на практике: эмоциональное и физическое состояние человека оказывает огромное влияние на его решения. В данном случае, усталые и голодные судьи склоняются к более легкому решению по умолчанию и отказывают в УДО.
Личный опыт
Читая про этот парадокс, вспомнил, как на заре карьеры работал в маленьком коллективе на 4-5 человек, и директор все самые важные переговоры с заказчиками назначал аккурат после их обеда😁. Теперь я понимаю, что он, сам того не зная, использовал знание о «парадоксе судьи». И, видимо, это работало, так как договоры заключались!
Lifehack. Как использовать это знание (без нарушения УК😉)
✅ Важные решения, «архитектурные», моральные выборы — буду принимать утром или после полноценного отдыха. Реализовать важную часть логики в конце рабочего дня — плохая идея, шанс на баг вырастает.
✅ Если мне нужно «продать» сложную идею начальнику или коллегам, буду стараться назначать встречу на время, когда они с большей вероятностью будут в ресурсе (не перед обедом и не в пятницу вечером). Это повышает шанс на положительное решение.
💭 Финал
Получается, справедливость — понятие не только юридическое, но и биохимическое. Осознание этого парадокса не делает мир несправедливее. Можно осознать дополнительный факт, который стоит учитывать👍.
📌 А Вы замечали, что Ваши решения зависят от времени суток, голода или усталости?
#ОшибкиМышления #Книги
❤3
Утренний апгрейд: с бега на велосипед
По утрам, до начала рабочего дня, я стараюсь проводить лёгкую тренировку (low pulse cardio) — чтобы привести мысли в порядок и разогнать активность перед погружением в код, DAG’и и обсуждения.
🔄 Смена стека
Раньше это был бег.
Но этот требует дополнительного времени: добраться до места тренировки (около 15 минут в одну сторону), размяться, пробежать, вернуться, принять душ…
В общем, долго по логистике.
Перешел на велосипед. Тот самый, что годами стоял на техобслуживании — задача по его ремонту висела в трекере с меткой low priority. Спас друг: сделал за меня часть ресерча и нашел в соседней деревне молодого парня (лет 16, красавчик, что ищет способы заработка и привнесения доли упорядоченности и счастья в мир👍), который за адекватные деньги провел полный апгрейд: заменил амортизаторы, настроил передачи, поставил новые ниппели…
Теперь велосипед работает как новый. Полностью доволен.
🚴Новый маршрут
Собственно, к истории. Обычно я езжу по трассе — привычный маршрут, предсказуемый, но скучноватый. И, честно, горок там слишком много — утомляют даже в лёгком темпе.
Вчера решил разнообразить — поехал к реке.
Маршрут проходит через маленькую деревню, где построены премиальные дома — так что добавляется лёгкий элемент экскурсии: “О, особняк в стиле готики… А тут цветник прям на дороге - красиво!"
И вот, на одной из улиц, посреди дороги лежали две собаки. Сначала подумал: “Что за мешок такой странной формы?” Потом понял — собаки. Одна — большая, черная, спокойная. Вторая — помельче, размером с кокер-спаниеля. Подумал: «Прикольно, лежат себе». Проезжаю мимо — большая даже ухом не повела, а вот маленькая... Видимо, испугалась и решила, что лучшая защита — это нападение. Сделала резкий выпад и цапнула за икру! 😅
Боль была символической. Я даже не остановился — подумал: “Ну, мелочь, ничего страшного”.
📈Итоги инциндента
Вообще назад планировал поехать поэтому же маршруту, но решил: "На фиг надо!". Cделал круг и вернулся по другой улице.
Далее зашел в магазин купить творог, колу и шоколадку (баланс белков и глюкозы!). И только там заметил, что штанина мокрая. Оказалось, даже самый «легкий укус» способен кровоточить. А к обеду на этом месте расцвел такой синяк, что можно было проводить презентацию на тему «Недооцененные риски периферийных маршрутов».
💡Мораль
Даже самый гладкий апгрейд и смена стека😁 (с бега на велосипед) не защитят от внезапных багов в продакшене в виде местной собаки для тестирования нагрузки. Хорошо, что зачастую можно найти запасной маршрут!
💬 А у вас были похожие неожиданные случаи во время тренировок или прогулок? Делитесь в комментах!
#ХоббиПрограммиста
По утрам, до начала рабочего дня, я стараюсь проводить лёгкую тренировку (low pulse cardio) — чтобы привести мысли в порядок и разогнать активность перед погружением в код, DAG’и и обсуждения.
🔄 Смена стека
Раньше это был бег.
Но этот требует дополнительного времени: добраться до места тренировки (около 15 минут в одну сторону), размяться, пробежать, вернуться, принять душ…
В общем, долго по логистике.
Перешел на велосипед. Тот самый, что годами стоял на техобслуживании — задача по его ремонту висела в трекере с меткой low priority. Спас друг: сделал за меня часть ресерча и нашел в соседней деревне молодого парня (лет 16, красавчик, что ищет способы заработка и привнесения доли упорядоченности и счастья в мир👍), который за адекватные деньги провел полный апгрейд: заменил амортизаторы, настроил передачи, поставил новые ниппели…
Теперь велосипед работает как новый. Полностью доволен.
🚴Новый маршрут
Собственно, к истории. Обычно я езжу по трассе — привычный маршрут, предсказуемый, но скучноватый. И, честно, горок там слишком много — утомляют даже в лёгком темпе.
Вчера решил разнообразить — поехал к реке.
Маршрут проходит через маленькую деревню, где построены премиальные дома — так что добавляется лёгкий элемент экскурсии: “О, особняк в стиле готики… А тут цветник прям на дороге - красиво!"
И вот, на одной из улиц, посреди дороги лежали две собаки. Сначала подумал: “Что за мешок такой странной формы?” Потом понял — собаки. Одна — большая, черная, спокойная. Вторая — помельче, размером с кокер-спаниеля. Подумал: «Прикольно, лежат себе». Проезжаю мимо — большая даже ухом не повела, а вот маленькая... Видимо, испугалась и решила, что лучшая защита — это нападение. Сделала резкий выпад и цапнула за икру! 😅
Боль была символической. Я даже не остановился — подумал: “Ну, мелочь, ничего страшного”.
📈Итоги инциндента
Вообще назад планировал поехать поэтому же маршруту, но решил: "На фиг надо!". Cделал круг и вернулся по другой улице.
Далее зашел в магазин купить творог, колу и шоколадку (баланс белков и глюкозы!). И только там заметил, что штанина мокрая. Оказалось, даже самый «легкий укус» способен кровоточить. А к обеду на этом месте расцвел такой синяк, что можно было проводить презентацию на тему «Недооцененные риски периферийных маршрутов».
💡Мораль
Даже самый гладкий апгрейд и смена стека😁 (с бега на велосипед) не защитят от внезапных багов в продакшене в виде местной собаки для тестирования нагрузки. Хорошо, что зачастую можно найти запасной маршрут!
💬 А у вас были похожие неожиданные случаи во время тренировок или прогулок? Делитесь в комментах!
#ХоббиПрограммиста
🔥3
Марат и его записки программиста
Утренний апгрейд: с бега на велосипед По утрам, до начала рабочего дня, я стараюсь проводить лёгкую тренировку (low pulse cardio) — чтобы привести мысли в порядок и разогнать активность перед погружением в код, DAG’и и обсуждения. 🔄 Смена стека Раньше…
Пара фото в догонку, почти сразу после инцидента с укусом😉
👍2
Когда Kafka — не панацея: Sharded Task Queue от Яндекса
На канале сейчас рассказываю про Kafka (тык1, тык2) и её использовании при построении ETL-процессов. Поэтому сегодня решил разобрать доклад, где Kafka оказалась недостаточным решением — про внутреннюю систему Яндекса Sharded Task Queue (STQ).
🔹 Что такое STQ?
Это месседж-брокер, а не классический сервер очередей (вроде Kafka или RabbitMQ).
Основная цель: надёжное выполнение отложенных задач с произвольной точностью (например, отправить уведомление через 40 минут, или месяц или год).
Система не сохраняет порядок задач, что критически важно для отложенных операций.
🔹 Как рождалось решение.
Авторы не стали сразу пилить монстра. Они честно говорят, что решали проблему одну за другой, как и бывает в реальных задачах. Это показывает инженерную работу, а не просто презентацию готового результата. В итоге сложились следующие требования:
Базовые: Произвольная точность выполнения, ретраи, независимость от падений сервисов.
Инфраструктурные: Долгосрочное хранение, наблюдаемость, масштабируемость для высоких нагрузок и кросс-платформенность (поддержка разных языков программирования).
Именно эти требования сразу отсекли простые варианты вроде Cron и заставили искать специализированное решение.
🔹 Сравнение с Kafka и RabbitMQ
Главный вывод: классические брокеры — это про порядок (FIFO), а отложенные задачи — про произвольный доступ ко времени выполнения. Попытка сделать «отложенную очередь» на Kafka — это костыли. STQ же хранит задачи как база данных с индексами, что позволяет гибко двигать их по времени. Это ключевое архитектурное отличие, продиктованное требованиями.
🔹 Результат
Система стала критической инфраструктурой для 700+ микросервисов (такси, доставка, банк) с пиковой нагрузкой под 150k RPS. Философия — «разработчик не должен думать о проблемах очередей», и судя по отзывам, у них получилось.
🔸 Что огорчило
Информационный вакуум. Кроме этого видео и пары упоминаний в вакансиях, подробной информации не нашел. Возможно, есть ещё пару докладов, но в названии и контексте там не указана STQ. Очень жаль, что такая крутая инженерная разработка не имеет публичной документации. Хочется заглянуть под капот!
✅ Итог
Отличный пример, что нет серебряной пули. Инструменты вроде Kafka — мощные, но для узких задач (как отложенные выполнения) часто нужны специализированные решения.
Ссылка на доклад: https://vkvideo.ru/video-17796776_456241737?pid=152308462
💬 А Вы сталкивались с задачами, где классические брокеры не подходили? Либо когда публично-известное решение обладало рядом существенных недостатков и нужно было реализовывать собственное решение?
Интересно обменяться кейсами!
#ITИнсайты
На канале сейчас рассказываю про Kafka (тык1, тык2) и её использовании при построении ETL-процессов. Поэтому сегодня решил разобрать доклад, где Kafka оказалась недостаточным решением — про внутреннюю систему Яндекса Sharded Task Queue (STQ).
🔹 Что такое STQ?
Это месседж-брокер, а не классический сервер очередей (вроде Kafka или RabbitMQ).
Основная цель: надёжное выполнение отложенных задач с произвольной точностью (например, отправить уведомление через 40 минут, или месяц или год).
Система не сохраняет порядок задач, что критически важно для отложенных операций.
🔹 Как рождалось решение.
Авторы не стали сразу пилить монстра. Они честно говорят, что решали проблему одну за другой, как и бывает в реальных задачах. Это показывает инженерную работу, а не просто презентацию готового результата. В итоге сложились следующие требования:
Базовые: Произвольная точность выполнения, ретраи, независимость от падений сервисов.
Инфраструктурные: Долгосрочное хранение, наблюдаемость, масштабируемость для высоких нагрузок и кросс-платформенность (поддержка разных языков программирования).
Именно эти требования сразу отсекли простые варианты вроде Cron и заставили искать специализированное решение.
🔹 Сравнение с Kafka и RabbitMQ
Главный вывод: классические брокеры — это про порядок (FIFO), а отложенные задачи — про произвольный доступ ко времени выполнения. Попытка сделать «отложенную очередь» на Kafka — это костыли. STQ же хранит задачи как база данных с индексами, что позволяет гибко двигать их по времени. Это ключевое архитектурное отличие, продиктованное требованиями.
🔹 Результат
Система стала критической инфраструктурой для 700+ микросервисов (такси, доставка, банк) с пиковой нагрузкой под 150k RPS. Философия — «разработчик не должен думать о проблемах очередей», и судя по отзывам, у них получилось.
🔸 Что огорчило
Информационный вакуум. Кроме этого видео и пары упоминаний в вакансиях, подробной информации не нашел. Возможно, есть ещё пару докладов, но в названии и контексте там не указана STQ. Очень жаль, что такая крутая инженерная разработка не имеет публичной документации. Хочется заглянуть под капот!
✅ Итог
Отличный пример, что нет серебряной пули. Инструменты вроде Kafka — мощные, но для узких задач (как отложенные выполнения) часто нужны специализированные решения.
Ссылка на доклад: https://vkvideo.ru/video-17796776_456241737?pid=152308462
💬 А Вы сталкивались с задачами, где классические брокеры не подходили? Либо когда публично-известное решение обладало рядом существенных недостатков и нужно было реализовывать собственное решение?
Интересно обменяться кейсами!
#ITИнсайты
VK
Не Кафкой единой / Серёжа Бунатян
На Яндекс Dev Day&Night Серёжа Бунатян, руководитель разработки инфраструктуры пользовательских продуктов, рассказал про собственный инструмент Яндекса для асинхронного обмена сообщениями между микросервисами. В докладе Серёжа остановился на преимуществах…
🔥1
ETL. Коротко о важном.
Вы когда-нибудь запускали DAG, который работает сам — и не требует вашего участия?
В этом видео:
● Что такое ETL на самом деле
● Ключевые характеристики процесса на проде
● Batch vs Streaming: когда что использовать
● Пример использования обоих подходов на возможном кейсе
И главное — почему хороший ETL — это система, которая работает без тебя
👉 https://vkvideo.ru/video-231048746_456239032
👉 https://youtu.be/oo2e15ohHY4
P.S. Накопились вопросы по видеоконтенту, завтра опубликую пост про это, прошу поучаствовать в ответах🤗
#КакРаботаютДанные
Вы когда-нибудь запускали DAG, который работает сам — и не требует вашего участия?
В этом видео:
● Что такое ETL на самом деле
● Ключевые характеристики процесса на проде
● Batch vs Streaming: когда что использовать
● Пример использования обоих подходов на возможном кейсе
И главное — почему хороший ETL — это система, которая работает без тебя
👉 https://vkvideo.ru/video-231048746_456239032
👉 https://youtu.be/oo2e15ohHY4
P.S. Накопились вопросы по видеоконтенту, завтра опубликую пост про это, прошу поучаствовать в ответах🤗
#КакРаботаютДанные
VK Видео
ETL: Что это и как работает (Как работают данные: практические кейсы) #14
Рассказываю о том что такое ETL, какие к нему требования, каких типов бывают и рассматриваю два типа ETL на схожие данные. Материалы по видео : https://github.com/MaratNotes/marat_notes/tree/master/how_data_works-practice_cases/14_ETL Подписывайся на мой…
🔥4
Приветствую!
Хочу посоветоваться по видеоконтенту.
Пишите в комментариях: какие темы вам интересны?
Мои планы на ближайшие недели:
1️⃣ Видео про Task Flow API
— Уже от нескольких подписчиков была просьба
— Покажу, как он упрощает написание DAG’ов
2️⃣ Дополнительные аспекты Kafka*
— Также был запрос от подписчика
— Best practices: retention, offset’ы
— Как не сломать топик при первых запусках
— Что делать, если consumer “отстал”
*возможно, это будет после пункта 3 и реализации потокового режима для примера магазина
3️⃣ Реализация пакетного режима для интернет-магазина с последнего видео
— Генерируем заказы, пользователей, покупки
— Обрабатываем через Airflow + Kafka
— Без event-driven, но надёжно
А дальше при обзоре новой темы, будем добавлять логику в этот пример с магазином.
— Добавлю мониторинг (кто, что, когда)
— Настрою логирование (чтобы было видно, где сломалось)
— Введу data lineage — кто обработал, откуда взял
Чтобы показать:
не “вот мой DAG”, а “вот как растёт настоящая система”.
Жду ваших мыслей. Какие темы хотели бы увидеть?
Спасибо, что читаете🤗
Хочу посоветоваться по видеоконтенту.
Пишите в комментариях: какие темы вам интересны?
Мои планы на ближайшие недели:
1️⃣ Видео про Task Flow API
— Уже от нескольких подписчиков была просьба
— Покажу, как он упрощает написание DAG’ов
2️⃣ Дополнительные аспекты Kafka*
— Также был запрос от подписчика
— Best practices: retention, offset’ы
— Как не сломать топик при первых запусках
— Что делать, если consumer “отстал”
*возможно, это будет после пункта 3 и реализации потокового режима для примера магазина
3️⃣ Реализация пакетного режима для интернет-магазина с последнего видео
— Генерируем заказы, пользователей, покупки
— Обрабатываем через Airflow + Kafka
— Без event-driven, но надёжно
А дальше при обзоре новой темы, будем добавлять логику в этот пример с магазином.
— Добавлю мониторинг (кто, что, когда)
— Настрою логирование (чтобы было видно, где сломалось)
— Введу data lineage — кто обработал, откуда взял
Чтобы показать:
не “вот мой DAG”, а “вот как растёт настоящая система”.
Жду ваших мыслей. Какие темы хотели бы увидеть?
Спасибо, что читаете🤗
Такое разное кэширование: как вывозить нагрузку, когда данных много
Если вы работаете с высокими нагрузками и большими данными, это видео — must see. Степан Полохин из Яндекса на примере взаимодействия с колоссальным монорепозиторием (14 ТБ, 8000 коммитов в день!!!) рассказывает, как спасает ситуацию грамотное кэширование.
Что особенно понравилось:
Докладчик виртуозно сочетает глубокую проработку темы с понятностью изложения. Сложные концепции кэширования и устройство собственной СУБД «Object» объясняются настолько ясно, что становятся доступны даже не-экспертам. Отдельно хочется отметить качество слайдов — они визуализируют сложные архитектурные решения без лишней воды, что делает материал предельно наглядным.
Ключевые идеи доклада:
1️⃣ Кэшируйте всё, что движется. Главный вывод доклада. Тяжёлые операции вроде подсчёта разницы между коммитами не должны вычисляться каждый раз. Готовый ответ из кэша радикально ускоряет работу и разгружает серверы.
2️⃣ Многоуровневый подход — ключ к успеху. Яндекс использует сразу несколько стратегий:
● Фоновый прогрев кэшей: Кэши заранее подготавливаются в фоне. Это нужно, чтобы на старте сервера, он имел возможность сразу быть доступным и иметь возможность отвечать.
● Кэши на диске: Собственная БД «Object» позволяет ускорить запуск серверов и избежать излишнее число запросов запросов к основной базе данных.
● Кэширование ответов: Результаты тяжёлых запросов кэшируются целиком.
3️⃣ Индексы — ваш друг. Для ускорения сложных запросов (например, история изменений файла) необходимы специальные индексы. В системе их уже несколько, и этого мало — команда разрабатывает очередной.
Кому смотреть?
Бэкенд-инженерам, разработчикам высоконагруженных систем и всем, кто хочет понять, как работают с экстремальными масштабами в практике крупнейших IT-компаний.
Ссылка на видео: https://vkvideo.ru/video-65336816_456239606
Это тот случай, когда ценность — не только в теме доклада, но и в подаче. Рекомендую к просмотру для прокачки своего понимания работы высоконагруженных систем и навыков доклада презентации!
#ITИнсайты
Если вы работаете с высокими нагрузками и большими данными, это видео — must see. Степан Полохин из Яндекса на примере взаимодействия с колоссальным монорепозиторием (14 ТБ, 8000 коммитов в день!!!) рассказывает, как спасает ситуацию грамотное кэширование.
Что особенно понравилось:
Докладчик виртуозно сочетает глубокую проработку темы с понятностью изложения. Сложные концепции кэширования и устройство собственной СУБД «Object» объясняются настолько ясно, что становятся доступны даже не-экспертам. Отдельно хочется отметить качество слайдов — они визуализируют сложные архитектурные решения без лишней воды, что делает материал предельно наглядным.
Ключевые идеи доклада:
● Фоновый прогрев кэшей: Кэши заранее подготавливаются в фоне. Это нужно, чтобы на старте сервера, он имел возможность сразу быть доступным и иметь возможность отвечать.
● Кэши на диске: Собственная БД «Object» позволяет ускорить запуск серверов и избежать излишнее число запросов запросов к основной базе данных.
● Кэширование ответов: Результаты тяжёлых запросов кэшируются целиком.
Кому смотреть?
Бэкенд-инженерам, разработчикам высоконагруженных систем и всем, кто хочет понять, как работают с экстремальными масштабами в практике крупнейших IT-компаний.
Ссылка на видео: https://vkvideo.ru/video-65336816_456239606
Это тот случай, когда ценность — не только в теме доклада, но и в подаче. Рекомендую к просмотру для прокачки своего понимания работы высоконагруженных систем и навыков доклада презентации!
#ITИнсайты
Please open Telegram to view this post
VIEW IN TELEGRAM
VK Видео
Степан Полохин. Такое разное кэширование: как вывозить нагрузку, когда данных много
В докладе я расскажу о том, на какие ухищрения идёт Яндекс VCS, чтобы сделать работу с хранимым в ней исходным кодом быстрой и эффективной. - Ленивые данные. Самый быстрый запрос — тот, который не случился. - Кэши в памяти. Повторим базу, которую нужно знать:…
🔥2