SLA в IT и аутсорсинге что это

SLA (Service Level Agreement) — соглашение об уровне сервиса между бизнесом и IT‑подрядчиком или внутренней поддержкой.

Если документ описывает уровень сервиса и измеримые метрики, а не только цену и объём работ, то это SLA, а не просто договор.

Простой пример: SLA для хостинга может обещать доступность сайта не ниже оговорённого процента и указать, за сколько часов устраняются сбои разной критичности.

Суть SLA в IT простым языком

В отличие от общего договора, SLA описывает не деньги и объём работ, а качество, скорость и доступность сервиса.

Обычный договор отвечает на вопросы «что делаем» и «за сколько». SLA добавляет «как хорошо», «как быстро» и «как это проверим». В нём появляются конкретные цели по времени реакции, времени решения, доступности систем, формату отчётности и каналам обращения.

Мини‑пример фрагмента SLA для техподдержки: «Заявки критичности P1 принимаются круглосуточно через тикет‑систему, время реакции — до 15 минут, целевое время решения — до 4 часов при условии доступа к инфраструктуре заказчика».

Ошибка считать, что договор с общими формулировками уже равен SLA. Симптом — бесконечные споры, входит ли конкретная задача в поддержку и «что такое быстро». Если в документе нет измеримых параметров сервиса, то это ещё не SLA. Что сделать сейчас: откройте текущий договор, выпишите все фразы без цифр и подумайте, как превратить их в показатели, которые можно посчитать по логам и отчётам.

Расшифровка SLA и основная идея

Service Level Agreement — это соглашение об уровне сервиса между заказчиком и тем, кто оказывает IT‑услуги: внешним подрядчиком или внутренней поддержкой.

В IT SLA используют в аутсорсинге, облачных сервисах, технической поддержке, корпоративной инфраструктуре. Документ задаёт общие правила игры: какие сервисы доступны, в какие сроки реагируют на инциденты, как измеряется качество работы.

• какие сервисы поддерживаются и для каких пользователей;
• какие каналы обращения считаются официальными;
• какие приоритеты у разных типов инцидентов;
• какие метрики и отчёты подтверждают выполнение обязательств.

Отличие SLA от обычного договора

Классический договор услуг фиксирует предмет, стоимость, сроки действия и общие обязанности сторон. SLA выступает приложением или надстройкой к такому договору и фокусируется на уровне сервиса.

В SLA появляются пункты, которых обычно нет в общем договоре: целевые показатели доступности, время реакции и решения по приоритетам, порядок эскалации, формат и периодичность отчётности.

SLA — живой документ: его пересматривают при изменении сервиса, нагрузки или бизнес‑требований. Юридический договор может оставаться прежним, а SLA обновляется версиями или допсоглашениями, чтобы отражать реальную работу.

Зачем бизнесу и IT нужен SLA

Инцидент без SLA: «сайт лежит», бизнес ждёт, подрядчик чинит «как получится». Никто не понимает, через сколько всё поднимут, что считается критичностью и можно ли требовать компенсацию за простой.

Инцидент с SLA: зафиксирован приоритет, время реакции и решения, канал эскалации. Бизнес знает, когда ждать обновления статуса, IT‑команда понимает, что чинить в первую очередь и какие ресурсы подключать.

Отсутствие SLA бьёт по обеим сторонам: заказчик теряет деньги из‑за простоя и не может доказать, что сервис оказывался плохо, исполнитель тонет в «срочно» и спорах, входит ли задача в поддержку. Ошибка считать SLA бюрократией: симптом — постоянные конфликты и реплики «думали, что будет по‑другому».

Если споры о качестве и сроках решаются по памяти и перепискам, то SLA по факту нет, даже если слово фигурирует в договоре. Что сделать сейчас: запишите три последних конфликта с IT и отметьте, решились бы они быстрее, если бы заранее были прописаны приоритеты, сроки реакции и границы ответственности.

Выгоды SLA для заказчика и исполнителя

Для заказчика SLA даёт понятные ожидания: какие услуги входят, как быстро реагируют на разные типы инцидентов, когда сервис считается недоступным и какие отчёты он увидит по итогам месяца.

Снижаются риски простоя: критичные инциденты получают приоритет, есть формальные основания требовать разбор и компенсации, если уровень сервиса не выдержан.

Для подрядчика и внутреннего IT SLA — защита от завышенных ожиданий. Появляется прозрачный приоритез заявок, предсказуемая нагрузка и аргументы, почему часть задач — проектные работы, а не «обычная поддержка».

Внутреннему IT SLA помогает отбиваться от запросов «срочно всё и сразу»: каждый инцидент попадает в понятную категорию, а бизнес видит, какие сроки реакции и решения согласованы и за что команда реально отвечает.

Типы SLA и смежные соглашения (SLA, внутренний SLA, OLA)

В IT используют несколько типов SLA. Сервисный SLA описывает уровень сервиса для конкретного продукта, клиентский — подстраивают под конкретную компанию или группу клиентов, а многоуровневый делит клиентов на уровни обслуживания с разными пакетами.

Внутренний SLA и OLA работают внутри организации. Внешний или внутренний SLA обещает бизнесу уровень сервиса, а OLA раскладывает это обещание между поддержкой, инфраструктурой и другими командами.

Ошибка — держать один универсальный SLA для всех: симптом — поток допсоглашений и ручных исключений. Если под одного клиента постоянно придумываются особые правила, базовый тип SLA выбран неверно. Что сделать сейчас: выпишите ключевые сервисы и клиентов и отметьте, где нужен отдельный SLA и внутренние OLA.

Типы SLA для сервисов и клиентов

Сервисно ориентированный SLA описывает один сервис для всех потребителей. Например, для почтового сервиса или CRM фиксируют доступность, время реакции, поддерживаемые каналы и ограничения по объёму.

Клиентский SLA фокусируется на конкретном заказчике. В нём подстраивают часы работы поддержки, состав услуг, приоритеты и формат отчётности под бизнес этой компании или сегмента.

• Отдельный SLA под сервис уместен, когда один продукт используют десятки клиентов с одинаковыми правилами.
• Клиентский или многоуровневый SLA нужен, когда разным клиентам продаются разные уровни сервиса на один и тот же продукт.

Внутренние SLA и OLA

Внутренний SLA заключают между бизнес‑подразделениями и внутренним IT. В нём бизнес фиксирует ожидания по доступности систем, срокам реакции и каналам поддержки без юридических штрафов, но с управленческой ответственностью.

OLA (Operational Level Agreement) связывает команды внутри IT. Это договорённость, как поддержка, инфраструктура, сеть, безопасность и разработка обеспечат выполнение внешнего или внутреннего SLA.

Типичная цепочка: внешний SLA с бизнесом обещает восстановление критичного сервиса за определённое время, а OLA между поддержкой и инфраструктурой делит это время на диагностику, переключение ресурсов и коммуникацию с пользователями.

SLA, KPI, SLI, SLO: как связать договор и метрики

SLA в IT фиксирует, что именно обещано клиенту: доступность сервиса, сроки реакции, время решения. KPI, SLI, SLO и OLA помогают управлять этим внутри команды, но не всегда подходят для договора.

Для кого	Пример
Заказчик ↔ подрядчик	Время реакции на критический инцидент
Команды внутри IT	Срок переключения инфраструктуры
Сотрудники и отделы	Доля заявок, решённых с первого обращения
Техкоманда	Фактическая и целевая доступность сервиса

Ошибка — переносить внутренние KPI в SLA с заказчиком. Симптом: команда оптимизирует личные показатели, а бизнес получает формальное соблюдение при росте юридических рисков и конфликтов. 

Если показатель зависит только от внутренней организации работы, то это кандидат для KPI или OLA, а не для SLA. Что сделать сейчас: выпишите все текущие метрики и пометьте, какие важны клиенту и понятны ему — только их оставьте в проекте SLA, остальные используйте как внутренние.

SLA vs KPI, SLI, SLO

SLI — это само измерение, например фактическая доступность сервиса за месяц. SLO — целевое значение этого измерения, которого стремятся придерживаться внутри команды.

SLA превращает SLO в обещание клиенту: в договор попадает формулировка про минимальный уровень доступности и допустимое время реакции на инциденты. Юридические последствия настраивают именно вокруг этих обещаний.

KPI используют для оценки работы поддержки и инфраструктуры: скорость обработки заявок, долю повторных обращений, загрузку специалистов. Эти показатели помогают выполнять SLA, но не всегда должны становиться юридическими обязательствами.

Пример связки: SLI показывает, сколько часов сервис был доступен; SLO задаёт целевой уровень; SLA обещает заказчику, что при падении ниже порога он получит компенсацию; KPI команды настраивают так, чтобы не допускать систематических провалов по этой метрике.

Что должно быть в договоре SLA

SLA для IT‑услуг — это структурированный список обязательств, а не набор общих обещаний «поддерживать и помогать». Каждый раздел должен опираться на данные: тикеты, логи, отчёты мониторинга.

• Описание услуг и сервисов.
• Границы ответственности.
• Уровни доступности и время работы сервиса и поддержки.
• Порядок обработки инцидентов.
• Роли и эскалация.
• Финансовая ответственность.

Ошибка — описывать услуги общими словами. Симптом: постоянные споры «это входило в поддержку или нет» и попытки «договориться задним числом». Если раздел нельзя проверить по логам, тикетам или отчётам мониторинга, то его нужно переписать в измеримом виде. Что сделать сейчас: возьмите текущий договор и отметьте маркером все пункты без цифр, чётких критериев или ссылок на источники данных.

Ключевые разделы SLA для IT услуг

Блок «Услуги» оформляйте списком: название сервиса, краткое описание, типовые операции. Отдельно перечислите, что не входит в поддержку: доработки, обучение, нестандартные интеграции.

В разделе «Доступность и поддержка» задайте режим работы сервисов и службы поддержки: часы, дни недели, плановые окна обслуживания. Укажите, какие обращения принимаются только в рабочее время, а какие — круглосуточно.

Раздел «Ответственность и эскалация» фиксирует, кто со стороны подрядчика отвечает за выполнение SLA, кто со стороны заказчика предоставляет доступы и информацию, как и кому эскалировать инциденты при нарушении сроков.

В блоке про финансовую ответственность опишите принципы: когда начисляются компенсации, какие события считаются исключениями, как считается факт нарушения. Конкретные ставки можно вынести в приложение, но правила расчёта должны быть однозначными и проверяемыми по данным системы.

Метрики SLA: uptime, доступность и время реакции

Метрики в SLA задают, что именно считается качественным сервисом. Для IT‑услуг обычно используют несколько базовых показателей: доступность сервиса, скорость реакции поддержки и скорость восстановления работы.

• Uptime — суммарное время, когда сервис работает без простоев.
• Availability — доля времени, когда пользователи реально могут пользоваться сервисом.
• Response time — за сколько поддержка берёт заявку в работу.
• Resolution time / MTTR — сколько занимает устранение инцидента от регистрации до закрытия.

Ошибка — включать в SLA показатели, на которые исполнитель почти не влияет. Симптом: бесконечные споры о справедливости штрафов и поиски внешних виновников. 

Если подрядчик не может управлять метрикой своими действиями, не делайте её основной. Что сделать сейчас: выпишите 3–5 метрик, по которым уже можно собрать данные за последний месяц из тикет‑системы и мониторинга, и проверьте, зависят ли они напрямую от работы исполнителя.

Доступность (uptime, availability)

Uptime показывает, сколько времени сервис технически работал без падений. Availability отражает, какую долю планового времени пользователи действительно могли пользоваться сервисом с учётом всех простоев.

В SLA для хостинга или облака обычно фиксируют доступность как процент за период, например за месяц, и отдельно описывают, какие простои не учитываются: плановые работы, аварии у внешних провайдеров, форс‑мажор.

Важно не придумывать нереалистичные проценты, а опираться на фактическую статистику и возможности инфраструктуры. Формулировки должны быть проверяемы по логам и отчётам мониторинга.

Время реакции и время решения

Response time — это время от регистрации тикета до первого ответа или начала работ. Resolution time или MTTR — время от регистрации до полного восстановления сервиса и закрытия инцидента.

Эти показатели нельзя смешивать: быстрый ответ без решения не спасает бизнес, а долгое отсутствие реакции подрывает доверие даже при быстром последующем исправлении.

В SLA время реакции и решения обычно задают отдельно для каждого приоритета инцидента. Это помогает согласовать ожидания бизнеса и выстроить работу поддержки так, чтобы критичные проблемы закрывались в первую очередь.

Приоритеты заявок и время реакции

Приоритеты задают, в каком порядке поддержка берёт заявки и какие сроки применяет. Классификация строится от влияния на бизнес, а не от громкости просьбы пользователя.

Типовая шкала приоритетов:

• P1 — остановлен ключевой процесс (продажи, производство, расчёты), есть массовый простой.
• P2 — серьёзное ухудшение работы важного сервиса, но есть обходной путь.
• P3 — локальная проблема одного пользователя или некритичная ошибка.
• P4 — запрос на доработку, консультацию, мелкое изменение.

Ошибка — ставить одинаковые сроки для всех заявок. Симптом: критические инциденты висят в очереди вместе с мелочью, бизнес теряет деньги, а команда тушит «кто громче крикнул».

Если инцидент останавливает ключевой бизнес‑процесс, то его приоритет должен быть максимальным, даже если формально заявка пришла как обычная. 

Зафиксируйте в SLA право повышать приоритет по согласованию с ответственным со стороны заказчика. Что сделать сейчас: набросайте свою таблицу приоритетов и примерные сроки реакции и решения для P1–P3, не подбирая точные числа, а опираясь на влияние на бизнес.

Классификация инцидентов и пример матрицы

Уровни приоритета удобно описывать через влияние на бизнес: массовый простой, серьёзное ухудшение, локальная проблема, запрос на изменения.

Пример матрицы приоритетов (ориентир, не стандарт):

Описание	Время решения
Полный простой критичного сервиса	часы
Сильное ухудшение работы	рабочий день
Ограничение для части пользователей	несколько дней
Запросы на изменения	по плану работ

Учет рабочего времени в SLA

В SLA важно различать рабочие и календарные часы. Одно дело — «4 часа в рабочее время», другое — «4 часа 24×7».

Формулировки вроде «в течение N рабочих часов» требуют явного описания графика: какие дни считаются рабочими, когда начинается отсчёт, как учитываются праздники и ночное время.

Для критичных инцидентов часто задают сроки в календарных часах, для некритичных — в рабочих. Это нужно явно зафиксировать, чтобы не спорить, когда именно истёк срок реакции или решения.

Как составить рабочий SLA: краткий алгоритм

SLA рождается не в одиночку. Его делают вместе: бизнес, IT и юристы. Каждый отвечает за свою часть — цели, реалистичность и формулировки.

Сначала определите, какие бизнес‑риски нужно закрыть: простой продаж, потеря данных, срыв регламентных сроков. Затем опишите услуги и инциденты, выберите ключевые метрики и приоритеты, а после этого оформите договорённости юридически.

Ошибка — писать SLA только юристами. Симптом: документ из общих юридических фраз без технических метрик и понятных сроков. Если в обсуждении SLA не участвовали люди, которые реально оказывают услуги, то документ будет нежизнеспособным. Что сделать сейчас: выпишите участников, которых нужно привлечь к разработке или пересмотру SLA — представителя бизнеса, руководителя поддержки, ответственного за инфраструктуру и юриста.

Основные шаги разработки SLA

Сначала соберите входные данные: перечень IT‑сервисов, список типовых инцидентов, их частоту и влияние. Если статистики нет, используйте экспертную оценку и последние реальные случаи.

Затем определите бизнес‑критичность сервисов. Разделите их на уровни: жизненно важные, важные, вспомогательные. От этого зависят приоритеты заявок и целевые сроки.

На следующем шаге с командой поддержки и инфраструктуры выберите метрики: доступность, время реакции, время решения, объём работ. Для каждой договоритесь о способе измерения и источнике данных.

После этого зафиксируйте договорённости в черновике SLA: описание услуг, границы ответственности, приоритеты, сроки, порядок эскалации. Передайте черновик юристам, чтобы оформить юридическую оболочку, не ломая суть договорённостей.

Перед подписанием проверьте документ с исполнителями и представителем бизнеса: уберите двусмысленные формулировки, убедитесь, что все метрики выполнимы. Донесите ключевые пункты SLA до команды поддержки, иначе документ останется на бумаге.

Как контролировать IT подрядчика по SLA

Контроль по SLA строится вокруг трёх вещей: данные, регулярные обзоры, решения по итогам.

Организуйте поток данных. Зафиксируйте, какие отчёты подрядчик обязан предоставлять, и определите периодичность: ежемесячно для общей картины, еженедельно — для критичных сервисов.

На основе отчётов проводите регулярные встречи: заказчик, представитель подрядчика, руководитель поддержки. Обсуждайте нарушения SLA, причины, план корректирующих действий и сроки. Все договорённости фиксируйте протоколом или изменениями в процессах.

Ошибка — верить отчётам подрядчика без сверки с реальными инцидентами. Симптом: по отчётам всё отлично, а пользователи жалуются. Если отчёты SLA не обсуждаются регулярно, договор перестаёт влиять на работу. Что сделать сейчас: составьте список отчётов и показателей, которые хотите видеть ежемесячно, и согласуйте его с подрядчиком.

Мониторинг метрик и обзоры SLA

Базовый набор отчётов включает:

• сводку по инцидентам: количество, приоритеты, время реакции и решения;
• отчёт по доступности ключевых сервисов;
• статистику повторных обращений и эскалаций;
• краткое описание крупных инцидентов и принятых мер.

Для проверки используйте тикет‑систему и систему мониторинга. Сверяйте выборочно: отдельные заявки, интервалы простоя, время реакции. Несовпадения с отчётами подрядчика — повод пересмотреть процесс учёта и формулы расчёта метрик.

Формат обзора SLA делайте предсказуемым: повестка, тайминг, ответственные. Встреча должна завершаться списком действий: что улучшить в процессах, какие настройки мониторинга поменять, какие пункты SLA требуют уточнения. Договорённости фиксируйте письменно и возвращайтесь к ним на следующем обзоре.

Почему SLA нарушается и что с этим делать

SLA чаще ломается не из‑за «плохого подрядчика», а из‑за сочетания завышенных ожиданий, слабых процессов и некорректных метрик. Нарушения повторяются, если разбирать только последствия, а не причины.

Типичная причина — SLA спроектирован от «хотелок» бизнеса, а не от реальных возможностей команды. Симптом: постоянные просрочки по времени реакции даже при нормальной нагрузке. Что сделать: пересчитать цели по фактической статистике и зафиксировать новые значения с обеих сторон.

Организационный фактор — хаотические каналы обращений. Пользователи звонят напрямую администраторам, пишут в мессенджеры, а в тикет‑систему попадает лишь часть инцидентов. Если заявки обходят тикет‑систему, то статистика SLA искажена и выводы будут неверными. Что сделать: жёстко определить один основной канал и обучить пользователей работать через него.

Ошибка — наказывать подрядчика без анализа корня проблемы. Симптом: одни и те же нарушения, растущая напряжённость и нулевые улучшения. Вместо этого разбирайте крупные инциденты: причина → что сломалось в процессе или SLA → какие изменения внести в регламенты, метрики или ресурсы. 

Что сделать сейчас: выгрузите последние 10 нарушений SLA и для каждого отметьте, что стало первопричиной — договор, процессы или ресурсы.

Что будет, если работать без SLA

Когда SLA нет, каждая сторона держит в голове свою картину «нормального сервиса». Ожидания расползаются, а споры о качестве и сроках решаются по памяти и старым перепискам. Если ключевые ожидания от IT нигде не зафиксированы письменно, то SLA нет, даже если это слово звучит в переговорах.

Типичные последствия для бизнеса: простой критичных систем, срывы запусков, потеря сделок. Для подрядчика и внутреннего IT — постоянные авралы, обвинения в «медленной поддержке», выгорание команды. Ошибка считать, что «мы и так договоримся». Симптом — вечные цепочки писем и поиск виноватых после каждого крупного инцидента.

Мини‑сценарий. Падает CRM в разгар рабочего дня. Без SLA никто не знает, кому звонить, какой это приоритет и за сколько должны поднять систему. Час уходит на выяснение, ещё несколько — на споры о срочности. 

С SLA уже заранее определён канал обращения, приоритет, время реакции и время восстановления, а спорить можно только о фактах, а не о том, «обещали или нет».

Что сделать сейчас: выпишите критичные для бизнеса сервисы (финансовые системы, CRM, склад, сайт, почта) и отметьте, по каким из них нет формализованных ожиданий по времени реакции, времени решения и доступным каналам поддержки. Именно с этих сервисов стоит начинать внедрение SLA.

Проблемы без формального SLA и первый шаг к нему

Без формального SLA сроки срываются даже при добросовестной работе команды. Нет приоритетов, поэтому критические инциденты конкурируют за внимание с мелкими задачами. Пользователи ждут «почините за час», IT ориентируется на «как получится», а руководитель узнаёт о проблеме, когда бизнес уже несёт потери.

Пример инцидента без SLA: бухгалтерия не может провести платежи, заявки сыплются в чат, по телефону и в личные сообщения. Часть обращений теряется, время начала работ никто не фиксирует, через несколько часов спорят, «кто не так понял задачу», вместо того чтобы восстановить процесс и предотвратить повтор.

Первый шаг к формализации не требует сложного договора. Достаточно короткого документа, где описаны базовые услуги, каналы обращения и минимальные ожидания по времени реакции. Для начала хватит 5–7 пунктов, которые все участники понимают одинаково и готовы выполнять.

Что сделать сейчас: составьте черновик одной страницы по ключевому сервису. Укажите, какие типы обращений принимает поддержка, через какие каналы, в течение какого времени реагирует и когда инцидент считается закрытым. Этот черновик станет основой будущего SLA.

Проверка качества IT услуг по SLA

Формальное выполнение SLA по процентам не гарантирует довольных пользователей. Ошибка смотреть только на цифру «SLA 99%». Симптом — отчёты зелёные, а бизнес продолжает жаловаться на медленную или бесполезную поддержку.

Качество нужно оценивать по трём слоям: соблюдение целевых метрик, опыт пользователей и устойчивость процессов. Если в SLA нет ни одной метрики, связанной с опытом пользователя (опросы, NPS, доля повторных обращений), то картина качества будет неполной.

Для проверки подрядчика и внутреннего IT полезно регулярно задавать одни и те же вопросы и сверять ответы с отчётами. Базовый чек‑лист:

• Какой процент инцидентов закрывается в целевые сроки по приоритетам?
• Сколько обращений повторяется по одной и той же причине?
• Сколько времени уходит на восстановление ключевых сервисов при серьёзных сбоях?
• Какую оценку ставят пользователи после обращения в поддержку?
• Какие метрики за последние месяцы ухудшаются и почему?

Если споры о качестве и сроках идут только на уровне эмоций, без опоры на такие вопросы и данные, договор перестаёт помогать управлять сервисом. Что сделать сейчас: подготовьте 5–7 своих вопросов к подрядчику и внутреннему IT по качеству услуг и отчётам и договоритесь обсуждать их на ежемесячной встрече.

Чек лист для оценки подрядчика и внутреннего IT

Для аудита SLA используйте три группы вопросов: к документу, к отчётам и к опыту пользователей. Это помогает увидеть расхождения между «на бумаге» и реальной работой.

• К SLA: описаны ли услуги и исключения; понятны ли приоритеты; есть ли метрики по времени реакции, решению и удовлетворённости; прописан ли порядок эскалации.
• К отчётам: совпадает ли число инцидентов с тикет‑системой; видно ли разделение по приоритетам; есть ли тренды по месяцам; отражены ли причины нарушений и повторные инциденты.
• К опыту пользователей: как часто жалобы не попадают в отчёты; сколько обращений повторяется; понятны ли каналы связи с поддержкой; сколько времени уходит на решение типовых задач.

Если отчёты SLA выглядят идеально, а ответы пользователей противоречат цифрам, значит, часть обращений идёт мимо официальных каналов или метрики подобраны неверно. Что сделать сейчас: соберите короткий опрос для сотрудников о работе поддержки и сравните ответы с текущими отчётами по SLA.

Пересмотр SLA и развитие сервиса

SLA устаревает так же быстро, как меняется сервис. Ошибка держать его неизменным годами. Симптом — документ не отражает реальную работу, им не пользуются ни бизнес, ни поддержка.

Триггеры пересмотра простые: выросла нагрузка, изменился объём функций, поменялась архитектура или критичность сервиса для бизнеса. Если меняется модель сервиса или бизнес‑требования, SLA нужно пересматривать, иначе метрики и сроки перестают совпадать с ожиданиями.

Алгоритм ревизии по шагам:

• Соберите данные по инцидентам, нагрузке и нарушениям SLA за период.
• Сравните фактические показатели с текущими целями и жалобами бизнеса.
• Предложите изменения по метрикам, приоритетам, зонам ответственности.
• Согласуйте правки с бизнесом, IT и юристами, зафиксируйте новой версией.
• Обновите отчётность и правила работы поддержки под новый SLA.

Если пересмотр не назначен заранее, его откладывают до крупного сбоя. Что сделать сейчас: задайте периодичность ревизии SLA (например, раз в год или при крупных изменениях сервиса) и назначьте ответственного, который будет запускать этот процесс и собирать входные данные.

Как и когда обновлять SLA

Поводом для обновления служат конкретные события:

• запуск нового продукта или крупный релиз, меняющий функциональность;
• масштабирование инфраструктуры или перенос в другое окружение;
• рост числа пользователей или расширение географии работы сервиса;
• изменение бизнес‑критичности: сервис стал ключевым или, наоборот, вспомогательным;
• серия нарушений SLA по одной и той же причине.

В аутсорсинге изменения фиксируют допсоглашениями и версиями SLA с датой вступления в силу. Во внутреннем IT удобно вести нумерацию версий и хранить историю, чтобы при споре опираться на актуальный текст, а не на устные договорённости.

После обновления важно донести изменения до всех сторон. Проведите короткую сессию для поддержки и ключевых пользователей, разошлите выдержки с новыми приоритетами, сроками и каналами связи. Если команда не знает, что поменялось, даже лучший текст останется на полке.

Краткий вывод и следующий шаг

SLA связывает ожидания бизнеса, работу IT и ответственность подрядчика. Если документ чётко задаёт услуги, метрики и сроки, качество сервиса можно не только обсуждать, но и измерять, сравнивать, улучшать.

Соглашение об уровне сервиса работает, пока по нему ведут отчётность, проводят обзоры и обновляют формулировки под изменения в продукте и нагрузке. Если текст лежит в архиве и не влияет на решения, это не SLA, а формальное приложение к договору.

Первый практический шаг простой: выберите один критичный сервис — например, корпоративную почту, CRM или сервис‑деск. Выпишите список услуг, которые по нему реально оказываются, целевые метрики (доступность, время реакции, время решения) и каналы обращения.

Дальше сравните этот список с текущим договором и внутренними правилами. Отметьте, где нет цифр, где размыты границы ответственности, где не описаны приоритеты. Эти пометки станут основой правок к существующему SLA или отправной точкой для создания нового.