ПНСТ 367-2019 Информационный менеджмент. Облачные вычисления. Структура соглашения об уровне сервиса. Метрическая модель

Раздел библиотеки:35. ИНФОРМАЦИОННЫЕ ТЕХНОЛОГИИ. МАШИНЫ КОНТОРСКИЕ
Язык:
Год:
Язык:
>

ФЕДЕРАЛЬНОЕ АГЕНТСТВО

ПО ТЕХНИЧЕСКОМУ РЕГУЛИРОВАНИЮ И МЕТРОЛОГИИ

ПРЕДВАРИТЕЛЬНЫЙ

НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ

пнет

367-

2019

Информационный менеджмент

ОБЛАЧНЫЕ ВЫЧИСЛЕНИЯ

Структура соглашения об уровне сервиса. Метрическая модель

Издание официальное

Москва Стандартинформ 2019

ПНСТ 367—2019

Предисловие

  • 1 РАЗРАБОТАН Акционерным обществом «Всероссийский научно-исследовательский институт сертификации» (АО «ВНИИС») и Обществом с ограниченной ответственностью «Информационно-аналитический вычислительный центр» (ООО ИАВЦ)

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

  • 3 УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Приказом Федерального агентства по техническому регулированию и метрологии от 18 октября 2019 г. № 44-лнст

Пробила применения настоящего стандарта и проведения его мониторинга установлены в ГОСТ Р 1.16—2011 (разделы 5 и 6).

Федеральное агентство по техническому регулированию и метрологии собирает сведения о практическом применении настоящего стандарта. Данные сведения, а также замечания и предложения по содержанию стандарта можно направить не позднее чем за 4 мес до истечения срока его действия разработчику настоящего стандарта по адресу: 123557 Москва. Электрический пер., д. 3/10. стр. 1 и/или в Федеральное агентство по техническому регулированию и метрологии по адресу: 109074 Москва. Китайгородский проезд, д. 7. стр. 1.

В случае отмены настоящего стандарта соответствующая информация будет опубликована в ежемесячном информационном указателе «Национальные стандарты» и также будет размещена на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет (www.gost.ru)

© Стзндартинформ, оформление. 2019

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

Содержание

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

  • 2 Термины и определения

  • 3 Сокращения

  • 4 Обзор показателей

    • 4.1 Общие положения

    • 4.2 Контекст разработки

    • 4.3 Показатели

    • 4.4 Показатели облачных сервисов

    • 4.5 Показатели облачных СУС

  • 5 Обзор метрической модели

    • 5.1 Общие положения

    • 5.2 Основные понятия

  • 6 Метрическая модель

    • 6.1 Разработка метрической модели

Приложение А (обязательное) Взаимосвязь показателей, целевых параметров и их расчетов

Приложение Б (рекомендуемое) Табличная форма метрической модели

Приложение В (справочное) Пример метрической модели

Приложение Г (обязательное) XML-Схема метрической модели

Библиография

ПНСТ 367—2019

Введение

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

  • • ясность: определение того или иного показателя может быть неполным, неоднозначным, нелогичным или противоречивым, либо такое определение может полностью отсутствовать. Например, определение такого показателя, как «доступность», может не иметь ничего общего с общепринятым понятием термина «доступность». В случае такой неоднозначности сервис может быть практически постоянно недоступен в общепринятом смысле, а в соответствии с выбранным определением показателя показывать стопроцентную доступность. Такое может произойти в случае, если для определения значения показателя требуется постоянный мониторинг, который невозможно обеспечить, или если значение показателя определяется на основании экспертной оценки провайдером сервиса, оценка которого может оказаться субъективной;

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

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

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

  • — ясность: формулировка определения показателя устраняет неоднозначность, присущую описанию. сделанному с помощью «естественного языка»;

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

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

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

ПНСТ 367—2019

ПРЕДВАРИТЕЛЬНЫЙ НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ Информационный менеджмент

ОБЛАЧНЫЕ ВЫЧИСЛЕНИЯ

Структура соглашения об уровне сервиса.

Метрическая модель

Information management. Cloud computing. Service level agreement (SLA) framework. Metric model

Срок действия с 2021—01—01 no 2021—12—31

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

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

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

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

Любая спецификация показателей признается как соответствующая настоящему стандарту в том случае, если эта спецификация использует типы данных и отношения, описанные в разделе 7 настоящего стандарта. Если XML-документ. описывающий метрику, использует пространство имен urn: RosStandard:IT:CtoudCornputing:SLA:Metrics:v1.0.0. этот документ должен соответствовать схеме, приведенной в приложении А.

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

В настоящем стандарте применены следующие термины с соответствующими определениями.

  • 2.1 характеристика облачного сервиса: Свойство облачного сервиса.

Примечание — Сеойсгао/характеристика может быть качественным или количественным.

  • 2.2 показатель облачного сервиса: Показатель, предназначенный для определения характеристики облачного сервиса.

  • 2.3 целевой параметр облачного сервиса: Обязательство провайдера облачного сервиса обеспечить заданную характеристику облачного сервиса.

Примечание — Набор целевых параметров облачного сервиса представляет собой объединение набора целевых количественных и качественных параметров облачного сервиса.

  • 2.4 измерение: Набор операций, направленных на получение результатов измерений.

Примечание — Представленное определение основано на определении «измерения» в соответствии с [1]. Кроме указанного, в настоящем стандарте оно используется в значении отдельного акта выполнения указанных операций, направленных на получение отдельного экземпляра результатов измерений.

Издание официальное

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

  • 2.6 показатель: Стандарт измерений, определяющий условия и правила выполнения измерений и интерпретации результатов измерений.

Примечания

  • 1 Показатель описывает, что означает результат измерений, но не определяет, каким образом он измеряется.

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

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

  • 2.7

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

(ИСО/МЭК 80000-1:2009, пункт 3.9]

3 Сокращения

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

СУС — соглашение об уровне сервиса:

Облачный СУС — соглашение об уровне облачного сервиса;

ПОС — показатели облачных сервисов;

ПДн — персональные данные;

ЦЗОС — целевое значение облачного сервиса;

ЦКОС — целевое качество облачного сервиса.

4 Обзор показателей

  • 4.1 Общие положения

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

  • 4.2 Контекст разработки

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

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

Процесс приобретения облачных сервисов может быть разбит на три основных этапа:

а) подбор облачных сервисов, которые удовлетворяют требованиям потребителя:

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

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

  • 4.2.1 Выбор облачного сервиса

В настоящее время провайдеры определяют состав характеристик облачного сервиса и способы их количественной оценки каждый по-своему. Это делает сравнение характеристик облачных сервисов разных провайдеров (а иногда и одного провайдера) сложным или даже невозможным. Характеристики облачного сервиса часто определяются с помощью размытых текстовых описаний и их трудно не только сравнить, но и просто понять. Это затрудняет перенос набора требований в соглашение между потребителем и провайдером, в результате формируются соглашения (СУС), которое могут не отвечать потребностям сторон. Как описано в [2], обязательство, записанное в облачный СУС. принимает количественную (ЦЗОС) или качественную (ЦКОС) форму. ЦЗОС — это обязательства провайдера по обеспечению характеристик предоставляемого облачного сервиса, имеющие количественную оценку, в то время как ЦКОС — это обязательства в отношении качественных характеристик.

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

Недоступность означает:

а) облачный сервис не отвечает на запросы;

б) облачный сервис возвращает ответ на допустимый запрос пользователя в течение двух или более последовательных интервалов длительностью в 1 минуту;

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

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

Таблица 1 — Пример разных имтерпретацты провайдерами одной характеристики

Сервис

Определение доступности

Обязательство

Целевой параметр

Сервис 1

Доля времени безотказной работы в общем количестве времени работы

99.99%

Время безотказной работы

Сервис 2

Доля успешных транзакций в общем количестве транзакций

99.99%

Время безотказной работы

Сравнение доступности двух сервисов, приведенных в таблице 1. невозможно. В то время как характеристика («доступность») и обязательство по ее целевому значению (99.99 %) кажутся идентичными, текст, определяющий время безотказной работы двух сервисов, принципиально отличается. Облачный сервис 1 использует определение доступности, основанное на времени, а облачный сервис 2 использует определение доступности, основанное на транзакциях. Поэтому потребитель неспособен оценить, в чем заключается различие между этими сервисами.

  • 4.2.2 Преобразование требований потребителя в соглашение

После выбора сервиса провайдер и потребитель уточняют целевые требования к параметрам сервиса. Требования будут преобразованы в набор ЦЗОС (количественные характеристики) и ЦКОС (качественные характеристики), фиксируемые в облачном СУС. Как и описания возможностей облачных сервисов, используемых в процессе принятия решений. ЦЗОС/ЦКОС в настоящее время также описываются неформализованным образом с использованием естественного языка. Это добавляет двусмысленность процессу и увеличивает его время и сложность, поскольку каждый целевой параметр должен быть тщательно рассмотрен и оценен в каждом конкретном случае.

  • 4.2.3 Обеспечение выполнения соглашения

После заключения соглашения и подготовки облачного сервиса к работе начинается его эксплуатация сотрудниками потребителя. В процессе эксплуатации и провайдер, и потребитель контролируют заданные параметры работы сервиса. Провайдер предоставляет потребителю инструменты для измерения характеристик облачного сервиса и/или данные для их измерения. Потребитель сравнивает результаты измерения уровня сервиса с целевыми значениями, указанными в соглашении. Из-за неоднозначного и противоречивого характера описания ЦЗОС/ЦКОС и показателей потребителю сейчас трудно быть уверенным в том. что результаты измерений вычисляются так же. как это определено в облачном СУС.

  • 4.3 Показатели

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

Поютто> -Оимая* Измврммв — «омму* *»

>- Хврахпфмспяв

Рисунок 1 — Определение правил измерения показателем

Показатель описывает характеристику облачного сервиса и сведения, необходимые для ее использования (параметры, данные, правила, выражения, дополнительные сведения). Например, показатель «доступность» будет определять практические шаги процесса измерения, необходимые для расчета доступности, измерения времени простоя, правил исключения и т. д. Результатом измерения является значение, полученное в результате выполнения измерения заданного показателя. Оно служит оценкой наблюдаемой характеристики. Как показано на рисунке 1. показатель определяет правила измерения. поэтому измерение может быть выполнено повторяемым, сопоставимым способом. Измерение дает результат измерения, который в сочетании с информацией о показателе предоставляет сведения о характеристике. Характеристики облачных сервисов почти никогда точно не известны, поэтому вместо этого выполняется аппроксимация характеристики (на основе одного или нескольких измерений). при этом учитывается погрешность между аппроксимацией и фактическим значением характеристики. Эта погрешность напрямую связана с используемым процессом измерения. Другими словами, показатель — это стандартный набор правил, позволяющих генерировать повторяемые, сопоставимые оценки характеристики.

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

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

  • 4.4 Показатели облачных сервисов

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

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

Хотя метрическая модель, описанная в разделе 6, предназначена для общего пользования, в настоящем стандарте основное внимание уделяется показателям, используемым в облачных СУС.

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

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

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

  • — могут использоваться для описания ЦЗОС и ЦКОС облачного СУС:

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

  • 4.4.1 Основные заинтересованные стороны

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

сторона

ywrciMfWintut сторон»

Имтефатор Сторонний

серен»» мониторинг

Потребитель

зеленное перраздммнме

Комкде

сервиса

Служба

Опцрваюнме пэдрмйеление

<_______

Команд» ршрибегпы ______J

Рисунок 2 — Состав и структура сторон, использующих показатели

Представитель

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

Контролирующая сторона

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

Удостоверяющая сторона

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

Договорный отдел/закупочное подразделение потребителя

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

Операционное подразделение провайдера

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

Команда продаж провайдера

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

Риск-менеджер сервиса (со стороны провайдера)

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

Служба поддержки (со стороны провайдера)

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

Команда разработки

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

Интегратор сервисов

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

Служба стороннего мониторинга

Отслеживает обслуживаемые сервисы, используя показатели настоящего стандарта. Должна знать показатели, используемые для данного ЦЗОС или ЦКОС и отслеживать, чтобы мониторинг выполнялся с использованием тех же показателей. Может привлекаться как потребителем, так и провайдером. а также другими заинтересованными сторонами для выполнения измерений показателей настоящего стандарта.

  • 4.4.2 Направления использования показателей облачных сервисов

Настоящий пункт описывает общие направления использования показателей.

  • 4.4.2.1 Описание облачных сервисов

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

  • 4.4.2.2 Сравнение облачных сервисов

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

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

  • 4.4.2.3 Интерпретация соглашений об уровне облачного сервиса

Важные для потребителя характеристики сервисов включаются в облачный СУС в форме целевых параметров показателей.

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

  • 4.4.2.4 Разработка инструментов мониторинга производительности

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

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

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

  • 4.4.2.5 Мониторинг производительности сервиса

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

  • 4.4.2.6 Верификация облачных СУС

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

ИспОЛЬфОТО! 8

Нотисы? пцямеиры

Мегрже

-Оммчнг.8». Иямренм

Характеристик*

Рисунок 3 — Роль показателей 8 цикле мониторинга сервиса

  • 4.4.2.7 Завершение функционального цикла

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

4.5 Показатели облачных СУС

Определение и использование показателей, а также порядок их измерения являются важными компонентами облачных СУС и ЦЗОС/ЦКОС, которые являются составными частями облачных СУС. В облачных СУС показатели используются для установления границ, в которых должен действовать поставщик сервиса. Стандартные показатели и шаблоны показателей облачных СУС упрощают и ускоряют разработку облачных СУС и включенных в них ЦЗОС/SQO легче и быстрее.

5 Обзор метрической модели

  • 5.1 Общие положения

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

Как указано в [2]. «определения облачных ЦЗОС и ЦКОС нейтральны к технологиям или бизнес-мо-делям. поэтому не все ЦЗОС и ЦКОС применимы к тем или иным облачным сервисам, а те. которые применяются. могут быть реализованы и применены по-разному в каждом конкретном облачном сервисе».

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

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

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

  • 5.2 Основные понятия

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

  • 5.2.1 Целевые количественные (ЦЗОС) и качественные (ЦКОС) параметры сервиса

Облачный СУС включает в себя набор целевых количественных (ЦЗОС) и качественных (ЦКОС) параметров сервисов, в отношении которых берет обязательства провайдер сервисов.

Метрическая модель е этом стандарте может использоваться для описания показателей, используемых для описания как ЦЗОС. так и ЦКОС. Однако в случае ЦКОС отсутствуют формулы и параметры. поскольку ЦКОС определяется набором правил формирования показателей.

Пример ЦЗОС — доступность (см. приложение В.1 для этой метрики в форме, предусмотренной настоящим стандартом).

Обязательство

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

Недоступность означает:

• облачный сервис не отвечает на запросы

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

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

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

Определения

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

Пример ЦКОС— согласие на сбор и использование персональных данных (см. В.2 приложения В для соответствующего показателя в форме, предусмотренной настоящим стандартом).

Описание

Данный параметр (ЦКОС) относится к качественным параметрам, описывающим тип договоренности относительно сбора, использования и обмена персональными данными. Значение параметра соответствует следующей шкале.

Формулировка и выходные данные

Уровень 0 — Отсутствие согласия. В процессе или перед сбором персональных данных согласие пользователя получено не было.

Уровень 1 — Предполагаемое согласие. Согласие вытекает из действий субъекта данных, инструменты выражения согласия или отказа не предоставляются.

Уровень 2 — Отказ. Субъект данных может принять меры для недопущения сбора персональных данных, при этом инструменты выражения согласия не предоставляются.

Уровень 4 — Выраженное согласие. Субъект данных явным образом подтверждает согласие на сбор и/или использование персональных данных.

  • 5.2.2 Форматы показателей

Модель, описанная в разделе 7. формирует концептуальную основу для спецификации показателей целостным и непротиворечивым для разных групп пользователей способом, обеспечивает солоста* вимость показателей и потенциально облегчает автоматизацию процесса определения показателей. Подробная спецификация показателя может быть выполнена в формах XML- и JSON-документов или других сериализуемых форматах, как это показано в примерах, представленных в приложениях Б и В к настоящему стандарту. В настоящем стандарте представлены два подхода к заданию показателей:

  • — табличный подход: определение показателей с использованием табличного подхода описано в приложении Б. Примеры, приведенные в приложении В. демонстрируют табличный подход на практике. Таким образом можно задавать составные показатели, хотя итоговые таблицы будут более сложными. Чтобы облегчить использование табличного подхода, можно разработать сборники вспомогательных таблиц для связанных показателей и связанных выражений:

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

6 Метрическая модель

  • 6.1 Разработка метрической модели

При разработке метрической модели учитывают следующие основные цели:

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

  • • явное выделение связей: показатели должны быть представлены таким образом, чтобы отношения между ними, если таковые имеются, были явными. Это объясняет их воздействие и их важность;

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

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

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

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

  • 6.1.1 Спецификация метрической модели

На рисунке 4 показана метрическая модель, поддерживающая ЦЗОС/ЦКОС (2).

Lf (ШвСфйОП

9 nieStatarnort

К» гиШац|Ш01 га пл»

‘—

—хг-

1

1

1

1

га yanetaSUBumJil unit

га п<*и

§ Ьцдиий» ’ч» —

evrarionStEtanont

Eg вфедемеприне

пси

I

-ибагМпй&твйэт

Рисунок 4 — UML-предсгаеление метрической модели

Эта модель использует обозначения диаграммы класса UML [3]. Классы (показаны в виде прямоугольников) представляют типы элементов, которые можно найти в экземпляре показателя. Классы содержат признаки, определяющие данные, присоединенные к элементу. Отношения между классами называются ассоциациями и отображаются в виде линий, связывающих прямоугольники.

Ассоциации с пустым ромбом — это группы, представляющие собой набор повторно используемых элементов. Стрелки в конце ассоциаций показывают направление ассоциации (например, от показателя к правилам). Метка рядом с ассоциацией представляет определенную роль для класса.

Настоящий стандарт не предписывает конкретный формат представления показателя, но используемый формат должен соответствовать схеме классов, описанной на рисунке 4. Если для описания показателя используется XML. он должен основываться на пространстве имен «urn:RosStandard:IT:Clo udComputing:SLA:Metfics:v1.0.0» (XML-схема представлена в приложении Г), а также должен соответствовать схеме, приведенной в приложении А.

  • 6.1.2 Описание метрической модели

Элемент Metric содержит основную информацию, связанную с показателем. Эта информация предоставляет контекст для показателя. Элемент Expression содержит формулу или текстовое описание (например, выраженное на естественном языке), необходимые дня количественного или качественного расчета результата измерения показателя. Элемент Metric может состоять из вложенных элементов, которые записываются в том же виде, что и элемент Metric. Элементы Parameter содержат значения, используемые в элементе Expression. Параметры рассчитываются перед процессом измерения и остаются постоянными во время процесса измерения, но могут изменяться между двумя измерениями. Элементы Rule содержат ограничения, необходимые для понимания характеристики и обеспечения повторяемости измерений, выполненных с помощью показателя.

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

  • 6.1.3 Расширение показателей

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

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

  • 6.1.4 Детальное описание метрической модели

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

Таблица 2 — Показатель: детальное описание

Имя класса

Maine

Описание

Информация о показателе

Атрибут или класс

Тил

Множественность/ обязательность

Определение

Id

Строка

1

Уникальный идентификатор показателя в рамках данного контекста

description

Строка

0..*

Описание показателя

source

Строка

1

Разработчик показателя (лицо или организация)

scale

Список выбора

1

Классификатор типа данных, полученных в результате измерения; возможные значения; «номинальный*, «порядковый», «интервальный» и «отношение», количественные параметры (ЦЗОС) могут быть «интервальными» или «отношениями», качественные параметры (ЦКОС) могут быть «номинальными» и «порядковыми»

Note

Строка

0..’

Дополнительная информация о показателе или способе его применения

category

Строка

0..1

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

expression

Expression

0..1

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

ПНСТ 367—2019

Окончание таблицы 2

Имя классе

Metric

Описание

Информация о показателе

Атрибут или класс

Тип

Множественность/ обязательность

Определение

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

parameter

Parameter

0..’

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

rule

Rule

0..*

Правило предназначено для определения границ показателя и указания допустимых методов измерения; правило может ссылаться на идентификаторы других формул; в то же время в рамках отдельного правила должны использоваться уникальные идентификаторы

undertyingMetric

Metric

0..‘

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

underlyingExpression

Expression

0..*

Дополнительное выражение, используемое в рамках основной формулы, параметра или правила

Детальное описание формулы приведено а таблице 3.

Таблица 3—Формула; детальное описание

Имя класса

Expression

Описание

Формула для расчета показателя и сопроводительная информация

Атрибут или класс

Тип

Множественность? обязательность

Определение

id

Строка

1

Уникальный идентификатор формулы (в контексте показателя)

description

Строка

0..*

Описание формулы

expressionstate menl

Строка

1

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

expressionLanguage

Строка

1

Язык, используемый для формул расчета показателя (в соответствии с ИСО 80000)

note

Строка

0..*

Дополнительная информация о формуле

unit

Строка

0..1 (требуется, если тип результата «интервал» или «отношение»)

Единица измерения

Детальное описание параметра приведено в таблице 4.

Таблица 4 — Параметр: детальное описание

Имя класса

Parameter

Описание

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

Атрибут или класс

Тип

Множественность/ обязательность

Определение

id

Строка

1

Уникальный идентификатор параметра

description

Строка

0..*

Описание параметра

paramelerSlalement

Строка

1

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

unit

Строка

1

Единица измерения

note

Строка

0..*

Дополнительная информация о параметре

Детальное описание правила приведено в таблице 5.

Таблица 5 — Правило: детальное описание

Имя класса

Rule

Описание

Правило предназначено для определения границ показателя и указания допустимых методов измерения; например, показатель «AvailabililyDuringBusinessHour* может быть описан через задание ограничений показателя «AvailaMdy» посредством определения кбизпеввНоиг» {час рабочего времени). Правило содержит ограничения для формулы расчета показателя; ограничения могут задаваться различным образом, неформализованным языком. ИСО вОО&О. SBVR и т. д

Атрибут или класс

Тип

Множественность/ обязательность

Определение

И

Строка

1

Уникальный идентификатор правила

description

Строка

0..*

Описание правила

ruleStatemenl

Строка

1

Ограничение метрики

ruleLanguage

Строка

1

Язык, используемый для формулировки правила в ruleStatement

note

Строка

0..’

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

ЛИСТ 367—2019

Приложение А (обязательное)

Взаимосвязь показателей, целевых параметров и их расчетов

А.1 Спецификация

Спецификация представлена на рисунке А.1

Рисунок АЛ — Целевой параметр и его оценка

А.2 Детализированное описание

Таблица А.1 — Целевой параметр: детальное описание

Имя класса

SO

Описание

Целевом параметр, ассоциированный с конкретным показателем

Атрибут или класс

Тип

Множественности обязательность

Определение

Id

Строка

1

Уникальный идентификатор параметра

name

Строка

0..*

Имя целевого параметра 8 соответствии с «ключевыми понятиями» [6]

soConditionStatement

Строка

1

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

note

Строка

0..’

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

metric

Metric

1

Показатель, ассоциированный с целевым параметром

Таблица А.2 — Результат измерений; детальное описание

Имя класса

MeasuiementResult

Описание

Результат измерения характеристик облачного сервиса, основанных на показателе

Атрибут или

класс

Тил

Множественность/ обязательность

Определение

id

Строка

1

Уникальный идентификатор результата измерений

value

Строка

1

Величина, составляющая результат измерений

uncertainty

Строка

1

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

time

Строка

1

Дата и время проведенного измерения

note

Строка

0..’

Дополнительная информация о результате измерения

metric

Metric

1

Показатель, используемый для получения «value» и «uncertainty»; ссылается на тот же показатель, который ассоциирован с целевым параметром

Таблица А.З — Оценка целевого параметра: детальное описание

Имя класса

SO Evaluation

Описание

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

Атрибут или класс

Тип

Множественность/ обязательность

Определение

id

Строка

1

Уникальный идентификатор выполненной оценки

comparisonResult

Логический

1

Результат сравнения результата измерений с заданной величиной целевого параметра (обязательством)

note

Строка

0..1

Дополнительная информация о проведенной оценке

so

SO

1

Целевой параметр, относительно которого выполняется оценка

measurementResuK

MeasurementResull

1

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

ПНСТ 367—2019

Приложение Б (рекомендуемое)

Табличная форма метрической модели

Б.1 Общие положения

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

Используемый 8 данном разделе шаблон описывает формат, необходимый для разработки метрик, применяемых для получения значений целевых параметров. При работе с документарной формой метрической модели необходимо использовать данный шаблон. Детальная информация относительно атрибутов для каждой таблицы представлена 8 6.1.4. В случае множественности значений того или иного атрибута его значения фиксируются 8 дополнительных строках с тем же именем в 1-й колонке.

При использовании данного шаблона первой создается таблица Metric, связанная с ней таблица Expression, и далее, по необходимости, таблицы Rule и Parameter.

Б.2 Показатели 8 табличной форме

Таблица Б.1 «Метрики» содержит основные сведения относительно показателя, включая описание, уникальный идентификатор и единицу измерения. Также там даются указатели на таблицу с формулами (обязательное значение), параметры (опционально), правила (опционально) и связанные показатели (опционально). Опциональные строки могут отсутствовать в таблицах.

Таблица Б.2 «Формулы» содержит порядок расчета количественных или качественных параметров (в виде уравнения или текста). Также в таблице указываются язык, используемый в формуле, и примечания.

Таблица Б.З «Параметры» содержит определения параметров, используемых в формулах.

Таблица Б.4 «Правила» содержит правила или ограничения, которым должно соответствовать измерение.

Таблица Б.1—Метрики

Melric (id)

description

source

scale

note

category

expressionstatement

parameter

rute

undertyingMetric

underlyingExpression

Таблица Б.2 — Формулы

Expression (id)

description

expressionSlate menl

expressionLanguage

unit

note

Таблица Б.З — Параметры

Parameter (id)

description

parameterstatement

unit

note

Таблица Б.4 — Правила

Rule (id)

description

ruleStatement

ruleLanguage

note

Таблица Б.5 —Табличная форма целевого параметра

SO (id)

name

soConditionSlatement

note

metric

Таблица Б.6 — Таблица оценки целевого параметра

SO Evaluation (rd)

compansonResutt (true/lalse)

note

so

measurementResult

Таблица Б.7 — Таблица результатов измерений

MeasurementResult (id)

value

uncertainty

time

note

metric

ЛИСТ 367—2019

Приложение В (справочное)

Пример метрической модели

В.1 Пример количественной характеристики «Доступность облачного сервиса: табличная

и XML-реализация»

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

В.1.1 Описание примера параметра «доступность»

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

Недоступность сервиса идентифицируется следующим образом:

  • • сервис не отвечает на запросы;

  • • сервис возвращает ошибку сервера на корректный погъзовательский запрос в течение двух или более последовательных интервалов длительностью по одной минуте;

  • — 8 соответствии с замерами третьей стороны длительность загрузки эталонного документа превышает среднюю величину 8 1 секунду.

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

Определение: регламентные работы — это мероприятия по обслуживанию, запланированные не позднее чем за 5 дней до начала, длительностью не более 1 часа в календарную неделю.

В.1.2 Анализ целевого параметра

Целевой параметр ухазан в разделе «Обязательства» и составляет 99.95 % времени. Время. 8 течение которого данная характеристика мажет измеряться, также указано в разделе «Обязательства» как «период тарификации». но значение или порядок определения величины «период тарификации» не представлены. В рамках примера принимается, что «период тарификации» составляет 30 дней. Описание недоступности дано а разделе «Недоступность». В соответствии с описанием имеется три типа недоступности:

  • — отсутствие ответа:

  • • ошибка сервера в ответ на корректный запрос:

  • • медленный ответ сервера.

В разделе «Недоступность» также постулируется исключение: если какое-то из указанных событий имеет место, но были предусмотрены регламентные работы, это не считается недоступностью.

Этой информации достаточно для формирования показателя «доступность». В приведенном далее разделе дается описание данного показателя в табличной форме в соответствии с приложением В. а также в форме XML-документа. сформированного в соответствии со схемой, представленной в приложении А.

В таблице ВЛ приведен пример целевого параметра «доступность» в табличной форме.

Таблица В.1—Целевой параметр «доступность»

SO (SO.001)

name

Доступность обла^мого сервиса (Cloud service availab*ty)

metric

M.AVL.002

soConditionStatement

>99.95%

В.1.3 Пример показателя в табличной форме

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

Таблица В.2

Heine (M.AVL.002)

description

Доступность облачного сервиса (CioudServiceAvailabdity)

source

Пример

Окончание таблицы В. 2

Metric (M.AVL.002)

scale

«Отношение»

note

Основано на общепринятой практике

expressionstatement

Е.001

parameter

Р.001

underlyingMetric

М_ TQD.001

Таблица В.З

Expression (Е ОРТ)

expresstonStatement

100 х (Р.001 — M.TQD.001 УР.001

expressionLanguage

исовоооо

unit

Проценты

Таблица В.4

Parameter (Р_001)

parameterstatement

2.592×10*6

unit

Секунды

note

Параметр соответствует 30-дневному периоду тарификации, выраженному в секундах

Таблица В.5

Metre (M.TOO.OOI t

description

Общее время простоя (TotalQualifiedDownTime)

source

Пример

scale

«Отношение»

underlyingMetric

M.QDT.001

expression

Е.001

Таблица В.6

Expressen (E.OOt)

expressionstatement

Z(M_QDT_001)

expressionLanguage

исовоооо

unit

Секунда

Таблица В.7

Metre (M.ODTJJOI >

description

Время простоя (QuaJifiedOownTme)

source

example

scale

RATIO

rule

R.001. R.002. R.003

expression

E.001

ПНСТ 367—2019

Таблица В.8

Expression (E QOC!)

expressionstatement

A(t)

expressionLanguage

ИСО 80000

unit

Секунда

Таблица В.9

Rute(R.OOt)

ruteStatement

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

ruleLanguage

Russian

Таблица ВЛО

Rule(R_002>

ruteStatement

Сервис не откликается

ruleLanguage

Russian

Таблица ВЛ1

Rute(R 003)

ruleStatement

Сервис возвращает ошибку сервера в ответ на корректный пользовательский запрос в течение двух или более последовательных интервалов длительностью по одной минуте

ruleLanguage

Russian

Таблица ВЛ2

Rule(RJXM)

ruleStatement

Длительность загрузки эталонного документа превышает среднюю величину в 1 секунду. Недоступность, вызванная регламентными работами, исключена из расчета

ruleLanguage

Russian

ВЛ.4 Пример метрики в форме XML-документа

Ниже представлен пример XML-документа. описывающий изложенный выше пример метрики. <?xmlv6rsion=»1.0f‘ encoding=»UTF-8″?> <Metricsxmins=»um;RosStandard;IT:CloudComputing:SLA:Metncs:v1.0.0*> <Metricdescripbon=“CtoudSe<v»ceAva»lability*source=’exampt6“id=»M_AVL_002″scale=» RATIO»> <Expression»d=*E_001“expressionStatement=’ 100 x (P_001- M_TQD_O0iyP_001“ expcessK)nLanguages*>SOBOOOO»units*peccenlage7> <Parametefid=»P_001’paramete<Statement=»2.592 x10»6*’unit=’’second»

по<ег*Параметр соответствует 30-дневному периоду тарификации, выраженному в секундах 7> <UnderlyingMelricRefrefid=*M_TQD_OOr/>

</Metric> <Metricdescription=»TotalQualifiedDowntime“source=»example*td=*M_TQD_OOrscale=*RA,nO*> <Expcessionki=‘,E_00rexpressionStatement=’&#x3A3;(M_QDT_00lj» express<onLanguages*!S080000*units*S6Cond7>

<Underty»ngMetficRefrefid=*M_QDT_0017>

</Metric> <Metricdescfiption=*QualifiedDownTim6*source=»example“id=‘M_QDT_OOrscaie=»RATIO*> <Expressionid=“E_00rexpressionStatement=’&#x394;(t)“expressionLanguage=’iSO80000’‘unit=’s6cond»/>

<Ruleid=*R_00rruleLanguage=»Russian4ang=»ru* njleStatement=»BpefcieHHoA интервал начинается с моменте обнаружения, что сервис недоступен, и завершается в момент. когда фиксируется, что сервис перестал быть недоступен в соответствии с правилами R.002. R.003. R.Q047» <Ruieid=*R_002’ruleLanguage=»Russian*lang=“ru* ruteSlatements*Cep8HC не откликается»/»

<Ruteid=*R_003’ruleLanguage=»Russian*lang=»ru* ruteStatements*Cep8HC возвращает ошибку сервера в ответ на корректный пользовательский запрос в течение двух или более последовательных интервалов длительностью по одной минуте»/»

<Ruieid=*R_004*ruleLanguage=»Russian4ang=»ru* futeStatements*AnHTenbHocTb загрузки эталонного документа превышает среднюю величину в 1 секунду. Недоступность. вызванная регламентными работами, исключена из расчета.»/»

«/Metric»

«/Metrics»

В.1.5 Пример оценки целевого параметра доступности

После формирования облачного СУС между провайдером и потребителем сервиса и настройся аккаунтов сотрудники потребителя могут начать использовать сервис. В рамках приведенного выше примера примем, что время простоя в течение периода тарификации составило 2 часа, что эквивалентно 7200 секундам. Таким образом:

  • • связанный показатель M.QDT.001 = [4000 с. 3200 с] (примем наличие двух периодов простоя);

  • • связанный показатель M.TQD.001 = 7200 с;

  • • параметр Р_001 = 2.592 * 106 с (период тарификации);

  • • формула расчета показателя:

    M.AVL.002 = 100

    wP_001-M_TQD_001.

    Р 001

результат измерения:

M.AVL.002 = 100 ♦

2.592 *106 -7200

2.592-10е

Один из способов использования показателя облачюго СУС — оценка целевого параметра, включенного в облачный СУС. На рисунке 3 представлена связь между результатом измерения M.AVL.002 и значением целевого параметра. Поскольку обе величины основаны на одном и том же показателе, они подлежат сравнению с точки зрения оценки факта выполнения зафиксированных обязательств. На основе приведенного выше примера оценка целевого параметра выглядит следующим образом:

Таблица В.13

MeasuremonlRaeull (MR 001)

value

99.722

uncertainty

He задана

time

23.05.2018 21:00

metric

M.AVL.002

Таблица В.14

SO Evaluation (SOE_001)

comparisonResutt (true/false)

FALSE

so

SO.001

measurementResult

MR.001

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

8.2 Пример качественной характеристики аСогласие на сбор и использование персональных данных»

В.2.1 Описание примера качественного целевого параметра

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

ЛИСТ 367—2019 чигь при передаче персональной идентификационной информации (в соответствии с NIST 800-53v4 [4]). Исходя из предпочтений пользователей, выделяют разные степени подтверждения/согласия на обработку персональной информации.

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

В.2.2 Анализ описания параметра

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

— уровень 0 — Отсутствие согласия. В процессе или перед сбором персональных данных согласие пользователя получено не было:

  • • уровень 1 — Предполагаемое согласие. Согласив вытекает из действий субъекта данных, инструменты выражения согласия или отказа не предоставляются;

  • • уровень 2 — Отказ. Субъект данных может принять меры для недопущения сбора персональных данных, при этом инструменты выражения согласия не предоставляются:

  • • уровень 4 — Выраженное согласие. Субъект данных явным образом подтверждает согласие на сбор и/или использование персональных данных.

Предоставленной информации достаточно для формирования показателя «Согласие на сбор и использование персональных данных». В следующих разделах представлено описание указанного показателя в табличной форме (в соответствии с приложением Б) и в форме XML-документа по схеме, заданной в приложении Г.

Таблица В.15 — Пример качественного целевого параметра

SO (SO.002)

Name

Согласие на обработку персональных данных (PI! Consent)

soConditionStatement

True if «3*

Metric

М_ТРС_001

В.2.3 Пример показателя в табличной форме

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

Таблица В.16

Maine (M.TPC.001)

Description

Тип согласия на обработку лерсонагъных данных (TypePIlConsent)

Source

Пример

Scale

«Порядковый»

Note

Согласие на обработку лерсонагъных дангшх ранжировано по следующей шкале

Expression

E.TCL.001

undertyingMetric

M_TCL_OOt. M_TCL_002. M_TCL_003. M.TCL.004

Таблица В.17

Expression <E TCL 001)

expressionstatement

M_TPC_001 равняется одной из величин M_TCL_001. M_TCL_002. M_TCL_003. or M.TCL.004. в зависимости от критериев, указанных в соответствующих правилах

expressionLanguage

Russian

Таблица В.18

Metre {M.TCL.001)

description

Тип согласия — Уровень 0 (TypePIIConsent_LevelO)

source

Пример

scale

«Порядковый*

rule

R.001

expresston

Е_001

Таблица В.19

Expressen (E.OOt)

expressionstatement

0

expresstonLanguage

ИСО 80000

Таблица В.2О

Rule (R.001)

rulestatement

Отсутствие согласия. В процессе или перед сбором персональных данных согласие погъзователя получено не было

ruleLanguage

Russian

Таблица В.21

Metre (M.TCL.002)

description

Тил согласия — Уровень 1 (TypePIIConsenl_Level1)

source

Пример

scale

«Порядковый*

rule

R.002

expression

Е.002

Таблица В.22

Expressen (Е.002)

expressionstatement

1

expressionLanguage

ИСО 80000

Таблица В.23

Rule (R.002)

rulestatement

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

ruleLanguage

Russian

Таблица В.24

Metric (M.TCL.003)

description

Тип согласия — Уровень 2 (TypePI!Consent_Levei2)

source

Пример

scale

«Порядковый»

rule

R.003

expression

Е.003

Таблица В.25

Expression (E.003)

expressionstatement

2

expressionLanguage

ИСО 80000

Таблица В.26

Rule (R.003)

rulestatement

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

ruleLanguage

Russian

Таблица В.27

Metric (M.TCL.004)

description

Тип согласия — Уровень 3 (TypePIIConsent.LeveO)

source

Пример

scale

«Порядковый»

rule

R.004

expression

Е.004

Таблица В.28

Expression (Е.004)

expressionstatement

3

expressionLanguage

ИСО 80000

Таблица 8.29

Rule (R.004)

rulestatement

Выраженное согласие. Субъект данных явным образом подтверждает согласие на сбор и/или использование персональных данных.

ruieLanguage

Russian

В 2.4 Пример метрики в форме XML-документа

Ниже представлен пример XML-документа. описывающий изложенный выше пример метрики. <?xmlversion»»1.0r encodtng=»UTF-8″?> <Metricsxmlns=’um;RosStandard:rr:CloudComputiogSLA:Metncs:v1.0.0*>

«Metncid=»M_TRC_OOrdescript»on=»TypeOfPilConsent»source=“example*scale=*ORDINAL»

notes*CornacHe на обработку персональной информации ранжировано по следующей шкале»»

< Expressionids**E_TCL_001″

expressionStatemenl=» М_ТРС_001 равняется одной из величин M_TCL_001. M_TCL_002, M_TCL_003. orM_TCL_004. в зависимости от критериев. указанных 8 соответствующих правилах**

expression Languages«Russian7>

«Underlying Me tncRefrefid=»M_TCL_0017>

«Underlying Me tricRefrefid=»M_TCL_0027»

«UnderlyingMetricRefrefida«M TCL_0037>

«UnderiyingMetricRefrefid=»Mj*CL_0047»

«/Me too «Metricid=»M_TCL_001’descript>on=’*TypeOfPIIConsent_Lev6Wsource=-example*scale=,*ORDlNAL“> <Expressionids«E_001″expressionStatements«0»expressionLanguages*IS080000″/* «Ruteid=»R_OOrruleLanguage=»Russian»lang=“ru»

ruteStatements*OrcyrcTBHe согласия. В процессе или перед сбором персональных данных согласие пользователя получено не было»

!>

«/Metric*

«Metricid^M TCL_002*d8SCripbon=*TypeOfPIIConsent_Level1″sowce=»example*scale=*ORDlN

AL’*

<Expressionid=»E_002″express»onStatemenla«1*expressionLanguage=*iS080000″/» <Ruieids*R_002*ruleLanguage=»Russian’lang=»ru*

ruteStatement=TlpaflnonafaeMoe согласие. Согласие вытекает из действий субъекта данных, инструменты выражения согласия или отказа не предоставляются»

Г>

«/Metric*

«Metricid=»M TCL_003*description=»TypeOfPIIConsent_Level2″soufce=»example’scale=*ORDIN

AL**

<Expressxxiids«E_003*expressrenStalemenl=»2″expressionLanguage=*iS080000″/> <Ruleids’R_003*ruleLanguages«Russ»an*langa«ru*

rukeStatements*Onca3. Субъект данных может принять меры для недопущения сбора персональных данных, при этом инструменты выражения согласия не предоставляются»

1>

«/Metnc*

«Metricida«M_TCL_004’descripbon=»TypeOfPIIConsent_Level3″source=»example*scalea*ORDlN

AL’>

<Express»onids*E_004’express»onStatemenl=»3″expressionLanguages*IS080000″/>

« Ruleids*R_004*ruleLanguage=»Russian*lang=»ru»

ruteStatement=’BbipaxeHHOe согласие. Субъект данных явным образом подтверждает согласие на сбор и/или использование персональных данных.»/*

«/Metric*

«/Metrics*

В.2.5 Пример оценки целевого параметра

Фиксация результатов измерений

Таблица В.ЗО

McawrementResult (MR 002|

value

3

uncertainty

Данные стороннего аудита

time

25.05.2018 21:00

metric

M.TPC001

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

Таблица В.31

SO Evaluation (SOE Q02)

compansonResutt (true/false)

TRUE

so

SO.002

measurementResult

MR.002

Из приведенного выше примера следует, что данный целевой параметр провайдером обеспечивается.

В.З Пример расширения модели в JSON — определение элемента выборки

В.3.1 Общие положения

В процессе формирования показателей часто возникает потребность снабдить модель дополнительными сведениями о порядке выполнения расчетов.

В.3.2 Пример 1

Например, необходимо собирать информацию для последующего выполнения выборки данных. Это может быть реализовано посредством создания дополнительного элемента «Выборка» (Sample) (входящего во внутреннюю структуру показателя). Представленный ниже пример взят из действующего онлайн-хранилища бинарных данных, в СУС которого предусмотрены разные обязательства в зависимости от типа операций. В представленном примере элемент «Выборка» (Sample) создается только для одного типа операций, однако указанный порядок может быть экстраполирован на другие типы операций. Приведенный ниже фрагмент описания показателя содержит дополнительные сведения для связанного показателя «M_HER_001*. посредством использования созданного пользователем элемента «Выборка» (Sample).

«expression*:! *id»:*E_00r. «expressionSlatement»:»E_003/E_002*. «expressionLanguageVISOeOOOO».

“undertyingExpression»:[

*id*:*E_002″. “expressionstatement».»&#3A3:(SAMPLE_001 belonging to P_001)*. «expressionLanguage»:’ISOeOOOO».

“note»:’Number of samples within the boundary period*

{

«id»:*E_003″. “expressionstatement»:»&#3A3;(SAMPLE_001 .value>P_002 belongingtoP_001 *expressionLanguage*:*ISOBOOOO».

”note»:’Number of error samples within the boundary period* ) )

И новый элемент «Выборка» (Sample) выглядит следующим образом: «samples»:!!

«name*:»STORAGEGETBLOCKLISTAPICALLresponsetime», “i<T;*SAMPLE_00r.

«scaleTinterval». «valueJimit’:»P_002*. *unit’-.»second».

«protocolTREST*.

“operation»:*GetBlockLrst». “по1е»:*примереыборкндляизыерениявремениот клика сервиса* )l

Ниже представлен полный текст JSON-документа, описывающего пример:

{ «description»:»M AS Availaibiity*.

“id*:*MAS_00r. «source’/’example». «scale»;»NOMINAL». «expression»:! «expressionSlatement»:»M_MUP_002 < P_002″. “expression La ng uage»:*ISO80000″

«parameter»:!! «id*:*P_002». «description»:»availability_limir. «unit*:»*».

«parameters tatement*:»99.9»

)].

‘underlying Me tric’:[( ‘дввслрЬоп’.’Долявременибезотказнойработыетечвнмемесяиа’. ‘»d’:»M_002′.

“souroe»:»example*.

«scale»:’RATIO».

«expression»:!

“jd»:»E_002*.

«expressionStatement*:*100 — M_AER_001». «expressionLanguage*:»lS080000*.

“unrt»:»%»

}.

«underlying Methc“:[{ «(1е5спрЬоп*:*Средняядоляошибок*.

«td’:»M_AER_001».

«source»:»example*.

*untt»:*%»,

“scale*:‘RATIO»,

“expression»:!

*expressionSt8tement*:*M AER.001 =AVG(M_HER 001) AND M HER.001 belonging to P.001*.

«express» nLanguageTISOOOOOO»

}.

«parameter*;!!

«йГ:»Р_00Г.

“deschption’/nnarexHwnnepnofl».

«unrtVmonttT,

«paramelerSlalementVI ’

}).

«underlying Me

“description»;*flonRoujM6oK. вчас».

«id*:»M_HER_00r.

“souroe»:»example*.

*uniT:»%».

«scale*:’RATIO»,

«expression*:!

*id“:»E_001*. «expressionStatem6nt»:*E_003/E_002“.

«express® nLanguage‘:»IS080000»,

«underlyingExpression*:[

{

“jd»:”E_002*.

“expressionStatement*:»&#3A3:(SAMPLE_001 belonging to P_00t)». «expressionLanguage*:»IS080000».

*гхЯе*:*Количестеозлеыен108выборкиарамкахзадакногопериода «

}.

{

“id»:»E_003*.

“expressionStat6ment“:*&#3A3:(SAMPLE_001 .vatue>P_002 beiongmgtoP_001)», «expressionLanguage*:»IS080000*.

*гхЯе*:*Количестеоэлемен1Обвыборкисошибкамиврамкахзадэнногопериода *

}

1

}.

«parameter*:!

{

«parameterSlatemenr:*3600».

«ЬевспрЬоп’/заданный период*.

“uniT:»second*.

«id“;»P 001*

}.

{

«parameterSlatemenr:*60».

«unit1:»second1.

«icT:1P 002″

).

{

«id»:1P_003″.

«descriptionVnnarexHbiH период».

«unit’:»monlh».

«parameters tatement1:»1″

) ].

«samples»:{{ «name‘:»STORAGEGETBLOCKUSTAPICALLresponsetime».

«id»;1SAMPLE_00r,

«scale»:»inlervar, «value_limit»:»P_0021. *unil’:»second1.

«protooorfREST1.

«operation»:»Ge®lockL»st».

«note»:» примереыборкидляизмерениявремешоткликасервиса «

)] И )] И. «noteVDpMMep» )

В.3.3 Пример 2

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

Поскольку элемент «Выборка» (Sample) в модели не определен, класс «Выборная (Sample) мажет быть изменен и получена следующая форма:

«parameter»:}

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

Текст JSON-документа для представленного примера изложен ниже:

( *бевспрЬоп“:*Параметрывиртуальногоядрадлямалыхвиртуальныхмашин*. “id’;»M_MAS_00r.

“source»:“example*. “scale’i’NOMINAL».

“expression’ll

“id»:»E_001*.

“expressionStatement“:’M_STD001 < P.002 & M.AVG.001 о P_003″,

“expcessionlanguage’riSOeOOOO’

“parameter*:!

{

“id’:»P_002*.

“parameterSlatement»:*10″

}.

{

“»d»;“P_003*.

“un>t»:“operat>ons per second*.

“paramelerStatement»:*X*

}

1.

“underlying Me tric“;l( *пате“:*Србдмеестандартноботклонениеотэталонныхзначенийтестоепроиз8одительности.%отсредяегозначения*. “>d*:»M_STD_00r.

“souroe»:“example*,

“unrt»:’%»

“scale»:*RATIO».

“expression’ll ‘expressKjnStat6menC;’100’average[(abs(SAMPLE_001-M_AVB_001)/M_AVB_001]’. “expressionLanguage*:“IS080000″

“parameter*:!].

‘underlyingMethc*:[(

‘ОезслрЬоп’/Среднийэталонныйрезультаттеста производительности*.

“id*;»M AVB001″.

“unit»:’».

“scale“:*intervar.

‘expression’ll

“»d*:»E_001*.

“expressionStatement*:*average(SAMPLE_001) belonging in P_001″. “expressionLanguage’;»IS080000“

}.

“parameter*;!

{

“id»:»P_001*.

“unrt»:“month*.

“parameterStatemenl»:*! *

}.

{

“id*:»P_004*.

“parameterStalement»:*small. default, large*.

“scale“:*ordinar

}-

{

“»d»:“P_005*.

“unit»:“perday*.

“parameters tatementVJ»

)

].

«samples»^

«description»:»DaCapo Benchmark»,

«id»:*SAMPLE_OO1″,

“scaleTinterval»,

«value»:*Throughpur.

«unitVoperations/sec*.

«operation»:’Avrora».

*’workload_type»:’P_004″1

«wockload_value»:*default».»frequency’;»P_005*.

«note»:’ примвропределениятестапроизводигепьности )l

)l

)].

«по№»:*примерметрикивформате JSON»

)

Приложение Г

(обязательное)

XML-Схема метрической модели

Представление показателя в форме XML-документа должно соответствовать как UML-модели, представленной е приложении А. так и XML-схеме. представленной ниже. XML-схема соотнесена с пространством имен:

um:RosSlandard:IT;CloudComputing:SLA:Metrics:v1.0.0.

<?xml version=»1.0* encoding=*UTF-8*?> <xs:scbemaxmlns:xs=Tittp7Mfww.w3.ocjy2001/XMLSctiema* efementFormDefauft=»quaiified“ targetNamespace=’um;RosSlandanl:IT:CloudComputing:SLA:Metfics:v1.0.0″ version»* 1.0.0″ xmlns=-um:RosStandard:IT:CtoudComput)ng:SLA:Melrics:v1.0.0″>

<xs:complexType name»*Metr»cType»>

<xs:sequence>

<xs:elsment name»*Expression* type»*Express»nType» minOocurs=»07>

<xs:elecnent name=*ExpressionReF type=“ReterenceType* minOccurs=*0″/>

<xs:element name=’Parameter* type=*ParameterType* mmOccurs=*0*

maxOccurs=“unbounded7>

<xs:elemenl name»*ParamelerRer type=»ReferenceType‘ minOccurs=*0* maxOccurs=“unbounded“/>

<xs:elemeril name=*Rule» type=*RuleType* miпOccuгs=*0,* max0ocurs=»unbounded7>

<xs:elemenl name»*RuleRer lype=”R6ferenceType* mtnOccurs=*0* maxOccurs=“unbounded’/>

<xs:element name=*UndertyingMetnc“ type=*MetncType* minOccurs»*^

maxOccurs»»i<)bounded7>

<xs:elemenl name=*UndertyingMetncRer type»*ReferenceType* minOccurs=»0* maxOccurs»»i<)bounded7>

<xs:elemenl name=*UndertyingExpression» type»»ExpressionType* minOccurs»^* maxOccurs=»K)bounded7>

<xs:elemenl name=*UndertyingExpressionRer type»*ReferenceType» minOccurs=»0″

maxOccurs»»i<)bounded7>

</xs:sequence>

<xs:a№ibute name»*»d» use=*requtfed* type=“xs:NCName7>

<xs:atlribute name=»descripbon» type=*xs:slring7>

<xs:a№ibule name»*source* use»’required* lype=»xs:NCName*/>

<xs:attribute name»*scale* use»»required*>

<xs:SHnpleTyp6>

<xs:restriction base=“xs:slhng*>

<xs:enumerabon value»“0RDINAL7>

<xs:enumeration va1ue=»NOMINAL7>

<xs:enumerabon value=»INTERVAL7>

<xs:enumerabon va1ue=»RATlO7>

</xs:reslriction>

</xs:simpteType>

</xs:attnbute>

<xs:atlribute name=*calegory* type=»xs:slnng7>

<xs:a№ibute name=*note* type=“xs:string7>

</xs:compiexType>

<xs:complexType name=’ParameterType’>

<xs:a№ibute пагтю=»кГ use=*required* type=»xs:NCName»/>

<xs:atlribute name=»descripbon» type=“xs:slring7>

<xs:a№ibute names*parameterSlatemenf use»*required» type=»xs:string7>

<xs:atlribute name=»unit’ use=»reqwred» type=»xs:NCName7>

<xs:a№ibute name=*note’’ type=»xs:string’/>

</xs:comptexType>

<xs:complexType name=*Express»onType*>

<xs:a№ibute name=7d» use=*required* type=»xs:NCName7>

<xs:attnbute name»*description* type=»xs:slring7>

<xs:attribute name=»expressionStatement,‘ use=»requirecT type=“xs:string7> <xs:attribute name=»expressionLanguage» use=»required“ type=»xs:NCName7* <xs:attribute name=»unif types«xs:NCName7>

<xs:attribute name=»note* type=“xs:slring7* </xs:complexType>

<xs:comptexType name=»RuieType»*

<xs:attribute name=»id* uses*required» type=“xs:NCName*/*

<xs:attribute name=“njleStalemenr uses«requred* type=“xs:string7> <xs:attribute name=»ruleLanguage» use=»required* type=’xs:NCName»/> <xs:attribute name=»lang“ use=»requirecf type=»xs:NCName*/>

<xs:attribute name=»note* type=’xs:string7> </xs:complexType*

<xs:comptexType name=»ReferenceType’>

<xs;attribute name=“reficr use=*requtred»type=*xs:NCName7* </xs:complexType>

<xs:element name=“Metncs*>

<xs:ccxnptexType>

<xs:choice maxOccurs=*unbounded**

<xs:etement name=”Metric’ type=*MetricType»/>

<xs:etement name=“Expression’ type=»ExpressionType7*

<xs;etement name=»Parametsr» type=»ParameterType»7*

<xs:et6ment name=*Rule* type=“RuieType7>

</xs:choice>

</xs:complexType*

<*- • Uniqueness constraints — -> <xs:unique name=“metricfDUnique** <xs:selector xpath=’.//’/Metric»/* <xs:fietd xpath=»@id7* </xs:unique>

<xs:unique name=“expressionlOUnique’>

<xs:selector xpath=’.//’/Expression*/*

<xs:fietd xpath=»@id7*

</xs:unique>

<xs:unique names«parameterlDUnique»>

<xs;seteclor xpath=*.//7Parametsr7>

<xs:field xpath=»@id*/*

</xs:unique>

<xs:unique names«rulelDUnique»*

<xs:selector xpath=*.//*/Rute*>

<xs:fietd xpath=»@id7*

</xs:unique* </xs:element>

</xs:schema*

Библиография

  • [1] ИСО/МЭК 15939:2017 Системная и программная инженерия. Процесс измерения (Systems and software engineering — Measurement process)

  • (2] ИСО/МЭК 19086-1:2016 Информационные технологии. Облачные вычисления. Структура соглашения о качестве предоставляемых услуг (SLA). Часть 1. Обзор и концепции (Information technology — Cloud computing — Service level agreement (SLA) framework — Part 1:Ove<v»ew and concepts)

  • (3] ИСО/МЭК 19501:2005 Информационные технологии. Открытая распределительная обработка. Унифицированный язык моделирования (UML). Версия 1.4.2 (Information technology — Open Distributed Processing — Unified Modeling Language (UML) Version 1.4.2)

  • [4] National Institute of Standards and Technology (NIST) Special Publication (SP)800-53 (NIST 800-53)

УДК 004:006.354

ОКС 35.020

Ключевые слова: информационные технологии, облачные вычисления, договор об уровне сервиса, метрическая модель

БЗ 10—2019/45

Редактор В.Н. Шмельков Технический редактор И.Е. Черепкова Корректор ЕЛ Дульнева Компьютерная верстка ПА. Круговой

Сдано а набор 21.10.2019. Подписано а печать 21.11.2019 Формат 6О*8л’/8. Гарнитура Ариал. Усл. леч л. 4.6S. Уч.-идд. л 3.95

Подготовлено на основе электронной версии, предоставленной разработчиком стандарта

Создано о единичном исполнении во . 117418 Москва. Нахимовский пр-т. д. 31. к. 2.

www.goslinfo.ru mfo@gosbnfo.ru

1

i<T:1P_00r.

«unif:»month1.

«parameterStatemenr:»1»

).

{

«id»:1P_004″, «parameterStatementVsmall. default, large».

«scale»:»ordmar

).

{

«id»:1P_005″.

«unitVperday».

«param6terSlatement»;»3″

)

J.

«samples”:}} ”description»:»DaCapo Benchmark1.

*id»:’SAMPLE_001“.

«scale»:»intervar, “vahje“:1Throughput». *unit’:»operations/sec1. «operationVAvroca».

*workload_type»:1P_004″, *workload_value»:1default», «frequency»:»P_005″.

«по1е»:1примеропределвниятестапроиээодительносги»

Оцените статью
Комментарии читателей