Network tarafında “konfigürasyon drift’i” kaçınılmazdır: acil müdahale, vendor farklılıkları, saha baskısı… Drift’i tamamen “yasaklamak” yerine, tespit edip kontrollü düzeltmek sürdürülebilir olandır.
Bu yazıda pratik bir akışı anlatıyorum:
NetBox (source of truth) → Nornir (execute) → Git PR (approval) → rollout (ring).
Hedef mimari (minimum viable)
Bu akışın en yalın hali şu bileşenlerle çalışır:
- NetBox: cihaz/arayüz/IP/VLAN/tenant envanteri
- Git repo: “istenen durum” (templates + variables)
- Nornir job:
- NetBox’tan inventory çek
- Cihazdan running-config al
- Template ile “beklenen” üret
- Diff üret (rapor)
- Onay sonrası uygula (commit + tag ile)
Adım 1 — NetBox’ta envanteri “otomasyon dostu” hale getir
NetBox’ta drift akışını kolaylaştıran pratikler:
- Cihazlara role ver (core/edge/access)
- Site/region alanlarını tutarlı kullan
- VLAN/VRF modelini “gerçek” ile hizala
- Custom field ile “automation ring” ekle (canary/pilot/prod)
Amaç: Nornir inventory’sini etiketlerle kesebilmek.
Adım 2 — Nornir inventory: NetBox kaynağı
Nornir tarafında iki önemli detay:
- NetBox API token’ını salt okunur başlatın (rapor aşaması için)
- “Onay sonrası apply” aşamasında ayrı token/kimlik kullanın
Bu ayrım, “rapor üretme” ile “değişiklik uygulama” riskini böler.
Adım 3 — Drift raporu: cihaz başına diff üret
Rapor aşamasında hedef:
- Hangi cihaz drift’te?
- Drift hangi sınıfta? (ACL, routing, interface, NTP, SNMP, syslog…)
- Drift “beklenen” mi (planned change) yoksa sürpriz mi?
Ben raporu iki formatta üretmeyi seviyorum:
- İnsan için: Markdown özet + en kritik farklar
- Makine için: JSON (CI gate / metrik)
Adım 4 — PR workflow: “onaylanmış drift düzeltmesi”
PR içinde şu bilgileri standart hale getirin:
- Etkilenen cihaz listesi (ring’e göre)
- Değişiklik sınıfı (routing/ACL/…)
- Beklenen etki (risk)
- Geri dönüş komutu/planı
- Değişiklik penceresi (varsa)
Adım 5 — Rollout: ring ring uygula
Rollout disiplininde ben şu sırayı uygularım:
- Canary: 1–3 cihaz
- Pilot: küçük site/tenant
- Prod: kalan
Her aşamada ölç:
- Routing adjacency flap?
- Packet loss / latency?
- ACL hitcount anomalisi?
- CPU spike?
Adım 6 — Geri dönüş (rollback) gerçek olmalı
Rollback “teoride var” değil, pratikte uygulanabilir olmalı:
- Uygulanan config değişikliğini “transaction” gibi düşünün
- Vendor destekliyorsa commit/confirm mekanizmalarını kullanın
- Değişiklikleri küçük ve atomik tutun
Kapanış: Drift’i görünür kıl, sonra azalt
Bu akışın ilk kazanımı “drift’i azaltmak” değil, drift’i görünür kılmaktır. Görünür olan şey yönetilebilir olur; yönetilebilir olan şey de standartlaşır.
Eğer istersen bir sonraki adım olarak bu akışa “risk skoru” ve “otomatik bakım penceresi seçimi” ekleyebiliriz: drift sınıfına göre gate’ler.