Наш фронтенд начинался как простой SPA на React, собранный с помощью Vite — типичный монолит с несколькими страницами. Со временем проект оброс новыми функциями и интеграциями и начал становиться всё сложнее в поддержке.

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

После изучения разных вариантов мы остановились на подходе микрофронтендов. Хотелось разграничить зоны ответственности между командами и ускорить разработку, не теряя гибкости. В качестве сборщика решили остаться на Vite — он быстро развивался, предлагал отличную DX и поддержку модульной федерации через плагин. Кроме того, важно было сохранить единый репозиторий, чтобы упростить CI/CD и управление зависимостями.

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

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

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

Постоянное развитие сервисов для пользователей и конкуренция среди операторов предъявляет всё более высокие требования по скорости пакетной передачи данных и задержкам. Задача оптимизатора — максимально раскрыть потенциал имеющихся ресурсов и эффективно их использовать. 

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

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

Привет, Хабр! Меня зовут Александр Маркачев и я — Data Engineer команды Голосовой Антифрод в билайн. Расскажу, как борьба с мошенниками может обернуться личным вызовом.

Все техники сопровождаются объяснениями, примерами и рекомендациями для самостоятельного повторения.

В статье — о том, как мы решили отказаться от PropTypes в пользу TypeScript для автоматического извлечения типов пропсов React-компонентов. 

Наши разработчики давно просили эту возможность, справедливо возмущаясь: «Зачем описывать типы дважды — в TypeScript и PropTypes?». Тем более, что аналогичный механизм уже работал в Storybook.

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

В середине 2000 я купил Psion 3c для коллекции. Лет через 10 увидел, что его комплектный диск называется SSD — Solid State Disk. На волне тестирования NVME возникла идея, а не протестировать ли скорость SSD-1993? И спустя 20 лет после покупки на этой машинке была написана первая программка.

Разработчики часто сталкиваются с задачами, в которых одна функция должна работать с разными типами данных и количеством аргументов. Чтобы каждый раз не создавать множество функций с разными именами, существует перегрузка (overload). Она позволяет использовать одно имя операции для обработки различных комбинаций входных данных. Благодаря перегрузке одна функция может адаптироваться под различные сценарии и делать код лаконичным и понятным. 

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

Так повелось, что по итогам своих опытов с различными технологиями подключения дискового пространства писал сюда небольшие заметки:

Настройка NVME over TCP — для тех, кому надо подключить больше 1 диска единственной конфигурации из всех примеров в Сети.

Попытка разогнать сеть для БД со 100 до 200Гб/c или «failure is always an option».

Настройка iScsi в L3-сети для эффективной утилизации возможностей канала и СХД.

Поскольку появился новый свежий опыт по настройке и тестированию подключения еще одним способом, и все уже собрано для внутренней wiki-статьи, решил продолжить традицию.

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

В статье подробно расскажем о функциях и внутреннем устройстве TN Map: разберем сценарии использования продукта и его отличительные особенности.

Пользовательский ввод

Результат генерации QR-кода

У билайна есть разношерстный парк Unix-серверов: это AIX, Solaris, где-то есть даже HPUX на итаниуме. Они достаточно надежны, но так как они начали эксплуатироваться давно, вероятность их выхода из строя по мере расходования запаса надежности увеличивается. Часто на таких серверах работают критичные программные продукты, а данные с них хранятся на системах хранения данных (СХД), которые тоже не молодеют. 

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

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

Эта статья была написана для конкурса Технотекст-7 «Тот момент, когда происходит изменение». Тема адаптации UI к меняющимся деталям была выбрана, так как связана с темой конкурса.

Современная UI-разработка живет быстрыми темпами. Мы постоянно создаем и меняем код, чтобы соответствовать новым трендам, но часто это делается «на коленке» и без долгосрочного видения. В итоге уже через пару месяцев все, что казалось суперсовременным, превращается в легаси из-за смены моды фреймворков и других деталей реализации.

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

Привет! Как и обещала в первой части — теперь про ребалансировки и не только.

Выделяют безотлагательную и совместную ребалансировки. 

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

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

Всем привет! Сегодня расскажу про Confluent Kafka. Ее любят, ненавидят, но мало кто остается равнодушным.

О себе

Меня зовут Алена, я ведущий разработчик, занимаюсь развитием референсной архитектуры в компании билайн. К основным областям профессиональных интересов можно отнести проблемы распределенных систем, event sourcing и DDD.

В двух словах о Kafka

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

Привет, меня зовут Иван, и я зануда.

Сразу скажу, что в моем понимании зануда в тестировании — не тот человек, который всех достал и которого все хотят удушить, а тот, который умеет показать людям, что нужно делать хорошо и не делать плохо, и добиться от них этого. Я считаю, что QA должно расшифровываться как Quality Assistant. Это даже не про Assurance, когда вы обеспечиваете качество, это именно про то, что вы как тестировщик и участник команды помогаете на каждом этапе от требований до выкатки в прод и работы с сопровождением и вашими коллегами добиться того, чтобы каждый этап проходил все лучше и лучше.

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

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

Наша команда Unix — распределённая: коллеги работают из Санкт Петербурга, Воронежа, Москвы, Ярославля, Нижнего Новгорода, Архангельска, Ижевска и Владивостока. Чтобы коммуникация была комфортной, система организации онлайн-конференций должна хорошо и быстро работать на звонках 1:1 и командных встречах разного размера.

Рабочие места у команды организованы на mac/linux/windows/vdi-windows/vdi-linux. Выбирали отечественное решение для онлайн-встреч из нескольких вариантов — некоторые из них до сих пор используются в разных командах и находятся на стадии испытаний. Нам достался Контур Толк, или ktalk.

Если после стресс-испытаний для NVME дисков или сети принято делиться опытом, почему бы мне не рассказать про использование программного продукта? В статье будет пользовательский опыт команды Unix и немного внутренней кухни про предотвращение и устранение сбоев.

Первая часть — здесь.

Data lineage

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

Нам важен разрез, когда клиентами или целевыми заказчиками данных являются ML-модели. 

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

Для начала немного о себе. Я более десяти лет в разработке и анализе данных, имею научный бэкграунд, принимал участие в различных проектах от построения высоконагруженных сервисов с использованием моделей машинного обучения и глубоких нейронных сетей до построения корпоративных хранилищ данных и ETL-процессов. В настоящий момент работают в билайн, в дирекции билайн бизнес (Big Data&AI). 

Департамент DS состоит из двадцати специалистов. Билайн сегодня в первую очередь — технологичная компания, мы любим говорить, что мы технологичны снаружи и технологичны внутри. У нас трудится более 3500 IT-специалистов, более 200 продуктовых команд, которые разбиты на различные сегменты (внутренние продукты, продукты B2C, B2G и B2B). Дирекция Big Data&AI сфокусирована на B2B-сегменте, у нас 13 продуктовых команд, 200 IT-специалистов, это ML, DS, дата аналитики, фронт, бек, DevOps и другие функции.

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

Привет! Продолжаю знакомить вас с библиотекой Prophet в качестве инстурмента прогнозирования продаж. Первая часть тут.

Функции для критериев качества в нашей прогнозной модели будут выглядеть следующим образом: