ПНСТ 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 %) кажутся идентичными, текст, определяющий время безотказной работы двух сервисов, принципиально отличается. Облачный сервис 1 использует определение доступности, основанное на времени, а облачный сервис 2 использует определение доступности, основанное на транзакциях. Поэтому потребитель неспособен оценить, в чем заключается различие между этими сервисами.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Рисунок 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.

Рисунок 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).

Рисунок 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 — Показатель: детальное описание

ПНСТ 367—2019

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

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

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

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

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

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

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

ЛИСТ 367—2019

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

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

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

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

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

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

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

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

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

ПНСТ 367—2019

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ЛИСТ 367—2019

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Таблица В.2

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

Таблица В.З

Таблица В.4

Таблица В.5

Таблица В.6

Таблица В.7

ПНСТ 367—2019

Таблица В.8

Таблица В.9

Таблица ВЛО

Таблица ВЛ1

Таблица ВЛ2

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

Ниже представлен пример XML-документа. описывающий изложенный выше пример метрики. <?xmlv6rsion="1.0^f' 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)nLanguage^s*>SOBOOOO"unit^s*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<onLanguage^s*!S080000*unit^s*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* ruteSlatement^s*Cep8HC не откликается"/»

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

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

«/Metric»

«/Metrics»

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

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

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

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

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

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

  M.AVL.002 = 100

  
  

  _wP_001-M_TQD_001.

  Р 001

  
  

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

2.592 *10⁶ -7200

2.592-10^е

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

Таблица В.13

Таблица В.14

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Таблица В.16

Таблица В.17

Таблица В.18

Таблица В.19

Таблица В.2О

Таблица В.21

Таблица В.22

Таблица В.23

Таблица В.24

Таблица В.25

Таблица В.26

Таблица В.27

Таблица В.28

Таблица 8.29

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

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

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

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

< Expressionid^s**E_TCL_001"

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

expression Language^s"Russian7>

«Underlying Me tncRefrefid="M_TCL_0017>

«Underlying Me tricRefrefid="M_TCL_0027»

«UnderlyingMetricRefrefid^a"M TCL_0037>

«UnderiyingMetricRefrefid="Mj*CL_0047»

«/Me too «Metricid="M_TCL_001’descript>on=’*TypeOfPIIConsent_Lev6Wsource=-example*scale=^,*ORDlNAL“> <Expressionid^s"E_001"expressionStatement^s"0"expressionLanguage^s*IS080000"/* «Ruteid="R_OOrruleLanguage="Russian"lang=“ru"

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

!>

«/Metric*

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

AL’*

<Expressionid="E_002"express»onStatemenl^a"1*expressionLanguage=*iS080000"/» <Ruieid^s*R_002*ruleLanguage="Russian’lang="ru*

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

Г>

«/Metric*

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

AL**

<Expressxxiid^s"E_003*expressrenStalemenl="2"expressionLanguage=*iS080000"/> <Ruleid^s’R_003*ruleLanguage^s"Russ»an*lang^a"ru*

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

1>

«/Metnc*

«Metricid^a"M_TCL_004’descripbon="TypeOfPIIConsent_Level3"source="example*scale^a*ORDlN

AL’>

<Express»onid^s*E_004’express»onStatemenl="3"expressionLanguage^s*IS080000"/>

« Ruleid^s*R_004*ruleLanguage="Russian*lang="ru"

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

«/Metric*

«/Metrics*

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

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

Таблица В.ЗО

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

Таблица В.31

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

В.З Пример расширения модели в 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".

"unit¹:"second¹.

"icT:¹P 002"

).

{

"id":¹P_003".

"descriptionVnnarexHbiH период".

"unit’:"monlh".

"parameters tatement¹:"1"

) ].

"samples":{{ "name‘:"STORAGEGETBLOCKUSTAPICALLresponsetime".

"id";¹SAMPLE_00r,

"scale":"inlervar, "value_limit":"P_002¹. *unil’:"second¹.

"protooorfREST¹.

"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"₁

"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 type^s"xs:NCName7>

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

<xs:comptexType name="RuieType"*

<xs:attribute name="id* use^s*required" type=“xs:NCName*/*

<xs:attribute name=“njleStalemenr use^s"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 name^s"parameterlDUnique">

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

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

</xs:unique>

<xs:unique name^s"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

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

БЗ 10—2019/45

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

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

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

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

www.goslinfo.ru [email protected]

¹

i<T:¹P_00r.

"unif:"month¹.

"parameterStatemenr:"1"

).

{

"id":¹P_004", "parameterStatementVsmall. default, large".

"scale":"ordmar

).

{

"id":¹P_005".

"unitVperday".

"param6terSlatement";"3"

)

J.

"samples”:}} ”description":"DaCapo Benchmark¹.

*id":’SAMPLE_001“.

"scale":"intervar, “vahje“:¹Throughput". *unit’:"operations/sec¹. "operationVAvroca".

*workload_type":¹P_004", *workload_value":¹default", "frequency":"P_005".

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