Резервное копирование конфигов в Git: Oxidized/RANCID и ревью

Задача: сохранить конфиги и видеть, кто и что поменял

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

Резервное копирование конфигов в Git закрывает сразу две задачи: у вас остается копия «как было», и появляется история «кто, когда и что именно поменял». Git удобен тем, что показывает разницу построчно (diff). Это нагляднее, чем архивы с датами или папка «final_final2».

Обычно в бэкап попадают конфиги коммутаторов доступа и ядра, маршрутизаторов, межсетевых экранов, балансировщиков, контроллеров Wi‑Fi. Форматы у всех разные, но цель одна: регулярно забирать текущий running-config (или эквивалент) и складывать его в репозиторий так, чтобы изменения читались человеческими глазами.

Если продумать процесс заранее, аудит будет реальным, а не формальным. Сразу определите три вещи: как вырезаете секреты, кто имеет доступ к репозиторию, и кто отвечает за разбор неожиданных diff (и подтверждает, что «это было запланировано»).

Минимальный полезный старт выглядит просто: ежедневный автоматический сбор конфигов, единый репозиторий и понятная история изменений. Тогда при спорной правке можно быстро увидеть, что поменялось, и уверенно откатиться к последней рабочей версии.

Oxidized и RANCID: что выбрать и почему

Если цель - резервное копирование конфигов в Git с читаемой историей изменений, оба инструмента решают одну задачу: регулярно забирать конфиги с устройств и приводить их к виду, удобному для diff.

Oxidized часто выбирают за простоту и «живую» модель опроса. Он хорошо работает с Git как с бэкендом и позволяет опрашивать устройства часто (например, каждые 5-15 минут). Это удобно там, где изменения происходят в течение дня и важно быстро увидеть, что именно поменялось.

RANCID - классический подход «раз в день собрали, закоммитили, получили историю». Он хорошо подходит, если изменения редкие, а сбор нужен в основном для контроля и восстановления.

Ограничения обычно упираются не в Git, а в поддержку вендоров и стабильность вывода. На практике diff «шумит» из-за строк со временем, счетчиками, аптаймом или случайным порядком блоков. Еще одна типичная проблема: на одних устройствах команда show/run отдает полный конфиг, на других - только часть. Это лучше проверять на пилоте.

Выбор чаще всего зависит от режима работы:

• До сотен устройств и редкие изменения - обычно хватает RANCID с ежедневным сбором.
• Много изменений и нужна быстрая фиксация - чаще удобнее Oxidized с частым опросом.
• Смешанный парк и разные требования к частоте - разумно разделить политики: критичные устройства собирать чаще, остальные - по расписанию.

Если сетевое ядро в дата-центре меняют по заявкам пару раз в месяц, RANCID будет «тихо» работать годами. Если команда часто правит ACL и NAT на периметре, Oxidized быстрее покажет неожиданный коммит и упростит разбор инцидента.

Архитектура: где живет сборщик, где Git и как подключаться

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

Git можно держать как отдельный сервис или использовать внутренний GitLab/Bitbucket/DevOps, если он уже принят в компании. Важно, чтобы репозиторий был доступен сборщику по стабильному каналу, а в нем работали права на ветки и ревью.

Сборщик (Oxidized или RANCID) лучше запускать не на рабочей станции администратора, а на отдельном хосте: VM, выделенный сервер или контейнер. Так проще обновлять, делать бэкап самого сборщика и не смешивать доступы.

Минимальная схема обычно включает Git-сервис, хост со сборщиком, management-сеть (или выделенный сегмент) и журналирование доступа хотя бы на уровне системных логов хоста. Если прямой доступ к management-сети запрещен, добавляется jump-host, и сборщик ходит к устройствам только через него.

Подключения к устройствам делайте через management-сеть, а в ACL оставляйте минимум: с хоста сборщика разрешить нужные порты (обычно SSH) только к списку устройств. Учетные записи на устройствах заведите отдельные и только для чтения, без прав на изменение конфигурации.

Доступ к Git храните как SSH-ключ или токен с минимальными правами (только push в нужный репозиторий). Сразу договоритесь о ротации ключей и о том, кто имеет право их менять, чтобы процесс не держался на одном человеке.

Права доступа: кто может читать, менять и утверждать

Когда конфиги лежат в Git, доступ к ним становится частью безопасности сети. Лучше сразу разложить роли, чтобы резервные копии не превратились в общий «архив паролей», а история изменений была пригодна для проверки.

Чаще всего хватает трех уровней:

• Сборщик (Oxidized/RANCID + сервисный аккаунт в Git): добавляет коммиты в выделенную ветку или репозиторий и больше ничего.
• Ревьюеры (сетевые инженеры/дежурная смена): читают все, открывают MR/PR, утверждают изменения, разбирают конфликты.
• Читатели (аудит, ИБ, смежные команды): доступ только на чтение.

Принцип наименьших прав простой: доступ к полной истории нужен не всем, а только тем, кто реально расследует инциденты или принимает изменения. Остальным обычно достаточно права «читать» и видеть diff в MR/PR.

Разделяйте доступы по зонам. Практичный вариант - отдельные проекты или хотя бы раздельные каталоги/ветки для prod, test, филиалов и критичных сегментов (например, ядро и периметр). Тогда ревьюер филиала не видит конфиги ЦОД, а аудит не смешивает контуры.

В Git включайте защиту веток: в main никто не пушит напрямую. Разрешайте только merge через MR/PR. Для критичных зон задайте правило минимум двух аппрувов (например, сетевой инженер плюс представитель ИБ).

Секреты в конфигурациях: как не хранить лишнее в Git

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

Самое опасное, что нельзя коммитить: SNMP community, локальные пароли, enable secret, ключи SSH, pre-shared key для VPN, токены API. Обычно проблема не в злых намерениях, а в мелочи: инженер добавил пользователя, сборщик забрал конфиг, и секрет уехал в историю.

Хорошая практика - вырезать секреты на этапе выгрузки (фильтры/санитайзеры) или хранить их отдельно в защищенном хранилище, а в конфиге оставлять только шаблонные строки. Ориентир такой: конфиг в Git должен помогать в diff и восстановлении настроек, но не должен позволять подключиться к устройству без дополнительных данных.

Перед коммитом добавьте проверку: pre-commit хук или шаг в CI, который ищет подозрительные строки регулярками и блокирует изменения. Ложные срабатывания здесь полезнее, чем «тихая» утечка.

Если секрет уже попал в историю, действуйте по плану: сначала ротация (пароль/ключ/community/PSK), затем проверка зависимостей (шлюзы, мониторинг, VPN), временное ограничение доступа к репозиторию, очистка истории и настройка правила, которое не даст повторить ошибку.

Как настроить сбор конфигов так, чтобы diff был полезным

Цель здесь не просто «сохранить файл», а получать понятный diff: что изменилось в настройках, а не что «обновилось само». Для этого конфиги нужно привести к стабильному виду.

Нормализация вывода: убрать «шум»

Многие устройства добавляют строки, которые меняются постоянно: время генерации, uptime, счетчики, серийники в заголовках. Если их не убрать, каждый коммит будет выглядеть как большое изменение.

Фильтруйте строки, которые не несут смысла для ревью. Например, удаляйте ! Last configuration change ... или ! NVRAM config last updated ..., а также динамические блоки со статистикой.

Соглашения по именам и инвентарь

Diff проще читать, когда понятно, что это за устройство и где оно стоит. Договоритесь о схеме имен, чтобы в репозитории не было «sw1», «sw2», «test».

Рабочий формат: site-role-model-hostname. Например: ala-access-c2960-ala-sch-01 или ast-core-n9k-ast-dc-01.

Инвентарь лучше вести как источник правды для сборщика: список устройств, группы и теги (площадка, роль, критичность). Тогда вы зададите разные правила опроса и фильтрации без ручных исключений.

Расписание опроса и разные политики

Частый опрос дает актуальность, но создает нагрузку и больше «шума» в истории. Обычно помогает базовое расписание плюс исключения: ядро и ЦОД опрашивать чаще, доступ реже, edge и филиалы переносить на ночные часы, а после окна изменений делать принудительный сбор.

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

Шаблон структуры репозитория конфигов (готовая заготовка)

Хороший репозиторий для сетевых конфигов решает две задачи: позволяет быстро найти нужное устройство и дает чистый diff. Ниже заготовка, которая подходит и для Oxidized, и для RANCID.

repo/
  inventory/
    prod/
      almaty/
        core.yaml
        access.yaml
      astana/
        core.yaml
    test/
      lab.yaml

  configs/
    prod/
      almaty/
        core/
          rtr-a1.cfg
          rtr-a2.cfg
        access/
          sw-a10.cfg
      astana/
        core/
          rtr-n1.cfg
    test/
      lab/
        access/
          sw-lab1.cfg

  docs/
    naming.md
    onboarding.md
    restore-playbook.md

  tools/
    sanitize-config.sh
    normalize-lines.sh

  policies/
    access.md
    review-rules.md
    retention.md

Для именования файлов чаще всего хватает схемы: <env>/<site>/<role>/<hostname>.cfg. Если у вас много одинаковых имен хостов (например, после миграций), добавьте префикс с инвентарным ID: 00123-rtr-a1.cfg. Путь должен однозначно отвечать на вопрос «где стоит устройство и какую роль выполняет».

Рядом с конфигом удобно хранить краткие метаданные в inventory: модель, версия ОС, mgmt-IP, владелец (команда или отдел), контакт для согласований, критичность, окно работ. Это помогает в ревью: вы видите изменения и понимаете контекст.

Не кладите в репозиторий то, что раздувает историю или повышает риск утечки: приватные ключи и пароли, дампы логов «на всякий случай», бинарные файлы (прошивки, архивы), а также конфиги с динамическими счетчиками, которые меняются каждый запуск (их лучше чистить в tools/ перед коммитом).

Процесс ревью перед выкладкой: ветки, MR/PR и правила аппрува

Чтобы история в Git была пригодна для проверки, договоритесь: в main попадает только то, что прошло ревью. Любые изменения (даже «поправил описание интерфейса») делайте в рабочей ветке, а затем оформляйте MR/PR.

Схема может быть одинаковой и для плановых работ, и для автоматического сбора после окна изменений. В обоих случаях цель одна: человек подтверждает, что diff ожидаемый, а не результат ошибки или лишней команды.

Ветки и минимальные правила

Обычно хватает базового набора: main защищен (прямые push запрещены), ветки называются по смыслу (например, change/<device>-<date> или ticket/<id>), для критичных устройств требуется минимум два аппрува, автор не аппрувит сам себя, а после merge ветка удаляется.

Что должно быть в MR/PR

Описание не должно быть длинным, но обязано давать контекст: причина изменения и номер тикета, список затронутых устройств, окно работ и ожидаемый эффект, план отката и отметка, что проверка на секреты пройдена и diff читаемый.

Типовой пример: после замены коммутатора инженер открывает MR/PR с изменением VLAN и ACL, описывает откат и отдельно фиксирует, что пароли и SNMP community не попали в diff. Ревьюер сверяет, что изменились только нужные строки, и после аппрува это уходит в main.

Аудит изменений: как сделать историю пригодной для проверки

Аудит работает только тогда, когда коммиты читаются как журнал действий, а не как случайный набор diff. Для резервного копирования конфигов в Git задайте стандарт: что считается изменением, как оно подписывается и где искать подтверждение.

Что фиксировать в истории

Если конфиги собирает Oxidized/RANCID и коммитит сервисный аккаунт, не теряйте «человеческий след». Помогает единый формат сообщений коммита и привязка к заявке.

Практичный минимум: имя устройства и метод (oxidized/rancid), время (в едином часовом поясе), исполнитель (логин/ФИО), причина (номер изменения или инцидента). Тогда на вопросы «кто поменял, когда и зачем» отвечает обычный Git log плюс diff.

Контрольные точки, отчеты и логи сборщика

Для больших изменений делайте контрольные точки тегами (например, BEFORE-CHANGE-<id> и AFTER-CHANGE-<id>). Так проще доказать, что было «до» и что стало «после», и быстрее откатиться.

Отчеты удобнее вести как ежедневную сводку: какие устройства изменились, какие не удалось опросить, какие изменения затронули критичные узлы (ядро, периметр, DC). Ошибки доступа и недоступность устройств лучше не прятать в коммитах. Логи сборщика храните отдельно: успех/ошибка, причина, время, с какого хоста выполнялся опрос. Это показывает не только изменения, но и покрытие, и пробелы.

Частые ошибки и ловушки при хранении конфигов в Git

Проблема почти всегда не в Git, а в правилах вокруг него. Если правил нет, репозиторий превращается в свалку: непонятно, что изменилось, зачем и кто это согласовал.

Одна из типичных ловушек - смешивание ручных и автоматических коммитов. Например, Oxidized коммитит каждые 5-10 минут, а инженер параллельно делает ручной коммит после инцидента. История рвется, а важное изменение теряется среди фоновых правок. Проще договориться заранее: либо ручные коммиты запрещены, либо делаются только через отдельную ветку и ревью.

Вторая частая ошибка - слишком широкие права. Конфиги содержат адреса, топологию и иногда строки, которые упрощают доступ. Если репозиторий читают все подряд, вы расширяете поверхность атаки. Минимум выглядит так: чтение только тем, кому нужно, запись только автоматике и ограниченному кругу, утверждение - отдельной роли.

Еще одна боль - огромные пачки изменений. Когда за ночь прилетает 300 файлов без понятного описания и без ревью, расследование превращается в угадайку. Помогают разбиение по площадкам/ролям устройств и понятные сообщения, чтобы было видно, где «фон», а где реальная правка.

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

Быстрые проверки: чеклист для ежедневного контроля

Ежедневный контроль нужен не «для галочки». Он помогает заметить проблему до того, как вам срочно понадобится конфиг после сбоя или неудачного изменения.

Короткий набор проверок на 3-5 минут:

• За последние сутки есть свежие коммиты с бэкапом, а не «тихий» Git без изменений.
• Сборщик хотя бы два раза успешно подключался к критичным устройствам (ядро, граничные, VPN, основные коммутаторы).
• По репозиторию не всплыл секрет (быстрый поиск по “password”, “secret”, “community”, “private key”).
• Основная ветка защищена: прямые push запрещены, изменения идут через MR/PR и аппрув.
• Понятно, кто сегодня дежурный и кто ревьюит, чтобы изменения не зависали.

Если что-то стало «красным», важно закрыть причину, а не просто отметить. Два ключевых устройства не бэкапятся - это может быть истекший пароль read-only аккаунта, смена SSH-алгоритмов, новый ACL или банально забитый диск на хосте сборщика.

Полезное правило для команды: любой сбой бэкапа заводится как короткая задача с владельцем и сроком «сегодня». А если в истории внезапно появился секрет, реакция должна быть мгновенной: удалить его из Git с учетом истории, заменить секрет на устройстве и добавить правило, которое не даст повторить это снова.

Пример из практики: изменение на устройстве и прозрачный откат

Филиал жалуется: часть сотрудников не попадает в бухгалтерскую систему. Частая причина - правка ACL на маршрутизаторе филиала. Чтобы это не превращалось в поиск по чатам и догадки, помогает резервное копирование конфигов в Git и дисциплина изменений.

Сценарий простой: инженер должен заменить старый ACL на новый (например, добавить подсеть нового отдела и убрать временное правило). Он не делает правку «втихаря». Сначала оформляет изменение как задачу, затем готовит MR/PR с понятным описанием: что меняем, зачем, какой риск и как проверяем.

Цепочка обычно такая:

1. Инженер вносит правку на устройстве в согласованное окно.
2. Oxidized/RANCID снимает конфиг, Git фиксирует коммит.
3. Появляется MR/PR в ветку изменений, где виден diff.
4. Ревьюер проверяет diff и задает вопросы.
5. Ответственный за безопасность подтверждает, что доступы не расширили лишнего.
6. После аппрува изменение считается официальным, а проверка связи фиксируется в комментарии.

Git здесь полезен не только как хранилище. Diff показывает, что поменялось на самом деле: одна строка в ACL или еще и NAT, маршруты, VPN. История дает доказательство: кто внес, когда, по какой заявке и кто утвердил.

Если после выкладки связь упала, откат делается быстро и спокойно. Инженер берет последний «хороший» коммит, возвращает предыдущую версию конфига (или только блок ACL), применяет и получает ожидаемое состояние. Дальше уже можно разбирать причину: ошибка в порядке правил, пропущенная подсеть, конфликт с deny.

Следующие шаги: внедрить пилот и аккуратно масштабировать

Чтобы резервное копирование конфигов в Git действительно заработало, начните с короткого пилота и четких правил. Цель пилота - не «покрыть все», а проверить, что сбор стабилен, diff читаемый, а ревью не превращается в формальность.

План на 1-2 недели

Выберите 10-20 устройств: по 1-2 ключевых модели от каждого вендора плюс одно «проблемное», которое часто меняют. Дальше двигайтесь по шагам: назначьте роли (админ сборщика, ревьюеры, кто делает merge, кто только читает), зафиксируйте минимум правил (именование, окна опроса, что считается аварийным изменением), настройте маскирование секретов и проверьте, что ничего лишнего не коммитится.

Проведите 2-3 тестовых изменения на стенде или на некритичном устройстве и обязательно отработайте откат. Затем соберите обратную связь и поправьте фильтры и шаблоны перед расширением.

Документация должна быть короткой: одна страница для инженера («как внести изменение и оформить MR/PR») и одна для ревьюера («что проверить перед аппрувом»). Ориентир простой: человек, который не участвовал в настройке, должен повторить процесс без дополнительных вопросов.

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

Если нужно быстро развернуть инфраструктуру под такой процесс (хост под сборщик, Git-сервис, сервер под журналы, базовая отказоустойчивость), это можно делать параллельно с пилотом. В таких задачах иногда помогает системный интегратор: например, GSE.kz (gse.kz) как производитель серверов и системный интегратор в Казахстане может подобрать серверную платформу под сборщик и репозиторий и организовать поддержку 24/7 в рамках общей ИТ-эксплуатации.