Кто платит за простой: ответственность подрядчика в деньгах, а не на словах

MAATRIX

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

Почему «мы разберёмся по-человечески» не работает именно тогда, когда нужнее всего

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

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

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

Штраф за простой сверх SLA: с чего вообще считать

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

Юристу стоит принести не пожелание «пусть будут штрафы», а конкретную структуру вопроса:

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

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

Ограничение ответственности подрядчика: почему оно почти всегда есть

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

Формы такого ограничения разные, и юристу стоит явно проговорить, какая закладывается в конкретный договор:

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

Как объективно измерить простой, а не спорить на словах

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

Практические темы для договора:

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

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

Кто отвечает, если простой вызван третьей стороной

Четвёртая тема — граница ответственности подрядчика, когда причина простоя лежит вне его прямого контроля. Это частая точка конфликта, потому что заказчик и подрядчик интуитивно по-разному видят, где заканчивается зона ответственности исполнителя.

Пограничные случаи для разбора с юристом:

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

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

Форс-мажор и плановые работы как законные исключения

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

Темы для юриста:

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

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

Чек-лист для разговора с юристом до подписания

Собранные темы стоит принести на встречу с юристом не как готовые формулировки (это не задача статьи и не задача читателя без юридического образования), а как список вопросов, требующих ответа применительно к конкретному проекту, юрисдикции сторон и сумме контракта:

1. От какой базы считается штраф за простой сверх SLA:
   от суммы контракта, фиксированной ставки за время, иначе?
2. Есть ли порог (буфер), ниже которого простой не штрафуется?
3. Штраф растёт со временем простоя или фиксирован за факт нарушения?
4. Есть ли верхний потолок суммарного штрафа за период?
5. Как оформлено общее ограничение ответственности подрядчика
   (потолок суммой, исключение косвенных убытков, срок претензии)?
6. Какой источник данных о простое считается официальным для сторон?
7. Что именно считается простоем (полная недоступность,
   деградация, недоступность отдельных функций)?
8. Какая зона ответственности подрядчика по инфраструктуре,
   а что явно вне неё (хостинг заказчика, сторонние сервисы)?
9. Какие плановые работы и как заранее согласуются,
   чтобы не попадать под штраф?
10. Какой список форс-мажорных обстоятельств применим
    в юрисдикциях обеих сторон?

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

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