Добрый день, дорогие хаброчитатели. Меня зовут Алексей Прутик, я архитектор платформенных решений ВТБ. А по совместительству эксперт и один из судей архитектурного хакатона ARCHI.TECH ВТБ, про который я расскажу в этой статье. Вы прочитали заголовок и вам хочется узнать, как научиться делать невозможное? Очень скоро это станет понятно. Начнем с краткой информации по хакатону, ведь он уже закончился и можно подвести итоги. Поехали!
Главные цифры
✔️ 31 мая – 30 июня даты проведения;
✔️ 1200+ участников сформировали 430 команд;
✔️ 2 этапа задач (разминочная и основная) и этап онлайн-питчей для финалистов;
✔️ 70%+ решили разминочную задачу;
✔️ 72 команды решили основную задачу;
✔️ 3 уровня сложности основной задачи: простая, средняя и сложная;
✔️ 3 номинации (оцениваемых архитектурных профилей): архитектор стрима, архитектор системы и архитектор данных;
✔️ 24 часа на решение основной задачи;
✔️ 23 решения дошли до финальных питчей;
✔️ 1837 человек посмотрели трансляцию;
✔️ 1,2 млн руб. разделили между собой 9 победителей, по 3 в каждой из номинаций.
В статье мы рассмотрим, как были достигнуты эти результаты: на чем хакатон базировался, как была организована работа экспертов и многое другое. Но начать хотелось бы со старинной притчи:
В стародавние времена, хозяйки больших богатых домов не могли обойтись без надежных помощниц – горничных. Но как найти такую, которая и порядок обеспечит, и не унесет ничего из дому? Хозяйка одного из шато в провинции Лангедок использовала такой метод. Она предварительно разбрасывала по дому десять монеток и просила новую горничную прибраться. Если горничная под вечер возвращала ей все разбросанные монетки – это говорило о том, что она, а – честная, б – аккуратная. Если горничная монетки не возвращала, ее, конечно, не нанимали.
Принципы оценки
У любого человека, склонного к архитектурной работе должны быть две вещи:
компетенции — знания конкретной компании, руководств проектирования, стандартов организации и т.п;
навыки — имманентные знания и экспертиза, не связанные с организацией.
Мы останавливаемся на оценке именно навыков, которые человек имеет независимо от того, где работает. Навыки делятся на технические и личностные.
Навык — это умение решать задачи определенного типа. Задачи мы классифицировали по 4 профилям: Архитектор стрима, Архитектор системы, Архитектор интеграции, Архитектор данных (которые стали номинациями хакатона, кроме номинации «Архитектор интеграции» — ее мы впоследствии решили пока исключить, оставив в качестве задела на будущее). У профилей навыки могут пересекаться.
А теперь ключевой момент: как выявлять навыки? Мы решили это делать также, как в описанной притче: через монетки, только архитектурные. Как прилежная горничная, которая должна была найти все монетки, так и хороший архитектор, сможет понять суть задания, проанализировать требования, заметить в них противоречия и отсутствующую, но важную для принятия решения информацию, и понять, как ему поступать.
В каждое задание, явно или неявно подсыпаются «архитектурные монетки». Например, мы не указываем в задании явно «реализовать сегментирование», но мы сформулируем нефункциональные требования таким образом, что, если человек понимает проектирование высоконагруженных систем, знает, как обеспечить надежность и масштабирование — он про это подумает.
Монетки распределены по архитектурным профилям и областям навыков, которые мы проверяли:
Управление требованиями — человек понимает важность функциональных и нефункциональных требований. Все как в реальной жизни: они могут противоречить друг другу, могут быть неполными и т.д. Пример монеток: мы не договорили что-то в задаче, указали среднюю нагрузку в сутки, но не указали пиковую или указали требования, которые противоречат друг другу;
Функциональная декомпозиция — основной навык архитектора: разбить задачу на слабосвязанные части, чтобы с ними дальше работать по отдельности;
Архитектура данных — выделение сущностей в системе, их состава и связей между ними. Задачи мы составляли без привязки к предметным областям, глубоко знать специфику для решения не требовалось;
Интеграция — правильно выбраны шаблоны взаимодействия (синхронный, асинхронный, стриминг, публикация-подписка), протокол (HTTP, WebSocket, gRPC, MQ, Kafka), где необходимо высокая производительность предусмотрена буферизация;
Проектирование API — API строится вокруг сущности, может быть разных типов (CRUDL, технологический процесс, передача данных, публикация событий), должен иметь входные и выходные параметры, перечень ошибок, единый стиль именования;
Учет эксплуатации — для сопровождения системы нужны соответствующие инструменты мониторинга, API управления, АРМ сопровождения;
Безопасность — предусмотрена аутентификация, авторизация различных уровней (двухфакторная, трехфакторная), электронная подпись;
Надежность и масштабируемость — где необходимо, предусмотрены резервирование СУБД, веб-серверов, брокеров, сегментирование и шардирование, масштабируемость для высоконагруженных элементов;
Техническая грамотность — выбор наиболее подходящих технологий для реализации, с учетом национальных реалий (импортозамещение);
Техническая архитектура — аргументированное использование виртуальных или «железных» серверов, сегментирование сети (интернет-сегмент, сегмент ДМЗ, внутренняя сеть) и способы взаимодействия между сегментами.
По всем перечисленным навыкам были составлены монетки, которые легли в основу «Инструмента оценки архитектурных навыков». Рассмотрим его подробнее.
Инструмент оценки архитектурных навыков
Последовательность использования инструмента
Инструмент работает в 3 этапа:
Создание базы знаний — словаря монеток
Монетки составляются экспертами в определенных областях (об этом рассказали в предыдущем разделе). В основу инструмента положена идея деления большой задачи на много маленьких. Монетка — это маленькая архитектурная задача. По каждой монетке определяются условия оценивания: за что 1 балл, за что 2 балла, и за что 3 балла. Максимальные 3 балла, когда монетка найдена полностью. Например, для монетки «Декомпозиция на сущности»: нет модели данных — это 0 баллов; не все сущности — 1 балл; избыток сущностей — 2 балла; полное соответствие модели данных кандидата эталонному решению (нет лишних сущностей и есть все нужные) — 3 балла.-
Подготовка заданий
Разрабатываются архитектурные задания, в которые набираются монетки из словаря монеток. В хакатоне были доступны задачи трех уровней сложности на выбор: простая, средняя и сложная. В простую задачу «подсыпается» одно количество монеток, в среднюю — больше, в сложную — самое большое количество. В нашем случае, по правилам хакатона, получилось: 30, 40 и 50 баллов соответственно. Принципиальный момент: балльная стоимость монетки не меняется в зависимости от того, в какой задаче она находится.Под каждую задачу готовится эталонное решение. На основе эталонного решения конкретизируются монетки в проверочном листе — для всех задач с ответами и по каждой монетке есть свой проверочный лист. Например, для монетки «Декомпозиция на сущности», эта конкретизация заключается в указании списка сущностей. Для простой задачи это были: «Страница», «Событие перехода на страницу», «Цифровой отпечаток устройства». При указании всех нужных сущностей за монетку участник получает 3 балла, если будут приведены указанные и излишние — 2 балла, если не будет хватать сущностей — 1 балл.
-
Проверка решений
Проверочным листом пользуется назначенный эксперт. Эксперт видит решение кандидата, проверочный лист по задаче и оценивает, в какой степени решена та или иная монетка. Для каждой монетки эксперт ставит в форму оценки соответствующий балл: 0, 1, 2, 3.Последний шаг — маппинг монетки на каждый профиль, в котором она присутствует: архитектор стрима, системы, данных. Суммируя баллы по каждому профилю, мы видим куда каждый индивидуальный участник/команда более склонны, и можем определить победителей.
Особенности применения инструмента в хакатоне
Разработанный инструмент можно использовать в разных сценариях: для тестирования кандидатов на работу, для ежегодного оценивания, для хакатонов. Для хакатонов он используется особым образом, чтобы обеспечить массовость и быструю оценку.
Проверка решений была распараллелена на 7 экспертов. Отметка оценок выполнялась в специализированной системе. Основным тормозящим аспектом при таких массовых проверках является переключение контекста эксперта — он сначала думает про одно, затем про другое. Чтобы этого избежать, мы распределили области проверяемых навыков между экспертами (каждому эксперту — несколько монеток из определенной области) и замаппили артефакты, которые предоставляли участники, на конкретные экспертные области. Например, если эксперт занимался безопасностью, ему нужно было смотреть только в артефакт «Архитектура ИС», остальные при необходимости можно просто пробегать глазами.
Такой подход имеет следующие преимущества:
А) позволяет эксперту загрузить проверяемые монетки к себе в голову, не обращаться к эталонному решению, а открывать решение кандидата и быстро по памяти проходиться по ограниченному списку артефактов, не изучая все материалы решения работы. Это существенно сокращает время на проверку одного решения: от 5 до 10 минут у одного эксперта и суммарно около часа времени всех экспертов. Для понимания: решения некоторых участников содержали до 30 слайдов.
Б) объективная оценка кандидатов достигается тем, что один эксперт оценивает одни и те же монетки для всех, ставит оценку, ранжируя всех кандидатов по одинаковой шкале (субъективное суждение, если оно есть, одинаково влияет на всех).
Как проходил хакатон
Этапы хакатона
В хакатоне можно выделить несколько основных этапов:
Введение: правила игры, решение демо-задачи, ответы на вопросы участников;
Разминочная задача;
Основная задача на выбор: простая, средняя, сложная;
Защита своих решений финалистами во время онлайн-питчей.
На первом этапе мы дали всю вводную информацию, решили демо-задачу, ответили на вопросы. Участникам было сказано, как им поступать, если в задачах они обнаружат недосказанности или противоречия, т.е. одну из наших «монеток» (нужно делать допущения при решении, когда не хватает каких-то данных).
Разминочная задача позволила участникам прочувствовать правила, требования к решению, оценить свои силы чтобы выбрать подходящую сложность задачи основного этапа, на который отводилось всего 24 часа.
Ясно, что за сложную задачу было больше баллов, чем за среднюю, но и вероятность допустить ошибки или решить не полностью — она тоже больше. Поэтому мы на встречах с участниками рекомендовали оценить силы, время и выбрать ту задачу, которую они смогут решить максимально полно. В итоге в призерах у нас большинство со сложной задачей, но также есть и 2 победителя со средней задачей, которые набрали практически максимальное количество баллов.
23 участника, лучше всего решивших задачу основного этапа, мы пригласили на онлайн-питчи, на которых давалось 10 мин для рассказа решения задачи и еще 5 мин для ответов на вопросы экспертов. Во время питчей оценивались софт навыки, такие как: оформление презентации, связность, полнота, логичность доклада, ответы на вопросы и знание терминологии.
На рисунке есть описание того, как ставилась задача. Структура по всем задачам была общая. Это условия задачи, стек технологий и перечень требуемых артефактов. Это стандартные артефакты, которые всегда проектируются при разработке системы:
функциональная структура системы — схема, описание функций системы и их зависимостей;
архитектура данных — логическая и физическая модель данных;
архитектура системы — внутреннее устройство проектируемой системы с указанием технологий реализации и взаимодействий с внешними системами;
API модулей системы — описание функций API, способов их вызова, возвращаемый результат (указать протоколы, синхронный/асинхронный и т.д.);
архитектура развертывания — развертывание компонентов системы на инфраструктуре, основные параметры конфигурации компонентов и связи между ними.
При этом мы не требовали от участников соблюдения каких-то определенных правил использования нотаций, не вкладывали специфику ВТБ. Максимально лояльно, чтобы люди могли пользоваться инструментами, к которым привыкли.
Мы стремились к тому, чтобы судейство было максимально справедливым, объективным и равным для всех участников. Субъективизм, там, где он остался, был одинаково отнесен к каждому участнику благодаря инструменту оценки, описанному в предыдущем разделе.
Результаты
Для проведения самого хакатона организаторы и участники пользовались созданным на основе соревновательной платформы codenrock.com веб-приложением. Через эту платформу участники загружали задачи, а эксперты получили необходимый интерфейс для проверки, адаптированный к нашему инструменту оценки. На слайде приведена выгрузка из этой платформы.
Думаю, что с учетом уже рассказанного, дополнительных комментариев таблица не требует. Могу только еще раз назвать наших победителей, хотя про сам хакатон было много сообщений в СМИ и различных телеграм-каналах.
Лучшими в номинации «Архитектор стрима» стали: Alfa Masters, AdventureTime и «Зайчики»;
В номинации «Архитектор системы» – команды Java Boys, «Фыва» и единственный среди победителей индивидуальный участник под псевдонимом «Дмитрий-76768»;
Команды «Эпсилон», Monikai и CAP стали победителями в категории «Архитектор данных».
Заключение
В результате проведения хакатона мы имеем апробированную методику оценки архитекторов, которая обладает следующими характеристиками:
Позволяет оценивать архитекторов по разным профилям: стрима, системы, данных. При необходимости, профили можно расширить, добавив в условия задач соответствующие, как мы их называем, «монетки» — то, что архитектор должен заметить и учесть при решении задачи;
Проверка по методике реализуется на основе конвейера, сам процесс проверки линейно-масштабируем: нам потребовалось 7 экспертов, чтобы за 8 часов оценить решения 72 команд. Будет больше участников — привлечем больше экспертов;
Методика не только масштабируема, но и формализуема. Люди, имеющие опыт проведения подобных мероприятий, знают насколько бывает сложно проверять работы участников, тут мы эту проблему смогли решить. Мы организовали объективную проверку работ участников и выявили 9 призеров, по 3 финалиста в каждом профиле.
«ИТ-архитектура предполагает сочетание самых разных компетенций: было здорово увидеть среди участников как совсем юных, так и вполне сложившихся специалистов из смежных областей. Средний возраст финалиста составил 30 лет. Предложенный нами формат ИТ-соревнований встретил большой отклик у рынка. Мы обязательно продолжим практику проведения архитектурных хакатонов»
Илья Старостин
руководитель департамента ИТ-архитектуры, старший вице-президент банка ВТБ
Следите за нашими анонсами и до встречи на хакатонах!
