Как не потеряться в данных для аналитики? 

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

Но что, если данных в компании много, они отличаются сложной структурой и поступают из разных источников? Едут и из MongoDB, и из PostgresSQL, и из MS SQL; при этом постоянно появляются новые продукты и направления, данных становится ещё больше. Документация по ним устаревает примерно в тот момент, когда заканчиваешь её писать.

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

Упростить жизнь в такой ситуации призван Data Catalog, и в Сравни мы выбрали популярный вариант — DataHub. Под катом рассказываем, как меняется работа с данными для аналитики, когда в твоей жизни появляется визуализация потоков данных.

«Что там с базами, не пора ли добавлять ресурсов?» — казалось бы, звучит как дежурная реплика менеджера, и классический ответ на неё: «всё ок, до конца недели должно хватить!». 

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

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

О том, что из этого вышло, читайте под катом.

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

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

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

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

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

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

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

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

Представьте ситуацию. Приходит Product Owner и говорит: «Давайте сделаем новый дизайн страницы сайта». Аналитик берётся за задачу — проводит A/B-тест. Такая же задача случается в соседней команде, в сопоставимом по сложности продукте, — но если в первом случае тест занимал пару часов, то во втором ждать приходится несколько дней. Чем больше команд и аналитиков, тем выше риск разрозненности. 

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

Под катом пошагово описываем, как мы унифицировали процессы в нашем A/B-тестировании, и что получили на выходе.

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

Под катом автор блога Considerations on Codecrafting рассматривает ошибки, связанные с наложением ссылок, предлагает методы их предотвращения и призывает внедрить эти методы на уровне проектирования новых языков.

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

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

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

Хорошие новости: можно по‑другому. Повысить вовлеченность команды в ретроспективу, помочь увидеть конкретный результат своих усилий по улучшению работы. Уйти от вопросов «Что будем обсуждать на ретро?» и «У нас все хорошо?» к прозрачной картине того, что происходит с командой, чего удалось достичь и куда двигаться дальше. Помогут нам в этом процессные метрики.

Или станешь менеджером, или накопишь много денег и тогда сможешь дауншифтнуться, кататься на серфе у берегов Австралии, выращивать помидоры в деревне. 

В поисках ответов на вопрос “А куда дальше развиваться в профессии?” всё ещё много стереотипов и движения по инерции, но кажется, становится получше. Инженеры всё чаще имеют возможность двигаться не обязательно в сторону превращения в лида или руководителя, но быть высоко квалифицированными individual contributors. В грейдах появляется больше вариативности.

Интересная сторона вопроса – кейсы про горизонтальное развитие, когда люди меняют одну ИТ-роль на другую. Обязательно ли это должно происходить при достижении уровня senior в ранее выбранной роли? Возможно ли в рамках одной компании или чаще связано со сменой работодателя? 

Расспросили об их опыте смены роли коллег из ИТ-команды Сравни:

* Таня – прошла путь от специалиста первой линии поддержки до Delivery-менеджера в DevOps-команде; 

* Максим – прошёл путь от QA-инженера к Delivery-менеджеру и затем к Product Owner; 

* Света – из QA-инженера стала Frontend-разработчиком. 

Вот, что они рассказали. 

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

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

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

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

Привет, Хабр! Меня зовут Тимофей, я Android-разработчик в Сравни. Давайте поговорим о кросс-обновлении Android-приложений без привязки к конкретному стору – так, чтобы пользователи могли устанавливать из одного источника, а обновлять – из другого, без необходимости удалять и ставить заново.

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

Но первые реальные практические шаги в этом направлении мы сделали в формате
“А что, так можно было?”: пошли выкладывать приложение в RuStore и попутно обнаружили возможности использовать аналогичные механизмы для настройки кросс-обновления.

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

Звучит отлично – в теории.

На практике из собравшихся, условно, 30 человек в обсуждении участвуют 5, остальные отмалчиваются и ждут, когда это скорее закончится и можно будет заняться нормальными делами.

Когда-то так было и у нас. Сейчас – все 30 участников высказываются по очереди, формируют рабочие группы по внедрению улучшений, разносят итоги встреч по своим командам.

За 2.5 года мы прошли путь от “лиды молча послушали рассказ о том, как космические корабли бороздят просторы большой стратегии” до “ребята сами придумали и реализовали точки роста, которые помогли компании сэкономить миллионы рублей”. 

Как развивался формат общих встреч лидов в Сравни – читайте в этой статье. 

Привет, Хабр! Меня зовут Ахмед, я Deputy CTO в Сравни. 

Сегодня расскажу вам об опыте управления дежурствами в ИТ-команде.

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

Привет, Хабр. На связи Денис Былинин, системный архитектор из финансового маркетплейса Сравни. Сегодня хочу поделиться подробностями запуска курса по практической разработке для студентов мехмата Новосибирского Государственного Университета, где я выступал в роли составителя программы и основного лектора. 

Курс охватывает широкий спектр тем от продуктового мышления и софт-скиллов до сравнения типов архитектур и DevOps-инструментария и призван познакомить студентов с принципами разработки на реальных (или приближенных к реальности) кейсах. Записи лекций лежат здесь в открытом доступе. 

Привет, Хабр! Меня зовут Анджей, я QA-лид в Сравни. В этой статье давайте попробуем если не победить, то хотя бы побороться вот с какой ситуацией: вроде всё сделали хорошо и проверяли, а сайт всё равно пролежал на выходных с 500-ми ошибками. Помогать с тестированием нам будет Kubernetes-инструментарий в общем (Helm) и механизм хуков в частности. 

Привет! Меня зовут Ваня, последние несколько лет я занимаюсь backend-разработкой в Сравни. Моя команда разрабатывает интеграции с сервисами наших партнёров, код пишем на PHP и Symfony Framework.

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

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

Привет, Хабр! На связи Дмитрий Парфёнов (СТО) и Антон Смирнов (дизайн-директор). Сегодня хотим поделиться нашим опытом создания и внедрения дизайн-системы для ускорения разработки сайта и мобильного приложения Сравни. Сразу скажем, что процесс это был непростой, не обошлось без всевозможных затыков — о них тоже пойдет речь. 

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

Привет, Хабр! Меня зовут Оксана, я системный аналитик в Сравни. Сегодня хочу рассказать о том, как мы разбирались с ошибками в интеграциях по API с нашими партнерами, какие инструменты для анализа ошибок нам тут помогали. Надеюсь, статья будет полезна для системных аналитиков и всех, кто работает с внешними API, особенно если интеграций много.

Привет, меня зовут Валентин, я NodeJS-разработчик в Сравни. Моя команда делает Profile Service — внутренний продукт, который отвечает за быстрое получение и запись личных данных пользователей для экосистемы Сравни. Мы взаимодействуем с 20+ продуктовыми командами, которые дают нагрузку на сервис порядка 200-300 RPS; порядок обрабатываемых записей в БД – десятки миллионов.

В какой-то момент мы решили внедрить Kafka – де-факто стандарт транспорта, работающий в миллионах проектов. Что может пойти не так? Оказалось – вообще всё что угодно. 

В этой статье я расскажу, с какими неочевидными проблемами мы столкнулись при переходе на Kafka у нас в продукте, как мы чинили баги в NestJS Microservices и какие выводы сделали (спойлер: Kafka – не всегда хорошее решение). 

Приступим!

У нас в ИТ-команде Сравни есть принцип: в любой непонятной ситуации вместо того, чтобы раз за разом решать похожие проблемы, лучше сделать инструмент, который поможет системно решать целый класс таких задач. Шаблонизация, автоматизация занимают важное место у нас в бэклогах. Поэтому эксперименты с Copilot от GitHub и OpenAI, наверное, были для нас неизбежны.

В этой статье хотим поделиться обратной связью от коллег с их впечатлениями от Copilot – сравнить с вашим опытом и, возможно, добавить аргументов, чтобы попробовать этот инструмент (или окончательно убедиться, что делать этого не нужно — тут уж каждый решает сам).

Привет, Хабр! Меня зовут Миша и я фронтенд-разработчик в Сравни. Сегодня расскажу историю об одном рефакторинге. Как мы сначала копили джентльменский набор: лишние запросы и библиотеки, спагетти из кода и обещаний, пелена гигабайт в Docker-билде и отсутствие времени даже на размышления. Потом рефакторили, а теперь стараемся не допустить повторения проблем. 

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