Коротка відповідь: SLA для IT-адміністрування має чітко розмежовувати прийняття звернення, реакцію, початок роботи, відновлення роботи сервісу та остаточне вирішення проблеми. Водночас документ повинен визначати пріоритети, години підтримки, порядок ескалації, винятки, відповідальність за третіх осіб, спосіб вимірювання та наслідки невиконання.
SLA — це не обіцянка, що технічний спеціаліст відповість якомога швидше
SLA — це вимірювана частина договору про надання послуг. У ньому має бути зазначено, на які послуги він поширюється, коли починається відлік часу, хто приймає інцидент, як визначається пріоритет і що відбувається в разі невиконання погодженого зобов’язання.
Фрази «критичні звернення обробляємо першочергово» недостатньо. Вона не визначає, яке звернення є критичним, за який час його мають оцінити та чи гарантує постачальник початок роботи, чи лише першу відповідь.
Крім того, один інцидент часто впливає на кілька взаємопов’язаних сервісів. Вхід користувача може залежати від Microsoft Entra ID, електронна пошта — від Exchange Online, віддалена робота — від міжмережевого екрана та VPN, спільні файли — від Synology DSM або QNAP QTS, а відновлення — від окремого сховища резервних копій. Тому SLA має описувати не лише швидкість роботи технічного спеціаліста, а і його роль у разі збою інтернет-з’єднання, хмарного сервісу, ліцензії або обладнання.
Прийняття, реакція та вирішення — не одне й те саме
У договорі мають бути окремі визначення щонайменше п’яти моментів.
- Прийняття звернення: служба підтримки створила заявку та зафіксувала час її надходження. Автоматичне підтвердження засвідчує, що система отримала повідомлення.
- Реакція: відповідальна особа оцінила звернення, перевірила його вплив, визначила пріоритет і повідомила про подальші дії. Якщо реакцією вважається лише автоматичне повідомлення, це має бути однозначно зазначено в договорі.
- Початок роботи: технічний спеціаліст фактично розпочав діагностику, обмеження наслідків або відновлення. Повідомлення «ми знаємо про проблему» саме по собі не обов’язково означає початок втручання.
- Відновлення сервісу: користувачі знову можуть працювати, за потреби — за допомогою тимчасового обхідного рішення.
- Вирішення: причину усунено, постійне виправлення перевірено, а заявку закрито.
Постачальник може гарантувати час реакції, але для відновлення чи вирішення зазначати лише цільовий час. Це зрозуміло, наприклад, коли доводиться чекати на відновлення хмарного сервісу або постачання запасної деталі. Однак пропозиція має чітко розрізняти зобов’язання, операційну ціль і необов’язкову попередню оцінку.
Пріоритет визначається впливом на роботу
Саме лише позначення від P1 до P4 нічого не гарантує. Для кожного рівня потрібно описати вплив, масштаб, ризик для безпеки та наявність альтернативного способу роботи.
| Пріоритет | Практичне визначення | Типовий приклад |
|---|---|---|
| P1 — критичний | Ключові процеси зупинено, інцидент поширюється або придатної альтернативи немає | недоступна основна інформаційна система, втрата зв’язку в усій філії, активний інцидент кібербезпеки |
| P2 — високий | Значна група користувачів не може працювати або її робота суттєво обмежена | не працює вхід до Microsoft 365 для всього відділу, недоступний VPN без альтернативного способу підключення |
| P3 — звичайний | Вплив обмежений або існує придатний обхідний спосіб | проблема з одним комп’ютером, повільна робота застосунку, несправний офісний принтер |
| P4 — запит | Йдеться не про несправність, а про заплановану зміну | створення облікового запису, встановлення застосунку, підготовка пристрою для нового працівника |
Договір також має визначати, хто призначає пріоритет, хто може його змінити та як вирішується незгода замовника. Несправний принтер одного працівника зазвичай не зупиняє роботу компанії. Але така сама несправність на єдиному робочому місці для друку експедиційних етикеток може зупинити відправлення та потребувати вищого пріоритету.
Без цього правила замовник може позначати кожне звернення як критичне, а постачальник — довільно переводити серйозні інциденти до нижчого пріоритету.
Години підтримки визначають, коли триває відлік часу
Формулювання «реакція протягом двох годин» є неповним, якщо не зазначено, чи йдеться про дві астрономічні години, чи про дві години в межах робочого вікна підтримки.
Умовний приклад: підтримка працює в робочі дні з 8:00 до 17:00, а замовник повідомляє про інцидент у п’ятницю о 16:30. Із двогодинного часу реакції пів години зараховується в п’ятницю, а залишок починає відраховуватися в понеділок уранці. Отже, умову щодо реакції буде виконано, якщо відповідь надійде до понеділка 9:30, за умови, що на розрахунок не впливає державне свято або окремо погоджене чергування.
Тому SLA має визначати:
- робочі дні, години та часовий пояс;
- порядок дій у державні свята;
- пріоритети, які обслуговуються поза звичайними робочими годинами;
- спосіб активації чергування;
- телефонні контакти та контакти для ескалації;
- інтервал оновлень під час критичного інциденту.
Звичайний електронний лист на сервісну адресу може не активувати чергування. Тому для P1 зазвичай потрібен спеціальний номер телефону або окрема функція в клієнтському порталі.
Обсяг послуг має відповідати реальному середовищу
Фіксовану послугу, позначену лише як «IT-адміністрування», складно контролювати. У додатку до договору мають бути перелічені всі користувачі, пристрої, локації та сервіси, що обслуговуються.
Для хмарного середовища недостатньо просто вказати Microsoft 365. Обсяг може охоплювати, наприклад, Entra ID, Exchange Online, SharePoint, OneDrive, Teams, керування ліцензіями та багатофакторну автентифікацію. Для локальної інфраструктури потрібно розмежувати адміністрування міжмережевого екрана, Wi-Fi, VPN, серверів, робочих станцій, Synology DSM або QNAP QTS і системи резервного копіювання.
Так само точно мають бути описані включені роботи:
- служба підтримки та дистанційна допомога;
- моніторинг і оцінювання попереджень;
- оновлення операційних систем і керованих застосунків;
- керування обліковими записами користувачів і правами доступу;
- контроль завдань резервного копіювання;
- тестування відновлення;
- виїзди та робота на місці;
- ведення документації та обліку доступів.
Міграції, масштабні проєктні зміни, ліцензії, обладнання або криміналістичне розслідування інциденту безпеки можуть оплачуватися окремо. Проте в договорі має бути зазначено, де закінчується обсяг фіксованої оплати, як погоджуються додаткові роботи та за яким прайс-листом вони оплачуються.
Якщо вам потрібно визначити обсяг послуг відповідно до конкретної кількості користувачів, пристроїв і філій, ми розробимо для вас IT-адміністрування з урахуванням реального середовища, а не на основі універсального пакета.
Виняток не звільняє постачальника від відповідальності за комунікацію
SLA може містити винятки для ситуацій, які постачальник не контролює безпосередньо. До них можуть належати збій у постачальника інтернет-послуг, несправність хмарної платформи, втручання іншої сервісної компанії, очікування запасної деталі або відсутність доступу, необхідного для діагностики.
Ризикованим є загальне формулювання «обставини поза контролем постачальника». Без додаткових правил воно може охопити майже кожен складніший інцидент.
Для кожної залежності від третьої сторони має бути зрозуміло:
- хто створює сервісне звернення до оператора, виробника або дистриб’ютора;
- хто надає журнали подій, серійні номери та інші технічні матеріали;
- чи призупиняється відлік часу SLA;
- з якого зафіксованого моменту обчислюється призупинення;
- які умови мають бути виконані для поновлення відліку;
- як часто замовник отримуватиме оновлення;
- чи шукає постачальник тимчасове рішення.
IT-адміністратор не може відремонтувати мережу оператора чи інфраструктуру Microsoft. Проте він може перевірити, чи проблема справді не виникла в корпоративній мережі, відкрити звернення до оператора, надати діагностичні дані та координувати подальші дії. Ця відповідальність має залишатися в договорі навіть тоді, коли час фактичного ремонту не зараховується до SLA.
Практичний порядок дій у разі повної втрати підключення також описує кризовий контрольний список на випадок несправності корпоративного інтернету.
Доступність сервісу — не те саме, що доступність підтримки
Підтримка 24/7 визначає, коли можна повідомити про інцидент і коли команда готова розпочати роботу над ним. Відсоткова доступність натомість показує, протягом якої частини контрольованого періоду конкретний сервіс працював відповідно до погодженого способу вимірювання.
Договір має визначати:
- який сервіс охоплює показник доступності;
- звідки вимірюється працездатність;
- тривалість оцінюваного періоду;
- що вважається недоступністю;
- чи віднімається час оголошеного технічного обслуговування;
- як враховується частковий збій;
- хто може перевірити результат.
Для резервних копій поряд із доступністю підтримки потрібні також RPO та RTO. RPO визначає максимально допустимий вік даних, до яких можна повернутися після інциденту. RTO встановлює цільовий час відновлення сервісу або даних. Швидка реакція служби підтримки сама по собі не визначає, наскільки актуальними будуть відновлені дані та коли компанія зможе почати з ними працювати.
Погоджене відновлення потрібно перевіряти на практиці. Сам по собі зелений статус завдання резервного копіювання не підтверджує, що базу даних можна відкрити, віртуальний сервер — підключити, а потрібну папку — відновити. Докладні відомості наведено в інструкції щодо тестування відновлення резервної копії та його документування.
Призупинення відліку часу має відбуватися за правилами
Постачальнику може знадобитися додаткова інформація, доступ до системи або рішення замовника. SLA може дозволяти призупинення відліку часу в такій ситуації, але просто змінити статус заявки на «очікуємо» не повинно бути достатньо.
Для кожного призупинення потрібно зафіксувати:
- чого саме бракує;
- хто має виконати наступну дію;
- коли було надіслано запит на взаємодію;
- коли замовника було повідомлено;
- коли необхідну допомогу було надано;
- коли відлік часу поновився.
Нечіткий запит на кшталт «надішліть більше інформації» не є належною підставою для призупинення на кілька днів. Технічний спеціаліст має вказати, чи потрібні йому, наприклад, час виникнення помилки, ім’я користувача, знімок повідомлення, віддалений доступ або погодження простою.
Ескалація має працювати навіть за відсутності конкретного спеціаліста
SLA не повинен залежати від особистого номера телефону одного адміністратора. Потрібні сервісний канал, взаємозамінність працівників і чіткий порядок ескалації.
У разі критичного інциденту потрібно знати:
- куди повідомити про інцидент;
- хто підтверджує пріоритет;
- коли долучається старший технічний спеціаліст або керівник підтримки;
- хто спілкується з керівництвом замовника;
- з яким інтервалом надходять оновлення;
- хто ухвалює рішення щодо тимчасового рішення або запланованого простою.
Ескалація — це не просто пересилання заявки іншій людині. Вона має підвищити рівень керування інцидентом, залучити потрібних фахівців і забезпечити регулярну комунікацію.
Без вимірювання оцінити виконання SLA неможливо
Джерелом даних для оцінювання має бути система заявок або інший заздалегідь визначений журнал, у якому можна згодом перевірити часові позначки.
Для кожного звернення потрібно зафіксувати:
- прийняття;
- першу кваліфіковану реакцію;
- початок роботи;
- відновлення роботи;
- остаточне вирішення;
- пріоритет і його можливі зміни;
- призупинення відліку часу та його причину;
- комунікацію з третьою стороною;
- згоду замовника із закриттям або спосіб автоматичного закриття.
Щомісячний звіт має окремо показувати виконання за кожним пріоритетом і типом зобов’язання. Один загальний середній показник може приховати прострочений критичний інцидент серед десятків швидко закритих дрібних звернень.
Перед підписанням попросіть надати анонімізований зразок звіту. Перевірте, чи містить він дані, які використовуються в договорі для розрахунку SLA, і чи можна встановити причину кожного винятку.
Постійний моніторинг інфраструктури може виявити частину інцидентів ще до звернення користувача. Однак має бути зрозуміло, що саме контролює моніторинг і чи створює попередження заявку автоматично.
Наслідки невиконання мають бути зазначені в договорі
SLA має описувати порядок подання претензії та спосіб оцінювання спірного інциденту. Він може передбачати сервісний кредит, знижку, коригувальні заходи або можливість припинити співпрацю в разі повторного невиконання.
Важливо визначити:
- хто може заявити про невиконання;
- у який строк потрібно подати претензію;
- які записи беруться за основу;
- як розраховується можлива компенсація;
- чи має компенсація місячний ліміт;
- що вважається повторним порушенням;
- як після припинення послуги передаватимуться доступи, документація та дані.
Компенсація сама по собі не відновить непрацездатний сервіс. Проте вона змушує обидві сторони точно визначити, який параметр є обов’язковим і як підтверджується його виконання.
Контрольна таблиця для порівняння пропозицій
У середні стовпці перенесіть точне формулювання з обох пропозицій. Порожнє місце або усну обіцянку позначте як невизначений пункт.
| Контрольний пункт | Пропозиція A | Пропозиція B | Що має бути зазначено прямо |
|---|---|---|---|
| Обсяг | ___ | ___ | пристрої, користувачі, локації та сервіси |
| Прийняття заявки | ___ | ___ | дозволені канали та визначальна часова позначка |
| Реакція | ___ | ___ | конкретна дія та строк відповідно до пріоритету |
| Початок роботи | ___ | ___ | окреме визначення та спосіб вимірювання |
| Відновлення та вирішення | ___ | ___ | зобов’язання, операційна ціль або оцінка |
| Пріоритети | ___ | ___ | вплив, масштаб, безпека й альтернативний спосіб роботи |
| Години підтримки | ___ | ___ | дні, години, свята та часовий пояс |
| Чергування | ___ | ___ | спосіб активації та охоплені пріоритети |
| Ескалація | ___ | ___ | контакти, послідовність та інтервал оновлень |
| Винятки | ___ | ___ | конкретний і зрозумілий перелік |
| Призупинення часу | ___ | ___ | причини, початок, завершення та необхідна взаємодія |
| Треті сторони | ___ | ___ | хто комунікує та які подальші дії забезпечує |
| Резервні копії | ___ | ___ | обсяг, RPO, RTO та тест відновлення |
| Звітність | ___ | ___ | джерело даних, періодичність і зміст |
| Наслідки невиконання | ___ | ___ | претензія, виправлення та можлива компенсація |
| Припинення співпраці | ___ | ___ | передання доступів, документації та даних |
Що слід додати перед підписанням
Якісний SLA дає змогу двом людям дійти однакового висновку щодо тієї самої заявки: визначити пріоритет, початок і завершення вимірювання, тривалість обґрунтованого призупинення та факт виконання зобов’язання.
Тому перед підписанням спробуйте оцінити за договором три власні ситуації:
- інтернет не працює в усій філії;
- один користувач не може увійти до системи;
- компанії потрібно запланувати створення облікового запису для нового працівника.
Якщо для будь-якої ситуації неможливо визначити пріоритет, перебіг часу, відповідальну особу та спосіб ескалації, SLA потрібно доповнити. Неясності мають бути врегульовані в договорі або додатку до нього, а не лише в електронному листі менеджера з продажу.
Поширені запитання
Час реакції — це те саме, що час вирішення?
Ні. Реакція — це кваліфіковане прийняття та оцінювання звернення. Початок роботи означає перше фактичне втручання, відновлення повертає сервіс до придатного для використання стану, а вирішення є постійним перевіреним виправленням. Кожен момент повинен мати власне визначення.
Чи потрібна малій компанії підтримка 24/7?
Не обов’язково. Це залежить від режиму роботи компанії, важливості систем і наслідків нічного збою або збою у вихідні. Для частини компаній доцільною є підтримка в робочий час із чергуванням лише для критичних інцидентів.
Що робити, якщо проблему спричинив Microsoft 365 або постачальник інтернет-послуг?
Адміністратор не може гарантувати строк ремонту чужої інфраструктури. Однак SLA може вимагати проведення діагностики, відкриття звернення до третьої сторони, передання журналів подій, пошуку альтернативного рішення та регулярного інформування замовника.
Чи входить резервне копіювання до IT-адміністрування автоматично?
Ні. Потрібно прямо зазначити, які дані резервуються, куди, як часто, протягом якого часу зберігаються копії та хто перевіряє результати завдань. Окремо мають бути погоджені тести відновлення, RPO та RTO.
Як розпізнати якісний SLA до підписання?
Для одного й того самого інциденту замовник і постачальник мають визначити однаковий пріоритет, момент початку вимірювання, години підтримки, відповідальність і спосіб ескалації. Якщо результат залежить від усного пояснення менеджера з продажу, текст іще недостатньо точний.
Де нас знайти
ITHOPE — компанія з Брно, Чехія: ми робимо відновлення даних з дисків, RAID і NAS, сервіс ПК та ноутбуків та IT для бізнесу, усе у власній лабораторії за адресою Viniční 3587/216, 615 00 Brno.
Телефон +420 775 556 063 (цілодобово). Пристрій можна привезти особисто або надіслати курʼєром (Zásilkovna, PPL).