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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Помогаете devby = помогаете ИТ-комьюнити.

Засапортить сейчас.