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, считайте его скомпрометированным и меняйте пароль или ключ, даже если файл потом удалили из репозитория.