# Бесплатная экспертная база знаний по управлению ИТ

Никакого пересказа ITIL, COBIT, ISO 20000, PRINCE2, TOGAF и прочего. Только сведения от консультантов и тренеров Cleverics. Включает ответы на **несколько тысяч вопросов** из **сотен источников**, а также детальный глоссарий с примерами, объяснениями и нюансами

# Требование к уровню услуг

Требование [заказчика](https://cleverics.ru/digital/kb-glossary/customer/) к аспекту [ИТ-услуги](https://cleverics.ru/digital/kb-glossary/it-service/). [SLR](https://cleverics.ru/digital/kb-glossary/service-level-requirement/) основаны на [бизнес-целях](https://cleverics.ru/digital/kb-glossary/business-objective/) и используются для согласования согласованных целевых значений [уровня услуги](https://cleverics.ru/digital/kb-glossary/service-level/).

Синонимы: SLR

## Оригинальный английский термин

service level requirement, SLR

## Подробности

[Требование к уровню услуг](https://cleverics.ru/digital/kb-glossary/service-level-requirement/) описывает, какого уровня [услуги](https://cleverics.ru/digital/kb-glossary/service/) ожидает заказчик от конкретной ИТ-услуги по измеримым аспектам, важным для достижения бизнес-целей. По сути, это исходная позиция заказчика для обсуждения: какие значения [метрик](https://cleverics.ru/digital/kb-glossary/metric/) нужны, чтобы [результат](https://cleverics.ru/digital/kb-glossary/outcome/) был достигнут, и как это соотносится со [спросом](https://cleverics.ru/digital/kb-glossary/demand/), [риском](https://cleverics.ru/digital/kb-glossary/risk/) и [затратами](https://cleverics.ru/digital/kb-glossary/cost/). Такие требования формируются на этапе [проектирования](https://cleverics.ru/digital/kb-glossary/design/) или существенного [изменения](https://cleverics.ru/digital/kb-glossary/change/) ИТ-услуги и затем используются как основа для согласования целевых значений уровня услуги, которые попадут в [соглашение об уровне услуг](https://cleverics.ru/digital/kb-glossary/service-level-agreement/) ([SLA](https://cleverics.ru/digital/kb-glossary/service-level-agreement/)) или другие договорённости. На [практике](https://cleverics.ru/digital/kb-glossary/practice/) требование к уровню услуг помогает связать язык [бизнеса](https://cleverics.ru/digital/kb-glossary/business/) и язык [управления услугами](https://cleverics.ru/digital/kb-glossary/service-management/): переводит ожидания заказчика в конкретные показатели, по которым можно организовать [мониторинг](https://cleverics.ru/digital/kb-glossary/monitoring/), [измерение и отчётность](https://cleverics.ru/digital/kb-glossary/measurement-and-reporting/), а также спланировать [ресурсы](https://cleverics.ru/digital/kb-glossary/resource/), поддержку и [восстановление](https://cleverics.ru/digital/kb-glossary/recovery/). При этом термин не охватывает сам факт юридического или контрактного закрепления обязательств и не является описанием того, как именно [поставщик услуги](https://cleverics.ru/digital/kb-glossary/service-provider/) будет обеспечивать достижение уровней (это относится к проектированию услуг, [управлению доступностью](https://cleverics.ru/digital/kb-glossary/availability-management-practice/), [управлению мощностями и производительностью](https://cleverics.ru/digital/kb-glossary/capacity-and-performance-management-practice/) и другим практикам).## Нюансы

Частая [ошибка](https://cleverics.ru/digital/kb-glossary/error/) — воспринимать требование к уровню услуг как уже согласованный уровень услуги или как SLA. Требование к уровню услуг выражает потребность заказчика и может быть завышенным, неполным или противоречивым; согласованные целевые значения уровня услуги появляются только после переговоров и [оценки](https://cleverics.ru/digital/kb-glossary/assessment/) реализуемости, стоимости и риска. Также требование к уровню услуг нередко путают с внутренними [KPI](https://cleverics.ru/digital/kb-glossary/key-performance-indicator/)[команды поддержки](https://cleverics.ru/digital/kb-glossary/support-team/) или с техническими параметрами [компонентов](https://cleverics.ru/digital/kb-glossary/component/): например, «аптайм [сервера](https://cleverics.ru/digital/kb-glossary/server/) 99,9%» сам по себе не равен требованию к уровню услуг, если не привязан к ИТ-услуге и бизнес-результату заказчика. Ещё одно заблуждение — описывать требования исключительно в терминах [доступности](https://cleverics.ru/digital/kb-glossary/availability/); на практике значимы и [производительность](https://cleverics.ru/digital/kb-glossary/performance/), [пропускная способность](https://cleverics.ru/digital/kb-glossary/throughput/), время восстановления ([RTO](https://cleverics.ru/digital/kb-glossary/recovery-time-objective/)), [целевая точка восстановления](https://cleverics.ru/digital/kb-glossary/recovery-point-objective/) ([RPO](https://cleverics.ru/digital/kb-glossary/recovery-point-objective/)), поддерживаемые часы, [время реакции](https://cleverics.ru/digital/kb-glossary/response-time/) и [разрешения](https://cleverics.ru/digital/kb-glossary/resolution/), а также [требования гарантии](https://cleverics.ru/digital/kb-glossary/warranty-requirements/), включая [конфиденциальность](https://cleverics.ru/digital/kb-glossary/confidentiality/) и [целостность](https://cleverics.ru/digital/kb-glossary/integrity/). Важно избегать расплывчатых формулировок вроде «быстро» или «стабильно»: они не позволяют выстроить мониторинг и измерение и отчётность и приводят к конфликтам при оценке качества услуги. Наконец, не каждое пожелание [пользователя](https://cleverics.ru/digital/kb-glossary/user/) автоматически становится требованием заказчика: требование к уровню услуг относится к ожиданиям заказчика и должно быть связано с бизнес-целями, а не с индивидуальными предпочтениями.## Примеры

- Для ИТ-услуги «корпоративная почта»: доступность 99,95% в рабочее время и время восстановления услуги (MTRS) не более 2 часов при сбое
- Для ИТ-услуги «интернет-банк»: время отклика ключевых транзакций не более 2 секунд при нагрузке до 5 000 одновременных пользователей
- Для ИТ-услуги «виртуальные рабочие места»: время предоставления нового пользователя как запрос на обслуживание — не более 8 рабочих часов
- Для ИТ-услуги «ERP»: RTO 4 часа и RPO 15 минут для критичных модулей в рамках плана восстановления после катастрофы
- Для ИТ-услуги «контакт-центр»: время реакции на крупный инцидент — 15 минут, время разрешения — 2 часа

## Рекомендуемые продукты по этой теме

- [VAP: Управление уровнем ИТ-услуг и каталогом ИТ-услуг](https://edu.cleverics.ru/vap-slm?utm_source=knowledgebase&utm_medium=article&utm_content=banner&utm_term=VAP-SLM) — Учебный курс: интенсив с тренером. Разработка и совершенствование каталога, соглашений об уровне услуг (SLA), метрик качества услуг, включая расчёт доступности услуг
- [Grab@Pizza — ИТ и основной бизнес](https://edu.cleverics.ru/grab-a-pizza?utm_source=knowledgebase&utm_medium=article&utm_content=banner&utm_term=PIZZA) — Деловая игра. SLM, BRM, управление ИТ-бюджетом, управление изменениями
- [Altevics](https://cleverics.ru/solutions/altevics?utm_source=knowledgebase&utm_medium=article&utm_content=banner&utm_term=altevics) — Современная ITSM/ESM-система