Проекты, связанные с тестированием и аналитикой производительности, терпят неудачу по целому ряду причин. Большинство этих проблем происходит по различным и весьма сложным причинам на каждом этапе жизненного цикла разработки и тестирования производительности. Иногда проблемы с производительностью просто не поддаются контролю и их не под силу решить ни менеджеру проекта, ни ИТ-архитекторам или даже непосредственно инженерам по производительности. По моему опыту (как деловому, так и личному) — большинство проектов по повышению КПД терпят неудачу из-за простого недостатка общения между инженерами по производительности, разработчиками, DBA (администраторы баз данных), бизнес-командами и заинтересованными сторонами (стейкхолдеры).

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

Неудачи в проектах с тестами производительности должны рассматриваться так же, как и другие проблемы бизнеса. Важно понять, что пошло не так, почему это пошло не так, и что можно сделать, чтобы предотвратить возникновение таких проблем в будущем. В большинстве сценариев инженеры по производительности должны устраивать «театр одного актёра», чтобы заставить всех коллег изучить и понять проблемы эффективности в сквозных реализациях полного жизненного цикла (end-to-end full life cycle). Работая с командами тестировщиков и CoE (центр передового опыта), мы продолжали видеть одни и те же повторяющиеся ошибки от многочисленных компаний и проектов, поэтому, основываясь на своём личном опыте, я составил список причин, почему проекты по повышению КПД терпят неудачу.

1. Непонятные и непроработанные нефункциональные требования (NFR)

Сбор всех нефункциональных требований сложнее, чем функциональные требования, поскольку они рассматриваются как требования второго или даже третьего плана. В результате они часто упускаются, неправильно понимаются, игнорируются, и есть лишь несколько организаций и заинтересованных сторон, которые фокусируются на NFR как на требованиях высшего приоритета. Такой подход приводит к серьёзным проблемам в пользовательском взаимодействии с архитектурой и дизайном системы, а также к срывам проектов и сбоям в работе веб-сайтов, подобно сбою на Чикагской бирже опционов (CBOE), который привёл к полной неработоспособности системы.

В большинстве случаев документ NFR был неполным, непоследовательным или, как в большинстве неудачных проектов по тестированию производительности, не существовал вовсе. Первым шагом в жизненном цикле тестирования КПД является проведение анализа целесообразности приложения/системы и создание чёткого набора нефункциональных требований для успешного проведения тестирования производительности. Тщательно проработанный документ NFR определит все критерии, которыми должен обладать продукт или приложение, чтобы успешно и с наилучшей производительностью работать в продакшене.

Кроме того, необходимо:

• Установить однозначные цели по уровню КПД и ожидаемые результаты для продукта/приложения и системы в целом.
• Добиться того, чтобы все (инженеры по производительности, команды разработчиков, команды администраторов, DBA, бизнес-команды и другие заинтересованные стороны) были на одной волне.
• Построить коммуникацию между техническими, проектными и бизнес командами, чтобы понять реальные проблемы с производительностью у конечных пользователей в релизном продукте.
• Использовать аналитические инструменты, такие как Alexa, Pingdom, Google Analytics и Omniture, чтобы получить статистику клиентского трафика для создания подходящих моделей рабочей нагрузки.
• Разобраться в архитектуре, дизайне, общих проблемах и проблемах с производительностью вашего продукта/приложения во время сбора нефункциональных требований.
• Добиться того, чтобы нефункциональные требования обсуждались с самого начала процесса разработки ПО и на протяжении всего его жизненного цикла. Для тестирования производительности, если приложение является совершенно новым, необходимо провести базовое тестирование и сравнительный анализ.
• Получить полную информацию обо всех внутренних и внешних компонентах, а также понять — как они взаимодействуют друг с другом (CDN, брандмауэры, DNS, балансировщик нагрузки, серверы, сети и системы, кеш и т.д.).
• Рассмотреть возможность распределения бизнес-целей на системные требования по части производительности.
• Разобраться в технических ограничениях размера приложения, решений от сторонних разработчиков и архитектуры в целом.
• Поговорить с бизнес-командами и другими заинтересованными сторонами, чтобы понять цели и определить, какие из них являются наиболее важными. Разобрать существующие проблемы с производительностью и ограничения платформы, а также понаблюдать за конкурентами.
• Приготовиться всё задокументировать, собрать заинтересованные стороны бизнеса и ИТ на одном собрании и определить — применимы ли существующие NFR, а также обсудить соглашение об уровне услуг (SLA), которое может быть достигнуто.

2. Менеджеры и заинтересованные стороны не понимают/не слушают конечных пользователей, которые выражают сильную озабоченность по поводу производительности приложения

Разговор с конечными пользователями может выявить существующие потенциальные проблемы производительности, о которых вы и не знали. Чтобы выявлять существующие проблемы в нагруженности релизных систем, нам необходимо получать постоянную обратную связь от конечных пользователей о том, как приложение ведёт себя в различных предполагаемых условиях нагрузки. Всегда есть множество пользователей, которые всё равно будут использовать какую-либо функцию в клиентской версии, даже если она не будет соответствовать их ожиданиям по части желаемого отклика. Они просто не станут подвергать её сомнению и будут считать, что всё работает корректно, а это впоследствии может стать большой проблемой для многих, когда доступ к этой функции будет осуществляться из нескольких мест одновременно. Поэтому, если вы хотите улучшить производительность вашего приложения, вы должны привлечь конечных пользователей, чтобы получать постоянную обратную связь о приложении и эффективности системы в продакшене. Конечно, взаимодействие с пользователями требует времени и усилий, а иногда даже кажется невозможным. Тем не менее оно определённо стоит того, если у вас стоит цель обеспечить максимальную производительность для конечного продукта или приложения.

3. Плохой дизайн архитектуры

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

4. Непредусмотренные технологические зависимости

Зависимость — это связь между компонентами, которая позволяет расширить возможности и функциональность приложения. Определённые версии ОС, серверы приложений, серверы баз данных или виртуальные машины Java, общеязыковая исполняющая среда и фреймворк dotnet — являются примерами простых зависимостей. Однако некоторые зависимости являются более сложными, например, зависимости, состоящие из различных пакетов в Linux, Java и скриптовых языков, таких как Python и Ruby. Понимание зависимости каждой технологии от каждого компонента (с точки зрения дизайна и инфраструктуры): «какие технологии, фреймворки и инструменты?» — всё это имеет решающее значение для каждого инженера по производительности, если они хотят провести тестирование с желаемыми результатами.

5. Отсутствие должного внимания к целям по производительности

Постановка целей является одним из наиболее важных аспектов успеха в тестировании производительности. Многие инженеры по оптимизации и другие члены команды постоянно не достигают своих целей по улучшению производительности, тратя много времени на исправление существующих и неочевидных проблем с производительностью в приложении/системе. Цели для perfomance-тестов должны быть определены, разработаны и выполнены с наиболее реалистичными условиями, такими как фактически используемые браузеры и устройства, а также несколько географических местоположений и т.п. Определение правильных метрик для мониторинга (какой тип производительности мы измеряем, определение минимальных пороговых значений для каждой метрики, выполнение perfomance-тестов для получения базовых результатов) необходимо для того, чтобы выявить, какие изменения могут улучшить КПД. Отличной практикой является раннее начало тестирования эффективности в жизненном цикле разработки ПО, для чтобы устранить узкие места в первую очередь и гарантировать, что ваше приложение постоянно проверяется на быстроту процессов при высокой пользовательской нагрузке.

6. Чрезмерное расширение количества новых функций и изменений в последний момент каждого релиза

Чрезмерное расширение функциональных возможностей — это распространённое и основное препятствие, с которым сталкиваются разработчики ПО и инженеры по производительности. Самый эффективный способ справиться с этой ситуацией — регулярно проводить встречи и обсуждения с участием каждого члена команды, чтобы проверить каждую функцию и убедиться, что она действительно решает ту проблему, которую вы поставили перед собой. Команды тестировщиков КПД должны начинать с планирования тестовых сред и графиков выпуска, а также заранее сообщать, сколько времени им необходимо для тестирования приложения (с точки зрения продуктивности) на тот случай, если какие-либо новые функции будут добавлены в последнюю минуту выпуска. Если ваш проект имеет фиксированный дедлайн — планируйте требования к среде заранее, чтобы непредвиденные задержки среды не повлияли на график perfomance-тестов. Предположим, что разработчики и команды продолжают добавлять функции в последнюю минуту — в этом случае качество конечного продукта будет неизбежно страдать. В конечном счёте заказчики отвергнут финальные наработки, создав сценарий переделок и дополнительной нехватки ресурсов.

7. Сосредоточение только на сиюминутном успехе

Сосредоточенность на целевых SLA для достижения допустимых пределов (стандартного для отрасли времени отклика) может быть невозможным на самых первых запусках тестирования. Это циклический процесс, который требует много непрерывных perfomance-тестов для выявления и устранения всех узких мест в производительности. Соответствующие инженеры должны тратить дополнительное время на оптимизацию каждой строки кода и компонента для повышения КПД в системе/приложении. Каждый SLA и KPI необходим для тестов и получения желаемого времени отклика, пропускной способности, сетевой задержки и утилизации ресурсов. Всё это возможно только при вышеупомянутых тестах, профилировании кода, профилировании памяти, проектировании нагруженности, мониторинге и настройке как со стороны клиента, так и со стороны сервера, что иногда может занимать годы. Анализ всех результатов эффективности и деградации, сбор данных с использованием соответствующих метрик с пользовательского уровня, уровня ОС, системного уровня, сетевого уровня и уровня сервера — имеет решающее значение для всех инженеров по производительности, если они хотят осуществить анализ первопричин (RCA).

8. Неудачное планирование по наращиванию производственных мощностей

По своему опыту могу сказать, что существует множество различных причин, по которым многим инфраструктурам не удаётся внедрить эффективное планирование по увеличению мощностей. Проще говоря, процесс планирования мощностей не является таким уж лёгким и понятным. Мы можем создать сценарий, добавить трафик, оценить результаты, решить проблемы оптимизации и повторять до тех пор, пока не будем удовлетворены, но на деле — основная проблема возникает при неэффективном планировании потенциальной нагрузки. Некачественное планирование пропускной способности проекта увеличивает вероятность того, что его цели не будут достигнуты, а все риски станут совершенно очевидными, что в конечном счёте приведёт к полному провалу. Всего этого можно избежать, если правильно решить эти проблемы с помощью тщательного планирования наращивания мощностей. Системные аналитики (из области инфраструктуры), программисты-аналитики (из области разработки приложений) и администраторы баз данных — это три группы людей, которые должны быть наиболее вовлечены в работу по эффективному планированию мощностей. Многие из нас иногда путают управление мощностями с планированием нужных мощностей, а инженеры по производительности, наряду с другими командами, не могут точно спрогнозировать и предсказывать неправильный будущий объём рабочих нагрузок. Инженеры обязательно должны убедиться, что мы определяем точные требования к ресурсам (процессор, память, дисковое пространство и пропускная способность сети) для поддержки текущих и будущих повышенных нагрузок, чтобы удовлетворить требования бизнеса и избежать сбоев в планировании мощностей. Непрерывный мониторинг с правильными метриками поможет нам эффективно спланировать потребность в наращивании мощностей, а также справиться с неожиданными будущими рабочими нагрузками с повышенным трафиком.

9. Отсутствие отлаженной методической базы

Из-за отсутствия надлежащей методической основы при создании стратегии тестирования КПД становится очень трудно получить нормальные результаты. Понимание методологии тестирования и самого процесса поможет каждому инженеру в команде (особенно при возникновении проблем с производительностью), давая правильное решение для каждого возникшего в системе узкого места. Процессы тестирования должны быть хорошо спланированы, определены и детально задокументированы. Благодаря выстроенной документации появится эффективная коммуникация между разработчиками, DBA'ами и инженерами по производительности. Поскольку приложения становятся более сложными и многогранными, а также в связи с растущим числом платформ и мест для тестирования, становится действительно важно иметь надёжную методологию для обеспечения наиболее полного тестирования КПД разрабатываемых приложений и систем. Важно убедиться, что они отвечают всем установленным бизнес-требованиям и могут успешно работать во всех предполагаемых условиях нагрузки и средах с необходимой продуктивностью и мощностью.

10. Нерешённые проблемы с КПД

Ещё больше проблем с КПД наблюдается при увеличении числа пользователей приложения. Незамеченные и уже известные проблемы с нагрузкой в приложении/системе с течением времени становятся основными причинами постоянного снижения продуктивности. Каждое выявленное узкое место должно быть рассмотрено с каждым членом команды в проекте для успешного обеспечения должной скорости работы в соответствии с SLA клиента. Когда дело доходит до проблем с производительностью, каждая минута на счету, и если вы проигнорируете существующие проблемы — ваши приложения и системы будут работать значительно медленнее или даже хуже. Например, некоторые службы могут и вовсе перестать работать на сильно перегруженном сервере, и приложение будет недоступно. Думаю, что мы не хотим терять время на выяснение того, что пытаются сказать вам данные мониторинга, если критически важная служба не работает. Следовательно, полезно быть заранее знакомым с методами обнаружения и наиболее распространёнными причинами проблем с производительностью сервера.

---

НЛО прилетело и оставило здесь промокод для читателей нашего блога:

— 15% на все тарифы VDS (кроме тарифа Прогрев) — HABRFIRSTVDS.