01.08.2026

Нет штатного админа: как не потерять серверы и бэкапы

Linux/Windows без постоянного присмотра — риск простоя. Что входит в аутсорсинг администрирования с SLA.

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

Для компаний на 20–150 человек это типичная картина: IT не core-бизнес, полноценный админ в штате «дорого и непонятно чем занять», а подрядчик «настроил когда-то» и пропал. Риск не в том, что серверы плохие. Риск в том, что за ними никто не смотрит по регламенту — с мониторингом, патчами, проверкой бэкапов и понятным временем реакции.

Директору важно понимать простую арифметику. Стоимость дня простоя бухгалтерии, склада или интернет-витрины часто сопоставима с месяцами нормального сопровождения. Вопрос не «дорого ли платить за администрирование», а «сколько стоит узнать о проблеме от сотрудников, когда продажи уже встали».

Как это обычно ломается на практике

Первый сценарий — тихая деградация. Диск забит на 95%, swap растёт, обновления Windows или Linux откладывают «потому что страшно». Никто не видит симптомы, пока бухгалтерия не сообщает, что 1С «висит». К этому моменту простой уже измеряется часами закрытия периода и сорванными отгрузками.

Второй — ложные бэкапы. Задача в планировщике зелёная, папка на NAS заполняется. При аварии выясняется: бэкап битый, неполный, без логов приложения или восстанавливать некуда. «Мы думали, что копируется» — фраза, после которой спорят уже про убытки и ответственность, а не только про «кто админ».

Третий — зависимость от одного человека. Пароли в Excel, VPN «у Васи», документация отсутствует. Вася заболел или ушёл — доступ к инфраструктуре превращается в квест. Пока ищут, кто помнит IP шлюза, бизнес стоит. Четвёртый — «временный» RDP или проброс порта, который живёт годами и ждёт брутфорса.

Ошибки, которые кажутся экономией

Откладывать security-патчи месяцами — понятный страх после истории «обновили и всё упало». Но вечный отказ от обновлений лишь копит уязвимости. Правильный ответ — окно работ, снимок виртуальной машины и план отката, а не стратегия «никогда».

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

Четвёртая — смешивать зоны ответственности. Подрядчик «вроде за серверы», разработчик «вроде за сайт», никто — за мониторинг сертификатов. В момент аварии начинается футбол.

Что должно быть в нормальном контуре

Аутсорсинг администрирования — не «удалённый Вася», а измеримый сервис. На практике для среднего бизнеса обычно нужны шесть опор.

Инвентаризация. Список серверов, ролей, версий ОС, схема сети, кто владелец сервиса. Без этого любой инцидент начинается с раскопок и звонков «а это чьё?».

Мониторинг с алертами людям. Не красивая панель «для инженеров», а сообщения в рабочий канал до звонков пользователей: диск, нагрузка, недоступность 1С, сайта и почты, срок SSL, статус задач резервного копирования.

Регламент патчей. Критичные — в согласованное окно за 7–14 дней; остальное — по плану. Со снимком и возможностью отката. Страх обновлений лечится процедурой, а не запретом.

Бэкапы с проверкой восстановления. Успешный job — мало. Нужен периодический восстановление на тестовый контур и фиксация целевого времени восстановления в понятных цифрах для руководителя.

Реакция по приоритетам. Когда бизнес стоит — минуты до первого ответа; плановое изменение — дни. Без градации всё становится «срочно» и ничего не делается вовремя.

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

РискЧто видно на местахЦена для бизнеса
Нет патчейУязвимости месяцамиВзлом, простой
Бэкапы «для галочки»Восстановление не тестировалиПотеря данных
Нет мониторингаДиск 98%, никто не знаетНочной простой
Один человекПароли «в голове»Нет доступа в кризис
Нет SLA«Когда освобожусь»Часы и дни простоя

Как отличить сервис от «иногда помогаем»

Спросите три вещи. Что входит в ежемесячный регламент, а что — отдельные проекты? Какое время первого ответа на недоступность 1С в рабочее и нерабочее время? Когда в последний раз проверяли восстановление из бэкапа?

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

Что получает бизнес на выходе

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

Для директора метрика простая: сколько стоит день без 1С, сайта или почты — и покрывает ли договор этот риск. Часто годовая стоимость нормального сопровождения меньше одного серьёзного инцидента без присмотра.

С чего начать, если админа уже нет

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

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

Начать разговор

Нужна помощь с похожей задачей?

Опишите ситуацию — предложим решение на основе нашего опыта.