SLA в SaaS-договорах – доступність, час відповіді, RTO, RPO та сервісні кредити

Від Mallbutiken · Факти перевірено 30 вересня 2026 р. · Приблизний час читання 8 хвилин

SLA робить рівень обслуговування SaaS-провайдера вимірюваним. У ньому має бути визначено, що означає доступність, як вона розраховується, як пріоритезуються інциденти, які діють часи відповіді, які цілі відновлення є релевантними та що отримує клієнт, якщо рівень обслуговування не досягнуто.

Що таке SLA у SaaS-договорі?

SLA означає Service Level Agreement (угода про рівень обслуговування) і часто є додатком до основного договору. Основний договір описує комерційні відносини, тоді як SLA деталізує вимірювані рівні якості поточної послуги.

Хороший SLA повинен бути придатним для використання як під час нормальної роботи, так і в разі виникнення проблем. Якщо сторони починають обговорювати значення «критичного збою» або «99,9 відсотка доступності» лише під час інциденту, договір занадто нечіткий.

Дивіться також основний посібник про те, що має містити SaaS-договір.

Доступність – відсоток це лише початок

Рівень доступності, наприклад 99,9 відсотка, мало що каже без правил вимірювання. Тому вкажіть:

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

Різниця між 99,9 та 99,99 відсотка може бути комерційно суттєвою. Тому вимоги повинні базуватися на тому, наскільки критичною для бізнесу є послуга і що насправді може забезпечити технічна архітектура провайдера.

Класи інцидентів та час відповіді

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

Для кожного рівня пріоритетності SLA може вказувати час першої відповіді, цільовий час для обхідного рішення або відновлення, частоту оновлень та рівень ескалації. Будьте уважні до різниці між часом відповіді та часом вирішення. Відповідь протягом 30 хвилин автоматично не означає, що помилку буде усунено протягом 30 хвилин.

Вікна підтримки повинні відповідати діяльності

Час відповіді P1 у 30 хвилин є марним для підприємства, що працює цілодобово, якщо підтримка провайдера доступна лише в робочі дні з 09:00 до 17:00. Вкажіть, які рівні діють поза звичайним робочим часом підтримки та як повідомляється про критичні інциденти.

RTO та RPO – дві різні цілі відновлення

RTO використовується як ціль для того, як швидко послуга чи процес мають бути відновлені після перебою. RPO використовується як ціль для того, який обсяг втрати даних у минулому можна допустити в ситуації відновлення.

Їх не слід обирати ізольовано в IT-договорі. BIA (аналіз впливу на бізнес) може показати, як довго бізнес насправді може витримати перебій і яка втрата даних є прийнятною. Читайте посібник щодо Business Impact Analysis та практичний приклад BIA.

Також перевірте, що провайдер має на увазі під своїми значеннями. RTO — це ціль, гарантія чи лише внутрішній проектний принцип? Чи стосується RPO усіх типів даних? Як часто тестується відновлення?

Сервісні кредити – компенсація чи єдина санкція?

Сервісні кредити можуть створити автоматичний фінансовий стимул, коли рівень обслуговування не дотримано. Наприклад, шкала може надавати більший кредит, чим довше послуга перебуває нижче цільового рівня.

Але перевірте, чи не вказано в договорі, що сервісний кредит є єдиною санкцією для клієнта. У разі серйозних або повторюваних недоліків клієнту можуть знадобитися інші права, наприклад, право на план дій, спеціальна ескалація або розірвання договору. Узгодьте SLA з обмеженням відповідальності та правилами розірвання основного договору.

Планове обслуговування та інші виключення

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

Також будьте обережні з виключеннями для сторонніх сервісів. Якщо провайдер сам обрав критичного постачальника хмарних послуг або інфраструктури, договір має чітко визначати, як ця залежність впливає на SLA та відповідальність.

Контрольний список для корисного SLA

• Чи чітко визначена послуга, що вимірюється?
• Чи є однозначна формула для доступності?
• Чи обмежене планове обслуговування?
• Чи пов'язані рівні інцидентів із впливом на бізнес?
• Чи розрізняє договір відповідь, обхідне рішення та вирішення?
• Чи працює підтримка протягом критичних для вас годин роботи?
• Чи пов'язані RTO/RPO з реальними потребами в безперервності?
• Чи є вимоги щодо оновлення статусу під час інцидентів P1?
• Чи є чіткими сервісні кредити та інші санкції?
• Чи є право на дії у разі повторних порушень SLA?

Вам потрібен основний договір та SLA в одній структурі?

SaaS-договір від Mallbutiken містить основний договір та шість додатків, серед іншого, для специфікації послуг, SLA, PUB/GDPR, безпеки, виходу та ціни. Word та PDF. Ціна в магазині: 149 крон.

Переглянути SaaS-договір

Поширені запитання

Чи є 99,9 відсотка завжди хорошим SLA?

Ні. Правильний рівень залежить від критичності послуги, методу вимірювання, виключень та вартості вищої надмірності. Відсоток має розглядатися в контексті.

Чи є RTO тим самим, що й SLA-доступність?

Ні. Доступність зазвичай вимірює роботу протягом періоду. RTO стосується цілі відновлення після перебою.

Чи має сервісний кредит бути єдиною санкцією?

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