Меня зовут Сигида Алексей, я старший архитектор по развитию технологий CVM (Customer Value Management) в компании Мегафон. Много лет решения о том, что показать клиенту, у нас принимал Teradata RTIM (Real-Time Interaction Manager) - движок real-time маркетинга. Если вы когда-нибудь получали смс-сообщение от Мегафона или заходили в личный кабинет в 99% случаев сообщение для вас было подобрано этой системой. Вы заходите на сайт или в приложение, и за миллисекунды решается, какое предложение показать. Логика выбора описывается деревьями принятия решений: запрос проходит по веткам дерева, а условия переходов в узлах - критерии - определяют, к какому сегменту отнести клиента и какое предложение ему подобрать.

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

Это не разбор, не рекомендация, а скорее ценный опыт фронтовой команды с полей российского IT. Все что описано ниже — общий результат нашей работы.

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

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

Разработка имеет такую очередь: архитектурно наш UI Kit лежит в закрытом artifactory npm пакетом. Также есть шаблон со всеми необходимыми зависимостями и UI Kit«ом. Когда приходит время нового проекта, делается fork заготовки. Это дает быстрый старт.»

Начинаем

Давайте посмотрим, как бы начиналась разработка приложения. Возьмем для примера компонент Select. Не будем писать сами, возьмем Antd Select и через обертку emotion стилизуем его под корпоративные стили.

Структура получится такая:

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

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

UDP или TCP? 3 потока или 10? BBR или CUBIC?

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

В любой промышленной системе обработки данных есть пласт регулярной работы, которую нужно просто запускать раз в день или раз в час и не думать о ней: ночные ETL-загрузки, пересчёт витрин, выгрузки в смежные системы, всякая техническая обвязка вроде чистки служебных таблиц. Всё это должно где-то стартовать по расписанию, уметь учитывать зависимости между потоками и принимать во внимание тот факт, что задачи у нас разнородные. Ниже — рассказ про то, как устроен наш планировщик на Oracle Data Integrator и PL/SQL: из чего он собран, как задачи попадают в очередь, как они распределяются по серверам, и как мы закрываем сценарий с зависаниями.

Многие из нас любят NoSQL. И MongoDB среди них является одним из топ-любимчиков. Очень часто мы выбираем нашу «Монгу» за гибкость и скорость. И это вполне логично, ведь MongoDB почти никогда не подводит... сразу. Неприхотливая, шустрая, удобная - она ведет себя как идеальный помощник: не требует лишнего, принимает любые данные, не задаёт неудобных вопросов про схему и с готовностью отвечает на каждый запрос за считанные миллисекунды.

Но потом ты начинаешь подозревать что-то неладное. И, что самое главное, происходит это не сразу, а постепенно. Сначала один запрос начинает задерживаться немного дольше обычного, потом еще один. Там, где раньше было 10-20 миллисекунд, становится 100. Ты замечаешь, что графики ведут себя странно. И начинаешь искать причину: грешишь то на версию софта, то на железо, то думаешь, что сама MongoDB какая-то не такая.

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

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

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

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

Обе библиотеки представляют из себя дополнительный слой, который отображается поверх любой карты, такой как Open Street Map (OSM), Google Maps, Яндекс.Карты и многие другие популярные платформы. По сути, библиотека предоставляет инструменты для визуализации, манипулирования и взаимодействия с картографическими данными непосредственно внутри вашего приложения, не ограничиваясь каким-либо одним провайдером карт.

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

Уважаемые читатели, меня зовут Ольга Чикова и я бизнес-аналитик компании «МегаФон». Долгие годы я работала в сфере закупок и проектов оптимизации стока, а в 2025 году перешла в аналитику, чтобы помогать другим представителям бизнеса лучше доносить свои требования до it команды. 

Самым большим проектом в 2025 году для меня стало внедрение системы маркировки «Честный знак». Я хотела бы поделиться своим опытом подготовки к вступлению в систему маркировки, рассказать, каких ошибок можно избежать, на что сделать упор в подготовке и как не потратить зря время и деньги.

Кратко о том, что необходимо знать при знакомстве с «Честным знаком»:

Обязательная система маркировки «Честный знак» запущена в России в 2018 году. В октябре 2025 года система маркировки действовала уже в 33 товарных категориях, и еще 13 сейчас являются пилотными. Кто в РФ решает, какую категорию товаров включать в систему «Честный знак»? Решение принимает Правительство РФ по представлению Минпромторга. Это длительный процесс, который состоит из нескольких этапов: сначала проходит эксперимент, после его завершения выпускается постановление правительства, затем наступает этап обязательной маркировки для всех участников рынка.  

Товарные категории разделены по направлениям: шины и покрышки, лекарства, товары легкой промышленности и т.д. У каждой товарной категории свои правила, где-то они совпадают, а где-то различаются, причем достаточно сильно. Если ваш товар относится к экспериментальной группе, то настоятельно рекомендуем вам вступить в эксперимент как участник (как вступить в эксперимент описано на сайте «Честный знак»). Во-первых, вы будете в курсе всех изменений, во-вторых, вы сможете задавать вопросы по товарной категории не только по электронной почте, но и онлайн на общих встречах с организаторами.

В статье рассказывается, как команда интегрировала Qlik с OpenMetadata, создав собственный коннектор вместо использования коробочного решения. Авторы объясняют, почему стандартный подход не обеспечивал нужного lineage и привязки к глоссарию, и как они решили проблему с помощью парсера скриптов Qlik, поддержки include-файлов и доменной модели Business Views. В результате удалось связать дашборды с источниками данных и бизнес-терминами, сократив время поиска отчётов с 2 часов до 2 минут и обеспечив покрытие lineage более чем для 85% приложений. Статья будет полезна тем, кто сталкивается с управлением метаданными в крупных BI-инфраструктурах.

Здравствуйте! Я Дина Лакеева, в разработке я с 2012 года. Сейчас я являюсь лидером системного анализа продуктового стрима в команде разработки личного кабинета МегаФона.  Практически на всех своих проектах я сталкивалась с проектированием интеграций, то есть со взаимодействием различных систем или их частей. И именно эта часть проекта меня больше всего увлекала. Интеграции – это то, в чем мне всегда хотелось развиваться, и я вижу в этом большой интерес и по сей день.

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

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

Так вот, представим, что наша система – это корабль... О чем же стоит подумать на берегу?

Наша команда работает над системой геовизуализации, позволяющей отображать статистику на интерактивной карте. Одной из задач была отрисовка полигонов (в нашем случае — прямоугольников, рис.1) по центральной точке из массива данных, предоставленного заказчиком. Достаточно быстро мы столкнулись с ситуацией искажения размеров этих полигонов в зависимости от широты: чем ближе к северу находилась точка, тем меньше становились полигоны, а на юге они и вовсе начали перекрываться друг другом. Для тех, кто спешит, сразу перейду к объяснению решения задачи. Для остальных, кто настроен на более неспешное чтение, во второй части статьи приведена справочная информация о проекции Меркатора и её особенностях.

Как мы сделали лёгкий игровой тест по мотивам соционики. Задача — дать короткую, но содержательную обратную связь о вероятной командной роли (мыслитель, душа компании, хранитель или лидер) и предложить, как применить свои сильные стороны в работе и учёбе. Это не «ярлык», а удобный язык для разговора о взаимодействии: разнообразие ролей помогает точнее проверять гипотезы и принимать более устойчивые решения.

Эту статью хотел бы посвятить некоторым технологиям распределения/балансировки трафика по разрозненным радиолинкам в пределах одной РРЛ.

В предыдущей статье  «РРЛ для самых маленьких» https://habr.com/ru/companies/megafon/articles/925514/ я рассказывал о некоторых технологиях и решениях, позволяющих увеличить пропускную способность РРЛ (радиорелейных линий):

-          XPIC (Cross-Polarization Interference Cancellation)

-          CA (Carrier Aggregation)

-          SDB (Super Dual Band)

-          или строительство параллельных линков на разных частотах

  Использование этих решений позволяет получить РРЛ в конфигурации N+0 (2+0, 4+0, 8+0 или 16+0), где N – это количество независимых радиолинков. Почему независимых? А потому, что эти технологии не занимаются распределением трафика между линками, у них другая задача – организация дополнительных радиолиний ("стволов").

Привет, Хабр!

В этой статье хочу поделиться нашим опытом интеграции с Kafka.

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

В какой-то момент в нашем КХД также появилась необходимость интеграции с Kafka.

При разработке первой интеграции мы пошли традиционным путем и использовали Kafka Connect для Confluent 6.0.1. Сообщения, читаемые коннектором, перекладывались в Hadoop. Далее в PySpark выполнялся парсинг нужных данных, и полученные пачки выгружались в Oracle Exadata.

Но на этапе опытно-промышленной эксплуатации у нас возникли проблемы с производительностью из-за большого объема читаемых данных: ~100-110 млн сообщений в час (поток со звонками абонентов). Также было требование от бизнеса - данные в конечной витрине должны появляться с задержкой не более часа. Оптимизация интеграции затянулась еще на пару месяцев.

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

Тем временем, перед нами встала задача разработки еще нескольких интеграций с Kafka.

Было очевидно, что требуется какое-то решение, которое не только ускоряло бы внедрение, исключая рутинную разработку, но и позволяло реализовать стандартную для таких интеграций батчевую выгрузку считанных сообщений в разные БД (Oracle/Hive/ClickHouse и в перспективе в Greenplum). И кроме того, умело выполнять предварительную обработку данных на лету (парсинг и трансформацию значений заданных атрибутов).

Всем привет!

Всем, кто когда‑либо реализовывал ИТ‑проекты, наверняка знаком термин HLD (High Level Design) и тот факт, что без него достаточно сложно спланировать любой комплексный проект. Более того, в проектах всегда очень хочется пропустить кажущуюся ненужной трату времени на сбор и описание требований и сразу приступить к обсуждению решения, тем более, когда оно кажется очевидным.

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

Итак, нужна архитектура решения (HLD) или она уже есть и надо убедиться в ее правильности.

Для кого эта статья

Эта статья будет полезна разработчикам, которые только начинают писать WPF. Здесь будет рассмотрена механика динамических ресурсов - опытные WPF-разработчики вряд ли найдут что-то полезное для себя.

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

Работая с Oracle Data Integrator (ODI), мы ценим его графический интерфейс за автоматизацию рутины и удобство разработки. Однако, когда проект масштабируется до десятков пакетов и сотен сущностей, GUI перестает быть оптимальным инструментом для отслеживания потоков данных, глубокого анализа и аудита зависимостей.

В таких случаях ключом к эффективности становится прямое взаимодействие с метаданными ODI через SQL‑запросы к его репозиториям. Эта статья посвящена именно этому — практической работе со структурой репозиториев ODI и детальному разбору SQL‑запроса для построения потоков данных.

Почему стоит использовать Tagged Unions при разработке на TypeScript

👋 Привет! Меня зовут Александр, я работаю фронтенд-разработчиком в компании «МегаФон». Сегодня я хочу поговорить на тему Tagged Unions (размеченных объединений) и объяснить, почему они ваш секретный инструмент для написания надежного TypeScript-кода.

Привет, Хабр!

Начну с того, что немного уточню, о каких именно устройствах пойдёт речь. Ни для кого не секрет, что для организации мобильной связи используются базовые станции, на которых стоит много разного электрооборудования. А значит, за энергопотреблением надо следить, отчитываться и оплачивать его. Естественно, всё это логично делать удалённо, для чего на базовых станциях установлены специальные устройства сбора и передачи данных (далее УСПД).

Основная задача УСПД — это опрос подключённого к нему оборудования (электросчётчиков, резервных генераторов и других устройств, необходимых для работы базовых станций) с последующей передачей собранных данных на серверы МегаФона, где в дальнейшем они используются для формирования отчётности, анализа и управления работой базовых станций. По сути, это классическая IoT-система.

Речь пойдёт как раз о перенастройке УСПД.

Современные РРС – это уже не просто альтернатива ВОЛС, это уже полноценная, хорошо масштабируемая транспортная сеть.

Всё о современных радиорелейных системах для самых маленьких.

Привет! Меня зовут Геннадий Хараев, я Service Delivery Manager в интернет‑магазине МегаФона. Ниже мой откровенный рассказ о том, как за последний год мы полностью перезагрузили процессы, команды и технологическую платформу. Я сознательно избегаю точныхцифр — важнее настроение, идеи и принципы, которые стоят за нашими изменениями.

Почему мы вообще взялись за трансформацию

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

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

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

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

Наконец, наш технологический стек тормозил развитие. Монолитная архитектура и отсутствие автоматизированного тестирования усложняли процесс масштабирования и устранения ошибок.

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

По итогу, компания инвестировала в развитие интернет-магазина МегаФона и сделала его одним из приоритетных проектов на ближайшие несколько лет.