Чтобы составить SLA на ИТ-обслуживание, нужно связать четыре вещи: границы услуги, измеримые цели, возможности исполнителей и правила проверки результата. Фраза «поддержка по запросу» не отвечает, когда начнут работу, что восстановят и кто подтвердит готовность сервиса.
Для заказчика
Проверить предложение подрядчика, убрать разные трактовки сроков и определить критерии приёмки.
Для ИТ-команды
Превратить договорённости в каталог услуг, счётчики Service Desk, эскалации и понятный отчёт.
Ниже — рабочая последовательность и формы для подготовки своего документа. Числа в примерах учебные; они не являются тарифами или обязательствами AVG IT. Если нужно сначала разобраться в терминах, начните со сравнения SLA, OLA и SLR.
1. Опишите сервисы, а не только список оборудования
«Обслуживаем пять серверов» не определяет, за какой результат отвечает исполнитель. Пользователь работает с почтой, документами, 1С и файлами. Для каждого сервиса запишите владельца, рабочее окно, пользователей и зависимости.
| Сервис | Пример границ | Что уточнить отдельно |
|---|---|---|
| Рабочие места | Поддерживаемые ОС, приложения, подключение к корпоративным ресурсам | Закупки, ремонт оборудования, личные устройства и переезды |
| Сервис 1С | Платформа, СУБД, инфраструктура и согласованные операции | Изменение конфигурации, внешние компоненты и ответственность разработчика |
| Облачная среда | Виртуальные ресурсы и их согласованные параметры | Гостевая ОС, приложение, лицензии, копии и пользовательская поддержка |
Это примеры разграничения, а не готовый состав пакета услуг. Приложите актуальный перечень объектов, площадок и поддерживаемых версий. Для изменений перечня определите порядок согласования и дату вступления в силу.
2. Соберите структуру SLA
| Раздел | Что зафиксировать |
|---|---|
| Услуга и границы | Какие сервисы входят, что исключено, какие есть зависимости |
| Календарь | Часы поддержки, доступность сервиса, часовой пояс и праздники |
| Обращения | Каналы, обязательные сведения, регистрация и аварийный маршрут |
| Приоритеты и цели | Критерии влияния/срочности, отдельные цели реакции и восстановления |
| Правила измерения | Старт, паузы, остановка, повторное открытие и изменение приоритета |
| Ответственность | Роли заказчика, исполнителя, внутренних групп и внешних поставщиков |
| Эскалации и связь | Кто подключается, когда и как информируют заказчика |
| Отчёт и отклонения | Период, состав событий, проверка нарушений и согласованные последствия |
| Изменение соглашения | Версии, утверждение, пересмотр при изменении бизнеса или архитектуры |
Этот каркас помогает проверить полноту договорённостей. Состав SLA, ответственность и метрики рассмотрены также в обзоре IBM. Конкретные условия должны соответствовать основному договору и фактической модели обслуживания.
3. Разведите рабочие часы и доступность сервиса
Когда нужен сервис
Например, сотрудникам филиалов требуется доступ к системе в согласованные часы. Запишите календарь потребления услуги и критичные периоды.
Когда работает поддержка
Отдельно определите приём обращений, работу специалистов, мониторинг и действия по тревоге ночью или в выходные.
- Укажите часовой пояс и способ учёта праздников.
- Разделите плановое обслуживание и аварийные действия.
- Опишите согласование и уведомление об окнах работ.
- Уточните, какие цели считают календарными, а какие рабочими минутами.
Настройка должна повторять документ. Например, в Jira Service Management календарь SLA задаёт рабочие часы и исключения. Наличие почтового ящика для заявок круглосуточно само по себе не означает круглосуточное выполнение работ.
4. Определите приоритеты по влиянию и срочности
Запишите наблюдаемые признаки, по которым обращению назначают приоритет. Названия P1–P4 удобны только тогда, когда участники одинаково понимают их смысл. Для запросов доступа и плановых изменений нужны свои маршруты и цели.
Влияние
- Какие операции остановлены?
- Сколько подразделений затронуто?
- Есть ли согласованный обходной путь?
Срочность
- Когда начинается ущерб для процесса?
- Есть ли критичное событие или срок?
- Как долго возможна работа в обход?
Согласуйте, кто назначает и пересматривает приоритет, как уведомляет стороны и сохраняет историю. Приоритет сотрудника по должности и приоритет остановившегося бизнес-процесса не должны подменять друг друга.
5. Задайте отдельные цели реакции и восстановления
Учебная цель реакции: 15 минут
Уполномоченный специалист принял обращение в работу и начал согласованное действие. Автоматическое подтверждение регистрации измеряется отдельно.
Учебная цель восстановления: 120 минут
Согласованная операция снова выполняется, результат подтверждён. Возможность временного обходного решения определена заранее.
Числа приведены для пояснения расчёта. Перед принятием таких целей нужно проверить резервные ресурсы, доступы, копии, участие других команд и время контрольной операции. Цель устранения корневой причины может быть отдельной: восстановление работы и завершение всех последующих изменений происходят не всегда одновременно.
Кто доступен в нужное окно? Есть ли полномочия и безопасный доступ? Сколько длится испытанное восстановление? Как быстро подключается поставщик приложения? Если ответов нет, короткое число в SLA пока не подкреплено процессом.
6. Для каждого счётчика опишите старт, паузу и остановку
Согласуйте точные события: получение сообщения выбранным каналом, регистрация, принятие в работу, восстановление и подтверждение результата. Если регистрация задержалась, это должно оставаться видно в хронологии.
| Учебное событие | Время | Значение для расчёта |
|---|---|---|
| Операция стала недоступна | 10:00 | Начало наблюдаемого простоя |
| Обращение зарегистрировано | 10:05 | Условный согласованный старт двух счётчиков поддержки |
| Специалист принял работу | 10:12 | Реакция — 7 минут после регистрации |
| Техническое восстановление выполнено | 11:20 | Началась проверка рабочей операции |
| Согласованный результат подтверждён | 11:30 | Восстановление по условиям примера — 85 минут после регистрации |
Всё происходит внутри рабочего окна, без пауз. Цели 15/120 минут выполнены, но наблюдаемый простой бизнеса составил 90 минут. Это разные показатели: пять минут до регистрации не должны исчезнуть из оценки влияния.
Для пауз определите основание, уведомление, необходимые сведения и событие возобновления. Внутренняя передача задачи не должна незаметно обнулять общий срок. Правила повторного открытия и изменения приоритета также включите в документ. Пример настройки подобных событий — условия SLA в Jira Service Management.
7. Сделайте паспорт каждого показателя
Для доступности, времени реакции и восстановления нужны разные определения. На каждый показатель заполните одну карточку: объект, цель, окно, источник, формула, исключения и владелец проверки.
- Что проверяем: порт сервера, вход в приложение или выполнение контрольного действия.
- Где измеряем: серверная сторона, пользовательская площадка или согласованная внешняя точка.
- Как учитываем сбой: недоступность полностью, деградацию части пользователей, ошибки и отсутствие данных мониторинга.
- Из чего считаем: временные интервалы либо события; одинаковый знаменатель для сравниваемых периодов.
- Кто подтверждает: источник фактов, доступ заказчика к отчёту и порядок разбора расхождений.
Разделять определение показателя и способ его получения рекомендует Google SRE Workbook. Например, «успешная отгрузка» и «ответил сервер» описывают разные результаты, даже если обе проверки технически доступны.
8. Распишите обязанности сторон и зависимых поставщиков
Исполнитель
- Поддерживаемые сервисы и состав действий.
- Ответственный, замещение и эскалация.
- Сохранение истории, уведомления и отчёт.
- Порядок безопасных изменений и проверки результата.
Заказчик
- Контакт и уполномоченный принимающий сотрудник.
- Согласованные сведения и доступы.
- Решения по рисковым действиям и окнам работ.
- Уведомление об изменениях инфраструктуры и приложений.
Внутренние правила команд должны поддерживать общую цель. Для внешних провайдеров проверьте часы поддержки, сроки подключения, доступ и границы ответственности. Их условия нельзя считать автоматически равными обещанию вашего поставщика.
Для облачной среды отдельно назовите исполнителей по виртуальной машине, гостевой ОС, приложению и резервным копиям. Укажите, кто может запустить восстановление и где доступны ключи и лицензии после отказа рабочей площадки.
9. Подключайте помощь до нарушения срока
Зафиксировать влияние, приоритет и следующий контакт.
Увидеть задержку, зависимость или недостаток полномочий.
Привлечь старшего специалиста, владельца сервиса или внешнего поставщика.
Обновить статус заказчику и продолжить вести общий срок.
В Service Desk настройте предупреждения, назначение групп и календари по согласованной модели. Например, GLPI поддерживает уровни SLA/OLA, календари и эскалации. Но название поля продукта ещё не подтверждает совпадение с вашим определением реакции: это проверяют на тестовых обращениях.
10. Согласуйте отчёт, который нельзя улучшить одним закрытием заявок
- Показывайте реакцию и восстановление отдельно, с количеством учтённых событий.
- Сохраняйте просроченные незакрытые обращения, историю пауз и пересмотра приоритета.
- Разделяйте сервисы и приоритеты: общий процент может скрыть остановку критичной операции.
- Добавляйте разбор повторений, причины отклонений и владельца исправлений.
- Проверяйте результаты вместе с заказчиком и фиксируйте спорные события.
В период попали 100 событий, срок которых по выбранной цели уже наступил. В 97 случаях цель выполнена вовремя; в трёх — нет, включая ещё не завершённые работы. По этому определению выполнение — 97 / 100 × 100% = 97%. События со сроком за пределами периода показывают отдельно. Правило отбора должно быть одинаковым от отчёта к отчёту.
Такой показатель не равен доступности сервиса и не описывает все аспекты качества. Правила для отмен, объединённых и повторно открытых обращений нужно определить до расчёта, а не после получения неудобного процента.
11. Определите действия при отклонениях
Опишите, как фиксируют нарушение, какие факты подтверждают расчёт, кто рассматривает расхождения и какие действия следуют дальше. При повторениях нужен план улучшений с ответственным и сроком проверки.
Если стороны предусматривают компенсации или иные последствия, согласуйте базу расчёта, пределы, исключения, порядок обращения и связь с основным договором. Универсального размера компенсации из слова SLA не следует. Пример того, как конкретный поставщик отделяет измерение, исключения и процедуру обращения, — публичное SLA Atlassian; его коммерческие условия относятся только к описанным там услугам.
12. Проверьте проект SLA до принятия обязательств
| Контрольный случай | Что должно совпасть с документом |
|---|---|
| Обычное обращение внутри графика | Приоритет, старт, цели и ответственный |
| Обращение на границе рабочего дня | Часовой пояс, выходные и итоговый срок |
| Разрешённая пауза и возобновление | Основание, история и пересчёт нужного счётчика |
| Передача другой группе | Сохранение общей цели и владельца координации |
| Повторное открытие | Предсказуемое правило, которое не скрывает прошлый результат |
| Нарушение цели | Уведомление, эскалация и попадание в отчёт |
Проведите тестовые обращения и, где требуется, испытание восстановления. Если настройка системы не повторяет документ, исправьте одну из сторон до запуска. Затем укажите версию SLA, дату действия, владельца пересмотра и условия изменения. Не переносите автоматически старые цели на новое приложение, филиал или схему размещения.
Материалы для подготовки своего SLA
Структура проекта SLA
Разделы и поля, которые нужно согласовать под свой состав услуг.
Скачать структуру · TXTПаспорт показателей
Таблица целей, календарей, событий, источников и ответственных.
Скачать паспорт · TXTПротокол проверки
Контрольные случаи для Service Desk и приёмки процесса обслуживания.
Скачать протокол · TXTФормы содержат поля для заполнения, а не обязательные сроки. Они помогают подготовить проект и проверить его; итоговые условия утверждают стороны.
Свяжем SLA с реальным обслуживанием и ресурсами
ИТ-аутсорсинг: от перечня работ к проверяемому результату
- Описать сервисы и границы сопровождения.
- Разобрать приоритеты и маршрут обращения.
- Согласовать измерение, эскалации и отчёт.
- Проверить возможности команды и восстановления.
Обсудим исходные требования и состав обслуживания под вашу инфраструктуру.
Обсудить SLA обслуживанияОблачные ресурсы: учесть зависимости приложения
- Оценить ресурсы и критичные операции.
- Разделить доступность среды и приложения.
- Определить резервные копии и путь возврата.
- Согласовать взаимодействие исполнителей.
Конфигурация, режим поддержки и условия аренды подтверждаются по задаче.
Обсудить облачную средуВопросы о подготовке SLA
Можно ли взять готовый шаблон и поменять название компании?
Он поможет со структурой, но границы услуг, цели, календари, зависимости и измерение нужно проверить заново. Чужие сроки без исполнителей и ресурсов не создают работающий процесс.
Нужны ли одинаковые сроки для всех заявок?
Нет. Инцидент, запрос доступа и изменение системы решают разные задачи. Цели задают по согласованному сервису, влиянию, срочности и маршруту работ.
Можно ли считать ответ робота реакцией?
В документе нужно назвать конкретное событие. Автоматическое подтверждение регистрации можно измерять отдельно; оно не доказывает, что специалист начал работу.
Что делать, если подрядчик ждёт информацию от заказчика?
Применять заранее согласованное правило паузы, уведомления и возобновления. Сохранять историю и отдельно учитывать фактический простой сервиса.
Достаточно ли настроить SLA в GLPI или Jira?
Настройка реализует выбранные правила, но не определяет вместо сторон состав услуги и критерии результата. Календарь, события и отчёт проверяют на контрольных случаях.
Как часто пересматривать соглашение?
Назначьте периодический разбор и события для внепланового пересмотра: новая система, филиал, нагрузка, критичность или состав поставщиков. Сохраняйте версии и дату начала новых условий.