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

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

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

Для такого договора перечень обслуживаемых устройств и систем важнее красивого названия услуги. Нужно понимать, какие рабочие станции, серверы, принтеры, МФУ, сетевое оборудование и учетные записи реально входят в поддержку.

Отдельно стоит проверить правила удаленного доступа, права администратора, резервное копирование, хранение паролей и порядок возврата доступов после прекращения договора.

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

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

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

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

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

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

Техническая поддержка редко ограничивается локальной техникой. На практике подрядчик работает с M365, Google Workspace, облачным резервным копированием, почтовым шлюзом, VPN, антивирусом, биллингом провайдера и сторонними лицензиями. Если договор делает вид, что этого вопроса не существует, в аварии никто не понимает, кто вообще вправе входить в чужой кабинет и поднимать сервис.

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

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

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

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

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

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

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