ИТ на ролевых играх, например.
Пост по мотивам прошедшей на майских игры на 100 человек.
На игре были:
В целом все взлетело и работало в нормальном режиме.
Программная часть представляет собой HTTP REST Api на которое навешиваются фронт-энды.
Само API - асинхронное Plack приложение. Расширяется модулями. Модули осуществляют проверку входных параметров и через Gearman создают задачи для исполнения воркерами.
Соответственно, приложение API не выполняет никаких ресурсоемких действий и способно обслуживать большие объемы запросов (на несколько порядков больше чем может быть сгенерировано на игре).
Бэкенд, при необходимости, масштабируется горизонтально. Как обычно вопрос к БД, но на игре (при грамотном написании ПО) очень сложно упереться в скорость БД вынесенной на отдельную машину.
Фронт-энды представляли собой асинхронные приложения на Mojolicious. Выбор фреймворка был сделал по принципу "я с ним работал больше всего". Т.к. приложения не выполняют никаких нетривиальных действий.
Единственное исколючение - система управления ЯО. По ТЗ она должна была быть независима от остальных и оставаться в работе в случае падения всего остального. Соответственно использовала собственную БД sqlite.
Логи со всех систем собирались в Graylog2. И из него выгружались в систему СБ после фильтрации.
Как оказалось очень удобная система. Все логи в одном месте и удобно фильтруются при помощи запросов к ElasticSearch. Так же Graylog предостваляет возможность настройки алертов если в логах есть что-то заданное. Но этой фичей мы не пользовались.
Аппаратная часть игрового ПО представляла собой 2 ноутбука на которых крутились виртуальные машины с игровым софтом.
Первый MacBook Pro, 8Gb оперативной памяти. Использовался как сервер для городского портала и системы блогов и в качестве резервного. Т.к. переодически радовал проблемами с SSD при выходе из спячки.
Второй HP Pavilion, 6Gb оперативки. На нем крутились 3 виртуальные машины со всем остальным.
Проблем такая конфигурация не практически не доставляла. Но надо наращивать объем памяти минимум до 8 гигабайт. Т.к. пул машин выжирает 3Гб, 1.5Гб выжирает ОС и, при наличии всего 6Гб на хост-машине, на второй день вся ОС выгружается в своп и при попытке что-то сделать на хост машине она тормозит. Это не сказывается на работе полигонного ПО, но создает дискомфорт при обслуживании.
Единственная проблема была при деплое ВМ с фронтэндом - первая попытка деплоя провалилась т.к. машина не нашла корневую ФС. Это странно, т.к. машины обслуживавшие фронтэнд и бэкэнд одинаковые и получены клоном одной и той же машины (девелоперской). Так же, после 3х дней работы, во время выключения эта машина вообще потеряла корневой диск и сейчас не пригодна к эксплуатации.
В данной ситуации это не является проблемой. Но этот момент следует учесть на будущее.
В принципе, загрузка машины была крайне незначительной. Так что, в дальнейшем, можно не разносить машины, а держать все на одной и клон этой же машины в горячем резерве.
Надо только настроить репликацию БД.
Главная ошибка - не была готова админка ко всем электронным системам полигона. Соответственно, нормально настраивать все эту красоту мог только я, что приводило к постоянной необходимости убегать с полигона в админскую.
Вывод: админка должна писаться ДО того как будет написана система.
Не была проверена работа блогов и порталов при отсутствии интернета. Оказалось что вордпресс тащит кучу всего с CDN и при отсутствии доступа жутко тупит. Проблема была решена на полигоне путем скачивания нужных ресурсов и заворачивания хостов, к которым шли запросы, на наши сервера. Систему я тестировал в работе перед выездом на полигон, но во время теста был интернет. И проблема не вылезла.
Вывод: Финальный тест всех систем должен проводить в условиях максимально приближенных к полигонным.
Скрипты обновления ПО не были рассчитаны на работу в локальной сети без доступа к интернету. Из-за этого часть изменений приходилось делать сразу в продакшене, что есть плохо и опасно.
Вывод: скрипты деплоя не должны рассчитывать на наличие интернета на продакшен машинах.
Остальные заморочки (как-то отсутствие списка всех транзакций для аудитора в банке) были с игровой механикой и к техническим проблемам не относятся.
На игре были:
- Банковская система
- Система для СБ/Полиции
- Модель управления тактическим ЯО
В целом все взлетело и работало в нормальном режиме.
Программная часть представляет собой HTTP REST Api на которое навешиваются фронт-энды.
Само API - асинхронное Plack приложение. Расширяется модулями. Модули осуществляют проверку входных параметров и через Gearman создают задачи для исполнения воркерами.
Соответственно, приложение API не выполняет никаких ресурсоемких действий и способно обслуживать большие объемы запросов (на несколько порядков больше чем может быть сгенерировано на игре).
Бэкенд, при необходимости, масштабируется горизонтально. Как обычно вопрос к БД, но на игре (при грамотном написании ПО) очень сложно упереться в скорость БД вынесенной на отдельную машину.
Фронт-энды представляли собой асинхронные приложения на Mojolicious. Выбор фреймворка был сделал по принципу "я с ним работал больше всего". Т.к. приложения не выполняют никаких нетривиальных действий.
Единственное исколючение - система управления ЯО. По ТЗ она должна была быть независима от остальных и оставаться в работе в случае падения всего остального. Соответственно использовала собственную БД sqlite.
Логи со всех систем собирались в Graylog2. И из него выгружались в систему СБ после фильтрации.
Как оказалось очень удобная система. Все логи в одном месте и удобно фильтруются при помощи запросов к ElasticSearch. Так же Graylog предостваляет возможность настройки алертов если в логах есть что-то заданное. Но этой фичей мы не пользовались.
Аппаратная часть игрового ПО представляла собой 2 ноутбука на которых крутились виртуальные машины с игровым софтом.
Первый MacBook Pro, 8Gb оперативной памяти. Использовался как сервер для городского портала и системы блогов и в качестве резервного. Т.к. переодически радовал проблемами с SSD при выходе из спячки.
Второй HP Pavilion, 6Gb оперативки. На нем крутились 3 виртуальные машины со всем остальным.
Проблем такая конфигурация не практически не доставляла. Но надо наращивать объем памяти минимум до 8 гигабайт. Т.к. пул машин выжирает 3Гб, 1.5Гб выжирает ОС и, при наличии всего 6Гб на хост-машине, на второй день вся ОС выгружается в своп и при попытке что-то сделать на хост машине она тормозит. Это не сказывается на работе полигонного ПО, но создает дискомфорт при обслуживании.
Единственная проблема была при деплое ВМ с фронтэндом - первая попытка деплоя провалилась т.к. машина не нашла корневую ФС. Это странно, т.к. машины обслуживавшие фронтэнд и бэкэнд одинаковые и получены клоном одной и той же машины (девелоперской). Так же, после 3х дней работы, во время выключения эта машина вообще потеряла корневой диск и сейчас не пригодна к эксплуатации.
В данной ситуации это не является проблемой. Но этот момент следует учесть на будущее.
В принципе, загрузка машины была крайне незначительной. Так что, в дальнейшем, можно не разносить машины, а держать все на одной и клон этой же машины в горячем резерве.
Надо только настроить репликацию БД.
Главная ошибка - не была готова админка ко всем электронным системам полигона. Соответственно, нормально настраивать все эту красоту мог только я, что приводило к постоянной необходимости убегать с полигона в админскую.
Вывод: админка должна писаться ДО того как будет написана система.
Не была проверена работа блогов и порталов при отсутствии интернета. Оказалось что вордпресс тащит кучу всего с CDN и при отсутствии доступа жутко тупит. Проблема была решена на полигоне путем скачивания нужных ресурсов и заворачивания хостов, к которым шли запросы, на наши сервера. Систему я тестировал в работе перед выездом на полигон, но во время теста был интернет. И проблема не вылезла.
Вывод: Финальный тест всех систем должен проводить в условиях максимально приближенных к полигонным.
Скрипты обновления ПО не были рассчитаны на работу в локальной сети без доступа к интернету. Из-за этого часть изменений приходилось делать сразу в продакшене, что есть плохо и опасно.
Вывод: скрипты деплоя не должны рассчитывать на наличие интернета на продакшен машинах.
Остальные заморочки (как-то отсутствие списка всех транзакций для аудитора в банке) были с игровой механикой и к техническим проблемам не относятся.