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

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

Что на самом деле входит в обслуживание корпоративной инфраструктуры

Прежде чем искать подрядчика, нужно чётко зафиксировать объём работ. Под «инфраструктурой» в 2024 году понимают не только серверные и сетевое оборудование, но и облачные тенанты, контейнерные платформы, системы мониторинга и бэкапа, управление идентификаторами и доступы (IAM), а также периметр безопасности. Обслуживание делится на три слоя, которые часто перекрываются:

• Реактивная поддержка (L1–L3): инцидент-менеджмент, выполнение сервис-запросов, эскалация к вендорам железа и ПО, восстановление после сбоев.
• Проактивное администрирование: установка патчей, ротация логов, проверка бэкапов, управление емкостью (capacity planning), обновление прошивок, тюнинг производительности.
• Инженерные проекты и изменения: миграции, развёртывание новых сегментов, внедрение IaC, аудит безопасности, подготовка к аттестациям (ФСТЭК, 152-ФЗ, PCI DSS, ISO 27001).

Чёткое разделение этих слоев в ТЗ исключает споры вроде «почему вы не обновили прошивку на коммутаторах, если у нас договор на поддержку?» — обновление прошивок это плановая инженерия, а не реактивная поддержка, и её объём нужно фиксировать отдельно.

Основные модели взаимодействия: MSP, системный интегратор, штат или гибрид

На рынке нет единой терминологии, но практически встречаются четыре модели. Выбор модели определяет и структуру договора, и распределение ответственности, и цену.

Модель	Суть	Когда подходит	Ограничения
MSP (Managed Service Provider) — полная передача операций	Подрядчик берёт на себя 24/7 мониторинг, инциденты, патчинг, бэкапы, часто — управление облачными аккаунтами. Оплата фиксированная месячная (per device / per node / per user).	Нет внутренней ИТ-команды или она мала (1–2 админа), нужна предсказуемая стоимость и SLA на доступность сервисов.	Зависимость от одного вендора (vendor lock-in), сложность аудита качества «изнутри», стандартные SLA часто не покрывают бизнес-риски конкретного приложения.
Системный интегратор / профильный вендор — проектно-служебная модель	Договор на сопровождение конкретного стека (например, только VMware + NetApp + Cisco) или на выполнение плановых работ по заявкам. Оплата по факту (T&M) или банк часов.	Есть сильная внутренняя команда, нужна экспертиза по узким стекам, сложные миграции, аудиты.	Нет единой ответственности за доступность end-to-end, управление несколькими договорами, риск «пробелов» на стыках зон ответственности.
Внутренняя команда + точечное аутсорсирование (гибрид)	Свои админы держат операционку, подрядчик делает то, чему нет компетенций внутри: настройка WAF, аудит AD, миграция в Kubernetes, ночные дежурства.	Зрелая ИТ-организация, чёткое понимание своих пробелов, готовность управлять подрядчиком.	Требует внутреннего технического менеджера, который понимает, что проверять и как принимать работу.
Специализированные нишевые провайдеры (SecOps, DevOps, DBA, Backup as a Service)	Отдельные договоры на безопасность (SOC, pentest), базы данных, CI/CD, бэкап как сервис.	Высокие требования к конкретному домену, регуляторные обязательства.	Фрагментация ответственности, сложность координации при инциденте, рост управленческих затрат.

На практике крупные энтерпрайзы часто комбинируют: базовый MSP на периметр и мониторинг + интегратор на сторадж и виртуализацию + нишевые вендоры на безопасность и БД. Малый и средний бизнес чаще выбирает единого MSP с полным покрытием.

Ключевые критерии отбора: что проверять в первую очередь

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

1. Соответствие стека и глубина экспертизы

Не спрашивайте «умеете ли вы работать с Cisco?» — спросите: «кто именно будет настраивать ACI, сколько у него сертификаций CCIE, покажите конфиги из похожего проекта за последние 12 месяцев». Требуйте:

• Список инженеров с именами, сертификациями (актуальными, не просроченными) и ролями в проекте.
• Кейсы с техностеками, максимально близкими к вашему (версии гипервизоров, модели стораджей, облачные провайдеры).
• Наличие лаборатории/стенда для тестирования патчей и изменений перед выкаткой в прод.

2. SLA и штрафные санкции — читаем мелочь

Стандартный SLA «99.9% аптайма» ничего не значит без определений. Уточняйте:

• Что считается инцидентом: падение кластера БД или недоступность портала самообслуживания?
• Время реакции (Response Time) vs время восстановления (Resolution Time): часто гарантируют только реакцию («примем заявку за 15 мин»), а восстановление — «по лучшим усилиям».
• Исключения: плановые окна, форс-мажор, действия третьих лиц (провайдер канала, вендор ПО), ошибки ваших сотрудников.
• Штрафы (Service Credits): процент от абонентской платы за нарушение SLA. Если штраф plafonирован 10–15% месячной оплаты — мотивации у подрядчика мало. Ищите uncapped penalties или поэтапные штрафы за длительные простои.
• Бизнес-ориентированные SLA: RTO/RPO для критических сервисов, время доставки изменения (lead time for changes), процент успешных деплоев.

3. Процессы и инструменты: прозрачность и управляемость

Хороший подрядчик принесёт свою ITSM-систему (ServiceNow, Jira Service Management, топовые российские аналоги) и даст вам доступ к порталу. Проверьте:

• Единая точка входа (Single Point of Contact) — портал, телефон, Telegram-бот, email. Нет «пишите инженеру в личку».
• CMDB (база конфигураций) — актуальная, с привязкой к сервисам, владельцам и SLA.
• Change Management — любой плановый работ требует RFC (Request for Change) с риск-анализом, планом отката и вашим согласованием (CAB).
• Reporting — еженедельные/ежемесячные отчёты: SLA compliance, топ инцидентов, тренды емкости, статус бэкапов, открытые уязвимости, плановые изменения.
• Интеграция с вашими системами — пуш уведомлений в ваш Slack/Teams/Mattermost, синхронизация тикетов.

4. Безопасность и комплаенс

Подрядчик получает доступ к короне вашей инфраструктуры. Минимальный чек-лист:

• Наличие сертификата ISO 27001 (или ГОСТ Р ИСО/МЭК 27001) — не просто «в процессе», а действующий.
• Политика управления доступом: PAM (Privileged Access Management), just-in-time доступ, запись сессий, MFA для всех инженеров.
• Процедура уведомления о инцидентах безопасности (Data Breach Notification) — сроки, формат, контакты.
• Аудит действий подрядчика: возможность самостоятельно просматривать логи доступа (SIEM, CloudTrail, аудит AD).
• Соответствие отраслевым требованиям: 152-ФЗ (персональные данные), 187-ФЗ (КИИ), PCI DSS, требования ЦБ РФ для финсектора и т.д.

5. Финансовая устойчивость и юридическая чистота

• Отсутствие массовых судов, банкротств, налоговых долгов (проверка через СБИС/Контур.Фокус/Спарк).
• Наличие страховки профессиональной ответственности (Professional Indemnity Insurance) — покрывает убытки от ошибок инженеров.
• Прозрачная структура ценообразования: фиксированная часть + переменная (проекты, выход за лимиты инцидентов, ночные/выходные окна).

6. Референзы и репутация — звоните сами

Не верьте написанным отзывам на сайте. Попросите 3–5 контактов ЛПР (лиц, принимающих решения) из проектов со схожим стеком и масштабом. Спросите по телефону (не по почте):

• Как подрядчик ведёт себя при критическом инциденте в 3 ночи?
• Есть ли ротация ключевых инженеров? Как передавали контекст?
• Как решаются споры по SLA и счетам?
• Готовы ли они рекомендовать этого подрядчика коллегам?

Процесс отбора: от длинного списка к контракту

Не ограничивайтесь одним коммерческим предложением. Структурированный процесс занимает 4–8 недель, но снижает риск ошибки в разы.

1. Подготовка базы (неделя 1): соберите актуальную CMDB (инвентарь активов), схемы сети, список критических сервисов с RTO/RPO, текущие боли и инциденты за год, требования регуляторов. Сформируйте RFI (Request for Information) — предварительный опросник для отсева заведомо не подходящих.
2. Длинный список и RFI (недели 1–2): отправьте RFI 8–12 компаниям. Критерии отсева: нет нужных сертификатов, нет опыта со стеком, финансовые проблемы, отказ дать референзы. Остаётся 4–6 кандидатов.
3. RFP / ТЗ и коммерческие предложения (недели 3–4): вышлите детальное ТЗ с обязательными разделами:Scope of Services, SLA Matrix, RACI-матрица, требования к отчётности, процедура эскалации, безопасность, процедура смены ключевых сотрудников, выход из договора. Получите коммерческие предложения с раскладкой по позициям.
4. Технические интервью и демо (недели 4–5): встречи с техническими лидерами (не продажами). Разбор 2–3 реальных инцидентов из их практики: как обнаружили, как диагностировали, как коммуницировали с клиентом, что сделали для предотвращения. Демонстрация портала, отчётов, CMDB.
5. Проверка референзов (неделя 5): самостоятельные звонки ЛПР. Зафиксируйте ответы в единой таблице.
6. Пилот / Proof of Concept (опционально, недели 6–8): если сумма договора > 5–10 млн руб/год или критичность высокая — проведите платный пилот 1–2 месяца на некритическом сегменте (тестовый кластер, dev-окружение). Оцените: скорость входа в работу, качество документации, адекватность эскалаций, прозрачность отчётности.
7. Финальная оценка и переговоры (неделя 6–8): заполните scorecard по всем критериям с весами. Переговоры по договору: SLA, штрафы, IP rights, выход из договора, лимиты ответственности, процедура замены ключевых инженеров.
8. Подписание и онбординг (первый месяц работы): передача доступов, настройка мониторинга, первичный аудит инфраструктуры (health check), согласование базовых runbook’ов, первый ежемесячный отчёт.

Что обязательно зафиксировать в договоре (помимо цены и SLA)

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

• RACI-матрица для каждого типа работ: кто Responsible, Accountable, Consulted, Informed. Исключает «я думал, это вы делаете».
• Процедура замены ключевых сотрудников: уведомление за 30 дней, право вето на замену, передача знаний за 2 недели, штраф за необоснованную ротацию.
• Exit-план (Transition Out): действия при расторжении/истечении договора: передача CMDB, конфигов, паролей (через PAM), документации, обучение вашей команды. Срок 30–90 дней. Штраф за саботаж передачи.
• Лимиты ответственности: подрядчик часто ставит cap = 100% годового контракта. Для критических рисков (утечка данных, длительный даунтайм продакшена) требуйте carve-outs — исключения из лимита.
• Аудитное право: ваше право провести аудит процессов подрядчика (или нанять третью сторону) с уведомлением за 10 дней.
• Управление изменениями: любое изменение в проде — только через RFC с вашим согласованием. Исключение — emergency changes по предопределённому списку (блокировка атаки, критический патч безопасности).
• Интеллектуальная собственность: скрипты, плейбуки, конфиги, документация, созданные в рамках договора — ваша собственность (work for hire).

Типичные ошибки заказчиков и как их избежать

Ошибка	Последствие	Как сделать правильно
Выбор только по цене (lowest bidder)	Нанимают джуниоров без сеньоров, экономят на мониторинге, игнорируют проактивку. Результат — частые инциденты, долгие восстановления.	Введите минимальный проходной балл по техническим критериям (scorecard). Цена сравнивайте только среди прошедших технический отбор.
Размытое ТЗ: «обслуживание серверов и сети»	Споры за каждый чих: обновление прошивки — это поддержка или проект? Мониторинг приложений — входит?	Декомпозируйте Scope до уровня сервисов и задач. Приложите каталог услуг (Service Catalog) с описанием каждого элемента.
SLA без штрафов или с плафоном 5–10%	Подрядчику выгоднее платить штраф, чем нанимать ночную смену или покупать резервный канал.	Штрафы должны болеть. Uncapped или поэтапные: 10% за 1 час простоя, 25% за 4 часа, 50% за 8 часов. Привяжите к бизнес-ущербу.
Нет процедуры выхода из договора	При расторжении подрядчик забирает доступы, удаляет скрипты, не передаёт пароли. Восстановление контрольности — недели.	Пропишите Exit Plan в договоре. Проводите репетицию передачи раз в год (tabletop exercise).
Полная передача ответственности без контроля	«Они профессионалы, они сами знают». Через год обнаруживаете: бэкапы не проверялись 8 месяцев, патчи не накатывались, документация отсутствует.	Назначьте внутреннего Service Delivery Manager. Еженедельные созвоны, ежемесячные QBR (Quarterly Business Review), аудит отчётов.
Игнорирование безопасности доступа подрядчика	Инженер уволился — у него остался VPN и рутовый доступ. Или подрядчик использует общий аккаунт admin/admin.	Требуйте PAM, JIT, запись сессий, MFA, регулярный пересмотр доступа (access review) раз в квартал.
Отказ от пилота «чтобы сэкономить время»	Вступаете в долгосрочный договор с вендором, который не умеет работать с вашим стеком или не вписывается в ваши процессы.	Пилот на 1–2 месяца на некритическом сегменте стоит 5–15% годового контракта, но экономит миллионы при ошибке.

Сценарии выбора: под разные условия — разные решения

Единого правильного ответа нет. Ориентируйтесь на свою ситуацию:

• Стартап / малый бизнес (до 50 сотрудников, 1–2 админа): MSP с полным покрытием, фиксированная цена, простой SLA. Приоритет — предсказуемость расходов и закрытие базовых потребностей (бэкап, антивирус, патчинг, мониторинг).
• Растущая компания (50–500 сотрудников, своя ИТ-команда 5–15 человек): Гибрид. Внутри — операционка, сервис-деск, базовое администрирование. На аутсорсе — ночные дежурства, экспертиза по стекам (K8s, БД, безопасность), проектные миграции.
• Энтерпрайз / регулируемые отрасли (финтех, медицина, КИИ): Мультивендорная модель. Базовый MSP на периметр и мониторинг + специализированные вендоры на SecOps (SOC), DBA, Backup/DR, CloudOps. Жёсткие SLA, аудиты, ISO 27001, страховка, exit-планы.
• Компания перед крупной миграцией (DC → Cloud, on-prem → Kubernetes): Проектный интегратор с экспертизой именно в этой миграции + текущий MSP на BAU. Чёткое разделение зон: интегратор отвечает за результат миграции, MSP — за доступность текущего прода.

Практический следующий шаг: чек-лист для запуска отбора завтра

Если вы приступили к выбору подрядчика прямо сейчас, начните с этих пяти действий — они дадут 80% основы для правильного решения:

1. Сформируйте актуальную CMDB (хотя бы в Excel): активы, критичность, владельцы сервисов, текущие RTO/RPO.
2. Напишите RFI (1 страница): стек, масштаб, SLA-требования, регуляторные обязательства, формат отчётов, требования к безопасности доступа. Разослайте 10 компаниям.
3. Подготовьте scorecard с весами критериев (пример: экспертиза стек — 25%, SLA/штрафы — 20%, безопасность — 15%, процессы/инструменты — 15%, референзы — 10%, цена — 15%).
4. Найдите внутреннего Service Delivery Manager — человека, который будет управлять подрядчиком, принимать работу, следить за SLA. Без этого роли договор не будет работать.
5. Заблокируйте бюджет на пилот (даже если решите не проводить — наличие опции усиливает переговорную позицию).

Часто задаваемые вопросы

Нужен ли нам MSP, если у нас есть системный администратор в штате?

Если админ один — да, ему нужна перестраховка на ночи/выходные, экспертиза по сложным стекам и проактивная работа, на которую у него нет времени. Если админов 3+ и они покрывают стек — возможно, достаточно точечного аутсорсинга (бэкап, безопасность, конкретные проекты).

Как проверить компетенцию инженера до подписания договора?

Попросите техническое интервью с лидером команды (не продажником). Дайте кейс из вашей практики: «У нас упал кластер PostgreSQL при патчинге ОС, вот логи, что делаете за первые 15 минут?». Оцените структуру мышления, вопросы к вам, знание runbook’ов.

Что делать, если подрядчик систематически нарушает SLA, но штрафы не помогают?

Штрафы — стимул, не лекарство. Эскалируйте на уровень CTO/CEO подрядчика по процедуре из договора. Требуйте Root Cause Analysis и план корректирующих действий (CAPA) с дедлайнами. Если повторяется 2–3 квартала — инициируйте процедуру расторжения по пункту «material breach», используя накопленные штрафы как компенсацию затрат на переход.

Стоит ли требовать эксклюзивность (запрет работать с конкурентами)?

В ИТ-аутсорсинге это редко работает и пугает сильных игроков. Лучше зафиксировать конфликт интересов: подрядчик не имеет права использовать знания вашей инфраструктуры для пользы конкурентов, не делегирует работу на фрилансеров без согласования, не нанимает ваших ключевых сотрудников в обход HR (non-solicitation).

Как оценить качество бэкапов и DR, если подрядчик говорит «всё настроено»?

Требуйте отчёты о тестовых восстановлениях (test restores) не реже раза в квартал: RTO/RPO фактические vs целевые, скриншоты успешного поднятия ВМ/БД на тестовом стенде. Без тестовых ресторев «настроено» = «надеемся, сработает».

Материал носит информационный характер и не заменяет консультации с юристами, специалистами по информационной безопасности и аудиторами при подготовке конкретных договоров и технических заданий. Требования регуляторов (ФСТЭК, ЦБ РФ, 152-ФЗ, 187-ФЗ, PCI DSS) могут меняться; актуальные версии нормативных актов и методических документов необходимо проверять на дату заключения договора.

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