Прийшов час осідлати справжнього Буцефала🏇🏻Приборкай норовливого коня разом з Newxel🏇🏻Умови на сайті
×Закрыть

Повышаем стабильность игрового клиента с помощью сервиса Crash reporting: опыт Wargaming

Підписуйтеся на Telegram-канал «DOU #tech», щоб не пропустити нові технічні статті.

Привет! Я работаю системным аналитиком в киевской студии Wargaming. Мой департамент — Platform — занимается разработкой околоигровых сервисов для оперирования и поддержки игр, которые помогают нашим играм зарабатывать, стабильно функционировать и быть удобными для игроков.

Вместе с командой из 10 человек я разрабатываю один из таких сервисов — Crash Analysis Tool (CAT).

Один из важных аспектов разработки и поддержки игровых клиентов — оценка их стабильности, которая чаще всего рассчитывается соотношением количества сбоев (crash) к количеству игровых сессий или запусков клиента в единицу времени. В статье я поделюсь опытом разработки и внедрения сервиса Crash reporting и о его влиянии на стабильность игровых клиентов Wargaming. Надеюсь, наш опыт будет полезен не только игровым разработчикам, но и всем, кто занимается разработкой систем, в которых есть удаленные клиенты, например IoT-проектам.

CAT — инструмент для мониторинга работоспособности приложений и решения проблем с багами и сбоями наших игр и внутренних инструментов разработки. Многие наши игры и инструменты используют CAT: World of Tanks, World of Warships, платформа Wargaming Game Center, World Editor (инструмент для создания карт для художников) и WoWS Mod Station (инструмент для модов).

Зачем нужен Crash reporting-сервис

На рынке есть много готовых решений для анализа сбоев, подавляющее большинство которых предназначены для мобильных клиентов. Для desktop/PC клиентов предложений немного, а решение, которое удовлетворило бы запросы больших и сложных проектов с миллионами игроков, как World of Tanks или World of Warships, найти и вовсе сложно.

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

Так и возникла идея разработать сервис, который помог бы разработчикам и студиям решать проблемы с багами и сбоями на разных этапах разработки — Crash Analysis Tool.

CAT на разных стадиях жизненного цикла игры

Каждая стадия разработки и поддержки игры важна по-своему, но анализ сбоев одинаково важен для всех. На этапе разработки CAT помогает командам Automation Testing собирать больше информации о воспроизводимых багах. Инструмент интегрирован с JIRA, благодаря чему собранные метаданные падения, логи приложения, memory dump, dxdiag автоматически прикрепляются к задаче.

На этапе закрытого тестирования (Beta, Common Test) команды разработки с помощью САТ быстро получают информацию, необходимую для оценки стабильности версии, и репорты об ошибках. Это позволяет быстрее приступить к исправлению багов и, соответственно, выпустить новую версию.

На этапе релиза на прод, САТ помогает разработчикам быстро реагировать на массовые сбои и зависания до того, как пользователи начнут обращаться в поддержку.

Помимо инженеров-разработчиков и тестировщиков, САТ также помогает нашим коллегам-дизайнерам и художникам, которые занимаются разработкой карт в World Editor. В случае сбоя, например, у дизайнера, работающего с World Editor, ему больше не нужно пытаться воспроизвести ошибку: CAT собирает сведения об ошибках, анализирует их и автоматически создает задачу в JIRA со всей информацией, необходимой для решения проблемы.

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

Игры, интегрированные с CAT, могут отслеживать такие типы событий, как Crash, Assert (invariant check), UI Freeze, Abnormal exit.

Любая игра или инструмент на winapi может интегрироваться с CAT. И не только на winapi — нужно лишь добавить компонент для совместимости с другими системами.

Кроме этого, CAT мониторит собственную стабильность.

Как работает CAT

Инструмент состоит из 4 компонентов: CAT Monitor, CAT Receiver, CAT Resolver, CAT Office. Рассмотрим более детально структуру и функции каждого компонента.

CAT Monitor

Компонент поставляется как часть приложения и собирает отчеты о сбоях со всей необходимой информацией и отправляет их в CAT Receiver. CAT Monitor состоит из таких модулей:

ErrorMonitor — приложение, которое запускается вместе с клиентом игры и позволяет мониторить приложение «out of process».

ClientLib — библиотека, которая интегрируется непосредственно в игровой клиент для инициализации работы CAT Monitor. В некоторых случаях позволяет обрабатывать ошибки «in process».

Monitor plugins — дополнительная функциональность для корректной работы с приложениями, разработанными на Unreal Engine, Unity и интеграции с другими специфическими движками и системами.

В обычном режиме работы приложения CAT Monitor собирает и отправляет на CAT Receiver только статистические данные:

  • количество запусков приложений за час
  • версия запущенного приложения

В случае сбоя работы приложения (перезапуска или зависания игры), в зависимости от вида сбоя и конфигурации самого CAT Monitor, он может собирать такие данные:

  • логи работы приложения
  • дамп памяти с заранее настроенным наполнениеи
  • информацию про конфигурацию приложения
  • информацию про конфигурацию ПК (версия ОС, количество и тип процессоров, количество и тип графических адаптеров и другое)
  • системную информацию, полученную через DxDiag

Все данные упаковываются в архив и отправляются на сервер, если пользователь дал согласие на отправку.

CAT Receiver

Receiver — централизованный сервер для регистрации и приема отчетов от CAT Monitor. CAT Receiver использует ceph для хранения артефактов, но есть возможность использовать любую другую файловую систему для хранения.

С помощью админ-панели CAT Receiver можно переопределить конфигурацию удаленных клиентов (CAT Monitor), например, чтобы для определенного типа ошибки принимать определенный набор артефактов, установить лимит запросов от одного физического устройства и другие настройки приема и обработки отчетов.

Архитектура CAT Receiver

С помощью реализации HyperLogLog в Redis агрегируется статистика по количеству сессий клиента.

Для быстрого подключения новых приложений реализована возможность горизонтального масштабирования CAT Receiver.

Логическая репликация Postgres используется для передачи данных в CAT Office определенной команды разработки или целой студии.

CAT Resolver

Resolver отвечает за анализ дамп-файла, предоставляя на выходе данные, необходимые для выявления причины ошибки.

Архитектура CAT Resolver

Утилита WinDbg используется непосредственно для «расшифровки» дампа и получения стека вызовов, которые привели к ошибке.

Разработчик может указать адрес своих персональных символ-серверов, или использовать открытые символ-сервера Microsoft, Nvidia, Unreal и т.п.

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

CAT Office

Этот компонент обрабатывает результаты, полученные от CAT Resolver, и группирует все обнаруженные сбои по заданным правилам. Набор микросервисов обеспечивает преобразование событий в отчеты, их группирование по общему признаку, создание issue, а также расчет статистики после анализа дампов.

Архитектура CAT Office

Для каждого уникального сбоя CAT Office дает возможность создать задачу в JIRA вручную или автоматически по заданным критериям, например, если количество отчетов превышает N. Это экономит время разработчиков — вместо копания в дамп-файле в поисках соответствующих данных, разработчики сразу получают всю информацию, необходимую для устранения проблемы, аккуратно упакованную в задачу JIRA.

CAT Office отображает все собранные данные, статистику, аналитику с огромным количеством и разнообразием фильтров и настроек для любых полученных и обработанных данных.

Realtime статистика crash rate

Пользователи могут посмотреть информацию о любой конкретной проблеме, а также расширенный анализ работоспособности для любой конкретной сборки приложения, проверить появление ошибок на основе версий, ОС, периода времени или любого другого параметра метадаты отчета.

Статистика по issue

Планы по развитию

Сегодня Crash Analysis Tool — уже готовый инструмент, но у нас есть еще много векторов развития. Выделю 5 основных:

Кроссплатформенность. Для поддержки большего количества игр, мы планируем реализовать поддержку платформ Linux, XBOX, PS4.

Интеграция с большим количеством языков программирования. Сейчас CAT можно использовать в C/С++ и C# приложениях, в том числе в приложениях, разработанных на движках Unity и Unreal Engine. Мы работаем над интеграцией с Python, Rust и Java.

Улучшение логики группирования репортов. Одна из самых интересных и сложных задач систем Crash reporting — создать оптимальный алгоритм группировки событий для учета различных факторов: callstack, OS version, library version, error type, error message. Для этого мы уже начали внедрять machine learning механизм кластеризации, который позволит выработать оптимальную группировку для каждой из поддерживаемых платформ, а также для более точной фильтрации событий. Все события будут сохранены на сервере, но для повторяющихся событий идентичная информация собираться не будет.

3rd-party интеграции. К существующим интеграциям с Jira, Stash, MS Teams (webhooks), мы будем добавлять другие сервисы, которые используются нашими клиентами в их бизнес процессах.

Улучшение взаимодействия с Easy Anti Cheat

Что получили мы, как компания, разработав и внедрив Crash Analysis Tool?

  • У команд разработки появилась возможность находить и понимать причины как типовых падений, так и таких, которые были неизвестны или сложно исследуемы.
  • Благодаря раннему мониторингу на этапах super test и common test значительно снизилось количество падений в день релиза новой версии на production.
  • Игровые разработчики существенно увеличили скорость реакции на неисправности, что помимо фактического снижения crash rate также позитивно влияет и на customer satisfaction: игроки получают необходимые исправления еще до того, как успеют оставить жалобу или в принципе встретятся с неисправностью.
  • Появилась возможность автоматизировать ряд бизнес-процессов внутри команд разработки.

А как вы мониторите работоспособность приложений?

LinkedIn

Похожие статьи

Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Интересно, чем не устроил AppCenter?

Спасибо большое за вопрос. AppCenter — очень хорошеее решение от MS, но как и множество других сервисов ориентировано больше на мобильные приложения. У них есть поддержка desktop apps на базе UWP , WPF , WinForms и Unity, но нет поддержки C++ приложений, которая нам была необходима. Помимо этого, разработка собственного сервиса позволяет кастомизировать функционал под воркфлоу наших студий разработки. И, конечно же, поддержка взаимодействия с античитами.

Да, у Sentry есть поддержка С++ , но мы выбрали путь собственного решения по следующим причинам:
— объем обрабатываемой информации на наших продакшн площадках определяет серьезные требования к системе, мы не были уверены, что Sentry их удовлетворит и это не будет стоить всех денег мира :)
— нам необходима гибкость и скорость в работе со специфическими запросами от игровых команд
— интеграция с корпоративными системами позволила автоматизировать ряд бизнес-процессов внутри команд разработки
Также, САТ должен был стать и стал частью платформы Wargaming, о которой ранее рассказывал мой коллега на другом ресурсе:
habr.com/...​ny/wargaming/blog/434004

Подписаться на комментарии