BT Sistem Yönetimi: Sunucu ve Sanallaştırma

Bir şehrin inşa edilmesini düşünün. Önce imar planı çıkarılır: nerede konut, nerede sanayi, nerede yeşil alan olacağı; şehrin hangi eksende büyüyeceği, hangi mahallelerin hangi kamu hizmetini alacağı bir masa başında karara bağlanır. Bu stratejik katman, kurumsal dünyada BT danışmanlığı ile birebir örtüşür; şehrin omurgasını masa başında belirleyen süreçtir. Plan bittiğinde sıra yollara gelir: mahalleler birbirine nasıl bağlanacak, hangi kavşak sinyalize olacak, acil durum koridorları nasıl açık tutulacak? Şehrin damarları olan ulaşım sistemi, BT tarafında kurumsal network kurulumuna denk düşer; trafiği taşıyan ve tıkanıklığı yöneten katmandır. Peki ya binalar? İmar planı tamamlanmış, yollar asfaltlanmış bir parselin üzerinde yükselen yapıların temeli, taşıyıcı kolonları, elektrik tesisatı, asansörü ve çatısı olmadan şehir yaşamaz. İşte BT sistem yönetimi tam olarak bu binaların inşasıdır: sunucular temel katı, işletim sistemleri taşıyıcı kolonları, sanallaştırma katmanı kat planı, yedekleme sistemleri ise yangın merdiveni ve jeneratördür. Bir şehir yalnızca inşa edilmekle kalmaz; polis devriyesi, yangın müdahale ekipleri ve CCTV ağı olmadan güvenle yaşanmaz. Bu koruyucu katman BT tarafında kurumsal siber güvenlik disiplinine karşılık gelir; her yolun ve her binanın üzerinden geçen ortak bir koruma kuşağı gibi çalışır.

Yıllar önce bir veri merkezinden diğerine taşıdığımız fiziksel sunucuyu yeniden çalıştırdığımızda, hypervisor’ın tamamen gittiğini fark ettim. Kapatmadan önce tüm sistemleri test etmiştik, her şey çalışıyordu. Donanım sağlamdı, diskler yerindeydi; ama üzerindeki sanallaştırma katmanı yoktu. Binaya benzetirsek, temel ve duvarlar ayakta duruyordu ama asansör şaftı ve elektrik kablolaması bir yerde kopmuştu. O an öğrendim ki BT sistem yönetimi sadece donanımı kurmak değil; taşıma, değişiklik ve kriz senaryolarını önceden düşünmek ve her birisi için hazır olmaktır. Bir şehirde binayı inşa etmek ne kadar önemliyse, yıllar içinde bakımını, güçlendirmesini ve gerektiğinde yıkıp yeniden yapmayı planlamak da o kadar kritiktir. Bu projenin tüm detaylarını, 4 saatlik planlı bir kesintiyle tamamlanan veri merkezi taşıma vaka çalışmasında anlatıyoruz.

O günden bu yana hypervisor migrasyonları, yedekleme mimarileri ve merkezi depolama yapılandırmaları dahil pek çok sistem altyapısı projesi yürüttüm. Her projede şunu gördüm: doğru tasarlanmış bir BT sistem yönetimi felaketi önler; yanlış tasarlanmış bir sistem ise felaketi sadece erteler. Bu makalede sunucu seçiminden sanallaştırmaya, Windows Server ekosisteminden yedeklemeye kadar kurumsal BT sistem yönetiminin tüm binalarını katı katı gezeceğiz; hangi tuğlanın nereye konması gerektiğini, hangi tesisatın hangi duvarın arkasından geçmesi icap ettiğini saha tecrübesiyle anlatacağım. Sunucu ve sanallaştırma kararlarını çoktan verdiyseniz doğrudan yedekleme ve felaket kurtarmaya geçebilirsiniz.

Sunucu Seçimi ve Boyutlandırma

Bir kurum için sunucu seçmek, hastane, okul veya belediye binası yaptıracak arsa belirlemeye benzer. Zeminin dayanıklılığı, kaç katlı yapıya müsait olduğu, önümüzdeki on yılda çevresinde nasıl bir yerleşimin oluşacağı, yakın altyapıya erişimi; bugün bakıldığında ikinci derecede görünen ama beş yıl sonra işi yapan ya da bitiren parametrelerdir. Sunucu kararı da katalog karıştırıp en pahalı modele parmak basmak değildir; önce iş yükünü tanımlamak, ardından ona uygun fiziksel-sanal tercihi, form factor ve boyutlandırma disiplinini kurmaktır.

Bu bölümde dört sorunun cevabını sırasıyla arayacağız: fiziksel sunucu mu sanal makine mi, hangi form factor (tower, rack, blade), donanım hangi ölçüde boyutlandırılmalı ve kurumsal filo nasıl standartlandırılmalı? Her dört karar da bugünün ihtiyacını değil, kurumun önümüzdeki 3-5 yıllık yol haritasını referans almak zorundadır.

Fiziksel Sunucu mu, Sanal Makine mi?

İzmir Atatürk Organize Sanayi Bölgesi gibi büyük bir OSB’yi ziyaret edin; iki farklı yerleşim modelinin yan yana durduğunu görürsünüz. Bazı firmalar OSB’den arsa alıp kendi fabrikalarını sıfırdan inşa eder: tüm alan kendilerine aittir, üretim bandını istedikleri gibi kurarlar, güç panosunu ve su hattını kendileri yönetir. Diğerleri ise OSB’nin “ortak kullanım bloğu” adı verilen çoklu kiracılı binalarında yer tutar; elektrik ve su OSB altyapısından gelir, güvenlik, yemekhane ve atık arıtma bloğun tüm kiracıları arasında paylaşılır. Birincisi tam kontrol ve maksimum kapasite sunar, her metrekare için tam maliyet yaratır; ikincisi paylaşılmış altyapı sayesinde birim maliyeti düşürür, karşılığında ortak hizmetlerin kalitesi için OSB yönetimine bağımlı kalır.

Bare metal ve sanal makine tercihi tam olarak bu iki modelin BT’deki karşılığıdır. Bare metal sunucu donanımın tamamını tek bir iş yüküne adar: disk, bellek, CPU başka kimseyle paylaşılmaz; yüksek IOPS isteyen veritabanları, ağır ERP iş yükleri veya gerçek zamanlı üretim kontrol yazılımları için ideal platformdur. Sanal makine (Virtual Machine) ise bir hypervisor katmanı üzerine kurulur; VMware vSphere, Microsoft Hyper-V veya Proxmox VE gibi hypervisor yazılımları tek fiziksel sunucudaki kaynakları (CPU, RAM, depolama, ağ) birden fazla sanal sunucuya adil ve yönetilebilir biçimde dağıtır. Böylece 20 ayrı fiziksel sunucu yerine 20 sanal sunucu tek bir güçlü donanım üzerinde koşar; her biri kendi işletim sistemi ve uygulamasıyla izole kalır, buna rağmen altyapı konsolidasyonu kurumun donanım yatırımını ciddi şekilde düşürür.

Saha gerçeği şu ki modern kurumsal altyapıda bu tartışma “ya o ya bu” değil, “hangi iş yükü nereye” sorusudur. Serçe Bilişim olarak çoğu projede hibrit yaklaşım öneririz: 2-3 güçlü fiziksel sunucu üzerinde hypervisor kurulumu ve konsolide sanal iş yükleri, artı spesifik yüksek-performans ihtiyacı için 1-2 adet bare metal sunucu. Bu kurgu hem lisans ve donanım maliyetini düşürür hem de performans-kritik iş yüklerini güvence altına alır; tıpkı OSB’de hem kendi fabrikasını işleten hem de ortak bloktan ek ofis kiralayan iyi planlanmış bir işletme gibi.

Tower, Rack ve Blade: Hangi Form Factor Ne Zaman?

Kurumsal sunucu filosunun fiziksel formunu anlamak için konut tiplerini düşünün. Müstakil bir ev bağımsızdır: kendi bahçesi, kendi girişi, kendi su ve elektrik bağlantısı vardır; komşularla altyapı paylaşmaz, az katlıdır, yer tutar ama düşük yoğunluklu yerleşim için en pratik çözümdür. Bir apartman dairesi ise ortak bir binada, belirli bir kat planı disiplininde yer alır; birden fazla daire aynı binada düzenli biçimde istiflenir, asansör ve merdiven boşluğu ortaktır, birim yer verimliliği müstakile göre katlarca yüksektir. En yoğun format olan rezidans veya büyük site tipi yerleşim ise bireysel tesisatın yerini merkezi planlamaya bırakır: güç, soğutma, güvenlik, ortak alanlar tek bir yönetim altında toplanır, yüksek yoğunluk ve yoğun yönetim gereksinimi birlikte gelir.

BT dünyasında bu üç yerleşim tipinin tam karşılığı tower, rack ve blade sunuculardır. Tower Sunucu masaüstü bir kasaya benzer, bağımsız ayağa kaldırılır. Sistem odası gerektirmez, herhangi bir dolap veya ofis köşesine yerleştirilebilir; 10-50 çalışanlı küçük ofisler ve tek sunucuyla operasyonu yürütülebilen senaryolar için en pratik seçimdir. Rack Sunucu standart 19 inçlik kabinete kızakla monte edilir; her sunucu “U” (unit) yüksekliğiyle ölçülür (1U, 2U, 4U gibi). Birden fazla sunucu aynı kabinette düzenli istiflenir, sistem odası ve yapılandırılmış kablolama gerektirir; 50 çalışan üzerindeki kurumlar için standart tercih budur. Blade Sunucu ise ince bir kart formunda, “chassis” denen ana kasanın içine takılır. Güç kaynağı, soğutma ve ağ bağlantıları chassis üzerinde ortaklaşa kullanılır; tek chassis içinde 10-20 blade çalışabilir, yüksek yoğunluk ve karmaşık yönetim araçları birlikte gelir.

Saha opinyonu: KOBİ ölçeğinde blade sunucu almak, dört kişilik bir aile için rezidans dairesi almaya benzer; prestij verir ama hem finansal hem operasyonel olarak ciddi bir yüktür. Blade’in getirdiği yoğunluk avantajı, ancak tek chassis içinde en az 8-10 sunucu çalıştırılacaksa anlamlıdır; altındaki özel yönetim yazılımı, chassis bağımlılığı ve yedek parça zinciri KOBİ’nin operasyonel bant genişliğini boşa tüketir. Çoğu orta ölçekli kurum için rack sunucu + hypervisor kombinasyonu hem yer verimliliği hem yönetim sadeliği açısından en dengeli seçimdir; tower ise sahada hala çok geçerli bir seçenektir, yeter ki sistem odası yokluğu ve sunucu sayısının tek haneli kalacağı gerçekçi olarak kabul edilsin.

Donanım Boyutlandırma: CPU, RAM, Disk

Sunucu boyutlandırması üç temel parametrenin kesişiminde belirlenir: CPU çekirdek sayısı, RAM miktarı ve disk IOPS (saniyedeki giriş-çıkış işlem sayısı). Her iş yükü bu üç kaynağa farklı oranlarda yüklenir. SQL Server üzerinde çalışan bir ERP ağırlıkla RAM ve IOPS ister; bir dosya sunucusu disk kapasitesi ve ağ bant genişliği ister; bir terminal sunucu ise kullanıcı başına 1-2 GB RAM ve CPU zamanı tüketir. Doğru boyutlandırma, workload profilinin ortalaması değil, pik yüküdür: mesai başlangıcında aynı anda kimlik doğrulama, e-posta senkronizasyonu ve ERP açılışı birleşince sunucunun dizlerinin kırılmadığı noktaya kadar headroom bırakmak gerekir.

Sahada en sık gördüğüm hata, sunucuyu “bugünkü” iş yüküne göre boyutlandırıp 3-5 yıllık donanım ömrü boyunca kurumun büyüyeceğini unutmaktır. İkinci klasik hata ise yalnızca RAM ve CPU’ya bakıp diskin IOPS performansını görmezden gelmektir; 128 GB RAM’li ama SATA HDD üzerinde çalışan bir veritabanı sunucusu, 32 GB RAM’li NVMe SSD’den daha yavaş cevap verir. Boyutlandırma yapılırken bugünün ihtiyacına %30-50 büyüme payı, diske ise en az bir sınıf yukarı yatırım disiplini kurumun orta vadeli huzurunu belirler.

Kurumsal Sunucu Standartları ve Marka Bağımsızlığı

Ordular neden NATO standart 5.56mm kalibre mermiyi tercih eder? Çünkü farklı birliklerin farklı kalibre silah kullandığı bir senaryo lojistik kabusudur: bir birlik cepheye ulaştığında stoktaki mermi uyumsuz çıkarsa, ne kadar eğitimli asker olursa olsun ateş edemez. Standart kalibre sayesinde ambar bir defa planlanır, yedek parça akışı tek zincirden yürür, eğitim programı tek doktrin üzerine kurulur. Karma filoya sahip bir askeri lojistik sistemi, her çatışmada katlanarak büyüyen operasyonel yüke mahkumdur.

Kurumsal sunucu filosunda da kural aynıdır. Hangi sunucu üreticisinde karar kılacağınız kurumun hakkıdır; ancak seçim yapıldıktan sonra tek marka ve mümkünse tek jenerasyon disiplini uygulanmalıdır. Çünkü her üreticinin yedek disk formatı, RAID controller yönetim arayüzü, BIOS/UEFI davranışı ve kart üstü uzaktan yönetim denetleyicisi farklıdır; o denetleyicinin adı da arayüzü de her üreticide başkadır. Karma filoda aynı ekip birden fazla yönetim paneli öğrenmek, birden fazla yedek stoğu tutmak ve birbiriyle uyumsuz firmware güncelleme prosedürleri yürütmek zorunda kalır. Tek marka filo ise out-of-band management aracı sayesinde fiziksel erişim olmadan BIOS güncellemesi, sanal medya ile işletim sistemi kurulumu ve donanım sağlık izlemesi yapılmasına imkan verir.

Saha gerçeği şu ki, “en iyi marka” diye bir cevap yoktur; yanlış olan seçim değil, kararsızlıktır. Beş yıl içinde üç farklı markadan sunucu almış bir kurumun sistem odasını açtığınızda, her rafta farklı raylar, birbiriyle konuşmayan yönetim araçları ve kimsenin tam hakim olmadığı bir envanter görürsünüz. İşte Serçe Bilişim olarak projelere girdiğimizde ilk yaptığımız iş, hangi markanın seçildiğinden çok hangi disiplinle sürdürüldüğünü sorgulamaktır.

Sanallaştırma: Hypervisor Seçimi ve Kurulumu

Çok kiracılı bir iş merkezini düşünün. Aynı binanın içinde bir kat hukuk bürosu, bir kat muhasebe şirketi, bir kat yazılım ekibi, bir kat da poliklinik olabilir. Her kiracının kendi kapısı, kendi kilidi, kendi personeli ve kendi ticari sırları vardır; kimse komşu katın dosyasını görmez, biri kepenk indirse diğerleri çalışmaya devam eder. Oysa jeneratör, su deposu, asansör, ısıtma ve bina güvenliği ortaktır. Bunca ayrılık ile bunca ortaklık aynı anda nasıl yürür? Bina yönetimi, hangi katın ne kadar güç çekeceğini, asansörün hangi saatte hangi kata öncelik vereceğini ve kimin hangi kapıdan geçebileceğini merkezden tahsis eder. Kiracı komşusunu görmez ama binayı da tek başına tüketemez.

Sanallaştırma, BT dünyasında tam olarak bu bina yönetimi modelinin karşılığıdır. Girişte “sanallaştırma katmanı kat planıdır” demiştik; o kat planını çizen ve uygulayan şey hypervisor denen yazılım katmanıdır. Fiziksel sunucunun CPU, RAM, depolama ve ağ kaynaklarını birden fazla sanal makineye bölüştürür; her sanal makine kendi işletim sistemi, kendi uygulamaları ve kendi güvenlik sınırlarıyla çalışır, ancak donanım altyapısı merkezi olarak yönetilir. Bu sayede 20 fiziksel sunucunun yerini 2-3 güçlü fiziksel sunucu üzerinde çalışan 20 sanal sunucu alır; elektrik, soğutma, sistem odası alanı ve donanım yatırımı ciddi ölçüde azalır. Kat planının nasıl çizildiğini, sanal makinenin donanımı nasıl gördüğünü ve kapasitenin nasıl planlandığını hypervisor sanallaştırma makalemizde ele alıyoruz.

Piyasada üç ana hypervisor platformu KOBİ ve kurumsal ölçekte ağırlıklı olarak kullanılır: VMware vSphere (ESXi), Microsoft Hyper-V ve Proxmox VE. Her üçü de aynı temel mantıkla çalışır; ancak lisans modeli, yönetim araçları, kurum ekosistemiyle entegrasyon ve topluluk desteği açısından farklı yerlerde dururlar. Kurum için doğru hypervisor seçimi, sahip olunan Windows Server lisans stoğundan Linux ekibinin yetkinliğine, veri merkezi büyüklüğünden felaket kurtarma stratejisine kadar birkaç parametrenin kesişiminde belirlenir.

VMware vSphere / ESXi

Uluslararası bir taahhüt firmasının nasıl çalıştığını düşünün. Aynı firma İstanbul’da da, Frankfurt’ta da, Singapur’da da aynı detay çizimini okur; aynı malzeme şartnamesini uygular, aynı yedek parça kodlarını bilir, saha şefinin sertifikası her ülkede geçerlidir. Bir kolon detayı sorulduğunda cevap kişiye göre değil klasöre göre değişir. Bu disiplinin bedeli vardır: teklifi mahalle müteahhidinden belirgin biçimde pahalıdır. Karşılığında öngörülebilirlik, sertifikasyon zinciri ve arayınca gerçekten cevap veren bir destek hattı gelir.

VMware vSphere, kurumsal sanallaştırmada aynı taahhüt firmasının kıvamındadır. ESXi çekirdek hypervisor çalışma katmanıdır; doğrudan donanım üzerine (bare metal) kurulur, bir işletim sistemi değildir. vCenter Server ise merkezi yönetim platformudur; onlarca ESXi sunucuyu tek panelden yönetir, vMotion (çalışan sanal makineyi kapatmadan başka fiziksel sunucuya taşıma), HA (High Availability) ve DRS (Distributed Resource Scheduler) gibi kurumsal özellikleri etkinleştirir. vSAN ile yazılım tanımlı depolama, NSX ile ağ sanallaştırması, vRealize ile operasyon otomasyonu gibi ekosistem ürünleri VMware’in derinliğini büyük kurum senaryolarında net biçimde gösterir.

Saha gerçeği şu: VMware, son 15 yıldır kurumsal sanallaştırmanın de-facto standardı olarak konumlandı. Ancak 2023 sonrası Broadcom satın alımıyla lisans modeli ciddi biçimde değişti; abonelik zorunluluğu ve paket konsolidasyonu, özellikle KOBİ ölçeğindeki müşterileri yeniden hesap yapmaya itti. Büyük kurumlar için VMware hala güvenli tercih olmaya devam ediyor; global destek, partner ekosistemi ve yetişmiş personel havuzu bu pozisyonu ayakta tutuyor. KOBİ ölçeğinde ise artık “sadece standart olduğu için VMware seçmek” ekonomik bir refleks olmaktan çıktı; 3-4 host ve 20-30 sanal makine çalıştıracak bir ortamın Hyper-V veya Proxmox ile çok daha düşük toplam maliyette yürütülmesi pekala mümkündür.

Microsoft Hyper-V

Hyper-V, Microsoft Windows Server lisansının içinde dahil gelen hypervisor rolüdür. Windows Server Standard veya Datacenter lisansına sahip kurumlar için ek sanallaştırma lisansı satın alma zorunluluğu yoktur. Active Directory ile native entegrasyon, Failover Cluster ile yüksek erişilebilirlik, Cluster Shared Volumes (CSV) ile ortak depolama yönetimi ve System Center Virtual Machine Manager (SCVMM) ile çok host’lu konsolide yönetim sunar. Hyper-V Manager konsolu üzerinden tek host yönetimi yapılır; kurumsal ölçekte SCVMM veya üçüncü taraf araçlarla genişletilir.

Windows ağırlıklı ekosistemlerde Hyper-V ekonomik olarak fark yaratır. Kurum zaten Windows Server lisans stoğuna sahipse, Active Directory yönetiyorsa ve ekibin yetkinliği Windows platformu üzerindeyse ek VMware lisansı satın almak çoğu zaman gereksizdir. Sahada gördüğüm eksi yönü, Hyper-V’nin Linux misafir sistemlerini teknik olarak desteklese de ekosistem araçlarının VMware kadar olgun olmamasıdır; yoğun Linux iş yükü taşıyan veya karışık işletim sistemi ortamı yöneten kurumlarda küçük operasyonel sürtünmeler birikir. Saf Windows ortamında ise pozisyon çok güçlüdür; AD, DNS ve GPO ile entegre sanallaştırma yönetimi neredeyse tek panel deneyimi sunar.

Proxmox VE

Yıllardır aktif amatör telsizci olarak AFAD saha operasyonlarında gönüllü çalışırım. Bu topluluğun ilk bakışta görünen yapısı şudur: resmi bir şirket yoktur, merkez ofis yoktur, kimse aylık fatura kesmez; ancak bir afet anında koordinasyon kurulur, repeater istasyonları devreye girer, yüzlerce gönüllü standart bir haberleşme protokolüyle aynı frekansta çalışır. Temelde açık standart, paylaşılan bilgi, gönüllü uzmanlık ve karşılıklı destek vardır. Bir aksaklık yaşandığında forum, WhatsApp grupları ve saha büyükleri cevap verir; maliyet sıfıra yakındır, ancak sistemin ayakta kalması topluluk disiplinine bağlıdır.

Proxmox VE, açık kaynak sanallaştırma platformudur; Debian Linux üzerine kurulu KVM (Kernel-based Virtual Machine) ve LXC (Linux Containers) teknolojilerini tek web arayüzü altında birleştirir. Kurumsal düzeyde cluster yapısı desteklenir, Ceph veya ZFS ile ortak depolama entegre edilir, yedekleme için yerleşik Proxmox Backup Server bileşeni sunulur. Web arayüzünden onlarca host ve yüzlerce sanal makine tek panelden yönetilebilir; VMware vSphere veya Hyper-V’nin sunduğu kurumsal özelliklerin büyük bölümü açık kaynak olarak gelir. İsteğe bağlı yıllık abonelik satın alınırsa kurumsal repo ve ticari destek devreye girer.

Saha gerçeği şu: Proxmox, KOBİ ve orta ölçekli kurumlar için yazılım maliyeti açısından rakipsizdir. Ancak topluluk destekli açık kaynak ürününün doğası gereği “aradığın partner telefonda cevap veriyor mu” sorusu VMware veya Microsoft destek kanallarından farklı işler. Bu nedenle Proxmox’u başarıyla kullanan kurumların ortak noktası, ya iç ekipte Linux yetkinliği ya da sözleşmeli danışman desteğidir. Serçe Bilişim olarak Proxmox kurulumlarını özellikle GLPI, Zabbix ve Cacti gibi Linux tabanlı yönetim araçlarıyla birlikte konumlandırırız; lisans maliyetini düşürürken kurumun açık kaynak yetkinliğini adım adım büyütürüz. Doğru ekiple Proxmox, kurumsal sanallaştırmada tam donanımlı bir alternatif olarak çalışır; yanlış ekiple ise topluluk forumlarına kilitli kalır.

Windows Server Ekosistemi

Kurumsal Windows altyapısı tek bir üründen değil, aynı domain çatısı altında birbirine geçmiş 10-15 ayrı rolden oluşur. Active Directory kimliği yönetir, DNS ad çözer, DHCP adres dağıtır, File Server ve DFS dosyayı taşır, Print Server baskıyı merkezileştirir, NPS ağa girişi denetler, Group Policy masaüstünü standartlaştırır. Windows Server’ın rakiplerine karşı asıl üstünlüğü tek bir rolün üstün olması değil, bu rollerin birbirini varsayarak çalışmasıdır: DHCP dağıttığı adresi DNS’e yazar, DNS kaydı domain oturumunu mümkün kılar, oturum GPO’yu tetikler.

Bu bağımlılık zinciri aynı zamanda kurumsal Windows kurulumlarının en kırılgan yanıdır. Sahada gördüğüm arızaların büyük kısmı tek bir rolün bozulmasından değil, iki rol arasındaki varsayımın sessizce kopmasından çıkar: birincil DNS olarak Domain Controller yerine 8.8.8.8 yazılmış bir istemci, kimlik doğrulayamadığında hata mesajında DNS’ten hiç bahsetmez. Bu yüzden Windows tarafını rol rol değil, katman olarak kurmak gerekir.

Hangi rolün ne işe yaradığı, hangi sürümün hangi ölçeğe uygun olduğu, çekirdek bazlı lisanslama ile CAL modelinin nasıl hesaplandığı ve destek yaşam döngüsünün yükseltme planınızı nasıl belirlediği Windows Server rehberimizde ele alınıyor.

Zincirin dört halkası ise kendi rehberinde açılıyor. Orman ve domain tasarımının neye göre kurulduğu, OU ağacının nasıl kurgulandığı, GPO’ların hangi sırayla işlediği ve kimlik katmanının nasıl sıkılaştırıldığı Active Directory rehberinde toplanıyor. Sıfırdan bir sunucuyu ayağa kaldırırken sürüm seçimi, disk düzeni, statik IP ve hostname kararlarının hangi sırayla verilmesi gerektiği Windows Server kurulum rehberinde anlatılıyor. Scope planlaması, rezervasyon disiplini ve iki sunuculu failover kurgusu ise DHCP kurulum rehberinde yer alıyor. Kurumun kendi sertifika otoritesini kurarak iç servislerini şifreli konuşturması, sihirbazdaki geri alınamayan kararlar ve kurulumun gerçekten çalıştığının nasıl doğrulanacağı AD CS kurulum rehberinde anlatılıyor. Bütün bu rollerin sunucuya hiç bağlanmadan, yöneticinin kendi bilgisayarından yönetilmesini sağlayan konsolların kurulumu ise RSAT kurulum rehberinde duruyor.

Linux Sunucu Altyapısı

Bir şehrin yüzeyinde gördüğümüz binaların, caddelerin ve park alanlarının altında çoğu zaman hiç dikkat etmediğimiz bir altyapı uzanır. Yeraltı su hatları, kanalizasyon kanalları, doğalgaz boruları, elektrik kabloları ve fiber omurgalar; şehir bunlar olmadan tek gün yaşayamaz, ancak vatandaşın günlük hayatında genellikle görünmez. Bu altyapıyı tasarlayan mühendisler reklam panolarında yer almaz, çoğu belediye duyurusunda adları geçmez; işleri doğru yapıldığında zaten kimse yokluğunu hissetmez. Bir arıza çıkmadığı sürece herkes akan suyu, yanan ışığı ve çalışan fiberi olağan kabul eder.

Kurumsal BT altyapısında Linux sunucular tam olarak bu sessiz altyapı rolünü üstlenir. Kurumun ana iş uygulaması Windows tarafında koşuyor olabilir, ancak arka planda çalışan izleme sistemleri (Zabbix, Cacti), envanter ve helpdesk platformları (GLPI), web sunucuları (Nginx, Apache), veritabanları (PostgreSQL, MariaDB), dosya/medya servisleri ve DNS/mail cache’leri büyük ölçüde Linux üzerinde yaşar. Dünyadaki web sunucularının büyük çoğunluğu, konteyner platformlarının neredeyse tamamı ve kurumsal bulut altyapısının omurgası Linux üzerinde koşar.

Sahada Serçe Bilişim olarak Ubuntu Server’ı KOBİ ve orta ölçekli kurumlar için varsayılan Linux tercihi yapıyoruz. Sebep teknik üstünlük değil ekosistem genişliğidir: Docker dokümantasyonu Ubuntu üstünde örneklenir, Kubernetes kılavuzları Ubuntu referansı verir, GLPI’dan PostgreSQL’e kadar ihtiyaç duyduğumuz her paket Ubuntu depolarında güncel tutulur, ve bir şey ters gittiğinde aynı hatayı yaşamış on kişi forumda cevabı çoktan bırakmıştır. Bugün çalışan kurulumlarımızın çoğu 24.04 LTS üzerinde; Nisan 2026’da çıkan 26.04 LTS ise yeni projelerde desteği en uzağa taşıyan sürüm, standart bakımı 2031’e kadar sürüyor. Dağıtım ailelerinin karşılaştırması, LTS ve Ubuntu Pro takvimi, paket ve depo yönetimi, systemd ile servis disiplini ve katmanlı sıkılaştırmanın tamamı Ubuntu Server rehberimizde duruyor. Sunucuyu sıfırdan ayağa kaldıracaksanız, kurulum medyasının başlatılmasından statik IP ve LVM’li disk düzenine kadar bütün adımlar ekran görüntüleriyle Ubuntu Server kurulumu rehberinde anlatılıyor.

Bu makalenin kapsamı açısından sıkılaştırmada tek bir şeyi vurgulamak istiyorum, çünkü sahada en sık kırılan yer orası: sıkılaştırma bir kurulum adımı değil, takvime bağlı bir disiplindir. En sık karşılaştığım hata, Linux sunucu kurulumunun apt install ile bitirildiği ve sıkılaştırmanın “sonra yaparız” rafına kaldırıldığı senaryodur; “sonra” çoğu zaman hiç gelmez. İkinci klasik hata, servis hesapları ile günlük yönetici hesabının ayrılmamasıdır; sistem yöneticisi saatlerce root kabuğunda çalışır, audit log tek isim altında birikir, kim ne zaman ne yaptı izlenemez hale gelir. Üçüncüsü sessiz olanıdır: saat. Zaman kayması yaşayan bir Linux sunucu, Active Directory entegrasyonunda Kerberos bilet doğrulamasından TLS sertifika kontrolüne kadar pek çok yerde sebebi kendini göstermeyen hatalar üretir; bu sunucuların saatini tek noktadan besleyecek iç NTP sunucusu kurulumunu ayrı bir rehberde ele alıyoruz. Aynı disiplinin log tarafındaki karşılığı, kayıtları sunucunun kendi diskinden çıkarıp merkezi bir syslog sunucusunda toplamaktır; ele geçirilen bir makinede ilk silinen şey kendi loglarıdır.

Linux’un bu ortamdaki rolü kimliğin tüketicisi olmakla da sınırlı değildir: Samba’nın AD DC rolüyle bir Ubuntu sunucu domainin kendisini barındırabilir, Windows istemciler ona bir Windows denetleyicisine katılır gibi katılır. Kurulum kararlarını ve provizyon sonrası doğrulamayı Samba AD DC kurulumu rehberimizde ölçümleriyle ele alıyoruz.

Bu sunucuların üzerinde çalışan araç seti de büyük ölçüde Linux tarafındadır: envanter ve helpdesk için GLPI, altyapı izleme için Zabbix, uzun vadeli bant genişliği trendi için Cacti, yönetici panosu için Grafana. Sahada gördüğüm en sık hata bunların her birini “var olsun” diye kurup sahip ve alarm politikası olmadan bırakmaktır. Bildirim kurulur, herkes alır, kimse bakmaz; bir yıl içinde alarm sesleri gürültüye dönüşür ve kritik olay geldiğinde kimse farkına varmaz. Doğru yaklaşım her aracın net bir sahibini belirlemek, alarmları kritik/uyarı/bilgilendirme seviyelerine ayırmak ve yalnızca kritik olanları aktif bildirim kanalına yönlendirmektir. Araçları çoğaltmaktan çok, her aracın hangi soruyu cevapladığı konusunda netlik yaratmak asıl saha disiplinidir.

Windows Server mı Linux mu: Farklar ve Hangi İş Yükü Nereye?

Windows Server ile Linux arasındaki asıl fark hız, güvenlik veya kararlılık değil; her birinin etrafında kurulmuş ekosistemdir. Bu yüzden doğru soru “hangisi daha iyi” değil, “şu anda şehrin hangi katmanını inşa ediyorum” sorusudur. Yukarıdaki iki bölüm aslında tam olarak bunu anlattı: Windows tarafı yer üstündeki kamu binalarıdır, vatandaşın kimliğini, dosyasını ve yetkisini tutar; Linux tarafı yeraltı altyapısıdır, kimse görmez ama su, elektrik ve fiber oradan akar. Su hattını binanın salonundan geçirmezsiniz; nüfus müdürlüğünü de kanalizasyon galerisine kurmazsınız.

Fark pratikte dört yerde somutlaşır. Kimlik ve masaüstü yönetimi Windows’un rakipsiz olduğu alandır; oturum açma, grup yetkisi, politika dağıtımı ve dosya izinleri tek bir domain zincirine bağlıdır ve bu zinciri Linux tarafında taklit etmek mümkün olsa da bakım maliyeti hızla katlanır. Lisans modeli ikinci ayrımdır: Windows’ta çekirdek lisansı artı CAL kalemi vardır, Linux’ta bu satır sıfırdır. Ancak maliyet yok olmaz, yalnızca ekip yetkinliğine taşınır. Yönetim yüzeyi üçüncüsüdür; Windows arayüzüyle hızlı başlatır, Linux komut satırı ve yapılandırma dosyasıyla daha yavaş başlatır ama çok daha kolay otomatikleştirir. Dördüncüsü güncelleme davranışıdır: Windows tarafında yama çoğu zaman bir yeniden başlatma penceresi ister, Linux tarafında pek çok servis kesintisiz güncellenir ve bu tek başına 7x24 çalışan bir iş yükünün platformunu belirleyebilir.

Sahada iki klasik hata görüyorum. Birincisi Linux’u “lisans yok, bedava” diye seçmektir; fatura kaybolmaz, sadece ekibe taşınır. Sürdürecek yetkinlik yoksa üç yıl sonra elde kimsenin dokunmaya cesaret edemediği, güncellemesi geçmiş bir sunucu kalır. İkincisi Windows’u “zaten biliyoruz” diye her yere yığmaktır; doğal olarak Linux’ta çalışan izleme ve envanter araçlarını Windows’a taşımak hem CAL hem kaynak faturası üretir, karşılığında kayda değer bir yönetim kolaylığı getirmez. Çoğu kurumda sağlıklı denge yüzde 30-70 ile 60-40 arasında bir karmadır ve bu oranı ideoloji değil, hangi ekibin hangi katmanı gerçekten sürdürebildiği belirler. Platform kararında sorulacak tek soru şudur: bu sunucuya önümüzdeki beş yıl boyunca kim bakacak?

Depolama Sistemleri: NAS, SAN ve DAS

Bir kurumun depolama mimarisi, aslında bir arşiv planıyla aynı soruya cevap arar: hangi belge, hangi veri, hangi ölçekte ve kaç kişinin erişimine açık olarak nerede tutulmalıdır? Tek ofisli bir avukatlık bürosu kendi masa çekmecesine dosyalarını koyar; on avukatlı bir hukuk firması paylaşımlı bir dosya odası kurar; büyük bir hukuk zincirinin merkezi arşiv sistemi ise artık fiziksel dolapla sınırlı kalmaz, yüksek kapasiteli bir merkezi depolama ve dağıtım ağı gerektirir. Her ölçeğin kendi çözümü vardır; küçük ofise büyük depo çözümü yükselen maliyet, büyük kuruma çekmece seviyesi çözüm ise yetersiz kapasite demektir.

BT depolama mimarisi üç temel yaklaşıma dayanır: DAS (Direct Attached Storage), NAS (Network Attached Storage) ve SAN (Storage Area Network). Üçü de aynı temel ihtiyaca hizmet eder (veriyi güvenli, hızlı ve yetkili biçimde saklamak); ancak farklı ölçek ve erişim modelleri sunar. Kurumun günlük iş yükü, çalışan sayısı, sunucu sayısı ve yüksek erişilebilirlik beklentisi bu üçlü arasındaki seçimi belirler.

DAS (Direct Attached Storage)

Evde kendi odanızdaki çekmece dolabını düşünün. İçindeki eşyalara yalnızca siz erişirsiniz; çekmece doğrudan odanızda durur, kapı arkasında veya koridorda değildir. Bir şey aradığınızda odadan çıkmanız gerekmez, uzantı kablosu veya ağ bağlantısı gerekmez, ulaşım mesafesi sıfırdır. Ancak başka biri dolabınıza erişmek isterse ya sizden izin istemesi ya da fiziksel olarak odanıza girmesi gerekir; paylaşım doğal olarak kısıtlıdır. Bu model küçük ölçekli, kişisel kullanım için en ekonomik ve en hızlı çözümdür; ancak ölçek büyüdüğünde herkesin kendi çekmecesi ayrı duran bir ev, çalışma verimini düşürür.

DAS (Direct Attached Storage) depolama aygıtının doğrudan tek bir sunucuya bağlandığı modeldir; sunucu içindeki dahili diskler (SATA, SAS, NVMe) veya sunucuya doğrudan bağlı harici disk kasaları bu kategoriye girer. Ağ üzerinden paylaşım yoktur, veri yalnızca o sunucu tarafından erişilebilir. SAS kontrol kartı üzerinden RAID yapılandırması kurulur; RAID 1, 5, 6, 10 gibi tipler veri dayanıklılığını ve performansını belirler. Bağlantı yolu kısa olduğundan gecikme düşüktür; bant genişliği doğrudan kontrol kartının yeteneği kadardır. Kurulum basittir, ek bir ağ cihazı veya protokol gerektirmez; tek sunucu artı yerel disk setinden ibarettir.

DAS’ın yeri küçük ofislerdeki tek sunuculu kurulumlar, laboratuvar ortamları ve özel bir iş yükünün yalnızca o sunucuya bağlı çalışması gereken senaryolardır. Sahada en sık gördüğüm DAS hatası, veriler büyüdükçe ve birden fazla sunucu DAS’a erişmek istediğinde sistemin doğal sınırına çarpmaktır; ikinci sunucuya veri aktarımı için SMB üzerinden manuel paylaşım kurulur, zamanla “aslında NAS olmalıydı” pişmanlığıyla büyüme krizi yaşanır. İkinci klasik hata, RAID’i yedekleme yerine koymaktır; RAID bir disk arızasına karşı veri dayanıklılığı sağlar, ancak yanlışlıkla silme, fidye yazılımı veya RAID controller arızası için yedekleme yerine geçmez. Doğru yaklaşım, DAS kurulumlarını “tek sunucu artı özel iş yükü” senaryosuyla sınırlı tutmak ve kurum bir sunucudan ikinci sunucuya büyüdüğü an NAS veya SAN planlamaya geçmektir.

NAS (Network Attached Storage)

Bir reklam ajansını hayal edin. Yaratıcı ekip Photoshop dosyası üretiyor, medya planlama Excel raporu hazırlıyor, müşteri ilişkileri sunum çıkarıyor. Herkesin kendi masası var ama bir de ortak bir dijital kitaplık: çalışanların “ağ klasörü” dediği paylaşımlı sürücü. Bu kitaplığa fiziksel olarak gitmek gerekmiyor; ofisteki her bilgisayardan, hatta evden VPN ile, aynı raflara ulaşılıyor. Kim hangi klasöre girebilir, kim sadece okur kim yazar, kapı görevlisi denetliyor. İşte NAS bu kitaplığın kendisi: ağa takılı, rafları olan, içindeki dosyaları dosya düzeyinde paylaştıran bir cihaz.

NAS, DAS’tan temel olarak erişim katmanında ayrışır. DAS’ta tek bir sunucu disk blokları üzerinde doğrudan çalışırken, NAS kendi işletim sistemi üzerinde bir dosya sistemi çalıştırır ve ağ üzerinden dosya düzeyinde paylaşım yapar. Windows tarafındaki istemciler SMB/CIFS, Linux/Unix istemcileri NFS, Mac kullanıcıları AFP veya SMB ile bağlanır. NAS üreticilerinin kendi işletim sistemleri kullanıcı ve grup yönetimi, ACL tabanlı yetkilendirme, kotalar, sürüm takibi (BTRFS snapshot), LDAP/Active Directory entegrasyonu ve kutunun kendi çapraz yedekleme araçlarını sunar. Donanım tarafında 2-bay’den 24-bay’e kadar modeller, SATA/SAS hot-swap disk yuvaları, ZFS veya BTRFS destekli RAID (SHR, RAID 5/6/10) ve 10GbE ağ seçenekleri bulunur. Aynı klasörü hem Windows hem Linux tarafına açan kurulumlarda dikkat edilecek nokta kutunun kendisi değil, iki protokolün kullanıcıyı farklı şeyle tanımasıdır: SMB tarafı dizin kimliğine bakar, NFS tarafı sayısal bir numaraya. Bu ayrımın izin çakışmalarını nasıl doğurduğunu NFS nedir rehberimizde ele alıyoruz.

KOBİ ölçeğinde NAS, dosya sunucusu ile yedekleme hedefini tek cihazda birleştirdiği için en hızlı geri dönen yatırımlardan biridir. İki üretici arasında seçim yaparken kararın kilit noktası genelde fiyat değil yazılım ekosistemidir: kimi üretici daha oturmuş bir arayüz ve sabır gerektirmeyen güncelleme disiplini sunar, kimi daha zengin donanım yelpazesi ve kutu üstünde sanallaştırma verir. Ama büyük bir uyarı: üretim ortamında tüketici sınıfı NAS kullanılmamalı, ve bu ayrımı model adından değil diskin teknolojisinden okuyun; düşük yazma dayanıklılığı olan masaüstü sınıfı diskler ve kiremitleme (SMR) kullanan modeller RAID rebuild sırasında patlayabilir. Ve en önemlisi: BTRFS snapshot’ları yedek değildir, aynı diskte yaşarlar. Snapshot’ları mutlaka harici bir hedefe (ikinci NAS, bulut veya LTO teyp) replike edecek bir disiplin kurulmalıdır.

SAN (Storage Area Network)

Başakşehir Çam ve Sakura Şehir Hastanesi gibi büyük kampüs hastanelerini dolaşırken duvarların içinden geçen pnömatik tüp sistemini görmüşsünüzdür. Acil servisten alınan kan tüpü, laboratuvara giden yoldaki hemşirenin elinde değildir; tavanın üstünde uzanan özel bir boru ağında, vakum basıncıyla saniyeler içinde laboratuvara iner. Numunenin kim tarafından gönderildiği, hangi kattan geldiği tüpün üzerinde yazılı; sistem sadece “şu adres” ve “bu kapsül” diye düşünür. Hasta ve ziyaretçi trafiğinden tamamen ayrı bir altyapı, sadece kritik transferler için. SAN bu resmin dijital karşılığıdır: sunucular ile depolama dizisi arasındaki, kullanıcı ağından izole edilmiş özel bir depolama fabric’i.

SAN’ı NAS’tan ayıran temel fark erişim katmanıdır. NAS dosya düzeyinde paylaşım yapar (yönetim sunucuda), SAN blok düzeyinde çalışır: sunucunun işletim sistemi SAN üzerinden gelen LUN’u (Logical Unit Number) sanki yerel bir SCSI diski gibi görür, üzerinde kendi dosya sistemini (NTFS, VMFS, XFS) kurar. Fiziksel taşıma iki yoldan biriyle olur: Fibre Channel (FC) ayrı HBA kartları, FC anahtarları ve kendine özgü fabric protokolüyle 16/32/64 Gb/s hızda düşük latency sunar; iSCSI standart Ethernet üzerinde çalışır, ucuzdur ama jumbo frames, ayrı VLAN ve QoS disiplini gerektirir. Kritik kavramlar: zoning (hangi sunucu hangi LUN’u görebilir), masking (erişim kontrolü), multipath I/O (her sunucunun depolamaya iki bağımsız yoldan ulaşması), dual fabric topolojisi (SAN A / SAN B ayrılığı) ve senkron/asenkron replication. VMware vSphere HA, vMotion ve DRS gibi kurumsal sanallaştırma özellikleri blok düzeyinde shared storage gerektirdiği için SAN genelde bu senaryolarda zorunlu hale gelir. Günümüzde kurumsal all-flash diziler ve NVMe-oF protokolü standart hale gelmiştir.

SAN satın alma kararında iki sık yapılan hata vardır. Birincisi ölçek hatası: 3-5 sunucusu olan bir KOBİ için SAN genelde overkill’dir; bu noktada kurumsal bir NAS veya hiperkonverjan çözüm (VMware vSAN, Nutanix, Proxmox + Ceph) aynı işlevi üçte bir maliyetle yerine getirir. İkincisi operasyon hatası: “SAN kurduk, gerisi kolay” zihniyeti felaketle sonuçlanır. SAN yöneticiliği; zoning diyagramı tutan, firmware uyumluluk matrisi (VMware HCL) takip eden, multipath konfigürasyonunu aylık denetleyen ayrı bir disiplindir. Tek SAN controller failover’ı her sabah 09:00’da test edilmiyorsa, o SAN üretim ortamı için hazır sayılmaz. Bir de küçük bir hatırlatma: FC’nin prestijine kapılıp iSCSI’yi küçümsemeyin; 10/25/40 GbE Ethernet üzerinde iyi yapılandırılmış bir iSCSI, çoğu iş yükü için FC ile aynı cümlede anılabilir performans verir ve toplam sahip olma maliyetini yarıya indirir.

Yedekleme ve Felaket Kurtarma

6 Şubat 2023 sabahı Kahramanmaraş merkezli depremlerde kaybettiğimiz on binlerce canımızı saygıyla, rahmetle anıyoruz. Tüm milletimizin başı sağ olsun.

O elim felaketin sonraki haftalarında bölgedeki kurumsal BT için acı bir gerçek de ortaya çıktı. Hatay, Adıyaman ve Malatya’daki şirketlerin bir kısmı operasyona günler içinde döndü; bir kısmı aylarca müşteri veritabanına, finansal kayıtlara, hukuki sözleşmelere ulaşamadı. Aradaki tek fark offsite yedekleme disipliniydi. Yedeği olan firma, kendi binası yerinde olmasa bile bankadaki nakdiyle başka bir şehirde ofis tutabildi, sunucusunu yeniden kurabildi, bulut yedeğinden veriyi geri yükleyip müşteri faturasını kesmeye, personeline maaş ödemeye devam edebildi. Yedeği olmayan firma ise nakdi hesapta dursa bile hangi müşteriye ne kadar alacağı olduğunu, hangi tedarikçiye borcu bittiğini, personel bordrolarını, imzalı sözleşmeleri hatırlayamadı. İşi ayağa kaldırmak için parası vardı; ama işin kendisinin kayıtları yoktu.

Ben AFAD’da aldığım eğitimi doğrudan Van depreminde Azra bebeği enkazdan çıkaran arama-kurtarma ekibinden aldım. O eğitimde bir insanın can varlığıyla birlikte mal varlığını da nasıl bir anda kaybedebildiğinden bahsettiler. Ekip enkaz altında can kurtarmaya çalışırken, bazı yakınların operasyondaki personele “benim akrabam buranın altında kaldı” deyip aslında geleneksel kasadaki altınları kurtarmaya yönlendirdiğini de anlattılar. O anlatım bende kalıcı bir iz bıraktı: yarınlarımız çok değerli. Para kazandığımız iş yerimiz, ailemizin yaşadığı evimiz; bunların her biri belki de bir ömrün amacıdır. Felaketlerin önlemini önceden almak zorundayız.

Yastık altında tutulan altın komisyonsuzdur, rahattır, elimizin altındadır; ama bir hırsız girdiğinde ya da enkaz altında kaldığında bir gecede kaybolabilir. Yedeksiz çalışmak da bunun bire bir dijital karşılığıdır. Bir hacker ransomware ile kapıyı kırar, ya da deprem, yangın, sel ile sunucu odası çöker; kurumun yıllarca biriktirdiği varlık dakikalar içinde yok olur. Bankaya yatırılmış altın her ay kasa ücretine mâl olur; offsite yedek de aylık bir maliyet ister. Ödediğiniz rakam “fazladan yedek” bedeli değildir; felaket anında ayakta kalma bedelidir. Tekrardan o elim günde kaybettiklerimizi rahmetle anıyor, tüm milletimize sabır ve dayanıklılık diliyoruz.

Yedekleme Stratejisi: 3-2-1’den 3-2-1-1-0’a

Ailenin çocukluk fotoğraflarını nasıl sakladığınızı düşünün. Salonun dolabında bir albüm duruyor, telefonunuzda aynı fotoğraflar var, bir de bulutta senkronize bir kopya. Üç farklı kopya, iki farklı medya ve bir kopya evin dışında. Bu, farkında olmadan uygulanan bir yedekleme stratejisidir; kurumsal BT’de buna 3-2-1 kuralı diyoruz: en az 3 kopya, 2 farklı medya türü, 1 kopya başka bir coğrafi lokasyonda.

Bugünün gerçekliğinde 3-2-1 artık taban kuraldır, tavan değil. Fidye yazılımı sonrası 3-2-1-1-0 güncel standart kabul edilir: ek bir “1” değiştirilemez (immutable) veya çevrimdışı kopyayı, sondaki “0” ise geri yükleme testinde sıfır hatayı ifade eder. Çünkü fidye yazılımı modern yedekleme depolarını hedef alır; erişilebilir bir yedek, şifrelenebilir bir yedektir.

Kuralın beş hanesinin tek tek ne anlama geldiğini, yedek türlerini (tam, artımlı, fark) ve “aynı RAID havuzundaki iki disk iki medya sayılmaz” gibi sık düşülen tuzakları kurumsal veri yedekleme ve felaket kurtarma rehberimizde ayrıntılı olarak ele alıyoruz.

RTO ve RPO: İki Kritik Metrik

Kasım sonu, Kara Cuma kampanyası, akşam 21:47. Büyük bir Türk e-ticaret sitesinin çekirdek sipariş servisi aniden cevap vermiyor, sepete ürün eklenemiyor. O anda iki farklı saatin tik tak sesi başlar. Birinci saat ticari saattir: sistem ne kadar sürede geri gelmeli? Her geçen dakika yüzbinlerce liralık ciro kaybediliyor, rakip siteye trafik kaçıyor. İkinci saat veritabanı saatidir: sistem geri geldiğinde en son hangi ana kadar olan veriye güvenebiliriz? İşte RTO birinci saatin, RPO ikinci saatin adıdır.

RTO (Recovery Time Objective) sistemin kabul edilebilir bir seviyeye dönmesi için üst limittir. RPO (Recovery Point Objective) ise ne kadar veri kaybının tolere edilebileceğini tanımlar. Bu iki sayı yedekleme ve replikasyon mimarisini birebir belirler; ve en kritiği, ikisi de BT kararı değil iş birimi kararıdır.

Buradaki en sinsi hata, kağıt üzerindeki RTO ile gerçek RTO arasındaki uçurumdur. Planınızda “otuz dakika” yazabilirsiniz; hiç tatbikat yapmadıysanız gerçek süreniz saatlerdir ve bunu krizin ilk dakikasında öğrenirsiniz. Yazılan bir hedeftir, ölçülen ise gerçek.

Yedekleme Araçları: Ölçeğe Göre Seçim

Taşınıyorsunuz. Öğrenci evinden geçişte bir arkadaştan pikap ödünç alırsınız; ev hayatına oturmuş bir aileyseniz mahalle nakliye firması tutarsınız; bir holdingseniz kurumsal nakliyat kontratı imzalarsınız. Yedekleme araçları tam olarak bu spektrumu işgal eder. “En iyi yedekleme aracı” diye tek bir cevap yoktur; hangi ölçekte ve hangi hizmet seviyesiyle çalıştığınıza bağlıdır.

Pratikte üç kategori vardır. Açık kaynak seviyesi: rsync, BorgBackup, Restic, Bacula/Bareos. Düşük maliyetli ve esnektir, ama kurulum ve disiplin ekibe kalır. Orta ölçek ticari araçlar: entegre ajan, fidye yazılımı koruması ve bulut hedefi sunan, KOBİ ve yönetilen hizmet sağlayıcılara yönelik ürünler. Kurumsal platformlar: sanallaştırma, fiziksel sunucu, bulut ve SaaS iş yüklerini tek konsoldan kapsayan, değiştirilemez depolama ve otomatik doğrulama sunan sistemler. Bulut hedefi tarafında S3 Object Lock benzeri nesne kilidi özellikleri, fidye yazılımı çağının güvencesidir.

Kaba yön verici: 10 sunucuya kadar açık kaynak ve sıkı disiplin; 10-100 arası ticari bir ürün; 100 üstü kurumsal platform. Hangi ürünü seçerseniz seçin değişmeyen tek şey şu: hiçbir araç geri yükleme testinizi sizin yerinize yapmaz. Ürünlerin otomatik doğrulama işlevleri yardımcıdır, ama gerçek bir geri dönüş senaryosunu masaya yatırıp kronometreyi çalıştırmayan hiçbir kurum gerçek anlamda yedekli değildir.

Veeam yedekleme sistemi kurulumu vaka çalışmasında, 25 sunuculuk bir ortamda sıfırdan kurduğumuz ve geri yükleme testleriyle doğruladığımız projeyi anlatıyoruz.

Veri Merkezi Migrasyonu

Cerrahpaşa Tıp Fakültesi’nin Başakşehir Çam ve Sakura Şehir Hastanesi’ne taşınma sürecini hatırlayın. Yüz yılı aşkın bir tıp kampüsü, tek bir hafta sonu paket açar gibi boşaltılmadı. Kardiyoloji poliklinikleri bir ay önce taşındı, yoğun bakım üniteleri hasta transferi zincirleriyle aşama aşama devredildi, laboratuvarlar paralel çalıştı, hatta bazı branşlar hâlâ eski kampüste hasta kabul ediyor. Kampüs değiştiren bir hastanede iki temel zorluk vardır: hizmet hiç kesilmeden taşınmalı ve hasta dosyalarının hiçbir satırı yolda kaybolmamalı. Veri merkezi migrasyonu kelime kelime aynı problemdir. Bir sunucuyu farklı bir donanıma, farklı bir hypervisor’a veya farklı bir buluta taşırken sistem çalışmaya devam etmeli, veri bütünlüğü korunmalı, bağımlılıklar zincirleme kopmamalıdır.

Migrasyon projeleri genelde üç bağlamda karşımıza çıkar: eski fiziksel sunucuları sanallaştırmak (P2V: Physical to Virtual), hypervisor veya sanallaştırma platformu değiştirmek (V2V: Virtual to Virtual) ve on-premise iş yüklerini bulut sağlayıcıya taşımak (Cloud migration). Her üçünde de süreç aynı dört adımda yürür: envanter ve bağımlılık haritası çıkarılır, pilot iş yükü seçilir, senkron kopya veya replikasyon hattı kurulur, cutover penceresi planlanır. Bu bölümde üç senaryoyu sırayla inceleyeceğiz; daha derin bir rehber için veri merkezi migrasyonu sayfasına göz atabilirsiniz. Ortak olan husus şu: iyi bir migrasyon, eski sistemin kapatıldığı an ile yeni sistemin üretime alındığı an arasındaki karanlık aralığı mümkün olan en kısa saniyeye indiren migrasyondur.

P2V (Physical to Virtual) Migrasyon

Bir sanayi sitesinde yirmi yıldır çalışan, büyümüş, ciddi bir müşteri ağı olan bir hırdavat işletmecisi düşünün. Tüm stok takibini, cari hesapları ve çek-senet kayıtlarını hâlâ elle tuttuğu A4 defterlerinde tutuyor. Bir gün oğlu işi devralıyor ve Logo-Mikro-Netsis gibi bir muhasebe yazılımına geçelim diyor. İşlem basit görünüyor ama içinde saklı detaylar var: binlerce eski sayfa satır satır girilecek, bazı sayfalarda kahve lekesi üzerinden zar zor okunan kayıtlar var, bazı müşteri ismi iki farklı şekilde yazılmış, eski sistemdeki “veresiye defteri” yeni sistemin “cari hesap” kavramına bire bir karşılık gelmiyor. En önemlisi: geçiş sırasında bakkal kapanamaz; eski defter bir süre paralel tutulur, yeni sistem doğrulanır, ancak ondan sonra eski defter kilitlenir. İşte P2V migrasyonu tam olarak bu hikayenin veri merkezi versiyonudur: çalışan bir fiziksel sunucuyu, kapattırmadan, veri kaybı yaşatmadan sanal bir makineye dönüştürmek.

Teknik olarak P2V iki modda yapılır. Hot (online) migration: Kaynak sunucu çalışmaya devam ederken üzerine bir ajan kurulur, disk içerikleri blok düzeyinde hedef hypervisor’a kopyalanır, sonra aradaki delta’lar senkronize edilir, cutover anında sunucu birkaç dakikalığına durdurulup VM ayağa kaldırılır. Cold (offline) migration: Sunucu bakım penceresinde kapatılır, disk imajı alınır (Clonezilla, Disk2VHD, dd) ve VM olarak tekrar oluşturulur. Sektörde en çok kullanılan araçlar VMware vCenter Converter Standalone (VMware tarafı), Microsoft Disk2VHD ve Hyper-V Integration (Windows tarafı), StarWind V2V Converter (ücretsiz ve hypervisor-agnostik), Veeam Agent üzerinden backup + restore-as-VM yaklaşımı ve kurumsal ölçekte OpenText PlateSpin Migrate ile Carbonite Move’tur. Pratikte iki kritik nokta vardır. Birincisi sürücü uyumsuzluğudur: fiziksel donanımın spesifik RAID, NIC ve chipset sürücüleri sanal makinede anlamsızdır, hatta bazen mavi ekrana yol açar; migrasyon sonrası mutlaka VMware Tools veya Hyper-V Integration Services kurulmalı, sanal paravirtualized NIC ve SCSI controller’ları aktif edilmelidir. İkincisi HAL ve ağ kimliği tarafıdır: eski Windows sürümlerinde HAL uyumsuzluğu sistem çökmesi yaratır; statik IP’li sunucularda DHCP rezervasyonları MAC değişimiyle birlikte kopabilir, domain join sertifikaları yenilenmek zorunda kalabilir.

P2V’nin zahmeti yazılım değil, karar disiplini tarafındadır. Beş yıldır dokunulmamış, belgesi olmayan, geliştiricisi emekli olmuş bir SQL Server 2008 sunucusunu sanallaştırırken aslında cevap aranması gereken soru “nasıl taşıyoruz” değil, “bu sunucu gerçekten taşınmalı mı, yoksa üzerine kaldığı uygulama zaten modernize mi edilmeli” sorusudur. Gördüğümüz üretim vakalarında P2V kararlarının neredeyse üçte biri aslında bir migrate değil, retire (kullanımdan kaldır) veya refactor (yeniden yaz) kararı olmalıydı; ama konfor alanı kazanmıştı. İkinci bir sık hata diski büyütmeden taşımaktır: fiziksel sunucunuzun 500 GB’lık diski yıllar içinde yüzde 92 dolmuşsa, aynı boyutta VMDK yaratıp içine kopyalamak altı ay sonra patlayacak bir bomba kurar. Migrasyon anı, disk ve RAM’i bu beş yılın değil, önümüzdeki beş yılın yüküne göre yeniden boyutlandırma fırsatıdır. Ve en önemlisi: P2V sonrası en az iki hafta boyunca eski fiziksel sunucu kapatılmalı ama imha edilmemelidir. Bulut ve sanal dünyada rollback, eski donanımın hâlâ ayağa kalkabiliyor olması demektir.

V2V (Virtual to Virtual) Migrasyon

Türkiye’de 2008’de yürürlüğe giren Mobil Numara Taşıma hakkını hatırlayın. On yıldır Turkcell hattı kullanıyordunuz, bir gün tarife karşılaştırmasında Vodafone’un daha iyi paket çıkardığını gördünüz, dilekçeyi imzaladınız. İşte o andan sonraki yedi gün V2V migrasyonunun neredeyse tam bir klinik örneğidir. Telefon numaranız aynı kalacak; ama altındaki operatör, şebeke, faturalama sistemi, tedarik zinciri ve tarife motoru tamamen değişecek. Geçiş sırasında bir iki saatlik kısa bir kesinti olacak, birkaç özel hizmet (örneğin operatöre özel kısa kodlar, TV+ aboneliği) yeni operatörde birebir karşılanmayacak, ama arayan için siz hâlâ aynı numarasınız. Sanal makineler de aynı şekilde taşınır: VM kimliği ve içindeki uygulama aynıdır; değişen, altındaki hypervisor ve platform ekosistemidir.

V2V migrasyonunun teknik omurgası disk formatı dönüşümüdür: VMware VMDK, Microsoft Hyper-V VHD/VHDX, KVM/Proxmox QCOW2 (veya RAW), Citrix/XenServer kendi formatları. Bu dönüşüm için sektör standardı araç qemu-img convert’tir; VMware tarafında ovftool ile OVF/OVA paketleri çıkarılır, yeni platforma import edilir. Üretici araçları da vardır: VMware vCenter Converter, StarWind V2V Converter, Microsoft Virtual Machine Converter (artık deprecated), kurumsal ölçekte Veeam Instant Recovery (yedekten doğrudan hedef hypervisor’a açma), Nutanix Move, AWS Application Migration Service ve Azure Migrate. Proxmox VE 8.2 ile gelen ESXi Import özelliği, Broadcom sonrası migrasyonları ciddi şekilde kolaylaştırdı; doğrudan vCenter’dan VM çekip dönüştürüp import ediyor. Ancak hiçbir araç “düğmeye bas, bitsin” değildir; her geçişte paravirtualized sürücü değişimi kritik adımdır. Kaynak hypervisor’da yüklü olan VMware Tools kaldırılmalı, hedefte VirtIO (KVM), Hyper-V Integration Services veya Nutanix Guest Tools yüklenmelidir. Aksi halde VM ayağa kalkar ama disk performansı zemine yapışır veya NIC görünmez. Static MAC adresi tutulan DHCP rezervasyonları, license anchor’ları (özellikle Oracle, SAP, bazı ERP’ler), cluster üyelikleri ve antivirüs sertifikaları da geçişten önce haritalanmalıdır.

2026 itibarıyla V2V projelerinin büyük çoğunluğu tek bir başlıktan çıkıyor: Broadcom sonrası VMware’den çıkış. Kasım 2023’teki satın almanın ardından perpetual lisansların iptali, zorunlu abonelik modeline geçiş ve üç-beş kat artan faturalar, özellikle Türkiye gibi döviz kuruna açık pazarlarda orta ve büyük ölçekli kurumları rakip platformlara itti. Pratikte gördüğümüz pattern şu: 50 VM altı ortamlar Proxmox VE’ye geçiyor (açık kaynak + topluluk + kurumsal abonelik opsiyonu), 50-500 VM arası Microsoft ekosistemine yakın kurumlar Hyper-V + Azure Stack HCI tarafına yöneliyor, 500 VM üstü ve HCI odaklılar Nutanix AHV veya OpenShift Virtualization (KubeVirt) değerlendiriyor. Bu geçişlerde bizim bir büyük uyarımız var: Broadcom paniğiyle 90 günde tüm estate’i taşımaya kalkmayın. V2V; test, regresyon ve rollback planı olmadan yapıldığında P2V’den daha tehlikelidir çünkü bir kez VM ayağa kalktığında kaynak ortam da genelde silinir. Pilot grup, aşamalı dalga (wave-based migration), paralel çalışan hipervizör dönemi ve cutover öncesi iş birimine imzalatılan Go/No-Go protokolü; iyi bir V2V projesini kötü bir maceradan ayıran dört temel disiplindir.

Bulut Migrasyonu: On-Premise’den Hybrid’e

Migros veya CarrefourSA gibi bir zincir marketin nasıl çalıştığına bakın. Gebze’deki dev merkez dağıtım üssü toptan ölçekte stoğu tutar; çamaşır deterjanı paleti, konserve kasaları, kuru gıda koli koli orada bekler. Şehrin içindeki şubeler bu stoktan yalnızca birkaç günlük rafa yetecek kadar taşıyor; müşteriye yakın, hızlı, küçük paketlerle. Taze ürünler ise hiç merkez deponun uğramıyor; soğuk zincir kamyonuyla doğrudan üreticiden şube rafına iniyor. Kimse “ya hepsini merkez depoya koyalım ya hepsini mağazaya koyalım” demiyor; çünkü hangi ürünün nerede durması gerektiği ağırlığa, bozulma hızına, talep frekansına ve müşteri yakınlığına göre değişiyor. Bulut migrasyonunun doğru cümlesi de tam budur: “her şeyi buluta” değil, “hangi iş yükü nereye” sorusudur.

Sektörde kabul gören çerçeve Gartner/AWS’in 6 R modelidir: Rehost (lift-and-shift: VM’i AWS EC2 / Azure VM’e olduğu gibi taşımak), Replatform (lift-tinker-and-shift: veritabanını managed RDS’e veya Azure SQL’e çevirmek gibi küçük uyarlamalar), Repurchase (on-premise uygulamayı SaaS’a bırakmak, örn. kendi Exchange sunucusundan Microsoft 365’e), Refactor/Rearchitect (uygulamayı cloud-native yeniden yazmak: Lambda, Fargate, App Service, Cloud Run), Retain (bazılarını şirket içinde tutmak) ve Retire (ihtiyaç duyulmayanları kapatmak). Araç tarafında her hyperscaler kendi migrasyon hattını kurmuştur: AWS Application Migration Service (eski CloudEndure) ve AWS Database Migration Service, Azure Migrate ve Azure Database Migration Service, Google Cloud Migrate for Compute Engine; hypervisor köprüsü olarak VMware HCX, yedekleme-tabanlı göç için Veeam ve Commvault. Bağlantı katmanında VPN tüneli küçük ölçek için yeterlidir ama kritik iş yüklerinde AWS Direct Connect, Azure ExpressRoute veya Google Cloud Interconnect gibi özel hatlar şarttır. Hybrid mimaride ayrıca Azure Arc, AWS Outposts ve Google Anthos gibi yönetim düzlemleri, on-premise ve bulut kaynaklarını tek bir konsoldan işletmeye imkân verir.

Türkiye gerçeğinde bulut stratejisini belirleyen üç ana sürtünme noktası vardır: döviz kuru, KVKK ve veri yerelliği, ve egress maliyetleri. Saatlik faturalanan bulut servisleri, TL değer kaybettikçe on-premise’da amortize edilmiş bir sunucunun maliyet eşiğini hızla geçebilir; “buluta geçelim ucuzlayalım” söylemi, özellikle 7x24 yüksek kullanım oranına sahip iş yüklerinde doğru değildir. KVKK ve sektörel regülasyonlar (BDDK, SPK) bazı verilerin sınır dışına çıkmamasını zorunlu kılar; bu durumda AWS İstanbul Local Zone, Microsoft Türkiye Azure Region (açıklanan yol haritasında) veya yerel bulut sağlayıcıları (Türk Telekom Bulut, Turkcell BulutTR, Innova) öne çıkar. Üçüncü kritik nokta egress faturasıdır: bulut sağlayıcıları veriyi içeri almayı ücretsiz, dışarı çıkarmayı pahalı fiyatlar; büyük veri analitiği yapılan workload’larda bu “cloud hotel California” etkisi yaratır, girersiniz ama veriyle beraber çıkmak servet tutar. Bizim tavsiyemiz şu: tek seferlik büyük bir bulut göçü yerine workload-başına karar alın. Müşteriye yakınlık gerektiren web ön yüzleri, sezonluk trafik dalgalanmasına maruz kalan uygulamalar, analitik ve yapay zeka iş yükleri, geliştirici test ortamları bulut için idealdir. Veritabanının büyük gövdesi, legacy ERP, düzenleme gereği yerelde kalması gereken veriler ve sabit yüklü dosya sunucuları büyük ihtimalle on-premise kalmalıdır. “Hybrid” moda değil, işin doğasına uygun topolojidir; marketin raflarıyla deposu arasındaki denge gibi.

Sistem İzleme ve Periyodik Bakım

Ankara Gölbaşı’ndaki TEİAŞ Ulusal Yük Dağıtım Merkezi’ni düşünün. Dev bir duvarda Türkiye haritası, üzerinde kırmızı-yeşil ışıklarıyla yüzlerce santral, trafo ve iletim hattı canlı olarak yanıp sönüyor. Operatörler önlerindeki ekranlarda şebekenin frekansını 50 Hz çevresinde, gerilimi tolerans bandında, yükü üretim kapasitesine göre sürekli izliyor. Frekans 49,8’e düşse saniyeler içinde yedek santral devreye giriyor; bir iletim hattı aşırı ısınsa yük otomatik olarak komşu hatta kaydırılıyor. Kimse arızanın televizyon haberlerinde duyulmasını beklemiyor. Kurumsal BT sistem yönetimi tam olarak bu disiplini ister: sorunu kullanıcı fark etmeden önce siz fark edeceksiniz. Aksi halde görevinizi müşteri hizmetleri ekibi değil, müşteriler kendisi yapar ve bu tür geri bildirimler son derece pahalıdır.

Sistem izleme ve periyodik bakım, BT operasyonunun reaktifden proaktife geçiş eşiğidir. Reaktif BT “bir şey bozulunca koşturan” BT’dir; proaktif BT ise arızayı görülmeden önce tespit eden, trendleri okuyan, bakım takvimi işleten BT’dir. İkisi arasındaki maliyet farkı kurumsal ölçekte çift haneli çarpanlara ulaşır: çökmüş bir üretim sunucusu saatlerce ciro kaybı, SLA cezası ve müşteri güveni kaybı getirirken, iki hafta önce fark edilmiş bozuk RAM modülü bir kahve molasında değiştirilir. Bu bölümde bu disiplinin iki ayağını ele alacağız. Birincisi izleme altyapısı: Zabbix, Cacti, Grafana ve eşlik eden SNMP/agent mimarileri. İkincisi periyodik bakım protokolü: disk sağlığı, log analizi, firmware güncellemeleri ve donanım hijyeninin takvime bağlanması. Birincisi gözdür, ikincisi eldir; biri olmadan diğeri körelir.

Zabbix: Servis ve Altyapı Availability İzleme

Kurumsal izleme altyapısı olmayan ortamlarda saha tablosu hep aynıdır. Bir lokasyon düşer, bir switch cevap vermez olur veya ISP router’ı sessizleşir; haber ya kullanıcıdan gelir ya da fark edilene kadar dakikalar akar. Sorunu tespit etmek için manuel ping başlar; sırayla router, switch, sunucu pinglenir, lokasyon lokasyon gezilir. Bu yöntem karanlıkta fenersiz kayıp obje aramaya benzer: uzun, yorucu, her saniyesinde iş yanar. Zabbix gibi bir izleme aracı devreye girdiğinde tablo bir gecede değişir: sanki her cihaza fosforlu bir etiket yapıştırılır, onlar da karanlıkta “buradayım, beni al” diye seslenmeye başlar.

Teknik olarak Zabbix, availability izlemenin modern kurumsal standardıdır. Windows ve Linux için Zabbix Agent, ağ cihazları için SNMPv1/v2c/v3, sunucu donanımı için IPMI, uygulama sunucuları için JMX, veritabanları için özel plug-in’ler, HTTP servisler için Web Monitoring ve Docker/Kubernetes için auto-discovery modülleri tek bir çatı altında toplanır. Template’ler ile yüzlerce sunucu aynı izleme setine bir tıkla dahil edilir, Low-Level Discovery (LLD) sayesinde yeni bir disk takıldığında kendiliğinden metriklendirilir, Triggers ve Actions ile eşik aşımı sonrası Slack, Teams veya e-posta bildirimi, hatta otomatik çözüm script’i zincirleri kurulur. Zabbix 7.0 LTS (Haziran 2024) ile dashboard widget’ları, zenginleştirilmiş raporlama ve yüksek erişilebilirlik desteği varsayılan hale gelmiştir. Yanında Grafana görselleştirme katmanı olarak çoğu kurulumda standart eklentidir; Prometheus de cloud-native ve Kubernetes ağırlıklı ortamlarda tercih edilen pull-based alternatiftir. Zabbix açık kaynak (GPL v2) lisansıyla dağıtılır ve ticari lisans ücreti yoktur; resmi destek isteyen kurumlar için Zabbix SIA üzerinden isteğe bağlı bir abonelik modeli sunulur.

Zabbix’in kendisi ise izlediği sistemden daha kırılgan olmamalıdır. Tek sunucuda çalışan, yedeksiz, izlenmeyen bir Zabbix kurulumu gözlemlediği altyapıdan daha zayıftır; “koruyanı koruyan kim” sorusu burada ciddidir. Kurumsal kurulumda HA cluster veya en azından yedekli bir VM, haftalık veritabanı yedeği ve bağımsız bir heartbeat izleyici şarttır.

Cacti: Bant Genişliği ve Satürasyon Analizi

Eğitim sektörü gibi çok lokasyonlu kurumlarda sık gördüğümüz bir tablo vardır: merkez dışındaki şubelere MPLS hatları maliyet gerekçesiyle 50 MB veya 100 MB gibi düşük hızlarda açılır. Farklı lokasyonlardaki kullanıcıların aynı anda çevrimiçi toplantılara girmesi gündelik hale gelir; bu da zaten dar olan MPLS hattını anında satüre eder. Aynı sıkışma WSUS kurulmadığı ortamlarda da yaşanır: bir Windows Update döngüsü düştüğünde o lokasyondaki tüm istemciler aynı anda internetten güncelleme çekmeye başlar, hat fiilen kilitlenir.

Cacti bu tür senaryolarda bir kapasite röntgen cihazı gibi çalışır. Satürasyon Cacti grafiklerinde görülür görülmez bir derin paket analiz aracıyla “bu hattı patlatan paketler nereye gidiyor” sorusuna cevap aranır; ardından QoS politikaları veya trafik kısıtlamaları ile sistem düzeltilir. İzleme altyapısı olmadan bu analizi yapma şansı yoktur; iş kullanıcı şikayetiyle köşeye sıkışmaya kalır.

Teknik olarak Cacti, 2001’den beri kullanılan, RRDtool üzerine kurulu klasik bir grafiklendirme aracıdır. SNMP ağırlıklıdır: ağ anahtarları, router’lar, UPS’ler, sıcaklık sensörleri gibi SNMP konuşan her cihazdan veri çekip zaman serisi grafikler üretir. MRTG geleneğinin devamıdır; ağ operatörleri bant genişliği takibi için hâlâ güvenilir bir araç olarak konumlandırır. Kurulumu sade (LAMP stack üzerine bir PHP uygulaması), öğrenme eğrisi düşüktür; Ubuntu üzerinde adım adım kurulumunu ve apt paketinin klasik rehberlerden neden ayrıldığını Cacti kurulum rehberimizde gösterdik. Sınırı ise basit olmasıdır: karmaşık tetikleme kuralları, uygulama-seviyesi izleme, service discovery ve modern bildirim entegrasyonları için tasarlanmamıştır. Cacti de GPL lisansıyla dağıtılan açık kaynak bir yazılımdır ve ticari lisans maliyeti yoktur; yatırım yalnızca sunucu ve kurulum emeğiyle sınırlıdır. İşte bu yüzden Cacti ile Zabbix bir kurumda rakip değil tamamlayıcıdır: Cacti kapasiteyi grafikler, Zabbix availability’yi alarma dönüştürür. Olgun BT organizasyonlarında ikisi yan yana çalışır.

Danışmanlık pratiğimizde sık karşılaştığımız bir tablo şudur: kurumun gerçek ölçeğine oranla fazla büyük ya da ihtiyaca göre yanlış seçilmiş bir izleme platformuna yıllık lisans ve cihaz başı ücretler ödeniyor olabilir. Böyle bir durumda rolümüz yargılamak değil, yönetim verimsizliğinden doğan israfı tespit edip kurum ölçeğine uygun ve daha ekonomik bir mimariyi (ör. Zabbix ve Cacti gibi açık kaynak bir zemin) öneri olarak sunmaktır. Karar daima kurumundur; onay çıkarsa geçişi ve operasyonel disiplini biz kurarız. Lisans kaleminden tasarruf edilen bütçe, doğrudan kuruma kâr getirecek dijital dönüşüm projelerine aktarılabilir. İzleme altyapısı sadece teknik bir tercih değil, aynı zamanda bir bütçe mühendisliği sorusudur.

Tam olarak bu tabloyu, yanlış yapılandırılmış ve maliyetli bir PRTG’yi Cacti, Zabbix ve Grafana ile değiştirdiğimiz vaka çalışmasında anlatıyoruz.

Son olarak her iki araçta da ortak dert alarm disiplinidir. En sık gördüğümüz felç, binlerce sinyalin aynı anda Teams kanalına akıtıldığı alert fatigue tablosudur; her alarm operatörü bıktırdıkça bir sonraki gerçek olay kalabalığın içinde kaybolur. İyi bir izleme sistemi alarm sayısını azaltmak için değil, alarmların büyük bölümünü görünmez kılarak yalnızca eyleme geçirilmesi gereken sinyalleri yüzeye çıkarmak için kurulur. Eşikler iki katmanlı tasarlanmalıdır: warning (e-posta veya dashboard kartı) ve critical (anlık bildirim + oncall çağrısı). Bir metriğin sürekli warning’te kalması normalleştirildiği gün o metrik izlenmiyor demektir. Ayda bir alarm denetimi yapılmayan bir izleme sistemi, altı ay sonra manzara resmine döner.

Periyodik Bakım Protokolü

Bir otomobilin servis kitapçığına bakın. Yaptırıcının sesli hatırlatmasına gerek kalmadan her 10.000 kilometrede motor yağı ve filtre değişimi, 40.000 km’de fren balataları, 60.000 km’de triger kayışı, 100.000 km’de debriyaj ve amortisör kontrolü yazar. Bu aralıkların her biri kimsenin keyfi değildir; üreticinin milyonlarca saatlik test sonrası belirlediği istatistiksel arıza eğrileri üzerinden çizilmiştir. Triger kayışını 80.000 km’de değiştirmek size 2 bin liraya mal olur, 110.000 km’de kopmasına izin vermek motorun tamamının hurdaya çıkmasıyla biter. Sunucu altyapısında da durum bundan farklı değildir. Ne zaman hangi kontrolün yapılacağı takvime bağlanmamışsa, “bir ara bakarım” zihniyeti size her seferinde dört basamaklı bir kesinti faturası çıkarır. Periyodik bakım protokolü, işte bu servis kitapçığının BT versiyonudur.

Saha pratiğinde iyi bir bakım takvimi dört periyoda bölünür. Aylık kontroller: Disklerin S.M.A.R.T. değerleri (smartctl -a), RAID dizilerinin durumu (MegaCli/StorCLI, ZFS zpool status, mdadm /proc/mdstat), yedekleme başarı raporları, antivirüs imza güncelliği, kritik servislerin uptime raporu ve sunucu kaynak trendleri (CPU/RAM/disk büyüme eğrileri). Üç aylık kontroller: Sunucu ve depolama firmware güncellemeleri (üreticinin kendi filo yönetim aracıyla), BIOS sürümleri, UPS akü testi (deşarj tatbikatı), out-of-band yönetim (kart üstü denetleyici veya IPMI) erişim doğrulaması, hypervisor patch bildirim takibi ve GLPI envanter güncelleme döngüsü; varlık listesinin gerçekle çakıştığını doğrulamak kritik. Altı aylık kontroller: Tam güvenlik taraması (CVE tespiti, konfigürasyon baseline denetimi), AD/LDAP hesap temizliği (kullanılmayan hesaplar, eski servis hesapları), GPO ve firewall kural envanteri, SSL/TLS sertifika yenileme haritası, cluster failover veya HA testi ve kritik iş yükleri için DR tatbikatı (yedekten geri yükleme + çalışabilirlik doğrulaması). Yıllık kontroller: Sunucu odası fiziksel temizliği (fan ve radyatör tozu, kablo düzeni), UPS pil değişimi (3-5 yıl ömür), CMOS pilleri, iklimlendirme bakım sözleşmesi denetimi, yıllık kapasite planlama raporu ve lisans yenileme takvimi. Tüm bu döngü bir CMDB içinde (GLPI, ServiceNow, Jira Insight) kayıtlı olmalı; kim, ne zaman, hangi kontrolü yaptı, hangi parça değişti; bir kaza sonrası soruşturmanın ilk soracağı soru budur.

İki pratik uyarı. Birincisi “çalışıyor dokunma” tuzağıdır. İşletim sistemi kernel’inin iki yıl güncellenmediği, BIOS’un 2019’dan kaldığı, diskin 92.000 saat çalıştığı bir sunucu hâlâ çalışıyor olabilir; ama istatistiksel olarak artık patlamaya yakındır. Bakım, sorun çıkmadan önce bilinçli bir rahatsızlık yaşamaktır; dokunmamak rahatlık değil, kriz biriktirmektir. İkincisi takvimin belgeye bağlanmasıdır. “Ayda bir diskleri kontrol ediyoruz” cümlesi denetim karşısında yalan kadar hafiftir; kontrolü yapan kişinin imzası, tarih, bulgular ve aksiyon listesiyle bir kontrol formu aynı gün doldurulmuyorsa o kontrol yapılmamış demektir. Takvim + form + CMDB üçlüsü bir araya gelmiş bir organizasyon reaktif BT’den proaktif BT’ye, “her şey yanıyor” rejiminden “her şey tahmin edilebilir” rejimine geçmiş demektir. BT sistem yönetiminin ustalığı göz alıcı kriz çözümlerinde değil, kriz çıkmadan geçen sessiz yıllarda ölçülür.

Sonuç: Sistem Yönetimi Bir Ürün Değil, Bir Disiplindir

Makaleye başlarken açtığımız şehir benzetmesine geri dönelim. Bir şehrin ayakta durması tek bir binanın zarafetine değil, altındaki imar planına, üstündeki ulaşım ağına ve yıllara yayılan bakım disiplinine bağlıdır. BT Danışmanlığı imar planını çizer, Kurumsal Network Kurulumu yolları ve köprüleri inşa eder; BT sistem yönetimi ise binaları ayağa dikip, yıllar içinde yaşatan ekiptir. Sunucu seçimi, sanallaştırma, Windows ve Linux’un birlikte yürütülmesi, depolama mimarisi, yedekleme disiplini, migrasyon kararları, izleme ve periyodik bakım; bu başlıklardan hiçbiri tek başına altyapıyı ayakta tutmaz. Her biri bir destek kirişidir; bir tanesi eksilince, eksikliği fark etmek için genelde bir arıza günü beklemek gerekir.

Bu rehberde baştan sona bir tema ısrarla geri geldi: BT sistem yönetimi bir ürün satın alma meselesi değil, bir pratiktir. En pahalı SAN’ı alabilirsiniz, en prestijli yedekleme lisansını imzalayabilir, Zabbix’i kurup her sunucuya agent atayabilirsiniz; ama yedekten geri yükleme testi yılda bir bile yapılmıyorsa, CMDB güncellenmiyorsa, alarm eşikleri aylarca denetlenmiyorsa, bu yatırımların hepsi kağıt üzerinde görünür, gerçekte ise bir gün çözülecek düğüm olarak bekler. Ustalık, aracı satın almakta değil; takvimin, belgenin, tatbikatın ve disiplinin iş akışına yerleşmesinde gizlidir.

Bir sonraki adımınız bu resmin sizde karşılığını çıkarmaktır. Aşağıdaki hızlı check-up listesi, kendi altyapınızın hangi başlıklarda güçlü, hangilerinde kırılgan olduğunu beş dakikada ölçmenize yardımcı olsun.

Hızlı Check-up Listesi

Aşağıdaki 15 soruyu “evet / hayır / bilmiyorum” olarak cevaplayın. Beşten fazla “hayır” veya “bilmiyorum” varsa altyapınız risk biriktiriyor demektir.

1. Tüm fiziksel ve sanal sunucularınızın güncel bir envanteri (CMDB / GLPI) var mı?
2. Kritik sunucularınız son 12 ay içinde canlı bir yedekten geri yüklenerek test edildi mi?
3. Yedekleriniz 3-2-1-1-0 kuralına uyuyor mu (üç kopya, iki medya, bir offsite, bir immutable, sıfır geri yükleme hatası)?
4. Her kritik iş yükünüz için iş birimiyle mutabık kalınmış RTO ve RPO değerleri yazılı mı?
5. Sanallaştırma platformunuz için yüksek erişilebilirlik (HA) ve canlı göç (vMotion / Live Migration) yapılandırılmış mı?
6. Windows ortamınızda iki fiziksel Domain Controller ve DNS/DHCP yedekliliği var mı?
7. Linux sunucularınızda SSH key-only erişim, fail2ban ve otomatik güvenlik yaması aktif mi?
8. Sunucularınız son 90 gün içinde işletim sistemi ve firmware düzeyinde yama aldı mı?
9. UPS akülerinizin son deşarj testini ne zaman yaptığınızı biliyor musunuz?
10. Zabbix / Prometheus / eşdeğer bir izleme platformu CPU/RAM/disk dışında servis sağlığını da izliyor mu?
11. Izleme sisteminiz için iki katmanlı alarm eşikleri (warning + critical) ve oncall rotasyonu tanımlı mı?
12. Depolama mimarinizde RAID tek savunma hattı olarak kullanılmıyor ve gerçek bir yedekleme hedefi var mı?
13. Aktif Dizin’de kullanılmayan hesaplar, eski servis hesapları ve kullanılmayan GPO’lar son altı ayda temizlendi mi?
14. Veri merkezi migrasyonu planlıyorsanız pilot → wave-based → Go/No-Go disiplinine bağlı bir proje planınız var mı?
15. Tüm bu kontrollerin aylık/üç aylık/altı aylık/yıllık bir bakım takvimi üzerinde yürüdüğünü kanıtlayan formlarınız var mı?

Yazan

İlker Pehlivan

BT Danışmanı | Ağ, Sistem ve Güvenlik Yönetimi

İlker Pehlivan, karmaşık BT altyapılarını ölçeklenebilir ve güvenli sistemlere dönüştüren bir ağ ve sistem mühendisidir. Şirketlere özel teknoloji rehberleri burada.