💬 Модели доставки сообщений: Push и Pull

При проектировании интеграционных взаимодействий важно понимать две базовые модели доставки сообщений: Push ("толкай") и Pull ("тяни"). Поэтому давайте рассмотрим их ключевые особенности.

📌 Push ("Толкай")

- Кратко: Источник сам отправляет ("выталкивает") сообщение получателю.
- Иллюстрация: Курьерская служба по мере поступления заказов направляет посылки водителям. Если водитель перегружен заказами, эффективность падает.
- Подробнее: Система немедленно передаёт сообщение клиенту, как только оно поступает в саму систему или создано в ней.
- Используется: В RabbitMQ.
- Преимущества: Быстрая передача сообщений; меньшая нагрузка на хранилище брокера.
- Недостатки: Возможна перегрузка клиента при большом количестве входящих сообщений.

📌 Pull ("Тяни")

- Кратко: Потребитель сам запрашивает ("вытягивает") сообщения из источника.
- Иллюстрация: Библиотека, в которой читатели берут книги, когда сами готовы их читать. При этом брать сразу множество книг непрактично.
- Подробнее: Клиенты сами выбирают нужный момент для чтения сообщений.
- Используется: В Apache Kafka.
- Преимущества: Избегает перегрузок клиента, помогает оптимизировать обработку большого объёма данных.
- Недостатки: Требует больше внимания к разработке клиентов; увеличивается потребление ресурсов на хранение сообщений.

#интеграции #брокеры

👀 Такие разные канарейки

Многие наверняка слышали историю о шахтёрах, которые в XX веке брали с собой в шахту клетку с канарейкой.

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

Сегодня вместо птиц используются современные электронные газоанализаторы, однако эта старая практика нашла отражение в мире IT, породив ряд интересных терминов, напоминающих нам о тех временах.


🦆 Канареечное развёртывание (Canary Deployment), или канареечный релиз (Canary Release)

Подход, предполагающий постепенное раскатывание функциональности на клиентов.

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

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


🐦‍ Канареечное тестирование (Canary Testing)

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

Фактически то же самое, что и канареечное развёртывание, однако данный термин акцентирует внимание именно на процессе тестирования, а не механизме внедрения изменений.

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


🦉 Канареечный токен (Canary Token)

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

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

Стоит отметить, что к канареечным токенам часто относят и другие механизмы для обнаружения утечек: фиктивный файл или запись в БД, адрес электронной почты и HTTP-ссылка. Работает это следующим образом: если злоумышленник взаимодействует с этим токеном (открывает файл, переходит по ссылке и т.п.), он незаметно для себя отправляет сигнал владельцам системы. Это канарейка, которая "поëт".


🦜 Ловушка для канареек (Canary Trap)

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

Принцип: в документ внедряются уникальные изменения (опечатки, специфическое форматирование и т.п.). Если документ слит, то по этим меткам можно точно определить источник утечки.


🪿 Стековая канарейка (Stack Canary)

Механизм защиты, предотвращающий исполнение вредоносного кода вследствие переполнений стека.

Как работает: во время каждого вызова функции в память добавляется специальное секретное значение (канарейка). Если оно изменяется перед выходом из функции, система немедленно прерывает своё выполнение и сигнализирует о попытке хакерской атаки.


🔍 Итого

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

#термины #проектирование #ai #qa #инфобез

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

Кандидат на позицию аналитика уровня middle/middle+ представила резюме, буквально нашпигованное баззвордами индустрии. Kubernetes, Kafka, MSA, EDA и прочие модные слова — казалось, невозможно было найти технологию, которой не нашлось бы места в этом документе.

И это на фоне того, что диплом о высшем образовании был получен всего лишь в 2025г.🤔 Само по себе это уже вызывало нехорошие подозрения, а состоявшееся позднее собеседование шансы их развеять и вовсе свело к нулю. Но об этом поподробнее. 👇

Сначала впечатление от рассказов девушки просто зашкаливало. Её речь звучала безупречно: она локально поднимала контейнеры, рисовала макеты в Figma вместо дизайнера, согласовывала пуллреквесты разработчиков, восстанавливала логику по исходному коду, отслеживала баги на проде и делала много чего ещё. Рассказанное звучало потрясающе… разве что слишком хорошо, чтобы быть правдой.👀

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

Чёткими маркерами обмана стали многократные неверные произношения одних и тех же терминов: "откладка", "манго ди-би", "идемпотичный", "элк стак", "кейси эм-эль", "эн-восемь-эн" (видимо, прочтение онлайн незнакомых терминов предательски подводило), а также декламируемые команды и ключевые слова для решения задач (например, ALTER TABLE и NOT NULL).

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

Могу сказать наверняка: логарифмы с точностью до десятых в голове, да ещё и за микросекунды, считать не научилась ещё ни одна вчерашняя студентка вуза.🤣🤣🤣

Забавно? Ещё бы! А я ведь перечислил лишь часть занимательных моментов нашего интервью.

Но отдельно впечатлила манера речи девушки: интонационные акценты, варьирование высоты голоса и время от времени звучащие с нотками досады оговорки вроде:

Боже мой, опять я сказала „сервис“, а не „сервер“!

Такое выступление достойно сцены МХАТа 🎭, а не скромного айтишного офиса! Но вернёмся к делу.

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


Итак, подведём итог. ☝️

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

#собесы #ai #войтивайти

Вспомнилась история, некогда рассказанная коллегой на прошлой работе. Вот она.

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

Но в этот момент "безопасник" переводит на неё взгляд и спокойным отстранённым тоном выдаёт, что фото на пропуске должно быть реалистичным, ведь служит оно не для красоты, а для того, чтобы можно было быстро опознать тело. 😈 Занавес!

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

#стейкхолдеры #требования

⚡️ Только бы нам ночь простоять да день продержаться

Ассоциация AITEX объявила о проведении в последние дни февраля нового мероприятия — AITEX Summit Winter 2026: From Insight to Action.

В этот раз хакатон посвящён современным направлениям работы с данными: Product Analytics, Operational Analytics, Business Analytics, Open Analytics.

Звучит интересно? Вот и я так подумал. Но на этом история не заканчивается. 👇

Примерно в тот же период Hackathon Raptors будет проводить свой хакатон — sudo make world.

Соревнования будут проводиться по 6 направлениям: Education, Climate, Health, Civic, Tools, Wildcard. На выходе должны получиться open source решения, которые делают жить лучше.

👁‍🗨 Участников обоих хакатонов ждёт строгая оценка международных жюри — всё как полагается. Вот только тут закавыка вышла: я попал сразу в оба состава этих уважаемых комиссий. Ну что ж, запасаюсь кофеином и желаю себе побольше выдержки 😅

#анонсы #достижения #события #судейства

🧑‍💻 Кэши разные нужны, кэши разные важны

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

И в зависимости от того, о каком компоненте системы идёт речь, можно выделить несколько основных типов кэша.


🔲 Аппаратный кэш (Hardware Cache)

Включает в себя физические компоненты оборудования, например:

🟡кэш CPU — высокоскоростная память внутри процессора, предназначенная для хранения часто используемых инструкций и данных. Кэширование в CPU позволяет обеспечить быстрый доступ процессора к ним, минуя обращение к основной оперативной памяти (RAM). Кэш CPU разделяется на несколько уровней (L1, L2, L3), отличающихся скоростью и объёмом.
🟡кэш GPU — аналогичный аппаратный кэш в графическом процессоре, предназначенный для ускорения обработки графики и хранения данных, нужных для рендеринга. Эта память обеспечивает быстрый доступ к данным шейдеров, текстурам, буферу кадров и другим элементам визуализации.
🟡кэш DRAM — это отдельная микросхема оперативной памяти, встроенная прямо в SSD. Её основная задача — хранить таблицу размещения файлов, чтобы контроллер накопителя мог мгновенно находить нужные данные на диске. В отличие от остальных кэшей данный вид не предполагает непосредственное хранение запрашиваемых данных, а служит навигатором по ним.


🖥 Программный кэш (Software Cache)

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

К данному типу кэша можно отнести:

🟡Внутренний кэш СУБД — кэш, размещённый в оперативной памяти и управляемый непосредственно системой управления базой данных (СУБД). Когда приложение запрашивает данные из базы, СУБД первым делом проверяет их наличие в своём внутреннем кэше, чтобы минимизировать обращение к жёсткому диску (HDD) или твёрдотельному накопителю (SSD).
🟡Внешние решения, например, Redis, Apache Ignite, Memcached и аналогичные инструменты. Эти системы позволяют создавать высокопроизводительные механизмы для сохранения и повторного использования промежуточных результатов вычислений и часто используемых данных.


🌐 Веб-кэш (Web Cache)

Обеспечивает эффективность передачи контента по сети и включает в себя три ключевых компонента:

🟡Кэш браузера — сохраняет файлы веб-ресурсов (CSS, JavaScript, изображения и др.) на устройстве пользователя, позволяя быстрее загружать страницы при повторных посещениях.
🟡Прокси-кэш, или HTTP-кэш — сохраняет копии запросов и ответов на промежуточных прокси-серверах, снижая количество обращений к исходному серверу и сокращая сетевую нагрузку.
🟡CDN (Content Delivery Networks) — это глобальные сети серверов, предназначенные для распределения контента по географическим регионам (или даже по всему миру), что уменьшает задержки и увеличивает доступность контента.


🗄️ DNS-кэш (DNS Cache)

Служит для временного хранения соответствий между доменными именами и IP-адресами, позволяя быстро разрешать адреса (например, ya.ru 👉 5.255.255.242) без необходимости обращаться к внешним DNS-серверам.

Принцип работы. Когда пользователь вводит адрес сайта, система сначала ищет его IP в локальном кэше. Если IP есть в кэше, сайт загружается сразу. Если нет, система проверяет системный DNS-кэш устройства, а если и он не знает — идёт к DNS-серверу провайдера. Если последний также не знает, то последовательно "разматывается" вся цепочка обращений к вышестоящим серверам вплоть до корневых серверов DNS (Root Servers).


🔍 Итого

Понятие "кэш" охватывает широкий спектр технологий и методов, направленных на повышение эффективности работы IT-инфраструктуры и приложений.

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

#проектирование #данные #термины

🐠 Оставайся, мальчик, с нами!

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

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

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

Прошло некоторое время, друг решил действовать и отправился на собеседование в другую компанию. Там ему оперативно сделали предложение: бессрочный трудовой договор, зарплата выше нынешней, квартальные премии и полная удалённая работа. Бинго! 💵

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

Спустя пару дней последовал звонок от HR текущего работодателя: мол, готовы предложить перейти в штат. Что дальше? А дальше началось шоу абсурда.🤡

Другу предложили бессрочный трудовой договор, но только на гибридной основе (посещение офиса три раза в неделю), да ещё и зарплату ниже той, что обещана в другом месте, плюс меньшую премию.

Вот такая вот странная попытка удержать сотрудника. Герой истории удивлён: по всем параметрам условия хуже. В чëм подвох, зачем это сделано? Возможно, хотели проверить его на стрессоустойчивость и чувство юмора одновременно? 😬

Но правда ведь забавно получается: зачем предлагать заведомо худшие условия? Просто загадка века!

🍲 Трёшка! Мы её теряем!

Согласно данным РБК, для одобрения ипотеки на приобретение скромной трёшки в российских городах-миллионниках потребуется зарплата в среднем 257'800 руб.

Если говорить о Москве, то планка необходимого дохода поднимется до 715'500. Питер и Казань занимают почётное второе и третье место соответственно.

Не знаю, как вам, а меня цифры впечатляют. Особенно что касается столицы.

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

Так вот, при средней 225'000 руб. с разбросом ± 90'000 руб. выглядит так, что трёшка системному аналитику, скорее всего, не светит чисто математически. Для того, чтобы получить на неё ипотеку квалифицированному специалисту может потребоваться рост доходов в 2.5-3 раза от текущих уровней.

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

#жиза #экономика #ипотека #недвижимость #зарплаты