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

Для кандидата это один этап. Для компании — процесс, который может меняться от встречи к встрече.

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

Мы решили собрать этот фольклор в систему и запустили внутреннюю школу технических интервьюеров. Цель — сделать подготовку собеседующих более предсказуемой по срокам и снизить зависимость интервью от личного стиля конкретного человека.

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

Знакомая ситуация: вашей команде нужна фича в чужом сервисе, вы ставите задачу — и ждёте. Неделю, месяц, квартал. Потому что у того сервиса свои приоритеты и свой ограниченный ресурс. А ваш продукт стоит.

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

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

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

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

Такие ситуации обычно показывают не частную ошибку, а устройство процесса в целом. Когда важные условия нигде не закреплены, команда расплачивается за это уточнениями, возвратами и лишней синхронизацией. И напротив — если критерии перехода определены заранее, работать проще. Поэтому Quality Gates для нас в Островке — не только способ ничего не упустить, но и понятный маркер того, насколько процесс разработки вообще выстроен и управляем. 

Форма у таких гейтов может быть разной: автоматическая проверка, правило в workflow или простой критерий готовности. Важно не как выглядит гейт, а какую точку неопределённости он закрывает.

Под катом — практический разбор того, что вообще можно считать Quality Gate, где такие механизмы реально работают и как подбирать их под задачи команды.

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

В Островке из этой задачи в итоге вырос отдельный сервис: он собирает события о релизах, связывает их с изменениями в GitLab, сопоставляет с инцидентами и отдаёт данные в Grafana. На MVP мы покрыли 90% проектов. После того как команды начали регулярно разбирать метрики и автоматизировать узкие места, критичных сбоев стало заметно меньше: в зависимости от месяца снижение доходило до 80% год к году.

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

В Островке мы используем ИИ в разных задачах — от автоматизации внутренних процессов до продуктовых сценариев — и периодически рассказываем об этом на Хабре. Например, как строим вспомогательные системы на базе LLM и RAG или применяем ML в продукте.

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

Ниже мы перевели и адаптировали материал Алекса Эверлёфа — инженера, который систематизировал подходы к проектированию ИИ-систем за последние несколько лет.

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

Цель материала — помочь опытным инженерам, архитекторам и техническим руководителям разобраться в ИИ-инженерии и показать, что значительная часть привычных нам инженерных практик продолжает работать и здесь.

Примечание. Часть текста была подготовлена с помощью Gemini 3 Pro, но финальную версию автор полностью вычитал, проверил и отредактировал, чтобы она точно отражала его опыт и выводы.

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

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

В Островке (тысячи сотрудников, распределённые команды, несколько продуктовых направлений и операционная работа 24/7) мы столкнулись с этой проблемой в полном объёме. Каталог процессов начал формироваться, но быстро стало ясно: сам по себе он не создаёт ценности. Читать схемы BPMN готовы немногие, а поддерживать актуальность описаний вручную — дорого и нестабильно.

Так мы встали на путь превращения каталога процессов из статичного документа в сервис. Поверх него был построен чат-бот на базе LLM и RAG с low-code автоматизацией, который стал точкой входа в процессную архитектуру: отвечает на вопросы, инициирует обновления, обучает сотрудников и принимает заявки на оптимизацию.

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

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

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

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

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

Если вы когда-нибудь писали фронтенд на TypeScript и получали в проде Cannot read property 'x' of undefined, — добро пожаловать в клуб!

TypeScript спасает нас от сотен ошибок… но только пока код не запущен. Как только он скомпилировался, типы исчезают, и в рантайме вы снова остаетесь один на один с невалидными данными.

И вот тут начинается: меняется API, формы шлют что угодно, аналитика ломает отчёты, а тесты молчат.

В Островке мы попробовали библиотеку Valibot — легковесный runtime-валидатор, который умеет проверять данные на границах контекстов и при этом остаётся дружелюбным к TypeScript.

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

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

Но в конце 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-продукт — это не только нейронные сети, но и классические модели, а также различные эвристики. Надеюсь, результаты вас удивят!