SLA с подрядчиком: что реально можно требовать с маленькой студии

MAATRIX

Заказчик приносит на подпись SLA, скопированный из договора с прошлым enterprise-провайдером: реакция за 15 минут, доступность 24/7, персональный менеджер на связи в любой час. Студия из четырёх человек читает это и оказывается перед выбором — молча подписать то, что физически не может выполнить, или честно отказаться от проекта, который в остальном ей интересен. Оба варианта плохие, и оба возникают из одной ошибки: попытки натянуть на маленькую команду шаблон соглашения, рассчитанный на дежурную смену из десятка инженеров. Разберём, что в SLA с небольшим подрядчиком реалистично требовать, а что превращает документ в красивую фикцию.

Почему enterprise-шаблон не работает на маленькой студии

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

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

Требовать от такой студии enterprise-параметры — значит просить либо соврать в договоре, либо отказаться от контракта. Третьего варианта, где маленькая команда честно берёт на себя невыполнимые обязательства и потом их выполняет, не существует: физика количества людей не обманывается формулировками в PDF.

Что происходит, когда студия всё-таки подписывает нереалистичный SLA

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

В этот момент заказчик обнаруживает: обещанные 15 минут реакции превратились в три часа, потому что единственный человек, кто мог помочь, был недоступен, а «команда поддержки 24/7» на деле — тот же самый один человек в других терминах. Дальше конфликт разворачивается по одному из двух сценариев. Либо заказчик требует штрафные санкции, прописанные в SLA, — и выясняется, что мелкая студия физически не может их покрыть, потому что вся сумма контракта меньше суммы штрафа. Либо просто теряется доверие: документ, который не работает в критический момент, хуже отсутствия документа, потому что создаёт ложное чувство защищённости ровно тогда, когда защита нужна.

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

Время реакции в рабочие часы: конкретика вместо «мгновенно»

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

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

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

Эскалация вне обычных часов: не 24/7, а согласованный «крайний случай»

Отказ от круглосуточного дежурства не означает полного молчания в нерабочее время — между «дежурная смена 24/7» и «до понедельника ничего не делаем» есть разумная середина: явно согласованный процесс на случай действительно критичного инцидента. Это не то же самое, что настоящий on-call с ротацией, но это существенно лучше полной тишины ночью и по выходным.

Такой процесс стоит описать в SLA максимально конкретно, а не общей фразой «мы постараемся помочь при необходимости»:

• какой канал связи используется именно для экстренных случаев — отдельный от обычной переписки телефон, мессенджер с уведомлениями, тревожная кнопка в таск-трекере;
• кто именно реагирует на этот канал вне рабочего времени и есть ли у этого человека резерв, если он окажется недоступен;
• какое разумное время реакции на этот экстренный канал — заведомо больше, чем в рабочие часы, но конечное и понятное обеим сторонам, а не неограниченное «когда сможем»;
• входит ли такая экстренная реакция в стоимость контракта или оплачивается отдельно как внеурочная работа — это стоит проговорить заранее, а не выяснять постфактум по факту счёта.

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

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

Прозрачная приоритизация: что критично, а что подождёт до понедельника

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

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

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

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

Как закрепить это в договоре, а не только на словах

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

Практический минимум, который стоит закрепить письменно:

1. Рабочие часы поддержки: [дни недели, часы, часовой пояс]
2. Время реакции на обращение в рабочие часы: [диапазон, согласованный со студией]
3. Экстренный канал связи вне рабочих часов: [конкретный контакт]
4. Время реакции по экстренному каналу: [диапазон]
5. Критерии критичного инцидента: [конкретный список для вашего проекта]
6. Что происходит при недоступности экстренного контакта: [запасной план заказчика]
7. Оплата работы вне рабочих часов: [включена в контракт / отдельно]

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

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

Честный скромный SLA лучше красивого нарушенного

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

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

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

Частые вопросы