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

Термин SLA (service level agreement соглашение) в аутсорсинге звучит для многих собственников как что-то абстрактное и необязательное. На практике это формальное соглашение на бумаге, которое превращает устные договорённости в измеримые обязательства. В условиях, когда каждый рубль на счету, а налоговая и другие надзорные органы требуют безупречной отчётности, отсутствие чётких правил работы с IT-подрядчиком может обойтись же самого договора.

SLA в IT-аутсорсинге — это не просто «ещё один документ». Это инструмент, который обязательно фиксирует время реакции на инциденты, критерии качества и ответственность сторон. Разберёмся, что именно даёт это соглашение бизнесу в 2025–2026 годах, почему без него риски растут, а контроль над IT-инфраструктурой теряется.

Для российского бизнеса сейчас особенно остро стоят вопросы экономии. Расширять штат системных администраторов дорого: оклады, налоги, страховые взносы, больничные. IT-аутсорсинг с правильно составленным SLA позволяет получить предсказуемый уровень сервиса без найма сотрудников в штат. Но только если соглашение написано не «для галочки».

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

Что такое SLA простыми словами

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

В отличие от обычный договор, который часто описывает лишь предмет и стоимость услуг, SLA добавляет измеримые параметры. Соглашение об уровне сервиса — это не про «мы стараемся» или «по возможности». Это про конкретные цифры: время реакции — 20 минут, восстановление — 4 часа, доступность — 99,5%.

Что такое SLA в IT-аутсорсинге по сути? Это ответ на три вопроса для руководителя:

• Какой уровень сервиса я покупаю;
• Как я это проверю;
• Что получу, если обещанного не случится.

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

Соглашение service level agreement строится вокруг четырёх элементов:

1. Перечень услуг, которые подрядчик обязан предоставлять;
2. Метрики качества каждой услуги;
3. Порядок фиксации нарушений;
4. Компенсации и штрафы.

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

Зачем бизнесу SLA при работе с IT-подрядчиком

SLA заказчику нужен не как «ещё одна бумажка», а как инструмент контроля и защиты. Когда на счету каждый рубль, а налоговая и другие ведомства требуют безупречной сдачи отчётности через ЕГАИС, маркировку или системы прослеживаемости, простой IT-системы на два дня может вылиться в штрафы, сравнимые с месячным бюджетом IT-услуг.

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

Вот что конкретно даёт SLA собственнику бизнеса:

• Предсказуемый бюджет на IT-поддержку без сюрпризов в виде «а тут надо доплатить, потому что срочно»;
• Юридическую возможность требовать компенсацию за простой;
• Снижение нагрузки на управленческую команду — не нужно каждый раз разбирать, кто прав, а кто нет;
• Понятные KPI для подрядчика, которые можно проверить по отчётам.

Почему SLA работы с подрядчиком становится критичным именно сейчас? Потому что рынок труда в IT перегрет. Найти квалифицированного администратора в штат за адекватные деньги сложно. А если найдёте, то он уйдёт к конкуренту за плюс 20 тысяч. Аутсорсинг с чётким SLA решает кадровую проблему без расширения ФОТ.

Следующий важный момент — прозрачный контроль. Подрядчик знает, что каждая его метрика фиксируется. Если он обещал стабильность, но простой составил 10 часов в месяц, SLA позволяет применить санкции. В одном из логистических проектов после внедрения SLA доступность серверов выросла с 97% до 99,8% за три месяца — подрядчик просто начал выполнять то, что подписал.

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

Отсутствие формального соглашения — это всегда риски. И главный из них — субъективная оценка. Заказчик считает, что проблема критичная. Подрядчик — что терпимая. Начинаются споры, теряется время, бизнес несёт убытки.

Без SLA теряется не только деньги, но и управляемость. Вы не можете доказать, что подрядчик работал плохо. В договоре нет цифр, нет сроков, нет нормативов. Качество сервиса оценивается по принципу «нравится — не нравится». Это путь к постоянным конфликтам и, в конечном счёте, к разрыву отношений.

Реальные последствия работы без SLA:

Последствие	Описание	Риск для бизнеса
Простой критичных систем	Не можете взыскать компенсацию, потому что сроки не прописаны	Потеря выручки + штрафы от контрагентов
Споры по оплате	Подрядчик требует 100% оплаты, хотя услуги оказаны плохо	Дополнительные юридические расходы
Невозможность быстро сменить подрядчика	Передача инфраструктуры затягивается на месяцы	Заложник текущего исполнителя
Отсутствие гарантий	Любой сбой трактуется как «форс-мажор»	Бизнес платит за чужой провал

Особенно остро это чувствуется в сферах с высокими требованиями к непрерывности: онлайн-кассы, системы передачи данных в ФНС, маркировка «Честный ЗНАК». В этих областях простой на несколько часов может привести к блокировке лицензии или крупному штрафу. Без SLA вы не сможете доказать, что проблемы возникли именно по вине IT-подрядчика.

Типы SLA и смежные соглашения

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

1. Первый тип — клиентский (внешний) SLA. Это соглашение между заказчиком (вашим бизнесом) и внешним IT-подрядчиком. В нём прописаны все метрики, зоны ответственности и штрафы. Самый распространённый вариант для IT-аутсорсинга.

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

3. Третий тип — многоуровневый SLA. Он объединяет первый и второй варианты. Например, у вас есть внешний SLA с подрядчиком, а внутри вашей IT-службы — внутренние операционные соглашения между сотрудниками. Такая конструкция позволяет управлять всей цепочкой предоставления услуги.

Отдельно стоит сказать про OLA — operational level agreement. В русской практике его часто называют операционным соглашением или соглашением об уровне обслуживания между внутренними подразделениями. OLA не заменяет SLA, а дополняет его.

Вот как выглядят три типа SLA в таблице для наглядного сравнения:

Тип соглашения	Между кем	Пример	Для чего нужен
Клиентский SLA	Заказчик и внешний подрядчик	Договор с IT-аутсорсером на поддержку серверов	Защита интересов бизнеса, штрафы, метрики
Внутренний SLA	Подразделения внутри компании	Отдел разработки и отдел тестирования	Ускорение внутренних процессов, прозрачность
OLA (операционное соглашение)	Технические команды внутри подрядчика	Сетевая команда и команда администрирования серверов	Обеспечение выполнения внешнего SLA

Чем SLA отличается от OLA

Отличие SLA от OLA — один из самых частых вопросов у руководителей, которые углубляются в управление IT-услугами. Разные уровни соглашений решают разные задачи.

SLA — это внешнее обещание заказчику. OLA — внутреннее обещание между командами исполнителя, которое обеспечивает выполнение SLA.

Пример. В вашем SLA с подрядчиком прописано: «Время восстановления сервера после сбоя — не более 4 часов». Чтобы это выполнить, внутри компании-подрядчика должны быть заключены OLA между:

• Командой мониторинга (обнаружить сбой за 5 минут);

• Сетевой командой (диагностика за 30 минут);

• Командой системных администраторов (восстановление за 3 часа);

• Службой качества (проверка за 25 минут).

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

Соглашение об уровне обслуживания (SLA) обращено к бизнесу. Operational level agreement — к техническим специалистам. И часто проблема невыполнения SLA кроется именно в разрыве внутренних OLA. Когда вы обсуждаете договор с подрядчиком, спросите: «А как у вас построено взаимодействие между службами? Есть ли у вас внутренние регламенты?» Ответ покажет, насколько серьёзно подрядчик подходит к качеству.

Сравнение в таблице:

Параметр	SLA	OLA
Аудитория	Заказчик, бизнес	Внутренние технические команды
Язык	Бизнес-метрики (доступность, время реакции)	Технические задачи (настройка, диагностика, устранение)
Юридическая сила	Приложение к договору, можно взыскать штрафы	Внутренний документ подрядчика, к бизнесу прямого отношения не имеет
Кто контролирует	Заказчик через отчётность	Внутренний менеджмент подрядчика

Понимание разницы между SLA и OLA помогает правильно строить отношения с подрядчиком и не требовать от него того, что он физически не может выполнить из-за внутренних разрывов.

Ключевые метрики SLA: KPI, SLI, SLO

Метрики в SLA — это не просто цифры для отчётности. Это измеримые критерии, по которым заказчик оценивает, работает подрядчик или нет. Ключевые метрики качества должны быть объективными, понятными обеим сторонам и привязанными к бизнес-процессам.

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

1. Первый уровень — SLI (Service Level Indicator). Это технический показатель «сырых» данных. Например: «время ответа сервера на запрос составило 0,3 секунды». Или «за месяц зафиксировано 47 минут простоя». SLI — это факт, цифра без оценки.
2. Второй уровень — SLO (Service Level Objective). Это целевое значение, которое подрядчик обязуется соблюдать. Например: «доступность сервера должна быть 99,9% в месяц». Или «время реакции на инцидент P1 — не более 15 минут». SLO — это обещание.
3. Третий уровень — KPI (Key Performance Indicator). Это бизнес-показатель, который влияет на оплату, бонусы или штрафы. Например: «если доступность упала ниже 99%, подрядчик платит штраф 5% от месячной стоимости». Не все SLO становятся KPI. Обычно в договор выносят 3–7 самых критичных для бизнеса показателей.

Параметры качества без привязки к бизнес-процессам бесполезны. Например, доступность сервера 99,9% звучит хорошо. Но если этот сервер отвечает за онлайн-кассы, то даже 0,1% простоя (43 минуты в месяц) может привести к сбою в самый неподходящий момент.

Управление качеством услуг по SLA строится на цикле: измерили (SLI) → сравнили с нормой (SLO) → применили санкции или бонусы (KPI). И так каждый отчётный период.

Вот как это выглядит на примере типового IT-сервиса:

Что измеряем	SLI (факт)	SLO (норма)	KPI (бизнес-последствие)
Доступность CRM	99,4% за апрель	Не ниже 99,8%	Штраф 3% от оплаты за месяц
Время реакции на P1	20 минут	Не более 15 минут	Штраф 2000 руб. за каждое превышение
Время восстановления после сбоя	5 часов 20 минут	Не более 4 часов	Компенсация за каждый час простоя сверх нормы

Объективно оценить подрядчика можно только при наличии всех трёх уровней метрик. Если в договоре есть только KPI, но нет методики расчёта (SLI), начинаются споры: «а как мы считали», «а это не считается», «а лог-файл мы не ведём». Методика измерений должна быть приложением к SLA.

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

Основные метрики уровня сервиса в IT

Uptime (доступность) — самая популярная метрика, но не единственная. Простой оборудования в IT-аутсорсинге измеряется в процентах, но способ расчёта сильно влияет на результат. Например, можно считать доступность за месяц, а можно — за год. Можно исключать плановые работы, а можно — нет.

Доступность uptime рассчитывается по формуле: (общее время − время простоя) / общее время × 100%. Восстановления системы после сбоя — это время, за которое сервис вернулся в работу. Важно различать: время восстановления (всё заработало) и время решения (найдена и устранена причина).

Время реакции — это интервал от момента, когда заказчик сообщил о проблеме (или система зафиксировала сбой), до момента, когда подрядчик начал работать над инцидентом. Не решил, а именно начал. Подрядчик должен подтвердить приём заявки, назначить ответственного, начать диагностику.

Часов в SLA — отдельная тема. «Время реакции — 2 часа» звучит хорошо. Но 2 часа в будни с 9 до 18 или 2 часа круглосуточно? Разница колоссальная. Подрядчики часто экономят на ночной и выходной поддержке. Если ваш бизнес работает 24/7 (интернет-магазин, логистика, маркетплейс), требуйте круглосуточное время реакции. Если нет — договаривайтесь о рабочем времени.

Полный набор метрик, которые стоит включить в SLA для IT-аутсорсинга:

• Uptime (доступность) в %, отдельно для каждого критичного сервиса

• Время реакции (response time) в минутах или часах, дифференцированное по приоритетам

• Время восстановления (resolution time) для каждого приоритета

• Время решения (time to fix) — устранение первопричины

• Частота инцидентов — сколько сбоев допустимо в месяц

• Доля решенных заявок без эскалации

• Процент соблюдения SLA за отчётный период

Для реального проекта в сфере логистики были установлены такие целевые показатели: доступность сервера учёта товаров — 99,8%, время реакции на P1 — 30 минут круглосуточно, время восстановления — 3 часа. Время простоя сверх нормы компенсировалось из расчёта 5000 руб./час. За первые два месяца подрядчик дважды нарушал SLA, выплатил компенсацию 45 000 руб. На третий месяц нарушений не было.

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

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

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

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

Классы P1, P2, P3 (от Priority 1 до Priority 3) — это международное обозначение уровней критичности.

P1 (критический) — сервис полностью недоступен, остановлены ключевые бизнес-процессы, множество пользователей не могут работать. Примеры: упал сервер 1С, недоступна CRM, не работает онлайн-касса. Время реакции на P1 должно измеряться минутами (5–30 минут), восстановление — часами (2–4 часа), работа ведётся круглосуточно 7 дней в неделю.

P2 (высокий) — сервис работает, но с серьёзными ограничениями, критичная функция недоступна, но есть обходной путь. Пример: медленно работает учётная система, не загружаются отчёты, но основные операции возможны. Время реакции — до 2 часов в рабочее время, восстановление — до 8 часов.

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

Матрицы определения приоритета может выглядеть так:

Влияние на бизнес	Срочность (критичность инцидента)	Приоритет
Высокое (остановка процесса)	Высокая (блокирует работу)	P1
Высокое (остановка процесса)	Средняя (медленная работа)	P2
Среднее (один отдел)	Высокая (блокирует работу отдела)	P2
Среднее (один отдел)	Средняя (медленная работа)	P3
Низкое (один сотрудник)	Любая	P3

В SLA обязательно нужно прописать, как определяется влияние и срочность. Кто присваивает приоритет — заказчик или подрядчик? Что делать при несогласии? Типичное правило: приоритет назначает заказчик при открытии заявки, но подрядчик может запросить изменение с обоснованием. При конфликте — решение за заказчиком.

Также важно указать, как учитываются будни и выходные. Если инцидент P1 случился в 23:00 пятницы, время реакции должно отсчитываться немедленно, а не с понедельника 9:00. Иначе любой сбой перед выходными автоматически становится «бесплатным» для подрядчика.

Что должно быть в договоре SLA — структура документа

Структура SLA-документа должна быть такой, чтобы любой сотрудник — от технического специалиста до финансового директора — мог найти нужный раздел. Содержание соглашения обычно включает 7–10 обязательных блоков.

Вот список того, что должно быть в договоре SLA:

• Предмет соглашения (какие именно IT-услуги покрываются SLA);

• Перечень обслуживаемого оборудования, ПО, серверных, облачных ресурсов;

• Метрики качества для каждой услуги (uptime, время реакции, восстановление);

• Классификация инцидентов и приоритеты (матрица P1–P3);

• Права и обязанности заказчика и подрядчика;

• Порядок фиксации нарушений и обмена отчётностью;

• Санкции, штрафы, компенсации за нарушение SLA;

• Форс-мажор и исключения (плановые работы, действия заказчика);

• Порядок пересмотра и изменения SLA;

• Срок действия и порядок расторжения.

Содержит ли ваш текущий договор все эти пункты? Если нет, то это не полноценное SLA, а только его видимость.

Предмет договора должен быть максимально конкретным. Не «сопровождение IT-инфраструктуры», а «поддержка 15 серверов (список прилагается), 120 рабочих станций, 3 маршрутизаторов, системы резервного копирования на базе Veeam». Без приложения с перечнем оборудования SLA не работает — всегда можно сказать: «а это не входило в услугу».

Структура SLA часто оформляется как приложение к основному договору на IT-аутсорсинг. Это удобно: основной договор описывает общие условия (цена, сроки, реквизиты), а приложение — конкретные уровни сервиса. Если нужно изменить метрики, меняется только приложение, а не весь договор.

Согласование SLA — отдельный этап, который нельзя пропускать. Многие компании подписывают договор и думают, что SLA «сам собой работает». Нет. Каждый пункт должен быть согласован и понятен обеим сторонам. Заказчик должен понимать, как именно измеряется downtime. Подрядчик должен подтвердить, что может предоставить отчётность в нужном формате.

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

Время реакции, восстановления и гарантированная доступность

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

Реакции на инциденты по разным приоритетам должны отличаться в разы. Для P1 норма — 15 минут в любое время суток. Для P3 — до 4 часов в рабочие дни. При этом важно понимать, что реакция — это не решение проблемы, а подтверждение того, что подрядчик взял заявку в работу, идентифицировал проблему и приступил к диагностике.

Восстановить работоспособность после сбоя — это вторая ключевая метрика. Время восстановления (Time To Restore) должно быть реалистичным, но жёстким. Нормы по минутам и часам зависят от критичности сервиса. Если после сбоя сервер недоступен, а бизнес терпит убытки, норма восстановления для P1 — 2–4 часа. Для P2 — 8–12 часов, для P3 — до 48 часов.

Гарантированная доступность (uptime) рассчитывается за месяц, квартал или год. Допустимо указывать её в процентах с точностью до десятых. Пример: 99,9% доступности означает не более 43 минут простоя в месяц (если считать 24/7). 99,5% — это уже 3,6 часа простоя в месяц. Разница существенная.

Нормы времени реакции и восстановления в типовом SLA для среднего бизнеса:

Приоритет	Время реакции	Время восстановления	Гарантированная доступность
P1 (критичный)	15 минут (24/7)	4 часа	99,9% в месяц
P2 (высокий)	2 часа (рабочий день)	8 часов	99,5% в месяц
P3 (средний)	8 часов (рабочий день)	48 часов	99,0% в месяц

Процент доступности ниже 99% для критичных сервисов — это уже не SLA, а «как получится». В российских проектах с жёсткими требованиями к непрерывности (финансовый сектор, онлайн-торговля, маркировка) требования к доступности могут достигать 99,99% — это менее 5 минут простоя в месяц.

Регламент обновлений, резервного копирования и перечень оборудования

Регламент обновлений — раздел SLA, который часто забывают прописать, а зря. Без чётких правил подрядчик может обновлять ПО когда угодно или не обновлять вообще. В хорошем соглашении указывается периодичность обновлений (например, ежемесячно для критичных уязвимостей и ежеквартально для версионных), порядок согласования и время проведения (обычно ночью в воскресенье). Обновления не должны считаться простоем, но о них надо предупреждать минимум за 5 рабочих дней.

Резервного копирования касается ещё один важный блок. SLA должен содержать не просто фразу «бэкапы делаются», а конкретику: периодичность (ежедневный, еженедельный), тип бэкапа (полный, дифференциальный), срок хранения (30 дней, 6 месяцев), место хранения (локально и в облаке), а также регулярное тестирование восстановления из бэкапа (например, ежемесячно).

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

• Сервер (модель, серийный номер, IP-адрес, назначение);

• Серверных компоненты (хранилища, сетевое оборудование, СХД);

• Программное обеспечение (операционные системы, СУБД, прикладные системы с версиями);

• Рабочие станции и периферия, если входят в услугу;

• Облачные ресурсы и виртуальные машины.

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

Ответственность сторон и санкции при нарушении SLA

Нарушение метрик SLA должно иметь чёткие финансовые последствия. Штрафы и компенсации — это не способ заработать, а мотивация для подрядчика соблюдать договорённости. Невыполнение показателей SLA без уважительной причины (форс-мажор или действия заказчика) влечёт санкции.

Финансовых механизмов несколько. Самый простой — штраф за каждый факт нарушения. Например: превышение времени реакции на P1 — 3000 рублей за каждые 30 минут сверх нормы. Превышение времени восстановления — 5000 рублей за каждый час. Нарушение доступности (простой сверх нормы) — 2% от месячной стоимости услуги за каждый час.

Более жёсткий вариант — шкала с нарастанием. При первом нарушении за квартал — предупреждение, при втором — штраф, при третьем — право заказчика расторгнуть договор в одностороннем порядке. В некоторых контрактах прописывают компенсацию не только штрафа, но и подтверждённых убытков бизнеса (например, если из-за простоя не прошли платежи или начислены штрафы от госорганов).

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

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

Для заказчика важно также прописать ответственность за несвоевременное предоставление доступа, неисполнение своих обязательств (например, неподписание актов). Ответственность всегда должна быть двухсторонней, иначе договор может быть признан кабальным.

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

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

Составить SLA, который действительно работает, а не пылится на полке, можно за шесть шагов. Алгоритм проверен на десятках российских проектов — от небольших интернет-магазинов до производственных предприятий с распределённой IT-инфраструктурой.

1. Определите перечень услуг, которые нужно покрыть SLA

На этапе сбора информации составьте список всех IT-услуг, критичных для бизнеса. Не включайте в SLA то, без чего бизнес может работать день-два без серьёзных потерь — это лишняя бюрократия. Сосредоточьтесь на том, от чего зависит выручка, отчётность перед госорганами, работа с клиентами. План должен быть реалистичным: не нужно требовать 99,99% доступности для внутреннего файлового сервера.

2. Пропишите метрики для каждой услуги

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

3. Напишите матрицу приоритетов и классификацию инцидентов

Создайте таблицу, где каждому типу проблемы соответствует свой приоритет (P1, P2, P3). Зафиксируйте, кто и как назначает приоритет. Согласуйте этот раздел с подрядчиком особенно тщательно — здесь чаще всего возникают споры. В хорошем SLA есть примеры: «P1 — недоступна CRM для 80% пользователей, остановлены продажи».

4. Пропишите санкции и ответственность

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

5. Зафиксируйте отчётность и порядок контроля

Согласуйте формат отчётов (ежемесячно, в таблице Excel или в ITSM-системе), перечень метрик, которые будут в отчёте, и сроки предоставления. Заказчик должен иметь право проверять логи, данные мониторинга, журналы инцидентов. Это не недоверие, это стандартный механизм контроля.

6. Подпишите и регулярно пересматривайте

После согласования всех разделов — подписание. Но SLA не вечен. Раз в квартал или хотя бы раз в год проводите пересмотр: метрики устарели? Изменилась IT-инфраструктура? Появились новые риски? Обновляйте SLA допсоглашением.

Этот алгоритм позволяет написать работающий SLA за 2–3 недели при условии активного участия бизнеса. Если пустить процесс на самотёк и отдать «юристам», получится общая бумажка без конкретики.

Примеры SLA для IT-услуг на практике

Теория теорией, но собственнику нужны примеры. Ниже — реальные образцы метрик для популярных IT-услуг, которые заказывают на аутсорсинге. Например, service desk служба поддержки пользователей, удалённые рабочие столы, почта и CRM.

Пример 1. Service desk (техническая поддержка пользователей)

Этот сервисный SLA описывает работу первой линии поддержки. Заявки принимаются по e-mail, телефону, в мессенджере. Ключевые метрики:

Тип заявки	Время реакции	Время решения	Примечание
Блокировка учётной записи	30 минут	1 час	В рабочее время
Не работает принтер у одного сотрудника	4 часа	8 часов	Рабочий день
Сбой антивируса	2 часа	4 часа	Приоритет P2
Консультация по работе в CRM	8 часов	16 часов	P3

В SLA service desk важно прописать каналы приёма заявок (e-mail, чат, телефон) и SLA для каждого канала. Для e-mail допустимо время реакции дольше, чем для телефона.

Пример 2. Удалённые рабочие столы и серверы

Если бизнес использует RDP или VDI, критичны доступность и скорость. Пример SLA:

• Доступность удалённых рабочих столов: 99,8% в рабочее время (пн–пт, 9:00–20:00)

• Время реакции на P1 (недоступны все рабочие столы): 15 минут круглосуточно

• Время восстановления: 2 часа

• Плановые работы: каждое воскресенье с 2:00 до 4:00, не считаются простоем

Пример 3. Корпоративная почта (e-mail) и CRM

Почтовый сервер и CRM — сервисы, от которых зависит общение с клиентами и сделки. Пример SLA для CRM на базе облачной версии или собственного сервера:

• Доступность: 99,5% в месяц

• Uptime (доступность) для CRM: 99,8% в часы работы (9–21)

• Время реакции на недоступность e-mail для всех пользователей: 20 минут

• Восстановление после сбоя: 3 часа

• Компенсация: 3% от абонентской платы за каждый час простоя сверх нормы

Для CRM дополнительно можно включить метрику «целостность данных» — гарантия, что при сбое не потеряются клиенты и сделки.

Пример 4. Хостинг и сайт

Если бизнес зарабатывает через сайт (интернет-магазин, лендинг, портал), SLA на хостинг должен быть жёстким. Обычно провайдеры предлагают типовой SLA:

• Доступность: 99,5% – 99,9% в месяц

• Время реакции на недоступность: 1 час

• Компенсация: дни простоя компенсируются днями обслуживания (бесплатно)

Но для серьёзного бизнеса этого мало. Требуйте конкретные штрафы в рублях, а не «подарочные дни». Например: «при простое более 2 часов в месяц — возврат 10% стоимости, более 4 часов — 25%, более 8 часов — 50%».

Пример 5. DevOps и сопровождение приложений

Для компаний с собственной разработкой или 1С SLA может включать:

• Время реакции на критический баг в production: 1 час

• Время исправления критического бага (релиз фикса): 24 часа

• Доступность dev- и test-сред: 99% (допустим простой на ночь)

• Частота деплоев: не чаще 1 раза в день в рабочее время

Пример из практики: производственная компания с ERP на 1С заключила SLA с аутсорсером. В первый месяц подрядчик дважды нарушил время восстановления после сбоя (4 и 6 часов вместо 2). По условиям SLA выплатил компенсацию 45 000 руб. После этого система мониторинга была перестроена, и нарушений не повторялось.

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

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

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

Проверка соблюдения SLA начинается с отчётности. Подрядчик обязан предоставлять ежемесячный отчёт по итогам работы, где по каждому инциденту указано: дата и время заявки, приоритет (P1, P2, P3), фактическое время реакции, фактическое время восстановления, факт нарушения или соблюдения SLA. Отчёт должен быть не «галочкой», а документом с цифрами, подтверждёнными логами системы мониторинга.

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

Статистику по инцидентам полезно визуализировать в простой таблице:

Месяц	Всего заявок	Нарушений SLA	% соблюдения	Компенсация (руб.)
Январь	47	3	93,6%	12 000
Февраль	52	2	96,2%	8 000
Март	45	1	97,8%	5 000

Методологий контроля несколько, но для малого и среднего бизнеса достаточно ежемесячной сверки фактов с планом. Не нужно сложных инструментов ITSM на старте — хватит Excel или Google Sheets, куда подрядчик выгружает данные. Главное, чтобы эти данные можно было перепроверить.

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

Что ещё можно проверять:

• Выполнение плановых работ (обновления, бэкапы) согласно регламенту;

• Соблюдение процедуры эскалации (если инцидент долго не решается, подрядчик должен подключать более квалифицированных специалистов);

• Наличие актов приёмки услуг с пометкой о нарушениях (если они были).

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

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

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

Первая и самая распространённая причина — нереалистичные метрики. Заказчик требует доступность 99,99% при бюджете в 30 тысяч рублей в месяц. Или время реакции 10 минут на P2, хотя специалисты физически не могут везде успевать. Ошибка на этапе составления SLA: цифры взяты с потолка, без учёта реальных возможностей подрядчика и его инфраструктуры. Что делать: пересмотреть SLA, провести анализ нагрузки, согласовать реалистичные метрики.

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

Третья причина — человеческий фактор внутри подрядчика. Из-за текучки кадров новые сотрудники не знают процедур. Ушёл ведущий инженер, а замену не нашли. Операционные соглашения (OLA) между отделами подрядчика не работают. Что делать: требовать от подрядчика план действий по снижению текучки и отчёт по инцидентам с указанием причин каждого нарушения.

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

Пятая причина — метрики не привязаны к бизнес-процессам. Например, время реакции измеряется, но не имеет значения, потому что реальная проблема не в реакции, а в долгом восстановлении. Или доступность считается по всему серверу, но бизнесу важно, чтобы работал конкретный модуль. Что делать: пересмотреть метрики, сделать их более точными.

Что делать, если SLA нарушается систематически, а подрядчик не исправляется:

1. Зафиксируйте нарушения документально (акт, письмо, запись в системе).
2. Примените штрафные санкции по договору.
3. Назначьте встречу для разбора причин.
4. Если подрядчик не предлагает план исправления — ищите нового.
5. При расторжении требуйте передачу всей документации и доступа к инфраструктуре по акту.

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

Итоги и следующий шаг

SLA в IT-аутсорсинге — это не просто приложение к договору. Это фундамент, на котором строится доверие между заказчиком и подрядчиком. Без него вы получаете абстрактные обещания, субъективные оценки и споры по каждой проблеме. С ним — измеримые метрики, прозрачную отчётность и реальную возможность влиять на качество услуг.

Давайте коротко повторим главное, что нужно знать о SLA:

• SLA — это формальное соглашение, которое фиксирует уровни сервиса в цифрах: время реакции, доступность, время восстановления.

• Без SLA подрядчик не обязан отчитываться по конкретным метрикам, а вы не можете взыскать компенсацию за простой.

• В хорошем SLA есть чёткие приоритеты (P1, P2, P3), матрица инцидентов и шкала штрафов за нарушения.

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

• Если SLA нарушается, сначала разбирайте причины, затем применяйте санкции. Иногда проблема не в подрядчике, а в нереалистичных метриках.

Следующий шаг — практический. Не пытайтесь написать идеальный SLA с первого раза. Начните с малого: выберите 2–3 самых критичных сервиса (например, доступность сервера 1С и время реакции на блокировку учётки). Пропишите по ним метрики, согласуйте с подрядчиком, запустите пилот на один квартал. Затем доработайте и расширьте на другие услуги.

Если у вас уже есть договор с IT-подрядчиком, но SLA нет или он «для галочки», не ждите. Инициируйте пересмотр прямо сейчас. Попросите подрядчика предоставить статистику по инцидентам за последние 3 месяца. На основе этих данных предложите конкретные метрики. Хороший подрядчик не будет против — наоборот, ему проще работать по правилам.

И последнее: SLA — это живой документ. Он меняется вместе с вашим бизнесом. Растёт нагрузка на IT — пересматривайте метрики. Появляются новые риски (например, требования по импортозамещению или ужесточение отчётности) — добавляйте их в соглашение. Не пытайтесь предусмотреть всё сразу, но будьте готовы обновлять SLA по мере необходимости.

Чек-лист из 15 пунктов перед подписанием договора IT-аутсорсинга

Перед тем как подписать договор с IT-подрядчиком, проверьте SLA по этому чек-листу. Каждый пункт — это зона потенциального риска, если он пропущен или прописан размыто.

1. Метрики и измерения

• В договоре явно указано, что приложение с SLA является его неотъемлемой частью.
• Для каждой услуги прописаны конкретные измеримые метрики: доступность в %, время реакции в минутах/часах, время восстановления.
• Методика расчёта доступности и времени реакции расшифрована (как фиксируется начало инцидента, исключаются ли плановые работы).
• Нормы различаются по приоритетам (P1, P2, P3), а для P1 установлено круглосуточное время реакции, включая выходные и праздники.

2. Приоритеты и классификация

• Есть матрица определения приоритета с примерами: что считается P1, P2, P3.
• Заказчик имеет право самостоятельно назначать приоритет при открытии заявки.
• Процедура эскалации прописана: кто подключается, через какое время, с какой ответственностью.

3. Санкции и ответственность

• За нарушение каждой метрики установлены штрафы или компенсации в рублях (не в «скидках на будущие услуги»).
• При систематических нарушениях (например, 3 месяца подряд) у заказчика есть право расторгнуть договор в одностороннем порядке.
• Форс-мажор описан чётко и закрывает только реальные чрезвычайные ситуации (пожары, решения госорганов), а не «проблемы с персоналом» или «сбой у хостера».

4. Отчётность и контроль

• Подрядчик обязан предоставлять ежемесячный отчёт по инцидентам с указанием даты, времени, приоритета, факта нарушения.
• Заказчик имеет право запрашивать логи мониторинга и данные из ITSM-системы для проверки.
• В договоре указан срок предоставления отчёта (например, до 5-го числа месяца, следующего за отчётным).

5. Перечень и границы ответственности

• Приложение с перечнем оборудования, ПО, серверов, облачных ресурсов подписано обеими сторонами.
• Чётко указано, что не входит в SLA: рабочие станции сотрудников (если отдельно не оговорено), бытовая периферия, услуги связи, нештатное ПО.

Используйте этот чек-лист при переговорах. Если подрядчик сопротивляется более чем по 3–4 пунктам из 15, это повод задуматься: возможно, он не готов к прозрачной работе. Хороший аутсорсер сам заинтересован в чётком SLA — это снижает количество конфликтов и позволяет ему уверенно планировать свои ресурсы.