Git для внутренних скриптов и автоматизаций: как малому IT-отделу не терять наработки при смене сисадмина

Три года назад у одного нашего клиента уволился системный администратор. Просто взял и ушёл, за две недели. А вместе с ним — весь архив скриптов автоматизации, которые он писал под их 1С-инфраструктуру пять лет. Я тогда понял: мы, айтишники, обожаем рассказывать бизнесу про бэкапы баз данных и резервное копирование серверов, а собственные скрипты храним в папке на рабочем столе. Как повар, который бережёт рецепты ресторана, но забывает записать свой собственный.

Почему скрипты остаются бесхозными

Вот смешная штука. Мы внедряем клиентам версионирование конфигов, объясняем важность истории изменений в 1С, ставим Git для разработчиков заказной автоматизации. А свои же рабочие скрипты — те самые .ps1 и .sh файлы, которыми настраивается DHCP, разворачивается GPO, чистятся логи на терминальном сервере — держим где придётся. На флешке. В облаке одного человека. В переписке в Telegram, если совсем стыдно признаться.

Причина проста: скрипт админа рождается не как проект, а как затычка. Нужно срочно почистить temp-папки на тридцати рабочих станциях — написал, запустил, забыл. Через полгода нужно то же самое, только уже на новом клиенте. Начинаешь вспоминать, было же что-то похожее... И либо пишешь заново, либо два часа роешься в переписке с коллегой недельной давности.

У нас в компании обслуживания малого бизнеса таких скриптов сотни. Развёртывание принтеров через GPO, автоматическая ротация паролей локальных админов, мониторинг свободного места на дисках терминальных серверов, скрипты бэкапа для тех клиентов, у кого нет Veeam. И каждый живёт своей жизнью, в голове у того, кто его писал.

История с уволившимся сисадмином

Расскажу подробнее про тот случай, раз уж начал. Клиент — торговая компания, 35 рабочих мест, серверная на площадке плюс аренда 1С в облаке. Штатный админ (в найме у клиента, не наш сотрудник) настроил у себя целую систему: скрипт синхронизации справочников между базами, автоматическую выгрузку отчётов в бухгалтерию по расписанию, мониторинг лицензий КриптоПро на истечение срока. Всё работало годами, никто не жаловался.

Когда он уволился, выяснилось: скрипты лежали на его личном ноутбуке. На сервере — только скомпилированные задачи в планировщике, без исходников, без комментариев, без версий. Планировщик Windows, если кто не знает, прекрасно исполняет .ps1 файл, но абсолютно не хранит его историю. Файл лежит там, где лежит, и если его удалить — всё, привет.

Нас позвали чинить. Два месяца ушло на то, чтобы восстановить логику работы через анализ логов, реверс-инжиниринг оставшихся файлов и разговоры с бухгалтерией — что именно должно происходить и когда. Клиент заплатил за эти два месяца в разы больше, чем стоило бы поставить простой git-репозиторий с самого начала. Вот и вся арифметика.

GPO — тоже код, просто вы об этом не думали

Отдельная боль — групповые политики. Администраторы почему-то не воспринимают GPO как код, хотя по сути это конфигурация, которая управляет поведением сотни компьютеров разом. Если политика сломалась после правки, откатить её обратно — то ещё удовольствие, потому что штатного diff между версиями в Group Policy Management Console просто нет.

В Windows Server есть встроенный бэкап GPO через Backup-GPO в PowerShell, и это уже неплохо. Но бэкап — не версионирование. Бэкап отвечает на вопрос «что было вчера», а Git отвечает ещё и на вопрос «кто это менял, зачем и что именно изменилось построчно». Когда у клиента резко перестаёт печатать половина офиса, а вы за пять минут должны понять, какая правка политики принтеров всё сломала — разница между этими двумя подходами становится очень ощутимой.

Мы для одного клиента (юридическая фирма, 22 рабочих места) настроили экспорт всех GPO в XML раз в сутки через задачу в планировщике, с автоматическим коммитом в локальный Git-репозиторий на сервере. Заняло это полдня работы одного нашего специалиста. Зато теперь если политика блокировки USB-накопителей вдруг перестаёт работать после чьей-то правки — открываем git log, смотрим diff, находим виновника за минуту вместо часа гадания.

Как устроить версионирование, если вы не разработчик

Не нужно пугаться слова Git. Для внутренней автоматизации хватает самого простого сценария: локальный репозиторий на файловом сервере или в облаке (Gitea, GitLab CE, да хоть приватный репозиторий на бесплатном тарифе GitHub — для скриптов админа этого более чем достаточно). Ставится Gitea на Linux-сервер за десять минут, ресурсов требует минимум, я такое разворачивал на VPS с одним ядром и гигабайтом памяти.

Структура простая: одна папка — один клиент или одна система. Внутри — подпапки по назначению: gpo-backups, scheduled-tasks, monitoring, deploy. В каждом .ps1 или .sh файле в шапке — краткий комментарий: что делает скрипт, для чего, дата последней проверки. Не поэма, а три строки. Этого достаточно, чтобы через год не гадать, зачем существует файл clean-temp-v3-final-ИСПРАВЛЕННЫЙ.ps1.

Коммитить нужно не раз в квартал, а сразу после каждого осмысленного изменения. Написал новую версию скрипта ротации логов — закоммитил с понятным сообщением, не 'fix', а 'добавлена проверка свободного места перед архивацией логов IIS'. Звучит как занудство, но именно эта привычка спасает, когда через восемь месяцев скрипт вдруг перестаёт работать после обновления Windows, и нужно быстро понять, что менялось за последний год.

Что делать с секретами и паролями в скриптах

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

Решение простое и давно придуманное: секреты выносятся в отдельный файл конфигурации (например .env или config.local.ps1), который добавляется в .gitignore и никогда не попадает в репозиторий. Сам скрипт читает переменные оттуда. Для Windows-окружения удобно использовать Credential Manager или зашифрованные строки через ConvertTo-SecureString с ключом на конкретной машине — тогда даже если файл конфигурации утечёт, толку от него без ключа не будет.

У нас как-то был неприятный урок: молодой специалист без опыта закоммитил в тестовый репозиторий скрипт с паролем от учётной записи службы прямо в коде. Репозиторий был приватный, утечки не случилось, но пароль пришлось менять по всем правилам — раз попал в историю Git, считай, скомпрометирован. С тех пор у нас жёсткое правило: секретов в коде быть не должно, точка, без исключений и без 'ну это же только для теста'.

Передача дел новому сотруднику становится формальностью

Возвращаясь к главной теме — смене сисадмина. Когда вся автоматизация лежит в git-репозитории с внятной историей коммитов, передача дел превращается из недельного стресса в документированную процедуру. Новый специалист клонирует репозиторий, читает README (если вы его вели, а вести стоит), смотрит историю изменений последних месяцев — и через день-два понимает логику работы предшественника без единого звонка ему на мобильный.

Мы теперь в договор на обслуживание малого бизнеса включаем отдельным пунктом требование: вся автоматизация, написанная для клиента, версионируется в репозитории, доступ к которому имеет и клиент, и мы как подрядчик. Это защищает обе стороны. Клиента — от ситуации, когда единственный носитель знаний увольняется и уносит их с собой. Нас — от репутационных потерь, когда клиент через год спрашивает 'а что вообще эти скрипты делают', а ответить некому.

Кстати, это работает и в обратную сторону, при смене подрядчика. Если вы отдаёте IT-обслуживание другой компании, и у прежнего подрядчика вся автоматизация была в git-репозитории с внятной историей — передача занимает день. Если всё держалось в голове одного человека — будьте готовы, что новый подрядчик часть систем будет настраивать заново, а вы будете за это платить.

С чего начать, если сейчас у вас хаос

Не пытайтесь навести порядок во всём сразу, это гарантированный способ забросить затею на второй день. Начните с одного сервера, самого критичного. Соберите все .ps1 и .bat файлы из планировщика заданий в одну папку, добавьте в свежий git-репозиторий, сделайте первый коммит с пометкой 'первичный импорт, состояние на такое-то число'. Уже на этом шаге вы получите точку отсчёта, от которой можно двигаться дальше.

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

Частые вопросы

Обязательно ли ставить полноценный GitLab или GitHub Enterprise для скриптов небольшой компании?
Нет, это избыточно для отдела из одного-двух администраторов. Достаточно Gitea или Gitea-подобного лёгкого сервера на существующей виртуалке, либо бесплатного приватного репозитория на GitHub или GitLab.com. Задача — иметь историю изменений и единую точку хранения, а не строить корпоративную DevOps-платформу.

Как быть с GPO, если организация небольшая и штатного администратора GPO нет?
Настройте простую задачу в планировщике на контроллере домена: раз в сутки экспортировать все политики в XML через Backup-GPO и коммитить результат в локальный репозиторий. Это делается один раз силами подрядчика или штатного айтишника и потом работает без вмешательства человека годами.

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

Как защитить пароли и API-ключи, которые уже вписаны прямо в тело старых скриптов?
Перед первым коммитом в репозиторий обязательно вынесите все секреты в отдельные конфигурационные файлы и добавьте их в .gitignore. Если секрет уже случайно попал в историю Git, считайте его скомпрометированным и меняйте пароль или ключ, даже если файл потом удалили из репозитория.