Передовой опыт технической команды Alibaba в тестировании программ
Среды тестирования являются важным аспектом любого процесса исследований и разработок программного обеспечения и обеспечивают систему для эффективного тестирования новых функций перед выпуском. Стабильность таких систем - один из важнейших факторов, влияющих на эффективность НИОКР.
В этой статье описаны основные проблемы и ограничения тестовых сред, а также представлены методы улучшения, которые могут эффективно повысить стабильность таких систем. Основная цель улучшения стабильности тестовой среды для технической команды Alibaba - это оптимизация успешности контейнерных приложений и повышение стабильности тестовых сред. В этой статье показано, что, решив проблемы с доступностью прикладных ресурсов и новыми приложениями ресурсов, Alibaba обеспечила более плавный процесс исследований и разработок программного обеспечения и, как следствие, лучшие конечные продукты.
Болевые точки
Приложения-контейнеры состоят из целых сред выполнения и являются эффективным решением для сокрытия различий в аппаратной инфраструктуре, которая может использоваться для тестовых сред. Сбои в этих контейнерных приложениях обычно приостанавливают выполнение НИОКР, пока проводятся тесты, чтобы выяснить, где и как возникли проблемы. Эти тесты могут включать все системы в тестовой среде.
Проблемы с контейнерами тестовой среды Alibaba возникали до 10 раз в течение полугода, что приводило к сотням часов потраченного впустую времени на исследования и разработки. Поэтому существует острая потребность в значительном повышении стабильности тестовой среды.
После тщательного анализа всех обнаруженных проблем Alibaba определила две основные проблемы, с которыми сталкиваются тестовые среды:
· Уже используемые ресурсы становятся недоступными
Низкая производительность и высокий коэффициент виртуальности хостов (на которые не распространяется гарантия) тестовой среды подвержены ошибкам. Контейнеры неисправного хоста не переносятся автоматически, что, скорее всего, приведет к сбою их повторного развертывания и перезапуска.
Патрулирование системы планирования делает неисправные хосты незапланированными. Поскольку на этих хостах по-прежнему есть контейнеры, которые нельзя отключить, отремонтировать и повторно использовать, ресурсы хоста становятся все более ограниченными.
· Низкий процент успешных заявок на новые ресурсы
Узлы тестовой среды сгруппированы в пулы ресурсов с разными приоритетами, которые не разделяют ресурсы. Непрозрачность общей / доступной емкости узлов тестовой среды в сочетании с отсутствием предупреждений приводит к сбою планирования из-за нехватки ресурсов.
Система планирования ресурсов не оптимизирована для использования в тестовых средах, которые разительно отличаются от онлайн-среды, что приводит к низкой вероятности успеха.
Статистика производительности: все дело в данных
Для оптимизации тестовых сред сбор данных был ключом к пониманию основных проблем стабильности. Подход Alibaba к пониманию стабильности тестовой среды изложен ниже:
Чтобы разобраться в проблемах стабильности тестовой среды, нисходящий процесс включал рассмотрение следующих платформ:
· Normandy: платформа для работы с основными приложениями
· Hornet: платформа для приложений ресурсов
· Zeus: двухуровневая система расписания
· Sigma: система планирования групповых ресурсов
· Атом: неисправная система замены хоста
Все вышестоящие и последующие системы имеют свои собственные отдельные данные. Основным ограничением этого является то, что эти данные не интегрированы и не совместимы между платформами. Несмотря на то, что анализ ошибок проводится на дневных, еженедельных и ежемесячных временных рамках, он по-прежнему фрагментирован по платформам, что еще больше затрудняет всесторонний анализ данных.
Тем не менее собранные данные помогли команде выявить конкретные проблемы с доступностью контейнеров и защитой базовой системы и разработать соответствующие решения. Эти решения включали автоматическую замену контейнеров и защиту от сбоев базовой системы. После внедрения проверяли стабильность тестовых сред, чтобы определить, были ли решения эффективными.
Рационализация распределения пула ресурсов
Распределение пула ресурсов обычно рационализируется с учетом следующих факторов:
· Пулы логических ресурсов
Теги хоста используются для обозначения различных ресурсов и приоритетов для каждого пула ресурсов. Чем выше приоритет, тем лучше хост.
· Оценка спецификации контейнера
В тестовых средах относительно мало спецификаций контейнеров, наиболее распространенной из которых является преобразование в 2-ядерный 4G. Другие оценки включают:
- Среднее ежедневное приращение контейнера для каждого пула ресурсов. А именно, приращение в этот день: P0, приращение м дней назад: Pm и среднесуточное увеличение: (P0 - Pm) / m.
- Вычислительные ресурсы и ежедневная инкрементная доля каждого пула ресурсов в группе:
- Прогнозируемое значение маржи для каждого пула ресурсов: Ti = Ri * T, где T - общая маржа.
· Рейтинг хоста
Хост-устройство можно настроить в зависимости от рейтинга помещения, количества исторических отказов, конфигурации оборудования и даты выпуска.
· Правила распространения контейнеров
Теги хоста, соответствующие пулу ресурсов, распределяются на основе рейтинга хоста и приоритета пула ресурсов.
Схема этого динамического распределения пулов ресурсов показана ниже.
Автоматическая замена контейнера
В случаях, когда используемые контейнеры становятся недоступными, происходит автоматическая замена контейнеров. По сути, эта функция создает новый контейнер на стабильном хосте и отключает исходный контейнер от неисправного хоста.
Процесс начинается с того, что система Sigma определяет неисправный хост, например, с полным диском или неисправным оборудованием. Затем Sigma уведомляет систему Atom, которая затем заменяет контейнеры на неисправном хосте. Затем система Atom инициализирует замену хоста в системе Normandy. Наконец, неисправный хост опорожняется путем автоматической замены, после чего следует автономный ремонт.
Защита от отказов основной системы
Встроенные буферные пулы
Из-за различий между тестовой и онлайновой средами - а также для экономии затрат - в основном используются тестовые среды с большим количеством виртуальных хостов. Это вызывает проблемы при создании и использовании контейнеров, поэтому пулы буферов контейнеров применяются для предотвращения воздействия на пользователей основных сбоев.
Пулы буферов встраиваются в конец производственного канала контейнеров тестовой среды для предварительного создания партии контейнеров, которые при необходимости выделяются пользователю. Даже если приложение для буферных контейнеров выйдет из строя, исходная производственная ссылка может продолжать производить контейнеры. Каждый раз, когда пользователь получает контейнер из пула буферов, в пул асинхронно добавляется другой контейнер с той же спецификацией, чтобы сохранить его емкость или количество контейнеров.
Емкость буферного пула
Другой ключевой момент - это разработка спецификаций буферизованных контейнеров и емкости буферного пула, что потребовало подсчета количества прошлых приложений для каждого пула ресурсов spec-image-ресурсов и определения емкости каждого буфера на пропорциональной основе. Чтобы гарантировать, что вся система по-прежнему доступна, когда система нижнего уровня прекращает обслуживание, необходимо подтвердить количество контейнерных приложений в час пик, допустимую продолжительность прерывания обслуживания и ресурсы хоста тестовой среды.
Кроме того, следует учитывать еще один момент: в число пользователей входят обычные пользователи (сотрудники отдела исследований и разработок и тестирования) и пользователи системы (например, системы автоматического тестирования), каждый из которых имеет разные приоритеты. Обычные пользователи обычно имеют более высокий приоритет, чем системные пользователи, с точки зрения доступности тестовой среды.
Защитные функции
Чтобы свести к минимуму возможное влияние пулов буферов на пользователей, в пул буферов добавлен ряд динамических переключателей для защиты некоторых его функций. Например, нужно ли изменять имя хоста контейнера или нет, можно установить для конкретных приложений. Если имя хоста не изменяется, успешное приложение в среднем занимает менее 1 секунды. В этом случае буферная функция может быть немедленно экранирована, если приложение ее не использует. Если в самом пуле буферов возникают ошибки, быстрое ухудшение работы может удалить функцию буфера со всего канала.
Перед доставкой буферных контейнеров пул буферов дополнительно проверяет, можно ли использовать контейнеры, чтобы избежать неудачного развертывания службы. Пул буферов регулярно удаляет контейнеры, которые нельзя использовать, и добавляет новые контейнеры буферов.
Результирующие тенденции
Анализ успешности является ключом к полному пониманию эффективности оптимизаций. Как показано ниже, использование полной емкости буферного пула с 21 декабря привело к значительному увеличению вероятности успеха и его стабильности. Снижение показателей успешности, например, 1 декабря, было вызвано неудачным планированием.
Корректировка емкости каждого пула ресурсов в соответствии с прогнозируемым балансом пулов ресурсов и предупреждениями исключила вероятность неудачного планирования и значительно снизила нестабильность показателя успешности.
В течение одной недели после того, как пул буферов был доведен до полной емкости, внутренняя ошибка и низкая частота попаданий в пул буферов привели к изменчивой частоте успеха, которая стабилизировалась после исправления ошибки и увеличения скорости попадания в пул буферов.
Ежедневный коэффициент успешности также был проанализирован путем выполнения продольного сравнения перспективы пользователя (с буфером) и перспективы системы нижнего уровня (без буфера). Как показано ниже, буферный пул экранировал большинство сбоев системы нижнего уровня и приводил к снижению производительности только на один день, когда буферный пул был исчерпан.
СМОТРЕТЬ ВПЕРЕД
Несмотря на улучшение показателей успешности после оптимизации, есть три ключевых аспекта, которые все еще требуют дальнейшего внимания:
· Автоматическое планирование емкости пула ресурсов
Текущие алгоритмы недостаточно сложны для обработки определенных сценариев, таких как добавление или удаление слишком большого количества контейнеров, что приводит к неправильному анализу тенденции баланса. Еще одна проблема - повышенная вероятность появления хаотичных тегов хоста из-за автоматического планирования.
· Динамическая настройка типов шаблонов буферов и количества каждого типа шаблонов
Типы шаблона буфера и количество каждого типа шаблона должны прогнозироваться и корректироваться динамически в соответствии с историческими данными приложения или данными в реальном времени.
· Увеличение емкости буферного пула
Это требует наличия достаточного количества ресурсов хоста.
Кроме того, существуют следующие более общие проблемы с тестовыми средами, разработка решений которых потребует более разнообразного подхода:
· Как можно увеличить коэффициент использования ресурсов для всей тестовой среды?
· Как можно сократить время доставки контейнера (от пользовательского приложения до момента доставки контейнера)?
· Как сделать приложения более планируемыми?
В дальнейшем это вопросы и проблемы, на которых будет сосредоточена техническая команда Alibaba.
(Оригинальная статья Чжан Цзин 张劲)
Alibaba Tech
Подробная информация о последних технологиях Alibaba из первых рук → Выполните поиск « Alibaba Tech » на Facebook
