Реклама в Telegram-каналах DzikPic и dev.by теперь дешевле. Узнать подробности 👨🏻‍💻
Support us

BI: Устранение проблем с производительностью оффлайн, или 10 часов тому вперед

Оставить комментарий
BI: Устранение проблем с производительностью оффлайн, или 10 часов тому вперед

В течение нескольких последних лет я работал на проекте, связанном с анализом производительности и настройкой BI отчетов и ETL (Extraction, Transformation, Load) процессов. Несмотря на то, что нашей основной целью был анализ производительности BI приложений (Oracle BI applications), мы также участвовали в анализе проблем, связанных с недостаточной производительностью различных заказчиков. Все проблемные случаи с  производительностью объединяло одно общее свойство: как правило, мы не могли напрямую связаться с заказчиком, у нас не было доступа к серверам заказчика, а также мы работали в другом часовом поясе (с разницей во времени 7-10 часов). Ниже я хочу рассмотреть несколько простых способов, которые мы применяли для выполнения задач подобного рода. 

Узнать больше

1. Начинаем задавать вопросы

Создаем документ со списком стандартных вопросов заказчику о профиле оборудования и конфигурации базы данных, просим заказчика ответить на эти вопросы.

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

  • точного объяснения ситуации. Общая информация о проблеме не позволит выяснить точную причину снижения темпа работы;
  • какого-либо свидетельства проблем с производительностью (журналы регистрации ошибок, AWR отчеты, файлы трассировки и любую другую информацию, которая могла бы прояснить потенциальную проблему);
  • шагов для воспроизведения этой ситуации;
  • текущих объемов данных в базе;
  • количества данных, переданного ETL процессами;
  • количества строк, сгенерированных BI отчетом;
  • любой другой информации, которую сочтем ценной.

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

2. Ни в коем случае не торопимся

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

  • изменение конфигурации системы;
  • изменение конфигурации базы данных;
  • какие-либо изменения в объемах данных;
  • какие-либо обновления программного обеспечения;
  • количество пользователей, одновременно работавших с системой.

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

3. Ведем статистику

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

Сразу создаем свой собственный способ хранения, обработки и получения отчетов по этим статистическим данным в более или менее стандартном виде. Это может быть таблица Excel или даже маленькое веб-приложение, позволяющее отображать статистику разными способами и помогающее анализировать и сравнивать похожие проблемы, о которых сообщают разные заказчики.

4. Анализируем

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

5. Устраняем неполадки

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

6. Ведём журнал наших исследований

Каждое действие, которое мы производим в рамках анализа конкретной проблемы, должно быть задокументировано. Любое wiki-пространство может помочь сохранить все, что было обнаружено в ходе анализа и фазы исправления проблемы. Такая практика позволяет сохранить все результаты работы и быстро найти решение в будущем при возникновении схожих проблем. Эта информация также позволит совмещать все находки, методы, исправления кода в одном документе с указаниями по оптимизации производительности приложения.

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

Новый рекламный формат в наших телеграм-каналах.

Купить 500 символов за $150

Читайте также
Старые iPhone начинают работать быстрее, если сменить регион на Францию
Старые iPhone начинают работать быстрее, если сменить регион на Францию
Старые iPhone начинают работать быстрее, если сменить регион на Францию
Samsung выпустила приложение для настройки процессора смартфона
Samsung выпустила приложение для настройки процессора смартфона
Samsung выпустила приложение для настройки процессора смартфона
«Есть шанс превратить Fibery в компанию на миллиард долларов». Михаил Дубаков о новом продукте, «сожжённом» $1 млн и выгорании
«Есть шанс превратить Fibery в компанию на миллиард долларов». Михаил Дубаков о новом продукте, «сожжённом» $1 млн и выгорании
«Есть шанс превратить Fibery в компанию на миллиард долларов». Михаил Дубаков о новом продукте, «сожжённом» $1 млн и выгорании
В конце февраля вышла бета-версия Fibery — нового продукта компании Targetprocess, «относительно стабильной, умеренно быстрой» платформы для управления компаниями. Тогда же dev.by попросил руководителя проекта Михаила Дубакова об интервью, но он предложил подождать месяц-другой, пока соберётся фидбек.
Fibery, новая система для управления компаниями от Михаила Дубакова, начала бета-тестирование
Fibery, новая система для управления компаниями от Михаила Дубакова, начала бета-тестирование
Fibery, новая система для управления компаниями от Михаила Дубакова, начала бета-тестирование

Хотите сообщить важную новость? Пишите в Telegram-бот

Главные события и полезные ссылки в нашем Telegram-канале

Обсуждение
Комментируйте без ограничений

Релоцировались? Теперь вы можете комментировать без верификации аккаунта.

Комментариев пока нет.