Scriptleriniz Altyapınızı Yönetiyor. Peki Scriptlerinizi Kim Yönetiyor? | BackBox #04

İlk script'i yazdığınızda her şey çok kolaydı. Bir cihaz. Bir işlem. Birkaç komut. Çalıştı. Sonra ikinci script geldi. Ardından backup için bir tane daha. Configuration kontrolü için başka bir tane. Upgrade için yenisi. Cisco için ayrı. Check Point için ayrı. Palo Alto Networks için ayrı. Fortinet için ayrı.

Bir süre sonra onlarca script, scheduler, credential, exception ve farklı cihaz versiyonuyla çalışan bir otomasyon yapınız oluştu.

Ve farkında olmadan ilginç bir noktaya geldiniz:

Scriptleriniz altyapınızı yönetmeye başladı.

Ama şimdi başka bir sorunuz var:

Scriptlerinizi kim yönetiyor?

Script Kötü Değildir. Hatta Bazen En Doğru Çözümdür.

Burada script kullanımını eleştirmiyoruz. Tam tersine. İyi yazılmış bir script, network operasyonlarında inanılmaz zaman kazandırabilir. Tekrarlanan işleri ortadan kaldırır. İnsan hatasını azaltır. Yüzlerce cihaz üzerinde aynı işlemi çok daha hızlı gerçekleştirmenizi sağlar.

Sorun script yazmak değildir.

Sorun, otomasyon ölçeklenmeye başladığında ortaya çıkar.

Çünkü birkaç script ile yüzlerce cihazı, farklı vendor'ları ve sürekli değişen software version'larını yöneten bir automation ecosystem aynı şey değildir.

Bir noktadan sonra script artık çözümün kendisi olmaktan çıkar.

Yönetmeniz gereken başka bir sistem haline gelir.

Dün Çalışan Script Yarın Neden Çalışmasın?

Network ve security altyapısı statik değildir. Software version değişir. CLI syntax değişebilir. API değişebilir. Authentication yöntemi değişebilir. Vendor yeni bir davranış getirir. Bir command deprecated olur. Bir cihaz modeli EoL olur, yerine yenisi gelir. Bir güvenlik politikası credential kullanımını değiştirir. Ve yıllardır sorunsuz çalışan script bir gün çalışmayı bırakır. Daha kötüsü:

Tamamen çalışmayı bırakmayabilir.

İlk beş adımı başarıyla gerçekleştirip altıncı adımda beklemediğiniz bir sonuç üretebilir. Job yine çalışmıştır. Ama operasyon istediğiniz şekilde tamamlanmamıştır. Bu nedenle otomasyonda önemli soru yalnızca:

"Script çalıştı mı?"

değildir. Asıl soru:

"Beklediğimiz sonucu üretti mi?"

Bir Script'in Gerçek Sahibi Kim?

Kurumsal ortamlarda çok sık karşılaştığımız başka bir durum var. Bir mühendis yıllar önce çok iyi bir script yazmıştır. Herkes kullanıyordur. Dokümantasyonu kısmen vardır. Belki Git üzerinde tutuluyordur. Belki ortak bir klasördedir. Belki yalnızca o mühendisin bildiği bazı parametreler vardır. Sonra ekip değişir. Script kalır. Ama script'i neden o şekilde yazdığını bilen kişi artık yoktur.

Şimdi kritik bir değişiklik yapmak gerekiyor. Kim dokunacak? Kim test edecek? Kim production için onaylayacak? Yeni software version'ında hâlâ çalıştığını kim garanti edecek?

İşte burada otomasyon teknik bir problem olmaktan çıkıp operasyonel sürdürülebilirlik problemine dönüşür.

Scheduler Çalışıyor. Peki Sonrasında Ne Oldu?

Bir scheduler'ın en güçlü tarafı basittir: Belirlediğiniz zamanda işi başlatır. Ama network operasyonlarında işin başlaması çoğu zaman en kolay bölümdür.

Örneğin bir configuration değişikliği yapacağınızı düşünün. Önce mevcut configuration alınmalı. Backup'ın başarılı olduğu doğrulanmalı. Cihazın uygun durumda olduğu kontrol edilmeli. İşlem uygulanmalı. Sonuç doğrulanmalı. Servislerin hâlâ çalıştığı kontrol edilmeli. Beklenmeyen bir durum varsa geri dönüş süreci başlamalı. Bütün bunların kayıt altına alınması gerekebilir. Dolayısıyla:

Schedule etmek ile operasyonu otomatikleştirmek aynı şey değildir.

Gerçek otomasyon yalnızca komutu başlatmaz.

İşlemin öncesini, sonrasını ve başarısızlık durumunu da yönetir.

Sonra İkinci Vendor Gelir

Tek üreticili bir ortamda kendi otomasyon yapınızı geliştirmek görece kolay olabilir.

Ama gerçek kurumsal network'ler çoğu zaman böyle değildir. Firewall tarafında iki farklı vendor olabilir. Datacenter switching başka bir vendor'dır. Branch tarafında farklı cihazlar vardır. Load balancer'lar vardır. Wireless altyapısı vardır. Her üreticinin API'si, CLI yapısı, software lifecycle'ı, authentication yöntemi, backup mekanizması ve upgrade prosedürü farklıdır.

Bu durumda otomasyon ekibiniz aslında network'ü değil, vendor farklılıklarını yönetmeye başlar. Yeni cihaz geldikçe script. Yeni version geldikçe update. Yeni exception geldikçe yeni koşul.

Bir süre sonra otomasyonun bakım maliyeti, otomasyonun sağladığı faydanın bir bölümünü yemeye başlar.

Peki 20 Cihazda Çalışan Model 500 Cihazda da Çalışır mı?

Ölçek yalnızca cihaz sayısının artması değildir. 50 cihazdan 500 cihaza geçtiğinizde: Daha fazla version vardır. Daha fazla exception vardır. Daha fazla dependency vardır. Daha fazla credential vardır. Daha fazla bakım gerekir. Daha fazla hata ihtimali vardır. Ve çok daha fazla operasyonel kontrol gerekir.

Bu nedenle büyük network'lerde otomasyonun başarısı kaç tane script yazdığınızla ölçülmemeli.

Ne kadar standart, tekrarlanabilir ve sürdürülebilir operasyon oluşturduğunuzla ölçülmelidir.

BackBox'ın 3.000+ Automation Hikâyesi Neden Önemli?

BackBox'ın önemli farklarından biri, network ve security operasyonlarında tekrar tekrar ihtiyaç duyulan işlemler için binlerce hazır automation sunmasıdır.

Bu yalnızca "hazır script var" anlamına gelmez. Asıl değer şurada: Her operasyon için sıfırdan geliştirme yapmak zorunda kalmamak. Vendor farklılıklarını her seferinde yeniden çözmemek. Tekrarlanan işlemleri standardize etmek. Ekip bilgisini kişilere bağımlı olmaktan çıkarmak. Ve farklı network ve security cihazlarını ortak bir operasyon modeli altında yönetebilmek.

BackBox'ın multi-vendor yaklaşımı burada anlam kazanır. Çünkü kurumun amacı aslında Cisco script'i, Palo Alto script'i veya Fortinet script'i yönetmek değildir.

Amaç network operasyonunu yönetmektir.

Otomasyonun Amacı Daha Fazla Kod Yazmak Değildir

Bazen otomasyon projelerinde başarı yanlış ölçülür. "Bu yıl 150 yeni script yazdık." Bu teknik olarak etkileyici olabilir. Ama başka bir açıdan bakalım. 150 yeni script aynı zamanda 150 farklı bakım noktası, version kontrolü, test ihtiyacı, dependency, dokümantasyon ve gelecekte oluşabilecek teknik borç anlamına da gelebilir.

Gerçek otomasyon başarısı belki de daha az kod yazıp daha fazla operasyonu standartlaştırabilmektir. Çünkü network ekibinin işi automation framework geliştirmek değildir.

Network'ün güvenli ve kesintisiz çalışmasını sağlamaktır.

İnsan Hatasını Azaltırken Yeni Bir Hata Kaynağı Oluşturmayın

Script kullanımının en önemli faydalarından biri insan hatasını azaltmaktır. Ama kontrolsüz büyüyen otomasyon yapısı yeni bir hata kaynağı oluşturabilir.

Yanlış variable. Eski credential. Yanlış device group. Uyumsuz software version. Eksik exception. Yetersiz error handling. Ve belki de en tehlikelisi:

Script'in başarılı çalıştığını düşünüp sonucu kontrol etmemek.

Bu nedenle olgun automation yaklaşımında sadece execution değil; pre-check, validation, error handling, post-check, audit ve gerektiğinde rollback aynı operasyonun parçalarıdır.

Şimdi Script Sayınızı Değil, Bağımlılığınızı Ölçün

Kendi ortamınıza bakın.

Kaç farklı network ve security otomasyon script'iniz var?

Bunların tamamının sahibi belli mi?

Yeni software version'larında düzenli olarak test ediliyorlar mı?

Script'in yalnızca çalıştığını değil, beklenen sonucu ürettiğini doğrulayabiliyor musunuz?

Script'i yazan mühendis yarın ekipten ayrılsa operasyon aynı şekilde devam eder mi?

Ve son olarak:

Yeni bir vendor veya 200 yeni cihaz geldiğinde mevcut modeliniz aynı rahatlıkla ölçeklenebilir mi?

Bu soruların cevabı giderek zorlaşıyorsa, sorun scriptlerinizin kötü olması değildir. Muhtemelen otomasyonunuz büyümüştür. Ve artık otomasyonun kendisinin yönetilmesi gerekiyordur.

Zero Second olarak BackBox ile mevcut network automation yaklaşımınızı birlikte değerlendirebilir, bugün script ve scheduler'larla yürüttüğünüz operasyonların hangilerinin merkezi, multi-vendor ve sürdürülebilir bir modele taşınabileceğini ortaya çıkarabiliriz.

Çünkü iyi otomasyon daha fazla script yazmak değildir.

Daha az insan bağımlılığıyla, daha öngörülebilir operasyon yapabilmektir.

Scriptleriniz Altyapınızı Yönetiyor. Peki Scriptlerinizi Kim Yönetiyor?

Zero Second | BackBox — Network Cyber Resilience | BackBox Series #04 — Prepared by Zero Second