SLA — это модель управления сервисом
В IT-аутсорсинге недостаточно договориться, что подрядчик будет «быстро реагировать». До начала обслуживания нужно одинаково понимать, когда работает поддержка, как определяется критичность, что считается реакцией, какой результат ожидается после инцидента и кто принимает решение об эскалации.
SLA связывает эти правила в одну модель. Он применяется к согласованному контуру: конкретным объектам, системам, рабочим местам и инфраструктурным сервисам. Универсальная таблица сроков для любой компании была бы вводящей в заблуждение — требования офиса на 30 сотрудников и распределённой сети с критичными системами различаются.
Приоритет определяется влиянием на бизнес
Приоритет инцидента задаётся не должностью автора обращения и не громкостью формулировки, а сочетанием влияния и срочности.
Типовая качественная модель:
- P1 / критический — остановлен критичный процесс или недоступен ключевой сервис без приемлемого обходного пути;
- P2 / высокий — существенная деградация влияет на подразделение или объект, но временный обход возможен;
- P3 / обычный — локальная проблема пользователя, рабочего места или некритичного сервиса;
- P4 / плановый запрос — консультация, стандартное изменение, настройка или согласованная работа.
Конкретные целевые сроки фиксируются в договоре или спецификации для конкретного проекта. На публичной странице мы не публикуем единые минуты и часы, которые невозможно честно применить к любому заказчику.
Реакция и восстановление — разные показатели
Время реакции показывает, когда обращение принято в работу по согласованному процессу. Оно не означает, что в этот же момент причина уже устранена.
Целевое время восстановления или решения описывает другой результат: вернуть бизнес-функцию, восстановить сервис или выполнить согласованную задачу.
Для части инцидентов сначала возможно временное восстановление — например, перевод на резервный канал или обходной сценарий — а затем окончательное устранение причины. Это должно быть понятно из SLA, иначе одна сторона считает инцидент закрытым, а другая — только начатым.
Окно поддержки и режим 24×7
Сервис может работать в рабочее время, в расширенном окне или круглосуточно для согласованного критичного контура.
Режим 24×7 не означает, что любые пользовательские запросы или плановые изменения автоматически выполняются ночью. В SLA отдельно определяются:
- системы и объекты, для которых действует круглосуточный режим;
- какие категории инцидентов принимаются вне стандартного окна;
- кто имеет право инициировать критическую эскалацию;
- какие внешние зависимости могут ограничивать фактическое восстановление.
Границы ответственности фиксируются заранее
Часть результата находится под прямым контролем IT-подрядчика, часть требует координации, а часть зависит от заказчика или третьей стороны.
SoftTech контролирует
Операции внутри согласованного сервисного контура: Service Desk, диагностику, администрирование закреплённых систем, документацию, мониторинг и выполнение согласованных изменений.
SoftTech координирует
Ситуации, где требуется оператор связи, производитель, сервисный центр или поставщик программного обеспечения. Подрядчик может оставаться единой точкой регистрации и эскалации, но не может подменить SLA внешнего поставщика.
Заказчик и внешние стороны обеспечивают
Доступ на объект, необходимые согласования, электроснабжение, договорные отношения с внешними поставщиками, согласованный подменный фонд и выполнение решений, находящихся вне зоны контроля SoftTech.
Что влияет на достижимость SLA
На сроки восстановления могут влиять:
- доступность интернет-канала и действия оператора;
- наличие запасного оборудования;
- возможность физического доступа на объект;
- состояние инфраструктуры и известный технический долг;
- наличие резервных копий и фактическая возможность восстановления;
- лицензии и поддержка производителей;
- согласования на изменение критичной системы.
Эти зависимости лучше описывать до инцидента, а не во время аварии.
Эскалация и отчётность
В SLA полезно определить не только сроки, но и механизм управления отклонением:
- кто владеет инцидентом;
- когда подключается следующий уровень компетенции;
- когда уведомляется ответственный со стороны заказчика;
- как фиксируется внешняя зависимость;
- что происходит при риске нарушения целевого срока;
- какие показатели попадают в регулярный отчёт.
Service Desk нужен именно для того, чтобы история инцидента, приоритет, действия и результат не терялись между звонками и чатами.
Что проверить заказчику до подписания
Перед стартом обслуживания стоит получить ответы минимум на следующие вопросы:
- какие пользователи, объекты и системы входят в сервис;
- какое окно поддержки действует для каждой категории;
- как определяется приоритет;
- что именно считается началом реакции;
- чем отличается восстановление от окончательного решения;
- как работает эскалация;
- кто взаимодействует с внешними провайдерами;
- как учитываются плановые работы;
- нужен ли подменный фонд;
- какие доступы и согласования должен обеспечить заказчик;
- какие показатели и с какой периодичностью будут доступны в отчётности.
Если эти пункты остаются «понятными по умолчанию», серьёзный инцидент быстро покажет, что стороны понимали их по-разному.
Как SoftTech согласует SLA
Сначала фиксируем состав инфраструктуры, критичные бизнес-сервисы и фактические зависимости. Затем определяем окно поддержки, классы инцидентов, целевые показатели, эскалации и границы сторон.
Если состояние инфраструктуры неизвестно, перед сервисом имеет смысл начать с IT-аудита. Если задача связана со сменой текущего поставщика, используйте сценарий перехода от другого IT-подрядчика.
Для эксплуатационной глубины — Service Desk, мониторинга и ежедневных процедур — остаётся профильный ресурс Office IT.
Обсудить SLA
Опишите количество пользователей и объектов, критичные системы, желаемое окно поддержки и текущую модель обслуживания. По этим вводным можно определить, какой SLA нужен именно вашему контуру.