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

На Хабре не так много статей, посвященных лайвнесс в биометрических системах, а те, что есть, описывают методы и алгоритмы определения лайвнесс или, проще говоря, принадлежности биометрических образцов живому человеку. Отдадим должное их авторам статьи интересные и содержательные, но что если нас интересует насколько хорошо они работают на данных, не входящих ни в один из открытых дата-сетов? Как понять, насколько лайвнесс действительно плох или хорош и какой следует выбирать при необходимости? В этой статье я опишу подход к выбору пассивного singleshot-лайвнесс (т.е. по одному изображению) лица для Единой биометрической системы.

Зачем нужен лайвнесс

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

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

Удалённая банковская идентификация: от сложного к простому, или Банки, зачем вам биометрия?

Мнение автора основано на устаревшей информации. Конкурс Deepfake Detection Challenge по распознаванию дипфейков на видео действительно существует, он проводится компаниями Amazon, Facebook и Microsoft. В этом году отечественная компания NtechLab заняла третье место среди более 2,2 тысячи команд со всего мира.

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

Ну и да. Уж что-что а социальная инженерия с биометрией упростится просто в разы. Про пин код с карты ещё хоть как-то можно объяснить, что никому не показывать, а вот биометрия Ну откуда бабульки (или даже мне) знать для каких целей меня сейчас снимают: чтобы подтвердить мою личность или чтобы украсть?

Как защитить биометрические данные пользователей от криминального использования

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

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

Новый метод биометрии: биоакустическая подпись

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

Биометрия по лицу, работающая с обычной веб-камеры крайне ненадежна и легко обманывается фоткой. Нормальные лицевые биометрии включают в себя дополнительные средства определения фейков: ИК, 3D и так далее.

Как Сбербанк собирает согласие на обработку биометрии

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

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

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

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

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

Делай по ГОСТу

В июле 2020 года в России введена в действие серия стандартов 58624, устанавливающая термины, классификацию и детальное описание атак на биометрическое предъявление для последующего определения эксплуатационных характеристик. До этого времени не было стандартного руководства для объективной и сопоставимой оценки лайвнесс. Стандарты описывают испытания, объектом которых могут являться:

• подсистема лайвнесс;

• подсистема сбора биометрических данных;

• биометрическая система полностью (контроль качества, распознавание и лайвнесс).

В нашем случае мы поговорим об испытаниях лайвнесс и измерении его способности правильно классифицировать атаки и подлинные предъявления. Для лайвнесс определяют метрики, включающие вероятности ошибок классификации, вероятности отсутствия ответа и метрики производительности. Подробное их описание и расчет можно прочитать в ГОСТ Р 58624.3, мы же приведем их интерпретацию:

• вероятность ошибки классификации предъявления при атаке вычисляют как долю атак, ошибочно классифицируемых как живые люди;

• вероятность ошибки классификации подлинных биометрических предъявлений вычисляют как долю живых людей, классифицируемых как атаки; вероятность отсутствия ответа на предъявление артефакта (ВООПА) вычисляют как долю атаки, на которую лайвнесс не ответил. ВООПА рассчитывается отдельно для каждого инструмента атаки;

• вероятность отсутствия ответа на подлинное биометрическое предъявление вычисляют как долю подлинных предъявлений, на которую лайвнесс не ответил;

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

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

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

У нас был сервер, пять веб-камер, один смартфон и пять сотен фотографий

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

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

Для наших испытаний мы выбрали следующие инструменты атак:

• фотографию лица предъявление распечатанной на цветном принтере фотографии высокого разрешения;

• 2D-маску предъявление распечатанной на цветном принтере фотографии высокого разрешения с обрезанным фоном;

• модифицированную фотографию лица предъявление распечатанной на цветном принтере фотографии высокого разрешения с вырезанными отверстиями под рот, нос, глаза;

• изображение лица на дисплее предъявление выводимой на дисплее фотографии;

• 3D-маску предъявление силиконовой маски или маски, распечатанной на 3D-принтере.

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

На фото внизу представлен стенд по сбору базы на примере атаки с использованием фотографии лица.

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

• Logitech C270;

• Logitech C930;

• Logitech B920;

• Logitech Brio;

• Intel Realsense D415;

• Xiaomi Redmi6.

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

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

Спецификация сервера, на котором проходили испытания:

1) CPU - Intel(R) Core(TM) i5-6600 CPU (4 ядра, 3.30 ГГц, AVX и AVX2 поддерживаются);
2) GPU - Nvidia GeForce GTX 1070 (8 ГБ видеопамяти);
3) ОЗУ - 16 ГБ DDR4;
4) ПЗУ - SSD накопитель SAMSUNG 970 EVO 500ГБ.

Результаты

Я провела испытания 12 методов лайвнесс от независимых вендоров. Все методы, кроме одного, являются пассивными singleshot-методами, для их работы на вход API подаётся RGB изображение лица, на выходе получается liveness score, отражающий насколько предъявленное изображение похоже на подлинное предъявление лица. Один из методов основан на применении 3D-камеры Intel RealSense D415 и, соответственно, на вход принимает RGB изображение и карту глубины изображаемой сцены, а на выходе отдаёт всё тот же liveness score. В таблице ниже приведен перечень измеренных значений эксплуатационных характеристик каждого из протестированных методов лайвнесс.

Исходя из данных таблицы, можно сделать несколько интересных наблюдений. Первое: лучший на сегодняшний день метод показывает вероятность ошибки классификации подлинного биометрического предъявления 1,3% при вероятности ошибки классификации предъявления атаки 1%. Второе: метод, основанный на применении 3D-камеры, оказался хуже большинства решений, не требующих специальных инструментов регистрации изображений.

Также интересно взглянуть на распределение ошибок по инструментам атаки для лучшего решения. Как видно на следующем рисунке, большая часть кривых выглядит как ступенька. Это связано с тем, что метод справился с классификацией с минимальной достоверно измеряемой ошибкой. Например, для случая с силиконовыми масками, где в нашем тесте было минимальное количество образцов атаки, оценка ВОКПА составила 9% и сказать, что действительное значение ВОКПА меньше, мы не можем, для уточнения её значения требуется больше примеров.

Что делать дальше

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

• увеличить количество образцов для каждого вида атаки;

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

• собрать базы данных для оценки конкретных методов лайвнесс.

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

Буду рада ответить на вопросы в комментариях, если они у вас есть.

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

Дискуссии об этичности использования этих технологий стали массовыми после выхода фильма Социальная дилемма (The Social Dilemma) на Netflix,поэтому мы решили с помощью нашей платформы для выявления перспективных рынков и технологий TeqViserразобраться, что же такое технологии убеждения, каковы их возможности, как они используются в ИТ-сфере и какие опасности таят. Кстати, именно результаты мониторинга трендов TeqViser мы использовали при разработке стратегии развития Ростелекома

Что такое технологии убеждения?

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

Дисциплина, изучающая технологии убеждения, называется Каптология (Captology, от аббревиатуры CAPT: Computers As Persuasive Technologies) новое направление науки, находящиеся на стыке информационных технологий и психологии.

Оба термина ввел Би Джей Фогг социолог, философ, специалист по поведению из Стэнфордского университета. Он является основателем и директором Stanford Persuasive Technology Lab, позже переименованной в Behavior Design Lab.

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

Изучать технологии убеждения Б.Дж. Фогг начал еще в 90-е годы прошлого века, а массовое применение они получили благодаря социальным сетям и мобильным приложениям, вернее сказать, социальные сети обязаны своей популярностью технологиям убеждения. Кстати, один из сооснователей Instagram, Майк Кригер, был студентом Фогга.

Почему это важно сейчас?

Формируя ежегодный рейтинг глобальных трендов цифровизации , мы обратили внимание на стремительный рост тренда Persuasive Technology по всем источникам. Особенно это заметно в инвестициях, что означает, что совсем скоро технология станет по-настоящему массовой.

Вот немного статистики из TeqViser:

Всего, начиная с 2014 года, опубликовано более 25 тыс. научных статей и получено около 500 патентов, связанных с технологиями убеждения.

Резкий рост инвестиций, начавшийся в 2019 году, связан с ростом числа приверженцев здорового и активного образа жизни, а также с повышенным вниманием общества к здоровью (физическому и психическому), т.к. основной сферой применения технологий убеждения на сегодняшний день является здравоохранение. Крупнейшей сделкой по этому направлению являются инвестиции венчурного фонда SoftBank в бразильское фитнес-приложение Gympass ($300 млн в 2019 году).

Кроме инвестиций растёт спрос на квалифицированных специалистов. Как правило, наибольший кадровый дефицит наблюдается на прорывных рынках в период зарождения технологий. По количеству вакансий тренд Persuasive Technology сопоставим с трендом Biometric, однако разница между спросом и предложением на рынке труда для технологий убеждений составляет 2270%, а для биометрии 112%. В очередной раз подтверждается востребованность специалистов, обладающих знаниями сразу в нескольких областях и осуществляющих свою деятельность на стыке дисциплин, в данном случае психологии и ИТ.

Как это работает?

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

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

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

Вот основные стратегии убеждения:

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

Вернемся к модели поведения Б.Дж. Фогга и сопоставим её с возможностями цифровых технологий:

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

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

3. Триггер: с помощью алгоритмов по анализу пользовательского поведения можно определить лучшее время для триггера (направления уведомления) и сделать его персонализированным.

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

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

Сферы применения и кейсы

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

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

Nike использует технологии убеждения в своих приложениях Nike Run Club и Nike Training Club, поддерживающих пользователей в занятиях спортом (функционал приложений включает в себя возможность ставить цели, отслеживать свой результат и делиться им, а также различные рекомендации)

MoneyVerbs (США) это платформа для изменения поведения, которая помогает пользователям сформировать правильные денежные привычки и улучшить свое финансовое благополучие.

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

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

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

Какие есть риски?

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

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

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

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

• Зачем это нужно знать, если есть встроенные методы сортировки?

• Зачем изобретать велосипед заново?

• Это нужно, чтобы пройти собеседование, объективно больше незачем это знать

• В "любой движок javascript" работают не дураки, и уже сделали все как нужно

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

Сразу к делу

Как думаете, что произойдет после выполнения данного кода?

Кажется, что ничего странного, но есть нюансы.

Случай номер раз

Сделали задачу, техническое решение, код, unit-тесты. По бизнес-процессу тоже все хорошо. При поверхностном тестировании проблем не нашли. Но когда дело дошло до авто-тестов, начались странности. Конфигурация, которую просчитывал Node.js 10, в основном отдавала корректный результат, но иногда конфигурация отличалась. Что усложняло процесс поиска проблемы, учитывая, что в режиме отладки конфигурация отдавалась всегда корректной. А еще у одних членов команды некорректная конфигурация воспроизводилась, а у других нет. И мы сделали вывод, что в старой версии, наверное, баг, и решили обновить версию на более новую.

После длительного поиска проблемы в коде ошибка не была найдена. Тестирование проекта на разных Node показало, что при запуске проекта на Node, начиная с версии 11, ответ был всегда стабильным. Что и послужило решением этой проблемы. Версия Node была обновлена до 12, и проблема исчезла.

Случай номер два

На этот раз конфигурации отличались уже в разных версиях браузера: в Google Chrome 80 был корректный результат, а в его 69 версии нет. И тут нам стало интересно, почему же конфигурация отличается.

• Увидел, что версии отличаются

• Открыл Release notes Google Chrome

• Обнаружил, что Google Chrome 69 это последняя сборка, где используется 6-я версия V8

• Открыл Release notes V8

• И начал просматривать все статьи между 6 и 7 версией V8

Спустя некоторое время я наткнулся на статью Getting things sorted in V8, в которой говорится, что с 7-й версии V8 переходит на стабильный алгоритм сортировки TimSort, вместо предыдущего нестабильного QuickSort. И тут сразу стало понятно, что никакой магии нет, и все эти баги из-за нестабильной сортировки.

Нюансы сортировки

Сортировка в Node.js 10.22 (движок V8 v6.8) QuickSort.

Как видите, массив из первого скриншота изменил порядок, хотя функция сравнения всегда возвращала 0.

Сортировка в Node.js 14.5 (движок V8 v7.0) TimSort.

На этот раз сортировка уже не изменила данные.

Как дальше жить

И что же в итоге получается? То, что у клиентов могут быть разные результаты работы нашего кода в зависимости от типа сортировки используемого движка JavaScript. И если с Node.js переход на новую версию решит проблему, то заставить всех пользователей сделать то же самое со своими браузерами не получится.

Есть несколько разных решений, которые подойдут для конкретных кейсов. В нашем случае мы решили использовать реализацию алгоритма BlockSort (wikisort). Да, реализация работает медленнее, чем нативная сортировка браузера, но зато теперь я уверен в стабильности результата сортировки там, где это необходимо.

Сравнение разных вариантов решения с нативной реализацией

Мы решили сравнить:

• lodash.sortby

• WikiSort javascript адаптация (WikiSort)

• QuickSort нативная реализация V8 (node.js 10.22.0)

• TimSort нативная реализация V8 (node.js 14.5.0)

В ходе теста было создано 10 массивов со случайным сортируемым значением, в каждом из которых было по 100 тысяч объектов.

Из этого графика можно сделать вывод: после оптимизаций, которые провел движок V8, сортировка WikiSort не уступает нативной реализации TimSort, хотя при первых сортировках разница довольно заметная. А вот lodash я бы не стал советовать.

Посмотреть результаты теста подробнее можно тут sort-test-js, а исходный код тут Tihon-Ustinov/sort-test-js

Где стабильно?

Выводы

• Не верьте в магию JavaScript, у всех странных кейсов в этом языке есть объяснение

• Изучайте технологии, которые вы используете

• Читайте официальную документацию

• Следите за тем, что появляется в новых версиях

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

Привет! Как вы знаете, мы являемся провайдером видеонаблюдения на различных значимых событиях, в том числе и ЕГЭ.

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

Обычно за ходом экзамена следят специальные люди наблюдатели. Они отмечают на портале видеонаблюдения smotriege.ru подозрительное поведение участников ЕГЭ и передают обнаруженные нарушения на модерацию в Рособрнадзор. Если модераторы считают, что нарушение действительно было, то его передают дальше на отработку в пункт проведения экзаменов (ППЭ). Сотрудники ППЭ проверяют каждое такое обращение и решают, как поступить с нарушителем. Например, удалить с экзамена, если он использовал телефон или шпаргалку.

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

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

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

Как работает алгоритм

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

Обучение и сложности

Чтобы алгоритм точно распознавал поведение участников ЕГЭ и корректно фиксировала нарушения, его нужно было обучить на большом массиве данных. Что мы и сделали, собрав видеозаписи с уже зарегистрированными нарушениями на экзаменах за 2018-2019 годы.

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

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

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

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

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

Результаты и планы

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

Сейчас проводятся исследования по улучшению качества работы алгоритма с использованием нейросетевых технологий Human Activity Recognition, архитектур SlowFast, I3D и C3D. Кроме того, мы работаем над увеличением точности алгоритма, его производительности и удобства эксплуатации. Мы уже расширили датасет и добавили данные за 2020 год это поможет нам существенно увеличить точность алгоритма.

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

Тема до сих пор весьма хайповая, и админы, добавляющие в свои резюме словечко DevOps, автоматически рассчитывают на +100К к зарплате. Но мы не про это. Мы хотим рассказать про то, как Ростелеком ИТ внедряет CI/CD & DevOps в энтерпрайзовый ИТ-ландшафт и тяжелые монолитные Legacy-системы.

Первая часть нашего руководства будет про Почему, зачем, как получить на это денег от бизнеса и как получается внедрять CI/CD в десятки проектных команд очень большой компании. Это интересная практическая информация для руководителей ИТ-подразделений и лидов. Вторая часть статьи сугубо инженерная, с описанием прикладных подходов, инструментов и реализаций в зависимости от типа и технологического статуса проекта. И третий блок будет про процесс внедрения в рамках Karma Framework в круге. Поехали!

Ретро. Как всё начиналось

Примерно за год ИТ-разработка Ростелекома в определенном периметре выстроила современную инфраструктуру, основанную на микросервисной архитектуре с развертыванием в кластере OpenShift. Эту инфру мы потом назвали Платформой Цифровых Продуктов, далее ПЦП. Мы позже подробнее опишем состав ПЦП.

Внедрение ПЦП позволило существенно перестроить работу некоторых команд, которые были лоцированы в одном структурном подразделении, с одной точкой управления. Это важно, так как у нас получилось создать в определенной степени технологический и методологический анклав и выстроить новые практики, которые отличаются от остальной корпорации вплоть до того, что мы не поддержали промышленный корпоративный стандарт, и проекты, запускавшиеся в ПЦП, выводились в продакшн на конечных юзеров, но не передавались в общую эксплуатацию. По сути это означает, что продукты НЕ падали вообще и были вне контура эксплуатации. Но с СБ ИТ все договоренности мы имели и нужные мероприятия делали. Плюс несколько команд начали работать в продуктовом подходе по Agile. Разумеется, это стало возможным на определенном классе продуктов и сервисов, что мы запускали. В основном это были относительно легкие фронтовые и middleware-решения, которые легко создавались на основе микросервисов и быстро запускались web-проекты, но с интеграциями в глубокий корпоративный бэкенд. Часть функционала и интеграции запиливались в микросервисы, которые могли использовать другие проекты. Тем не менее, для большой корпорации это был космос оказывается, за 3-6 месяцев можно развернуть для конечных пользователей довольно большой проект или сервис с интеграцией в общий ИТ-ландшафт, опробовать бизнес-гипотезы и модели или просто включить в продуктовую линейку и возможности для клиентов. Сноска для понимания стартаперов: в больших компаниях со множеством региональных биллингов на миллионы людей раньше нельзя было взять и просто за 3-6 месяцев запустить на всю клиентскую базу новый продукт или сервис. Обычно успехом считалось, что это время уходит только на согласование бюджета и ТЗ. А продукт в коде появлялся не ранее чем через год. Еще здесь стоит заметить, что любой стартап через пару лет становится легаси ))

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

И вот тут-то оказалось, что массы это разнокалиберные монолитные легаси-системы глубокого залегания порой циклопического масштаба и набора функционала с историей, уходящей вглубь веков. Класс систем типа АСР, CRM, аналитические системы, хранилища тарифных планов, системы ордеринга в общем, чудный мир OSS/BSS. И вся наша микросервисная архитектура, весь наш DevOps, OpenShift и CI/CD как попытка научить стадо слонов синхронному плаванию. Причем как чисто технологически, так и коммуникационно. Примерно полгода у нас ушло на исследование: насколько вообще применим пусть не микросервисный, а хотя бы компонентный инфраструктурный подход к монолитным системам. Еще сложнее оказалось объяснить и вовлечь ИТ-хэдов проектов и команд в исследование на тему как и главное зачем распиливать на компоненты ядро, где вся логика зашита, например, в пакеты Oracle. Ну допустим. А далее эстафета достигает, достигает, достигает бизнес-заказчиков. И бизнес задает главный вопрос жизни, вселенной и всего такого а зачем мы будем платить за архитектурный рефакторинг систем, которые и так работают?

Аээ 42!

Обычно на этом дискуссия съеживается, и ИТ уходит в офлайн мариновать тему, а архитекторы наслаждаться интеллектом друг друга. Тоже прок и лекарство против выгорания.

Вот на этом этапе и возникают докладчики на DevOps-конференциях с заявлениями, что в энтерпрайзе все это не летит.

Практики внедрения CI/CD&DevOps в Ростелекоме

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

Начали с простых внутрикорпоративных докладов и митапов для различных проектных ИТ-команд и для инхаус-бизнес-заказчиков. Это не дало результат с точки зрения конкретных внедрений CI/CD & практик DevOps в проекты за периметром ПЦП. Но когда ты этим занимаешься больше года, то повестка начинает проникать даже в весьма консервативные команды и дальние регионы компании. Дискурс меняется, и вдруг некоторые коллеги начинают козырять словом Kubernetes как своим! Это определенно шаг вперед.

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

Следующим шагом стала попытка организовать гильдии девопсеров. Это горизонтально организованный коммуникационный формат, где различные проектные команды обмениваются опытом и практиками внедрения DevOps и CI/CD. Различные гильдии были созданы и по другим ИТ-специализациям. Формат какое-то время успешно поработал в части дальнейшего проникновения актуальных практик в различные ИТ-команды. Десятки DevOps-инженеров Ростелекома объединились и выносили задачки и свой опыт в общее тематическое инфополе. Но в итоге данный формат затух. Прежде всего потому, что сложно самоподдерживать мотивацию без целеполагания, оформленного в роадмап. Второй веской причиной затухания гильдий стало то, что этот формат без обязательств так и не позволил на системном уровне внедрять CI/CD в большие проекты и легаси-системы. Как ни крути, но не DevOps-инженеры принимают решения о переформатировании всего технологического и релизного цикла разработки или о рефакторинге.

Примерно за три года миссионерской работы знание и принимаемость темы DevOps и CI/CD в компании вышли за порог отрицания. Проделанная работа в итоге начала все же приводить к тому, что по крайней мере IT-команды стали экспериментировать и что-то использовать из инструментов интеграции и развёртывания, особенно в части тестирования и работы с git. И, наконец, мы начали пробовать внедрять CI/CD на некоторых системах тяжелого класса с монолитным ядром в БД и легаси-кодом, которые оказались по разработке в прямом операционном управлении.

Важный кейс и настоящий профит от ПЦП, от сложившегося подхода к архитектуре, разработке и набора инструментов мы получили для сетапа самого яркого огонька в корпоративном ИТ в России 2020 это экосистемы. Концепция цифровых экосистем с кросс-связанностью и кросс-сервисами по всей продуктовой линейке отлично приземляется на микросервисную архитектуру. И у нас уже была готовая инфраструктура, откуда стали быстро расти экосистемные ростки Ростелекома. А что требуется для таких стейтмент-терминов как цифровая экосистема? Правильно quick win. Чайки, налетайте!

Несмотря на заметные результаты, как ни странно, целевое дело пошло на проектах, которые начинали делать не мы, и проекты пришли к нам в Центр Компетенции digital-разработки Ростелеком ИТ в тяжелом нестабильном состоянии. До 90% ресурса команд уходило на багфикс и латание дыр. Техдолг уходил за горизонт полугода. О функциональном развитии можно было забыть. При этом системы были чрезвычайно важны и нужны бизнесу. Вот здесь и случились прорывы. Возвращаясь к вопросу бизнеса: Зачем мы будем платить за архитектурный рефакторинг систем, которые и так работают?. А вот если системы еле ворочаются и критикал-баги зашкаливают, то разговор с бизнесом из томного превращается в конструктив. У вас как у ИТ-разработки появляется возможность найти у бизнеса понимание, что для сохранения жизнеспособности систем и затем их развития нужно не перепиливать все с нуля (на больших системах часто это вообще невозможно по технологическим или бюджетным причинам), а начать внедрять DevOps и CI/CD процессы с параллельным архитектурным рефакторингом, и начинать нужно с особенно критичных мест в системе и оптимизации релизного цикла. А внедрять можно даже в рамках существующего ресурса команды и бюджета. Мы, например, брали на себя коммиты, что через 3 месяца сократим затраты ресурса команды проекта на багфикс с состояния более 50% AS IS, в котором мы получили проект, до приемлемых в среднем по индустрии менее 20%. При том практически без роста бюджета и состава команды.

В общем, если вы хотите внедрить в энтерпрайзовую легаси-систему DevOps и CI/CD процессы, отдайте ее условным индусам. Верните ее потом себе назад в ужасном состоянии, и у вас появится возможность все исправить модными штучками! Шутка))

Что в итоге сработало. Круги и Karma Framework

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

Но реальный системный результат дало использование формата кругов в рамках Karma Framework. Поскольку Ростелеком ИТ не внешний вендор (тоже важный момент, кстати), а инхаус-разработчик в группе компаний ПАО Ростелеком, то мы работаем не за маржинальность, а за карму. Это не абстракция, а финансовая модель, помноженная на ключевые ценности. И, следуя фундаментальным ценностям, таким как открытость, честность, доверие и партнерство между ИТ и бизнес-заказчиками, мы как ИТ зарабатываем карму, или другими словами свою репутацию и лояльность бизнеса, стараясь делать продукты качественно, быстро и за адекватные бюджеты. Для последнего, собственно, и нужны Devops & CI/CD, с точки зрения технологий и процессов.

Karma Framework это оригинальная практика управления IT в Ростелекоме, которую мы внедряем последние годы, и даже Gartner включил Karma в число передовых мировых управленческих практик. Вполне заслуженно, надо сказать. Про Karma Framework можно рассказывать очень долго на разных уровнях абстракции, но для нашей темы достаточно пояснить, что суть фреймворка в плоской модели управления, где упор делается на самоорганизацию команд и горизонтальное взаимодействие команд посредством кругов. В одном круге с каким-либо предназначением может быть множество людей, представителей команд или целых проектных групп, которые объединены целью выполнить предназначение круга.

В нашем случае предназначение Круга DevOps стало очень простым: внедрить подходы Devops и практики CI/CD на корпоративном масштабе во множество проектных команд и сделать это технологическим промышленным стандартом.

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

А пока же эту бизнесовую по сути часть темы резюмируем двумя блоками обоснования и ответом на вопрос, зачем нужно внедрять Devops&CI/CD и платить за это. Плюс несколько ключевых поинтов.

Для бизнеса:

1. Ускорить Time-2-market вывода продукта в целом или обновлений по линейному развитию легаси.

2. Экономия. Оплатить внедрение Devops&CI/CD и потратить N бюджета, чтобы на горизонте получить экономию в деньгах Y больше N. Или получить прибавку производительности команды, и это окупит N, а потом пойдет время чистоганом. Реальные горизонты наступления эффектов в энтерпрайзе 612 месяцев. Бывает, что и за пару месяцев на проектах с нулевой зрелостью CI/CD можно окупить потраченный ресурс команды.

3. Сократить расходы на оплату ресурса команды, уходящего на багфиксы. В среднем по индустрии на зрелых проектах бизнес готов мириться с 20% затрат на саппорт на третьей ЛТП от бюджета развития. В целевом сокращается до 10%, а иногда уходит почти в ноль. И бизнес получает больше функционального развития.

4. Гораздо более стабильные продукты и системы. Это автоматически ведет к росту бизнес-маркеров типа NPS, экономии на 1-2 линиях, колл-центрах и т.д.

5. Нормализация работы и коммуникации бизнеса с ИТ. Исчезновение ментальных дисбалансов на темы Кто кому должен и кто плохо работает.

Для ИТ:

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

2. Частью идеологии DevOps является перестроение многих процессов как технологических, так и административных. Можно за счет нового технологического инструментария и настроек существенно менять формат работы с эксплуатацией и бизнесом и перестать тратить много сил на ПМИ/ПСИ, документацию, которой невозможно пользоваться, согласования в СЭДах и прочий мартышкин труд и бюрократию. Потому что снимаются риски потери контроля, многие вопросы зон ответственности и нестабильной работы системы.

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

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

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

Важные моменты:

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

2. Devops&CI/CD можно внедрять на любом уровне зрелости продукта и команды. Целый ряд вещей вообще не технологического порядка, а логистического и операционного. Часть инструментов и подходов можно внедрить очень дешево во всех смыслах. Даже в старых, тяжелых легаси-системах.

3. Devops&CI/CD не является синонимом Agile и вполне работает в классическом ватерфоле и фикспрайсовых моделях. Отдельные инструменты и подходы вполне можно использовать: ту же автоматизацию сборки, автотесты, Unit-тестирование, правильную настройку git(а) можно внедрять хоть где.

Однако, CI/CD наиболее эффективен в связке со Scrum или Канбан. По сути, это объединение продвинутых операционной и технологической методик работы с ИТ-конвейером. У нас есть несколько кейсов такого рода. И мы увидели большие перспективы наложения на Канбан-доску с ее этапами разработки, матрицы действий и инструментов CI/CD. Здесь просто золотая жила. И мы уже делаем оригинальный фреймворк о том, как поженить Devops&CI/CD с Канбан. В следующих частях темы Devops&CI/CD в энтерпрайзе мы расскажем и том, как устроена наша Платформа Цифровых Продуктов, и о том, как работают круг и фреймворк внедрения Devops&CI/CD в разные классы систем и проектов.

Ждите новостей от Ростелеком ИТ!

Всем привет! Это третья, завершающая, часть нашего рассказа о том, как Ростелеком ИТ внедряет CI/CD & DevOps в энтерпрайзовый ИТ-ландшафт и тяжелые монолитные Legacy-системы. Первую часть про внедрение CI/CD в десятки проектных команд очень большой компании можно прочитать на Хабре по ссылке здесь. Вторую часть сугубо инженерную, с описанием прикладных подходов, инструментов и реализаций читайте тут.

Сегодня мы расскажем про процесс внедрения в рамках Karma Framework в круге. Поехали!

Круг DevOps катаем квадратное, таскаем круглое

Фреймворк сетапа команд и дальнейшей работы по внедрению CI/CD & DevOps в проектные команды Ростелеком ИТ

Круг DevOps существует в модели управления Karma Framework Ростелекома. Под кругом мы понимаем объединение специалистов вне иерархии, которые взаимодействуют в формате экспертное сообщество. Родительским для нашего круга является круг Развитие цифровых технологий. Поэтому мы работаем с заказчиками в двух операционных моделях:

• Партнерская модель (ИТ владеет бизнес-экспертизой и разделяет цели продукта, ИТ самостоятельно планирует развитие исходя из бизнес-задач);

• Модель Драйвер (ИТ выступает инициатором и драйвером создания высокотехнологичных решений).

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

Итак, круги не являются формальной иерархической структурой. Каждый круг в Karma Framework должен сформулировать свое предназначение, отвечающее целям родительского круга. Для Круга DevOps оно звучит так: Развитие и внедрение технологий и инструментов в области DevOps для повышения эффективности и качества реализации цифровых продуктов.

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

• Лидер круга драйвит тему и организует регулярные встречи в формате онлайн;

• Фасилитатор и секретарь круга помогают держать встречи в заданной повестке, фиксировать договоренности и планируемые активности;

• Эксперты круга помогают командам с обсуждением архитектурных вопросов;

• Делегаты от проектных команд на регулярной основе участвуют во встречах Круга, формируют запросы и ожидания к Кругу, принимают на себя обязательства;

Существует два типа этой роли: Делегат-тимлид/Руководитель проектов (РП) и Делегат-DevOps-специалист. Делегат-тимлид/РП отвечает за внедрение процессов в команде и имеет полномочия на такие изменения как, например, выделение ресурсов на реализацию Continuous Delivery (CI) или изменение архитектуры решения. Делегат-DevOps-специалист наиболее погружен в технические аспекты и напрямую работает с инструментами.

• Наблюдатели приходят в Круг посмотреть и поинтересоваться. В формировании повестки встреч не участвуют, обязательства не принимают;

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

Инструменты совместной работы круга

1. Выделенное пространство в корпоративной базе знаний (например, Confluence.

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

2. Оперативный чат в мессенджере (у нас Телеграм)

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

3. Встречи в формате онлайн-конференции

   Сейчас у нас Zoom, но мы планируем переехать в корпоративный TrueConf. Выделены 4 типа встреч:

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

   • Техническое обсуждение/обмен опытом (по запросу) - проводятся заинтересованным кругом участников для решения конкретного технического вопроса или презентации какого-либо технического решения;

   • Ретроспектива и снятие напряжений (1 раз в квартал) на этой встрече подводятся основные итоги работы круга, проводится обзор снятых напряжений, принимаются решения о дальнейшей эволюции круга;

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

4. Таблица (матрица) соответствия проектов основным стандартам CI/CD опросник, который заполняют команды

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

   • Как именно происходит управление задачами и релизами;

   • Как организован обмен знаниями и документирование;

   • Какие инструменты CI/CD применяются;

   • Как контролируется качество кода;

   • Как мониторятся стенды и собираются метрики.

   • карта развития процессов разработки для каждой из команд.

   Каждый пункт опросника имеет вес 1 или 0 (иногда промежуточные 0.5), проект оценивается в баллах по сумме заполненных строк. Таким образом формируется общая оценка зрелости проекта. На основании таблицы формируется дорожная карта развития процессов разработки для каждой из команд.

Обязательства и продукция круга DevOps включают:

• Формирование и встраивание фреймворка внедрения CI/CD в связке с Agile-фреймворками команд (проектов);

• Создание, накопление, поддержание лучших практик, технологий, инструментов в области DevOps;

• Методологическая поддержка проектов и команд в части DevOps и CI/CD;

• Содействие обмену знаниями в командах;

• Содействие повышению качества продуктов и сервисов;

• Содействие повышению скорости поставки продуктов и сервисов;

• Содействие в оптимизации процессов эксплуатации продуктов и сервисов.

Фреймворк CI/CD мы планируем привносить в команды, которые в рамках общей digital-трансформации переходят на гибкие методики. Как мы уже отмечали, мы не мыслим Agile без современных технологических инструментов управления разработкой и здесь CI/CD является основной конвейера. Но в кровавом энтерпрайзе, где многим legacy-проектам и решениям от 5 до 10 лет, а некоторым и больше, такие переходы даются не сразу и не так легко.

Общая тенденция такова команды сетапятся в Канбан (или SCRUM), в чем нам помогает очень крутой корпоративный тренер, а в качестве Sidecar к гибкой методологии мы проводим аудит состояния DevOps и CI/CD, даем команде рекомендации, делаем совместную дорожную карту и детальные планы изменений в соответствии реальными возможностями команды и архитектурой информационной системы проекта.

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

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

Конечно, DevOps не заканчивается там, где заканчивается Kanban доска. Команды вовлечены как в процесс релиза, так и в процесс эксплуатации продукта.

Фреймворк, разрабатываемый кругом позволяет на всех этапах технологического цикла выстроить эффективные процессы в команде, а также дает необходимые инструменты на каждом шаге. На рисунке ниже отображено соответствие этапов Kanban процесса, DevOps-практик и инструментов CI/CD.

После вступления в круг DevOps и определения текущего уровня зрелости DevOps процессов команда формирует план своего развития, выделяя три блока задач:

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

2. Что можно сделать в разумный срок, за разумный бюджет (внесение небольших архитектурных изменений или новых практик и методик, приносящих ощутимый эффект) - в рамках имеющегося согласованного бюджета проекта. Примеры: внедрить логирование в Elastic Stack или Graylog, обеспечить покрытие всего кода Unit-тестами на определенный процент, внедрить регистрацию и сбор ошибок с продуктивной среды (например, с помощью Sentry), обеспечить автоматизацию UI-тестирования и т.п.

3. Что требует дополнительного согласования бюджета из-за значительных изменений в коде или архитектуре решения. Согласование изменений с бизнесом, исходя из прогнозируемой выгоды и улучшений: ускорение цикла разработки, повышение качества, снижение затрат (стоимости владения). Примеры: переход на микросервисную и Cloud Native архитектуру, контейнеризация приложений и размещение в OpenShift-кластере, внедрение инструментария управления версионностью БД (LiquiBase), и т.п.

Новая команда, которая проходит сетап любого из Agile-фреймворков, получает в комплекте фреймворк запуска CI/CD. Команда выбирает из своего числа делегата, который вступает в круг DevOps.

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

На следующем этапе делегат заполняет матрицу соответствия своего проекта стандартам CI/CD, в которую входят показатели уровня текущих процессов и инструментов, используемых в команде. Мы получаем более-менее объективную оценку текущего уровня развития DevOps в команде, выраженную в баллах.

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

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

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

Условия работы в круге

Принципиальными моментами в работе круга DevOps является следующее:

• Команды приходят в круг добровольно. Никакой обязаловки, никаких принудительных приводов и уговоров;

• Задача круга как экспертного сообщества заработать репутацию (карму) таким образом, чтобы командам было интересно туда приходить. Примеры экспертных кругов с репутацией в Ростелекоме есть это Круг аналитиков или Круг тестировщиков. Круг DevOps еще совсем молодой, мы только начинаем формировать и сообщество, и репутацию и хотим, чтобы у нас было интересно и работа приносила реальную пользу проектам;

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

• У круга нет формальных KPI. Его эффективность измеряется кармой. Карма это прежде всего оценка удовлетворенности работы кругом DevOps со стороны родительского круга Развитие цифровых технологий. Выполняем ли мы свое предназначение? Какой фидбек от бизнеса и команд? Не занимаемся ли ненужной фигней, которая никому не понятна и не приносит пользы?

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

Резюме

Экономия ресурсов и времени происходит на многих участках технологического цикла. На основе нашего опыта на десятках проектов мы в среднем получаем такие результаты:

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

• UAT-тестирование на тяжелых проектах сокращается в среднем с 5 рабочих дней до 2-3 за счет внедрения автотестов (в масштабе 2-3-недельной итерации).

• Подготовка релиза в среднем сокращается с 4-5 дней до 1-2 за итерацию.

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

• На многих проектах вывод в продуктивную среду сокращается с 3-4 часов до десятков минут, делается автоматически и производится днем, что еще несколько лет назад для Ростелекома было просто немыслимым.

• Регрессионное тестирование в среднем сокращается с 3-5 дней до 1-2 за итерацию, а количество ошибок и хотфиксов за счет автоматизации цикла сводится к минимуму.

• Экономия по всему технологическому циклу может достигать 5 рабочих дней всей команды; на месячном релизном цикле это дает +25% производительности команды.

• Не надо бояться разговаривать об изменениях практики разработки с бизнесом и смежными ИТ-службами.

Бизнес умеет считать деньги и смотреть по сторонам, анализируя мировой и российский опыт. Он умеет задавать вопросы А как сделать, чтобы эта фича увидела свет уже в конце квартала?, и ИТ-департаменту нужно быть готовым и ментально, и организационно, и технически обеспечить такую скорость и качество. Именно поэтому в ИТ-стратегию Ростелекома на ближайшие годы включено развитие и внедрение DevOps-процессов, и мы целенаправленно занимаемся этим далеко не простым, но очень полезным и интересным делом.

Привет, Хабр! Меня зовут Владимир, я бизнес-аналитик в офисе данных Ростелекома и занимаюсь развитием отчётности. Компания делает ставку на развитие data-driven культуры. Спрос на данные и аналитику со стороны бизнеса растёт, и соответственно развивается экосистема управления данными, в том числе организационная структура и бизнес-процессы.

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

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

Введение

Нужно бежать со всех ног, чтобы только оставаться на месте, а, чтобы куда-то попасть, надо бежать как минимум вдвое быстрее!, писал Льюис Кэрролл ещё во времена викторианской Англии. А сто лет спустя принципом Черной королевы назвали эволюционную гипотезу, сравнивающую борьбу за выживание с гонкой вооружений. Чем быстрее перемены окружающей среды, тем важнее скорость адаптации. Для организаций это правило работает так же: чтобы оставаться на плаву, нужно быстрее приспосабливаться к изменениям конкурентов, учиться и эффективнее перестраивать процессы.

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

Ситуация

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

В корпоративном центре Ростелекома все профильные направления, работающие с отчётностью, объединены в Офис Данных. Это более двух сотен сотрудников в Москве и регионах, которые занимаются развитием платформы управления данными, работают в направлении глубокого анализа и развитии аналитической отчётности.

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

Развитие отчётности организовано так: за сегментами бизнеса закреплены постоянные команды из 10-30 аналитиков и разработчиков, из которых формируют рабочие группы для отдельных задач. Различий в бизнес-процессах сегментов много и каждый раз в них разбираться непродуктивно. У разработчиков с этим проще, но всё равно хочется сохранять сработавшиеся команды. Командой сегмента руководит фронт-менеджер, который объединяет роль ресурсного менеджера для команды и аккаунт-менеджера для заказчика.

Обычно в работе у фронт-менеджера есть 10-12 задач, с каждой задачей на различных этапах может работать от 2 до 5 человек. Длительность таких задач от нескольких недель до полугода (это очень грубая оценка, чтобы показать масштабы). По каждой доработке требуется создать артефакты: комплект документов, которые будут использоваться сопровождением для работы над инцидентами, и отчётность в JIRA по объёмам трудозатрат, срокам работ и загруженности ресурсов, которая позволяет анализировать эффективность процессов.

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

Поиск решения

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

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

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

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

• погружены в предметную область, как никто другой;

• участвуют в выполнении задачи на всех этапах;

• выполняют интегрирующую роль для команды.

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

Реализация

Дальше мы проектировали и документально оформляли процесс, совмещали с уже существующими операционными процессами, о некоторых из которых уже рассказывали мои коллеги (статьи на Хабре: раз, два). В общем процесс разработки приобрел вид:

Документацию составили в формате методики управления, скорее даже инструкции. Где-то брали собственные наработки, где-то транслировали рекомендации PMBoK на наше организационное окружение. Писали так, чтобы документа было достаточно для выполнения роли РП, и чтобы его мог использовать человек без опыта проектного управления.

Затем, дополнив документ всей сопутствующей мишурой вроде шаблонов, провели обучение и в начале 2020 года запустили процесс в пилотном режиме. Работа ещё не завершена, по части согласованности процессов ещё многое нужно сделать, но определенные выводы уже можно сделать.

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

К плюсам принятого решения можно отнести:

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

2. На коммуникации внутри команды времени тратим не больше, чем тратили раньше;

3. Материалы задач легче использовать повторно, сроки в целом стали более прогнозируемыми.

Трудности:

1. Есть нестыковки с операционными процессами, особенно в нетиповых ситуациях, но это ожидаемо продолжаем шлифовать;

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

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

аналитика даёт больше плюсов, чем создает неудобств.

Вместо эпилога

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

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

P.S. Только не миниРП, пожалуйста :)

Привет, меня зовут Владимир Шилов, я руководитель направления в департаменте анализа данных Ростелекома. В мае 2019 года я пришёл в команду Business Intelligence (BI) и одной из первых задач была реализация отчётности по анализу посещаемости отчетов во всех BI-инструментах, установленных в компании.

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

Какие BI системы наиболее востребованы в реалиях крупной компании;
Какие критерии влияют на внутреннюю популярность решения;
Какие современные тенденции пользовательского поведения можно наблюдать внутри компании и какие вопросы будут стоять перед ИТ-подразделениями в ближайшее время.

С чего всё началось: реализация решения по анализу используемости BI систем

Начну с общего описания ситуации и подходов к сбору информации. У нас в компании целевыми BI-системами являются:

1. Oracle BI
2. Microsoft analysis services
3. Microsoft Power BI
4. Qlik Sense
5. Форсайт

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

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

1. Провести анализ логов BI-систем по запуску отчётов;
2. Спроектировать модель витрины данных;
3. Разработать ETL;
4. Реализовать отчет в Power BI;

Решение получилось примерно следующим:

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

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

Oracle BI

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

На основе второго графика динамики уникальных пользователей можно сделать вывод, что аудитория BI-системы стабилизировалась и сильного роста в 2020 году не наблюдается. Этому есть ряд причин:
Доступ к отчётности требует согласования, а прозрачность процесса предоставления доступа очень низкая;
Новые предметные области появляются очень редко;
Нет возможности создавать дашборды с аналитикой.

Analysis services

Microsoft Analysis services в компании это тоже достаточно распространённый инструмент, что во многом обусловлено удобной для пользователей работой в Excel. Именно этот инструмент получил наибольшее распространение в компании: он даже более популярен в МРФ (макрорегиональных филиалах), чем в корпоративном центре. Это можно увидеть на следующей диаграмме по уникальным пользователям в разрезе территорий за последние 12 месяцев:

Ниже представлены графики динамик по следующим показателям:
Количество используемых уникальных OLAP-кубов за период;
Количество уникальных пользователей.

Рост количества используемых OLAP-кубов за последний год не наблюдается, а рост аудитории в BI-системе нестабильный со значительными всплесками. У такой статистики несколько причин:
OLAP-кубы в основном дорабатываются, а новые кубы появляются очень редко;
BI-система больше предназначена для аналитиков, умеющих работать с данными, и она сложно продается широкой аудитории;
Доступ к отчётности требует согласования с владельцем OLAP-куба.

Power BI

BI-система Power BI от Microsoft появилась самой последней в стеке инструментов компании, но именно к этой системе сейчас приковано самое большое внимание со стороны бизнеса по следующим причинам:
Базовый набор визуализаций имеет хороший дизайн;
Лицензирование осуществляется по ядрам на сервере, отсутствует лицензирование по пользователям;
Скорость разработки отчётов довольно высокая, но стоит отметить, что на полный цикл разработки это не сильно влияет.

Ниже представлены динамики показателей аудитории и количество отчётов, которые она использует:

Стоит отметить, что при относительно низком росте количества используемой отчётности аудитория продолжает расти. Это связанно в большей степени с тем, что доступ к отчётам предоставляется без выделения лицензий на каждого пользователя и изначально нет никаких ограничений по доступу, то есть оформлять заявку не нужно. Уже сейчас наблюдается тенденция перевода отчетов с Qlik sense на Power BI именно потому, что новые пользователи подключаются бесплатно.

Qlik sense

Qlik sense была первой корпоративной BI-системой с возможностью реализации полноценных дашбордов. Именно с Qlik sense связан переход от предоставления табличных данных к графическим визуализациям в компании.
Ниже представлены графики динамик по следующим показателям:
Количество используемых уникальных отчётов за период;
Количество уникальных пользователей.

Казалось бы, перед нами современный BI-инструмент с высоким спросом, в котором можно создавать красивые решения, но сильного роста отчётности по сравнению с Oracle BI и Analysis services мы не наблюдаем. Тут есть несколько причин, влияющие на аудиторию и количество новых отчётов:
Лицензия на одного пользователя стоит существенных денег, и поэтому бизнес отказывается заказывать отчетность в Qlik sense;
Длительный период реализации отчётов от подготовки данных до реализации не позволяет быстро перенести все бизнес-процессы на новый инструмент.

Теперь поговорим про инструменты Self-service.

Self-service инструменты

Qlik sense self-service

В ноябре 2019 для бизнеса мы развернули self-service и предложили бизнесу реализовывать свои отчеты на своих источниках самостоятельно. С точки зрения лицензирования было одно изменение разработчики лицензируются отдельно. С лицензиями пользователей изменений не было по причине того, что сервера были объединены в один кластер и лицензии, соответственно, тоже.
Графики динамик количества запускаемых отчётов и уникальных пользователей в недельной динамике представлены ниже:

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

Power BI self-service

Вот мы и дошли к самому интересному. Power BI self-service появился примерно в то же самое время, что и Qlik Sense self-service, но у данных систем есть одно существенное отличие в лицензировании. Для подключения команды разработчиков от бизнеса в Power BI self-service надо разово заплатить за лицензию на 2 ядра, что примерно равняется 35 лицензиям пользователей в Qlik sense, но лимита на пользователей в Power BI нет.

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

Ещё более наглядно всё выглядит если показать все рассматриваемые системы вместе:

Какие критерии влияют на развитие отчетности?

В части развития отчетности в BI-системах стоит выделить следующие особенности, которые описаны в таблице:

Исходя из результатов нашего анализа именно критерии, описанные в таблице, оказали самое большое влияние как на скорость создания новой отчетности, так и на востребованность отчетности пользователями компании. А ключевым фактором успеха Power BI self-service стала политика лицензирования и его условная бесплатность для разработчиков на стороне бизнеса.

Заключение

Из выше сказанного можно сделать вывод, что ключевыми факторами по использованию отчётности в различных BI-системах являются (расположены по мере уменьшения значимости):
Стоимость подключения новых пользователей, особенно на большую аудиторию;
Длительность полного цикла реализации отчёта от подготовки данных до публикации;
Простота реализации отчётов в BI-системе.

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

Несмотря на то, что у ИТ сейчас нет однозначных ответов на эти вопросы, очевидно, что бизнес уже сделал свой выбор в пользу Self-service инструментов, и на эти вопросы нам придется отвечать. Будем рады присоединиться к обсуждению в комментариях. О том, какие решения мы нашли для self-service контура Ростелекома мы расскажем вам в наших будущих статьях.

Статья подготовлена командой управления данными Ростелекома

Привет Хабр! Мы выложили на YouTube видеозаписи докладов митапа ИТ-сообщества в разных компаниях 21 апреля. В онлайн-формате эксперты ИТ-кластера Ростелекома, а также наши коллеги из Альфа-Банка, Fleetcor, Райффайзенбанка рассказали, как создавать и развивать профессиональные сообщества в ИТ-компаниях.

Пропустили мероприятие? Делимся главными тезисами докладов, а ещё видео и презентациями спикеров. В хронолическом порядке.

#1 Делаем сложное возможным Татьяна Егорова(Ростелеком)

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

Скачать презентацию

#2 Что сотрудники могут изменить под эгидой Гильдии развития ИТ Полина Самсонова (Ростелеком)

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

Скачать презентацию

#3 Рабочие группы и их вклад в развитие системного анализа Алексей Лобзов (Альфа-Банк)

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

Скачать презентацию

#4 Карьерные диалоги Наталья Пешкова (Райффайзенбанк)

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

Скачать презентацию

#5 Внутренние обучения как способ повышения экспертизы сотрудников Анастасия Груздева и Светлана Михеева (Альфа-Банк)

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

Скачать презентацию

#6 Эти неловкие вопросы про комьюнити Татьяна Такташева (Fleetcor)

Резюмирующий доклад митапа в формате глупых вопросов:
- Как организовать комьюнити?
- Как найти ЦА?
- Какую периодичность встреч выбрать?

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

Скачать презентацию

Вместо заключения

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

Полную видеозапись митапа смотрите на YouTube по ссылке.

Всем привет! На связи Антон Баширов, разработчик из ИТ-кластера Ростелекома. Импортозамещение набирает обороты, а российский софт всё глубже проникает в нашу повседневную ИТ-шную сущность бытия. Процессоры Эльбрус и Байкал становятся более востребованными, комьюнити расширяется, но мысли о необходимости портировать весь наш любимый технологический стек на неизведанную архитектуру E2K звучат страшнее рассказов про горящий в пламени production-кластер.

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

Итак, гость в студии база данных Reindexer, разработка нашего ИТ-кластера.

Стоит сказать, почему выбор пал именно на Reindexer, а не другую БД. Во-первых, всеми любимый и известный Postgres уже есть в составе пакетов ОС Эльбрус. Переносить его нет необходимости. Во-вторых, наш гость уже прошел испытания на ARM, следовательно, пришло время ему покорить Эльбрус.

Стоит упомянуть, что Reindexer появился на свет как продуктвыбора между Elastic и Tarantool. Это определенно хочется попробовать завести на отечественном процессоре.

День 0. Знакомство с гостем

Несколько слов про нашего гостя:

Имя:NoSQL in-memory database Reindexer с функционалом полнотекстового поиска
Возраст:на момент испытаний версия БД была 3.1.2
Происхождение:Россия
Место рождения:пытливый ум разработчика Олега Герасимова@olegator99
Место жительства:https://github.com/Restream/reindexer
Место работы:Ростелеком
Строение:основная составляющая C++, имеются примеси из языка Ассемблера и немного CMake
Особенности:- Ассемблерные вставки;
- Много С++11 и C++14;
- Используются корутины.

Деятельность:- Хранение данных в памяти и на диске;
- Выполнение SQL запросов со скоростью 500K queries/sec для PK запросов;
- Выполнение запросов типа full-text search (почти как Elastic, только не тормозит);
- Работа в режиме server и embedded;
- Общение с крутыми парнями: Go, Java, Rust, .NET, Python, C/C++ и (да простит меня Хабр) PHP.

Заскучали? На этом нудная часть закончилась. В эфире рубрика Ээээксперименты!

День 1. А ты думал, в сказку попал?

Для начала попробуем нашего друга собрать из того, что есть.Идем на тестовый сервер Эльбрус 8C с ОС Эльбрус 6.0.1, клонируем туда репозиторий и запускаем CMake.

Хорошие новости, мы нашли компилятор! Новость действительно хорошая, ведь у Эльбруса свой компилятор LCC.

К счастью, создатели Эльбрус сделали LCC полностью совместимым с GCC и наши любимые нативные программки и сборщики смогут чувствовать себя хорошо без особых манипуляций. LCC уже сделал за вас нужные линки:gcc -> /opt/mcst/bin/lcc*.

Но вернемся к нашему гостю и тому, что не понравилось CMake.

В скриптах сборки, в CMakeLists.txt выполняется определение операционной системы и архитектуры процессора, на которой собирается Reindexer. Нужно это для того, чтобы подключать правильные исходники ассемблера, ведь как говорится Write once, run anywhere.

Разумеется, на момент написания скриптов никто не знал про процессоры Эльбрус, поэтому наш скрипт и упал. Исправляем.

Программисты люди ленивые, поэтому:

Попытка 2:

А что так можно было? На самом деле да для того, чтобы завелся CMake, этого было достаточно. Теперь ударим в бубен и запустимmake -j8:

Для тех, кто уже успел поработать с кроссплатформенным софтом, не новость, что С/С++ код с помощью макросов разделяют на платформозависимые секции.

Поэтому, в некоторые места кода Reindexer понадобилось добавить парочку новых условий для__E2K__и__LCC__:

После колдовства с макросами нас ждал монстр пострашнее:

Вот что бывает, когда игнорируешь messages у CMake.

Из-за того, что CMake не нашел подходящих исходников, компилятор не смог найти реализации двух функций:jump_fcontextиmake_fcontext. Про назначение этих функций я расскажу чуть позже, а пока что давайте успокоим нашего гостя и подсунем ему пару пустышек:

Этих операций оказалось достаточно, чтобы Reindexer собрался.

Поздравляю, у вас двойня!

Вот они, наши два долгожданных файла:

# file reindexer_serverreindexer_server: ELF 64-bit LSB executable, MCST Elbrus, version 1 (GNU/Linux

# file reindexer_toolreindexer_tool: ELF 64-bit LSB executable, MCST Elbrus, version 1 (GNU/Linux), dynamically linked, interpreter /lib64/ld-linux.so.2, for GNU/Linux 2.6.33, with debug_info, not stripped

Это можно считать успехом. Мы смогли собрать наш первый Эльбрус-бинарник. Даже два бинарника: reindexer_server и reindexer_tool.

Подведем итоги. Чтобы собрать Reindexer, мы:

• Поправили CMake-скрипты;

• Добавили несколько условий в макросы препроцессора;

• Заглушили ASM функции.

День 3. Наш Гость, попав на Эльбрус, начал подавать признаки жизни

Первый запуск прошел успешно - сервер поднялся, и даже открылся web-ui.

Я привык не останавливаться на достигнутом и решил немного поработать над Reindexer.

Результат меня порадовал - Гость устал и прилег отдохнуть:

Такое поведение наблюдалось только на Эльбрус. На i5 все работало штатно.

Давайте разбираться. Вооружившись отладчиком (gdb кстати под E2K работает прекрасно) и CLion, мне удалось докопаться до истины.

Пару запросов к Reindexer смогли воспроизвести ошибку:

Падает в деструкторе. Интересный момент - упало на free (в данном случае free реализуется через jemalloc). Видимо, здесь идет высвобождение памяти по некорректному указателю. Ошибку эту я исправлял в два этапа:

1. work around - дело в том, что QueryEntry лежит в объекте ExpressionTree, в самом классе примечательного я не нашел, поэтому копнул в сторону родителя. Оказалось, что до вызова деструктора был вызван вот такой копирующий конструктор, в котором есть интересный MakeDeepCopy(), реализованный с помощью библиотечкиmpark-variant.

   Подробнее про expression tree рассказываюттут.

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

   

   Итог - оно заработало.

2. TODO: Исправление тоже есть, но рассказ про него уже выходит за рамки данной статьи. Небольшой спойлер (код из mpark-variant с патчем под e2k):

inline constexpr DECLTYPE_AUTO visit(Visitor &&visitor, Vs &&... vs)#ifdef E2K //Fix for Elbrus    -> decltype(detail::visitation::variant::visit_value(lib::forward<Visitor>(visitor),                                                 lib::forward<Vs>(vs)...))    {     return detail::visitation::variant::visit_value(lib::forward<Visitor>(visitor),                                                 lib::forward<Vs>(vs)...);    }#else    DECLTYPE_AUTO_RETURN(        (detail::all(             lib::array<bool, sizeof...(Vs)>{{!vs.valueless_by_exception()...}})             ? (void)0             : throw_bad_variant_access()),        detail::visitation::variant::visit_value(lib::forward<Visitor>(visitor),                                                 lib::forward<Vs>(vs)...))#endif

День 5. Он ожил! Ну почти

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

Но все это время я упорно игнорировал один компонент.

Помните, как мы убрали завязку на ASM и функцииmake_fcontext и jump_fcontext?

Так вот, ASM исходники в Reindexer нужны для реализации C++ корутин, а эти функции - ключевые для корутин из библиотеки boost/context.

Корутина это функция, которая может быть приостановлена и возобновлена в любой момент. Для реализации достаточно трех основных компонентов:
- функция
- механизм для ее паузы (suspend)
- механизм для возобновления ее с той точки, в которой была сделана пауза (resume).

Реализацию корутин можно увидеть в таких языках и библиотеках, как:

• Libcoro(корутины на C/С++)

• Koishi(тоже корутины, тоже на С/С++)

• Boost(и это тоже корутины, тоже на С/С++, корутин много не бывает!)

• Node-fibers(корутины для NodeJS на базе libcoro)

• Tarantool(fibers на базе libcoro)

• Kotlin(свои корутины, не на C++)

• C++20

• Goroutine

Для наглядности вот скрин теста корутин из Koishi:

Последовательность следующая:

1. Создали корутину, выделили стек, задали функцию;

2. Возобновили корутину - в этот момент вызвалась наша функция;

3. Приостановили корутину с помощьюkoishi_yield здесь мы вернули управление в test1 сразу после строчкиkoishi_resume;

4. Если мы еще раз сделаемkoishi_resumeна нашей корутине мы вернемся на строчку функции cofunc1 сразу после первого вызоваkoishi_yield.

Без корутин не будет работать reindexer_tool, но не можем же мы оставить Reindexer без такой важной конечности. Будем исправлять.

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

Есть несколько вариантов реализовать корутины:

• Вариант 1:написать ASM реализацию. Самый очевидный, но при этом самый сложный вариант. У нас есть в планах попробовать именно этот вариант, так как ASM корутины - самые быстрые.

• Вариант 2: забить. Нет, это не наш путь.

• Вариант 3: использовать библиотеку.

По счастливой случайности Koishi оказалось той самой библиотекой, поддерживающей реализацию корутин с помощью встроенных E2K функций:makecontext_e2k()иfreecontext_e2k().

Там, где стандартная медицина бессильна, в дело вступает генная инженерия.

Для начала внедрим Koishi в организм Reindexer:

Заменим больной орган на здоровый:

Стараемся не повредить то, что уже работает:

Одним из backend-ов Koishi для корутин выступает fcontext (те же самые boost исходники, что в Reindexer). Последуем древней мудрости работает не трогай! и оставим как есть в случае, если у нас не E2K архитектура. Для Эльбруса мы будем использоватьucontext_e2k.c

И вот он, наш мутант с корутинами полностью здоров и функционален (и на amd64, и на E2K):

День 11. Проводим финальные испытания

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

Всего в Reindexer около 300 функциональных тестов, и мне не терпится запустить их все.

Тесты бежали, бежали и не добежали. Один из тестов вызвал Segmentation Fault.

Всему виной оказались вот эти строчки:

struct ConnectOpts {  /* тут тоже код, но он не такой интересный */  uint16_t options = 0;  int expectedClusterID = -1;};

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

Попробуем воспроизвести на изолированном более простом примере.

ASM, настало твое время

Внимание на скриншот:

Ошибка проявляется именно в том случае, когда отсутствуют не проинициализированные поля. Другими словами, если все ваши поля инициализируются при объявлении вы счастливчик, поймавший Segmentation Fault.

Баг заключается в том, что скомпилированное создание структуры выглядит как странныйaddd. Именно эта строчка и вызывает segfault. Кстати, если вместоbool anyField = falseнаписать простоbool anyField, то код совершенно другой и ошибки нет.

Семь бед, один ответ обновитесь!

Разгадка тайны оказалась проста. На момент работы с Reindexer последней версией компилятора LCC была v.1.25.16, однако в состав пакетов ОС Эльбрус по умолчанию входит 1.25.14, на котором я и запускал тесты. Добрые люди из сообщества подсказали нам, что уже в 15 версии данный баг был исправлен. Я решил обновиться на 16-ую и посмотреть, что будет.

Вот что нам принес новый компилятор LCC v.1.25.16:

C++ код такой же, однако ASM совсем другой, и что самое главное он работает! Последовательно (заранее прошу прощения за мой ломаный asm-русский переводчик):

1. gestp - выделяем стек и кладем его в %dr3

2. setwd - задаем текущее окно в регистровом файле

3. setbn - задаем подвижную базу регистров в текущем окне регистрового файла

4. addd - кладем "дно" стека (стек размером 0x20) в %dr2

5. addd - выделяем на стеке нашу структуру

6. ldb - достаем из констант наш false и кладем его в %r5

7. stb - кладем наш false из регистра %r5 в наше поле anyField1

8. addd - подготовили локальный указатель на структуру для вызова метода

9. addd - передаем указатель в базовый регистр для передачи при вызове anyMethod (в anyMethod мы достаем указатель из регистра %dr0)

10. disp - подготавливаем регистр перехода на anyMethod

11. call - вызываем anyMethod

Дальше все просто пересобрать, перезапустить, обрадоваться.

Тесты прошли успешно, и теперь у нас есть полностью рабочий и протестированный Reindexer на Эльбрусе.

На этом все ?

На самом деле нет. Сейчас мы смогли:

• собрать Reindexer Server

• запустить Reindexer Server

• собрать Reindexer Tool

• запустить Reindexer Tool

• переписать кусочек Reindexer Tool

• уронить Reindexer и поднять его

• добиться 100% проходимости Reindexer тестов

Мы научились:

• собирать C++ софт на Эльбрус

• переписывать C++ софт под особенности и отличия Эльбрусов

• разбираться в ASM E2K

• превозмогать трудности

• разбираться в C++ корутинах даже на Эльбрусе

Что в планах:

• корутины на ASM E2K (может быть даже сравнить fcontext ASM на i5 и ucontext/ASM на E2K)

• оптимизировать Reindexer под архитектуру Эльбрус

• перенести еще несколько интересных приложений на Эльбрус

• дополнить базу библиотек и пакетов Эльбрус

• организовать E2K инфраструктуру и песочницу

Что же можно сказать про Эльбрус со стороны простого разработчика?

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

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

Привет, меня зовут Фахридин Джамолидинов, я специалист департамента тестирования в Ростелеком ИТ. Занимаюсь автоматизацией тестирования основного сайта компании rt.ru и сегодня я расскажу, как про мы внедрили тестирование скриншотами, или как помочь автотестам видеть ошибки.

Наш сайт это не только витрина для информирования клиентов и продаж услуг и товаров для сегментов B2C, B2B и B2O, он ещё предназначен для обслуживания текущих клиентов: FAQ, чат, формы обратной связи, платежные формы и т.п.Он постоянно обновляется, и каждый раз после выпуска новой версии нужно проверять сотни страниц с богатым, динамичным UI на работоспособность в браузерах и адаптивность вёрстки.

Конечно же на этапе разработки применяется практика design review со стороны наших продуктовых дизайнеров, но нет-нет да проблемы всплывали: где-то элементы перекрываются, съезжаются, не сохраняется единый стиль. Осознавая, что ручное регрессионное тестирование существующего UI превращается в кошмар и отнимает кучу времени, мы решили автоматизировать данный процесс.

Как всё начиналось

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

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

Итого, что нам требовалось:

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

• проверка на адаптивность (десктоп 1920px, планшет 768px, мобила 360px);

• поддержка минимум двух браузеров: Chrome и Firefox;

• игнорирование и скрытие элементов (групп элементов) при сравнениях;

• удобочитаемый отчет с подсветкой отличий.

В качестве стека технологий было решено использовать то, на чём ранее были реализованы функциональные тесты:

Java основной язык программирования;
TestNG фреймворк автоматизации тестирования;
Maven сборщик;
Selenide обертка над Selenium, которая упрощает написание веб автотестов;
Selenoid GGR сервер-балансировщик для запуска изолированных браузеров в Docker контейнерах;
Allure фреймворк для создания отчётов автотестов и плагин ScreenDiff;
aShot библиотека для попиксельного сравнения изображений.

Благодаря балансировщику Selenoid GGR (Go Grid Router), в котором настроено распределение на несколько машин, мы имеем возможность поддержки нескольких браузеров (при необходимости: нескольких версий), плюс запуск тестов (изолированных браузеров) в параллель (~40 потоков).

В этой статье мы покажем как работает автотестирование по скриншотам будем акцентировать внимание на функционал aShot (кстати, спасибо ребятам из Яндекса за такие полезные инструменты как aShot и Allure) и на самом процессе.

Как это работает

Тесты условно разбиты на две группы:

• fullscreen страницы целиком (с прокручиванием);

• element(s) отдельный элемент (группа элементов)

Каждая из групп представляет из себя data-driven тесты, т.е. каждая страница, элемент (группа элементов) это отдельный параметризованный тест на основе DataProvider, а вся задача сводится к сравнению двух скриншотов. Например, регресс верстки списка Landing Page, в виде схемы выглядит так:

Избавляемся от динамики

Динамика в основном проявляется в виде:

• каретки в полях ввода, которая мигает (может пропасть или появиться);

• CSS Transition и Animations;

• видео с автопроигрыванием и ряд других моментов.

Там, где есть возможность отключаем (инъекцией CSS):

Каретку делаем прозрачной (задаем значениецвета = transparent). Таким образом она всегда будет невидимой и не будет влиять на результат. CSS Transition обнуляем transitions-delay и transition-duration. CSS Animation обнуляем animation-delay, animation-duration и ставим состояние анимации в паузу, устанавливаяanimation-play-stateвpaused.

*, *::after, *::before {    caret-color: transparent !important;    transition-delay: 0s !important;     transition-duration: 0s !important;    animation-delay: 0s !important;     animation-duration: 0s !important;    animation-play-state: paused !important;    overflow: hidden; // Опционально скрываем полосу прокрутки}

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

Проверяем на адаптивность

Если с десктоп браузером всё понятно, с планшетом и мобилой встал вопрос, как проще эмулировать браузер. Было решено, что пока достаточно использовать фичу вебдрайвера mobileEmulation. Пример скрипта поднятия вебдрайвера Chrome с включением этой опции, в режиме планшета и выбором девайса = iPad:

@Override    public WebDriver createDriver(DesiredCapabilities capabilities) {WebDriverManager.chromedriver().setup();Map<String, String> mobileEmulation = new HashMap<>();mobileEmulation.put("deviceName", "iPad");ChromeOptions chromeOptions = new ChromeOptions();chromeOptions.setExperimentalOption("mobileEmulation", mobileEmulation);WebDriver driver = new ChromeDriver(chromeOptions);WebDriverRunner.setWebDriver(driver);return driver;    }

Снимаем скриншоты

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

screens / {browser} / {desktop | tablet | mobile} / {region} в зависимости от выбранного для запуска браузера, устройства (режима адаптивности) и регионов (некоторые компоненты могут быть регионозависимы, т.е. отображаться по-разному в зависимости от выбранного пользователем региона).

Название файла состоит обычно из:

• для fullscreen (страницы целиком) = {URL path} + опционально {query}, {ref};

• для отдельного элемента | групп элементов = {URL path} + {уникальный class | id | path} (тут на усмотрение кому как удобно, главное, чтобы можно было выделить уникальное значение)

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

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

Пример снятия скриншота всей страницы (fullscreen):

Создаем объект Screenshot AShot, перед вызовом метода takeScreenshot() вызываем метод shootingStrategy(), в параметрах которого задаем правило съемки viewportPasting(300), т.е. снимать скриншот с прокручиванием, с таймаутом 300 мс. AShot по умолчанию использует jQuery для поиска координат, при его отсутствии, необходимо включить поиск координат с помощью WebDriver API предварительно вызвав метод coordsProvider(new WebDriverCoordsProvider()).

Screenshot actualScreenshot = new AShot()   .shootingStrategy(ShootingStrategies.viewportPasting(200))   .coordsProvider(new WebDriverCoordsProvider())   .takeScreenshot(getWebDriver());

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

Погуглив и проанализировав DPR (Device Pixel Ratio) значения страниц в разных режимах, стало понятно, что дело скорее всего в соотношении пикселей устройств, которые мы эмулируем. Запустив window.devicePixelRatio;в консоли браузера, можно найти его. Задали другой shootingStrategy, указав подходящий устройству DPR scaling в параметрах, и таким образом избавились от вышеуказанных проблем.
Для режима планшет (iPad) указали ShootingStrategies.viewportRetina(600,0,0,2f).
Для мобилы (Pixel 2XL) указали ShootingStrategies.viewportRetina(600,0,0,3.5f)

Пример снятия скриншота конкретного элемента (группы элементов):

При вызове метода takeScreenshot(), в параметрах, помимо текущего WebDriver, передаем еще элемент WebElement либо коллекцию элементов Collection <WebElement>, по которым мы хотим получить скриншот:

Collection<WebElement> elements = new ArrayList<>();   elements.add($x("//div[contains(@class,'rtk-offer-list')]")); // допуслуги и оборудование   elements.add($x("//div[@class='rtk-offer__legend']")); // блок ценыScreenshot actualScreenshot = new AShot()   .shootingStrategy(ShootingStrategies.viewportPasting(200))   .coordsProvider(new WebDriverCoordsProvider())   .takeScreenshot(getWebDriver(),elements);

Снятие скриншота c установкой игнорирований элемента(-ов) при сравнении:

Создаем set из элементов, которые хотим игнорировать при сравнениях:

Set<By> ignoredElements = new HashSet();ignoredElements.add(By.xpath(xpath);

и передаем при снятии актуального скриншота этот набор вызовом метода ignoredElements(final Set ignoredElements)

Screenshot actualScreenshot = new AShot()   .shootingStrategy(ShootingStrategies.viewportPasting(200))   .coordsProvider(new WebDriverCoordsProvider())   .ignoredElements(ignoredElements)   .takeScreenshot(getWebDriver());

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

expectedScreenshot.setIgnoredAreas(actualScreenshot.getIgnoredAreas());

Сравнение скриншотов

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

ImageDiff diff = new ImageDiffer().withDiffMarkupPolicy(new ImageMarkupPolicy().withDiffColor(Color.RED)).makeDiff(expectedScreenshot, actualScreenshot);    if(diff.getDiffSize()!=0){       Allure.label("testType", "screenshotDiff");       attachImg("expected", expectedScreenshot.getImage());       attachImg("actual", actualScreenshot.getImage());       attachImg("diff", diff.getMarkedImage());       attachImg("diff (прозрачность)", diff.getTransparentMarkedImage());       Assert.fail("Скрины отличаются");    }

Для удобства просмотра отличий используем плагин Allure ScreenDiff, который добавляет специальный блок в сценарий, внутри отчёта, с двумя режимами:

• Отображение отличий с подсветкой (Show diff);

• Отображение формы с режимом наложения (Overlay) с передвигаемым по горизонтали ползунком для удобного визуального сопоставления текущего и ожидаемого результата.

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

А в чём польза?

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

Пользователи мобильной версии версии сайта бренда долгое время вместо кнопки Узнайте больше видели Узнайте боль (спасибо ребятам из Альфа-банка, которые первыми это заметили). Это один из примеров, который вызывает больше улыбку чем неудобство, но бывают ситуации, которые не столь безобидны. На этом пока всё. Всем стабильных тестов! :)

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

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

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

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

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

В этот момент я испытал целую бурю эмоций - от радости, что наконец-то нашел проблему, до недоумения от самой сути находки. То, что каталог прилично нагружен, я знал и раньше: к хранилищу сейчас подключено уже больше 250 систем-источников, в каждом не одна сотня таблиц, а в самих таблицах может быть двухуровневое партиционирование. Greenplum учитывает каждую партицию как отдельный объект, поэтому системные представления вроде pg_class прилично раздуваются. Но неужели действительно нужно обращаться к каталогу при любом запросе данных?

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

Проверяю влияние по коду, комментирую вызов метода fetchFieldMetaData, собираю jar файл драйвера, подсоединяюсь с его помощью к базе, иииии

Сказать, что это дало результат - это не сказать ничего. Запросы теперь просто летают. Ускорение - в разы. Отправил коллегам на тест - отзывы примерно такие:

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

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

P.S. В итоговой версии кода создал новый параметр подключения драйвера runtimeMetaDisable. Вызов метаданных и выбрасывание исключений привязал к его значению. Такой подход более гибок, чем жестко закомментированный вызов метода и позволяет управлять поведением драйвера в зависимости от потребностей. Код выложил на гитхаб. Если у вашей базы тяжелый каталог и вы хотите попробовать драйвер в деле, но не знакомы с миром java и не знаете, как собрать jar файл драйвера - напишите в комментариях!

Привет, меня зовут Сергей Раков, я руководитель B2G-направления в ИТ-кластере Ростелекома. 23 марта 2021 года мы отметили год, как полностью работаем в удаленном режиме. За этот год мы в значительной степени пересмотрели наши процессы и решили ряд нетипичных проблем.

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

Я знал, что удаленные команды могут успешно решать задачи, но придерживался мнения, что эта команда должна быть расположена в одной локации и так же работать в офисе. Но прошлый 2020 год в корне изменил мое мнение о таком подходе. В начале пандемии я очень переживал, что команда будет испытывать стресс в новых вынужденных условиях, и пострадает продуктивность из-за удлинения коммуникаций. Поэтому я сразу начал предлагать различные решения, которые вернули бы ту атмосферу офиса, в которой мы так долго работали. Решение об использовании того или иного инструмента принималось совместно с командой. А бОльшую часть изменений в наши процессы внесла сама команда.

Как искали место для общения

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

Решением для нас стал Discord попробовать его предложил мне один из членов команды. Сначала я относился скептически к этому сервису, т.к. до этого у меня не было опыта работы с ним свою игровую карьеру я закончил до появления вышеуказанного приложения :)

В итоге я сделал сервер, в котором нагенерил несколько комнат, где постоянно находились ребята по командам отдельно для питонистов, отдельно для рубистов и т.д. В итоге можно было зайти к ним и обсудить какой-нибудь срочный вопрос почти как в офисе. Бонусом у нас появилось одно место для голосовых коммуникаций внутри команды. Никакой генерации ссылок на каждый созвон не требуется. Если писать долго, то мы просто переходим в Discord в свободный канал и решаем все вопросы. У нас даже есть специальный голосовой канал Курилка в котором можно просто поболтать.

Work(&/or)life balance

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

Для сохранения баланса между работой и личной жизнью кто-то начал жестко следить за временными рамками рабочего дня, а кто-то начал более гибко планировать свой рабочий день. Среди этих ребят был и я. Мы начали применять методику из книги Getting Things Done (Как привести дела в порядок) Дэвида Аллена. Она помогла нам все задачи держать в фокусе, ничего не забывать и меньше тратить время на переключение между ними. Удаленка нам показала, что изменения это хорошо. И я понял, что развития без изменений не бывает. В целом, команда научилась более гибко планировать рабочий день и сейчас бОльшая часть команды не хочет выходить обратно в офис.

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

Промежуточные итоги

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

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

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

Конечно, во время удаленной работы возникали различные организационные сложности. И в первую очередь с подписанием документов. Мы не стали оснащать всех сотрудников МФУ, т.к. они нужны нам крайне редко в основном, в случае подписания каких-либо документов. Мы же программисты, и у нас бумажный документооборот сведен к минимуму. В общем, все попытались максимально перенести в электронную форму, а для решения остальных вопросов мы просто приезжали в офис, подписывали необходимые бумаги и снова возвращались в удаленный режим работы. Но на удаленке не обошлось без дополнительных затрат. Например, у нас есть отдел тестирования, который занимается проверкой качества ПО для IP-камер. Вот таким тестировщикам пришлось выслать дополнительные комплекты тестового оборудования, а иногда даже установить более продвинутые сетевые маршрутизаторы, которые позволяют настроить доступ в нашу закрытую сеть.

Сейчас ИТ-кластер постепенно переходит на гибридный формат работы, и командам разрешили выбрать наиболее удобный формат работы:
- 3 дня в офисе / 2 дня дома;
- 2 дня в офисе / 3 дня дома;
- 1 день в офисе / 4 дня дома
- полностью на удаленке.

Ответственность за это решение несет руководитель команды главное, чтобы команда работала эффективно, а также была рабочая атмосфера, команда чувствовала себя хорошо, и все это вело к увеличению производительности. Некоторые ребята в нашей команде уже иногда выходят в офис. Кто-то только планирует это сделать. Значительная часть сотрудников планирует остаться на удаленке (последний пульс-опрос показал больше 50%), а в офис приезжать только при необходимости, используя специальные гостевые рабочие места.

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

Методология

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

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

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

Изобретения и патенты.
С патентами вообще всё просто: первым запатентовал что-то стоящее до пенсии обеспечен. И вся информация о патентах публична, т.к. все хотят застолбить поляну.

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

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

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

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

Пока, за три года, мы прогнали через систему 4,8млн. научных публикаций, 2,4 млн. патентов, информации об инвестициях на сумму$2,3 трлн, 2 млн. вакансий и 7 млн. резюме, около 1 млн. публикаций в СМИ и столько же поисковых запросов.

Как оцениваем

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

Технологический стек исследования трендов:

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

Эти 200 трендов мы уже отсматриваем вручную и отбрасываем какие-то откровенно общие. Допустим, выдала нам машина интернет или software, такой уровень абстракции нам ни к чему. После просмотра всего списка остаются уже 100-120 трендов.

Процесс выявления трендов

Да, кстати, о лингвистическом анализе. Всё было бы сильно проще, если бы каждый термин использовался только в своем значении, без синонимов и аббревиатур. Но, как вы знаете, ситуация выглядит иначе. Где-то интернет вещей будет назван интернетом вещей, в других источниках IoT, в патентах sensor network, machine type communication и так далее. В общем, кто во что горазд, поэтому мы адаптируем терминологию под конкретный вид источника: под каждый составляется уникальное именно для него семантическое ядро, и тренд привязывается к определенному лексикону.

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

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

Где всё это можно использовать

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

Например, высокоуровневый список вида Топ-100 чего-нибудь, который топы любят смотреть, чтобы понимать во что инвестировать. Практический смысл у таких рейтингов следующий. Есть у компании некий бюджет который она готова потратить на инновации. И ей нужно определить во что вкладывать. Искусственный интеллект? Блокчейн? Беспилотные автомобили? Или может квантовые компьютеры? Подобные списки помогают сравнивать перспективность разных технологий между собой. Конечно, после построения таких списков необходима их верификация и аналитическая интерпретация, но опираться на них вполне можно.

По итогам 2019 года список Топ-15 трендов выглядит так:

Искусственный интеллект второй год подряд занимает 1-е место в общем рейтинге (за последний год отрыв от мобильных сетей только увеличился). В 2019 году неплохой рост показали облачные технологии, поднявшись с 10-го на 4-е место, и технологии дополненной реальности, поднявшись с 24-го на 14-е место.

По каждой технологии мы готовим такие карточки:

Анализируя полученную информацию можно получить много инсайдов. Например, анализируя данные по искуcственному интеллекту и квантовым технологиям, мы обнаружили интересную закономерность: начиная с 2015 года в научных публикациях появляется термин quantum machine learning (использование квантовых компьютеров для анализа данных с помощью машинного обучения). А в 2019 году каждая 15-я научная статья по квантовым технологиям содержала отсылки к искусственному интеллекту. Это говорит о том, что ученые озабочены проблемой нехватки текущих вычислительных мощностей для дальнейшего развития ИИ и, судя по всему, квантовый компьютер станет решением этой проблемы.

5G за год из инновации превратилась в зрелую технологию, которая оказывает достаточно сильное влияние на другие технологии: в странах с первыми коммерческими сетями 5G увеличилась патентная и инвестиционная активность в сфере VR.

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

Ещё одним открытием для нас стали технологии убеждения (persuasive techniques) смесь из привычных ИТ-сервисов и психологических приемов. В 2019 году было сразу несколько крупных инвестиций и рост вакансий в этой области. Основное применение приложения, посвящённые здоровому образу жизни и образовательные сервисы. Другим применением является использование этих технологий в избирательных кампаниях, яркий пример: небезызвестная Cambridge Analytica в 2018 году. Похоже, что среди технологий двойного назначения прибыло.

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

Китай абсолютный мировой лидер по патентам и научным публикациям: каждый второй патент и каждая четвертая научная статья в сфере ИКТ китайские. Лидерство США сохраняется только в области инвестиций.

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

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

Вот, что мы выявили по итогам 2019 года:

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

Больше аналитики по итогам Мониторинга трендов цифровизации можно получить из наших ежегодных отчётов, доступных по ссылкездесь.

Про планы

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

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

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