Çok şubeli ağ yönetimi tek panodan. Meraki'nin ne yaptığını da, neyin bedelini ödettiğini de aynı sayfada yazıyoruz.
Dokuz şubesi ve bir bilgi işlem sorumlusu olan bir işletme düşünün. Şubelerin dördünde farklı marka modem var, ikisinde kimin kurduğu bilinmeyen bir güvenlik duvarı, birinde de servis sağlayıcının bıraktığı cihaz hâlâ varsayılan şifresiyle çalışıyor. Hangi cihazın hangi yazılım sürümünde olduğunu kimse bilmiyor, çünkü bakmak için tek yol her birine ayrı ayrı bağlanmak ve o bağlantıların yarısının şifresi kayıp. Misafir ağının şifresini değiştirmek gerektiğinde yapılan iş, arabaya atlayıp dokuz şubeyi dolaşmak.
Bu tablo bir teknoloji sorunu gibi görünür ama değildir. Bu bir personel sorunudur: lokasyon sayısı, o lokasyonlara bakabilecek insan sayısını geçmiştir. Bulut tabanlı ağ yönetimi tam olarak bu soruna cevap verir. Marka tercihi değil, ölçek sorunudur; bir kişinin kırk noktaya bakabilmesini mümkün kılan şey daha çalışkan bir mühendis değil, yönetimin cihazdan alınıp tek bir yere taşınmasıdır.
Cisco Meraki, bu yaklaşımın en yaygın karşılığı. Güvenlik cihazından anahtara, erişim noktasından kameraya kadar bütün donanım ailesi tek bir web panosundan yönetiliyor; yapılandırma cihazın üzerinde değil bulutta duruyor ve oradan sahaya gönderiliyor. Zincir otel, çok şubeli klinik, franchise mağaza zinciri ve sürekli yer değiştiren şantiye ofisleri bu modelin en çok işine yaradığı yapılar.
Bu sayfada Meraki'nin ne yaptığını anlatıyoruz, ama aynı ağırlıkta neyin bedelini ödettiğini de yazıyoruz. Lisans zorunluluğu, üreticiye bağımlılık ve arayüzün sınırları gerçek kalemler. Meraki'nin yanlış cevap olduğu durumlar da var ve o durumlarda ne kurduğumuzu aşağıda açıkça söylüyoruz.
Cihazların ortak noktası özellikleri değil, yönetildikleri yer. Hepsi aynı panoda, aynı kullanıcı hesabıyla, aynı mantıkla yönetilir.
Şubenin internet çıkışında duran kutu. Güvenlik duvarı, yönlendirme, çift WAN, içerik filtresi ve şubeler arası tünellerin ucu hep burada. Küçük bir mağazada masaüstü bir model, otel ya da genel merkezde rack tipi daha büyük bir model olur; yönetim ekranı ikisinde de aynıdır.
Port bazlı VLAN ataması, PoE bütçesi, link agregasyonu ve döngü koruması panodan yapılır. Bir şubede yanlış VLAN'a takılmış bir kamerayı düzeltmek için oraya gitmek gerekmez; portun profilini panodan değiştirirsiniz, cihaz yerine oturur.
SSID tanımları, misafir ayrımı, kimlik doğrulama ve radyo profilleri merkezi olarak dağıtılır. Kırk şubede aynı SSID adı, aynı şifreleme ve aynı bant davranışı tek yerden tanımlanır. Yerleşim kararı yine sahada verilir — bulut, duvarın betonu hakkında bir şey bilmez.
Kaydı cihazın kendi içinde tutan, ayrı bir kayıt sunucusu istemeyen kamera ailesi. Şube başına bir NVR kutusu ve onun bakımını ortadan kaldırması, az personelli yapılarda gerçek bir kazanç. Karşılığında depolama süresi cihazın kapasitesiyle sınırlıdır ve bunu baştan hesaplamak gerekir.
Sıcaklık, nem, su kaçağı, kapı açılma ve elektrik durumu için küçük sensörler. Sunucu odasının sıcaklığını ya da soğuk hava deposunun durumunu ağ panosunun içinden izlemek, ayrı bir sistem kurmaktan basit. Kritik değil, ama az personelli işletmede sessiz bir sigorta.
Bu ailelerin hepsini birden almak zorunda değilsiniz ve çoğu kurum almaz. Yaygın başlangıç, şube çıkışındaki güvenlik cihazı ile erişim noktalarıdır; anahtar tarafı mevcut donanım ömrünü doldurdukça devreye alınır. Karma yapı çalışır — Meraki güvenlik cihazının arkasında başka marka bir anahtar sorunsuz durur. Sadece o anahtarın portlarını panodan yönetemezsiniz, o kısım eski usul kalır.
Panonun asıl özelliği bir ekran olması değil, yapılandırmanın kayıt yerinin değişmesidir. Klasik bir kurulumda yapılandırma cihazın belleğinde yaşar; cihaz ölürse yapılandırma da onunla gider ve elinizde bir yedek yoksa her şey yeniden yazılır. Bulut yönetiminde ise cihaz yapılandırmanın kopyasını taşır, sahibi değildir. Bunun günlük hayattaki karşılığı, bir sonraki bölümde anlatılan şey.
Bu, bulut yönetiminin en somut ve en kolay anlatılan faydası. Cihazın yapılandırmayı seri numarasıyla kendisinin çekmesi, kurulum için mühendis seyahatini ortadan kaldırır.
Bu akışın gerçek değeri açılışta değil, arıza anında ortaya çıkar. Antalya'nın bir ilçesindeki şubede güvenlik cihazı yandığında klasik yöntemde yapılacak iş bellidir: yeni cihaz alınır, merkezde yapılandırılır, kargolanır ya da biri arabayla götürür, yerinde takılır ve büyük ihtimalle bir şey tutmadığı için telefonda saatlerce uğraşılır. Şubenin ayakta olmadığı süre gün ile ölçülür.
Bulut yönetiminde aynı olay şöyle yürür: yedek cihazın seri numarası panoda eskisinin yerine tanımlanır, kutu kargoya verilir, şubede biri takar ve cihaz kendi yapılandırmasını çeker. Kesinti süresi mühendis seyahatinden kargo süresine iner. Kritik şubelerde bir adım daha atıp raf yedeği bulunduruyoruz; o zaman süre kargodan da kurtulur.
Şubeler birbirinin kopyası değildir ama yüzde doksanı ortaktır. Şablon o yüzde doksanı bir kez yazdırır, kalan yüzde onu şubeye bırakır.
VLAN yapısı, güvenlik duvarı kuralları, içerik filtresi politikası, SSID tanımları ve trafik önceliklendirme şablonda bir kez yazılır. Şablona bağlı her şube bunları miras alır. Yeni bir kural eklemek kırk cihaza tek tek girmek değil, tek bir satır yazmaktır.
Şablon her şeyi tek tipleştirmez. Her şubenin kendi WAN adresi, kendi VLAN alt ağı, kendi hattı ve kendi cihaz sayısı vardır. Bunlar şube değişkeni olarak tutulur; şablon iskeleti verir, değişkenler yerel gerçeği doldurur.
Şubeler ve cihazlar etiketlenir: mağaza, depo, otel-resepsiyon, inşaat-şantiye, sezonluk. Bir kural yalnız belirli etikete sahip yerlerde geçerli olabilir. Sezonluk çalışan on şubeye ayrı politika uygulamak, ayrı bir yönetim yükü doğurmadan mümkün olur.
Şablonsuz bir yapıda bir politika değişikliğinin maliyeti şube sayısıyla doğru orantılıdır. Şablonla bu maliyet sabitlenir: dokuz şube de kırk şube de aynı süreyi alır. Bu sayfada anlatılan özellikler arasında yatırımı en hızlı geri döndüren kalem budur.
Madalyonun diğer yüzü: şablona yazılan yanlış bir kural da kırk şubeye aynı anda gider. Bu yüzden şablon değişiklikleri önce bir pilot şubede denenir, sonra dalga dalga uygulanır. Merkezi yönetim dikkati azaltmaz, tersine bir değişikliğin ağırlığını artırır.
Zincir işletmelerde yeni şube açılışının en sinir bozucu tarafı, ağın açılış gününe yetişip yetişmeyeceğidir. Şablon hazırsa yeni şube panoda beş dakikada tanımlanır; kalan iş kutunun kargoyla ulaşmasıdır.
Şablon tasarımının püf noktası, neyin ortak neyin yerel olduğuna doğru karar vermektir. Fazla katı bir şablon şubeleri zorlar ve insanlar şablon dışına çıkmak için istisna ister; fazla gevşek bir şablon ise kısa sürede kırk ayrı yapılandırmaya dönüşür ve merkezi ağ yönetiminin bütün kazancı erir. Kurduğumuz denge genellikle şudur: güvenlik kuralları, kimlik doğrulama ve trafik politikası kesinlikle şablonda; adresleme, hat bilgisi ve yerel cihaz sayısı şube değişkeninde.
Etiketler bu yapının ikinci katmanı. Bir mağaza zincirinde caddedeki mağaza ile alışveriş merkezindeki mağaza aynı politikayı kullanmaz — çalışma saatleri, misafir ağı beklentisi ve hat türü farklıdır. Bunları iki ayrı şablona bölmek yerine etiketlemek, ortak kuralları tek yerde tutmayı sürdürürken farklılığı da yönetilebilir kılar. Şantiye ofisleri gibi geçici lokasyonlar için de aynı yöntem işe yarar: proje bitince etiket kaldırılır, lokasyon panodan çıkarılır, cihaz bir sonraki şantiyeye gider.
Şubeler arası bağlantı, çok lokasyonlu ağların en çok vakit yiyen kalemidir. Klasik yöntemde iki uçta da aynı parametreleri elle yazarsınız: şifreleme algoritması, anahtar ömrü, ilgi çeken trafik tanımı, ön paylaşımlı anahtar. Bir taraf diğerinden bir kalem farklı yazıldığında tünel kurulmaz ve hata mesajı çoğu zaman sebebi söylemez. Dokuz şubelik bir yapıda yıldız topolojide dokuz tünel, tam örgüde otuz altı tünel demektir ve her biri iki uçtan yazılır.
Auto VPN bu işi kaldırır. Şubeler aynı kuruluş hesabında olduğu için birbirlerinin parametrelerini ve adres bloklarını zaten bilirler; siz yalnızca hangi şubenin hangi rolde olduğunu ve hangi alt ağların tünele gireceğini söylersiniz. Tüneller kurulur, kendini onarır, hat değiştiğinde yeniden kurulur. Kayan IP adresi olan mobil ya da ev tipi hatlarda bile çalışır; klasik kurulumda o durum ayrıca uğraş ister.
Buradaki kolaylığın bir dezavantajı da var ve dürüst olalım: tünelin nasıl kurulduğuna dair kontrolünüz azalır. Belirli bir şifreleme paketini zorlamak, üçüncü taraf bir güvenlik duvarıyla özel parametrelerle eşleşmek ya da bir denetim raporunun istediği tam ayarı yazmak istediğinizde arayüzün verdiğinin ötesine geçemezsiniz. Meraki dışındaki bir uca bağlanmak için klasik tünel de kurulabilir, ama o zaman kolaylığın büyük kısmı gider.
Bütün şubeler merkeze bağlanır, şubeler arası trafik merkez üzerinden geçer. Uygulama sunucusu, muhasebe, ERP ve dosya paylaşımı merkezde duruyorsa doğru seçim budur. Trafik tek noktadan geçtiği için denetim, kayıt ve filtreleme de tek noktada yapılır. Bedeli şudur: merkez hattı düşerse şubeler arası her şey düşer, o yüzden merkezde hat yedekliliği tercih değil zorunluluktur.
Her şube her şubeyle doğrudan konuşur. Şubeler arası doğrudan trafik varsa — mesela şubeler arası IP telefon görüşmesi ya da yerel sunucular arasında veri alışverişi — gecikme belirgin biçimde düşer, çünkü trafik merkeze uğrayıp geri dönmez. Bedeli, tünel sayısının şube sayısıyla birlikte hızla artması ve merkezde tek noktadan denetimin kaybolmasıdır.
Pratikte en sık kurduğumuz düzen bu. İnternet çıkışı ve merkez uygulamaları yıldız üzerinden yürür; sesli görüşme ve belirli şube grupları arasında doğrudan tünel açılır. Karar teknik bir tercih değil, trafiğin nereye gittiğine bakarak verilen bir ölçüm sonucudur.
Topoloji kararını verirken sorduğumuz tek soru var: bu ağda veri nereye gidiyor? Otel zincirlerinde cevap genellikle merkezdir — rezervasyon sistemi, muhasebe ve raporlama tek noktada durur, yıldız yapı yeterlidir. Şubeler arası yoğun sesli görüşme ya da şubeden şubeye dosya erişimi olan yapılarda ise merkeze uğrayıp geri dönen trafik hem gecikme hem gereksiz hat yükü üretir; orada doğrudan tünel açmak doğru olur. Karar ölçümle verilir, alışkanlıkla değil.
Tünel tasarımı yalnız bağlantı değil, erişim kararıdır. Şubenin merkezdeki her şeye erişmesi gerekmez; genellikle birkaç sunucu ve birkaç servis yeter. Tünele hangi alt ağın gireceğini sınırlamak, hem trafiği azaltır hem bir şubede yaşanan olayın bütün ağa yayılmasını engeller. Bu konuyu daha derinlemesine ele aldığımız yer VPN kurulumu sayfası.
İkinci hattın faturası her ay ödenir. Kurallar yazılmadıkça o hat sadece bekler ve birincil hat bozulduğunda da beklemeye devam eder. SD-WAN, ikinci hattı bekleyen bir yedek olmaktan çıkarıp kullanılan bir kaynağa çevirir.
Devrin kullanıcı tarafında nasıl hissedildiği, bu konunun en az konuşulan ama en önemli kısmı. Bir sesli görüşme sırasında hat devrederse iki şey olabilir. Kurallar doğru yazılmışsa görüşme kısa bir bozulmayla devam eder; kullanıcı hattın değiştiğini genellikle fark etmez, sadece "bir an kesildi" der. Kurallar yazılmamışsa görüşme düşer, santral yeniden bağlanmayı dener ve o sırada arayan müşteri telefonu kapatır. Aradaki fark bir donanım farkı değil, yapılandırma farkıdır.
Türkiye şartlarında ikinci hattı mobil bir hat olarak kurmak yaygın ve mantıklı. Fiber kesildiğinde — ki yaz aylarında kazı çalışmaları yüzünden bunu sık görüyoruz — mobil hat devreye girer, kasa çalışmaya devam eder, ödeme alınır. Bu senaryoda mobil hattın veri kotasını korumak için politika yazmak şart: yedekleme ve güncelleme trafiği mobil hatta hiç çıkmasın, yalnız iş trafiği geçsin. Yazılmadığında bir günlük kesinti aylık kotayı bitirir.
Merkezi kablosuz ağ kurulumu ayarları kolaylaştırır, ölçümü ortadan kaldırmaz. Beton perde, asansör kuyusu ve metal raf sistemi hâlâ oradadır ve panodan görünmezler.
Otel tarafında en sık gördüğümüz hata, kablosuz sorununun kapsama sorunu sanılmasıdır. Misafir "internet çalışmıyor" dediğinde çoğu zaman sinyal vardır; sıkışan şey kanaldır. Her katta aynı kanalda yayın yapan erişim noktaları birbirini bekletir ve otelin doluluk oranı arttıkça bu bekleme kullanıcıya yavaşlık olarak yansır. Çözüm ekstra erişim noktası takmak değil, çoğu zaman gücü düşürmek ve kanal planını düzeltmektir — sezgiye ters ama sahada defalarca işe yarayan bir müdahale.
Kimlik doğrulama tarafında ise otel ve klinik ayrışır. Otelde misafir ağı bir karşılama sayfasıyla açılır ve oda numarası üzerinden doğrulama beklenir; bu iş için ayrı bir yapı gerekir ve Hotspot ve misafir ağı sayfasında ayrıntısıyla anlatılıyor. Klinikte ve ofiste ise personel ağı dizin üzerinden doğrulanmalıdır; hangi cihazın ağa girebileceğini kural setiyle yönetmek isteyen kurumlar için ağ erişim kontrolü ayrı bir başlık.
Ölçüm olmadan yürüyen her ağ tartışması aynı yere varır: hattı yükseltelim. Ölçüm varsa tartışma otuz saniyede biter.
Hangi cihaz, hangi saatte, ne kadar veri, hangi uygulamaya. "Şubenin interneti yavaş" şikâyeti, panoda tek bir cihazın hattı doldurduğu bilgisine dönüşür. Ölçüm olmadan bu tartışma his üzerinden yürür ve hep hat yükseltmekle biter.
Bant genişliği kısıtlaması cihaz bazında değil uygulama bazında yazılabilir. Yedekleme ve bulut senkronizasyonu mesai saatlerinde sınırlanır, akşam serbest bırakılır. İş uygulamaları hiçbir zaman sınırlanmaz. Bu ayrımı yapmayan bir kısıtlama, çalışanı da engeller.
Cihaz düştüğünde, hat devrettiğinde, sensör eşiği aştığında ya da yeni bir cihaz ağa girdiğinde bildirim üretilir. Buradaki asıl iş uyarıyı açmak değil, eşiği doğru seçmektir: herkesin sustuğu bir uyarı akışı hiç uyarı olmamasıyla aynı kapıya çıkar.
Pano cihazın buluta bağlı olduğunu gösterir; kullanıcının işini yapabildiğini göstermez. Gerçek izleme, kullanıcıya benzeyen ölçümler ister: şubeden merkezdeki uygulamaya erişim süresi, ses kalitesi ölçümü, tünelin gerçekten veri taşıyıp taşımadığı. Sürekli yönetimi bu yüzden ayrı bir hizmet olarak kuruyoruz.
Bir sorun yaşandığında en değerli şey, olay anındaki veriye geri dönebilmektir. Trafik geçmişi, cihaz olayları ve yapılandırma değişiklik kaydı birlikte okunduğunda "dün saat onda ne oldu" sorusu cevaplanabilir hale gelir. Kayıt tutma süresi lisans seviyesine bağlıdır ve baştan konuşulması gereken bir konudur.
Sahadan somut bir örnek: bir şubeden gelen "internet çok yavaş" şikâyeti üzerine bakıldığında hattın neredeyse tamamının tek bir bilgisayardaki bulut senkronizasyonu tarafından kullanıldığı görülür. Klasör paylaşımına yeni katılan biri, birkaç yüz gigabaytlık arşivi indirmeye başlamıştır. Ölçüm olmadan bu olay bir hafta sürer ve sonunda hat yükseltme teklifiyle biter. Ölçümle birlikte çözüm, o uygulamaya mesai içinde bant sınırı koymaktır ve maliyeti sıfırdır.
Şunu da açıkça söylemek gerekir: pano canlı bir ekrandır, izleme sistemi değildir. Kimse gün boyu ona bakmaz. İzleme, eşiklerin doğru kurulduğu, uyarıların doğru kişiye gittiği ve gelen uyarının sahiplenildiği bir düzenle olur. Bu düzenin nasıl kurulduğunu ağ izleme ve sürekli yönetim sayfasında anlatıyoruz.
Bu bölümü satın alma kararından önce okumanızı istiyoruz. Aşağıdakiler ayrıntı değil, sözleşme kalemi.
Meraki'de donanım ile lisans birbirinden ayrılmaz. Her cihazın geçerli bir lisansı olmak zorundadır ve lisans süreli satılır. Bu bir kerelik alım değil, işletme giderine dönüşen bir kalemdir; bütçeyi ilk yılın donanım maliyetiyle değil, üç ile beş yıllık toplam sahip olma maliyetiyle yapmak gerekir.
Bunu yumuşatmaya çalışmayalım: lisans süresi dolduğunda ve uyarı süresi de geçtiğinde cihaz yönetilen bir ağ cihazı gibi çalışmayı bırakır. Elinizde kalan şey, kendi başına iş göremeyen bir kutudur. Sözleşme yenileme takvimini takip etmek teknik değil ticari bir sorumluluktur ve gözden kaçarsa şube ağı durur.
Klasik bir cihazda yapılandırma metin dosyasıdır; kopyalar, saklar, başka markaya taşırken referans alırsınız. Meraki'de yapılandırma üreticinin bulutunda yaşar. Panodan rapor ve dışa aktarım alınabilir, ama bunlar başka bir markaya basabileceğiniz bir yapılandırma dosyası değildir. Çıkış kararı verildiğinde yapılandırma pratikte yeniden yazılır.
Komut satırı olan bir cihazda ya da Linux tabanlı bir güvenlik duvarında yazabileceğiniz her şeyi panoda yazamazsınız. Alışılmadık yönlendirme kurguları, ince ayar gerektiren tünel parametreleri, özel betikler ve çok özel senaryolar için sadeleştirilmiş arayüz bir duvara çarpar. Sadelik bedava değildir; bedeli esnekliktir.
Bulut erişilemez olduğunda trafik akmaya devam eder — cihazlar mevcut yapılandırmayla çalışır, tüneller ayakta kalır, kullanıcılar çoğunlukla bir şey fark etmez. Kaybettiğiniz şey yönetimdir: değişiklik yapamaz, yeni cihaz devreye alamaz ve canlı görünürlüğü izleyemezsiniz. Kritik bir kesinti anında değişiklik yapamamak, hafife alınacak bir kısıt değildir.
Yönetim verisi, cihaz olayları ve trafik istatistikleri üreticinin altyapısında saklanır. Kişisel veri sorumluluğu olan kurumlarda — otel, klinik, finans — bunun hangi bölgede tutulduğu ve hangi verinin dışarı çıktığı kurulumdan önce netleştirilmesi gereken bir başlıktır. Sonradan sorulduğunda cevabı değiştirmek mümkün olmaz.
Bu kalemlerin hiçbiri Meraki'yi kötü bir ürün yapmaz. Yaptıkları şey, kararın niteliğini değiştirmektir: bu bir donanım alımı değil, çok yıllı bir hizmet taahhüdüdür. Doğru soru "bu cihaz iyi mi" değil, "bu modeli beş yıl taşıyabilir miyiz" olmalı. Beş yıllık toplam maliyeti çıkarıp yanına bir kişinin dokuz şubeyi dolaşmasının maliyetini yazdığınızda karar çoğu zaman kendiliğinden netleşir — bazen Meraki lehine, bazen aleyhine.
Bağımlılık kalemini biraz daha açalım, çünkü en az anlaşılan konu bu. Klasik bir kurulumdan çıkarken elinizde yapılandırma dosyaları olur; yeni markaya geçerken satır satır bakar, karşılığını yazarsınız. Bulut tabanlı bir yapıdan çıkarken bu dosya yoktur. Bunu telafi etmek için tasarım belgelerini marka bağımsız tutuyoruz: adresleme planı, VLAN tablosu, kural gerekçeleri ve tünel topolojisi panodan bağımsız ayrı bir belgede durur. Belge sizde olduğu sürece çıkış acı verir ama imkânsız olmaz.
Bir çözümü her yere uydurmaya çalışmak, satış yapmanın en kolay ve müşteriye en pahalıya mal olan yolu. Aşağıdaki durumlarda başka bir şey kuruyoruz.
Karar için kullandığımız pratik ölçü şu: bir yılda kaç kez şubeye gitmek zorunda kalıyorsunuz ve o seyahatlerin toplam maliyeti — yol, zaman, kaybedilen iş — nedir? Bu rakam lisans maliyetini geçiyorsa bulut yönetimi kendini ödetir. Geçmiyorsa, aynı bütçeyi daha güçlü donanıma ve düzgün bir yapılandırma düzenine harcamak daha akıllıcadır. İki durumda da işi biz yapabiliriz; sadece hangisini yaptığımızı yazılı olarak gerekçelendiriyoruz.
Çalışan bir şube ağı tek gecede değiştirilmez. Değiştirmeye kalkışanlar genellikle pazar akşamı yarım kalmış bir ağla ve pazartesi sabahı çalmayan telefonlarla karşılaşır.
Geçişin en çok atlanan adımı geri dönüş yolunun ne olduğudur. Sahada gördüğümüz manzara şu: yeni cihaz takılır, eski cihaz aynı gün söküp depoya atılır ve akşam bir sorun çıktığında geri dönmek için elde bir şey kalmaz. Eski cihazı bir hafta yapılandırması bozulmadan yerinde bırakmak, hiçbir maliyeti olmayan ve pek çok kez işe yarayan bir tedbir. Depoya atmak için acele etmeyin.
Sıralamada da bir kural var: en kritik şubeyi asla ilk sıraya koymuyoruz. Genel merkez, en yoğun otel ya da en çok ciro yapan mağaza listenin sonunda durur. İlk geçen şube en toleranslı olanıdır, çünkü ilk geçişte mutlaka bir şey unutulur — bir yazıcı, bir ödeme terminali, kimsenin bilmediği bir cihaz. O sürprizin en pahalı yerde yaşanmasını istemeyiz.
Her aşamanın bir çıktısı var. İlk aşamanın çıktısı bir teklif değil, bir karar notu.
Şube sayısı, trafik yönü, mevcut hatlar, personel kapasitesi ve bütçe konuşulur. Bu aşamanın çıktısı Meraki teklifi değil, bir karar notudur: bu yapı için bulut yönetimi doğru mu, değilse hangi alternatif.
Şube alt ağları, VLAN yapısı, tünel topolojisi ve hat politikaları belgeye dökülür. Çakışan adres blokları burada çözülür; kurulum sırasında değil.
Şablon, etiket düzeni, güvenlik duvarı kuralları, içerik politikası, SSID tanımları ve trafik önceliklendirme kurgulanır. Hangi ayarın şablonda, hangisinin şube değişkeninde duracağı yazılı olarak kararlaştırılır.
Bir pilot şube ile başlanır, canlı çalıştırılır, düzeltmeler şablona işlenir. Sonrasında şubeler dalga dalga devreye alınır; her dalganın kendi doğrulama listesi ve geri dönüş yolu vardır.
Kuruluş hesabı kurumun kendi adına açılır ve kurumun kendi yöneticisi tam yetkilidir. Pano kullanımı, günlük işler ve olay anında ne yapılacağı üzerine eğitim verilir. Belgeler teslim edilir.
Devam edilirse eşik bakımı, lisans takvimi, yazılım güncellemeleri, kapasite raporları ve yeni şube açılışları yürütülür. Devam etmemek de bir seçenektir; teslim dosyası bunu mümkün kılacak şekilde hazırlanır.
Bu maddeyi ayrı bir başlık altında yazıyoruz çünkü sektörde tersi çok yaygın. Kurulumu yapan firma panoyu kendi hesabı altında açar, müşteriyi sınırlı yetkiyle içeri alır ve ilişki bittiğinde ağın kontrolü kurumda değil, ayrılan firmada kalır. Teknik olarak devredilebilir ama pratikte bu bir pazarlık konusuna dönüşür ve kurum kendi ağına erişmek için birine muhtaç olur.
Bizim yöntemimiz basit: kuruluş hesabı kurumun kendi adına, kurumun kendi e-posta alan adıyla açılır ve en yüksek yetkili kurumun kendi çalışanıdır. Biz davet edilen bir yönetici olarak çalışırız. O yetki istendiği an, kimseye sormadan, tek işlemle kaldırılabilir. Lisanslar da kurumun hesabına tanımlanır; bizim üzerimize kayıtlı bir lisansla çalışmayız.
Aynı ilke belgeler için de geçerli. Adresleme planı, VLAN tablosu, şablon dokümantasyonu, tünel topolojisi, kural gerekçeleri, lisans yenileme takvimi ve şube doğrulama listeleri kuruma teslim edilir. Devralan bir ekip ilk günden işi yürütebilmelidir. Sürekli ağ yönetimi hizmetini bizden almak bir tercih olmalı; belgesizlikten doğan bir mecburiyet değil.
Hayır. Done Dynamics'in Cisco ile bayilik ya da kurumsal iş ortaklığı ilişkisi yok; mühendislerimizin bireysel Cisco eğitim geçmişi var, kurumsal bir akreditasyon iddiamız yok. Yaptığımız iş tasarım, kurulum, geçiş ve yönetim tarafı. Donanım ve lisans tedariki için Türkiye'deki yetkili kanalla çalışılır; siz doğrudan kendi tedarikçinizden de alabilirsiniz, bu kurulumu etkilemez. Tedarikte aracı olmadığımız için hangi ürünün önerildiği de ticari bir baskı altında değil.
Net bir eşik yok ama pratikte kırılma noktası, lokasyon sayısının bakım yapabilecek personel sayısını belirgin biçimde geçtiği yerdir. Üç şubesi ve bir bilgi işlem sorumlusu olan bir işletmede tartışmaya değer; dokuz şube ve tek kişi varsa cevap büyük ihtimalle evettir. Belirleyici olan şube sayısı değil, şube başına düşen "arabaya atlayıp gitme" sayısıdır. Ayda kaç kez yola çıkıldığını sorarak başlıyoruz.
Evet, bu doğru ve yumuşatılacak bir tarafı yok. Lisans süresi dolduktan sonra tanınan uyarı süresi de geçerse cihaz yönetilen ağ cihazı olarak işlevini kaybeder. Bu yüzden lisansı teknik bir ayrıntı değil, sözleşme takvimi olarak ele alıyoruz: yenileme tarihleri teslim dosyasına yazılır, hatırlatma kurulur ve bütçe planı üç ile beş yıllık toplam maliyet üzerinden yapılır. Bu maliyeti baştan görmeden karar vermenizi istemiyoruz.
Kuruluş hesabı kurumun kendi adına açılır ve kurumun kendi yöneticisi en yüksek yetkiye sahip olur. Biz kendi hesabımızla davet edilen bir yönetici olarak çalışırız ve bu yetki istendiği an tek tıkla kaldırılabilir. Panoyu kendi adımıza açıp müşteriyi misafir olarak eklemeyiz; bu, ilişki bittiğinde ağın rehin kalması demektir. Ağınızın kontrolü sizde kalmadıkça yaptığımız iş teslim edilmiş sayılmaz.
Hayır, ve zaten bunu önermiyoruz. Geçiş şube şube yürür. Yeni cihaz mevcut yapının yanına takılır, tünel kurulur, trafik parça parça taşınır ve eski cihaz bir süre yapılandırması bozulmadan yerinde bekletilir. Geri dönüş gerekirse yapılacak iş kabloyu geri takmaktır. Her şube geçişinden sonra yazılı bir doğrulama listesi şube sorumlusuyla birlikte yürütülür.
Bulut erişilemez olduğunda cihazlar mevcut yapılandırmayla çalışmaya devam eder; yerel trafik akar, tüneller ayakta kalır ve kullanıcılar çoğunlukla bir şey fark etmez. Kaybedilen şey yönetimdir: o süre boyunca yapılandırma değiştirilemez, yeni cihaz devreye alınamaz ve canlı görünürlük izlenemez. Şubenin kendi internet hattı kesildiğinde ise ikinci hat varsa devir devreye girer; tek hatlı bir şubede internet yoksa hiçbir mimari onu kurtarmaz.
Zor tarafı burası. Yapılandırma üreticinin bulutunda yaşadığı için elinizde başka bir cihaza basabileceğiniz bir yapılandırma dosyası olmaz; yeni yapı pratikte yeniden yazılır. Bunu hafifletmek için tasarım belgelerini marka bağımsız tutuyoruz: adresleme planı, VLAN tablosu, kural gerekçeleri ve tünel topolojisi ayrı bir belgede, panodan bağımsız duruyor. O belgeler elinizdeyken geçiş bir yeniden tasarım değil, bir yeniden uygulama olur.
Evet. Bulut yönetimi kanal planını ve güç ayarını kolaylaştırır ama duvarın betonunu inceltmez. Erişim noktası sayısı ve konumu kat planı üzerinde ölçümle belirlenir; kurulumdan sonra ikinci bir ölçüm yapılır ve iki rapor karşılaştırılır. Otel katları, klinik bekleme alanları ve metal raflı depolar bu ölçümün en çok fark yarattığı yerler. Ölçüm yapılmadan yerleştirilmiş erişim noktaları, panoda yeşil görünürken kullanıcıyı memnun etmez.
İlgili hizmetler
Tasarımdan güvenliğe, kurulumdan sürekli yönetime bütün ağ hizmetlerinin üst sayfası.
Marka kararından önce gelen kısım: IP planı, VLAN şeması ve fiziksel yerleşim.
Bulut dışı kurgular için sürüm kontrollü yapılandırma, VLAN, QoS ve WAN failover.
Şubeler arası ve uzaktan erişim tünelleri; hangi alt ağın tünele gireceği kararı.
Kural seti tasarımı, dışarı açılan portların gerekçelendirilmesi ve düzenli denetim.
Segmentasyon, erişim politikaları ve şube ağlarında olayın yayılmasını sınırlama.
Eşik tasarımı, uyarı akışı, kapasite raporu ve aylık yönetim düzeni.
Ağa hangi cihazın gireceğinin kural setiyle yönetilmesi ve kimlik tabanlı erişim.
Otel ve kafe misafir ağı: karşılama sayfası, doğrulama ve yasal kayıt yükümlülüğü.
Şubelerdeki bilgisayar, yazıcı ve terminal desteğinin ağ yönetimiyle aynı elden yürümesi.
Ağ katmanının ötesinde uç nokta, e-posta ve kimlik tarafındaki koruma.
Kaç lokasyon, kaç kişi bakıyor ve yılda kaç kez yola çıkıyorsunuz — karar bu üç rakamda.
Ekibimizle 30 dakikalık ücretsiz bir keşif görüşmesi planlayın.
Ağ ve siber güvenlik işlerini, uluslararası geçerli Cisco sertifikasyonuna sahip ekiple yürütüyoruz.
Veren kurum: Cisco · Sahibi: Devrim Tunçer
Güvenlik operasyon merkezi (SOC) yetkinliğini belgeleyen sertifika: güvenlik izleme, olay müdahalesi ve ağ saldırılarının analizi. Sızma tespiti, log korelasyonu ve olay sonrası müdahale gerektiren işlerde dayandığımız temel budur.
Cisco eğitim sertifikası · Ocak 2023'te tamamlandı
Ağ temellerini kapsar: yönlendirme, anahtarlama, IP adresleme ve ağ güvenliği. Kurumsal ağ kurulumu ile segmentasyon işlerinde kullandığımız bilgi tabanı.