Firmware upgrade, ağ operasyonunda en çok ertelenen ama risk biriktiren işlerden biridir. “Şimdi dokunmayalım” yaklaşımı bir süre sonra iki uçtan birine iter: ya güvenlik açığıyla yaşarsınız ya da bir gün incident bahanesiyle plansız upgrade başlar. Sağlam model; upgrade’i bir “event” olmaktan çıkarıp tekrarlanabilir bakım ritmi haline getirmektir.
Hedef: upgrade’i “komut seti” değil, “operasyon akışı” olarak tasarla
Bu runbook’un hedefi üç çıktıdır:
- Upgrade öncesi risk görünür olur (envanter + kritiklik)
- Upgrade sonrası doğrulama standardı oluşur (kanıt)
- Geri dönüş kararı hızlanır (karar ağacı)
1) Envanter ve kritiklik: “hangi cihaz” sorusunu kapat
Minimum envanter alanları:
- cihaz modeli/OS versiyonu
- rol (edge, core, aggregation, firewall, access)
- bağımlılıklar (BGP peers, OSPF area, VRRP, IPsec)
- kritiklik sınıfı (A/B/C)
- geri dönüş yolu (rollback image var mı?)
Bu envanteri bir “liste” değil, karar mekanizması yap:
- A sınıfı: ring 3 (en son)
- B sınıfı: ring 2
- C sınıfı: ring 1 (önce)
2) Ring/dalga yaklaşımı: küçük başla, kanıtla, büyüt
Benim sahada en stabil gördüğüm model:
- Ring 0: lab/staging (aynı model + benzer config)
- Ring 1: düşük kritik access/edge
- Ring 2: orta kritik aggregation
- Ring 3: core / internet edge / güvenlik katmanı
Her ring geçişi için bir durdurma kuralı koy:
- “Ring 1 sonrası 30 dk: adjacency stabil + loss yok + CPU normal”
3) Upgrade öncesi kontrol listesi (15 dk disiplin)
- Konfigürasyon yedeği alındı (running + startup)
- OS image doğrulandı (checksum)
- HA/stack durumu sağlıklı (varsa)
- Routing adjacency sayısı baseline alındı
- CPU/memory/temperature baseline alındı
- Değişiklik kaydı açıldı (kim, ne, geri dönüş süresi)
4) Upgrade akışı (örnek iskelet)
Her üretici/OS farklıdır ama operasyon iskeleti aynıdır:
- Değişiklik penceresi ve iletişim (kimin izleyeceği)
- Traffic safety: mümkünse yedek yol aktif, load azaltılmış
- Upgrade: image yükle + boot/ISSU
- Post-check: adjacency + forwarding kanıtı
- Gözlem: 15–30 dk stabilite
5) Post-check: minimum kanıt seti
Upgrade sonrası şu sınıfları birlikte doğrula:
- Control plane: BGP/OSPF/ISIS adjacency stabil mi?
- Data plane: kritik prefix’ler doğru next-hop ile gidiyor mu?
- Güvenlik: ACL/policy counters beklenen mi?
- Süreklilik: HA state, failover role, stack health
Eğer mümkünse otomasyonla şu çıktıları al:
- “before/after” adjacency sayısı
- CPU/memory trend
- interface error counters
6) Geri dönüş karar ağacı: “ne zaman rollback?” sorusunu önceden cevapla
Rollback kararını “panik” yerine eşikle bağla. Örnek:
- 10 dk içinde adjacency geri gelmez → rollback
- Kritik prefix reachability bozuk → rollback
- Control-plane CPU sürekli %90+ → rollback
7) Operasyonel kapanış: öğrenme döngüsü
Her dalga sonunda 10 dakikalık kapanış:
- Kaç cihaz geçti, kaçında sorun oldu?
- Sorun sınıfları ne? (image, config, donanım, bağımlılık)
- Ring geçiş eşiği doğru mu?
Bu kapanış ritmi yoksa, her bakım “ilk kez yapılan iş” gibi yaşanır.
Sonuç
Kurumsal ağ cihazlarında firmware upgrade, teknik komutlardan çok operasyonel disiplin işidir. Envanter, ring/dalga yaklaşımı, kanıtlı post-check ve yazılı rollback karar ağacı birlikte kurulduğunda upgrade; ertelenen risk biriktirme işinden çıkar, sürdürülebilir bir bakım ritmine dönüşür. Bu da hem güvenliği hem de operasyonel sakinliği aynı anda artırır.