Многие аварии в IT начинаются с обычного рабочего дня. Администратор чистит папку на сервере или правит настройку «на пять минут». Через час выясняется, что папка была на соседнем сервере, а бэкап, из которого её можно вернуть, не проверяли ни разу.
Мы собрали десять типичных ошибок системных администраторов, которые повторяются в компаниях любого размера. Для каждой разобрали, как она выглядит на практике, чем заканчивается и что сделать, чтобы она не повторилась. В конце есть чек-лист на один вечер и короткий раздел для обычных сотрудников, которые видят на экране «обратитесь к системному администратору».
Если вы только присматриваетесь к профессии, начните с обзора кто такой системный администратор и чем он занимается. Там разобрали обязанности, грейды и зарплаты.
Статья пригодится начинающим сисадминам, руководителям небольших компаний, где за весь IT отвечает один человек, и тем, кто только собирается стать системным администратором и хочет заранее знать, где спотыкаются новички.
А если хочется выучить ремесло по порядку, с практикой на стендах, загляните в подборку курсов для системных администраторов: там собраны программы от коротких интенсивов до годового обучения.
НетологияПрофессия «Системный администратор»69 100 ₽11 месяцев
GeekBrainsСистемный администратор99 500 ₽7 месяцев
Университет СинергияСистемный администратор (Бакалавриат)440 000 ₽3 года
БруноямОнлайн-курс Системный администратор65 900 ₽6 месяцев
ИПКСистемный администратор + ИИ30 450 ₽260 часов
OnSkillsСистемный администратор1 900 ₽8 недель
Почему ошибка сисадмина обходится так дорого

Ошибка бухгалтера обычно касается одного документа. Ошибка администратора касается всех, кто пользуется сервером, почтой или базой данных. Поэтому одна неверная команда превращается в простой сервиса (время, когда система недоступна пользователям) для сотен людей сразу.
Хрестоматийный пример случился 31 января 2017 года в GitLab. Инженер чинил репликацию базы данных (постоянное копирование данных с основного сервера на запасной) и удалил каталог с данными. Ошибся сервером: команда ушла на основной. Он остановил её через пару секунд, но 300 ГБ данных уже исчезли. По официальному разбору GitLab, сервис лежал около 18 часов, пропали примерно 5000 проектов, 5000 комментариев и 700 новых учётных записей.
Хуже всего в этой истории то, что резервных механизмов было несколько, и ни один не спас. Ежедневные копии не создавались из-за разницы версий программы, а письма об этой ошибке не доходили до инженеров, снимки дисков (снапшоты) для базы не были включены. Восстанавливались из копии шестичасовой давности.
Есть и юридическая цена. С 30 мая 2025 года в России действуют оборотные штрафы за повторную утечку персональных данных: от 1 до 3 % выручки компании, но не меньше 25 и не больше 500 млн рублей. Это установлено федеральным законом от 30.11.2024 № 420-ФЗ. Утечка часто начинается с открытого наружу сервера или пароля уволенного сотрудника, то есть с работы администратора.
Главный вывод. Почти все громкие аварии складываются из нескольких мелких упущений. Одна ошибка редко роняет систему, падает она тогда, когда рядом нет второй линии защиты.
Десять типичных ошибок системных администраторов
Первые пять ошибок касаются данных и доступа, их последствия труднее всего исправить задним числом. Вторые пять про то, как устроена сама работа.
Ошибка 1: бэкап, который никто не пробовал восстановить
Резервное копирование настроено, в журнале каждый день зелёная галочка, все спокойны. Но галочка значит только, что задача запустилась. Файл может оказаться пустым, повреждённым или не содержать нужной базы, как было в GitLab.
Решение: раз в месяц восстанавливать копию на отдельную машину и проверять, что данные читаются. Хорошая привычка записать, сколько заняло восстановление. Это время и есть реальный срок, на который компания встанет при аварии.
Отдельный курс по этой теме найдётся в подборке по навыку резервное копирование: там учат выстраивать схему копий и проверять восстановление на практике.
Ошибка 2: копии лежат рядом с оригиналом
Копия на том же сервере или на диске, подключённом к той же сети, защищает от случайно удалённого файла. От пожара, кражи и вируса-шифровальщика (программы, которая шифрует файлы и требует выкуп) она не защищает: шифровальщик доберётся до всех дисков, которые видит.
Американское агентство кибербезопасности CISA описывает для этого правило 3-2-1: три копии важных данных, на двух разных типах носителей, одна из них хранится вне офиса. Правило приведено в памятке CISA по резервному копированию (сайт агентства из России открывается не всегда, но само правило пересказывают почти все производители систем резервного копирования).
На практике для небольшой компании это может выглядеть так: рабочие данные на сервере, ежедневная копия на сетевом хранилище и еженедельная копия в облаке или на диске, который увозят домой. Облачную копию стоит делать неизменяемой, чтобы её нельзя было удалить учётной записью с сервера.
Ошибка 3: правки сразу на рабочем сервере
Продакшен (рабочая система, которой пользуются клиенты и сотрудники) кажется удобным местом для быстрых правок: открыл файл, поменял строчку, перезапустил. Пока всё работает, такой подход экономит время. Когда не работает, никто не помнит, что именно поменяли.
Показательный случай описан в разборе сбоя Cloudflare 2 июля 2019 года. Новое правило фильтрации трафика разослали сразу на все серверы компании по всему миру, без поэтапного развёртывания, то есть без проверки на части серверов. Правило загрузило процессоры почти до предела, и трафик упал примерно на 80 %. Сбой длился около 27 минут.
Решение: любое изменение сначала проверять на тестовой машине, затем выкатывать на один сервер из нескольких и только потом на все. И заранее знать, как откатить правку назад. Этот подход ближе к работе инженера эксплуатации, чем к классическому администрированию, но в маленькой компании роли совмещает один человек.
Ошибка 4: постоянная работа под администратором

Сидеть под учётной записью администратора домена (у неё есть права на все компьютеры и серверы в сети компании) удобно: не нужно вводить второй пароль, всё открывается сразу. Но любое открытое письмо и любой скачанный файл получают те же права. Вредоносная программа, запущенная таким пользователем, может менять что угодно во всей сети.
Правильная схема описывается принципом минимальных привилегий: у каждого пользователя и каждой программы ровно те права, которые нужны для задачи. Формулировку этого принципа можно найти в глоссарии американского института стандартов NIST.
Для администратора это значит две учётные записи: обычную для почты и документов и отдельную административную только для настройки систем. Если в компании есть специалист по защите данных, эту схему обычно вводит он. Чем занимается такой сотрудник, мы разбирали в статье про специалиста по информационной безопасности.
Ошибка 5: общие пароли и учётки уволенных
Один пароль от роутера на всех, пароль от базы в текстовом файле на рабочем столе, учётная запись бухгалтера, которая работает через год после его ухода. Такие вещи накапливаются годами и почти никогда не видны снаружи.
Решение: хранить пароли в менеджере паролей с доступом по ролям, включить двухфакторную аутентификацию (вход по паролю плюс код с телефона) везде, где она есть, и сделать блокировку учётных записей обязательным пунктом при увольнении. Сравнение программ для хранения паролей есть в нашей подборке систем хранения паролей.
Раз в квартал полезно выгрузить список активных учётных записей и сверить его со списком сотрудников. Обычно находится пара сюрпризов.
Ошибка 6: обновления откладываются «до лучших времён»
Обновление может что-то сломать, поэтому его откладывают. Через полгода на сервере висят известные уязвимости (ошибки в программах, через которые можно проникнуть в систему), и для них уже есть готовые инструменты взлома.
Список известных уязвимостей, в том числе в российском ПО, ведёт ФСТЭК в банке данных угроз безопасности информации (его коротко называют БДУ ФСТЭК). По названию программы там можно проверить, нет ли для неё свежих записей.
Решение: завести расписание. Например, обновления безопасности (патчи) ставятся раз в неделю: сначала на тестовую машину, через день на рабочие серверы. Критичные уязвимости закрываются вне очереди. С расписанием обновления ставят по привычке, без споров, стоит ли рисковать на этой неделе.
Ошибка 7: мониторинга нет или он шлёт сотню уведомлений в день
Без мониторинга (системы, которая следит за серверами и сообщает о проблемах) администратор узнаёт об аварии от пользователей. С плохо настроенным мониторингом узнаёт тоже от них: когда алертов (автоматических уведомлений о сбоях) сотни в день, их перестают читать, и важное сообщение тонет среди ложных тревог.
Решение: уведомлять только о том, что требует действия человека. Диск заполнен на 85 % и растёт, сервис не отвечает три минуты подряд, копия не создалась. Всё остальное пусть копится в отчёте, который смотрят раз в день. Бесплатные системы вроде Zabbix справляются с этим и в небольшой сети.
Ошибка 8: вся схема сети в голове одного человека

Пока администратор на месте, документация кажется лишней. Потом он уходит в отпуск или увольняется, и новый сотрудник неделю выясняет, какой сервер за что отвечает и где лежит пароль от хранилища.
Минимальный набор документов помещается на одну страницу базы знаний: схема сети, список серверов с назначением, где хранятся копии и как их восстановить, контакты подрядчиков. Правило простое: изменение не закончено, пока оно не записано.
Простой тест. Представьте, что завтра вас нет на связи неделю. Сможет ли коллега восстановить почтовый сервер по вашим записям? Если нет, документация уже нужна.
Ошибка 9: вся сеть в одном сегменте
В небольших офисах компьютеры бухгалтерии, гостевой Wi-Fi, камеры и серверы часто живут в одной сети. Если заражён один ноутбук, программа видит всё остальное.
Решение: сегментация сети, то есть разделение её на части с помощью VLAN (виртуальных сетей внутри одного физического оборудования) с открытыми между ними только нужными соединениями. Серверы отдельно, пользователи отдельно, гости и камеры отдельно. Подробнее о том, кто проектирует такие сети, мы писали в статье про сетевого инженера.
Ошибка 10: ручная рутина там, где хватит скрипта
На каждом ручном шаге можно ошибиться: создать пользователя не в той группе, забыть поменять настройку на одном из десяти серверов. Когда одно и то же действие повторяется чаще раза в неделю, его пора описать скриптом (короткой программой из команд). Автоматизация рутины убирает ошибки, которые человек делает от усталости и спешки.
Начать можно с командной оболочки bash и базовых команд Linux, их мы собрали в шпаргалке для системного администратора. Дальше идут системы управления конфигурацией вроде Ansible, которые приводят десятки серверов к одному описанному состоянию. Как устроены такие инструменты, мы разбирали на примере Chef в DevOps.
Отсюда растёт и карьера. Администраторы, которые автоматизируют свою работу, со временем переходят в DevOps-инженеры, где эта привычка становится основной задачей.
Ошибки начинающего сисадмина в первый месяц
Новичок приходит в чужую инфраструктуру, которую строили годами. Первое желание сразу исправить всё, что выглядит странно. Но от странной настройки может зависеть работа склада, и узнать об этом получится только после её удаления.
Первый месяц лучше потратить на инвентаризацию: какие есть серверы, что на них работает, где лежат копии, кто и куда имеет доступ. Любую команду, которая удаляет данные, стоит запускать только после проверки, на какой машине вы находитесь. История GitLab началась ровно с этого.
Про карьерные ошибки новичков (как выбрать первое место работы, что учить в первую очередь) мы подробно писали в материале о том, как стать системным администратором. А если впереди собеседование, пригодится разбор вопросов на собеседовании системного администратора: про резервное копирование и права доступа там спрашивают почти всегда.
Как разбирать ошибку после аварии

Авария уже случилась, сервис восстановлен. Теперь нужно сделать так, чтобы она не повторилась. Для этого пишут постмортем (письменный разбор инцидента: что произошло, почему и что меняем).
Подход хорошо описан в книге Google по надёжности сервисов. Там предлагают писать разбор после любой потери данных, заметного для пользователей простоя и случаев, когда о проблеме узнали не от мониторинга. И делать его без поиска виноватых: человек, который ошибся, лучше всех знает, как это произошло, и должен спокойно об этом рассказать.
| Раздел разбора | Что написать | Пример |
|---|---|---|
| Что случилось | Одно-два предложения для руководителя | Почта не работала 3 часа, письма не потерялись |
| Хронология | Время каждого события | 10:05 заполнился диск, 10:40 первая жалоба |
| Причины | Все, а не только последняя | Диск рос месяц, уведомление ушло в спам |
| Что меняем | Конкретные задачи с ответственным и сроком | Настроить уведомление в мессенджер до пятницы |
Культура таких разборов пришла из работы SRE-инженеров, но небольшой компании она полезна не меньше. Разбор на полстраницы, сохранённый в базе знаний, пригодится через год, когда похожая авария случится уже у нового сотрудника.
Чек-лист: проверьте свою инфраструктуру за вечер
Эти вопросы закрывают большую часть ошибок из списка выше. На каждый честный ответ «нет» стоит завести задачу.
| Вопрос | Как проверить | Тревожный признак |
|---|---|---|
| Восстанавливается ли копия | Развернуть вчерашнюю копию на отдельной машине | Последняя проверка была больше месяца назад |
| Есть ли копия вне офиса | Найти, где физически лежит третья копия | Все копии в одной сети с сервером |
| Кто администратор домена | Выгрузить список членов группы администраторов | В группе есть обычные рабочие учётки |
| Есть ли учётки уволенных | Сверить активные учётки со списком сотрудников | Учётка входила в систему после увольнения |
| Когда ставились обновления | Посмотреть дату последнего обновления на серверах | Больше трёх месяцев без обновлений |
| Кто узнаёт об аварии первым | Выключить тестовый сервис и засечь уведомление | Первыми звонят пользователи |
| Есть ли схема сети | Открыть базу знаний | Схема есть только в голове |
Если почти везде «да», инфраструктура в порядке. Если «нет» больше половины, начните с первых двух строк: копии спасают даже тогда, когда всё остальное уже сломалось.
Если на экране «обратитесь к системному администратору»
Этот раздел для обычных пользователей. Сообщение «обратитесь к системному администратору» в Windows означает, что действие запрещено настройками компьютера. Сам компьютер исправен, просто кто-то ограничил права.
Чаще всего встречаются такие варианты:
- «Недостаточно прав» или «Установка запрещена»: вы работаете под обычной учётной записью, а для действия нужны права администратора.
- «Учётная запись отключена»: её заблокировали после нескольких неверных паролей, по сроку действия или при смене должности. Включить обратно может только администратор.
- «Системный администратор ограничивает типы входа»: появляется при подключении к удалённому рабочему столу. По справке Microsoft, у учётной записи нет права входа через службу удалённых рабочих столов или его запрещает групповая политика (набор правил, который администратор рассылает на все компьютеры компании).
- «Действуют ограничения»: на компьютере включена политика, которая запрещает конкретную программу или настройку.
На рабочем компьютере это решение компании, и обходить его не стоит. Как обратиться к системному администратору, чтобы задачу решили быстрее: напишите в поддержку, приложите снимок экрана с текстом ошибки и опишите, что именно пытались сделать. Так администратор решит задачу с первого сообщения.
На домашнем компьютере такие ограничения обычно оставляют программы-«оптимизаторы» или старый антивирус. Проверьте в параметрах Windows, есть ли у вашей учётной записи права администратора. Если нет, войдите под той, что создавалась первой при установке системы.
Совет пользователю. Хорошее обращение в поддержку содержит текст ошибки, время, когда она появилась, и то, что вы делали перед этим. Такое письмо экономит обеим сторонам полдня переписки.
Где научиться администрированию на учебных стендах
Почти все ошибки из этой статьи можно один раз совершить на учебном стенде вместо рабочего сервера. Хорошие курсы системного администрирования дают именно это: виртуальные машины, на которых можно удалить базу, восстановить её из копии и настроить мониторинг, ничего не сломав в реальной компании.
При выборе программы смотрите на долю практики, наличие стендов и темы, которые разбирают: резервное копирование, права доступа, работа с Linux и Windows Server, мониторинг. Ниже собрали онлайн-курсы для системных администраторов с отзывами и ценами.
| Курс | Школа | Стоимость со скидкой | В рассрочку | Длительность | Обзор курса от Checkroi |
|---|---|---|---|---|---|
| Профессия «Системный администратор» Перейти на сайт курса | 69 100 ₽ | 5125 ₽/мес. | 11 месяцев | Обзор курса | |
| Системный администратор Перейти на сайт курса | 99 500 ₽ | 2764 ₽/мес. | 7 месяцев | Обзор курса | |
| Системный администратор (Бакалавриат) Перейти на сайт курса | 440 000 ₽ | - | 3 года | Обзор курса | |
| Онлайн-курс Системный администратор Перейти на сайт курса | 65 900 ₽ | 5491 ₽/мес. | 6 месяцев | Обзор курса | |
| Системный администратор + ИИ Перейти на сайт курса | 30 450 ₽ | 3171 ₽/мес. | 260 часов | Обзор курса | |
| Системный администратор Перейти на сайт курса | 1900 ₽ | 475 ₽/мес. | 8 недель | Обзор курса | |
| Системный администратор linux - курс переподготовки Перейти на сайт курса | 32 980 ₽ | 2748 ₽/мес. | 400 часов | Обзор курса | |
| Системный администратор windows - курс переподготовки Перейти на сайт курса | 32 980 ₽ | 2748 ₽/мес. | 400 часов | Обзор курса | |
| Системный администратор Перейти на сайт курса | 36 400 ₽ | 2100 ₽/мес. | 504 часа | Обзор курса | |
| Системный администратор Перейти на сайт курса | 115 500 ₽ | 4531 ₽/мес. | 6 месяцев | Обзор курса |
Больше программ — в полном каталоге курсов для системных администраторов
Если вам ближе работа с серверами на Linux, посмотрите обзор профессии администратора Linux и подборку курсов по администрированию Linux. А про деньги в профессии мы подробно писали в статье о том, сколько зарабатывает системный администратор.




