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

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

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

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

Привет, Хабр! Меня зовут Тимофей, я 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-билде и отсутствие времени даже на размышления. Потом рефакторили, а теперь стараемся не допустить повторения проблем. 

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

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

Меня зовут Юра, я Delivery Manager в Сравни. Сегодня расскажу вам, как мы делали конструктор для запуска и управления тематическими разделами на нашем маркетплейсе.

Всем привет! Меня зовут Николай Полушкин, я продуктовый аналитик в финансовом маркетплейсе Сравни. Недавно мы проводили тест-драйв новой системы A/B/n-тестирования, которую планируем внедрить в нашей компании. Хочу поделиться результатами с читателями Хабра, предупредить о подводных камнях и дать рекомендации тем, кто тоже планирует использовать многовариантное тестирование (MVT).

Привет, я Даша, занимаюсь iOS‑разработкой в Сравни. Мы в мобильной команде пользуемся SnapKit — помогает нам ревьюить изменения в общих компонентах быстрее и проще. Инструмент прекрасный, но я заметила тенденцию: стоит в работе появиться сложным вариантам вёрстки, как сразу в разы растёт вероятность, что UI может выглядеть ок, а в консоли будет отображаться множество ошибок LayoutConstraints, логи засоряются, найти действительно полезную информацию становится сложнее.

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

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

Привет, Хабр. Меня зовут Денис Былинин, я архитектор в компании Сравни. 

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

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

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

Про ИПР (индивидуальный план развития) можно найти немало материалов в интернете. Зачастую там представлены довольно общие формулировки, либо труднореализуемые предложения. Поэтому сегодня я хотел бы рассказать, каким может быть ИПР на примере того, как у нас в компании устроен процесс развития сотрудников. Простые, «приземленные» советы. 

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

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

Привет, Хабр! Мы Сабина Бадирханова и Светлана Юдина из UX-лаборатории Сравни и сегодня хотим поделиться нашим опытом создания и развития направления UX-исследований в компании. Мы расскажем, с чего всё начиналось, к каким результатам удалось прийти и как получилось встроить исследования в общий дизайн-процесс, не вызвав активного сопротивления коллег.

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