service level requirement, SLR

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

Частая ошибка — воспринимать требование к уровню услуг как уже согласованный уровень услуги или как SLA. Требование к уровню услуг выражает потребность заказчика и может быть завышенным, неполным или противоречивым; согласованные целевые значения уровня услуги появляются только после переговоров и оценки реализуемости, стоимости и риска. Также требование к уровню услуг нередко путают с внутренними KPI команды поддержки или с техническими параметрами компонентов: например, «аптайм сервера 99,9%» сам по себе не равен требованию к уровню услуг, если не привязан к ИТ-услуге и бизнес-результату заказчика. Ещё одно заблуждение — описывать требования исключительно в терминах доступности; на практике значимы и производительность, пропускная способность, время восстановления (RTO), целевая точка восстановления (RPO), поддерживаемые часы, время реакции и разрешения, а также требования гарантии, включая конфиденциальность и целостность. Важно избегать расплывчатых формулировок вроде «быстро» или «стабильно»: они не позволяют выстроить мониторинг и измерение и отчётность и приводят к конфликтам при оценке качества услуги. Наконец, не каждое пожелание пользователя автоматически становится требованием заказчика: требование к уровню услуг относится к ожиданиям заказчика и должно быть связано с бизнес-целями, а не с индивидуальными предпочтениями.