Мы предполагали, что на воркшопе случатся все возможные технические проблемы: люди придут с ноутбуками на самых разных ОС, заранее точно никто ничего не скачает и не настроит, а интернет на конференции будет отвратительный. Так обычно бывает, когда сотни человек собираются в одном помещении. Ещё мы рассчитывали, что все будут немного уставшие на третий день, что яркость экрана может быть плохой, что будет шумно. А еще совершенно точно мы будем в последний момент находить баги, исправлять их, релизить, и участники должны будут использовать последний релиз.
В общем, было понятно, что надо подстраховать участников всеми возможными способами. Вот что у нас получилось.
Последовательность действий разбили на шаги. Каждый шаг — длинная команда в консоли или пара команд. Всё это мы завернули в один скрипт, чтобы каждый шаг в первый раз выполнять одной командой, вроде
run.sh compile. Это должно было застраховать участников от ошибок, когда они невнимательно переписали команду или что-то пропустили. А потом, когда в перый раз всё получилось, можно развернуть подробную инструкцию, где объясняется каждый параметр в длинной команде, и выполнить еще разок.Завернули всё в докер, чтобы не заморачиваться с настройкой окружения. Получилось два образа: в одном наш компилятор, в другом тулзы для работы с веб-сервисом. Буквально в последний день добавился третий, в котором локально поднимается нода Ethereum и на ней смарт-контракт выполняет завершающий шаг вокршопа.
Чтобы была уверенность, что шаги работают, мы положили их все в CI. Вот буквально тесты поднимают контейнеры и в них проверяют, как воркшоп проходится по шагам. Версии всех образов зафиксировали, так что любое обновление проходило через CI. Это очень помогло нам в последний день до воркшопа, последнее обновление закинули буквально за полчаса до начала.
Чтобы не тратить время и интернет на подготовку окружения, мы сделали готовые виртуальные машины в AWS. На них сразу был клонирован репозиторий с кодом для воркшопа, установлен Docker, и скачана пара нужных образов. Так мы защитились от плохого интернета, неработающего докера и неподдерживаемых архитектур проца. У меня был готовый inventory, так что с помощью Ansible я мог быстро обновлять код и образы на машинках. И еще был плейбук для того чтобы раскидать по машинкам ключи, чтобы люди могли зайти по SSH. Соединение по SSH — штука нетребовательная и довольно живучая. Даже с плохим каналом можно зайти и работать. Рассчитывали на 15-30 участников, поэтому заранее подняли 30 машинок.
Конечно же мы всё это отрепетировали: и техническую сторону, и контентную. У нас был чат в дискорде, мы были готовы отвечать там на вопросы участников по ходу вокршопа, чтобы снять нагрузку с ведущего.
Подготовились в целом отлично. Не учли только один риск, и как раз он и случился. Как вы думаете, что это было?