Sap sla что это

SAP Cloud Platform Service Level Agreements and ITSM Process

The SAP Cloud Platform service level agreement (SLA) is a contract between SAP and its customers that defines the system availability that SAP promises our customers, as well as the compensation that’s due to them if we fail to deliver the promised availability.

The goal of this blog is to give you an understanding of the contracts that define this SLA as well an overview of how SAP’s world class ITSM processes enable us to provide a high level of business continuity to our customers. We also want to provide a consolidated list of links that will allow you to monitor your systems, and further understand how this applies to your business.

Before we look at the contracts, I want to make sure you have a clear understanding of the services covered by the SLA. As you know, SAP has different several cloud offerings:

With that said, it is important to understand that although SAP Cloud Platform can be used to extend HANA Enterprise Cloud and our SAAS applications, it is separate from them and has a separate system availability SLA. This SLA pertains only to the availability of productive instances of SAP Cloud Platform service packages that you purchase.

SLA Definition:

The Service Level Agreement involves several documents that can be found in the SAP Trust Center. The first entry point into the contract is the order form.

The order form is the document used to subscribe to SAP Cloud Platform services from SAP. It defines the commercial terms and lays out the agreement structure. The order form also incorporates several other documents that relate to the SLA. How the agreements work together is based on structure. The more specialized contracts – at the top of our pyramid diagram, override the more general ones.

The Service Level Agreement for SAP Cloud Services is then further refined by the other documents referenced in the order form.

Now that you understand the contractual terms, let’s take a look at how SAP ensures that it meets its promise of 99.9% availability with its robust, proactive ITSM processes.

ITSM Process

IT Service Management (ITSM) involves all the activities that make up the lifecycle of IT services. At a high level, ITSM includes designing, building, delivering, managing and supporting IT systems and infrastructure. A business needs to have well established processes in place to ensure that its IT services run seamlessly.

In particular, a number of ITSM processes directly impact how well an IT service provider meets their SLA’s. SAP has implemented ISO standardized processes around each of these to ensure we meet customer’s expectations:

You can get further information on these ITSM process in the presentation “The Service Level Agreement and ITSM process Deck” linked later in this blog

Where to find information

SAP Cloud Platform offers full transparency regarding its contracts and certifications, its system monitoring, its root cause analysis, its releases notes and more. Let’s take a look at what is available and where to find it.

SAP Trust Center

SAP Cloud Trust Center is a public-facing website with unified and easy access to all SAP cloud trust-related content including information relevant to the SAP Cloud Platform SLAs such as Data Center information and Disaster recovery procedures, compliance documents and reports such as SOC 2 report and the SLA contracts themselves.

The SAP Cloud Platform Service Description guide

The Service Description Guide provides information about SAP Cloud Platform. The web page and guide covers information such as:

It also has Individual information for each of the cloud services:

SAP Statuspage.io page

You can view the status of the SAP Cloud Platform and its services any time on the Status Page (sapcp.statuspage.io). The status page provides information on:

Root Cause Analysis Report

Part of our continuous improvement process includes a detailed root cause analysis of major issues. You can find the documentation of this analysis on the help.sap.com website. (Access to this page requires an authorized S-User ID that belongs to the SAP Customer group)

Release Notes – SAP Cloud Platform What’s New page

When planned updates are released, the changes are detailed in our release notes, which can be accessed on the public Help Portal as part of the service documentation.

The main page of the release notes page lists changes for all SAP Cloud Platform services, with a few exceptions (such as JAM), for the current quarter. The items are sorted by date and are assigned to standard categories such as New, Changed, Enhanced, Deprecated, and Announcement. You can also access information for older items under the “All Release Notes” tab.

The page does not currently support subscriptions, but you can get notifications by subscribing to The SAP Community Wiki page that is updated every time new release notes are available

SAP Cloud Platform Operating Model

We’ve talked a lot about SAP’s responsibilities and processes, but it’s also important to note that we can’t do it alone. We depend on our customers to work with us to ensure the reliabilities of their systems. The SAP Cloud Platform Operating Model page in SAP help, details out exactly what is SAP’s responsibility vs the customers responsibility

Direction forward

SAP Cloud Platform has been growing exponentially since 2012. During this time, we’ve consistently strived for continuous improvement. As part of this effort, we have launched two internal projects with board level visibility to ensure constant availability of both the platform and infrastructure.

We also have several upcoming changes on the roadmap that will

Further Information

The Service Level Agreement and ITSM process L2 Deck provides further details on the ITSM process, our customer support process, the information sources listed above and upcoming improvements. Please check it on slideshare by clicking here. This blog will also be updated with further links as they become available, so please bookmark and check back!

SAP Trust Center (contracts and certifications)

Availability reporting and ITSM information

Источник

Что такое Service Level Agreement

Что такое «Соглашение об уровне обслуживания», известное как SLA, какие метрики чаще всего содержит и почему будет полезно как компании-провайдеру услуг, так и организации-пользователю.

Как расшифровывается SLA

SLA (Service Level Agreement) дословно переводится как «Соглашение об уровне обслуживания (оказания услуги)», то есть это договор об уровне предоставляемого сервиса между компанией-провайдером и организацией-клиентом. Основное отличие SLA от обычного договора состоит в подробно прописанном уровне доступности сервиса и времени реакции на инциденты и раскрывает следующее:

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

Важно помнить, что использование SLA выгодно обеим сторонам:

Происхождение термина SLA

Термин SLA появился из методологии ITIL (англ. IT Infrastructure Library – библиотека инфраструктуры информационных технологий), которая помогает IT-компаниям упорядочивать свои бизнес-процессы.

SLA подробнее всего описывается в стандартах ITIL и COBIT (от англ. Control Objectives for Information and Related Technologies – «Задачи управления для информационных и смежных технологий»), используя которые компании-провайдеры регламентируют большинство своих процессов и выстраивают процедуры дальнейшего контроля выполнением этих процессов и взаимодействием с клиентами.

Для чего нужно SLA

Соглашение об уровне обслуживания в числе первых помогает потребителям сервисов однозначно понимать, на каком уровне предоставляется услуга и оперировать теми же терминами, что и компания-провайдер. Например, IT-компания может составить SLA, в котором будут указаны:

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

Что включает в себя типовой SLA

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

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

При описании уровня качества сервиса, важно указать в SLA такие параметры, как:

Если речь идет об оплате сервиса, то указывается следующее:

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

Параметры, от которых зависит SLA

Параметры, из которых состоит SLA – это измеримые метрики, отвечающие за уровень качества предоставления услуги. Условно эти метрики можно называть «KPI» для SLA.

Такие метрики позволяют пользователям сервиса понимать, что именно и в каком объеме будет предоставляться. Главное условие соблюдения SLA — значения метрик должны быть известны всем заинтересованным сторонам, то есть находиться в открытом доступе, а описания метрик должны трактоваться однозначно.

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

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

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

Доступность услуги

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

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

Доступность сервиса невозможна на 100%. Значение доступности в процентах стремиться к 100% и выражается в виде количества «девяток» процента доступности. Например, доступность 99% и 99,999% может быть обозначена как «2 девятки» и «5 девяток», а доступность в 99,95% — может обозначаться как «три с половиной девятки».

Кстати, на примере доступности дата-центров учитывается только время простоя, в то время как значения остальных основных параметров заданы по умолчанию. При размещении сервера в Selectel, в стоимость входят:

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

Время реакции на инциденты

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

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

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

Оценка результата

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

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

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

SLI и SLO

SLI (Service Level Indicator) – это количественная оценка работы сервиса, которая является корреляцией между ожиданиями пользователей и действительной производительностью сервиса за указанный период времени (месяц, квартал, год).

SLI можно рассматривать в качестве индикатора пользовательского опыта, измеряя его в процентном эквиваленте, где:

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

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

SLO (Service Level Objectives) – это значение SLI, которого компания-провайдер хотела бы достичь. При установке SLO рекомендуется указывать реально достижимое значение для каждого конкретного SLI. SLO показывает, с каким качеством фактически работает сервис и/или приложение, в отличие от SLA, который используется для того, чтобы задать тот уровня доступности сервиса, на который смогут ориентироваться все пользователи.

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

Плюсы использования SLA для заказчиков и исполнителей

Вместо заключения

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

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

Источник

Настройка соглашения об уровне сервиса в SAP Solution Manager 7.1 SP 08

Сатарин Кирилл

Прочитав статью, вы узнаете, как настроить соглашение об уровне сервиса (SLA) в системе SAP Solution Manager версии 7.1 (пакет поддержки SP08). В статье приводится описание того, как расширить стандартные сроки SLA своими собственными сроками и продолжительностями, а также, преодолеть стандартную проблему «вычисления сроков и продолжительностей SLA», если статус сообщения изменяется через операции пост обработки (Post Processing Framework), а не в пользовательском интерфейсе.

Используемые материалы:

Основные англоязычные источники, которые использовались при написании этой статьи.

Ссылки в квадратных скобках [] будут указывать на один из этих источников, чтобы к ним можно было обратиться при необходимости.

Введение

Функциональность ITSM (управление сервисом в области информационных технологий, information technology service management) системы SAP Solution Manager используется для обработки обращений пользователей. Для контроля службы сервиса в системе SAP Solution Manager следует настроить «соглашение об уровне сервиса».

Основные понятия:

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

Максимальное время обработки (MPT, maximum process time) — согласованное между конечным пользователем и поставщиком услуг время (продолжительность времени) обработки сообщения на стороне поставщика услуг от его создания до подтверждения закрытия сообщения. Часто измеряется в рабочих часах поставщика услуг или рабочих часах конечного пользователя. При расчёте продолжительности обработки времени обращения на стороне поставщика услуг из полной продолжительности обработки обращения (от создания до закрытия) вычитается продолжительность нахождения обращения вне зоны ответственности поставщика услуг. Часто это сводится к вычитанию времени ответа на вопросы сотрудников поставщика услуг конечными пользователями. Но в некоторых случаях по согласованию между конечным пользователем и поставщиком услуг могут применяться другие правила расчёта.

Время первичного ответа (IRT, initial response time) — согласованное время (продолжительность времени) квалифицированного отклика поставщика услуг на обращение конечного пользователя. Первичный отклик должен иметь место не позднее определённого времени после регистрации обращения конечного пользователя. Часто он измеряется только в рабочих часах поставщика услуг или рабочих часах конечного пользователя.

Соглашение об уровне сервиса — с точки зрения системы SAP Solution Manager — представляет собой набор двух плановых продолжительностей: продолжительность первичного ответа (IRT), и максимальное время обработки (MPT). Каждая из этих продолжительностей может иметь различное значение для разных приоритетов обращений и других атрибутов обращений (например, для различных категорий).

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

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

Подробное описание настройки SLA дано в документации SAP, в документе SLA Management [2]. В данной статье будет дано краткое описание настройки расчёта продолжительностей и видов сроков для целей учёта в соглашении об уровне сервиса.

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

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

Вид срока

Таблица 1. Стандартные настройки

В таблице 1 приведены стандартные настройки для инцидентов (вид операции SMIN). В ноте 1674375 также представлены стандартные настройки расчёта продолжительностей и для других операций. Рассмотрим отдельно назначение каждого столбца таблицы 1:

Статусная схема — указывается статусная схема, для которой выполняется расчёт продолжительности или срока. Для каждого вида операции в настройках определена одна статусная схема. Для нескольких видов операции может быть задана одна и та же статусная схема. В нашем случае статусная схема указывает на вид операции SMIN.

Пользовательский статус — пользовательский статус указанной статусной схемы, для которого выполняется расчёт. Т.е. продолжительность нахождения сообщения в данном пользовательском статусе будет добавлена к указанной в Таблице 1 продолжительности. Если этот статус устанавливается, то в момент установки заполняется соответствующий реквизит в столбце «Вид срока».

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

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

Продолжительность — в поле указывается продолжительность, к которой прибавляется время пребывания в статусе, который указан в колонке «Пользовательский статус».

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

Рисунок 1. Настройка ссылочного объекта для расчёта продолжительности

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

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

Вид срока рассчитывается в соответствии со своими собственными настройками в профиле сроков. Например, для вида срока, в котором рассчитывается плановая дата первой реакции, необходимо указать соответствующее правило расчёта (см. Рисунок 2). Настройка правил расчёта сроков не описана в настоящей статье.

Рисунок 2. Настройка вида срока

Вид срока (см. Рисунок 2) рассчитывается на основе правила «первой реакции». При отображении срока указывается день недели, дата, и время, часовой пояс не указывается.

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

Как работают стандартные настройки

Разберём стандартные настройки (в соответствии с нотой 1674375) на конкретных примерах:

1. Расчёт общей продолжительности обработки сообщения (в рабочих часах)

Ниже, в Таблице 2 представлены стандартные настройки (нота 1674375), которые относятся к продолжительности SRQ_TOT_DUR (Общая продолжительность сервисной операции), представлены только строки, в которых в столбце продолжительность указано значение SRQ_TOT_DUR, а в столбце статусная схема — SMIN0001.

Вид срока

Таблица 2. Параметры расчета общей продолжительности обработки обращения

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

2. Определение времени передачи сообщения автору

Все стандартные настройки для вида срока SMIN_CUSTL (Передано клиенту) указаны в Таблице 3.

Вид срока

Таблица 3. Параметры расчета момента времени перенаправления обращения конечному пользователю

При каждом переходе сообщения через воображаемую границу между SAP и конечным пользователем в этом сообщении, в реквизите «срок SMIN_CUSTL» будет указана дата и время такого перехода. На практике, лучше усовершенствовать эту настройку и ввести разные виды сроков:

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

3. Определение времени исполнения сообщения и сдвиг планового времени решения.

Стандартные настройки для расчёта продолжительности SMIN_CU_DURA указаны в Таблице 4.

Вид срока

Если хотите прочитать статью полностью и оставить свои комментарии присоединяйтесь к sapland

Источник