Инфра

Немного о том, на какой инфраструктуре планировалось проводить A/D.

Железо

Инфраструктура представляет из себя компьютерный класс кластер из 30 одинаковых нод с i5 (6 ядер/12 потоков) и 16 GB на борту, и мастера в виде Core2 Duo E6550 (2/2), 4 GB + 2 swap.

Cеть

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

Виртуалки

В качестве оркестратора виртуалок использовалась opennebula, сам гипервизор, очевидно, kvm. Размер виртуалки с тасками составлял порядка 6 GiB.

Факапы, вот они слева

  1. Отсутствие какого-бы то ни было предварительного тестирования, не то что нагрузочного. Первые рабочие версии сети “на железе” появились за 5-6 часов до ивента.
  2. Построение сети усложнялось тем, что, несмотря на то, что в день соревнований кластер был свободен, но в обычные дни на нём проводятся пары, а в течение пар тестировать и строить сеть было невозможно, поэтому приходилось это делать в ограниченное время по ночам.
  3. Один из разработчиков инфраструктуры потратил много времени на разработку задания, которое в итоге не вошло в релиз - по сути, время, которое можно было потратить на доработку инфры - ушло впустую

Timeline

Таймлайн инвета так, как он выглядел для игроков/сообщества:

  • 22 мая, пост в канале
  • 26 мая, репост SPbCTF
  • 29 мая, закрытие регистрации. Суммарно зарегистрировалось 96 человек.
  • 30 мая, день ивента
    • 12:47 - выкладывается архив с тасками
    • 13:00 - пароль от архивов с тасками и схема сети
    • 13:30 - сеть не поднимается
    • 14:30 - сеть не поднимается
    • 16:00 - отмена ивента

Тот же таймлайн, но с дополнением того, как это происходило изнутри команды разработки:

  • 13 мая, первые мысли о проведении A/D тренировки внутри kks, создание репозитория, написание плана разработки
  • 22 мая, пост в канале
  • 23 мая, в первый раз поднят оркестратор виртуальных машин
  • 26 мая,
    • 17:55, появляются первые наброски сети
    • 20:45, репост SPbCTF
  • 27 мая
    • 01:48 - сеть не работает в принципе, вплоть до виртуальных адаптеров
    • 03:30 - сеть всё ещё не поднята, как резервный вариант готовятся виртуалки для VBox’а
    • 03:50 - одного из разработчиков посещает просветление и сеть начинает работать, второй разработчик в ахуе шоке
    • 04:43 - изоляция сети отсутствует, как класс
    • 04:54 - команда разработчиков ищет трафик в виртуальной сети img1
    • 05:38 - обнаружена миграция с iptables на nftables в debian 10, из-за чего перестали работать трейсы в iptables - отладка сети откладывается на время фикса этой проблемы
    • 16:04 - начинается активная разработка сервисов
    • 17:48 - у одного из разработчиков рождается новая идея для сервиса (третьего) - сервис в итоге разработан, но в релиз не включен
    • 22:10 - появляется второй сервис
  • 28 мая
    • 00:55 - появляется третий сервис
    • 01:00 - происходит обновление сети на новый формат шоу
    • 04:30 - готов бэкенд первого сервиса
    • 12:00 - готов чекер второго сервиса
    • Замена стомегабитного микротика на гигабитный.
  • 29 мая
    • 05:28 - готов фронтенд первого сервиса
    • 18:01 - поднят внешний сервак для VPN подключений игрокам
    • 21:00 - закрытие регистрации. Суммарно зарегистрировалось 96 человек.
  • 30 мая, день ивента
    • 01:31 - формируется план задач на деплой - 14 пунктов, полностью выполнены были только 7
    • 06:00 - команда разработки разбирается, как писать чекеры под форкад
    • 11:40 - в первый раз пытается подняться форкад (не поднимается)
    • 12:14 - ресерч мертвого форкада закончен, форкад начинает работать
    • 12:20 - два из трёх чекеров падают
    • 12:46
      • формируется зашифрованный архив с тасками
      • из 97 виртуальных машин - 16 начинают раскатку
    • 12:47 - выкладывается архив с тасками
    • 13:00 - пароль от архивов с тасками и схема сети
    • 13:30 - сеть не поднимается
    • 14:27 - те вулнбоксы, что таки смогли раскататься не могут подняться, т.к из-за багов в opennebula при создании из шаблона они получили 2Мб оперативы, вместо 2Гб
    • 14:30 - сеть не поднимается
    • 15:05 - 8 машин из 16, начавших раскатываться - раскатались
    • 16:00 - отмена ивента

Выводы

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

0b00

Тестирование, тестирование, и ещё раз тестирование! Особенно нагрузочное - must have.

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

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

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

0b01

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

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

0b10.0

Не переоценивать свои силы.

По большому счету, самый большой опыт организации A/D, который у нас был - это организация личной очной self-hosted a/d на человек 20. Сеть на нём представляла собой просто кучу ноутбуков и несколько свичей, соединенных в одну плоскую сеть. Ещё несколько делали маленькие online self-hosted для себя, но это почти не считается) Кроме того, на них мы обычно пользовались руцтфной журейкой.

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

Из этого пункта (и первого ещё) плавно вытекает следующий подпункт:

0b10.1

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

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

0b11

Планирование, планирование, планирование!

Красной линией через весь постмортем идут катастрофическое проблемы с планированием. Чего стоит только трата кучи времени на разработку третьего сервиса одним из админов. Вместо разработки инфры, да. Очень тупой ход.

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

О каком-то конкретном решении тут написать сложно, кроме того, что планированию всё же стоит уделять время.

мемы

RouterOS - это не сложно, инсайды разработчиков https://t.me/ntwrkmms/1270

img2

img3