Конфигурацияларды Git‑ке сақтау: Oxidized/RANCID және ревью

Мақсат: конфигурацияларды сақтап, кімнің не өзгерткенін көру

Желілік құрылғылар әдетте аздап өзгереді: VLAN қосылды, ACL түзетілді, маршрут өзгертілді. Осындай түзетулерді апаттан, жабдықты ауыстырғанда, сәтсіз жаңартудан немесе жай біреудің аптасына не істегенін ұмытып кетуінен кейін жоғалту оңай. Әсіресе, өзгерістер байқалмай өтіп, инцидент кезінде ғана шығатын жағдайлар бар.

Конфигурацияларды Git‑ке резервтік көшіру екі мәселені бірден шешеді: сізде «қандай болғаны» деген көшірме қалады және «кім, қашан және нақты не өзгертті» деген тарих пайда болады. Git жол бойынша diff көрсететінімен ыңғайлы — бұл күн мен датамен папкалардан немесе «final_final2» сияқты қалталардан әлдеқайда айқын.

Әдетте бэкапқа access және core коммутаторларының, маршрутизаторлар, брандмауэрлер, балансировщиктер, Wi‑Fi контроллерлерінің конфигурациялары кіреді. Форматтар әртүрлі, бірақ мақсат бір: ағымдағы running-config (немесе оның эквивалентін) тұрақты түрде алып, оны адамға оқылатын түрде репозиторийге салу.

Процессті алдын ала ойласаңыз, аудит формальды емес, нақты болады. Бірден үш нәрсені шешіңіз: құпияларды қалай алып тастайсыз, репозиториге кімнің қолжетімдігі бар және күтпеген diff‑ті талдауға кім жауапты (және «бұл жоспарланған» екенін кім растады).

Минималды пайдалы старт өте қарапайым: күнделікті автоматты жинау, бірыңғай репозиторий және түсінікті өзгерістер тарихы. Даулы түзету кезінде не өзгергенін тез көріп, соңғы жұмыс істейтін версияға сенімді түрде оралуға болады.

Oxidized және RANCID: не таңдау керек және неге

Егер мақсат — Git‑ке конфигурацияларды сақтап, оқылатын өзгерістер тарихын алу болса, екі құрал да бір мәселені шешеді: құрылғылардан конфигті жүйелі түрде алып, diff үшін ыңғайлы формаға келтіру.

Oxidized қарапайым әрі «тірі» опрос моделінің арқасында жиі таңдалады. Ол Git‑ті backend ретінде жақсы қолдайды және құрылғыларды жиі (мысалы, әр 5–15 минут) опраштауға мүмкіндік береді. Күн ішіндегі өзгерістер көп болатын жерлерде бұл тез өзгерісті көруге ыңғайлы.

RANCID — «күнде жинап, коммиттеп, тарих алдық» деген классикалық тәсіл. Ол өзгерістер сирек және бақылау мен қалпына келтіру үшін жинау қажет болған жағдайда жарайды.

Шектеулер әдетте Git‑те емес, вендорларды қолдауға және шығыс тұрақтылығына байланысты болады. Практикада diff уақыт, счетчиктер, uptime немесе блоктардың кездейсоқ тәртіпте шығуынан «шум» жасайды. Тағы бір типтік мәселе: кейбір құрылғылар 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 ашады, өзгерістерді мақұлдайды және қақтығыстарды шешеді.
• Оқушылар (аудит, ақпараттық қауіпсіздік, басқа командалар): тек оқу қолжетімділігі.

Ең аз құқық принципі: толық тарихқа барлық адамға қажеті жоқ, оны инцидентті тексеретіндер мен өзгерістерді қабылдайтындар ғана көргені жөн. Басқаларға әдетте MR/PR‑да diff көру үшін оқу құқығы жеткілікті.

Қолжетімділікті аймақтар бойынша бөліңіз. Практикалық нұсқа — prod, test, филиалдар және критикалық сегменттер (мысалы, ядро және периметр) үшін бөлек жобалар не ең болмағанда бөлек каталогтар/веткалар. Солайша филиал ревьюері ЦОД конфигтарын көрмейді, аудит контурларды араластырмайды.

Git‑те веткаларды қорғауды қосыңыз: main‑ге ешкім тікелей пуш жасай алмайды. Тек MR/PR арқылы merge жасау рұқсат етілсін. Критикалық зоналар үшін минимум екі аппрув ережесін орнатыңыз (мысалы, желі инженері плюс ИБ өкілі).

Конфигурацияларда құпиялар: Git‑те артық нәрсені қалай сақтамау

Егер конфигурацияларды Git‑ке сақтайтын болсаңыз, қарапайым ереже ұстаңыз: репозиторияда құпиялар болмайды. Git тарихты жақсы сақтайды, сондықтан парольдер мен кілттер үшін сәйкес келмейді: ескі коммиттер ұзаққа сақталады, ал уақыт өте репозиториге қолжетімділік жиі кеңейеді.

Коммитке ең қауіпті нәрселер: SNMP community, локал паролдар, enable secret, SSH жеке кілттер, VPN‑ге арналған pre-shared key, 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.

Инвентарьді жинақтаушы үшін шынайы дереккөзі ретінде сақтау жақсы: құрылғылар тізімі, топтар және тегтер (орын, роль, критичность). Осы арқылы әртүрлі опрос және фильтрация ережелерін қолмен өзгертпей қоюға болады.

Опрос кестесі мен түрлі саясаттар

Жиі опрос өзектілікті арттырады, бірақ жүктеме және тарихта «шу» көбейеді. Тиісті тәсіл — базалық кесте плюс ерекшеліктер: ядро мен ЦОД‑ты жиі, access‑ты сирек, 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‑тің оқылатынын растау.

Мысал: коммутатор ауыстырғаннан кейін инженер VLAN мен ACL‑ді өзгертті, MR/PR ашады, кері қайтару жоспары мен құпиялардың diff‑ке түспегені көрсетіледі. Ревьюер тек қажетті жолдар ғана өзгергенін тексереді, аппрувтан кейін main‑ге merge болады.

Өзгерістер аудиті: тарихты тексеруге жарамды ету

Аудит тек коммиттер күнделік сияқты оқылатын кезде жұмыс істейді, ал шалағай diff‑тер жиынтыққа ұқсамайтын кезде пайдасыз болады. Конфигурацияларды Git‑ке сақтағанда стандарт орнатыңыз: не есептеледі, қалай қол қоятындар және қайда растығын іздеу.

Тарихта не жазылу керек

Егер Oxidized/RANCID жинап, сервистік аккаунт арқылы коммиттейді, «адам ізін» жоғалтпаңыз. Бірдей форматтағы коммит хабарлары мен тапсырмаға байланысын сақтау көмектеседі.

Практикалық минимум: құрылғы аты мен әдіс (oxidized/rancid), уақыт (бір қалыпты уақыт белдеуі), орындаушы (логин/аты-жөні), себеп (өзгеріс нөмірі немесе инцидент). Осы арқылы «кім, қашан, не үшін» деген сұраққа Git log пен diff жауап береді.

Контроль нүктелері, есептер және жинақтаушы логтары

Үлкен өзгерістер үшін BEFORE-CHANGE-<id> және AFTER-CHANGE-<id> сияқты тегтер қою пайдалы. Солай «бұрын» және «кейін» дәлелденіп, тез кері қайтаруға болады.

Күнделікті шолу түрінде есеп жүргізу ыңғайлы: қандай құрылғылар өзгерді, қандай құрылғыларға опрос сәтсіз болды, критикалық түйіндерге әсер еткен өзгерістер. Қолжетімсіздік пен қателіктерді коммиттерге жасырып қалмаңыз — жинақтаушы логтарын бөлек сақтаңыз: сәтті/қателік, себеп, уақыт, қай хосттан опрос жасалған. Бұл өзгерістер ғана емес, қамту мен пробелдерді көрсетеді.

Қателіктер мен тұзақтар

Мәселе көбінесе Git емес, оған қойылған ережелер жоқтығында. Егер ережелер болмаса, репозиторий тұрмыстық қалтаға айналып кетеді: не өзгерген, не үшін және кім жасағаны белгісіз болады.

Типтік тұзақ — қолмен және автоматты коммиттердің араласуы. Мысалы, Oxidized әр 5–10 минут сайын коммит істейді, инженер инциденттен кейін қолмен коммит жасайды. Тарих үзілмелі болып, маңызды өзгеріс фондық түзетулер арасында жоғалады. Алдын ала келісіңіз: қолмен коммиттерге тыйым салу немесе оларды бөлек ветка және ревью арқылы өткізу.

Екінші қате — тым кең құқықтар. Конфигурациялар адрес, топология және кей кездері қол жетімділікті жеңілдететін жолдар қамтиды. Репозиторийге барлығы оқи алса, шабуыл беті өседі. Минимум: оқу қажетті адамдарға ғана, жазу — автоматқа және шектеулі адамдарға, мақұлдау — бөлек рөлге.

Тағы бір проблема — үлкен пачкалар. Түнде 300 файл өзгерсе және түсініктеме болmasa, тексеру «болжамға» айналады. Оны аудандар/ролдер бойынша бөлу және түсінікті хабарламалар арқылы шешуге болады.

Алдын ала инцидент жоспары болсын: құпияларды қалай ауыстыру, жинақтаушы кілттерін қалай отоздау, кім репозиторигі қатып тастайды, қандай логтар форензика үшін сақталады және сенімді қолжетімділік тізбегін қашан қайта құрамыз.

Жедел тексерістер: күнделікті бақылау чек-листі

Күнделікті бақылау «қағазға» емес, мәселені көріп алу үшін керек. Ол апат кезінде конфиг қажет болғанда немесе өзгеріс сәтсіз болғанда проблеманы алдын ала байқауға көмектеседі.

3–5 минутқа арналған қысқаша тексерістер:

• Соңғы 24 сағатта бэкаптың жаңа коммиті бар ма; «тың» Git емес пе.
• Сборщик критикалық құрылғыларға (ядро, периметр, VPN, негізгі коммутаторлар) кемінде екі рет сәтті қосылған ба.
• Репозиторийде құпия ұшырап қалған жоқ па (жылдам іздеу: “password”, “secret”, “community”, “private key”).
• Негізгі ветка қорғалған: тікелей push тыйым, өзгерістер MR/PR арқылы өтеді және аппрув бар.
• Бүгінгі дежурный мен ревьюер анық, сонда өзгерістер ілініп қалмайды.

Егер бірнәрсе «қызыл» болса, себепті жабу маңызды — тек белгілеу емес. Екі негізгі құрылғы бэкапталмағи — бұл read-only аккаунттың паролі өткен болуы, SSH алгоритмдерінің өзгеруі, жаңа ACL немесе жинақтаушы хосттағы диск толған болуы мүмкін.

Команда үшін пайдалы ереже: кез келген бэкап сәтсіздігі қысқа тапсырмаға енгізіледі, иесі тағайындалады және мерзімі «бүгін». Ал тарихта құпия шықса, реакция дереу болуы тиіс: тарихтан оны алып тастау, құрылғыдағы құпияны өзгерту және қайта болдырмау ережесін қосу.

Практикалық мысал: құрылғыдағы өзгеріс және ашық кері қайтару

Филиалдан бухгалтерия жүйесіне бір бөлігі қосылмай жатыр деген шағым келді. Көбіне себеп — филиал маршрутизаторындағы 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 қолдауды ұйымдастыруда көмек бере алады.