Советы и рекомендации по IT-технологиям

Проблема: аутсорсинг обещает золотые горы, а приносит головную боль
Компания среднего бизнеса (40 сотрудников, два офиса) решила оптимизировать IT-поддержку. Текущий сисадмин работал "на доверии", документации не было, бэкапы хранились на том же сервере, что и базы 1С. Руководитель нашел аутсорсинговую компанию через рекомендацию коллеги. Устно договорились о "полном сопровождении", подписали типовой договор на три листа. Через месяц произошел сбой RAID-массива. Аутсорсер отказался восстанавливать данные бесплатно, сославшись на то, что "устранение последствий аварий" не входит в базовый пакет. Восстановление обошлось в 180 000 рублей сверх ежемесячной платы.
Кейс типичен. Заказчик не проверил, что скрывается за фразой "полное сопровождение". Подрядчик не закрепил процедуры и ответственность в договоре. В результате — потеря денег, данных и трех недель простоя бухгалтерии.
Шаг 1: отличите маркетинговые гарантии от реальных обязательств
Каждый IT-подрядчик обещает "высокое качество", "SLA 99.9%" и "24/7 мониторинг". Реальность: типовые договоры часто содержат формулировки, которые сводят эти обещания на нет. Вы получите гарантию только того, что явно прописано в документах.
Проверьте три критических пункта: время реакции на инцидент, состав включенных работ (мониторинг vs восстановление), границы ответственности. Если в договоре написано "устанавливаем обновления", но не указано "проверяем совместимость с вашим ПО" — в случае сбоя 1С после обновления Windows подрядчик снимет с себя ответственность.
Шаг 2: SLA — главный инструмент защиты
SLA (Service Level Agreement) — это не просто таблица с процентами. Это документ, который решает, заплатите вы за восстановление или нет. Требуйте от потенциального подрядчика не устного описания, а приложения к договору с конкретными параметрами.
- Время реакции: должна быть указана градация по критичности (Critical, High, Low). Для критичных сбоев (упал сервер, вирусная атака) — не более 1 часа с момента заявки.
- Время решения: сроки устранения неисправности для каждого типа проблемы. Для критичных — до 4 рабочих часов, для низкоприоритетных (запросить права для нового сотрудника) — до 24 часов.
- Режим работы: 8/5, 12/5 или 24/7. Если вам нужна поддержка в выходные — убедитесь, что в SLA это прописано, иначе подрядчик выставит двойной тариф.
- Процент недоступности сервиса: если подрядчик гарантирует uptime 99.9%, пропишите, как компенсируется нарушение (обычно — скидка на следующий месяц).
- Порядок эскалации: кто решает проблему, если на первой линии ее не устранили за час? Должна быть процедура подключения старшего инженера.
- Исключения: что не считается сбоем (плановые работы, форс-мажор, действия третьих лиц). Изучите этот пункт особенно внимательно.
Шаг 3: пропишите границы ответственности и санкции
Даже с хорошим SLA подрядчик может допустить ошибку. Главный риск — повреждение или потеря ваших данных. В договоре должно быть четко указано, кто отвечает за сохранность информации и в каком объеме компания возмещает ущерб.
- Размер ответственности: часто ограничивают суммой месячной оплаты. Для критичных задач (управление серверами, базы 1С) требуйте лимит не менее 3-6 месячных платежей или фиксированной суммы.
- Штрафы за нарушение SLA: не просто слова. Пропишите, что за пропуск времени реакции подрядчик платит 10% от месячной стоимости за каждые полчаса. За полную потерю данных — возмещение стоимости восстановления или фиксированную сумму.
- Ответственность за данные: текстовое заверение, что подрядчик не копирует, не использует и не передает ваши данные третьим лицам. В идеале — подписать NDA (соглашение о неразглашении).
- Страховка: проверьте, застрахована ли профессиональная ответственность IT-компании. Если да — запросите копию полиса. Это реальная защита, а не пустое обещание.
Шаг 4: проверьте реальную квалификацию команды
Личный опыт и сертификаты на сайте — не одно и то же. Попросите составить список сотрудников, которые будут работать с вашим проектом. Узнайте их опыт: сколько лет, какие типовые проекты вели, есть ли сертификации (Microsoft, VMware, 1С).
- Запросите контакты 2-3 текущих клиентов из смежных отраслей. Позвоните им. Спросите не "все ли хорошо", а "какие были проблемы и как их решили". Люди охотно жалуются на плохое.
- Проведите тестовый сценарий. Заведите фиктивную заявку на нерабочий принтер или почту. Засеките время отклика и качество взаимодействия. Если на этапе продаж отвечают за час, а в работе — за день — бегите.
- Проверьте документацию. Хороший подрядчик предоставляет журнал изменений, отчеты по мониторингу, резервным копиям, доступности серверов. Если после начала работы доков нет — вас не сопровождают, а просто "пасут".
- Узнайте, кто приедет в случае аварии. Если инженер будет из другого города с выездом на следующий день — это риск. Лучше, когда команда находится в радиусе 1-2 часов езды.
Шаг 5: заключите договор с четкими границами работ
Типовой пакет "все включено" — ловушка. Вам нужен четкий перечень: что входит, что не входит, что требует доплаты. Например, проектные работы — настройка нового сервера, миграция на облако, оптимизация Active Directory — часто выносятся за скобки с почасовой оплатой.
Что должно быть описано в договоре (проверочный лист):
- Перечень обслуживаемого оборудования и систем (инвентаризация).
- Частота и состав планового обслуживания (чистка пыли, проверка дисков, обновление прошивок).
- Процедура бэкапа: что бекапится, куда, как часто, как долго хранятся копии, как проверяется восстановление (хотя бы раз в квартал).
- Порядок внесения изменений (заявка → согласование → тестирование → внедрение).
- Процедура расторжения: как передаются данные, как забираются пароли и документация, сколько времени на передачу дел новому подрядчику.
Результат: предсказуемый бюджет и работающий IT
После описанного выше кейса компания пересмотрела подход. Новый подрядчик был выбран с использованием этого чек-листа. Договор содержал 7 страниц приложений: инвентаризация, SLA с 5 уровнями, ответственность до 300 000 рублей, график тестовых восстановлений из бэкапов. На втором месяце сотрудничества произошла атака шифровальщика. Подрядчик автоматически поднял сервера из облачной реплики за 3 часа. Данные не пострадали. Штрафные санкции не применялись, компания потеряла только несколько часов работы. Через год ежемесячная плата осталась фиксированной, непредвиденных расходов не было.
Главный вывод: гарантии — это не слова про качество, а конкретные цифры, процессы и финансовые обязательства, записанные в договоре. Риски минимизируются, когда вы платите не за обещания, а за проверенные процедуры.
Добавлено: 07.05.2026
