İçeriğe geç
Siber Kale by Labris Networks

Soru · SD-WAN ve çok şube

Çok Şubeli Bir Ağda Politikayı Merkezden Yönetmenin Sınırı Nedir?

Labris Networks Mühendislik Ekibi · Son güncelleme 15 Ağustos 2026 · 6 dk

Kısa cevap

Merkezden yönetim, şubeler birbirine benzediği ölçüde işler. Sınır, yerel istisnaların şablona sığmadığı yerdedir: her şubenin kendi yazıcısı, kendi kasa terminali ve kendi sağlayıcısı vardır. O farkları şablona gömdükçe şablon kaybolur ve elinizde merkezden dağıtılan yüz ayrı yapı kalır.

Merkezden yönetim bir iddiaya dayanır: “bu şubeler aynı yerdir”. İddia doğru olduğu sürece yönetim ucuzlar. Sınırlar da iddianın çatladığı yerlerde çıkar.

Şablonun Sınırı

Şubeye göre değişen şeyleri değere değil değişkene bağlamak, şablonu uzun süre ayakta tutar. Kural “yerel kullanıcı ağından merkezî uygulama sunucusuna” der. Yerel kullanıcı ağının ne olduğunu şube nesnesi söyler. Bu kısım iyi ölçeklenir.

Kaçtığı yer, yalnızca bir şubede var olan kuraldır. Bir şubede kasada özel bir terminal vardır, bir başkasında belediyenin verdiği bir kamera hattı, üçüncüsünde eski bir kartlı geçiş sistemi. Bunları şablona koyarsanız şablon “temel artı otuz özel durum” hâline gelir ve merkezden yönetimin sağladığı tek gerçek faydayı, tahmin edilebilirliği, kaybedersiniz. Doğru yapı, şubeye özgü kuralların ayrı ve açıkça işaretlenmiş bir bölümde toplanmasıdır. Ürünlerin bu bölüme verdiği ad değişir. Şartnamede aramanız gereken şey, böyle bir bölümün var olup olmadığıdır.

Sahiplik Sınırı

Şube yöneticisine yazma yetkisi verirseniz yapılandırma şablondan ayrışır. Vermezseniz, cuma akşamı kasadaki bir cihaz için kural gerektiğinde kimse açamaz ve iş durur. İkisi de kabul edilebilir değildir.

Çalışan yaklaşım rol ayrımı: kural setinin gövdesi merkezden gelir ve şube tarafından değiştirilemez, belirli bir bölüm ise yerel yöneticiye açıktır. Sınırın nerede olduğunu ürün değil siz yazarsınız. Bu sınır teknik bir ayar olduğu kadar bir sorumluluk paylaşımıdır. Yerel bölümde yapılan her değişikliğin merkezde de görünmesi şart. Görünmüyorsa yetkiyi vermeyin.

Erişilebilirlik Sınırı

Politikayı merkezden dağıtıyorsanız, dağıtım kanalı da politikanın altındadır. Yönetim tünelini kapatan bir kuralı ittiğiniz anda şubeyi kaybedersiniz. O şube de üç yüz kilometre uzaktadır.

Buna karşı üç önlem var. Değişikliği önce tek bir şubede deneyin. Ürününüzde onay gerektiren geri alma zamanlayıcısı varsa kullanın. Belli süre içinde onay gelmezse cihaz eski yapılandırmaya döner, siz de bağlantıyı kaybettiğinizde kendiliğinden kurtulursunuz. Ve şubede yönetimin ulaşabildiği ikinci bir yol bırakın, ayrı bir hat ya da mobil bir bağlantı. Bu üçüncüsü, ilk ihtiyaç duyulduğu gün bütün maliyetini geri öder.

Senkron Sınırı

Bir şube o an erişilemiyorsa gönderilen değişiklik kuyrukta bekler. Kuyrukta bekleyen değişiklik sayısı, aslında sizin gerçek uyum tablonuzdur ve çoğu kurumda kimse ona bakmaz.

Haftada bir “şablonla uyumsuz şube” listesi çıkarın. Bu listede üç ayrı satır türü olmalı. Gönderimi başarısız olanlar, yazılım sürümü farklı olduğu için şablonun tamamını uygulayamayanlar ve üzerinde elle değişiklik yapılmış olanlar. Üçünü tek bir “uyumsuz” sayısında toplarsanız, en tehlikeli olanı, yani elle değiştirilmiş olanı, kalabalığın içinde kaybedersiniz.

Etki Alanı Sınırı

Elle yönetimde bir hata bir şubede kalır. Merkezden yönetimde aynı hata yüz şubeyi aynı anda bozar. Bu, merkezî yönetimin eksiği değil doğasıdır ve karşılığı kademeli dağıtımdır: önce bir şube, sonra bir bölge, sonra hepsi. Değişikliğin doğru olduğunu gösteren şey, hata almaması değil, o şubede işin çalışmaya devam etmesidir. O yüzden aralara gerçek doğrulama koyun.

Ölçek Sınırı

Şube sayısı büyüdükçe düz bir kural listesi yönetilemez hâle gelir. Bölge, şube tipi ve iş kolu gibi gruplamalar baştan kurulmalı. Kırk şubeyle yola çıkıp yüz kırka geldiğinde gruplama eklemek, bütün kural setini yeniden yazmak demektir; kimse de o işi yapacak zamanı bulamaz.

Merkezî Yönetim Hangi Noktada Zorunlu Hale Gelir

Soru genellikle cihaz sayısı üzerinden sorulur ve sayının kendisi kötü bir ölçüttür. Aynı politikayı çalıştıran elli özdeş şube, birbirinden farklı on cihazdan kolay yönetilir.

Zorunluluğu belirleyen üç eşik vardır ve biri aşıldığında merkezî yönetim bir kolaylık olmaktan çıkar.

Tutarlılık eşiği. Aynı kuralın birden çok cihazda elle yazılması gerekiyorsa, cihazlar arasında ayrışma kaçınılmazdır. Bir kural bir yerde güncellenir, diğerinde unutulur ve ortaya çıkan fark aylarca fark edilmez. Bu, yapılandırma kaymasının en yaygın biçimidir.

Denetim eşiği. “Şu erişim bütün şubelerde kapalı mı” sorusuna tek tek cihaza bakarak cevap verilebiliyorsa sorun yoktur. Cihaz sayısı, bu kontrolün pratikte yapılamayacağı bir seviyeye çıktığında cevabı üretecek bir merkez gerekir.

Değişiklik riski eşiği. Bir değişikliğin kaç cihaza dokunacağı arttıkça, hata olasılığı da artar. Merkezden yapılan bir değişiklik bu riski azaltmaz; tersine, tek bir hatayı bütün ağa yayabilir. Buna karşılık değişikliği geri almayı da tek bir işleme indirir. Kazanç, geri dönüşün hızındadır.

Üçüncü eşik, merkezî yönetimin sık gözden kaçan yanını gösterir. Merkez bir kolaylık aracı değil, bir risk yoğunlaştırıcıdır; bu yüzden rol ayrımı ve dört göz ilkesi, merkezî yönetimde tek cihazlı ortamdan daha kritiktir.

Pratik bir gösterge şudur: bir kural değişikliğinin bütün ilgili cihazlarda uygulandığını doğrulamak yarım günden uzun sürüyorsa, eşik çoktan aşılmıştır.

Ne yapmalı

  1. Şubeye özgü değerleri nesne değişkenine çevirin, şubeye özgü kuralları ise ayrı bir yerel bölümde toplayın.
  2. Yerel yöneticinin hangi bölüme yazabileceğini rol tanımıyla sabitleyin, sözlü mutabakatla bırakmayın.
  3. Haftalık olarak şablonla uyumsuz şube listesi çıkarın, başarısız gönderimleri ve elle yapılmış değişiklikleri ayrı sayın.
  4. Politika değişikliğini önce tek bir şubede uygulayın, geri alma yolunu değişiklikten önce test edin.

Bu soruyu şöyle de soranlar var

  • Şube güvenlik duvarlarını merkezden mi yönetmeliyim?
  • Şubeye özel kural ihtiyacı şablonu nasıl bozuyor?
  • Merkezden itilen kural şubeyi erişilmez yaparsa ne olur?