Гарантийный период после сдачи сервера: о чём договориться заранее

MAATRIX

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

Почему гарантию стоит обсуждать до подписания акта, а не после

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

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

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

Что считается гарантийным случаем, а что — новой задачей

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

Обычно относится к гарантии:

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

Обычно НЕ относится к гарантии, а считается новой задачей:

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

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

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

Как определить разумную длительность гарантийного периода

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

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

Что стоит учитывать при обсуждении срока для конкретного проекта:

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

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

Примеры из практики: где проходит граница

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

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

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

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

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

Процесс обращения: куда писать и какой реакции ожидать

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

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

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

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

Что зафиксировать заранее — чек-лист для переговоров о цене

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

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

Типичный конфликт и как его избежать

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

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

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

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