В течение нескольких последних лет я работал на проекте, связанном с анализом производительности и настройкой BI отчетов и ETL (Extraction, Transformation, Load) процессов. Несмотря на то, что нашей основной целью был анализ производительности BI приложений (Oracle BI applications), мы также участвовали в анализе проблем, связанных с недостаточной производительностью различных заказчиков. Все проблемные случаи с производительностью объединяло одно общее свойство: как правило, мы не могли напрямую связаться с заказчиком, у нас не было доступа к серверам заказчика, а также мы работали в другом часовом поясе (с разницей во времени 7-10 часов). Ниже я хочу рассмотреть несколько простых способов, которые мы применяли для выполнения задач подобного рода.
1. Начинаем задавать вопросы
Создаем документ со списком стандартных вопросов заказчику о профиле оборудования и конфигурации базы данных, просим заказчика ответить на эти вопросы.
Кроме того, пробуем сузить критерии поиска для определения причины проблемы с производительностью, задав дополнительные вопросы на предмет:
- точного объяснения ситуации. Общая информация о проблеме не позволит выяснить точную причину снижения темпа работы;
- какого-либо свидетельства проблем с производительностью (журналы регистрации ошибок, AWR отчеты, файлы трассировки и любую другую информацию, которая могла бы прояснить потенциальную проблему);
- шагов для воспроизведения этой ситуации;
- текущих объемов данных в базе;
- количества данных, переданного ETL процессами;
- количества строк, сгенерированных BI отчетом;
- любой другой информации, которую сочтем ценной.
Эти данные позволят сопоставить полученные ответы с другой статистикой. Например, информация о серверах заказчика, версии операционной системы, количестве памяти, и др. помогут представить, насколько мощно оборудование заказчика, настройки базы данных могут указать на проблемы с конфигурацией базы данных, и т.д.
2. Ни в коем случае не торопимся
Необходимо дать заказчику понять, что вам требуется время подумать. Любая система уникальна по своим характеристикам, и идентификация первопричины проблемы может занять немалое количество времени. Продолжайте по необходимости задавать вопросы, чтобы сузить критерии поиска. Очень важно понять, были ли сделаны какие-либо изменения в системе до появления проблем с производительностью. Это может быть:
- изменение конфигурации системы;
- изменение конфигурации базы данных;
- какие-либо изменения в объемах данных;
- какие-либо обновления программного обеспечения;
- количество пользователей, одновременно работавших с системой.
Все сведения, поступившие от заказчика, требуют глубокого анализа, который занимает определенное время. Поскольку процесс настройки производительности – это итеративный процесс, может потребоваться дополнительный шаг для прояснения ситуации, поэтому продолжайте задавать уточняющие вопросы
3. Ведем статистику
Каждый ответ, предоставленный заказчиком, является частью статистических данных. Если мы работаем с одним приложением, используемым несколькими заказчиками, сбор статистики может дать информацию о наиболее частых проблемах, равно как и о наиболее проблемных местах в приложении.
Сразу создаем свой собственный способ хранения, обработки и получения отчетов по этим статистическим данным в более или менее стандартном виде. Это может быть таблица Excel или даже маленькое веб-приложение, позволяющее отображать статистику разными способами и помогающее анализировать и сравнивать похожие проблемы, о которых сообщают разные заказчики.
4. Анализируем
При наличии статистики, полученной от заказчика, и исторической статистики, собранной для этой системы, не так трудно определить точное проблемное место. И опять же, продолжаем задавать вопросы, если нам нужно больше информации.
5. Устраняем неполадки
Как только проблема обнаружена, делаем изменения в коде или конфигурации, тестируем на своей среде, если это возможно, и просим заказчика протестировать. При этом постоянно собираем статистику по производительности для нашего решения и сравниваем с первоначальным результатом.
6. Ведём журнал наших исследований
Каждое действие, которое мы производим в рамках анализа конкретной проблемы, должно быть задокументировано. Любое wiki-пространство может помочь сохранить все, что было обнаружено в ходе анализа и фазы исправления проблемы. Такая практика позволяет сохранить все результаты работы и быстро найти решение в будущем при возникновении схожих проблем. Эта информация также позволит совмещать все находки, методы, исправления кода в одном документе с указаниями по оптимизации производительности приложения.
Возможно, для опытных специалистов эти советы будут не столь актуальными. Я больше чем уверен, что за время общения с заказчиками команды уже успели построить свою собственную схему коммуникаций. Но я буду искренне рад, если кто-то, кто видит недостатки своего процесса, после прочтения моего поста найдет для себя что-то полезное. Даже в отношении себя и своей команды не могу сказать, что мы нашли универсальный для всех случаев жизни способ. Будет новый проект, и будут новые задачи. И мы будем учиться дальше не на своих ошибках, а на своем опыте.
Релоцировались? Теперь вы можете комментировать без верификации аккаунта.