1. Обзор и фон
На этапе тестирования проекта по созданию следующего поколения крупной больницы ежедневно происходило более десятка тысяч логов. Для быстрого выявления неисправностей и проверки качества в процессе тестирования было необходимо ежедневно проверять логи и классифицировать и систематизировать типы ошибок.
На тот момент составление отчетов об ошибках вручную занимало в среднем более 1 часа в день, а в дни с большим объемом логов это могло занять еще больше времени. Кроме того, из-за ручного труда существовала вероятность пропусков или неправильной классификации.
В связи с этим был разработан автоматизированный система с целями, указанными ниже.
-
Удаление повторяющейся ручной работы
-
Создание отчетной системы, способной надежно обрабатывать большие объемы логов
-
API предоставляет возможность каждому мгновенно создавать отчеты одинаковой формы
-
Структура разработана для гибкого реагирования на будущие требования к дополнительному анализу
В результате мы создали API для автоматизации отчетности в Excel на основе Apache POI, что позволило полностью автоматизировать процесс анализа логов, ранее выполнявшийся вручную.
2. Предпосылки внедрения Apache POI и процесс выбора технологий
2-1. Выбор формата отчетности
Сначала мы также рассматривали возможность предоставления данных в виде простого ответа JSON.
Однако в реальной практике тестирования большинство сотрудников проверяли данные на основе Excel, и поэтому мы пришли к выводу, что формат Excel наиболее подходит по следующим причинам.
-
Формат, с которым наиболее удобно работают тестировщики и пользователи на местах
-
Сортировка, фильтрация и условный поиск очень удобны
-
Дополнительный анализ и вторичная обработка легко выполняются
-
Удобно прикреплять и делиться электронными письмами, также можно сразу использовать в качестве отчетных материалов.
Особенно это не просто на уровне «просмотреть журналы», а скорее,
Я пришёл к выводу, что важно создавать результаты, которые можно использовать непосредственно в реальных операциях и тестовых площадках.
В связи с этим окончательный формат результатов был определён на основе Excel (.xlsx).
2-2. Причины выбора Apache POI
В процессе выбора библиотеки для создания Excel мы рассмотрели несколько вариантов.
Самым важным фактором, который я учитывал в этом процессе, были следующие моменты.
1) Надежность обработки больших объемов данных
Поскольку нужно было обрабатывать тысячи логов в день, стабильность памяти была самым важным фактором. Обычно библиотеки Excel загружали все данные в память, а затем создали файл, что создавало риск нехватки памяти (OOM) в условиях больших объемов данных.
Apache POI поддерживает SXSSF (потоковый режим), что позволило удерживать в памяти только часть данных при создании файла, что идеально подходит для обработки больших объемов.
2) Высокая совместимость с экосистемой Java
Поскольку весь бэкенд проекта был основан на Java + Spring, необходима была библиотека, которая могла бы естественно интегрироваться с Java-средой.
Apache POI был самой широко используемой библиотекой для обработки Excel в стандартной экосистеме Java,
-
имеет обширные ссылки по обслуживанию
-
Документация хорошо оформлена
-
В сообществе много примеров
-
Преимуществом было то, что стабильность была подтверждена.
Особенно из-за специфики проекта следующего поколения было важно использовать библиотеки с высокой универсальностью и стандартностью, поскольку нескольким разработчикам нужно было поддерживать проект вместе, а не полагаться на технологии, которые может понять только один человек.
3-1. Собранные логовые данные созданы в Excel на основе Apache POI
Сначала я преобразовал собранные логовые данные, полученные через API Loki для централизованной логирования, в структурированные объекты за определенный период времени, а затем создал отчет Excel, используя Apache POI.
Отчет составлен в следующем формате.
-
Лист с состоянием ошибок по услугам
-
Статистика кодов ошибок
-
Подробный журнал ошибок
-
Отчет о событиях по временным зонам
Каждый лист был реализован с возможностью динамического создания,
Мы спроектировали службу тестирования таким образом, чтобы она могла работать без дополнительных изменений, даже если сервис изменится.
3-2. Применение SXSSF и оптимизация памяти
Сначала я пытался реализовать это с помощью обычного XSSFWorkbook.
Однако в процессе обработки десятков тысяч логов использование памяти резко возросло, и фактически возникла угроза OOM.
Для этого я применил метод SXSSFWorkbook от Apache POI.
SXSSF имеет следующие характеристики.
-
Количество строк по расписанию сохраняется в памяти
-
Данные, превышающие лимит, сбрасываются во временный файл на диске
-
Можно создавать большие файлы с помощью потоковой передачи
Таким образом, нам удалось безопасно обрабатывать большие объемы логов, стабильно удерживая использование памяти.
Однако в SXSSF также существовали следующие ограничения.
-
Исправления в уже записанных строках невозможны.
-
Данные могут быть записаны только в последовательном порядке
-
Существуют ограничения на доступ к предыдущей строке
Поэтому при реализации были учтены следующие моменты.
-
Сначала определите заголовок/стиль
-
Предварительно спроектируйте порядок написания данных
-
Удалите логику, требующую последующей обработки
-
Структура листа была заранее определена
Понимание этих ограничений и их внедрение на этапе проектирования значительно помогло в стабильной реализации.
4. Заключение
С помощью разработки данной функции мы смогли сократить рабочее время вручную, которое занимало около 1 часа в день, до примерно 3 секунд, а также смогли значительно улучшить возможность анализа сбоев в отчетности, которая ранее оставалась на уровне простой проверки количества сообщений.
Я осознал, что для бэкенд-разработчика очень важно учитывать не только «код, который работает», но и масштаб данных, возможный в операционной среде, а также обслуживаемость и масштабируемость.
В будущем я хочу развиваться как разработчик, который, выходя за рамки простой реализации, будет думать о структурах, которые могут решать реальные проблемы и повышать операционную эффективность.
Новин
Список литературы