Баланс между ростом и оптимизацией производительности – это постоянное напряжение во всех сферах бизнеса. Это особенно актуально для DevOps, с его стремлением быстрее выпускать больше функций, чтобы опередить конкурентов, и необходимостью стабилизировать и оптимизировать производительность существующей системы для обеспечения наилучшего пользовательского опыта. Однако бюджеты и ресурсы DevOps в большинстве случаев сокращаются. С каждым релизом команды вынуждены принимать сложные компромиссные решения. Как обеспечить правильный баланс и удовлетворить потребности новых и существующих пользователей, а также бизнеса?
Просто часть работы
Существует внутреннее противоречие между созданием новых функций и оптимизацией производительности существующих. Это противоречие возникает из-за ограниченного набора ресурсов (время, бюджет, персонал) и необходимости расставлять приоритеты между конкурирующими целями.
Создание новых функций:
Оптимизация производительности:
Отсутствие управления этими конкурирующими приоритетами может привести к ряду проблем:
- Расширение границ: Добавление новых функций может привести к увеличению количества функций, что сделает существующие функции более сложными и трудными для поддержки.
- Технический долг: Задержка оптимизации производительности может привести к накоплению технического долга, что делает будущую разработку более сложной и дорогой.
- Влияние на бизнес: Отсутствие функций и нерешенные проблемы стабильности или производительности могут привести к неудовлетворенности пользователей, что потенциально скажется на итоговых показателях.
Метрики могут сыграть решающую роль в управлении этими противоречиями, предоставляя данные для обоснования решений. Они могут помочь:
- Измерить влияние новых функций: Отслеживайте вовлеченность пользователей, принятие функций и бизнес-ценность новых функций. Это помогает оценить, насколько оправданы были усилия по разработке.
- Отслеживать показатели производительности: Отслеживайте ключевые показатели производительности (KPI), такие как время отклика, время загрузки страницы и количество ошибок. Определите области, где производительность может быть улучшена, и оцените потенциальные преимущества.
- Измерение технического долга: Используйте инструменты анализа кода и метрики покрытия кода для оценки технического долга, накопленного в результате задержки оптимизации производительности. Это поможет понять потенциальные будущие затраты, связанные с пренебрежением производительностью.
- Использовать анализ затрат и выгод: Сравните ожидаемые преимущества новых функций с затратами на оптимизацию производительности. Это поможет принимать обоснованные решения о распределении ресурсов.
Определение, измерение и передача значимых показателей может помочь каждому члену команды DevOps более эффективно расставлять приоритеты. Правильные метрики могут служить путеводной звездой и согласовывать решения по расстановке приоритетов для достижения бизнес- и технических целей. Регулярный мониторинг и информирование о прогрессе в достижении целей позволяет членам команды принимать взвешенные решения, корректировать курс и работать над постоянным совершенствованием. Чтобы найти правильный баланс, команды должны выбирать показатели, которые охватывают цели производительности и развития.
Метрики производительности
Все знакомы с ключевыми показателями производительности (KPI), которые определяют состояние, производительность и устойчивость SaaS-системы. Эти показатели можно использовать для оптимизации работы предпроизводственных и производственных систем и в целом разделить на четыре основные области:
Доступность и время работы:
- Время безотказной работы: Показатель, характеризующий процент времени, в течение которого система доступна для пользователей. В идеале лучше всего стремиться к показателю работоспособности 99,9 % или выше. Снижение времени безотказной работы может указывать на нестабильность системы или перебои в ее работе, что негативно сказывается на пользовательском опыте и может привести к оттоку пользователей.
- Среднее время ремонта (MTTR): Показатель среднего времени устранения сбоя или инцидента. Более низкий показатель MTTR указывает на более быстрое время реагирования и восстановления, что сводит к минимуму время простоя и его влияние на пользователей.
Производительность и скорость:
- Время отклика: Показатель времени, которое требуется системе для ответа на запросы пользователей. Более быстрое время отклика улучшает работу пользователей и повышает их удовлетворенность. Для оптимальной производительности старайтесь, чтобы время отклика не превышало 2 секунд.
- Время загрузки страницы: Показатель времени, которое требуется для полной загрузки веб-страницы. Как и время отклика, более быстрое время загрузки страницы способствует улучшению пользовательского опыта и повышению вовлеченности.
- Пропускная способность: Это показатель количества запросов, которые система может обработать за единицу времени. Высокая пропускная способность гарантирует, что система сможет справиться с пиковыми нагрузками без снижения производительности.
Использование ресурсов:
- Использование процессора: Здесь измеряется процентное соотношение доступных ресурсов центрального процессора системы. Высокая загрузка процессора может привести к узким местам и замедлению работы.
- Использование памяти: Здесь измеряется процентное соотношение доступных ресурсов памяти, используемых системой. Как и в случае с загрузкой процессора, высокий уровень использования памяти может повлиять на производительность.
- Использование сети: Здесь измеряется процент доступной пропускной способности сети, которую использует система. Высокая загрузка сети может привести к перегрузке и замедлению работы.
Показатели использования процессора и памяти, отображаемые в SolarWinds Observability
Уровень ошибок и стабильность:
- Коэффициент ошибок: Показатель процента запросов пользователей, приводящих к ошибкам. Низкий уровень ошибок свидетельствует о стабильности и надежности системы.
- Аварии приложений: Измеряет количество случаев неожиданного сбоя или завершения работы приложения. Частые сбои могут быть неприятны для пользователей и указывают на нестабильность системы.
Метрики разработки и выпуска
Хотя такие показатели производительности, как время безотказной работы, количество ошибок и время отклика, используются для измерения производительности систем с 1970-х годов, именно с появлением Agile и DevOps показатели релизов стали более распространенными. Сначала принятие Agile и ориентация на постоянное совершенствование создали необходимость в измерении общих показателей релиза, таких как частота развертывания, для отслеживания улучшений. Затем DevOps расширил определение релиза, включив в него весь конвейер поставки программного обеспечения, и повысил внимание к производительности всей команды DevOps.
В 2014 году исследовательская инициатива Google Cloud Platform, DevOps Research and Assessment (DORA), провела свое первое исследование практики команд по доставке программного обеспечения. Целью исследования и отчета DORA является понимание возможностей, которые определяют эффективность доставки программного обеспечения и операций.
Опрос профессионалов DevOps проводится ежегодно и оценивает эффективность релизов по целому ряду показателей релизов, производительности и бизнеса. Отчет DORA широко цитируется отраслевыми аналитиками и лидерами мнений. Это ценный ресурс для всех, кто хочет узнать больше о практике DevOps и о том, как повысить эффективность работы своей команды.
Метрики DORA стали общепризнанным стандартом для измерения эффективности доставки программного обеспечения. Они используются командами любого размера и во всех отраслях промышленности для отслеживания прогресса и определения областей для улучшения. Они состоят из набора четырех показателей, предназначенных для оценки эффективности работы команд разработчиков программного обеспечения.
- Частота развертывания: Как часто команда внедряет новый код в производство?
- Время подготовки изменений: Сколько времени требуется для того, чтобы изменение прошло от фиксации в коде до развертывания в производстве?
- Частота отказов изменений: Как часто развертывание приводит к сбоям в производстве?
- Среднее время восстановления (MTTR): Сколько времени требуется для восстановления после сбоя в производстве?
Используя эти показатели и сравнивая результаты работы различных команд, команда DORA обнаружила, что у высокоэффективных команд значительно выше частота внедрения, короче время подготовки к изменениям, ниже процент отказов от изменений и выше MTTR, чем у низкоэффективных команд.
Метрики производительности и релизов вместе
Метрики доставки релизов и метрики производительности вместе создают целостную картину работоспособности и эффективности вашего пользовательского приложения. Измерение и анализ обоих типов показателей обеспечивает перспективу, необходимую для принятия более точных решений о приоритетах и компромиссах.
Показатели доставки релизов: Отслеживайте предсказуемость, эффективность и качество цикла релиза. К ним могут относиться:
- Время цикла релиза: Время от идеи до выпуска.
- Частота развертывания: Количество релизов в единицу времени.
- Время подготовки изменений: Время, необходимое для того, чтобы провести изменение от идеи до реализации.
- Скорость устранения дефектов: Процент дефектов, которые попадают в производство.
Показатели производительности: Измеряют способность приложения соответствовать ожиданиям пользователей и бизнес-целям. Они могут включать в себя:
- Время отклика: Время, необходимое приложению для ответа на запрос пользователя.
- Время безотказной работы: Процент времени, в течение которого приложение доступно для использования.
- Использование ресурсов: Использование приложением процессора, памяти и сети.
- Отзывы пользователей: Опрос пользователей об их опыте работы с приложением.
На высоком уровне метрики релиза измеряют эффективность и качество конвейера доставки, а метрики производительности выявляют области, требующие улучшения. Оба набора показателей вместе дают полную картину состояния приложения. Используя эти данные, вы можете принимать взвешенные решения по оптимизации процесса разработки, повышению производительности приложений и, в конечном счете, обеспечению большей ценности для пользователей и бизнеса.
Подведение итогов
Задача, с которой регулярно сталкиваются команды, – найти идеальный баланс между разработкой новых функций и оптимизацией производительности системы. Отслеживание и анализ комбинированного набора показателей выпуска и производительности позволяет достичь обеих целей и получить глубокое представление о сильных и слабых сторонах приложения. Например, выделение ресурсов для более быстрого создания новых функций может показаться прогрессом. Однако если эти новые функции добавляют нестабильность или снижают производительность системы, могут потребоваться дополнительные ресурсы для устранения неполадок и исправления ошибок. Аналогичным образом, выявление проблем с производительностью может выявить области, требующие улучшения в системе и процессе выпуска.
Показатели доставки релизов и производительности приложений дополняют друг друга и работают вместе, обеспечивая полное понимание состояния приложений. Чтобы реализовать этот подход, выберите метрики для отслеживания в соответствии с вашими целями, определите и внедрите инструменты, такие как SolarWinds Observability, для сбора и анализа данных. SolarWinds Observability – это полнофункциональное решение для мониторинга, объединяющее данные о веб-приложениях и внутренних системах для упрощения управления и получения полезных сведений.
Источник: Finding the Sweet Spot Between Innovation and Optimization
