Что проверить в договоре на системное администрирование

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

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

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

Если эти вещи не описаны, красивое обещание о времени реакции почти ничего не дает на практике.

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

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

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

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

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

Если этого блока нет, заказчик рискует потерять управляемость инфраструктурой, а исполнитель — попасть в спор о якобы невыполненной работе.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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