Привет! Меня зовут Алексей Петрашин, я ведущий специалист отдела внешнего обучения и сертификации, а еще курирую работу Учебного центра CTSG.
В статье поделюсь опытом проведения экзамена в формате игры «Подземелья и Драконы». Расскажу, как повысить вовлеченность студентов для решения сложных и трудоемких задач, опишу проведение такого экзамена на практике и техническую реализацию игрового подземелья.
Учебный центр в Crosstech Solutions Group
Обучение в Центре строится вокруг практической и теоретической базы, которая необходима для работы в технических направлениях. В течение нескольких месяцев студенты последовательно изучают ключевые темы ИТ-индустрии.
Программа включает работу с Linux, базами данных, SQL, сетями, виртуализацией, погружение в методологии управления проектами, а также общее понимание того, как устроены технические системы и инфраструктура. При этом акцент делается не только на знании инструментов, но и на понимании, в каких ситуациях они используются.
Практические задания на протяжении всего курса выстроены таким образом, чтобы студент учился ориентироваться в среде, искать информацию, пользоваться справочными материалами и логически подходить к решению задач. Так постепенно формируется навык самостоятельной работы.
Внедрение геймификации в обучающий процесс
Перед выведением обучающих курсов в прод, мы с командой решили внедрить интерактивные элементы в практику. В середине первого семестра начали замечать, что интерактив вызывает интерес и эмоциональный отклик, помогает быстрее находить ассоциации со сложной теорией.
По обратной связи было видно, что формат положительно влияет на вовлеченность. Студенты л��чше взаимодействовали между собой и делились результатами мини-активностей. Это отразилось на продуктивности: материал усваивался стабильнее по сравнению с предыдущими потоками. Количественный и качественный анализ выполненного домашнего задания показал, что число выполненных практических работ в срок выросло на 32%.
По опыту прошлых лет мы понимали, что классический формат обучения и проведения экзамена создает высокий уровень стресса. Студенты часто действовали механически, а проверка знаний переставала отражать реальный уровень подготовки и скорее показывала способность справляться со стрессом, чем понимание материала.
Сочетание положительного эффекта от интерактивности и выявленных проблем на экзаменах прошлых лет стало причиной перехода к более геймифицированному сценарию итоговой проверки знаний.
Концепция подземелья
Формат Подземелья и Драконов дал нам возможность соединить несколько сложных тем в целостный сюжет. Студенты погружались в него и сами определяли последовательность действий и динамику.
Задача студента заключалась в том, чтобы пройти все уровни подземелья и добраться до финальной точки – последнего этажа, где их поджидал «финальный босс». Таким образом, перед студентами сразу появлялась конкретная цель и формировалась дополнительная мотивация: дойти до конца и понять, что же ждет на следующем уровне.
Подземелье представляло собой изолированное пространство, с которым студент взаимодействовал через терминал Linux. В самом начале ему предстояло понять контекст и корректно интерпретировать поставленную задачу.
Всего в подземелье было пять уровней. Для продвижения в глубь студент решал практические задачи. Каждый уровень был связан с конкретным набором навыков, изученных в ходе курса.
На первом уровне проверялась базовая ориентация в Linux-среде и умение работать с терминалом. Далее задания постепенно усложнялись: появлялась работа с процессами, файлами и их типами, сетями, архивами, виртуализацией, символическими и жесткими ссылками, а также практическая задача с использованием SQL. Финальный уровень был связан с управлением процессами и завершал весь сценарий.
Каждый этаж имел собственное тематическое оформление, реализованное с помощью таблицы символов ASCII. Во время разработки концепции мы придумали элементы истории, персонажей и текстово-визуальные фрагменты, которые усиливали эффект погружения. Некоторые студенты не знали особенности лора П&Д, поэтому нам пришлось адаптировать контент под разную аудиторию, чтобы совместить технические аспекты с фэнтезийным миром. Повторюсь, именно такой подход позволял удерживать внимание и вызывать естественное любопытство.
Архивы с привычными расширениями могли запросто оказаться «мимиками» и при взаимодействии с ними отбросить студента на пару этажей назад, а «дракон» на финальном уровне был представлен в виде спящего процесса.
Основной ценностью стал сам механизм прохо��дения и логика взаимодействия со средой, которую в дальнейшем можно улучшать, масштабировать и адаптировать под другие образовательные задачи.
Техническая реализация
При проектировании подземелья главной задачей стало создание полностью изолированной среды. Использование стандартного пользователя Linux для этой цели оказалось недостаточным: студент все равно бы видел файловую систему, имел доступ к системным утилитам, мог бы выйти за пределы сценария и разрушить атмосферу подземелья.
Поэтому мы с командой стали искать пути решения – для MVP использование контейнеров показалось избыточным, поэтому было решено пойти другим путем и остановиться на утилите bubblewrap.
Bubblewrap позволяет запускать процессы в изолированной песочнице без привилегий суперпользователя, используя механизмы user namespaces. Ведь su – это привилегия. Это дало нам возможность:
- полностью скрыть системное окружение от студентов;
- показывать только нужную подготовленную файловую структуру;
- контролировать доступные бинарные файлы и библиотеки;
- отслеживать и логировать все действия студента.
К тому же мы настроили автоматический вход в песочницу при авторизации, поэтому студент сразу попадал в подземелье и не мог выйти за его пределы при помощи обычных команд.
Само подземелье с технической точки зрения представляло собой отдельную файловую структур с заранее спроектированными уровнями. Каждый уровень был оформлен в виде набора директорий и файлов с на��троенными правами доступа. Продвижение студента по подземелью было возможно только при выполнении определенных условий: решения головоломок, загадок и использования нужных утилит.
Ключевым элементом управления окружения стал конфигурационный файл dungeon_bashrc, который исполнялся при входе пользователя в систему. Он использовался как точка инициализации всей логики подземелья и регулировал работу и запуск остальных четырех bash-скриптов.
Основные задачи файла bashrc:
- подмена приглашения командной строки под стиль подземелья;
- вывод стартовых сообщений и элементов сюжета;
- запуск управляющих скриптов;
- подключение механизма ограничения доступных команд и утилит.
Ниже приведен фрагмент файла:
# Подмена приглашения командной строки PS1='[Traveler]$' # Подключение основной логики обработки команд export DOUNGEON_COMMANDS=”/etc/command.sh” if [ -r "$DUNGEON_COMMANDS" ]; then source "$DUNGEON_COMMANDS" 2>/dev/null || true else echo "Упс, похоже сбой загрузки заклинаний, необходимо проверить управляющие манускрипты!" fi # Вывод стартового сообщения при входе в подземелье if [ -z "${DUNGEON_WELCOME_SHOWN:-}" ]; then export DUNGEON_WELCOME_SHOWN=1 cat /etc/banner📜 fi
Ограничение и контроль команд мы реализовали с помощью управляющего файла command.sh. Вместо использования стандартных бинарников Linux, скрипт позволял переопределять команды как bash-функции и контролировать доступ студента к утилитам и их параметрам.
Упрощенная часть функции приведена ниже.
Пример:
_door_locked() { echo "╔════════════════════════════════════╗" echo "║ ДВЕРЬ ЗАПЕРТА 🔒 ║" echo "╚════════════════════════════════════╝" } cd() { local target="${1:-}" if [[ "${DOOR4_OPEN:-0}" -ne 1 ]]; then case "$target" in *Door4*|*/Door4*|*Door4/*) _door_locked return 1 ;; esac fi builtin cd "$@" || return $? }
Такая реализация позволяла:
- поэтапно открывать функциональность;
- исключить обход ограничений через прямой вызов бинарников;
- жестко контролировать пользовательский сценарий
Прогресс студента сохранялся в отдельный файл с переменными: state.env. Каждая переменная отражала, выполнено ли конкретное условие или задание и какие доступы у него есть на данный момент.
Пример файла структуры состояния:
LVL1_OPEN=1 LVL2_OPEN=1 DOOR4_OPEN=0 SECRET_DOOR_OPEN=0 PS_RIGHT=0 DRAGON_PID=9991
За обновление и изменение переменных отвечал третий скрипт – engine.sh. Он позволял
- валидировать ввод студента;
- обновлять состояние переменных;
- давать доступ к новым командам и открывать уровни;
Пример кода:
case "$ans" in port|Port|PORT) echo -e "$separator\n\nГде-то на уровне щелкнул замок. Одна из дверей теперь открыта!\n\n$separator" state_set DOOR4_OPEN 1 command echo "Level 0 | 3" >> /var/.dungeon_state/check_progress.sh ;; 0) echo -e "$separator\n\nОтлично, первая печать снята. Вы чувствуете как силы суперпользователя плавно прибывают.\nТеперь вы можете менять <права> комнат и залов.\nПоспешите разрушить вторую печать с помощью соответствующего <заклинания>!\n\n$separator" state_set BIG_DOOR_OPEN 1 command echo "Level 4/1 | 4" >> /var/.dungeon_state/check_progress.sh ;; *) echo -e "$separator\n\nНеверный ответ. Стены смеются над тобой!\n\n$separator" exit 1 ;; esac
Последний файл использовался для отслеживания прогресса и автоматического подсчета результатов прохождения подземелья студентами – check_progress.sh. Куда же мы без автоматизации в наше время.
Для упрощения использования и масштабирования был подготовлен единый установочный bash-скрипт. Он автоматически разворачивал все подземелье: создавал необходимую файловую структуру, настраивал окружение, копировал нужные утилиты и применял права доступа. В результате экзаменационное пространство приводилось в рабочее состояние за несколько минут и не требовало ручной настройки.
Практический опыт и обратная связь
Сценарий подземелья невозможно было пройти за предоставленное студентам время без опыта работы с изученными технологиями. Цель: диагностировать уровень подготовки и глубину усвоения материала.
Частично экзамен смогли пройти более 70% студентов. Четверть участников полностью покорили подземелье. На этот результат мы и ориентировались: учащиеся с сильными скилами смогли пройти его без единой подсказки и уложиться в отведенное время.
Студенты, которые показывали хорошие результаты во время обучения на курсе, заканчивали экзамен раньше дедлайна. Они проявили знания команд, инструментов, понимание логики среды, умение быстро ориентироваться и принимать решения в нестандартных условиях. Отдельно отмечу, что экзамен оценивал вместе с техническими навыкам еще и поведенческие аспекты.
Остальные участники либо использовали подсказки, либо не могли дойти до конца и убить дракона. При этом значительная часть студентов набрала промежуточный результат, около 17 баллов из 35.
Реакция студентов оказалась неоднозначной. Большая часть положительно отозвалась о концепции экзамена. Они отметили неожиданный формат, высокий уровень погружения, оформление терминала и сюжетных поворотов. Несколько студентов даже после экзамена возвращались с просьбой получить повторный доступ, чтобы пройти его до конца уже без ограничений по времени. Это вновь подтверждает фактор любопытства. Любопытство – главный способ учиться!
Следите за новыми приключениями Учебного центра на Хабре и телеграм-канале по стажировкам.
