Десять задач системного администратора, которые я больше не выполняю вручную
Краткая аннотация: Ручная установка программ, проверка свободного места и создание учётных записей кажутся мелочами, пока в офисе не появляется сотня компьютеров. Рассказываю, какие операции я автоматизировал, как устроил контроль ошибок и почему хороший скрипт не всегда означает хорошую автоматизацию.
В небольшом офисе ручное администрирование долго выглядит вполне разумно. Можно лично установить программу, зайти на компьютер по удалённому доступу, проверить обновления и создать новому сотруднику учётную запись. На одну операцию уходит несколько минут, поэтому автоматизация кажется лишней сложностью.
Проблема начинается не на первом компьютере, а примерно на пятидесятом. Одно и то же действие приходится повторять десятки раз, результаты нигде нормально не фиксируются, а конфигурации постепенно расходятся. На одном ноутбуке старая версия клиента VPN, на другом отключён BitLocker, на третьем пользователь получил локальные права администратора, потому что полгода назад так было проще.
В какой-то момент я перестал считать ручное выполнение признаком контроля. Настоящий контроль появляется тогда, когда операция воспроизводима, её результат записан в журнал, а отклонения видны без обхода всех рабочих мест.
Развёртывание компьютеров без ритуального флеш-накопителя
Раньше подготовка нового ноутбука занимала у меня до половины рабочего дня. Нужно было установить Windows, драйверы, браузер, офисный пакет, архиватор, VPN-клиент, средства удалённой поддержки и сертификаты. Затем следовали обновления, настройка политик и проверка шифрования.
Самое неприятное состояло не во времени. Два ноутбука, подготовленные вручную с интервалом в неделю, почти всегда немного отличались. На одном забывался параметр электропитания, на другом оставалась лишняя программа производителя, на третьем не применялась нужная политика.
Теперь вручную я не выполняю следующие задачи:
- не устанавливаю операционную систему по индивидуальному сценарию;
- не ставлю базовый набор программ по одной;
- не настраиваю одинаковые параметры локально на каждом устройстве;
- не сверяю вручную наличие антивируса, шифрования и актуальной версии системы.
Для Windows-среды логика строится вокруг профиля устройства. Новый компьютер регистрируется в системе управления, связывается с пользователем и получает конфигурацию после первого подключения. Windows Autopilot предназначен именно для предварительной подготовки и развёртывания устройств без традиционного создания отдельного образа под каждую модель.
Я разделил конфигурацию на несколько уровней. Сначала применяются требования безопасности: шифрование диска, пароль, блокировка экрана и параметры защитника. Затем устанавливается обязательное программное обеспечение. В последнюю очередь добавляются приложения, зависящие от отдела.
Бухгалтеру не нужен клиент для подключения к тестовой инфраструктуре, а разработчику не стоит автоматически устанавливать тяжёлое программное обеспечение, которым пользуется отдел дизайна. Универсальный образ на все случаи жизни быстро превращается в склад лишних пакетов.
Отдельно проверяется соответствие устройства требованиям. Система управления может оценивать версию ОС, состояние защиты и другие параметры, после чего помечать компьютер как соответствующий или не соответствующий политике.
Но автоматизированное развёртывание не означает, что ноутбук можно сразу отдать сотруднику. У меня остаётся короткая контрольная проверка: вход пользователя, доступ к корпоративным ресурсам, применение политик, работа VPN и наличие ключей восстановления. Просто теперь эта проверка занимает минуты, а не половину дня.
Обновления, инвентаризация и очистка без обхода кабинетов
Вторая группа задач раньше съедала время небольшими порциями. Кто-то сообщал, что приложение давно просит обновиться. Где-то заканчивалось место на диске. На одном компьютере обнаруживалась программа, о которой никто из ИТ не знал.
Именно такие мелочи создают большую часть технического долга.
Я перестал вручную:
- обновлять одинаковые приложения на каждом компьютере;
- собирать сведения о версиях программ через удалённое подключение;
- проверять свободное место на системных дисках;
- искать выключенные службы и неактивные агенты мониторинга.
Для локальной проверки Windows-компьютера достаточно PowerShell. Например, такой фрагмент собирает базовое состояние системы и возвращает структурированный объект, который можно отправить в журнал, API или систему мониторинга:
$systemDrive = Get-CimInstance Win32_LogicalDisk `
-Filter «DeviceID=’C:’»
$os = Get-CimInstance Win32_OperatingSystem
$servicesToCheck = @(
«WinDefend»,
«wuauserv»
)
$serviceState = foreach ($serviceName in $servicesToCheck) {
$service = Get-Service -Name $serviceName -ErrorAction SilentlyContinue
[PSCustomObject]@{
Name = $serviceName
Exists = $null -ne $service
Status = if ($service) { $service.Status.ToString() } else { «Missing» }
}
}
$result = [PSCustomObject]@{
ComputerName = $env:COMPUTERNAME
LoggedOnUser = $env:USERNAME
OSVersion = $os.Version
LastBootTime = $os.LastBootUpTime
FreeDiskGB = [math]::Round($systemDrive.FreeSpace / 1GB, 2)
TotalDiskGB = [math]::Round($systemDrive.Size / 1GB, 2)
FreeDiskPercent = [math]::Round(
($systemDrive.FreeSpace / $systemDrive.Size) * 100,
2
)
Services = $serviceState
CollectedAt = Get-Date -Format «yyyy-MM-ddTHH:mm:ssK»
}
$result | ConvertTo-Json -Depth 4
Сам по себе этот скрипт почти бесполезен. Он становится частью автоматизации только после появления централизованного запуска, расписания, хранилища результатов и правил реакции.
Если свободного места меньше 15 процентов, создаётся предупреждение. Если защитная служба остановлена, событие получает высокий приоритет. Если компьютер не отправлял данные несколько дней, я сначала проверяю связь и состояние агента, а не делаю вывод, что устройство исправно.
С обновлениями приложений действует тот же принцип. Windows Package Manager умеет находить, устанавливать и обновлять приложения, а команда winget upgrade —all пытается обновить все пакеты, для которых доступны новые версии.
Но запускать её без контроля на всех рабочих местах я бы не стал. Некоторые приложения требуют закрытия процессов, перезагрузки или проверки совместимости с корпоративными расширениями. Поэтому обновления делятся на кольца: сначала тестовая группа, затем несколько обычных рабочих мест и только после этого весь парк.
Автоматизация без поэтапного развёртывания просто позволяет быстрее распространить ошибку.
Для Linux-серверов и смешанной инфраструктуры я использую декларативный подход. В Ansible описывается не последовательность кликов, а требуемое состояние: пакет установлен, служба запущена, конфигурационный файл имеет нужное содержимое. Playbook можно повторно применять к группе узлов, не выполняя вручную одну и ту же процедуру на каждом сервере.
Простейший пример выглядит так:
—-
- name: Configure monitoring agent
hosts: linux_servers
become: true
tasks:
- name: Ensure monitoring package is installed
ansible.builtin.package:
name: zabbix-agent2
state: present
- name: Deploy agent configuration
ansible.builtin.template:
src: zabbix_agent2.conf.j2
dest: /etc/zabbix/zabbix_agent2.conf
owner: root
group: root
mode: «0644»
notify: Restart monitoring agent
- name: Ensure agent is enabled and running
ansible.builtin.service:
name: zabbix-agent2
enabled: true
state: started
handlers:
- name: Restart monitoring agent
ansible.builtin.service:
name: zabbix-agent2
state: restarted
Если конфигурация уже соответствует описанию, повторный запуск не должен бессмысленно перезапускать всё подряд. Для меня это один из главных признаков нормальной автоматизации: повторяемость без побочных эффектов.
Учётные записи я создаю не скриптом, а процессом
Десятая задача — создание и удаление учётных записей. Формально она автоматизируется несколькими командами. Практически это одна из самых опасных областей, потому что ошибка затрагивает доступ к почте, файлам, внутренним системам и данным клиентов.
Раньше заявка на нового сотрудника приходила обычным письмом. В ней могли забыть отдел, руководителя, дату выхода или перечень нужных ресурсов. Администратор начинал задавать вопросы, кадровик уточнял у руководителя, а в первый рабочий день выяснялось, что доступ к половине систем не готов.
Теперь исходной точкой служит структурированная заявка. В ней есть имя, подразделение, должность, руководитель, дата начала работы и профиль доступа. После согласования создаётся учётная запись, назначаются базовые лицензии и применяются группы, связанные с ролью.
Здесь я сознательно не выдаю права через длинный набор условий внутри одного скрипта. Доступ привязан к группам и ролям. Сотрудник отдела продаж получает стандартный профиль отдела продаж, а исключения оформляются отдельно.
Удаление пользователя построено строже, чем создание. Сначала блокируется вход, завершаются активные сеансы и отзываются токены. Затем меняются владельцы рабочих файлов, настраивается доступ к почте, удаляются назначения лицензий и только после хранения в течение установленного срока удаляется сама запись.
Главная сложность здесь не в PowerShell или API. Она в том, чтобы определить владельца каждого шага и не позволить автоматизации удалить данные раньше, чем бизнес подтвердит их передачу.
Поэтому критические операции работают по принципу подготовить, проверить, выполнить. Сценарий сначала показывает, какие изменения будут сделаны. Только после подтверждения запускается фактическое отключение.
И да, однажды тестовый сценарий попытался отключить мою собственную учётную запись. Именно после этого у меня появилось правило: административные аккаунты, сервисные записи и аварийный доступ исключаются не по названию, а отдельным защищённым признаком.
Автоматизация не освобождает от администрирования
За несколько лет я перестал вручную устанавливать систему, раскладывать приложения, проверять соответствие политике, обновлять типовые программы, собирать инвентаризацию, контролировать диски, проверять службы, настраивать одинаковые серверы, создавать пользователей и выполнять их увольнение по памяти.
Но работы меньше не стало. Она просто переместилась на другой уровень.
Теперь больше времени уходит на тестирование, описание состояний, обработку исключений, контроль прав и разбор неудачных запусков. Вместо ста одинаковых действий я один раз проектирую процесс и затем слежу, чтобы он выполнялся предсказуемо.
Я считаю задачу готовой к автоматизации, когда у неё есть однозначные входные данные, проверяемый результат и безопасный способ отката. Когда хотя бы одного элемента нет, скрипт лишь маскирует хаос.
Хорошая автоматизация незаметна. Пользователь получает настроенный компьютер, нужные программы и доступы, а системный администратор узнаёт о проблеме из журнала раньше, чем раздаётся звонок. Именно ради этого я и перестал делать руками то, что машина способна повторить точнее.