В феврале 2024 года стартовал секретный проект по ребрендингу Tele2: шведская франшиза заканчивалась, и мобильный оператор не планировал её продлевать. Проект по обновлению стиля коснулся и digital-платформы.

Нужно было переделать цифровое пространство Tele2 с большим количеством пользовательских сценариев под актуальные требования Т2. Это было сделано силами команды разработки T2 с помощью экспертов Лиги Цифровой Экономики.

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

В чем сложность проекта?

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

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

Эффективное управление проектами требует гибкости и прозрачности — особенно когда речь идет о крупном бизнесе, работающем с чувствительной информацией. Для этих целей был создан Атом.Проект, который мы теперь используем и внутри компании. Меня зовут Александр Кобозев, я директор практики в блоке BI и практике BigData Лиги Цифровой Экономики. В этом материале расскажу, как функционирует разработанная платформа для управления проектами и как именно она способна улучшить рабочие процессы.

Наша команда занимается развитием продуктов в сфере информационной безопасности в Лиге Цифровой Экономики. В этой статье хотим поделиться опытом создания нашего продукта — модуля управления инфраструктурными секретами ЦУП 2.0 на основе открытого программного обеспечения. В нашем случае это «ванильный» Vault версии 1.7, который был доступен по свободной лицензии MPL. Взяв его за основу в 2021 году, мы почти сразу столкнулись со следующими проблемами его использования:

отсутствие горизонтального масштабирования;

ограничение производительности при использовании в высоконагруженном режиме;

неадаптивный мониторинг;

узкие возможности управления доступом.

Все эти проблемы нам пришлось решать, т. к. стояла задача развернуть наш модуль секретов в проекте, где он будет интегрирован с системами Mission Critical+. Как мы это сделали — расскажем подробнее в статье.

Писать о регрессе в 2024 году — казалось бы, странная идея: каждый, кто хоть как-то связан с IT-миром, знает, что такое регрессионное тестирование и зачем оно нужно. В каждом курсе, в каждой статье для новичка о нем рассказывается. Вроде бы можно закрыть тему… Но почти каждый раз, когда на собеседовании я задаю вопрос: «Как мне выбрать тесты для регресса?», четкого ответа я не получаю. Это не зависит от уровня тестировщика, его опыта и направления. 

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

Делаем резервное копирование кластера ClickHouse: простая инструкция

Меня зовут Леонид Блынский и я администратор баз данных в Лиге Цифровой Экономики. В этой небольшой статье расскажу, как я делаю резервное копирование кластера ClickHouse размером 20 ТБ.

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

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

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

Процитирую автора древнеримского романа «Сатирикон»: «Чему бы ты ни учился, ты учишься для себя». Актуальности она не потеряла и по сей день. Так что, как вы уже могли понять, речь в статье пойдет про самообразование. А точнее — про то, как его можно разнообразить и попробовать сделать интереснее, при этом получить новые навыки не только в теме, которую изучаем в конкретный момент.

Давайте знакомиться: меня зовут Евгений, мне 30 лет, работаю в сфере ИТ уже более 8 лет и сейчас занимаю позицию ведущего DevOps-инженера в Лиге Цифровой Экономики. 

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

Люди вокруг спешат за подарками, а пришедшие по рабочим задачам коллеги и фитнес-тренеры, которые весь год из одного большого кубика живота своих подопечных старались сделать несколько маленьких, всё чаще слышат фразу:

— С наступающим! Давайте уже после Нового года-а?

Пока все вокруг находятся в предвкушении длинных выходных, я, Эльдар Аглиуллин, руководитель группы направления информационной безопасности Лиги Цифровой Экономики, предлагаю посмотреть на требования по защите информации 17 приказа ФСТЭК России глазами героев советской кинокомедии «Джентльмены удачи». 

Добро пожаловать под кат (осторожно, много картинок).

Приветствуем! На связи вновь Глеб Кононенко и Алексей Диков — разработчики из Лиги Цифровой Экономики. Ранее мы уже немного рассказывали про наш опыт работы с распределенными таблицами в ClickHouse в этой статье.

Сегодня хотим поделиться опытом оптимизации запросов и работы со словарями данных. Используемая версия ClickHouse: 23.8.7.24

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

А что будет, если в один прекрасный момент времени всё это «превратится в тыкву»? Как тогда быть простому аналитику и чем работать?

Без паники, выход есть. Меня зовут Андрей Устьянцев, я ведущий аналитик направления Big Data Лиги Цифровой Экономики. Я проведу небольшую ознакомительную экскурсию в мир Linux и покажу, что аналитик вполне себе может решать повседневные задачи в этой операционной системе.

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

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

В Лиге Цифровой Экономики для описания бизнес-процессов будущего продукта мы рассматривали и пробовали такие инструменты: 

Меня зовут Андрей Устьянцев, я ведущий аналитик направления Big Data Лиги Цифровой Экономики. Этот текст — техническое продолжение ранее написанных мной материалов: 

Приветствуем!

На связи Глеб Кононенко и Алексей Диков, мы разработчики из Лиги Цифровой Экономики. Год назад на одном большом проекте мы с коллегами начали работать с ClickHouse и сразу столкнулись с кучей проблем и недостатком информации по их преодолению.

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

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

Мы набрались опыта, «набив шишки» на практике, и готовы им поделиться — запускаем цикл статей о том, как правильно «готовить» ClickHouse. И начнем с того, как эффективно создавать и использовать распределенные таблицы. 

Немного о проекте: 

Стандартный интерфейс «Яндекс.Метрики» позволяет анализировать данные о посетителях сайта и их поведении достаточно подробно. Тем не менее, для решения задач глубокой аналитики (про это я рассказывал здесь) стандартного функционала может оказаться недостаточно. 

К тому же многим аналитикам привычнее и зачастую нужнее проводить аналитику в электронных таблицах (Excel, Google Sheet) или BI. Да, можно выгружать отчеты из «Метрики» сначала в Excel-файлы. Но на таком полуручном режиме оперативной и эффективной аналитики особо не построишь.

Меня зовут Андрей Устьянцев, я ведущий аналитик направления Big Data в Лиге Цифровой Экономики. В этой статье я пошагово распишу, как получать данные из «Яндекс.Метрики» в электронные таблицы (Excel, Google Sheet) и BI в автоматическом режиме. 

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

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

DevOps-инженер связывает и синхронизирует все этапы разработки программного обеспечения: от составления технического задания до релиза.

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

Со стороны hard skills это очень творческое направление — можно построить инфраструктуру или автоматизировать работу совершенно разными способами, приходится разбираться в процессах ИТ-бизнеса. Последнее, кстати, будет актуально для тех, кто в будущем планирует строить свой стартап. А еще это отличная профессия для общительных людей. 

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

Меня зовут Андрей Устьянцев, я ведущий аналитик направления Big Data в Лиге Цифровой Экономики. Эту статью я задумал как вторую в цикле материалов (первую об улучшении лендинга на основе метрик вы можете прочитать здесь). Сам текст будет полезен аналитикам, которым необходим более глубокий анализ данных о посетителях сайта, чем предоставляет стандартный интерфейс «Яндекс.Метрики». Или тем, кто хочет объединить данные из «Метрики» с другими источниками (например, из CRM) для визуализации, поиска инсайтов, проверки продуктовых гипотез etc.

Привет, Хабр! Меня зовут Евгений Абрамкин, я руководитель поддержки третьего уровня в направлении омниканальных решений Лиги Цифровой Экономики. Моя команда — последняя «инстанция» во флоу по решению инцидентов. Мы пишем доработки и фиксы, чтобы победить проблему клиента, а также можем предоставить оптимальную конфигурацию для системы, которая передана на эксплуатацию или требует масштабирования. Это может быть кластер Elasticsearch, балансировщики nginx или что поинтереснее — распределенная NoSQL СУБД Apache Cassandra.

В материале я расскажу именно об Apache Cassandra: какие ошибки можно совершить при ее использовании, на что стоит обратить внимание и чем лучше не пренебрегать.

Привет, Хабр! Меня зовут Андрей Устьянцев, и я ведущий аналитик направления Big Data в Лиге Цифровой Экономики. Занимаясь digital-маркетингом с 2006 по 2019 год, в какой-то момент я осознал очевидную сейчас многим истину. Эффективность рекламной кампании в интернете зависит не только от качества настройки ее параметров, но и от продающего качества лендинга, на который ведется рекламный трафик.

Но как измерить качество? Оперирование субъективными мнениями дизайнеров и результатами опросов в «экспертных сообществах» (в духе «подскажите, что не так»), как я могу судить по моему опыту, ни к чему в итоге не приводит.

Поэтому я разработал систему формирования метрик (сухих объективных цифр), на основе которых можно оцифровать качество лендинга.

Коротко — суть:

Привет, Хабр! Меня зовут Евгений Абрамкин, я руководитель поддержки третьего уровня в направлении омниканальных решений Лиги Цифровой Экономики. Моя команда — последняя «инстанция» во флоу по решению инцидентов. Мы пишем доработки и фиксы, чтобы победить проблему клиента, а еще предоставляем оптимальную конфигурацию для системы, которая передана в эксплуатацию или требует масштабирования. Это может быть кластер Elasticsearch, балансировщики nginx или что поинтереснее — распределенная NoSQL СУБД Apache Cassandra.

Михаил Михайлец, руководитель группы аналитиков направления облачных решений Лиги Цифровой Экономики, рассказал, как его команда попробовала быстро подготовить задачи по классическому ТЗ (ГОСТ 19) в Jira при работе с государственным заказчиком и что из этого получилось.

Пожалуй, большинству известно, что ГОСТ предусматривает водопадную модель разработки ПО. До недавнего времени она была зафиксирована в постановлении Правительства Российской Федерации от 6 июля 2015 г. № 676 «О требованиях к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем и дальнейшего хранения содержащейся в их базах данных информации».

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

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