"ГОСТ Р ИСО/МЭК 25045-2015. Национальный стандарт Российской Федерации. Информационные технологии. Системная и программная инженерия. Требования и оценка качества систем и программного обеспечения (SQuaRE). Модуль оценки восстанавливаемости"
(утв. и введен в действие Приказом Росстандарта от 29.05.2015 N 466-ст)

1 ПОДГОТОВЛЕН Обществом с ограниченной ответственностью "Информационно-аналитический вычислительный центр" (ООО ИАВЦ) на основе собственного аутентичного перевода на русский язык международного стандарта, указанного в пункте 4

2 ВНЕСЕН Техническим комитетом по стандартизации ТК 22 "Информационные технологии"

3 УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Приказом Федерального агентства по техническому регулированию и метрологии от 29 мая 2015 г. N 466-ст

4 Настоящий стандарт идентичен международному стандарту ИСО/МЭК 25045:2010 "Системная и программная инженерия. Требования и оценка качества систем и программного обеспечения (SQuaRE). Модуль оценки восстанавливаемости" (ISO/IEC 25045:2010 "Systems and software engineering - Systems and software Quality Requirements and Evaluation (SQuaRE) - Evaluation module for recoverability").

Наименование настоящего стандарта изменено относительно наименования указанного международного стандарта для приведения в соответствие с ГОСТ Р 1.5 (пункт 3.5).

При применении настоящего стандарта рекомендуется использовать вместо ссылочных международных стандартов соответствующие им национальные стандарты Российской Федерации, сведения о которых приведены в дополнительном приложении ДА

5 ВВЕДЕН ВПЕРВЫЕ

Правила применения настоящего стандарта установлены в ГОСТ Р 1.0-2012 (раздел 8). Информация об изменениях к настоящему стандарту публикуется в ежегодном (по состоянию на 1 января текущего года) информационном указателе "Национальные стандарты", а официальный текст изменений и поправок - в ежемесячном информационном указателе "Национальные стандарты". В случае пересмотра (замены) или отмены настоящего стандарта соответствующее уведомление будет опубликовано в ближайшем выпуске ежемесячного информационного указателя "Национальные стандарты". Соответствующая информация, уведомление и тексты размещаются также в информационной системе общего пользования - на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет (www.gost.ru)

Международная организация по стандартизации (ИСО) и Международная электротехническая комиссия (МЭК) формируют специализированную систему для всемирной стандартизации. Национальные органы по стандартизации, являющиеся членами ИСО или МЭК, участвуют в разработке международных стандартов через технические комитеты, созданные соответствующей организацией для рассмотрения вопросов конкретных сфер технической деятельности. Технические комитеты ИСО и МЭК сотрудничают в сферах, представляющих взаимный интерес. Другие правительственные и неправительственные международные организации, взаимодействующие с ИСО и МЭК, также принимают участие в работе. В сфере информационной технологии ИСО и МЭК создали совместный технический комитет ИСО/МЭК СТК 1.

Международные стандарты разрабатываются в соответствии с правилами, приведенными в Директивах ИСО/МЭК, Часть 2.

Основной задачей совместного технического комитета является подготовка международных стандартов. Проекты международных стандартов, принятые совместным техническим комитетом, распространяются среди национальных органов по стандартизации для голосования. Их публикация в качестве международных стандартов требует одобрения, по крайней мере, 75% национальных органов по стандартизации, принимающих участие в голосовании.

Следует обратить внимание на то, что некоторые элементы настоящего стандарта могут быть объектом патентного права. ИСО и МЭК не несут ответственности за установление какого-либо или всех таких патентных прав.

ИСО/МЭК 25045 был подготовлен Подкомитетом 7 "Системная и программная инженерия" совместного технического комитета ИСО/МЭК СТК 1 "Информационные технологии".

ИСО/МЭК 25045 является составной частью серии международных стандартов SQuaRE, которая состоит из следующих разделов:

- раздел "Менеджмент качества" (ИСО/МЭК 2500n);

- раздел "Модель качества" (ИСО/МЭК 2501n);

- раздел "Измерение качества" (ИСО/МЭК 2502n);

- раздел "Требования к качеству" (ИСО/МЭК 2503n);

- раздел "Оценка качества" (ИСО/МЭК 2504n).

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

Основные составные части оценки качества программного обеспечения - это модель качества, методы оценки и измерения качества программного обеспечения и вспомогательные инструменты. Для разработки хорошего программного обеспечения, необходимо определить требования к качеству, спланировать процесс обеспечения качества программного продукта, реализовать этот процесс и управлять им, провести оценку как промежуточных, так и конечных продуктов.

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

Основная цель создания серии стандартов SQuaRE состоит в том, чтобы построить логически организованную, обогащенную и объединенную серию стандартов, покрывающую два основных процесса: создание спецификации требований к качеству программного обеспечения и оценка качества программного обеспечения с поддержкой процесса измерения качества. Целью серии стандартов SQuaRE является помощь разработчикам и приобретателям программной продукции в спецификации и оценке требований к качеству. При этом определяются критерии для спецификации требований к качеству программного продукта, их измерения и оценки. Предлагаемая модель качества предназначена для того, чтобы согласовать потребительские определения качества с атрибутами процесса разработки. Кроме того, серия стандартов предоставляет рекомендуемые показатели атрибутов качества программной продукции, которые могут использоваться разработчиками, приобретателями и оценщиками.

SQuaRE обеспечивает:

- термины и определения;

- эталонные модели;

- общее руководство;

- отдельные разделы руководства;

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

Серия стандартов SQuaRE включает в себя международные стандарты, определяющие модели качества и показатели, а также требования к качеству и оценке.

Серия стандартов SQuaRE замещает серии стандартов ИСО/МЭК 9126 и ИСО/МЭК 14598.

ИСО/МЭК 25040 "Системная и программная инженерия. Требования и оценка качества систем и программного обеспечения (SQuaRE). Эталонная модель и руководство по измерениям" заменяет часть ИСО/МЭК 14598-1 "Информационные технологии. Оценка программного продукта. Часть 1. Общие положения".

ИСО/МЭК 25041 "Системная и программная инженерия. Требования и оценка качества систем и программного обеспечения (SQuaRE). Модули оценки" заменяет ИСО/МЭК 14598-6 "Программная инженерия. Оценка продукта. Документация модулей оценки".

ИСО/МЭК 25001 "Программная инженерия. Требования и оценка качества систем и программного обеспечения (SQuaRE). Планирование и менеджмент" заменяет ИСО/МЭК 14598-2 "Программная инженерия. Оценка продукта. Часть 2. Планирование и менеджмент".

На рисунке 1 показана организация серии международных стандартов SQuaRE, которая представлена семействами стандартов, называемых также разделами.

В модель SQuaRE входят следующие разделы:

- ИСО/МЭК 2500n - раздел "Менеджмент качества". Международные стандарты, входящие в данный раздел, определяют общие модели, термины и определения, используемые во всех других стандартах серии SQuaRE. Направляющие ссылки, используемые во всех документах SQuaRE, и высокоуровневые практические предложения по применению соответствующих стандартов в случаях конкретных приложений помогут всем потребителям. В разделе также представлены требования и методические материалы, касающиеся поддерживающей функции, отвечающей за менеджмент требований к программной продукции, спецификацию и оценку;

- ИСО/МЭК 2501n - раздел "Модель качества". Международные стандарты, которые входят в данный раздел, представляют детализированные модели качества программного обеспечения, качества при использовании и качества данных. Кроме того, в них представлено практическое руководство по использованию модели качества;

- ИСО/МЭК 2502n - раздел "Измерение качества". Международные стандарты, входящие в данный раздел, включают в себя эталонную модель измерения качества программной продукции, математические определения показателей качества и практическое руководство по их использованию. В данном разделе представлены показатели внутреннего качества программного обеспечения, показатели внешнего качества программного обеспечения и показатели качества при использовании. Кроме того, в них определены и представлены элементы показателей качества (ЭПК), формирующие основу для вышеперечисленных показателей;

- ИСО/МЭК 2503n - раздел "Требования к качеству". Международные стандарты, которые входят в данный раздел, помогают сформулировать требования к качеству. Такие требования к качеству могут использоваться в процессе формирования требований к качеству, при сборе информации перед разработкой программной продукции или как исходные данные для процесса оценки. Процесс определения требований отнесен к техническим процессам, определенным в ИСО/МЭК 15288 "Системная и программная инженерия. Процессы жизненного цикла систем";

- ИСО/МЭК 2504n - раздел "Оценка качества". Международные стандарты, которые входят в данный раздел, формулируют требования, рекомендации и методические материалы для оценки качества программного продукта, выполняемой как независимыми оценщиками, так и приобретателями или разработчиками. Кроме того, в них представлена поддержка документирования измерения как модуля оценки.

Настоящий стандарт является частью раздела оценки качества (ИСО/МЭК 2504n), в который входят следующие международные стандарты (см. рисунок 1):

- ИСО/МЭК 25040 "Системная и программная инженерия. Требования и оценка качества систем и программного обеспечения (SQuaRE). Процесс оценки" содержит общие требования к спецификации и оценке качества программного обеспечения, а кроме того, и общие понятия. В нем содержится также описание процесса оценки качества программного продукта и устанавливаются требования для использования этого процесса. Процесс оценки является основой оценки качества программной продукции для различных целей и подходов. Поэтому процесс может использоваться для оценки показателей внешнего и внутреннего качества программного обеспечения, а также показателей качества при использовании. Кроме того, процесс может быть применен для оценки качества как уже разработанного программного обеспечения, так и заказанного программного обеспечения в процессе его разработки. Оценка качества программного продукта может быть произведена, например, приобретателем, организацией разработчика, поставщиком или независимым оценщиком;

- ИСО/МЭК 25042 <1> "Системная и программная инженерия. Требования и оценка качества систем и программного обеспечения (SQuaRE). Модули оценки" определяет структуру и содержание документации, которую следует использовать для описания модуля оценки. Данные модули оценки содержат спецификацию модели качества (то есть характеристики, подхарактеристики и соответствующие показатели внутреннего, внешнего качества или показатели качества при использовании), соответствующие данные, а также информацию о планируемом использовании модели и информацию о ее фактическом применении. Для каждой оценки выбираются соответствующие модули оценки. В некоторых случаях, возможно, потребуется разработка новых модулей оценки. Руководство по разработке новых модулей оценки можно найти в ИСО/МЭК 25042. Данный международный стандарт также может использоваться организациями, разрабатывающими новые модули оценки;

--------------------------------

<1> В процессе подготовки.

- ИСО/МЭК 25045 "Системная и программная инженерия. Требования и оценка качества систем и программного обеспечения (SQuaRE). Модуль оценки восстанавливаемости" приводит спецификацию оценки подхарактеристики восстанавливаемости, определенной как подмножество характеристик надежности из модели качества. В связи с тем, что время простоя зачастую имеет серьезные экономические и другие последствия, особую важность имеет способность программного продукта, а следовательно, и системы оставаться в рабочем состоянии или восстанавливаться в течение приемлемого интервала времени. Все больше внимания уделяется способностям программной продукции работать автономно и, как следствие этого, системам, функционирующим с минимальным участием человека. В связи с этим определенный интерес, как со стороны пользователей, так и со стороны промышленности, представляет вопрос о том, насколько хорошо программный продукт, а следовательно, и система обрабатывает конкретные возмущающие воздействия - как их обнаруживает, анализирует, корректирует и восстанавливается. Данный международный стандарт определяет показатели качества - способность к восстановлению и индекс автономного восстановления в случае, когда выполняющая операции информационная система, состоящая из одного или более программных продуктов, подвергается серии возмущающих воздействий. Возмущающее воздействие может быть операционным сбоем (например, внезапным завершением процесса работы операционной системы, которое приводит систему в нерабочее состояние) или событием (например, существенным увеличением числа пользователей системы), или чем-либо иным, что может вызвать изменение состояния системы.

1. Область применения

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

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

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

1.1. Характеристики

Данный модуль оценки измеряет показатели качества, определенные для следующих указанных ниже характеристик и подхарактеристик модели качества, как установлено в ИСО/МЭК 9126-1.

Примечание - Ссылка на ИСО/МЭК 9126-1 будет заменена ссылкой на ИСО/МЭК 25010 после публикации последнего.

Характеристика - надежность.

Подхарактеристика - восстанавливаемость:

- показатель качества - способность к восстановлению;

- показатель качества - индекс автономного восстановления.

1.2. Уровень оценки

Уровень оценки - D, как это определено в ИСО/МЭК 14598-5. Данная оценка предназначена для систем, состоящих из исполнимых продуктов.

Примечание - Ссылка на ИСО/МЭК 14598-5 будет заменена ссылкой на ИСО/МЭК 25040 после публикации последнего.

1.3. Метод

Методология, основанная на применении инъекции возмущения, представляет собой тестирование при принудительном воздействии возмущения на приложения и другие компоненты системы. Тестирование происходит в условиях функционирования системы под рабочей нагрузкой, интенсивность которой соответствует интересам приобретателя. Методология инъекции возмущения и список возмущающих воздействий на основе общих категорий операционных дефектов и событий используются для оценки способности к восстановлению. Для каждого возмущения определяется способность к восстановлению, для чего вычисляют отношение числа успешно завершенных транзакций во время работы системы под воздействием возмущения к числу успешно завершенных транзакций системы без возмущающего воздействия. Множество возмущающих воздействий подразделяется на следующие категории:

- неожиданное завершение работы - например, внезапное завершение работы операционной системы (ОС), завершение работы процессора, завершение работы сети;

- конкуренция за ресурсы - например, процессор/память/ввод-вывод, неосвобождение памяти, очередь запросов к системе управления базой данных (СУБД), блокирование СУБД, переполнение очереди к СУБД и хранилищу сервера;

- потеря данных - например, потеря данных СУБД, потеря файла СУБД, потери организации очередей СУБД и диска сервера;

- реакция на загрузку - например, умеренное или существенное увеличение числа пользователей или рабочей нагрузки;

- отказы перезапуска - например, отказ перезапуска операционной системы и процесса сервера промежуточного программного обеспечения.

Кроме того, в других случаях возможно определение иных категорий возмущающих воздействий.

Для оценки показателя качества - индекса автономного восстановления для каждого возмущающего воздействия определен набор вопросов. Оценка вычисляется для каждого возмущения на основе ответов на эти вопросы.

Общий индекс способности к восстановлению и автономного восстановления вычисляется соответственно, как среднее число этих отдельных показателей.

Подробная методика оценки приводится в 5.1.

1.4. Применимость

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

Модуль оценки может использоваться в следующих случаях:

a) оценка как часть системного тестирования верификации;

b) оценка в тестовой среде производственной системы для измерения восстанавливаемости и идентификации недостатков;

c) оценка восстанавливаемости различных предложенных поставщиками решений при общей рабочей нагрузке.

Результат оценки применим только к конкретной версии и конфигурации компонентов программного и аппаратного обеспечения, для которых она производилась. Два результата оценки сопоставимы тогда и только тогда, когда они были получены для одних и тех же величин и набора параметров рабочей нагрузки (см. 5.2.2.2), для одних и тех же величин и набора параметров ввода неисправности (см. 5.2.3.2).

2. Соответствие

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

3. Нормативные ссылки

Нормативные документы, полностью или частично упомянутые в настоящем стандарте, обязательны для их применения. Для датированных документов используют только указанное издание. Для недатированных документов используют самое последнее издание ссылочного документа (с учетом всех его изменений):

ИСО/МЭК 25000:2005 <1> Программная инженерия. Требования и оценка качества программного продукта (SQuaRE). Руководство по SQuaRE (ISO/IEC 25000:2005, Software Engineering - Software product Quality Requirements and Evaluation (SQuaRE) - Guide to SQuaRE)

--------------------------------

<1> Заменен. Действует ИСО/МЭК 25000:2014.

4. Термины и определения

В настоящем стандарте используются термины и определения, данные в ИСО/МЭК 25000, а также следующие термины с соответствующими определениями:

4.1 базовый уровень производительности (performance baseline): Производительность системы под нормальной рабочей нагрузкой без воздействия возмущений.

4.2 возмущающее воздействие (disturbance): Операционный сбой (например, внезапное завершение процесса работы операционной системы, которое приводит систему в нерабочее состояние), событие (например, существенное увеличение числа пользователей системы) или что-либо иное, что может вызвать изменение состояния системы.

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

4.3 инъекционный период (период действия введенного возмущения) (injection slot): Временной интервал проверки восстанавливаемости тестируемой системы при введении возмущающего воздействия в процессе рабочего функционирования системы.

5. Входные данные и показатели

5.1. Методика оценки

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

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

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

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

Фаза тестирования разбивается на множество последовательных периодов инъекции возмущения. Эти инъекционные периоды должны следовать один за другим в указанной последовательности.

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

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

На рисунке 3 показаны пять интервалов, входящих в состав инъекционного периода:

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

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

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

- Интервал восстановления - время, необходимое системе для выполнения восстановления;

- Интервал задержки - время, требуемое для разгона и перехода системы в устойчивое состояние после восстановления. Данный интервал входит в состав измерительного интервала. Если устойчивое состояние не достигнуто или производительность ниже, чем до введения возмущения, то этот факт должен быть отмечен в отчете.

Необходимо отметить два следующих момента:

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

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

5.1.1 Практические соображения по методологии

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

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

Продолжительность интервала прогона зависит от рабочей нагрузки. Большие рабочие нагрузки с более высокой пропускной способностью, как правило, требуют более длительного периода разгона для достижения устойчивого состояния, при котором можно начать измерения. Вот один из примеров, который можно использовать для определения баланса между эффективностью и временем, необходимым тестируемой системе для обнаружения вводимых возмущений и восстановления после их воздействия. Для выполнения базовой фазы системе позволяют прогреться в течение 5 мин, а следующие 50 мин используются непосредственно для базовой фазы. Для тестового прогона системе позволяют прогреться в течение 5 мин, а затем начинают 50-минутную фазу тестирования, которая разбита на 10-минутный инъекционный интервал, 20-минутный объединенный интервал обнаружения и инициирования восстановления и 20-минутный интервал восстановления и задержки.

5.1.2 Возмущающие воздействия

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

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

5.1.2.1 Неожиданное завершение работы

Возмущающие воздействия в данной категории имитируют неожиданное завершение работы ОС, одного или более приложений или отключение сетевого соединения между компонентами тестируемой системы (см. таблицу 1).

5.1.2.2 Состязание за ресурсы

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

5.1.2.3 Потеря данных

Возмущающие воздействия в данной категории моделируют ситуации потери критически важных для бизнеса данных (см. таблицу 3).

5.1.2.4 Реакция на загрузку

Возмущающие воздействия в данной категории моделируют внезапное увеличение рабочей нагрузки в системе (см. таблицу 4).

5.1.2.5 Обнаружение отказа перезапуска

Возмущающие воздействия в данной категории моделируют ситуацию, при которой приложение или компонент, от которого приложение зависит, повреждены и не могут быть перезапущены (см. таблицу 5).

5.2. Входные данные для оценки

Примечание - В A.5 - A.8 в образце отчета приводится пример входных данных, перечисленных далее.

5.2.1 Описание тестируемой системы

5.2.1.1 Спецификация конфигурации аппаратных средств и операционной системы

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

- поставщик и номер модели;

- дата эксплуатационной готовности системы;

- ЦП (тип процессоров, число и скорость процессоров (МГц/ГГц));

- кэш (L1, L2, L3 и т.д.);

- оперативная память (в мегабайтах);

- используемые диски и файловая система;

- сетевой интерфейс;

- количество систем с точно такой же конфигурацией;

- операционная система (название продукта, поставщик и дата эксплуатационной готовности);

- параметры настройки операционной системы и опции, значения которых были изменены со значений по умолчанию;

- настройки компиляции, компоновки и оптимизации времени выполнения, использованные при построении/установке операционной системы;

- логическое или физическое разделение, используемое этой системой для размещения экземпляров программного обеспечения;

- какие компоненты программного обеспечения, приложения и дополнительное программное обеспечение, из перечисленных в 5.2.1.2; 5.2.1.3, 5.2.1.4, работают на этих аппаратных средствах.

5.2.1.2 Спецификация конфигурации компонентов программного обеспечения

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

- имя поставщика, название продукта, его версия и дата эксплуатационной готовности;

- параметры настройки и опции, значения которых были изменены со значений по умолчанию;

- настройки компиляции, компоновки и оптимизации времени выполнения, использованные при построении/установке компонентов программного обеспечения;

- количество экземпляров продукта в каждой системе.

5.2.1.3 Прикладные программы

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

- имя поставщика, название продукта, его версия и дата эксплуатационной готовности;

- параметры настройки и опции, значения которых были изменены со значений по умолчанию;

- настройки компиляции, компоновки и оптимизации времени выполнения, использованные при построении/установке компонентов программного обеспечения;

- число экземпляров в каждой системе.

5.2.1.4 Дополнительное необходимое программное обеспечение

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

- имя поставщика, название продукта, его версия и дата эксплуатационной готовности;

- настройка параметров и опций изменилась со значений по умолчанию;

- настройки компиляции, компоновки и оптимизации времени выполнения, использованные при построении/установке компонентов программного обеспечения;

- число экземпляров в каждой системе.

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

Для выполнения тестового прогона перечень должен включать в себя программное обеспечение, необходимое для внесения (инъекции) неисправностей (возмущений).

5.2.1.5 Хранимые данные

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

- файлы с данными, требуемыми для корректного вычисления;

- те файлы выходных данных, используемые программами, которые не являются пустыми перед запуском теста;

- данные из системы базы данных.

5.2.1.6 Дополнительная информация для обоснования

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

5.2.2 Описание рабочей нагрузки

5.2.2.1 Спецификация рабочей нагрузки

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

- описание тестируемой транзакции или операции;

- описание тестовых данных;

- сценарии тестирования.

5.2.2.2 Набор параметров рабочей нагрузки

Значения набора параметров, используемых для приведения в действие нагрузки, должны быть описаны в деталях, необходимых для обеспечения воспроизведения конфигурации программного обеспечения. В набор должны входить все параметры конфигурации драйвера нагрузки и приложений, которые могут повлиять на производительность и поведение приложения. Список включает в себя, но не ограничивается следующими пунктами:

- общее количество пользователей;

- продолжительность базового прогона (в секундах), включая продолжительность периодов разгона, устойчивой работы и завершения работы;

- учетный интервал (в секундах), в течение которого в ходе прогона учитывается скорость транзакций;

- состав смеси транзакции рабочей нагрузки (например, 10% - новые заказы, 20% - запросы состояния и т.д.);

- постоянен ли состав смеси транзакций в каждом учетном интервале, если - нет, то необходимо описание, когда во время прогона выполняется каждый тип транзакций;

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

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

5.2.2.3 Набор параметров для доказательства состоятельности и устойчивости рабочей нагрузки

Для правильной оценки эффекта инъекции возмущения необходимо показать повторяемость и состоятельность базового уровня. Базовый уровень должен быть получен в результате трех прогонов, а в качестве доказательства его повторяемости и состоятельности должны быть обеспечены следующие требования:

- статистическая значимость результатов измерений должна соответствовать требованиям, определенным приобретателем (например, число успешно завершенных транзакций в каждом из трех базовых прогонов не должно отличаться больше чем на 5%);

- статистическая значимость результатов измерений должна быть включена в отчет;

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

5.2.3 Описание ввода неисправности

5.2.3.1 Спецификация ввода неисправности

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

5.2.3.2 Набор параметров ввода неисправности

Каждое возмущение должно быть приложено в течение инъекционного периода, как это определено в 5.1. Для инъекционного периода должны быть определены следующие значения:

- интервал измерения (в секундах), называемый также продолжительностью инъекционного периода;

- инъекционный интервал (в секундах);

- интервал обнаружения (в секундах).

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

5.2.3.3 Анкета автономной завершенности

Для каждого прилагаемого возмущения необходимо подготовить анкету, содержащую вопросы, определенные в 5.4.3.

5.3. Элементы данных

Примечание - В A.9 - A.11 в демонстрационном отчете приводится пример выходных данных, описанных далее.

5.3.1 Выходные данные выполнения базового прогона

Выходные данные нормальной работы системы под рабочей нагрузкой должны содержать следующее:

- набор параметров рабочей нагрузки, под которой выполнялся прогон и записывались результаты;

- интервал измерения;

- отчетный интервал (например, каждые 30 с или каждые 10 мин и т.д. в течение прогона под рабочей нагрузкой);

- общее число транзакций, завершенных без ошибки в интервале измерения и между отчетными интервалами;

- общее число транзакций, завершенных с ошибками в интервале измерения;

- другую информацию о производительности системы, включая использование ЦП и ввода-вывода основными компонентами, используемыми тестируемой системой (например, веб-сервером, сервером приложений, сервером базы данных и т.д.) в каждом интервале для сравнения с тестовым прогоном системы.

5.3.2 Выходные данные тестового прогона

Выходные данные работы системы под рабочей нагрузкой при воздействии введенных возмущений для каждого инъекционного периода должны содержать следующее:

- набор параметров рабочей нагрузки, под которой выполнялся прогон и записывались результаты;

- интервал измерения (в секундах);

- инъекционный интервал (в секундах);

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

- отчетный интервал (в секундах, например, каждые 30 с или каждые 10 мин и т.д. в течение всего тестирования);

- общее число транзакций, завершенных без ошибки в интервале измерения и между каждым отчетным интервалом;

- общее число транзакций, завершенных с ошибками в интервале измерения;

- другую информацию о производительности системы, включая использование ЦП и ввода-вывода основными компонентами, используемыми тестируемой системой (например, веб-сервером, сервером приложений, сервером базы данных и т.д.) в каждом интервале для сравнения с базовым прогоном;

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

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

5.3.3 Заполнение анкеты автономной завершенности

Необходимо заполнить анкету автономной завершенности данными о том, как проблема была обнаружена, проанализирована и разрешена.

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

5.4. Показатели качества

Примечание - В A.2 и A.10 приводятся примеры отчетов, содержащих описанные далее выходные данные.

5.4.1 Показатели качества и элементы показателя качества (ЭПК)

Характеристика качества - надежность.

Подхарактеристика качества - восстанавливаемость:

- показатель качества - способность к восстановлению:

- ЭПК - число транзакций под возмущением - число завершенных без ошибок транзакций в интервале измерения при условии, что возмущение(я) введено(ы);

- ЭПК - число транзакций без каких-либо возмущений - число завершенных без ошибок транзакций в интервале измерения при условии, что возмущающие воздействия не введены;

- показатель качества - индекс автономного восстановления:

- ЭПК - автономная оценка завершенности.

В следующих пунктах описаны другие показатели качества и элементы показателя качества.

5.4.2 Показатель качества - способность к восстановлению

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

Наименование показателя - способность к восстановлению.

Цель показателя - определить, насколько жизнеспособна система при возмущениях.

Методика применения приведена в 5.1.

Измерение, формула и вычисление значения элемента данных. Для каждого возмущения вычисляется отношение

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

Pbase - число завершенных без ошибок транзакций в интервале измерения базового прогона в условиях отсутствия возмущающих воздействий.

Общая способность к восстановлению вычисляется как среднее от способностей к восстановлению для каждого инъекционного периода.

Интерпретация измеренного значения: x >= 0. Чем больше значение, тем лучше. (На практике значение, как правило, лежит в интервале 0 <= x <= 1, однако, теоретически возможно, что величина может превысить значение 1 в том случае, если производительность системы под возмущением выше производительности без возмущений).

Тип шкалы показателя - абсолютный.

Тип измерения P_i и Pbase - подсчет.

Входные данные для измерения - отчет о тестировании.

Ссылки: ИСО/МЭК 12207:2008 "Системная и программная инженерия. Процессы жизненного цикла программного обеспечения" (пункт 6.4.5 "Процесс системной интеграции", пункт 6.4.6 "Процесс квалификационного тестирования систем", пункт 6.4.9 "Процесс эксплуатации программного обеспечения").

Целевая аудитория - приобретатель, поставщик, разработчик, специалист по обслуживанию.

5.4.3 Показатель качества - индекс автономного восстановления

Индекс автономного восстановления - это качественный показатель уровня возможности автономного восстановления.

Наименование показателя - индекс автономного восстановления.

Цель показателя - определить, насколько хорошо программный продукт обнаруживает, анализирует и разрешает возмущающие воздействия.

Методика применения.

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

Результат для каждого возмущения должен вычисляться на основе ответов оператора тестирования на вопросы анкеты автономной завершенности. Каждому ответу присваивается определенное значение уровня автономности, соответствующее одному из уровней автономности реакции системы, представленных в таблице 6 (в порядке возрастания уровня).

Ответ на каждый вопрос должен быть одним из шести вариантов с различным начислением баллов, соответствующим определенным уровням автономности:

- A (базовый уровень) - 0 баллов;

- B0 (базовый/управляемый) - 0,5 балла;

- B (управляемый) - 1 балл;

- C (прогнозирующий) - 2 балла;

- D (адаптивный) - 3 балла;

- E (автономный) - 4 балла.

Примечание - Начисление баллов может быть скорректировано на основании опыта, потребительского предпочтения и условий применения.

Для каждого возмущения необходимо ответить на следующие вопросы:

- Каким образом было обнаружено возмущение?

A: служба поддержки сообщила операторам о многочисленных жалобах;

B0: операторы самостоятельно обнаружили проблему на основе мониторинга нескольких источников данных;

B: операторы самостоятельно обнаружили проблему на основе мониторинга единственного источника данных;

C: автономная управляющая программа уведомила оператора о возможной проблеме;

D: автономная управляющая программа обнаружила проблему без участия человека;

E: то же, что и в случае "D". Однако "E" выбирается только в случае ответа на следующий вопрос: "Каким образом осуществляется анализ возмущения?", т.е. если система осуществляет мониторинг и анализ данных на основе бизнес-правил и политик, что обеспечивает принятие мер без участия человека;

- Каким образом осуществляется анализ возмущения?

A: оператор собирает и анализирует сгенерированные системой данные из нескольких источников;

B: оператор анализирует данные, полученные от единственного инструмента управления;

C: система осуществляет мониторинг и анализ данных, что ведет к рекомендуемым действиям по восстановлению;

D: система осуществляет мониторинг и анализ данных, что обеспечивает принятие мер без участия человека;

E: система осуществляет мониторинг и анализ данных на основе бизнес-правил и политик, что обеспечивает принятие мер без участия человека;

- Какие действия предпринимаются?

A: оператор выполняет требуемые процедуры и выдает команды отдельно для каждого затронутого ресурса;

B: оператор выполняет требуемые процедуры и выдает команды через централизованную консоль управления;

C: оператор подтверждает и инициирует действия восстановления;

D: автономная система инициирует действия восстановления. Никаких действий от человека не требуется;

E: то же, что и в случае "D". Однако "E" выбирается только в случае ответа на следующий вопрос: "Каким образом осуществляется анализ возмущения?", т.е. если система осуществляет мониторинг и анализ данных на основе бизнес-правил и политик, то обеспечивает принятие мер без участия человека.

Каждое возмущение позволяет вычислить индекс автономной завершенности как среднее от суммы ответов на три вышеперечисленных вопроса. Необходимо раскрыть индекс автономной завершенности каждого вопроса для каждого возмущения.

Общий индекс автономного восстановления вычисляется как среднее значение по всем инъекционным периодам, нормализованное к самому высокому возможному значению уровня автономности (т.е. к 4). Результатом будет число от 0 до 1.

Значение 0 указывает на базовый уровень автономных возможностей системы (управляется вручную на основе отчетов, руководств по продукту). Значение 1 говорит о том, что система автономна (для достижения бизнес-целей управляет собой автоматически).

Измерение, формула для вычисления элемента данных. Для каждого возмущения берется средний балл ответов на вопросы, а затем делится на максимальное значение, равное 4.

Интерпретация измеренного значения: 0 <= x <= 1. Чем ближе значение к 1, тем лучше считается результат.

Тип шкалы показателя - абсолютный.

Тип измерения - подсчет.

Входные данные для измерения - записи мониторинга пользователей.

Ссылки: ИСО/МЭК 12207:2008 "Системная и программная инженерия. Процессы жизненного цикла программного обеспечения" (пункт 6.4.5 "Процесс системной интеграции", пункт 6.4.6 "Процесс квалификационного тестирования систем", пункт 6.4.9 "Процесс эксплуатации программного обеспечения").

Целевая аудитория - приобретатель, поставщик, разработчик, специалист по обслуживанию.

5.4.4 Элемент показателя качества (ЭПК). Число транзакций под возмущением

5.4.5 Элемент показателя качества (ЭПК). Число транзакций без возмущений

5.4.6 Элемент показателя качества (ЭПК). Индекс автономной завершенности

6. Интерпретация результатов

6.1. Представление показателей

Значения, как способности к восстановлению, так и индекса автономного восстановления, находятся в пределах от 0 до 1, и чем ближе значения к 1, тем лучше считается результат.

6.2. Создание отчета

В отчет должны входить следующие пункты:

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

- карта оценки, в которой перечислены оценки для каждого возмущения и общие оценки для способности к восстановлению и индекса автономного восстановления;

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

- выводы и рекомендации, включая достоинства, недостатки или возможные улучшения компонентов, входящих в состав тестируемой системы;

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

- элементы данных, определенные в 5.3, и показатели качества, определенные в 5.4;

- графики для базового и тестового прогонов для каждого возмущения для визуализации каждого интервала измерения и инъекционного периода. Ось X графика должна представлять собой время, а ось Y - количество транзакций;

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

Пример отчета приводится в приложении A.

6.3. Процедура подачи заявки

Настоящий стандарт для процедуры подачи заявки неприменим.

A.1 Сводная информация

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

Примечание - В начале каждого раздела приложения A курсивом выделены пояснения об области применения раздела. Примечания необязательно должны входить в реальный отчет.

Отчет содержит результаты тестирования восстанавливаемости и рекомендации по продукту для приложения "Day Trader" с открытым исходным кодом 2.0 в системном решении программного обеспечения, в состав которого входят сервер HTTP "HHHH v1.6", сервер приложений "AAAA v1.6" и сервер СУБД "DDDD v6.0".

Для этого решения системы программного обеспечения получены значения индекса способности к восстановлению, равное 0,81 (из возможного значения 1,00), и индекса автономного восстановления, равное 0,63 (из возможного значения 1,00). Это является улучшением по сравнению с предыдущими полученными значениями восстанавливаемости, равными 0,75 и 0,55, соответственно для приложения "DayTrader" 1.0 с сервером HTTP "HHHH v1.5", сервером приложений "AAAA v1.6" и сервером СУБД "DDDD v5.0".

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

Более подробная информация представлена в следующих разделах отчета.

A.2 Карта оценки

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

Примечание - Числа, используемые в таблице A.1, условные.

A.3 Сводка реакции на возмущающие воздействия

A.4 Выводы и рекомендации

A.4.1 Сервер приложений

Достоинства:

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

Недостатки/Возможности для улучшения:

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

A.4.2 Дефекты

Нет.

A.5 Входные данные для оценки

A.5.1 Описание тестируемой системы

A.5.1.1 Спецификация архитектуры и конфигурации аппаратных средств

- поставщик и номер модели;

- дата эксплуатационной готовности системы;

- ЦП (тип процессоров, число и скорость процессоров (МГц/ГГц));

- кэш (L1, L2, L3, и т.д.);

- оперативная память (в мегабайтах);

- используемые диски и файловая система;

- сетевой интерфейс;

- количество систем с точно такой же конфигурацией;

- операционная система (название продукта, поставщик и дата эксплуатационной готовности);

- параметры настройки операционной системы и опции, значения которых были изменены со значений по умолчанию;

- настройки компиляции, компоновки и оптимизации времени выполнения, использованные при построении/установке операционной системы;

- логическое или физическое разделение, используемое этой системой для размещения экземпляров программного обеспечения;

- какие компоненты программного обеспечения, приложения и дополнительное программное обеспечение, из перечисленных в 5.2.1.2; 5.2.1.3 и 5.2.1.4, работают на этих аппаратных средствах.

Аппаратные средства сервера базы данных:

Примечания

1 Параметры настройки:

1 vmo-o lgpg_regions=454-o lgpg_size=16777216-o v_pinshm=1.

2 aioo-o maxservers=100-o maxreqs=16384-o fsfastpath=1.

2 Необходимо также добавить дополнительные аппаратные средства для других компонентов тестируемой системы, таких как сервер приложений, средство моделирования нагрузки, средство загрузки возмущений, коммутатор Ethernet и т.д.

A.5.1.2 Спецификация конфигурации системы программного обеспечения

- настройки компиляции, компоновки и оптимизации времени выполнения, использованные при построении/установке компонентов программного обеспечения;

- количество экземпляров продукта в каждой системе.

Программное обеспечение сервера базы данных:

Примечание - Параметры настройки: скрипт db2tune.sh.

См. приложение XXX ... ...

Примечания

1 Это просто пример. Приложения XXX не существует.

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

A.5.1.3 Прикладные программы

DayTrader 2.0

Приложение, используемое в этом тестировании, является приложением DayTrader с открытым исходным кодом 2.0. Оно доступно на сайте Ahache Geroninmo по адресу: /template/go.php?url=https://cwiki.apache.org/GMOxDOC10/day-trader.html. Оно было загружено и сохранено на сервере XXXX в соответствующей директории /xxxxx/yyy/daytrader. Make-файл и необходимые параметры конфигурации находятся в директории /xxxxx/yyy/daytrader на сервере XXXX. Один экземпляр DayTrader был запущен на сервере XXXX.

A.5.1.4 Дополнительное необходимое программное обеспечение

A.5.1.5 Хранимые данные

База данных создана приложением DayTrader в процессе генерации данных для 500 тысяч учетных записей.

A.5.1.6 Дополнительная информация для обоснования

Нет.

A.6 Описание рабочей нагрузки

A.6.1 Спецификация рабочей нагрузки

Приложение, используемое в этом тестировании, является приложением DayTrader с открытым исходным кодом 2.0. Оно доступно на сайте Ahache Geroninmo по адресу: /template/go.php?url=https://cwiki.apache.org/GMOxDOC10/day-trader.html. Спецификация рабочей нагрузки также представлена на сайте.

A.6.2 Набор параметров рабочей нагрузки

Число пользователей - 100.

Продолжительность базового прогона - 3300 с.

Отчетный интервал - 30 с.

Смесь транзакций - 70/30 - транзакций чтения-записи (обычная смесь).

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

A.6.2.1 Набор параметров для доказательства состоятельности и устойчивости рабочей нагрузки

Выполнено три базовых прогона со следующими результатами:

- Прогон 1 - 15000,45 страниц/с;

- Прогон 2 - 15600,67 страниц/с;

- Прогон 3 - 15580,45 страниц/с.

Прогоны демонстрируют непротиворечивость и устойчивость, поскольку различие между самым низким и самым высоким результатом не превышает 3,8%.

A.7 Описание ввода неисправности

A.7.1 Спецификация ввода неисправности

A.7.1.1 Неожиданное завершение работы

A.7.1.2 Потеря данных

A.7.1.3 Состязание за ресурсы

A.7.1.4 Реакция на загрузку

A.7.1.5 Обнаружение отказа перезапуска

A.7.2 Набор параметров ввода возмущения

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

- интервал измерения - 3000 с;

- инъекционный интервал - 600 с;

- интервал обнаружения - 1200 с.

Все возмущающие воздействия выполнялись с остановкой и запуском рабочей нагрузки.

A.8 Анкета автономной завершенности

Сделано - см. A.11.

A.9 Выходные данные выполнения базового прогона

Параметры рабочей нагрузки:

Результаты:

Утилизация:

A.10 Выходные данные тестового прогона и результирующие показатели качества

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

Pbase - число завершенных без ошибок транзакций в интервале измерения базового прогона в условиях отсутствия возмущающих воздействий.

Примечание - В качестве примера представлен результат только для одного возмущения.

A.10.1 Неожиданное завершение работы

A.10.1.1 Неожиданное завершение работы операционной системы для СУБД

Параметры рабочей нагрузки:

- те же, что при выполнении базового прогона.

Результат рабочей нагрузки:

- производительность - 1440,43 страниц/с;

- общее количество обработанных транзакций в интервале измерения - 4 502 075;

- общее количество успешных транзакций - 4 321 290;

- общее количество отказов в транзакциях - 180 785 (из-за останова сервера базы данных, обычной тупиковой ситуации и пр., неожиданных ошибок - нет).

Загрузка:

- графики утилизации ЦП и ввода-вывода можно найти в директории /xxx/yyy/911 на сервере X.

Фаза проверки:

- выполнена путем сравнения журнала приложения, отчета о тестировании и подсчета количества строк таблиц, выполненных dbcheck.exe. Результаты совпадают. Результаты всех трех проверок можно найти в директории /xxxx/yyyy/911 на сервере X.

Показатели качества:

- способность к восстановлению - 4321290/4501350 = 0,96;

- индекс автономного восстановления - 3,33/4,0 = 0,83.

Анализ и замечания:

- в базе данных для автоматической обработки отказа реализована AIX HACMP, а для горячего резервирования базы данных - СУБД HADR;

- HACMP обнаруживает завершение работы операционной системы и автоматически подключает резервную базу данных HADR;

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

A.11 Заполнение анкеты автономной завершенности

Наименование показателя - индекс автономного восстановления.

Цель показателя - показать насколько хорошо программный продукт обнаруживает, анализирует и разрешает возмущающие воздействия.

Примечание - Начисление баллов может быть скорректировано на основании опыта, потребительского предпочтения и условий применения.

A.11.1 Неожиданное завершение работы

A.11.1.1 Потеря данных

A.11.1.2 Состязание за ресурсы

A.11.1.3 Реакция на загрузку

A.11.1.4 Обнаружение отказа перезапуска

Индекс автономного восстановления вычисляется как результат деления среднего всех оценок на максимальное значение оценки, равное 4.

--------------------------------

<1> Заменен. Действует ИСО/МЭК 25010:2011.

<2> Заменен. Действует ИСО/МЭК 25040-2011.

<3> Заменен. Действует ИСО/МЭК 15026-3:2011.

<4> Заменен. Действует ИСО/МЭК/ИИЕЕ 15288:2015.

<5> Заменен. Действует ИСО/МЭК 25001:2014.

<6> Заменен. Действует ИСО/МЭК 25021:2012.

<7> Заменен. Действует ИСО/МЭК 25051:2014.