Кейс: аналитическая система с ИИ для «ОЭЗ Технополис «Москва»

Привет, Хабр! Сегодня хочу рассказать о том, как мы с партнером-интегратором разработали и внедрили аналитическую систему Modus с искусственным интеллектом. Поехали!

Схема архитектуры Modus с ИИ

Схема архитектуры Modus с ИИ

До старта проекта сотрудники компании «Технополис «Москва» собирали информацию о задачах и поручениях по 10 исполнителям вручную из системы МосЭДО, и на это уходило больше 2-3 часов каждый день. При этом информация была ограничена не только по исполнителям, но и за период.

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

Разработали роботизированный алгоритм, который собирает, выгружает и обновляет поручения по всем исполнителям, а это порядка 200 человек. Искусственный интеллект анализирует полученный массив и классифицирует информацию, добавляет более детальные срезы для глубокого анализа.

Сформированные уточненные таблицы с детализацией по каждому поручению служат источником для двух направлений аналитики:

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

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

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

Мониторинг посещаемости для маркетинга c SimilarWeb

BI-систему интегрировали с web-аналитикой SimilarWeb.

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

Разработчики использовали стандартную версию сервиса SimilarWeb без расширений и API, собрали информацию по определенным источникам и свели в единый дашборд. В результате работа с аналитикой занимает не больше 3 минут.

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

Кастомные дашборды

Солодовникова Екатерина, руководитель практики BI, Смарт Тим Сервис:

 «Не все BI-системы поддерживают гибкую настройку. Часто, чтобы что-то доработать под требования заказчика, нужно знать внутренние языки и иметь в штате дорогих специалистов. А в Modus BI очень богатая палитра настроек и очень многое в дизайне можно сделать просто кликом мышки в версии «из коробки». Но и для более требовательных пользователей есть возможность превратить дашборд в искусство, используя всего лишь встроенный редактор CSS.

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

Двухуровневая архитектура баз данных

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

Было принято выстроить двухуровневую структуру аналитики Modus BI, особенность которой – это практически бесшовное встраивание в любую архитектуру. Источник для аналитического портала перенесли с PostgreSQL на более производительную ClickHouse в части высоконагруженных отчетов. В результате сократили скорость обработки данных до 5 секунд.

А что еще?

  • Разработали вспомогательные дашборды для оценки посещаемости пользователей и популярности тех или иных отчетов. Они служат одновременно и инструментом оценки, как пользователи воспринимают новый инструмент анализа данных, и источником информации для улучшения аналитического портала, чтобы все больше сотрудников компании «Технополис» пользовались системой.

  • «Смарт Тим Сервис» развивает дата-каталог с использованием Modus BI в части визуализации потоков данных от источников до каждого поля в дашборде. Это дает четкое понимание, что стоит за каждой цифрой, и где в источниках эта цифра содержится.

  • Новая модель данных охватывает все сферы бизнеса компании «Технополис». Поэтому собранные данные стали эталонными справочниками, которые используют все внутренние системы и подразделения компании

Солодовникова Екатерина, руководитель практики BI, «Смарт Тим Сервис»:

«Мы гордимся, что эти 12 месяцев работаем бок о бок с профессионалами из компании «Технополис», разрабатывая и улучшая аналитическую систему на базе Modus BI.

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

Разработанная аналитическая система открывает широкий спектр возможностей:

1. Интеграция данных

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

2. Интерактивная визуализация

Modus BI визуализирует данные и создает интерактивные дашборды для удобного мониторинга и управления бизнесом. Интуитивно понятные графики и диаграммы помогают быстро и эффективно представлять результаты анализа и делиться ими с командой, а адаптивный интерфейс — просматривать нужную информацию с любого устройства, например, со смартфона».


ссылка на оригинал статьи https://habr.com/ru/companies/modusbi/articles/751488/

Субъективный топ подкастов про IT: разработка, продукт, дизайн, аналитика

Привет! Меня зовут Даша Пешая, я head of developer relations в СберМаркете. А еще – фанат подкастов, слушаю их при любом удобном случае. Считаю, что нет удобнее формата узнавать новое, совмещая это с прогулкой с собакой / поездкой в метро / пробежкой / или, как пишут в анкетах, «вставьте свой вариант ответа». 

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

Будет и вечная классика (хиты 2020-ых), и свежие подкаст-игроки. Но главное, в подборку вошли только актуальные подкасты, которые регулярно выходят и растят вокруг себя уютные комьюнити. Если я что-то упустила, смело добавляйте в комментарии.

  1. Для дизайнеров

  2. Для продактов и аналитиков

  3. Для разработчиков (веб, фронтенд, бэкенд, инфраструктура)

  4. Для тимлидов и тех, кто хочет ими стать

  5. Для всех в IT и около

Дизайн

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

Дизайн прост. Подкаст, где поднимаются разные околодизайнерские темы: от проведения исследований до технологий в fashion-индустрии и грейдах дизайнера. 1 выпуск = 1 гость, причём встречаются весьма неожиданные (например, эпизод с врачом о профессиональных заболеваниях дизайнера или про крипту).

Ladies, Wine & Design, Moscow. Ladies, Wine & Design — некоммерческое сообщество, которое существует по всему миру. Московский филиал с энтузиазмом развивает русскоязычный подкаст, где приглашает девушек из мира дизайна поговорить о разном. 

Не о дизайне (NOD). Пусть вас не сбивает с толку название — как пишут сами ведущие: «О дизайне мы говорим тоже». Крутые гости, душевные разговоры о том, что волнует дизайнеров и очень крутой звук.

Дизайн тусовка. Подкаст от Евгения Шевцова, дизайн-директора в Usetech. В этом подкасте у Жени классический формат беседы с одним гостем (и вокруг него), а еще есть более экспериментальный — Этот ваш дизайн, где нет никаких правил. Берем, дайте оба!

Мой фаворит — подкаст «Дизайн тусовка», где я всегда нахожу что-то интересное для себя под настроение. Женя вместе с гостями освещает как вопросы дизайна в разных сферах, так и рассказывает истории пути, становления, развития дизайнеров.

Олеся Гумененко

Lead Product Designer

Дата и продукт

Make Sense. Классика! Кажется, его слушает почти всё продуктовое сообщество. Основатель конференции Product Sense Юра Агеев обсуждает с гостями эфира, что важно при создании продуктов: от инструментов и практик до мировоззрения и команды. 

(Не)настоящий продакт. Подкаст начинался как нарративный: в первом сезоне сотрудница продуктового офиса Сбера разбирается, как стать Product Owner’ом, параллельно лучше выясняя для самой себя, что это вообще за профессия и как устроено продуктовое управление. Во втором сезоне подкаста уже идут вглубь: например, обсуждают специфику разработки B2B и B2C продуктов. В общем, хорош и для старта в профессию и для более глубокого погружения.

Data Heroes. В выпусках длительностью 30-60 минут ведущий обсуждает с гостями разные аспекты аналитики данных. Из нестандартного — выпуски про ведение и монетизацию канала по аналитике и Новый год в ритейле! 

Data Coffee. Подкаст «о данных в современном мире, а также их хранении, визуализации и обработке». Но встречаются и более экзистенциальные темы — например, про дружбу дата инженеров и аналитиков или о пути тимлида. 

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

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

Особенно рекомендую выпуск с продакт-лидом Mos.ru Денисом Катковым о том, как создаются лучшие в мире городские сервисы, и выпуск с Антоном Куликовым, продактом MeindMeister, о том, как на самом деле нужно проверять гипотезы.

Лев Левицкий

Product Manager

Разработка

The art of programming. Подкаст существует, шутка ли, с 2015 года и насчитывает 250+ эпизодов. За это время очередь на обсуждения дошла до многого, но большинство выпусков, действительно, про искусство написания кода. На самых разных языках и в самых разных индустриях.

Люди и код. Как определяют себя сами ребята — это подкаст о программистах и для программистов. В каждом выпуске обсуждаются проблемы индустрии, интересные явления и технологии.

Кода кода. Подкаст о том, «что интересует программистов и менеджеров, но сложно обсудить с коллегами и начальством». Жизненные и искреннние выпуски о наболевшем.

Выбираю «Кода кода», когда хочется чего-то про IT, но ненапряжного. Легкая подача, интересные гости. Мне понравился выпуск «Стартап или энтерпрайз — где работать лучше?», когда-то я тоже искал ответ на этот вопрос и нашел здесь много близких для себя мыслей. А из технического рекомендую «Highload на практике — как готовиться и как держать высокие нагрузки».

Лев Захаров

Go-разработчик

Веб и фронтенд

Frontend Weekend. 150+ интервью с гостями из IT-индустрии — оправдывая свое название, преимущественно фронтенд-разработчиками. Человекоцентричные выпуски про разработку и карьеру, развитие и поиск себя в жизни.  

Суровый web. Подкаст суровый, потому что вещание идёт из Челябинска! Вышло уже более 200 эпизодов, так что сложилась своя особая атмосфера. Темы эпизодов в основном вокруг веба и фронтенда.

Сделайте мне красиво. Ещё один подкаст о фронтенд-разработке, а вовсе не о дизайне, как могло показаться из названия. Обсуждаются хардовые темы вокруг JS, CSS, React.

Веб-стандарты. Подкаст от одноименного сообщества разработчиков. Выходит каждую неделю, при этом средняя длительность каждого эпизода — полтора часа! Так что ребята ни одну новость фронтенда без обсуждения не оставят 🙂   

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

Илья Тимофеев

Ruby-разработчик

Бэкенд и инфраструктура

Moscow Python Podcast. Название говорит само за себя —это подкаст от московского сообщества питонистов. Поднимают все насущные темы: новости python-разработки, боли и радости observability и что делать, чтобы тебя не заменили нейросети. Есть спецвыпуски с ответами на вопросы зрителей. 

Linkmeup. Подкаст про сети, администрирование, DevOps и разработку. Осторожно: есть эпизоды длительностью больше 120 минут!

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

Go Get Podcast. Свежий подкаст о Golang-разработке. Помимо классических подкаст-платформ, выпуски выходят еще и на YouTube. Кстати, кроме подкаста там автор выкладывает и классические туториалы: от написания собственных торрент-клиентов или архиватора. 

Для лидов и тех, кто хочет ими стать

Разговоры СТО. Подкаст от команды Dodo Engineering, где каждый выпуск — интервью с СТО из других компаний. Поднимают волнующие душу техлидов темы: приоритизацию задач и распил монолита, структуру команд, найм и синхронизацию IT с бизнесом.

Asan Talks. Асан Курмангужин, сооснователь СберМаркета, берет интервью у вдохновляющих лидеров – предпринимателей и топ-менеджеров. Здесь можно вдохновиться историями о смелости в бизнесе, поиске себя и продуктивном мечтании.  

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

Серебряная Чпуля. Подкаст про Agile. Здесь будут темы близкие тимлидам, проджектам и продактам (потому что всё так или иначе про менеджмент в IT). Много классных историй из индустрии, которые вдохновят на мысли о том, как организовать работу у вас.

Для всех в IT и около

Podlodka. Один из бессменных игроков любой подборки про подкасты. Ведущие начинали с обсуждения мобильной разработки, но в этом блоке им быстро стало тесно.  В более, чем 300+ выпусках (шутка ли – с 2017 года!) каждый найдет что-то для себя: и хардкор про Scala, и, например, выпуски, посвященные кофе и чаю.

BeardyCast. Подкаст о технологиях и медиакультуре – от обзоров умного дома и новинок техники до дискуссий, зачем же все-таки компаниям опенсорс.  

Запуск завтра. За несколько лет – с 2019 года – стал фаворитом многих слушателей. В каждом выпуске Самат Галимов, технический директор, приглашает гостей из мира ИТ и обсуждает с ними сложные темы простым языком.

Радио-Т. Еженедельные разговоры на темы хайтек, высоких компьютерных технологий, гаджетов, облаков, программирования и прочего интересного из мира ИТ.

Трещим. Подкаст от разработчика на темы около технологий, которые его интересуют: ChatGPT, безопасность в сети, венчурные инвестиции и многое другое.

Кот уронил прод. Подкаст, который прекрасен тем, что в нём разбирают факапы и фейлы в IT (с теми, кто их совершил).

Для tech и этих. Подкаст, где 4 технических менеджера пытаются вынести уроки из успехов и провалов IT-гигантов. 1 эпизод — 1 компания: Apple, Microsoft, Netflix, Valve, Amazon и другие. Недавно стартовал сезон в видеоформате.

PS: кстати, этот подкаст делает моя команда, но этот тот случай, когда себя не стыдно похвалить 🙂 У нас более 4,5 тысяч лайков на Яндекс.Музыке, оценка 4,8 на Apple Podcasts и сложилась крепкая база фанатов. А ещё в подкасте мы часто рекомендуем хорошие книги по менеджменту, вот одна из наших подборок.

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


ссылка на оригинал статьи https://habr.com/ru/companies/sbermarket/articles/751056/

Вышел релиз GitLab 16.1 с совершенно новой навигацией

Картинка для привлечения внимания

Сегодня мы с радостью объявляем о новом релизе GitLab 16.1 с полностью изменившимся опытом навигации, GitLab Dedicated в общем доступе, визуализацией ресурсов Kubernetes, аутентификацией через сервисные аккаунты и многими другими фичами!

Это лишь несколько из более 100 улучшений, добавленных в этом релизе. Читайте дальше, чтобы узнать обо всех основных изменениях.

Мы благодарны сообществу GitLab за 189 изменений, которые они внесли в релиз 16.1! В GitLab каждый может сделать свой вклад, и ваш вклад в этот релиз неоценим!

Чтобы заранее узнать, что запланировано на следующий месяц, посмотрите страницу наших будущих релизов — на ней есть видео, посвящённое релизу 16.2.

GitLab MVP badge

Награда MVP этого месяца присуждается Gerardo Navarro и Yuri Konotopov

Gerardo упорно работал на протяжении нескольких релизов, чтобы у нас появились конечные точки REST API для области доступа токенов заданий. Итерирование – одна из ключевых ценностей GitLab, и Gerardo придерживался этой ценности, сделав множество итераций, чтобы добавить эту фичу.

Из-за изменений в дефолтном поведении токена CI_JOB_TOKEN у пользователей, которые автоматизировали создание проектов, не было возможности также автоматизировать добавление проектов. Эта конечная точка REST API позволит нашим пользователям снова автоматизировать этот процесс и повысить безопасность с использованием рабочего процесса CI_JOB_TOKEN.

Спасибо Gerardo и остальной команде из Siemens за эту фичу!

Yuri подхватил тикет, который был создан 6 лет назад, проявил проактивность – ещё одна из ключевых ценностей GitLab – и внёс это улучшение.

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

Спасибо Yuri за этот ценный вклад!

Ключевые фичи в GitLab 16.1

Новая навигация

(Доступно в планах SaaS: FREE, PREMIUM, ULTIMATE; self-managed: FREE, PREMIUM, ULTIMATE) Стадия цикла DevOps: Manage

GitLab 16.1 представляет совершенно новую навигацию! Сейчас её могут включить все пользователи. Чтобы начать пользоваться новой навигацией, кликните на свой аватар в верхнем правом углу и нажмите на переключатель Новая навигация (New navigation).

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

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

  • Закреплять 📌 часто используемые пункты;
  • Полностью скрывать боковую панель и открывать её по наведению мыши;
  • Легко переключать контексты, производить поиск и просматривать подразделы данных с новыми опциями Ваша работа (Your Work) и Обзор (Explore);
  • Просматривать меню быстрее благодаря меньшему количеству пунктов в верхнем уровне.

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

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

Документация о левой боковой панели GitLab и оригинальный эпик.

Визуализация ресурсов Kubernetes в GitLab

(Доступно в планах SaaS: FREE, PREMIUM, ULTIMATE; self-managed: FREE, PREMIUM, ULTIMATE) Стадия цикла DevOps: Deploy

Как проверить статус приложений, запущенных на ваших кластерах Kubernetes? Страницы статуса конвейера (в русской локализации GitLab «сборочная линия») и окружения дают информацию о последних запущенных развёртываниях. Однако, в предыдущих версиях GitLab не хватало информации об их состоянии. В GitLab 16.1 у вас появляется возможность просматривать информацию об основных ресурсах ваших развёртываний.

Эта фича работает со всеми подключёнными кластерами Kubernetes. Не важно, развёртываете ли вы свои приложения через интеграцию с CI/CD или через GitOps. Чтобы сделать эту фичу ещё полезнее для пользователей Flux, в тикете 391581 предлагается поддержка статуса синхронизации окружения.

Документация о панели информации Kubernetes и оригинальный тикет.

Сервисные аккаунты

(Доступно в планах SaaS: PREMIUM, ULTIMATE; self-managed: PREMIUM, ULTIMATE) Стадия цикла DevOps: Manage

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

Сервисные аккаунты не привязаны к конкретному человеку и более универсальны в настройке уровня доступа. Создание сервисных аккаунтов и управление ими пока что возможно только через API GitLab. Поддержка графического интерфейса разрабатывается в эпике 9965.

Документация по сервисным аккаунтам и оригинальный эпик.

GitLab Dedicated вышел в общий доступ

(Доступно в плане SaaS: ULTIMATE) Направление: Платформы

GitLab Dedicated — это управляемое однопользовательское SaaS-развёртывание нашей платформы DevSecOps, разработанной для решения проблем клиентов со строгими требованиями к безопасности.

Такие пользователи ранее не могли использовать GitLab SaaS из-за необходимости соблюдать строгие ограничения, например изоляцию данных. С GitLab Dedicated организации смогут получить доступ ко всем возможностям платформы DevSecOps, включая более быстрые релизы, улучшенную безопасность и повышение продуктивности разработчиков, в то же время соблюдая требования к безопасности, такие как локализация и изоляция данных, коммуникация в локальных сетях.

Узнайте больше о GitLab Dedicated.

GitLab Dedicated is now generally available

Документация по GitLab Dedicated и страница, посвящённая GitLab Dedicated.

Управление артефактами заданий со страницы артефактов

(Доступно в планах SaaS: FREE, PREMIUM, ULTIMATE; self-managed: FREE, PREMIUM, ULTIMATE) Стадия цикла DevOps: Verify

Ранее, если вы хотели просмотреть артефакты заданий или управлять ими, вам приходилось переходить на страницу каждого задания или использовать API GitLab. Теперь вы сможете просматривать и настраивать артефакты через страницу Артефакты (Artifacts), доступную в меню Сборка > Артефакты (Build > Artifacts).

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

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

Manage job artifacts through the Artifacts page

Документация по странице артефактов, тикет по расширению таблицы с данными об артефактах, тикет по удалению артефактов, тикет по групповому удалению артефактов, тикет по групповому выбору для удаления артефактов.

Улучшенный список переменных CI/CD

(Доступно в планах SaaS: FREE, PREMIUM, ULTIMATE; self-managed: FREE, PREMIUM, ULTIMATE) Стадия цикла DevOps: Verify

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

В GitLab 16.1 вы сможете увидеть первую итерацию этих улучшений. Мы объединили колонки Тип (Type) и Настройки (Options) в новую колонку Атрибуты (Attributes), которая лучше представляет эти связанные атрибуты. Мы будем благодарны за ваш фидбек о том, как мы можем продолжить улучшение работы с переменными CI/CD. Оставляйте комментарии в нашем эпике, посвящённом улучшению переменных.

Improved CI/CD variables list view

Документация по определению переменных CI/CD через графический интерфейс GitLab и оригинальный тикет.

Другие улучшения в GitLab 16.1

Улучшенная верификация домена

(Доступно в планах SaaS: FREE, PREMIUM, ULTIMATE; self-managed: FREE, PREMIUM, ULTIMATE) Стадия цикла DevOps: Manage

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

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

Документация по настройке верифицированного домена и оригинальный тикет.

Восстановление пароля через любой подтверждённый адрес почты

(Доступно в планах SaaS: FREE, PREMIUM, ULTIMATE; self-managed: FREE, PREMIUM, ULTIMATE) Стадия цикла DevOps: Manage

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

Документация по изменению пароля в GitLab и оригинальный тикет.

Ограничение удаления аккаунтов

(Доступно в планах self-managed: PREMIUM, ULTIMATE) Стадия цикла DevOps: Manage

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

Документация по ограничению удаления аккаунтов и оригинальный тикет.

Передача информации SCIM через API

(Доступно в планах SaaS: PREMIUM, ULTIMATE; self-managed: PREMIUM, ULTIMATE) Стадия цикла DevOps: Manage

API пользователей теперь возвращает для пользователя информацию SCIM. Ранее эта информация была доступна через графический интерфейс, но не через API.

Документация по API пользователей и оригинальный тикет.

Просмотр отчёта о уязвимостях как настраиваемое разрешение

(Доступно в планах SaaS: ULTIMATE; self-managed: ULTIMATE) Стадия цикла DevOps: Manage

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

Документация по настраиваемым ролям и оригинальный эпик.

Настройка директории статических файлов в GitLab Pages

(Доступно в планах SaaS: FREE, PREMIUM, ULTIMATE; self-managed: FREE, PREMIUM, ULTIMATE) Стадия цикла DevOps: Plan

Теперь вы можете задавать для директории статических файлов в GitLab Pages произвольное имя (по умолчанию public). Это упростит работу в Pages с популярными статическими фреймворками, такими как Next.js, Astro или Eleventy, освобождая от необходимости изменять папку при их настройке.

Configure the static file directory in GitLab Pages

Документация по настройке папки GitLab Pages по умолчанию и оригинальный эпик.

Генерация списков изменений из GitLab CLI

(Доступно в планах SaaS: FREE, PREMIUM, ULTIMATE; self-managed: FREE, PREMIUM, ULTIMATE) Стадия цикла DevOps: Create

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

Начиная с релиза GitLab CLI 1.30.0 вы сможете генерировать списки изменений прямо из CLI. Команда glab changelog generate упрощает просмотр, автоматизацию и публикацию списков изменений.

Спасибо Michael Mead за эту фичу!

Документация по спискам изменений и оригинальный тикет.

Конечная точка для настройки области доступа токена заданий CI/CD

(Доступно в планах SaaS: FREE, PREMIUM, ULTIMATE; self-managed: FREE, PREMIUM, ULTIMATE) Стадия цикла DevOps: Verify

В GitLab 16.0 изменилась область доступа токена заданий CI/CD по умолчанию (CI_JOB_TOKEN) для всех новых проектов. Это повысило безопасность новых проектов, но также добавило дополнительный шаг для пользователей, которые создавали проекты автоматически. Эта автоматизация иногда требовала настройки области доступа токена, что могло быть сделано через GraphQL или вручную через графический интерфейс, но не через REST API.

Чтобы сделать эту настройку доступной также через REST API, Gerardo Navarro добавил в версии 16.1 новую конечную точку для контроля области видимости токена заданий. Эта настройка доступна всем пользователям с уровнем доступа мейнтейнера или выше. Спасибо Gerardo за эту потрясающую фичу!

Документация по токенам доступа CI/CD и оригинальный тикет.

Объединение обработчиков заданий с одинаковыми настройками

(Доступно в планах SaaS: FREE, PREMIUM, ULTIMATE; self-managed: FREE, PREMIUM, ULTIMATE) Стадия цикла DevOps: Verify

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

Runner details - consolidate runners sharing a configuration

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

Шаблон ссылки на тикет службы поддержки для электронных писем

(Доступно в планах SaaS: FREE, PREMIUM, ULTIMATE; self-managed: FREE, PREMIUM, ULTIMATE) Стадия цикла DevOps: Monitor

Пользователям, которые обращаются в службу поддержки, может быть полезно получить доступ напрямую к созданному там тикету (в русской локализации GitLab «обсуждение») вместо того, чтобы взаимодействовать со своей заявкой только через почту. Мы представляем новый плейсхолдер %{ISSUE_URL}, который вы сможете использовать в своих шаблонах электронных писем (например, в письме с благодарностями), чтобы отправлять пользователям прямую ссылку на тикет службы поддержки.

Документация по службе поддержки и оригинальный тикет.

Автоматический ответ на слитые секретные ключи Google Cloud

(Доступно в плане SaaS ULTIMATE) Стадия цикла DevOps: Secure

Мы интегрировали поиск секретных ключей с Google Cloud для лучшей защиты пользователей, которые используют GitLab для разработки приложений в Google Cloud. Теперь, если организация отправляет данные Google Cloud в публичном проекте на GitLab.com, GitLab может автоматически защитить аккаунты организации, работая совместно с Google Cloud.

Поиск секретных ключей ищет три типа уязвимостей, определяемых Google Cloud:

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

Эта интеграция автоматически включена для проектов, в которых активирован поиск секретных ключей на GitLab.com. Сканирование на поиск секретных ключей доступно для всех планов GitLab, но автоматический ответ на слитые данные пока доступен только для планов Ultimate.

Больше деталей об этой фиче можно найти в нашем блоге.

Документация по автоматическому ответу на слитые секретные ключи и оригинальный тикет.

Обновления анализатора качества кода

(Доступно в планах SaaS: FREE, PREMIUM, ULTIMATE; self-managed: FREE, PREMIUM, ULTIMATE) Стадия цикла DevOps: Secure

Анализатор качества кода (GitLab Code Quality) поддерживает интеграцию инструментов, которые вы уже используете, а также предлагает шаблон CI/CD для запуска системы сканирования CodeClimate. Мы опубликовали следующие обновления для анализатора на основе CodeClimate с релизом 16.1:

  • Обновили CodeClimate до версии 0.96.0, которая включает новый плагин для golangci-lint и новую доступную версию для плагина bundler-audit.
  • Добавили поддержку настраиваемого пути к Docker API Socket. Спасибо @tsjnsn за эту фичу! Обновления для включения этой переменной в шаблон CI/CD можно отслеживать в этом тикете.

Посмотрите подробности в списке изменений.

Если вы используете шаблон Code Quality под управлением GitLab (Code-Quality.gitlab-ci.yml), вы получите эти обновления автоматически.

Описание изменений Code Quality в предыдущих релизах вы можете найти в последнем обновлении.

Документация по Code Quality и оригинальный тикет.

Настройки общего набора правил в SAST, сканировании IaC и обнаружении секретных ключей

(Доступно в планах SaaS: ULTIMATE; self-managed: ULTIMATE) Стадия цикла DevOps: Secure

Теперь вы можете установить переменную CI/CD, чтобы в нескольких проектах использовать одни и те же настройки наборов правил для SAST, сканирования IaC или обнаружения секретных ключей.

Совместное использование набора правил может помочь вам:

Дальнейшие улучшения в этой области обсуждаются в этом тикете.

Документация по настройке наборов правил SAST и оригинальный тикет.

Пропуск проектов при резервном копировании

(Доступно в планах self-managed: FREE, PREMIUM, ULTIMATE) Системы

Встроенный инструмент бэкапа и восстановления теперь позволяет пропускать определённые репозитории. Задача Rake принимает список путей групп или проектов, разделённых запятыми, которые будут пропущены во время резервного копирования или восстановления с помощью новой переменной окружения SKIP_REPOSITORIES_PATHS. Так можно пропускать, например, устаревшие или архивные проекты, которые не меняются со временем, экономя как время за счёт ускорения выполнения резервного копирования, так и место за счёт отсутствия этих данных в файле резервной копии. Спасибо Yuri Konotopov за этот вклад!

Документация по настройкам резервного копирования и оригинальный тикет.

Geo верифицирует репозитории дизайна

(Доступно в планах self-managed: PREMIUM, ULTIMATE) Системы

При добавлении дизайна в тикет создаётся или обновляется Git-репозиторий дизайна, а также создаётся объект LFS и директория для макетов. Geo уже проверяет объекты LFS и выгрузки, а теперь он проверяет и репозитории дизайна. Теперь, когда все базовые данные управления дизайном (Design Management) проверены, ваши проектные данные гарантированно не будут повреждены при передаче или хранении. Если Geo используется как часть стратегии аварийного восстановления, это защитит вас от потери данных.

Документация по администрированию Geo.

Более подробная информация о завершённом импорте проекта из GitHub

(Доступно в планах SaaS: FREE, PREMIUM, ULTIMATE; self-managed: FREE, PREMIUM, ULTIMATE) Стадия цикла DevOps: Manage

По завершении импорта проекта GitHub GitLab ранее показывал простую сводку импорта. Однако он не показывал, ни те сущности GitHub, которые не удалось импортировать, ни ошибки, вызвавшие сбои импорта. Поэтому было трудно решить, достаточно ли хорошо прошёл импорт.

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

Документация по проверке статуса импорта с GitHub и оригинальный тикет.

Значение личного токена доступа last_used теперь обновляется чаще

(Доступно в планах SaaS: FREE, PREMIUM, ULTIMATE; self-managed: FREE, PREMIUM, ULTIMATE) Стадия цикла DevOps: Manage

Значение last_used для личных токенов доступа (PAT) ранее обновлялось каждые 24 часа. Теперь оно обновляется каждые 10 минут. Это повышает видимость использования PAT и снижает риск в случае компрометации PAT, поскольку вредоносную активность можно быстрее заметить.

Спасибо Jacob Torrey за этот вклад!

Документация по личным токенам доступа и оригинальный тикет.

Повторное внедрение поддержки OmniAuth Shibboleth

(Доступно в планах self-managed: FREE, PREMIUM, ULTIMATE) Стадия цикла DevOps: Manage

Мы вновь внедрили в GitLab поддержку Shibboleth OmniAuth. Ранее она была удалена в GitLab 15.9 из-за отсутствия поддержки со стороны разработчиков. Благодаря щедрому вкладу сообщества от lukaskoenen, взявшего на себя эту поддержку, omniauth-shibboleth-redux теперь поддерживается в инстансах GitLab с самостоятельным управлением.
Документация по интеграции Shibboleth и оригинальный тикет.

Выбор доступа администратора для личных токенов доступа в режиме администратора

(Доступно в планах self-managed: FREE, PREMIUM, ULTIMATE) Стадия цикла DevOps: Manage

Администраторы GitLab могут использовать режим Admin Mode для работы в качестве пользователя, не являющегося администратором, и включать доступ администратора, когда это необходимо. Ранее личный токен доступа (PAT) администратора всегда давал права на выполнение действий API как администратор. Теперь, выбрав область Admin Mode при добавлении PAT, администратор может решить, будет ли этот PAT давать доступ администратора для выполнения действий API или нет. Администратор должен включить режим администратора для инстанса, чтобы использовать эту фичу.

Спасибо Jonas Wälter, Diego Louzán и Andreas Deicha за эту фичу!

Документация по личным токенам доступа и оригинальный тикет.

Добавили описание к загрузке дизайна

(Доступно в планах SaaS: FREE, PREMIUM, ULTIMATE; self-managed: FREE, PREMIUM, ULTIMATE) Стадия цикла DevOps: Plan

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

Add a description to design uploads

Документация по добавлению дизайна в тикет и оригинальный эпик.

Комментарий ко всему файлу в мерж-реквестах

(Доступно в планах SaaS: FREE, PREMIUM, ULTIMATE; self-managed: FREE, PREMIUM, ULTIMATE) Стадия цикла DevOps: Create

Мерж-реквесты (в русской локализации GitLab «запросы на слияние») теперь поддерживают комментирование всего файла, потому что не все комментарии в мерж-реквестах зависят от конкретной строки. Например, можно указать причину удаления файла, обратную связь по его имени или общие комментарии по структуре.

Comment on whole file in merge requests

Документация по добавлению комментариев к файлу в мерж-реквесте и оригинальный тикет.

Улучшение пользовательского интерфейса конвейеров и заданий CI/CD

(Доступно в планах SaaS: FREE, PREMIUM, ULTIMATE; self-managed: FREE, PREMIUM, ULTIMATE) Стадия цикла DevOps: Verify

Одной из наиболее используемых фич GitLab является CI/CD. В версии 16.1 мы сосредоточились на повышении удобства использования и улучшении представления CI/CD конвейеров и списков заданий, а также страницы с подробной информацией о конвейере. Теперь найти нужную информацию стало ещё проще. Если у вас есть замечания по поводу этих изменений, напишите в нашем тикете обратной связи.

Документация по настройкам конвейера и оригинальный тикет.

Использование needs в rules.

(Доступно в планах SaaS: FREE, PREMIUM, ULTIMATE; self-managed: FREE, PREMIUM, ULTIMATE) Стадия цикла DevOps: Verify

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

Документация по использованию needs в rules и оригинальный тикет.

Увеличение хранилища для обработчиков заданий GitLab SaaS на Linux

(Доступно в планах SaaS: PREMIUM, ULTIMATE) Стадия цикла DevOps: Verify

После недавнего увеличения количества vCPU и RAM в наших обработчиках заданий GitLab.com SaaS для Linux, мы также увеличили размер хранилища для типов машин medium и large.

Теперь вы можете легко создавать, тестировать и разворачивать большие приложения, для которых иногда требуется безопасное окружение обработчиков заданий GitLab для Linux, полностью интегрированное с GitLab CI/CD.

Документация по обработчикам заданий GitLab для Linux и оригинальный тикет.

Установка пакетов npm из вашей группы или подгруппы

(Доступно в планах SaaS: FREE, PREMIUM, ULTIMATE; self-managed: FREE, PREMIUM, ULTIMATE) Стадия цикла DevOps: Package

Вы уже можете использовать реестр пакетов вашего проекта для публикации и установки пакетов npm. Вы просто аутентифицируетесь с помощью токена доступа (personal, job, deploy или project) и начинаете публиковать пакеты в своём проекте GitLab.

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

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

Документация по установке пакетов npm на уровне группы и оригинальный тикет.

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

(Доступно в планах SaaS: FREE, PREMIUM, ULTIMATE; self-managed: FREE, PREMIUM, ULTIMATE) Стадия цикла DevOps: Monitor

Когда автор мерж-реквеста отвечает на email службы поддержки, сотруднику поддержки полезно знать, кто сделал комментарий. Но поскольку автором комментария может быть внешний пользователь, не имеющий учётной записи GitLab или доступа к проекту GitLab, эти комментарии ранее приписывались боту поддержки GitLab. Теперь внешние пользователи тоже будут отображаться как авторы, что сделает тикеты понятнее.

Show external user as a comment author in Service Desk issues

Документация по работе службы поддержки и оригинальный тикет.

Более ясное руководство и лучшее покрытие для правил SAST

(Доступно в планах SaaS: FREE, PREMIUM, ULTIMATE; self-managed: FREE, PREMIUM, ULTIMATE) Стадия цикла DevOps: Secure

Мы обновили правила SAST на GitLab, чтобы:

  • Более чётко объяснять тип уязвимости, на который направлено каждое правило, и как её устранить. Пока мы обновили описание и руководство для правил для C, C#, Go и Java. Остальные языки планируется добавить в тикете 382119.
  • Устранить дополнительные уязвимости в существующих правилах для Java.

Эти улучшения — часть сотрудничества между командами статического анализа и исследования уязвимостей GitLab по улучшению наборов правил статического анализа. Мы будем рады любым отзывам о правилах по умолчанию для SAST, обнаружения секретных ключей и сканирования IaC в эпике 8170.

Более подробно изменения в правилах GitLab SAST описаны в списке изменений. Начиная с версии GitLab 16.1, проект sast-rules является единым источником всех управляемых GitLab правил, используемых в анализаторе SAST на основе Semgrep.

Документация по анализаторам SAST и оригинальный тикет.

Обновления анализатора SAST

(Доступно в планах SaaS: FREE, PREMIUM, ULTIMATE; self-managed: FREE, PREMIUM, ULTIMATE) Стадия цикла DevOps: Secure

Статическое тестирование безопасности приложений (SAST) в GitLab включает в себя множество анализаторов безопасности, активно управляемых, поддерживаемых и обновляемых командой статического анализа GitLab. Мы опубликовали следующие обновления в релизе 16.1:

Если вы используете шаблон SAST под управлением GitLab, (SAST.gitlab-ci.yml) и у вас GitLab 16.0 или выше, вы получите эти обновления автоматически. Чтобы оставаться на определённой версии любого анализатора и предотвратить автоматические обновления, вы можете закрепить его версию.

Предыдущие изменения смотрите в обновлениях за прошлый месяц.

Документация по анализаторам SAST и оригинальный тикет.

Блокирование мерж-реквестов при проверках подтверждений правил безопасности, когда есть недействительные правила

(Доступно в планах SaaS: ULTIMATE; self-managed: ULTIMATE) Стадия цикла DevOps: Govern

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

Документация по недействительным правилам подтверждения мерж-реквестов и оригинальный тикет.

Geo добавляет фильтрацию по статусу репликации для всех компонентов

(Доступно в планах self-managed: PREMIUM, ULTIMATE)

В Geo появилась фильтрация по статусу репликации во всех компонентах, управляемых его автоматизированной платформой. Теперь элементы в представлениях деталей репликации можно фильтровать по статусам «В процессе» (“In progress”), «Сбой» (“Failed”) и «Синхронизировано» (“Synced”), что упрощает и ускоряет поиск данных, которые не удаётся синхронизировать.

Документация по администрированию Geo и оригинальный тикет.


Полный текст релиза и инструкции по обновлению и установке вы можете найти в оригинальном англоязычном посте GitLab 16.1 released with all new navigation.

Над переводом с английского работали maryartkey, ainoneko, cattidourden и rishavant.


ссылка на оригинал статьи https://habr.com/ru/articles/751500/

Получаем данные из «Яндекс.Метрики» в электронные таблицы и BI: пошаговая инструкция

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

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

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

Дисклеймер

Если используемый вами BI-инструмент позволяет писать пользовательские скрипты на Python для извлечения данных (например, PowerBI), смело используйте эту возможность и примеры кода, описанные в статье. Ну, и дальше можно не читать.

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

А если для вас актуально получение данных из «Метрики» — читайте дальше. Поделюсь своим подходом, как я загружаю данные из «Яндекс.Метрики» в электронные таблицы и BI для глубокой Web-аналитики в своих проектах.

Создаем сервис доступа к данным «Яндекс.Метрики»

1. Создаем на виртуальном хостинге сайт на Python

Совет: не обязательно покупать свой собственный домен с «красивым» именем! Есть хостинг-провайдеры, которые предоставляют технические домены третьего уровня при аренде виртуального хостинга. 

Для решения текущей задачи не обязательно иметь «красивый» домен второго уровня (типа «аналитика.рф»), вполне подойдет и домен с именем вида “analitika.techdomen.ru”).

2. В качестве кода основного приложения сайта воспользуемся скриптом на Python для получения данных об источниках трафика на сайт по дням (код подробно описан здесь).

Рассмотрим подробнее код приложения сайта.

import requests  def application(env, start_response):     try:         API_URL = 'https://api-metrika.yandex.ru/stat/v1/data/bytime.csv'         API_token = 'y0_AgAAAAACO_AIAAk7QAUm2oFFORLi5yKWs6_H8gQAYmrU'         params = {                    'date1': '6daysAgo',         'date2': 'today',         'id': 779344,         'metrics': 'ym:s:visits,ym:s:users',         'dimensions': 'ym:s:TrafficSource',         'group' : 'day',         'filters' : "ym:s:isRobot=='No'",         'limit': 100         }                  r = requests.get(API_URL, params = params, headers={'Authorization':API_token})                  content=r.text                  start_response('200 OK', [('Content-Type','text/html')])         return [content.encode('utf-8')]     except Exception as S:         content=str(S)                  start_response('200 OK', [('Content-Type','text/html')])         return [content.encode('utf-8')]

Строка 1 — подключаем библиотеку requests (если она не установлена, запускаем на виртуальном хостинге терминал и выполняем команду pip install requests).

Строка 3 — основная функция, которая исполняется при открытии сайта. Исполняемый код на Python необходимо размещать в теле этой функции. Уточню, что хостинг-провайдер, которым я пользуюсь, при создании сайта на Python сразу создает типовой файл-приложения с «базовым» Python-кодом, так что мне остается только внести свой код в функцию application.

Строки 5-19 — получаем данные из «Яндекс.Метрики» (подробно этот код разобран в статье).

Строка 21 — преобразуем полученный ответ от «Яндекс.Метрики» в строковый формат.

Строка 23 — сообщаем Web-серверу:

‘200 OK’ означает код ответа «200» (общепринятый код успешности исполнения запроса);

‘Content-Type’,’text/html’ означает, что возвращаемые данные — это текст.

Строка 24 — вернуть полученные от «Метрики» данные в виде текста.

Строки 25-29 — обработка ошибок, которые могут возникнуть при исполнении кода. При ошибке будет возвращен собственно текст возникшей ошибки. 

Убедимся, что все работает корректно. Перейдем в браузер и введем в адресной строке адрес нашего сайта:

Вуаля — отображаются данные, полученные из «Яндекс.Метрики». 

Загружаем данные «Яндекс.Метрики» в Excel

Если у вас Excel версии 2010, 2013

Сначала нужно дополнительно установить компонент PowerQuery.

На момент написания материала скачать и установить его можно было по ссылке с официального сайта.

После этого в Excel:

1. Выбираем вкладку «PowerQuery».

2. Затем — «Из Интернета».

3. Вводим адрес нашего сайта.

4. Жмем кнопку «Ок».

Если в правой части окна в предпросмотре у вас не отобразятся данные, а будет картинка по примеру как ниже, без паники!

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

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

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

5. Нажмите кнопку «Загрузить». 

Готово — данные из «Яндекс.Метрики» загружены в Excel.

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

Если у вас Excel версии 2016 и выше

Ничего специально доустанавливать не надо — PowerQuery уже включен в состав Excel. Разница лишь в интерфейсе панели инструментов.

Действовать дальше нужно так:

1. Открываем вкладку «Данные».

2. Жмем кнопку «Из интернета».

3. Вводим адрес сайта с «.csv».

Загружаем в BI-систему на примере PowerBI Desktop

В панели инструментов выбираем «Получить данные» (1 на скриншоте ниже), затем — «Интернет» (2 на скриншоте).

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

Загружаем в GoogleSheet

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

Усовершенствуем сервис доступа к данным

Получаем разные данные из «Яндекс.Метрики» 

Допишем код приложения сайта, чтобы можно было получать различные данные из «Метрики».

Определимся для себя, что при обращении к нашему сайту, например, к странице с именем «daily.csv» по URL-адресу вида «https://analitika.techdomen.ru/daily.csv» должны возвращаться данные об источниках трафика на сайт в динамике, как сейчас. 

А при обращении к странице «prolist.csv» по URL-адресу вида «https://analitika.techdomen.ru/prolist.csv» должны возвращаться сводные данные для глубокой аналитики лендинга (технология, описанная в этой статье).

Рассмотрим код подробнее.

import requests  API_token = 'y0_AgAAAAACO_AIAAk7FQAAAADd2oFFORLi5yKWs6_H8gQAYmrU'  def daily():     API_URL = 'https://api-metrika.yandex.ru/stat/v1/data/bytime.csv'          params = {            'date1': '6daysAgo',     'date2': 'today',     'id': 77344,     'metrics': 'ym:s:visits,ym:s:users',     'dimensions': 'ym:s:TrafficSource',     'group' : 'day',     'filters' : "ym:s:isRobot=='No'",     'limit': 1000     }          r = requests.get(API_URL, params = params, headers={'Authorization':API_token})          t = r.text          t.encode('utf-8')           return t  def prolist():          API_URL = 'https://api-metrika.yandex.ru/stat/v1/data.csv'     params = {             'date1': '2023-02-01',             'date2': '2023-04-04',             'id': 77944,             'metrics': 'ym:s:visits,ym:s:users',             'dimensions': 'ym:s:goal,ym:s:<attribution>TrafficSource,ym:s:<attribution>SourceEngine,ym:s:from,ym:s:deviceCategory',             'filters' : "ym:s:isRobot=='No'",             'limit': 1000     }          r = requests.get(API_URL, params = params, headers={'Authorization':API_token})      t = r.text          t.encode('utf-8')           return t  def application(env, start_response):     try:         if env['PATH_INFO'] == '/daily.csv':             content=daily()         elif env['PATH_INFO'] == '/prolist.csv':             content=prolist()         else:             raise ValueError('Вызов неизвестного URL')                  start_response('200 OK', [('Content-Type','text/html')])         return [content.encode('utf-8')]     except Exception as S:         content=str(S)                  start_response('200 OK', [('Content-Type','text/html')])         return [content.encode('utf-8')]

Строка 3 — сохраним API-ключ для обращения к «Яндекс.Метрике» в переменную.

Строки 5-26 — функция daily(), которая будет возвращать данные «Метрики» об источниках трафика на сайт в динамике.

Строки 28-47 — функция prolist(), которая будет возвращать данные «Яндекс.Метрики» о достижении целей для формирования воронки пролиста лендинга или сайта.

Отмечу, что в строках 32 и 33 для примера указано, что необходимы данные за период с 01.02.2023 по 04.04.2023, но вы можете исправить на относительные даты. Кроме того, в строке 36 можно добавить дополнительные группировки, например UTM-метки. Подробнее о том, как сформировать запрос к API «Яндекс.Метрики», смотрите в материале

Строка 49 — рассмотрим, что изменилось в коде приложения сайта (в функции application).

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

Строки 51-54 — анализируем значения в переменной окружения “PATH_INFO”, которая содержит имя страницы, к которой произошло обращение:

Строки 51-52 — если обращение к странице «daily.csv» — вызвать функцию daily() и вернуть результат этой функции (то есть данные «Яндекс.Метрики» об источниках трафика на сайт в динамике). 

Строки 53-54 — если обращение к странице «prolist.csv» — вызвать функцию prolist() и вернуть данные о достижении целей «Яндекс.Метрики».

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

Строки 54-56 — я называю «заглушкой» — это обработка ситуации, если кто-то обратится к странице вашего сайта, для которой нет «связанной» функции.

Важно! Теперь для получения данных в электронную таблицу или BI-систему необходимо обращаться не просто к сайту по адресу вида «https://analitika.techdomen.ru», а обязательно указывать страницу!

Так, для получения данных о достижениях целей «Яндекс.Метрики» в качестве URL-адреса источника данных необходимо будет обязательно указать адрес вида «https://analitika.techdomen.ru/prolist.csv».

Должны появиться выглядящие следующим образом данные:

Сделаем код более универсальным 

Это нужно, чтобы получать данные из любого счетчика «Яндекс.Метрики» за любой период времени, не меняя код приложения сайта на Python.

Важно! Речь идет о получении доступа о посетителях сайтов только из счетчиков «Метрики», к которым у вас есть доступ и к которым открыт публичный доступ к статистике. 

В рассматриваемых примерах кода зафиксированы («прибиты гвоздями») номер счетчика «Яндекс.Метрики» (id) и диапазон дат, за который извлекаются данные (date1, date2). 

Усовершенствуем код — сделаем так, чтобы номер счетчика и диапазон дат передавались в виде параметров при обращении к сайту. Для получения данных надо будет указывать URL-адрес в виде «https://analitika.techdomen.ru/daily.csv?ids=XXXXXX&date_from=YYYYYY&date_to=ZZZZZZ», где:

“ids”, “date_from” и “date_to” — обозначения параметров;

“ХХХХ” — номер счетчика «Яндекс.Метрики»;

“YYYYYY” — дата, начиная с которой необходимо получить данные;

“ZZZZZZ” — дата, до которой необходимо выгрузить данные.

Обе даты необходимо передавать в виде точной даты (например, «2023-07-20» соответствует 20.07.2023) или обозначениями, «понятными» «Метрике». Например, «today» соответствует текущей дате, «6daysAgo» — 6 дней назад, считая от текущей даты. Подробно об обозначениях дат или периодов времени можете почитать здесь.

Допишем код.

import requests from urllib.parse import parse_qsl  API_token = 'y0_AgAAAAACO_AIk7FQAAAADd0kEPGUm2oFFOWs6_H8gQAYmrU'  def daily(ids_p,date_from_p,date_to_p):     API_URL = 'https://api-metrika.yandex.ru/stat/v1/data/bytime.csv'          params = {            'date1': date_from_p,     'date2': date_to_p,     'id': ids_p,     'metrics': 'ym:s:visits,ym:s:users',     'dimensions': 'ym:s:TrafficSource',     'group' : 'day',     'filters' : "ym:s:isRobot=='No'",     'limit': 1000     }          r = requests.get(API_URL, params = params, headers={'Authorization':API_token})          t = r.text          t.encode('utf-8')           return t  def prolist(ids_p,date_from_p,date_to_p):          API_URL = 'https://api-metrika.yandex.ru/stat/v1/data.csv'     params = {             'date1': date_from_p,             'date2': date_to_p,             'id': ids_p,             'metrics': 'ym:s:visits,ym:s:users',             'dimensions': 'ym:s:goal,ym:s:<attribution>TrafficSource,ym:s:<attribution>SourceEngine,ym:s:from,ym:s:deviceCategory',             'filters' : "ym:s:isRobot=='No'",             'limit': 1000     }          r = requests.get(API_URL, params = params, headers={'Authorization':API_token})      t = r.text          t.encode('utf-8')           return t  def application(env, start_response):     try:         ids=-1         date_from=''         date_to=''                  query_string=env['QUERY_STRING']                  x=parse_qsl(query_string,encoding='utf-8')                  for y in x:             if y[0] == 'ids': ids=y[1]             if y[0] == 'date_from': date_from=y[1]             if y[0] == 'date_to': date_to=y[1]                  if ids == -1: ids=77963         if date_from == '': date_from='6daysAgo'         if date_to == '': date_to='today'                  if env['PATH_INFO'] == '/daily.csv':             content=daily(ids,date_from,date_to)         elif env['PATH_INFO'] == '/prolist.csv':             content=prolist(ids,date_from,date_to)         else:             raise ValueError('Вызов неизвестного URL')                  start_response('200 OK', [('Content-Type','text/html')])         return [content.encode('utf-8')]     except Exception as S:         content=str(S)                  start_response('200 OK', [('Content-Type','text/html')])         return [content.encode('utf-8')]

Строка 2 — подключаем библиотеку parse_qsl для быстрой работы с параметрами, передаваемыми через URL-строку. Если она не установлена, запускаем на виртуальном хостинге терминал и выполняем команду pip install parse.

Строки 6 и 29 — укажем три параметра для каждой функции:

ids_p — номер счетчика «Яндекс.Метрики»;

date_from_p — дата, начиная с которой необходимо получить данные;

date_to_p — дата, до которой необходимо выгрузить данные.

В строках 11-13 и 33-35 вместо ранее фиксированных значений укажем соответствующие параметры функции.

В строках 52-54 создадим переменные, которым присвоим значения по-умолчанию (ниже прокомментирую, зачем).

Строка 56 — получаем строку параметров URL, полученную при обращении к нашему сайту.

Строка 58 — превратим строку параметров в словарь.

Строки 60-63 — перебираем в цикле все полученные параметры URL-строки и извлекаем:

ids — номер счетчика «Метрики»;

date_from — дата, начиная с которой необходимо получить данные;

date_to — дата, до которой необходимо выгрузить данные.

Строка 65 — проверяем, был ли передан номер счетчика в строке с параметрами. По сути это логический контроль. В приведенном примере кода, если в строке параметров не передан ids, считаем, что необходимы данные из счетчика с номером 77963. Это дополнительная полезность, позволяющая не указывать номер счетчика в URL-строке, если нужны данные всегда по одному и тому же счетчику. 

Но вы можете дописать код: например, если в URL-строке нет параметра ids — «завершать код с ошибкой».

Строки 66-67 — аналогично проверяется, переданы ли параметры с какой по какую дату извлекать данные, и если не переданы — присваивать значения по умолчанию.

Таким образом можно получать данные, обращаясь по адресу вида https://site.techdomen.ru/daily.csv без всяких параметров — будут возвращаться данные счетчика 77963 за период «6 дней назад, считая от текущей даты, до текущей даты».

А можно с указанием параметров, например:

https://site.techdomen.ru/daily.csv?ids=8766&date_from=2023-01-01&date_to=2023-07-01

В таком случае будут возвращены данные счетчика 8766 за период с 01.01.2023 по 01.07.2023.

Полезные дополнения

В чем полезность такого подхода (создание сервиса доступа к данным в виде сайта на Python на виртуальном хостинге)

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

Получив по API данные «Яндекс.Метрики», вы можете предобработать их средствами Python любым нужным вам способом.

2. Имея единый источник данных, вы можете анализировать и визуализировать данные из «Яндекс.Метрики» в любой электронной таблице или BI-инструменте.

3. Вы можете делиться своими данными «Метрики», просто передавая ссылку на URL коллегам. При этом вы можете работать одновременно с одними и теми же данными.

4. Можно дописать Python-код и настроить cron на Web-сервере для онлайн-мониторинга и уведомления о значимых событиях на сайте (например, в Telegram-бот). 

В чем недостатки

1. Понадобится компетенция «как создать сайт на Python на виртуальном хостинге». 

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

Да и сама эта компетенция весьма полезна.

2. Виртуальный хостинг стоит денег.

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

175 рублей — это много или мало? Все, конечно, относительно… Для меня качественная и оперативная аналитика важнее.

_____________________________

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


ссылка на оригинал статьи https://habr.com/ru/companies/digitalleague/articles/751504/

Взломают ли 2048-битный RSA к 2030 году

Я пришёл к выводу, что 2048-битный криптографический алгоритм RSA достаточно безопасен, когда работал над недавним проектом. Канада1), в которой я живу, да и другие страны2), заявили, что 2048-битный RSA будет считаться потенциально небезопасным после 2030 года. Минимальная длина надежного ключа — это 3072 бита. Осталось всего семь лет до нового стандарта.

Откуда взялся 2030 год?

Я практически уверен, что мысль о конце эпохи в 2030-м почерпнута из научной статьи 2004 года Арьена Ленстры3). Он предложил такую датировку сроков истечения безопасности:

Длина ключа в битах

Консервативная оценка года

Оптимистичная оценка года

1024

2006

2006

1280

2014

2017

1536

2020

2025

2048

2030

2040

3072

2046

2065

4096

2060

2085

8192

2100

2142

Сроки жизни распространенных длин ключей RSA в битах. Таблица 4 из Key Lengths

Дата отсечки по 2048-битному ключу при консервативной оценке — 2030 год. Просто, прямолинейно и определенно. Отличная таблица для долгосрочного планирования…

Прогноз Ленстры в основном базировался на двух наблюдениях:

  • Производительность вычислительных технологий удваивается каждые 18 месяцев;

  • Благодаря совершенствованию ПО рост эффективности факторизации удваивается каждые 18 месяцев; 

С 2004 по 2030 год пройдёт 26 лет или 312 месяцев, произойдёт 35 удваиваний. То есть увеличение мощности в экспоненциальном представлении составит 2×2×2×2×2×2×2×2×2×2×2×2×2×2×2×2×2×2×2×2×2×2×2×2×2×2×2×2×2×2×2×2×2×2×2, или 235. Иными словами, по прогнозу, к 2030 году мощность вырастет в 34 359 738 368 раз, то есть примерно в 34 миллиарда (34×109) раз. Это значение показывает, насколько неуязвимым было 2048-битное шифрование RSA в 2004 году.

Вот как этот рост выглядит на графике:

Удвоение каждые 9 месяцев с 2004 по 2030 год

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

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

Положить на первую клетку шахматной доски одно зерно. На следующую пустую клетку положить удвоенное количество зёрен (2). Затем удвоить это количество зёрен (4) на следующей пустой клетке. Если заполнить все 64 клетки шахматной доски, каждый раз удваивая количество, то получим количество пшеницы, в тысячи раз превышающее ежегодное производство пшеницы на всей планете. Очевидно, что этот процесс невозможно было выполнить. Этому мешает экспоненциальная природа роста4). “Экспоненциальный рост не может продолжаться вечно, потому что поглотит всё” — Карл Саган, Миллиарды и миллиарды: Мысли о жизни и смерти на краю тысячелетия

Теперь, когда мы видим, как спрогнозирован экспоненциальный рост мощности RSA5), важно определить, возник ли предел, который бы помешал этому прогнозируемому росту.

Как на самом деле происходит развитие?

Удобнее всего здесь рассмотреть длину чисел, которые уже разложили на множители. Пока самое большое число длиной 829 битов6) было разложено на множители в 2020 году. В конце 2003 года было разложено на множители 576-битное число. 

Я не стал обращать внимание на тот факт, что рост мощностей факторизации после 2009 года замедлился, и добавил линейную экстраполяцию на основании рекордов факторизации на весь прогнозируемый интервал. Однако результат (1024 бита к 2030 году) меня всё равно разочаровал. Если бы мощности росли экспоненциально, можно было бы ожидать более четкого тренда. Такого тренда роста недостаточно, чтобы считать, что 2048-битный RSA окажется под угрозой к 2030 году.

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

Насколько справедливы сейчас базовые гипотезы?

Давайте рассмотрим две базовые гипотезы, на которых основан прогноз:

Производительность алгоритмов факторизации

Гипотеза заключается в том, что рост эффективности факторизации вследствие совершенствования ПО удваивается каждые 18 месяцев.

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

Фаза

Рост производительности

Относительная сложность

Самое очевидное

Большой

Низкая

Труднодоступное

Низкая

Высокая

Новый алгоритм

От маленького до очень большого

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

Именно так и происходило с алгоритмами факторизации в 80-х и 90-х7). За алгоритмом факторизации методом непрерывных дробей последовал метод квадратичного решета, который, в свою очередь, сменил общий метод решета числового поля (number field sieve, NFS). На момент публикации статьи Ленстры казалось, что его метод факторизации при помощи эллиптических кривых сможет превзойти по мощности алгоритм NFS.

За 19 лет с 2004 по 2023 год и при гипотезе об удвоении каждые 18 месяцев мы бы получили прогнозируемый рост производительности алгоритмов в 6502 раз. Сложно найти точные показатели настоящего роста производительности алгоритмов за этот интервал, потому что он смешан с аппаратной производительностью. Система CADO-NFS8) заявляет о росте в 3,2 раза с версии 1.1 до версии 2.3.0 на уровне 512 битов (RSA-155). Исследователи, поставившие последние рекорды факторизации9) (829 битов), утверждают, что производительность увеличилась в 3-4 раза. Даже если комбинировать этот рост (не уверен, приемлемо ли это), мы получаем рост производительности в 12 раз, что сильно отличается от спрогнозированных 6502 раз.

Метод эллиптических кривых так и не превзошёл алгоритм NFS при факторизации уровня RSA 2048. Алгоритм NFS так и не был превзойдён никаким другим алгоритмом. Поэтому спустя 27 лет после своего изобретения он всё ещё остаётся лучшим. Наверно, это и стало причиной существенного снижения роста производительности алгоритмов.

История компьютерных вычислений показывает, что обычно происходит быстрый всплеск прогресса производительности алгоритмов, когда становится возможным выполнение определённой задачи, а затем следует долгий период постепенного совершенствования. Очень хорошим примером является сортировка. Алгоритмы mergesort, quicksort и heapsort были изобретены, соответственно, в 1945, 1959 и 1964 году. Они по-прежнему активно используются для сортировки больших списков значений. В ретроспективе кажется, что почти то же самое происходит в мире алгоритмов факторизации. Сложность здесь высока (CADO-NFS содержит сотни тысяч строк кода), поэтому мы, скорее всего, находимся в фазе «труднодоступное». На данном этапе, похоже, нет причин ожидать спрогнозированного экспоненциального роста производительности алгоритмов факторизации (в 165140 раз), необходимого для того, чтобы представлять угрозу 2048-битному RSA к 2030 году.

Производительность вычислений

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

Эта гипотеза известна под названием «Закон Мура»10). Сегодня стало модно говорить, что закон Мура уже мёртв. Это и правда, и неправда.

Существует две версии закона Мура. Версия с удвоением каждые 18 месяцев относится к вычислительной мощи и применима к нашим рассуждениям. В исходном виде закон Мура относился к количеству транзисторов на подложке определённого размера; сегодня принято, что в среднем оно удваивается каждые 24 месяца. Закон 24 месяцев, связанный с количеством транзисторов, по-прежнему актуален (но частота примеров быстро снижается). Мёртв именно закон об удвоении производительности каждые 18 месяцев. А на нём основывается прогноз о 2030 годе…

Если удвоить количество транзисторов на подложке определённого размера, то если энергопотребление этих новых транзисторов будет вдвое меньше энергопотребления старых, тогда подложка будет излучать то же количество тепла. Закон масштабирования Деннарда подтверждает справедливость этого утверждения. В противном случае, каждое удвоение транзисторов повышало бы количество тепла на той же площади. И с этим теплом мы бы скоро перестали справляться. Версия закона Мура с удвоением производительности за 18 месяцев зависит от справедливости закона Деннарда, однако он уже не работает, поэтому закон Мура о 18 месяцах мёртв.

На этом графике показан пример с процессорами Intel:

Из статьи The death of CPU scaling: From one core to many — and why we’re still stuck

… основанной на The Free Lunch Is Over — A Fundamental Turn Toward Concurrency in Software

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

Вот и он, физический предел, мешающий экспоненциальному росту. Оглядываясь назад, можно увидеть, что этот предел уже мешал экспоненциальному росту в 2004 году, когда был сделан прогноз. Неподходящее время для прогнозов, но это сильно упрощает нашу задачу. Экспоненциального роста вычислительных мощностей с 2004 по 2023 год не было. И очень маловероятно, что такой рост произойдёт за семь лет перед 2030 годом.

Какова ситуация сейчас?

Как выглядит ситуация со взломом 2048-битного RSA сегодня, в 2023 году?

Лучший известный нам алгоритм, который можно использовать в самых мощных изготавливаемых нами компьютерах — это NFS. Поэтому мы возьмём его.

Какую вычислительную мощь мы можем привлечь? В качестве сильно преувеличенного примера можно использовать сеть майнинга Bitcoin. Это распределённая сеть, занимающаяся взломом криптографической функции с помощью поиска брутфорсом. Поэтому это будет достаточно неплохой пример, схожий со взломом RSA.

Майнинг Bitcoin — это процесс, зарабатывающий деньги для субъекта, исполняющего систему майнинга. Эта финансовая мотивация создала ситуацию, при которой сеть майнинга разрослась до огромных размеров. Финансовый стимул очень чувствителен к стоимости электричества. Поэтому системы майнинга спроектированы настолько энергоэффективными, насколько это возможно. В этой ситуации крайне актуален закон Деннарда. Создающее проблемы тепло начинается с дорогого электричества. Даже несмотря это отчаянное стремление к энергоэффективности, по оценкам, сеть майнинга Bitcoin в 2021 году потребляла 1/200 (0,5%) от электричества, генерируемого на всей планете11). Это превращает сеть в хороший верхний предел того, что можно делать втайне. Если бы какое-то государственное агентство исследования сигналов нарастило бы такую вычислительную мощь, мы бы смогли узнать это, просто посмотрев её счета за электричество. Потребление электричества на уровне целой страны невозможно было бы скрыть.

Представим, что нам волшебным образом удалось перенаправить вычислительную мощь всей сети майнинга Bitcoin на взлом одного 2048-битного ключа RSA. Для этого нам нужно будет соотнести то, чем сейчас занимается сеть, с алгоритмом NFS. Я буду сравнивать сопоставимое соотношение, разработанное в RFC376612). Оно основывается на ситуации, актуальной на 2004 год, но лучшего нам, похоже, не найти. Выполняемые сетью Bitcoin операции требуют приблизительно того же количества вычислений, что и используемые в качестве справочных в RFC376613). По RFC3766 для взлома 2048-битного RSA потребовалось бы 9,01×1030 криптографических операций. Сеть майнинга Bitcoin недавно достигла частоты 1,24×1028 операций/год14).

То есть воспользовавшись мощью самой большой сети, занимающейся взломом криптографических операций, нам бы понадобилось 9,01×1030/1,24×1028 лет для взлома одного ключа RSA. Это даёт 727 лет. Если бы волшебным образом смогли создать достаточно оборудования для взлома ключа RSA за год, то нам бы понадобилось 727/200, или в 3,6 раз больше электричества, чем генерируется на планете.

Так мы только сравнили объём вычислительной мощи, необходимый для взлома 2048-битного RSA, с вычислительной мощью сети майнинга Bitcoin. Однако выполняемые сетью Bitcoin операции требуют очень мало памяти, а алгоритму NFS нужны огромные объёмы памяти. В 2004 году Р.Д. Силверман отверг заявление о надвигающейся угрозе компрометации 1024-битного RSA. В частности, он сказал, что алгоритм NFS имеет этап (приведение матрицы), требующий большой вычислительной мощи, тесно связанной с большим количеством памяти. На основании этого утверждения он предсказал, что 1024-битный RSA не будет публично взломан до 2030-х. Пока этот прогноз кажется верным. Также он сказал, что для 2048-битного RSA потребуется 1018 байтов памяти на этап приведения неразложимой матрицы15). Это миллион терабайтов — невообразимый объём находящейся в одном месте памяти, более-менее тесно связанный с достаточной вычислительной мощью. К слову о памяти: скорость DRAM сильно отстаёт от скорости процессоров (примерно в сотню раз меньше), а алгоритмы просеивания решетом, скорее всего, очень неудобны для кэширования. Поэтому мысль о том, что вычислительная мощь сети Bitcoin сможет взломать один 2048-битный ключ RSA всего за 727 лет, безнадёжно оптимистична.

Очевидно, что 2048-битный RSA находится далеко за пределами возможностей современных технологий с лучшим из алгоритмов (NFS)…

Будущее

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

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

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

Квантовые вычисления

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

Если бы кто-то изобрёл такой компьютер, то RSA 2048 сразу же можно было взломать тривиальным образом. RSA 3072 тоже можно было бы тривиально взломать. То же самое относится к RSA 4096 и 8192. Очевидно, что угроза сейчас только гипотетическая, но это служит примером ситуации, когда обычное увеличение длины ключа не обеспечит никакой реальной ценности. Многократно увеличивая размеры ключей, мы делаем ставку на то, что будет ровно таким, чтобы смочь взломать устаревшую длину ключа, но не взломать актуальную. Это кажется маловероятным.

Новые угрозы обычно принимают другую форму, нежели старые…

Заключение

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

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

Эта цитата взята из ранее показанной таблицы «Common RSA modulus bit-length life spans» научной статьи Ленстры. Если вы мне не верите, то должны поверить доктору А.К. Ленстре, придумавшему прогноз двойного экспоненциального роста. Мы должны непрерывно ждать и наблюдать. Любые изменения политик должны вноситься в ответ на изменения в производительности алгоритмов и вычислительного оборудования.

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

Другие системы

Пока для удобства чтения мы исследовали только RSA. Давайте воспользуемся приведёнными рассуждениями для краткого изучения некоторых других популярных криптографических систем. В качестве практического примера я использую рекомендации NIST17)18). Период для всех этих рекомендаций NIST: с 2019 по 2030 год (11 лет). Текущая рекомендация о длине ключей вступила в действие в 2019 году, а следующая вступит в действие в 2030 году.

Дискретное логарифмирование

Текущий размер группы: 2048 битов. Следующий размер группы: 3072 бита.

Эту задачу чаще всего используют как основу системы обмена ключами Диффи — Хеллмана.

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

На основе эллиптических кривых

Текущий размер ключа: 224 бита. Следующий размер ключа: 256 битов.

Опыт говорит, что два дополнительных бита ключа эллиптических кривых увеличивают сложность вдвое. То есть за период в 11 лет произошло (256-224)/2=16 удвоений сложности. Это подразумевает, что мощности для взлома эллиптических кривых должны удваиваться каждые 11*12/16=8,25 месяца. Это чуть быстрее, чем допущение о двойном экспоненциальном росте за 9 месяцев, происходящее из гипотезы об удвоении вычислительных мощностей и производительности алгоритмов каждые 18 месяцев. Мы знаем, что для вычислительных мощностей она не выполняется. Мне не удалось найти никаких свидетельств о существующих или ближайших прорывах в программных методах взлома эллиптических кривых, но у меня недостаточно квалификации, чтобы судить об этом, поэтому дальше рассуждать об этом не могу. В условиях отсутствия признаков прогресса в алгоритмах переход с 224 битов на 256 битов будет ненужным.

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

Симметричное шифрование

Текущий размер ключа: 112 битов. Следующий размер ключа: 128 битов.

Вот некоторые из примеров симметричного шифрования: AES, ChaCha20 и Camellia.

В этой области сложность удваивается с каждым новым битом ключа. То есть за период 11 лет произошло 128-112=16 удвоений сложности, а значит, использовались те же ошибочные допущения, что и в случае эллиптических кривых.

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

Для взлома брутфорсом 112-битного ключа в симметричной системе требуется 2112=5,19×1033 криптографических операций. Мы сделаем разумное допущение, что одна операция Bitcoin занимает примерно то же время, что и одна операция симметричного шифрования. Тогда для расшифровки потребуется 5,19×1033/1,24×1028=418 548 лет. Для этого необходимо было бы 418 548/200= в 2092 раз больше, чем текущая генерация электричества по всей планете19).

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

Сноски

1) Cryptographic algorithms for UNCLASSIFIED, PROTECTED A, and PROTECTED B Information — ITSP.40.111

2) Recommendation for Key Management (США), Règles et recommandations concernant le choix et le dimensionnement des mécanismes cryptographiques (Франция)

3) https://infoscience.epfl.ch/record/164539/files/NPDF-32.pdf|Key Lengths: Contribution to The Handbook of Information Security

4) Задача о зерне и шахматной доске

5) Факторизация — это математическая операция, необходимая для взлома шифрования RSA.

6) RSA numbers

7) A Tale of Two Sieves

8) Система CADO-NFS использовалась для установки самого последнего рекорда факторизации (829 битов).

9) Comparing the Difficulty of Factorization and Discrete Logarithm: a 240-digit Experiment

10) Закон Мура

11) Cambridge Bitcoin Electricity Consumption Index, 136.19 TWh annually May 10/2021 | U.S. Energy Information Administration, 25343 TWh annually 2021

12) Determining RFC3766: Strengths For Public Keys Used For Exchanging Symmetric Keys, 0.02*e^( 1.92*cubrt( ln(n)*( ln( ln(n) ) )^2 ) )/300

13) Сеть Bitcoin выполняет половину работы на операцию, поэтому при игнорировании разницы мы получаем консервативную оценку. Допущения: Crypto++ 5.6.0 Benchmarks, Bitcoin: 2 SHA-256, 16 байтов/SHA-256, 15,8 тактов/байт, 3DES: 8 байтов/3DES, 134,5 тактов/байт.

14) Blockchain.com / Total Hash Rate, 3,94×1020 хэшей Bitcoin в секунду на 12 июня 2023 года

15) A Cost-Based Security Analysis of Symmetric and Asymmetric Key Lengths, section VII, subsection A.

16) Решето Эратосфена

17) Keylength — NIST Report on Cryptographic Key Length and Cryptoperiod (2020)

18) Похоже, Канада следует рекомендациям NIST.

19) Стоит заметить, что здесь не является проблемой тесная связь доступной памяти с вычислительной мощью, как в случае RSA.


ссылка на оригинал статьи https://habr.com/ru/companies/mvideo/articles/751506/