«Быстро реагируем» и «поддерживаем серверы» можно понимать по-разному. Для бизнеса важно, когда сотрудники снова смогут работать, кто ведёт инцидент и как проверить результат. SLR, SLA и OLA помогают связать потребности компании с согласованным уровнем обслуживания и работой исполнителей.
Понятные ожидания
Какие сервисы критичны, когда они нужны и какой простой допустим.
Измеримый результат
От какого события считается время и чем подтверждается восстановление.
Ответственный за инцидент
Кто координирует специалистов и сообщает о ходе работ.
Обоснованные затраты
Какие ресурсы и режим сопровождения нужны для выбранных целей.
SLR, SLA и OLA простыми словами
| Термин | На какой вопрос отвечает | С кем обсуждают |
|---|---|---|
| SLR Service Level Requirements — требования к уровню сервиса | Что нужно бизнесу и почему это важно? | Владелец бизнес-процесса и поставщик ИТ-сервиса |
| SLA Service Level Agreement — соглашение об уровне сервиса | Какой уровень обслуживания согласован и как его измеряют? | Заказчик сервиса и его поставщик |
| OLA Operational Level Agreement — внутреннее операционное соглашение | Как внутренние команды обеспечат согласованный результат? | Подразделения внутри организации поставщика сервиса |
SLR — исходные требования, а не уже принятое обязательство. Их обсуждают с учётом возможностей, зависимостей и стоимости. SLA фиксирует согласованный результат; OLA организует взаимодействие внутренних команд. Такое разделение описано в разборе сервисных каталогов ManageEngine.
Соглашение с провайдером связи или внешним разработчиком не стоит автоматически называть OLA. В классической терминологии поддерживающее соглашение с внешним поставщиком называют Underpinning Contract, UC. Важно согласовать границы и цели зависимых услуг, независимо от названия документа.
Как связаны требования, обещания и работа команд
Бизнес объясняет, какой процесс требуется поддержать и какие последствия имеет остановка.
Стороны определяют сервис, цели, календарь, ответственность и способ измерения.
Поддержка, администраторы и специалисты приложения договариваются о передаче и выполнении работ.
Отчёт связывает обращения и показатели с возможностью пользователей работать.
Документы можно согласовывать параллельно. Перед обещанием заказчику проверяют возможности внутренних команд и внешних поставщиков. Если сервис зависит от восстановления базы, резервных ресурсов и действий разработчика, один быстрый ответ первой линии не обеспечит весь результат.
В публичных описаниях управления уровнем сервиса акцент сделан на связи потребностей, измеримых целей, ответственности и регулярной оценки. Удобнее начинать с одного понятного сервиса, чем с одинаковых сроков для всех ИТ-задач.
SLR: что бизнесу нужно сформулировать до выбора сроков
- Результат: проводить продажи в 1С, отправлять почту, оформлять отгрузки или работать с файлами.
- Рабочее окно: время, часовой пояс, выходные, праздники и особые периоды.
- Масштаб: сотрудники, филиалы, критичные операции и пиковая нагрузка.
- Последствия: что происходит при остановке и существует ли допустимый обходной процесс.
- Восстановление: какие данные и зависимости нужны, кто проверяет готовность к работе.
- Приоритет: что восстанавливать раньше при нескольких одновременных сбоях.
«В период отгрузок сотрудники склада должны оформлять документы. При недоступности системы отгрузка останавливается. Требуются согласованный порядок восстановления и ответственный за коммуникацию». Затем стороны выбирают измеримые цели и проверяют, какие ресурсы нужны для их достижения.
Круглосуточная доступность сервиса, круглосуточный мониторинг и круглосуточная работа специалистов — разные требования. Их стоит записывать отдельно: иначе компания может ожидать ночного восстановления от команды, чей согласованный график начинается утром.
Один пример: сопровождение сервиса 1С
Учебная ситуация: компания хочет восстанавливать критичную операцию отгрузки в пределах двух часов в согласованное рабочее окно. Это пример обсуждения, не условия обслуживания AVG IT. Достижимость цели проверяют по инфраструктуре, зависимостям и испытанию восстановления.
SLR бизнеса
Определены операция отгрузки, рабочее окно, последствия остановки и желаемый предел ожидания.
SLA сервиса
После проверки возможностей согласуют цель, точку начала отсчёта, критерий восстановления и порядок связи.
OLA внутренних команд
Первая линия собирает сведения; администратор проверяет среду; специалист приложения подключается по условиям эскалации.
Зависимости
Проверены доступы, копии, резервные ресурсы и условия внешних поставщиков. Назначен координатор.
| Этап условного маршрута | Проектный бюджет | Что должно быть готово |
|---|---|---|
| Регистрация и назначение владельца | 10 минут | Масштаб сбоя, контакт и ответственный |
| Первичная диагностика и выбор действия | 15 минут | Гипотеза и подключение нужных специалистов |
| Восстановление согласованным способом | 60 минут | Доступный сервис либо допустимый обходной вариант |
| Проверка рабочей операции | 20 минут | Подтверждение результата уполномоченным сотрудником |
| Резерв времени | 15 минут | Запас на задержки внутри общего предела |
В этом упрощённом последовательном маршруте 10 + 15 + 60 + 20 + 15 = 120 минут. В реальной работе задачи могут идти параллельно; отдельно проверяют критический путь и ожидания внешних сторон. Нельзя выдать каждой группе по два часа и считать, что общая цель тоже составит два часа.
Обходной вариант считается восстановлением только при заранее согласованном критерии. Сам факт запуска виртуальной машины или службы СУБД ещё не подтверждает, что сотрудник может оформить отгрузку.
Реакция, восстановление и устранение причины — разные результаты
Реакция на обращение
Обращение принято в работу, назначен ответственный, начато согласованное действие. Автоматическое письмо не следует считать полноценной реакцией без явного определения сторон.
Восстановление сервиса
Пользователи снова выполняют согласованные действия. Может применяться допустимое временное решение.
Устранение причины
Проведён анализ и выполнены изменения, снижающие вероятность повторения. Это может потребовать отдельного окна работ.
Закрытие обращения
Зафиксированы результат, подтверждение и дальнейшие действия. Правила закрытия и повторного открытия согласуются отдельно.
Поставщик может отреагировать вовремя, но восстановить сервис позже цели. Поэтому в отчёте сроки показывают раздельно. Формулировка «ответ в течение часа» сама по себе ничего не говорит о времени возвращения сервиса.
Календарь и паузы меняют смысл одинакового срока
Для каждого показателя определите часовой пояс, график, момент запуска и остановки счётчика. Отдельно согласуйте допустимые паузы и сведения, необходимые для их подтверждения. Пример реализации таких правил — календари и условия SLA в Jira Service Management.
30 минут по календарю 24×7
Обращение зарегистрировано в пятницу в 17:50. При непрерывном отсчёте цель наступает в 18:20 той же пятницы.
30 рабочих минут: пн–пт, 09–18
В том же примере остаются 10 минут пятницы и 20 минут понедельника. Цель — понедельник, 09:20, если праздников и иных исключений нет.
Статус «ожидаем ответ заказчика» может при согласованных условиях приостановить конкретный счётчик поддержки. Он не означает, что сервис стал доступен. В отчёте сохраняйте причину, начало и конец паузы, а доступность считайте по её собственным правилам.
Перевод между внутренними группами не должен незаметно перезапускать общий отсчёт. Если меняется приоритет, сохраняют историю и применённое правило, чтобы срок нельзя было «исправить» редактированием карточки задним числом.
Доступность 99,9%: сначала определите, что и когда измеряете
T — согласованное время измерения; D — учитываемая недоступность в том же окне. Формула применима к простой модели измерения по времени. Правила отказов, частичной деградации, обслуживания и исключений задаются отдельно.
Условный месяц: 30 дней, 24×7
T = 43 200 минут. При цели 99,9% расчётная доля недоступности — 43,2 минуты.
Условное рабочее окно: 22 дня по 9 часов
T = 11 880 минут. При тех же 99,9% — 11,88 минуты внутри этого окна.
Это арифметические примеры без дополнительных исключений, не предлагаемые гарантии. Одинаковый процент при разных календарях означает разные условия. Определите также проверяемое действие: доступен ли TCP-порт, открывается ли приложение или проходит контрольная бизнес-операция.
У поставщиков встречаются и другие модели, например оценка ошибок запросов по минутным интервалам. В публичном SLA Atlassian отдельно описаны покрываемые действия, расчёт, исключения и порядок обращения за компенсацией. Такой документ полезен как пример структуры; его условия не переносятся автоматически на другой сервис.
Приоритет определяют последствия и срочность
| Ситуация | Что уточнить | Как организовать работу |
|---|---|---|
| Критичная операция остановлена у всех | Потери, рабочее окно, наличие обходного пути | Координатор, нужные команды и регулярные обновления статуса |
| Работа заметно замедлилась у части сотрудников | Масштаб, конкретные действия и возможность продолжать работу | Диагностика, наблюдение и пересмотр приоритета при ухудшении |
| Нужен новый доступ или настройка | Согласование, дата потребности и зависимости | Маршрут запроса на обслуживание, а не аварийное восстановление |
| Требуется изменение системы | Риск, испытание, окно и возврат | Плановая работа с отдельными критериями приёмки |
Это пример классификации без универсальных сроков P1–P4. Их названия, цели и границы стороны выбирают под сервис. Срочность заявки директора и влияние остановки склада на всю компанию следует оценивать по согласованным критериям.
OLA и внешние поставщики: кто держит общую ответственность
У сервиса может быть несколько исполнителей: поддержка, администраторы, команда приложения, облачный оператор, провайдер связи. Заказчику нужен понятный маршрут, а не необходимость самостоятельно выяснять, между кем потерялось обращение.
- Владелец сервиса: согласует цели и отвечает за их пересмотр.
- Координатор инцидента: ведёт общую временную шкалу, подключает команды и сообщает о ходе работ.
- Внутренние группы: договариваются о входных данных, приёме задачи, эскалации и результате передачи.
- Внешние поставщики: имеют отдельные условия доступа, поддержки, восстановления и уведомлений.
- Заказчик: назначает контакты, обеспечивает согласованные доступы и подтверждает рабочий результат.
Кому передали? Какие данные приложили? Кто подтвердил приём? Кто продолжает координацию? Пока это неизвестно, передача между группами может увеличивать простой независимо от качества отдельных специалистов.
Например, SLA на доступность облачной виртуальной машины и сопровождение приложения внутри неё описывают разные границы. Без проверки состава услуги нельзя заключить, что восстановление 1С, лицензии, резервные копии и пользовательская поддержка уже включены.
Как проверять выполнение договорённостей
SLI — измеряемый показатель, SLO — его целевое значение, а SLA объединяет согласованные условия обслуживания. Например, измеренное время восстановления и согласованная цель — разные вещи. Различия этих терминов разобраны в объяснении IBM.
Источники фактов
- Время событий и история обращения.
- Мониторинг и контрольные операции.
- Журналы действий и уведомлений.
- Подтверждение готовности пользователем.
Регулярный разбор
- Выполненные и нарушенные цели.
- Причины длительных пауз и повторных сбоев.
- Сервисы, где формальная метрика расходится с опытом пользователей.
- Изменения процесса, ресурсов и соглашений.
В отчёте указывайте период, календарь, количество учтённых событий и правила исключений. «Все заявки закрыты» не подтверждает доступность сервиса, а одна средняя длительность может скрыть долгий критичный инцидент.
Из-за чего SLA остаётся только красивой цифрой
Измеряют только быстрый ответ
Добавьте отдельную оценку восстановления и готовности рабочей операции.
Нет проверенного способа восстановления
Подтвердите доступ к копиям, ресурсам, ключам и ответственным специалистам.
Внутренние сроки не складываются
Проверьте маршрут, ожидания и запас времени до обещания заказчику.
Обещают один уровень всем сервисам
Разделите критичность, графики, состав работ и требования к восстановлению.
Начните с одного сервиса: опишите требования бизнеса, проверьте реальную схему поддержки, согласуйте измерение и проведите разбор учебного инцидента. Только затем распространяйте подход на остальные услуги. Подробное составление документа — отдельная задача; здесь важна связь требований, целей и исполнения.
Две формы для обсуждения уровня обслуживания
Карточка требований SLR
Сервис, рабочее окно, критичные действия, последствия и ожидаемый результат.
Скачать карточку SLR · TXTМатрица связей SLA–OLA
Общая цель, внутренние этапы, зависимости, ответственные и источники измерений.
Скачать матрицу · TXTФормы предназначены для сбора исходных данных. Заполнение не устанавливает автоматически обязательства сторон: состав услуг и условия должны быть согласованы.
Согласуем обслуживание и ресурсы под задачи бизнеса
ИТ-аутсорсинг: понятный процесс сопровождения
- Определить критичные сервисы и рабочие окна.
- Согласовать приоритеты и маршрут обращения.
- Связать мониторинг, исполнителей и отчётность.
- Проверить восстановление и работу после сбоя.
Обсудим состав обслуживания и измеримые критерии результата.
Обсудить сопровождениеОблачные ресурсы: согласовать границы услуги
- Оценить ресурсы и зависимости приложений.
- Разделить доступность среды и поддержку сервиса.
- Определить копирование и место восстановления.
- Согласовать взаимодействие команд при инциденте.
Конфигурации, резервирование и условия предоставления подтверждаются отдельно.
Обсудить облачные ресурсыПродолжить знакомство: принципы обслуживания серверов и измерение производительности 1С.
Вопросы об SLA, OLA и SLR
Можно ли работать без трёх отдельных документов?
Информация может быть организована в одном комплекте: требования, согласованные цели и внутренние правила. Важнее сохранить их смысл, владельцев и актуальность. Количество файлов само по себе не определяет качество сервиса.
SLR уже обязывает поставщика выполнить все требования?
SLR описывает потребность заказчика. Достижимость, состав услуги и условия обсуждают до принятия обязательств. Если ресурсов недостаточно, нужно пересмотреть архитектуру, обслуживание или целевые показатели.
OLA с администратором заменяет SLA заказчика?
Нет. OLA описывает внутреннее взаимодействие, поддерживающее общий результат. Заказчику по-прежнему нужны согласованные границы сервиса, показатели и ответственность поставщика.
99,9% означает круглосуточную поддержку?
Сам процент этого не определяет. Нужны календарь измерения, состав доступного сервиса и отдельные часы работы специалистов. Одинаковая цифра может относиться к разным условиям.
Нужно ли исключать плановое обслуживание из доступности?
Это определяют согласованные правила расчёта. Если обслуживание исключено, фиксируют его окно, порядок согласования и уведомления. Исключение из метрики не отменяет влияния работ на бизнес.
Штраф или компенсация автоматически появляется при нарушении SLA?
Последствия нарушения и порядок подтверждения определяются соглашением сторон. Необходимо смотреть конкретные условия, учитываемые события и процедуру обращения. Наличие слова SLA само по себе не задаёт размер компенсации.