Праздники в ИТ часто выглядят одинаково — независимо от десятилетия. Меньше людей в офисах, меньше изменений в инфраструктуре, меньше внимания к мелочам. И сегодня мы воспринимаем это как очевидную истину: длинные выходные — время повышенного риска.

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

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

Статья подготовлена по мотивам материала IEEE Security & Privacy, публикации Брайана Хэмэна и отчёта команды безопасности SPAN (NASA).

Чем больше данных в компании, тем критичнее становится понимание того, где именно они хранятся и как изменяются при обновлениях. В «Островке» мы пользуемся дата-каталогами, но в какой-то момент решили пойти чуть дальше: объединили DataHub с генеративным ИИ через Model Context Protocol, чтобы сделать работу с метаданными более интерактивной и быстрой.

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

Под катом делимся опытом внедрения связки DataHub + MCP, рассказываем об архитектуре решения и показываем реальные примеры, как ИИ становится практическим помощником в управлении метаданными.

Если вы когда-либо строили высоконагруженные системы поиска, то знаете, что в какой-то момент узким местом становится не код, а сама архитектура. Поиск доступных отелей — как раз тот случай: миллиарды «ночей», десятки тысяч RPS, постоянные обновления календарей, строгая консистентность и высокая цена любой ошибки. Старый стек на Python + Postgres + Redis долго тянул, но однажды стал «тормозить» настолько, что оптимизировать дальше было невозможно — SQL-запросы разрастались, реплики множились, latency прыгала до 60 секунд, а кэширование превращалось в источник инцидентов.

Так мы пришли к идее построить собственную in-memory базу данных на Go — заточенную под наш домен. Быструю, безопасную и синхронизированную с Postgres. 

Под катом — история того, как мы её спроектировали, какие архитектурные решения приняли, как победили холодный старт, справились с миллиардами значений. И почему в итоге смогли полностью отказаться от кэша доступности, переведя поиск в real‑time.

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

В итоге именно они — а не рациональность — нередко определяют поведение пользователя и влияют на ключевые метрики продукта: от конверсии и CTR до CSAT и удержания.

В этой статье мы рассмотрели travel-tech через призму поведенческой психологии и собрали распространённые когнитивные эффекты, которые встречаются на пути пользователя — от поиска направления до посадки в самолёт. Рассказали:

• как эти эффекты проявляются в реальных сценариях; 

• как их диагностировать с помощью данных и исследований; 

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

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

В Островке мы строим экосистему вокруг данных — от хранилищ и пайплайнов до систем мониторинга и каталогов. Но когда всё только начиналось, под часть наших процессов просто не существовало готовых решений. Так появился наш собственный дата-каталог DataPortal — лёгкий, быстрый и идеально подходящий для небольшой компании.

Со временем всё изменилось: объём данных вырос в десятки раз, появились новые команды, и вместе с этим начали звучать вопросы вроде «где лежат данные для этого дашборда?», «кому писать, если он упал?» и «можно ли этим данным доверять?». Так мы поняли, что пора взрослеть — и искать инструмент, который поможет масштабировать не только инфраструктуру, но и дата-культуру.

Мы выбрали DataHub — open-source каталог, обещавший прозрачность, автоматизацию и гибкость. Развернули, подключили источники, построили lineage, и даже порадовались, что всё заработало с первого раза. А потом стало ясно: DataHub не заменил наш DataPortal. Более того, оба инструмента отлично дополнили друг друга — инженерное ядро и удобное окно в данные для бизнеса.

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

Команда UX-исследователей Островка делится опытом работы с эмоциями и подробным чек-листом проведения и восстановления после интервью 

Привет! Меня зовут Артём Блохин, я Go-разработчик в команде интеграций Островка. Сегодня поговорим о линтинге кода.

Если бы «Сумерки» были про код, Эдвард — был линтером, а Белла — легаси-кодом, их диалог звучал бы так:

Всем привет!

На связи Денис Божок, руководитель домена технологий в Островке. В этой статье разберёмся, что на практике нужно современному DevOps-специалисту. Рассказывать буду в первую очередь на примере тех задач, которые мы решаем в Островке каждый день. Статья эта подойдёт как для тех, кто уже разбирается в данной этой области и хочет развиваться дальше, так и для новичков, желающих понять, с чего же начать свой путь.

Стоит учитывать, что под DevOps в каждой компании понимают своё, поэтому наш опыт может кардинально отличаться от вашего.

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

Итак, сегодня будем разбираться в паделе вместе с тройкой его преданных фанатов (по секрету, их у нас гораздо больше). 

Может показаться, что падел — новинка в мире спорта, но на самом деле зародился он уже больше полувека назад, в 1969 году. Говорят, один миллионер, по имени Энрике Коркер купил особняк в Акапулько и собирался возвести там теннисный корт, так как его жена обожала играть. Однако оказалось, что полноразмерный корт никак не вписывался в местный ландшафт, построить его было попросту невозможно, поэтому Коркер решил уменьшить оригинал в три раза — так, по легенде, и появилась площадка для падела, 20 на 10 метров. Затем вокруг построили четырёхметровые стены из прочного стекла, чтобы растения и деревья не мешали играющим. Теннисные ракетки Коркер заменил на пляжные, а мяч оставил. К слову, названием получившаяся игра обязана именно ракетке, так как падел (от англ. paddle) — переводится как весло. 

Вскоре к Коркеру в гости заглянул друг — испанский предприниматель Альфонсо де Гогенлоэ. Он, конечно, сыграл в падел — и так проникся этим спортом, что по возвращении в Испанию построил аж два корта. Что было потом, вы уже догадываетесь: популярность падела стала набирать обороты, играть начали даже именитые спортсмены, среди которых Марат Сафин, Златан Ибрагимович, Жерар Пике (да, и футболисты оценили!), а в 2023 году он даже вошел в программу III Европейских игр.

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

Привет, Хабр! Меня зовут Иван Чернов. Я 12 лет в IT, 6 из них работаю в «Островок!». В этой статье расскажу, как справиться с нагрузкой и поддерживать бесперебойную работу системы. Рассмотрим масштабирование Redis, использование Aerospike, фильтр Блума и решим задачку со звёздочкой. Поговорим о маленьком кусочке схемы, который непосредственно работает с поставщиками в поиске. Это самая нагруженная часть, где возникают наибольшие проблемы с highload. Но именно она нужна, чтобы пользователи получили лучшие цены.

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

Всем привет! Меня зовут Артём Блохин, я Golang-разработчик в команде интеграций Островка.

Если бы «Рождественская история» Чарльза Диккенса была про стиль кода, то получилось бы как-то так:

«Начнём сначала: код‑стайл умер. Сомневаться в этом не приходилось. Свидетельство о его погребении было подписано девопсом, архитектором и тимлидом. Оно было подписано разработчиком Островка.»

Привет! Меня зовут Иван Елфимов, я Developer Advocate в Островке. В прошлом месяце мы опубликовали пост о том, чем занимаются ML-инженеры в Островке. В этот раз рассказываем про Machine Learning (ML) и Data Science (DS) с точки зрения продукта.

Команда Data Science появилась в Островке в 2014 году, задолго до расцвета больших языковых моделей. За это время она успела сделать десятки проектов с computer vision, NLP и сложными классическими моделями.

Ажиотаж вокруг языковых моделей заставил многих из нас забыть, что Data Science — это не только трансформеры (General Pretrained Transformers, GPT). Мы используем картинки, текстовые и табличные данные для построения моделей, которые работают в реальном времени или обрабатывают статистические данные. Они помогают нам подбирать лучшие отели для вашего следующего путешествия.

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

Всем привет, меня зовут Иван Елфимов, я Developer Advocate в Островке. До DevRel-ства я 5 лет руководил командой разработки партнёрских интеграций. 

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

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

Аригато в хату! Меня зовут Денис Божок, я руководитель департамента платформенной разработки в Островке, но сегодня, внезапно, я здесь не как технарь, а как фридайвер. Так что все, кто давно задавался вопросом, чем занимаются айтишники в свободное время, в чём разница между погружениями с баллоном и без; безопасно ли нырять на глубину только с маской; какой мировой рекорд по задержке дыхания; как прокачаться, если хочешь профессионально плавать с маской; что нужно купить и как получить благословение Посейдона, то сегодня про всё это и расскажу. 

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

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

Если вы не первый год в аналитике, то знаете, каково это — прокладывать дорогу сквозь неопределённость. Рассматривать гипотезы и принимать ту, по которой работать, — это как выбирать дорогу, по которой идти всей команде. Волнительно и непросто отправляться на неосвоенные земли.

Вот вы — хороший штурман? Готовы встретиться с вызовами? Перетряхнём же рюкзак, посмотрим, чем он набит, и есть ли там самое важное, без чего не выжить в пути.

Всем привет!

У нас уже есть одна статья про развитие типизации в Ostrovok.ru. В ней объясняется, зачем мы переходим с pyContracts на typeguard, почему переходим именно на typeguard и что в итоге получаем. А сегодня я расскажу подробнее о том, каким образом происходит этот переход.