BT Sistem Yönetimi Hizmeti: Sunucu, Sanallaştırma, Yedekleme

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.

O günden bu yana hypervisor migrasyonları, Veeam yedekleme tasarımları ve QNAP 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 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. Dell, HPE veya Lenovo arasında seçim yapmak 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 markanın yedek disk formatı, RAID controller yönetim arayüzü, BIOS/UEFI davranışı ve uzaktan yönetim aracı (iDRAC Dell’de, iLO HPE’de, XClarity Lenovo’da) farklıdı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

Ankara Etimesgut gibi büyük bir hava kuvvetleri üssünü düşünün. Tek bir kompleksin içinde eğitim birimi, lojistik birliği, haberleşme merkezi, revir, akaryakıt deposu ve pist ekibi yan yana faaliyet gösterir. Her birim kendi komuta yapısına, kendi personeline ve kendi operasyonel sırlarına sahiptir; birimler birbirini görmez, operasyon paylaşmaz, biri sorun yaşarsa diğerleri etkilenmeden çalışmaya devam eder. Oysa jeneratör, su, atık, ortak mutfak ve güvenlik çevresi üs komutanlığı altında ortak kullanılır. Bunca izolasyon ve paylaşım aynı anda nasıl yürür? Üs komutanlığı, kaynakların hangi birime ne ölçüde tahsis edileceğini ve hangi birimin hangi güvenlik çevresini kullanacağını merkezi olarak yönetir.

Sanallaştırma, BT dünyasında tam olarak bu üs komutanlığı modelinin karşılığıdır. Hypervisor denen yazılım katmanı 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. Ayrıntılı mimari için hypervisor sanallaştırma makalemize göz atabilirsiniz.

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

Türk Hava Yolları gibi full-service bir uluslararası havayolunun operasyon yapısını düşünün. Uçuş planlaması, bakım programı, pilot sertifikasyonu, teknik servis ağı ve yolcu hizmeti yıllardır oturmuş global standartlar üzerine kuruludur. Bir uçak Singapur’a indiğinde yerel THY servis noktası aynı disiplinle bakımı yapar; İstanbul’daki mühendis ile Frankfurt’taki mühendis aynı bakım kılavuzunu okur, aynı yedek parça kodlarını bilir. Bu disiplinin getirdiği güvence maliyetlidir; bilet, ucuz havayolundan belirgin biçimde pahalıdır. Karşılığında yüksek operasyonel kararlılık, sertifikasyon zinciri ve 7/24 global destek ağı gelir.

VMware vSphere, kurumsal sanallaştırmada aynı premium havayolu 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

İstanbul Büyükşehir Belediyesi gibi büyük bir belediyenin günlük operasyonunu düşünün. Tek bir çatı altında nüfus hizmetleri, su ve kanalizasyon, toplu ulaşım, itfaiye, çevre sağlığı, zabıta ve onlarca farklı daire başkanlığı çalışır. Her daire kendi uzmanlık alanında hizmet verir, kendi ekibini yönetir, kendi prosedürlerine göre işler; ancak hepsi aynı belediye başkanlığı altında toplanır, aynı bütçe kaynağından beslenir, aynı kurumsal kimlikle vatandaşa görünür. Bir vatandaş nüfus kaydı için bir şubeye, su aboneliği için başka bir birime, imar işlemi için başka bir katta başvurur; hepsinde aynı kurumsal çatı altında işlem yapar.

Kurumsal BT altyapısında Windows Server ekosistemi tam olarak bu belediye rolünü üstlenir. Active Directory kimlik yönetir, DNS ad çözümler, DHCP otomatik IP dağıtır, File Server dosya paylaşır, Print Server yazıcıları yönetir, Group Policy masaüstlerini standartlaştırır. Her biri kendi başına bir servistir; ancak hepsi aynı domain çatısı altında birbirine entegre çalışır. Dış ürünlerle karşılaştırıldığında Windows Server’ın gerçek avantajı tek bir rolün üstün olması değil, 10-15 rolün birlikte entegre çalışıyor olmasıdır. Bu bölümde kurumsal Windows Server altyapısının sekiz temel sütununu sırayla ele alacağız.

Active Directory Domain Services (AD DS)

Bir vatandaşın Türkiye’de neredeyse her resmi işleminde tek bir şey soruluyor: T.C. kimlik numarası. Nüfus cüzdanı çıkarırken, bankada hesap açarken, doktor muayenesinde, pasaport başvurusunda, işe başvuruda; her seferinde bu on bir haneli numara sorgulanıyor. Arka planda MERNİS (Merkezi Nüfus İdare Sistemi) çalışıyor, İçişleri Bakanlığı altında merkezi bir veri tabanında tüm vatandaşların kayıt bilgisini barındırıyor. Bir vatandaş İzmir’de yaşıyor olsa da Erzurum’daki hastaneye gittiğinde kimliği aynı sistem üzerinden doğrulanıyor; kayıt tek merkezde, sorgulama her yerden. Kimlik yanında unvan (doktor, mühendis, öğrenci) da kayıtta tutulur; belirli yetkiler buna göre verilir. Askeri tabip rozetli bir kişi askeri tesise girebilir, aynı kişi sivil kamu binasına başka yetkiyle girer.

Active Directory Domain Services, kurumsal BT altyapısında tam olarak bu merkezi kimlik rolünü üstlenir. Domain Controller MERNİS’in karşılığı, kurumun tüm kullanıcı ve bilgisayar kimliklerinin saklandığı merkezi sunucudur. Her kullanıcı bir User Account ile temsil edilir; üyesi olduğu Security Group’lar unvan ve rolünü belirler. Organizational Unit (OU) yapısı kurum içindeki departman, lokasyon veya birim ayrımını kurar; İstanbul ofisi, Ankara ofisi, Satış birimi, Muhasebe birimi gibi. Group Policy Object (GPO) ile OU seviyesinde politikalar dayatılır; örneğin “Muhasebe OU’sundaki tüm bilgisayarlarda USB disk engelli” kuralı tek tıkla onlarca bilgisayara uygulanır.

Sahada gördüğüm en yaygın hata, en az yetki prensibi (Principle of Least Privilege) ihlaline düşmektir. Günlük iş yürütülsün diye kullanıcılara Domain Admin yetkisi veren, yöneticiye Enterprise Admin rolü açan, servis hesabı yerine kişisel admin hesabı kullanan kurumlar, ilk fidye yazılımı saldırısında tüm altyapıyı kaybediyor. Doğru AD tasarımı, bir vatandaşa “hayır, doktor kimlik kartı sadece hastanede geçerli, belediyede geçmez” diyen disiplinle aynı düşünce biçimindedir. Kurum içi yetkiler rollere ve OU’lara göre titizlikle bölünmeli; günlük kullanıcı hesabı ile yönetici hesabı ayrı tutulmalı, servis hesapları LAPS (Local Administrator Password Solution) veya Managed Service Account ile korunmalıdır.

DNS Sunucusu: AD Entegrasyonu ve Split-Brain Yapılandırması

Bir kargo aracını düşünün. Kadıköy’deki şoföre “Serçe Sokak No:5, Moda, Kadıköy, İstanbul” yazılı bir adres verirseniz, aracı nasıl oraya götürür? Adresin kendisi aslında yönlendirme bilgisi değildir; aracın navigasyonu bu yazılı adresi coğrafi koordinata (40.9812, 29.0259) çevirir, sonra yol haritasını çizer. İnsan için anlamlı olan “Serçe Sokak No:5”, makine için anlamlı olan ise koordinattır. PTT yıllardır aynı mantıkla çalışır: yazılı adres posta koduna, posta kodu dağıtım rotasına çevrilir. Yanlış yazılmış bir adres kargonun yanlış gitmesine, bazen hiç gitmemesine yol açar.

DNS (Domain Name System), ağ dünyasında tam olarak bu adres çözümleme işini üstlenir. İnsan tarafından okunabilen sercebilisim.com alan adını, makinenin anladığı IP adresine (203.0.113.42) çevirir. Bir kullanıcı tarayıcıya adres yazdığında ilk iş DNS sorgusu yapılır; cevap gelmezse sayfa açılmaz, e-posta ulaşmaz, kurum içi uygulama çalışmaz. Kurumsal ağda DNS iki rol üstlenir: iç DNS kurum içi kaynakları (domain controller, dosya sunucusu, yazıcı) çözer, dış DNS ise internet adreslerinin çözümlemesini yapar. Split-brain DNS yapılandırması iç ve dış dünyaya aynı alan adı için farklı cevap döndürür: iç kullanıcı crm.sirket.com için iç sunucu IP’sini alır, dış kullanıcı aynı isim için public IP’yi alır.

Yanlış veya eksik DNS yapılandırması, kurumsal BT’nin en çok baş ağrısı üreten alanlarından biridir. Sahada en sık karşılaştığım senaryo, AD ile entegre DNS yerine ISS’in DNS’ine güvenip domain üye makinelerin zaman zaman kimlik doğrulayamamasıdır. Active Directory’li bir ortamda domain üyeleri mutlaka iç Domain Controller’ı birincil DNS olarak kullanmalı, Google (8.8.8.8) veya Cloudflare (1.1.1.1) asla birincil DNS olarak yazılmamalıdır. İkinci sık hata, DNS kayıt temizliğinin yapılmamasıdır: kullanımdan kalkmış sunucular, değişmiş IP’ler DNS zone içinde kirlilik olarak kalır ve ara sıra yanlış yönlendirmelere yol açar. Düzenli scavenging politikası ve zone replikasyonu doğru kurulmadığında, DNS sessiz sedasız kurumsal operasyonu zehirleyen bir kaynağa dönüşür.

DHCP Sunucusu: Scope, Reservation ve Failover

Büyük bir konaklama oteli düşünün. Misafir resepsiyona geldiğinde oda anahtarını doğrudan almaz; önce resepsiyon müdürü müsait odalara bakar, kalış süresine göre bir oda atar, anahtarı verir. Misafir odasına yerleşir, ilan edilen süre boyunca o odaya sahiptir; kalış bittiğinde oda temizlenir ve başka misafire tahsis edilir. Eğer misafir sadık bir müşteriyse, “her geldiğinde 502 numaralı odaya atayın” gibi özel kayıt tutulur, otomatik olarak aynı oda verilir. Bazı özel statüdeki misafirler için belirli oda aralıkları rezerve edilir; örneğin 700-710 arası sadece VIP misafirlere ayrılmıştır, normal rezervasyon bu aralıktan oda alamaz.

DHCP (Dynamic Host Configuration Protocol), bilgisayar ağında tam olarak bu resepsiyon müdürü rolündedir. Ağa bağlanan her cihaz kendi IP adresini manuel tanımlamak yerine DHCP sunucusundan ister; sunucu mevcut IP havuzundan (Scope) uygun bir tanesini atar, belirli bir süre için kiralar (Lease), kiralama bittiğinde yenilenir veya başka cihaza verilir. Belirli cihazlar için her zaman aynı IP gerekliyse Reservation tanımlanır, sunucu o cihazın MAC adresini gördüğünde hep aynı IP’yi döndürür; yazıcı, kamera, telefon santrali gibi sabit IP isteyen cihazlar için bu yaklaşım yaygındır. Alt ağlardaki cihazların merkezi bir DHCP sunucudan IP alabilmesi için DHCP Relay Agent yapılandırması gerekir; ağ omurga cihazı (genellikle router veya Layer 3 switch) istekleri merkezi sunucuya iletir.

Küçük ofislerde modem veya router üzerindeki DHCP genellikle yeterlidir; ancak 50+ çalışan ve birden fazla VLAN’ın olduğu kurumlarda merkezi Windows DHCP sunucu çok daha kontrollü bir yapı sunar. Sahada gördüğüm en kritik yanlış, Scope çakışması ve IP yönetimi belgelememek üzerine kuruludur. İki farklı sunucunun aynı IP aralığında DHCP yayını yapması ağda kaos yaratır; aynı IP iki cihaza birden dağıtılır, paketler karışır. İkinci klasik hata, sabit IP verilen cihazların Exclusion Range dışında tutulmamasıdır, böylece DHCP aynı IP’yi farklı bir cihaza atayabilir. Kurumsal disiplin, IP havuzunu belgelemek, dinamik ve rezervasyon aralıklarını net bölmek ve sunucu redundancy’sini (DHCP Failover) kurmakla başlar.

Print Server: Merkezi Yazıcı ve Sürücü Yönetimi

Kariyerimin ilk yıllarında bir kurumda helpdesk olarak çalışıyordum. O dönem kurumda Print Server yoktu; her yeni bilgisayar kurulumunda veya yazıcı değişikliğinde elimde bir USB bellek, masa masa dolaşıyordum. Bellekte onlarca farklı yazıcı sürücüsü vardı; kullanıcının bağlanacağı yazıcının markası ve modeline göre doğru sürücüyü seçmem, bilgisayara kurmam, test sayfası basmam ve bir sonraki masaya geçmem gerekiyordu. Hem ben gün boyu yürüyordum hem kullanıcı o süre zarfında bilgisayarını kullanamıyordu; yeni başlayan bir personel için bazen tek yazıcı kurulumu yarım saati buluyordu.

O kurumda Print Server devreye aldığımda bu iş neredeyse tamamen masa başından çıktı. Print Server üzerinde yazıcıları tanımladıktan sonra Group Policy ile hangi OU veya departmanın hangi yazıcıyı otomatik alacağını tanımlıyordum; kullanıcı bir sonraki oturum açışında yazıcı zaten kurulu, sürücü yerinde, test sayfası basabilir durumdaydı. Masa masa dolaşma faslı neredeyse sıfıra indi; yeni başlayan personele yazıcı kurmak için artık asansöre binmiyordum, ayağımla değil panelden deploy ediyordum. O günden sonra şu kuralı oturttum: kurumda beş yazıcıdan fazlası varsa Print Server tartışma konusu değil, zorunluluktur.

Windows Server üzerindeki Print Server rolü, kurumsal ağda tam olarak bu merkezi baskı merkezini temsil eder. Kullanıcıların bilgisayarlarına ayrı ayrı yazıcı kurmak yerine Print Server üzerinde yazıcılar tanımlanır, sürücüler tek noktada hazırlanır ve Group Policy veya Print Management konsolu aracılığıyla kullanıcılara dağıtılır. Kullanıcı baskı komutu verdiğinde iş önce Print Server’a düşer, sunucu kuyruğa alır, sırayla yazıcıya gönderir; bir yandan print queue yönetimi, print job izleme ve hata raporlama merkezi olarak yürür. Printer Pool yapısı ile aynı işi birden fazla yazıcıya dengeli dağıtmak, Branch Office Direct Printing ile uzak ofislerde baskı trafiğini ağa taşımadan doğrudan yazıcıya yönlendirmek mümkündür.

Sahada en sık karşılaşılan hata, yazıcıların Print Server üzerinden değil doğrudan IP ile kullanıcı bilgisayarlarına kurulmasıdır. Bu model ilk bakışta “zaten çalışıyor” görünür, ancak iki bariz zayıf noktası vardır: sürücü güncellemesi geldiğinde her bilgisayara tek tek gitmek gerekir ve yazıcı IP değişirse onlarca kullanıcı çalışamaz hale gelir. İkinci yaygın hata, farklı marka yazıcıların aynı ortamda gelişigüzel çoğalmasıdır; her marka farklı sürücü stack’i, farklı yönetim paneli ve farklı sarf malzemesi getirir. Marka standardizasyonu sunucu filosunda ne kadar kritikse yazıcı filosunda da o kadar önemlidir; Serçe Bilişim olarak projelerde genellikle iki en fazla üç markaya indirgenmiş bir yazıcı havuzu öneriyoruz. Son olarak Print Server üzerine yazıcı başına yetki matrisi kurmak, renkli baskıyı belirli OU’larla sınırlamak ve aylık sayfa raporunu takip etmek, çoğu kurumun farkına varmadığı ciddi bir maliyet kaleminde belirgin tasarruf yaratır.

Yama ve Güncelleme Yönetimi: WSUS Sonrası Dönem

Sağlık Bakanlığı’nın her yıl yürüttüğü ulusal aşı kampanyasını düşünün. Yeni bir aşı veya hatırlatıcı doz piyasaya çıktığında önce küçük bir test grubunda denenir, yan etki profili çıkarılır, dağıtım zinciri kurulur ve ancak sonra milyonlara ulaşır. Soğuk zincir disiplini, dozaj takibi, advers reaksiyon raporlaması ve yaş/risk gruplarına göre önceliklendirme; kampanyanın aksamadan yürümesi için zorunludur. Sağlık otoritesi aynı zamanda geri çağırma (recall) mekanizması da işletir; hatalı parti tespit edilirse saha depolarından çekilir ve yerine güncel parti gönderilir. Bu model, merkezi dağıtım, kontrollü uygulama ve sürekli gözetimin birlikte yürüdüğü bir disiplini temsil eder.

Kurumsal BT’de yama ve güncelleme yönetimi tam olarak bu aşı kampanyası disiplinini ister. Güvenlik yamaları gecikirse saldırgan sızıntı noktasını bulur; yamalar test edilmeden dağıtılırsa bazen uygulama kırılmaları yaşanır; herkese aynı anda uygulanırsa bir hata tüm filoyu aynı anda vurur. Doğru model, Microsoft’un yıllardır önerdiği ring tabanlı dağıtım yaklaşımıdır: önce pilot grup (BT ekibi ve birkaç gönüllü kullanıcı), sonra erken dağıtım (belirli departmanlar), ardından geniş dağıtım (tüm filo). Her halkada birkaç günlük bekleme süresi, telemetri ve hata raporu kontrolü disiplini oturtulur.

Yıllarca kurum içi yama dağıtımında standart araç WSUS (Windows Server Update Services) olarak konumlanıyordu. Ancak Microsoft, Eylül 2024 itibarıyla WSUS’u resmi olarak deprecated ilan etti; mevcut kurulumlar çalışmaya devam ediyor, güvenlik güncellemeleri zaman içinde gelmeye devam edecek, ancak aktif geliştirme durdu ve yeni özellik beklenmiyor. Microsoft’un işaret ettiği yeni yön bulut tabanlı yönetim araçları üzerinden yama orkestrasyonudur. Windows Autopatch Microsoft’un yönetilen servis modelidir, Intune lisansına bağlıdır, özellikle Microsoft 365 E3/E5 abonesi kurumlar için hazır gelir. Microsoft Intune mobil cihaz yönetimi (MDM) üzerinden Windows, macOS, iOS ve Android cihazlara politika uygular; yama dağıtımı bu politikaların bir parçasıdır. Azure Update Manager Azure ve hibrit sunucular için yama orkestrasyonu sağlar; Azure Arc ile on-prem sunucular da kapsama alınır. Windows Update for Business (WUfB) ise daha minimal bir yaklaşım olarak GPO veya Intune politikaları üzerinden Windows Update ayarlarını merkezi kontrol eder; kurum içinde ayrı sunucu kurmak istemeyen KOBİ’ler için pratik bir başlangıç noktasıdır. Üçüncü taraf alternatifler olarak ManageEngine Patch Manager Plus, PDQ Deploy, Automox ve Ivanti özellikle çok işletim sistemli ortamlarda güçlü çözümler sunar.

Saha gerçeği şu: mevcut WSUS kurulumu olan kurumların acil göç etmesi gerekmiyor, ancak 2-3 yıllık BT yol haritasına modern bir alternatifi mutlaka eklemeleri gerekiyor. Sıfırdan kurulum yapan kurumlar bugün WSUS kurmamalı; Microsoft 365 ekosistemi varsa Windows Autopatch + Intune, yoksa en azından WUfB + GPO başlangıç noktasıdır. Test ring disiplini hangi araçla olursa olsun evrenseldir; yamayı pilot gruba 3-7 gün önce bıraktıktan sonra gözetim altında tam dağıtımı başlatmak, yıllar içinde büyük bir sistem kazası riskini sessizce önler. Serçe Bilişim olarak projelerde “hangi aracı kullanıyoruz?” sorusundan önce “hangi ring yapısını kurduk, nasıl test ediyoruz?” sorusunu cevaplamayı bekleriz; araç değişir, disiplin kalır.

File Server: NTFS İzinleri, ABE ve Shadow Copy

Bir noterlik arşivini düşünün. Noter ofisi yıllarca binlerce senet, sözleşme, vasiyet ve vekaletname kayıt altına alır; bu belgeler hiçbir zaman masa üzerinde bırakılmaz, belirli kurallar altında arşiv odasında korunur. Her belgenin bir dosya numarası, bir yıl-ay tasnifi ve bir erişim kaydı vardır; kim hangi belgeyi ne zaman çıkardı, ne zaman iade etti noter kayıt defterinde görünür. Belirli belgelere yalnızca noter veya noter yardımcısı erişebilir, bazı dosyaları ise yetkili avukatlar imza karşılığı görebilir; arşiv odasının kapısı gelişigüzel açık bırakılmaz. Bu disiplin yıllar içinde binlerce müşteriye ilişkin kayıtların korunmasını, aranabilirliğini ve yetki kontrolünü aynı anda sağlar.

Windows Server File Server rolü, kurumsal BT altyapısında tam olarak bu noter arşiv disiplinini üstlenir. Kullanıcıların dosyalarını kendi yerel bilgisayarlarında dağınık biçimde tutmak yerine, merkezi bir sunucuda organize edilmiş paylaşımlar altında toplar. SMB (Server Message Block) protokolü üzerinden kullanıcılar ağ üzerinden dosyalara ulaşır; okur, değiştirir, kaydeder. Her klasör için NTFS izinleri ve paylaşım izinleri ayrı ayrı kurulur; hangi kullanıcı veya grubun hangi klasöre hangi seviyede (okuma, yazma, tam yetki) eriştiği matris halinde tanımlanır. ABE (Access-Based Enumeration) özelliği ile kullanıcı yalnızca erişim yetkisi olduğu klasörleri görür, diğerleri gizlenir; bu hem güvenlik hem görsel sadelik açısından önemlidir. Quota ile departman bazlı disk kullanımı sınırlandırılır, File Screening ile belirli uzantıların (örneğin MP3, MP4) kurumsal alana yazılması engellenir.

Sahada en sık karşılaştığım hata, dosya sunucusunu sadece “ortak alan” olarak kurup yetki matrisini detaylandırmamaktır. Herkesin her şeyi görebildiği bir ortak klasör kaçınılmaz olarak mahrem belgelerin yanlış ellere geçmesiyle sonuçlanır; iş akışları bozulur, muhasebe dosyası pazarlamaya açılır, insan kaynakları dosyası başka bir birime sızar. İkinci kritik hata, dosya sunucusuna yedekleme planı kurmamaktır; fidye yazılımı saldırılarının ilk hedefi dosya sunucusudur, yedeği olmayan bir File Server kurumun en büyük varlığını tek darbede çöpe atar. Doğru kurulum hem yetki matrisini, hem Volume Shadow Copy (VSS) ile zamanlanmış anlık görüntüleri, hem de ayrı bir medyaya düzenli yedekleme yapısını birlikte taşır. Noter arşiv odasına çelik kapı, yangın önleme sistemi ve sigorta koymadan nasıl tamamlanmış sayılmazsa, File Server da yetki, snapshot ve yedekleme üçlüsü olmadan tamamlanmış sayılmaz.

DFS (Distributed File System)

Ziraat Bankası’nın Türkiye genelindeki 1700’ü aşkın şubesini düşünün. Bir müşteri İstanbul’daki şubede hesap açar, ancak Kayseri’ye seyahat ettiğinde oradaki şubeden aynı hesaba ulaşır, Hakkari’de para çeker, Trabzon’da havale gönderir. Müşteri için bu bir “tek banka deneyimi”dir; hangi şubeye gittiği önemli değildir, “Ziraat Bankası” adı altında her yerde aynı hesaba erişim sunulur. Arka planda ise her şube kendi altyapısına, kendi personeline ve kendi kasasına sahiptir; merkezi sistem şubeler arası işlemleri gerçek zamanlı senkronize eder. Bir şubede yapılan yatırma, diğer şubenin ekranında saniyeler içinde görünür. Müşteri tek bir mantıksal çatı altında hizmet alır, bankacı ise onlarca fiziksel noktanın senkronizasyonuyla ilgilenir.

DFS (Distributed File System), Windows Server ekosisteminde tam olarak bu çok şubeli banka modelinin dosya paylaşımı karşılığıdır. İki ana bileşeni vardır. DFS Namespace (DFS-N), birden fazla fiziksel dosya sunucusunu tek bir mantıksal yol altında birleştirir; kullanıcı \\sirket.com\ortak yazdığında ardındaki dosyalar farklı sunucularda (\\srv01\pazarlama, \\srv02\muhasebe) durabilir, ancak kullanıcı için tek yoldur. Sunucu IP’si değişse, sunucu tamamen başka donanıma taşınsa bile kullanıcı yolu değişmez, kısayollar kırılmaz. DFS Replication (DFS-R) ise birden fazla dosya sunucusu arasında klasör bazlı senkronizasyon yürütür; İstanbul ofisindeki sunucuyla Ankara ofisindeki sunucu arasında Remote Differential Compression algoritması sayesinde yalnızca değişen bloklar aktarılır, WAN bant genişliği verimli kullanılır. Her iki ofisteki kullanıcı kendi lokal sunucusundan hızlı erişir, değişiklikler arka planda eşitlenir.

Sahada DFS’in değeri en net, çok lokasyonlu kurumlarda ortaya çıkar. Tek ofisli bir KOBİ için DFS büyük olasılıkla gereksiz karmaşıklıktır; düz File Server yeterlidir. Ancak fabrika + genel müdürlük, şube ağı veya veri merkezi + uzak ofis modelindeki kurumlarda DFS olmadan kullanıcılar WAN üzerinden dosya çekmek için saatlerce bekler veya her ofis için ayrı manuel dosya taşıma rutini kurulur. Sahada en sık karşılaştığım hata, DFS-R’ı kurulumdan sonra çakışma politikası (conflict resolution) ayarlanmadan bırakmaktır; iki lokasyonda aynı dosya farklı zamanda değişirse birinin değişiklikleri sessizce DfsrPrivate\ConflictAndDeleted klasörüne gömülür, kullanıcı fark etmez. İkinci kritik hata, DFS namespace’ine eklenen hedeflerin Site-aware yapılandırılmamasıdır; Ankara’daki kullanıcı yanlış yapılandırma sayesinde İstanbul’daki sunucudan dosya çeker, ağ trafiği hem pahalı hem yavaştır. Doğru DFS kurulumu AD Site yapısıyla entegre, çakışma politikası tanımlanmış, replikasyon programı ve bant genişliği limitleri iş saatlerine göre ayarlanmış bir yapıdır.

NPS / RADIUS: 802.1X Kimlik Doğrulama ve VPN Authentication

İstanbul Havalimanı’ndaki pasaport kontrol alanını düşünün. Her yolcu kapıya yaklaştığında pasaport, biniş kartı ve gerekiyorsa vize ibraz eder. Polis memuru pasaportu tarar, merkezi sorgulama sistemi üzerinden kimliği doğrular, biniş kartındaki uçuş bilgisini kontrol eder, yolcunun aranan veya yasaklı listede olup olmadığını sorar, geçerli bir vize veya vizesiz geçiş hakkı varsa onay verir. Geçiş kabul edildiğinde yolcu havalimanının belirli bir bölümüne (iç hatlar, dış hatlar, transit alan) yönlendirilir. Eğer belgeler eksik, süresi dolmuş veya yolcu yetkisiz görünüyorsa geçiş reddedilir ve başka bir noktaya (misafir alanı, ek sorgu odası) yönlendirilir. Bir yolcu hakkındaki karar polis memurunun inisiyatifinde değildir; merkezi bir politika setinin saniyeler içinde verdiği cevaptır.

NPS (Network Policy Server), Microsoft’un kurumsal ağa giriş kontrolü için kullandığı RADIUS (Remote Authentication Dial-In User Service) sunucusudur; bu pasaport kontrol işini dijital dünyada yapar. Kablolu veya kablosuz ağa bağlanmak isteyen bir cihaz 802.1X protokolü ile önce kimlik doğrulamasından geçer: kullanıcı adı ve şifre, sertifika veya her ikisi birlikte. Switch veya kablosuz erişim noktası kimlik bilgisini NPS’ye RADIUS protokolü (UDP 1812/1813) üzerinden iletir; NPS bilgiyi Active Directory üzerinde doğrular, kullanıcının hangi gruplarda olduğunu okur, tanımlı Network Policy kurallarını işletir ve cevap döner: erişim kabul, erişim red veya belirli VLAN’a yönlendirme. EAP-TLS sertifika tabanlıdır, hem kullanıcı hem makine sertifikası gerektirir; PEAP kullanıcı adı/şifre tabanlıdır ve ek tünelleme ile şifrelenir. VPN sunucuları da kurumsal uzak erişimde NPS’yi arka uç olarak kullanır; VPN kullanıcısının kimliği tek noktadan doğrulanır, günlüğü tek yerde tutulur.

Sahada gördüğüm en kritik boşluk, kurumsal ofislerin kablosuz ağını hala WPA2/WPA3-Personal ile paylaşılan tek parola üzerine kurmasıdır. Tek parola ile çalışan bir kablosuz ağda çalışan ayrıldığında ya parola değiştirilmez ve güvenlik açığı büyür, ya da değiştirilir ve bütün cihazların yeniden yapılandırılması gerekir. WPA2/WPA3-Enterprise + NPS + 802.1X kurulu bir ortamda kullanıcı ayrıldığında yalnızca AD hesabı devre dışı bırakılır; kablosuz ağa erişimi saniyeler içinde kesilir. İkinci sık hata, 802.1X’i switch port seviyesinde hiç açmamaktır; ofise bağlanan her kablo prizinden doğrudan kurumsal VLAN’a erişilebiliyorsa, içeri giren bir cihaz herhangi bir kontrol olmaksızın ağa düşer. Doğru kurgu, bilinmeyen cihazı otomatik olarak misafir VLAN’ına düşüren, doğrulanmış cihazı ise hak ettiği yetki seviyesine yönlendiren politika tabanlı bir erişim modelidir. NPS loglarını (Event Viewer ve IAS log dosyaları) düzenli izlemek, başarısız kimlik doğrulamalarının nereden geldiğini anlamak saldırı girişimlerinin erken tespiti için kritiktir.

Group Policy (GPO): Merkezi Politika Yönetimi

İstanbul Büyükşehir Belediyesi’nin çıkardığı bir zabıta yönetmeliğini düşünün. Yönetmelik merkezi olarak hazırlanır; “kaldırımda satış yapılamaz”, “gürültü 60 dB’yi aşamaz”, “iş yerleri belirli saatler arasında çalışır” gibi kurallar şehrin genelini kapsar. Ancak bu yönetmelik her ilçede aynı şiddetle uygulanmaz; Beyoğlu’nda turistik alan olduğu için restoran çalışma saatleri uzatılır, Kadıköy’de sahil şeridi için ek gürültü kısıtlaması konur, Sultanahmet’te seyyar satıcılar için özel tahdit uygulanır. Her ilçe belediyesi ana yönetmeliği kendi saha gerçekliğine göre uyarlar; ancak merkezi çerçeveyi bozamaz. Saha ekipleri (zabıta memurları) ise bu katmanlı kural setini esnaf ve vatandaşa doğrudan uygular; esnaf ne kendisi kuralı seçer, ne de uygulama zamanını belirler.

Windows Server’da Group Policy (Grup İlkesi), Active Directory altında tam olarak bu katmanlı yönetmelik modelini üstlenir. Merkezi olarak tanımlanan Group Policy Object (GPO), kurumun bilgisayarları ve kullanıcıları üzerinde zorunlu veya varsayılan ayarlar uygular. GPO işleme sırası klasik bir hiyerarşi izler: önce Local (yerel politika), sonra Site, sonra Domain, sonra OU seviyeleri. Alt seviye üst seviyeyi geçersiz kılabilir; Enforced ayarı tersine üst seviyenin alt seviyeden öncelikli çalışmasını sağlar, Block Inheritance ise bir OU’nun üst seviye politikalarını almasını durdurur. GPO’lar Computer Configuration ve User Configuration olmak üzere iki ana dalda çalışır; bilgisayar açılırken, kullanıcı oturum açarken ve belirli periyotlarla (varsayılan 90-120 dakika) yenilenir. Uygulama alanı çok geniştir: şifre politikası, ekran kilidi süresi, yazılım dağıtımı (MSI), yazıcı atama, sürücü eşleme (drive mapping), USB disk engelleme, tarayıcı güvenlik ayarları, Windows Update davranışı ve daha fazlası. WMI filtreleme ve Security filtering ile aynı GPO’nun yalnızca belirli işletim sistemi sürümüne veya belirli güvenlik grubuna uygulanması sağlanır.

Sahada gördüğüm en yaygın hata, tek devasa bir “Kurumsal Politika” GPO’su hazırlayıp her şeyi içine koymaktır; değişiklik yapılmak istendiğinde neyi bozacağı anlaşılmaz, test mümkün olmaz, sorun çözümünde ekip saatlerce kaybolur. Doğru yaklaşım, GPO’ları işlevlerine göre ayrı ayrı kurmaktır: “Parola Politikası”, “USB Disk Engeli”, “Yazılım Dağıtımı”, “Yazıcı Atama” ayrı GPO’lar olarak durmalı ve OU yapısıyla hedeflenen kullanıcı ve bilgisayar grubuna bağlanmalıdır. İkinci kritik hata, GPO değişikliklerinin pilot OU’da test edilmeden doğrudan production OU’ya uygulanmasıdır; yanlış yapılandırılmış bir ekran kilidi veya sürücü eşleme, ertesi sabah yüzlerce kullanıcıyı aynı anda çalışamaz hale getirebilir. GPO yedekleme, sürüm etiketleme ve pilot OU’da test disiplini, tıpkı zabıta yönetmeliğinin önce belirli bir ilçede pilot uygulanıp sonra genele açılması gibi işlemelidir. Son olarak gpresult /h rapor.html komutu, bir kullanıcı veya bilgisayara hangi GPO’ların hangi sırayla uygulandığını görmek için sahada en sık kullandığım teşhis aracıdır; sorun çözümünde ilk bakılan yer burasıdır.

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 yaklaşık 4’te 3’ü, konteyner platformlarının neredeyse tamamı ve kurumsal bulut altyapısının omurgası Linux üzerinde koşar. Bu bölümde Linux’un kurumsal altyapıdaki yerini, Ubuntu Server’ın neden sahada en çok tercih ettiğimiz dağıtım olduğunu ve Linux sunucularını kurumsal disiplin altında tutmanın temel adımlarını ele alacağız.

Ubuntu Server: Neden Kurumsal Tercih?

Türkiye’de uzun yıllardır yollarda gördüğünüz en yaygın otomobili düşünün: Toyota Corolla. Teknik olarak en hızlı araç değildir, en gösterişli iç tasarıma sahip değildir, en fazla güç üreten motoru taşımaz. Ancak sahip olduğu şey eşsiz derecede değerlidir: her mahallenin oto sanayisinde yedek parçası bulunur, her tamirci motorunu tanır, uzun kullanım süresi boyunca öngörülebilir davranış sergiler, yakıt tüketimi dengelidir. Bir kurum filo aracı seçerken Corolla’yı tercih etmesinin nedeni heyecan değil, operasyonel kararlılıktır; hangi şehirde arıza yapsa ertesi gün yola çıkabilir. Aracın kendisi değil, arkasındaki yedek parça ağı ve usta havuzu Corolla’yı kurumsal filoya taşır.

Ubuntu Server, kurumsal Linux dünyasında büyük ölçüde Corolla’nın konumunda yer alır. En kararlı dağıtım olmayabilir (Debian daha muhafazakardır), en derin kurumsal destek sözleşmelerini sunmaz (Red Hat Enterprise Linux o pozisyonu tutar), en ince yapılandırma esnekliğini vermez (Arch veya Gentoo o kitleyi toplar). Ancak ekosistem genişliği açısından rakipsizdir: Docker dokümantasyonu Ubuntu üstünde örneklenir, Kubernetes kurulum kılavuzları Ubuntu referansı verir, Zabbix, GLPI, Nginx ve PostgreSQL paketlemeleri Ubuntu depolarında güncel tutulur. LTS (Long Term Support) sürümler beş yıl standart güvenlik desteği sağlar; Ubuntu Pro aboneliği ile bu süre on yıla kadar uzatılır. APT paket yöneticisi sade, okunaklı ve topluluk tarafından iyi belgelenmiş bir deneyim sunar. Canonical’in sunduğu profesyonel destek opsiyoneldir; temel kurulum ücretsiz, kurumsal destek ihtiyaç halinde satın alınır.

Sahada Serçe Bilişim olarak Ubuntu Server’ı KOBİ ve orta ölçekli kurumlar için varsayılan Linux tercihi yapıyoruz. Ubuntu Server 22.04 LTS veya 24.04 LTS üzerinde GLPI, Zabbix, Proxmox VE (Debian tabanlı), Nginx reverse proxy ve PostgreSQL gibi araçları sorunsuz çalıştırıyoruz. CentOS’un 2021’de klasik kararlı sürümden CentOS Stream’e dönmesinden sonra, Red Hat ekosisteminde kalmak isteyen kurumlar Rocky Linux veya AlmaLinux gibi topluluk çatallarına yöneldi; yeni projelerde ise Ubuntu Server çoğu zaman dümdüz yol olarak kalmaya devam ediyor. Debian’a eğilimli sistemciler de var; Debian daha yavaş dönen, daha az değişken bir tercih, “kurum içinde yıllarca uğraşmak istemiyorum” diyenler için iyi bir seçenektir. Ancak ekosistem entegrasyonu ve dokümantasyon zenginliği söz konusu olduğunda Ubuntu hala rakipsiz başlangıç noktasıdır; yanlış gittiği noktada bile bir ara forumda aynı sorunu yaşamış on kişi cevabı bırakmıştır.

Servis Yönetimi ve Sistem Sertleştirme

Bir kurumsal hizmet binasının çevre güvenliğini düşünün. Bina sokağa açık tek bir kapıyla başlamaz; önce dış çit veya bahçe duvarı ile çevrelenir, ardından güvenlik kabini ve kimlik kontrolü gelir, daha sonra ziyaretçi turnike alanı, CCTV ağı, alarm sistemi ve yangın önleme tesisatı sırayla kurulur. Güvenlik katmanları birbirini tamamlar; dış çit atlansa bile kapı güvenliği müdahale eder, kapı aşılsa bile CCTV kaydını tutar, içeri sızılsa bile hareket sensörü alarmı tetikler. Kimse tek bir duvarın tüm tehditleri durduracağına inanmaz; güvenlik birden fazla savunma hattının birlikte çalışmasıyla anlam kazanır.

Linux sunucu sertleştirmesi tam olarak bu katmanlı savunma modelini uygular. systemd modern Linux sistemlerinde servislerin başlatılması, durdurulması ve bağımlılıklarının yönetilmesini üstlenir; systemctl komutu ile servis başlatma politikaları, loglama, kaynak sınırlamaları ve otomatik yeniden başlatma davranışları merkezi olarak kontrol edilir. Sunucuya uzaktan erişimin tek kapısı genellikle SSH’dir ve bu kapının sertleştirilmesi her şeyden önce gelir: root kullanıcı doğrudan girişi kapatılır (PermitRootLogin no), kullanıcı adı/şifre yerine SSH sertifika tabanlı kimlik doğrulama (PubkeyAuthentication yes, PasswordAuthentication no) zorunlu kılınır, varsayılan 22 portu değiştirilir, MaxAuthTries düşürülür. UFW (Uncomplicated Firewall) veya nftables ile sunucu dışındaki tüm portlar kapatılır, yalnızca gerekli servisler dışarı açılır. fail2ban başarısız giriş denemelerini izler, belirli eşik aşıldığında saldırgan IP’yi otomatik bloke eder. unattended-upgrades paketi güvenlik yamalarını otomatik uygular; AppArmor veya SELinux uygulama seviyesinde zorunlu erişim kontrolü (MAC) sağlar, bir servis ele geçirildiğinde bile diğer alanlara sıçramayı zorlaştırır.

Sahada en sık karşılaştığım hata, Linux sunucu kurulumunun apt install ile bitirildiği ve sertleştirme adımlarının “sonra yaparız” raflarına kaldırıldığı senaryodur; “sonra” çoğu zaman hiç gelmez. İkinci klasik hata, servis hesapları ve günlük yönetici hesabı ayrımının yapı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. Doğru disiplin normal kullanıcı hesabıyla oturum açmak ve yalnızca gerekli komutlar için sudo kullanmaktır; her komut /var/log/auth.log üzerinde kimlikli biçimde kayıt altına girer. NTP senkronizasyonu (chrony veya systemd-timesyncd) sertleştirme listesinin sessiz kahramanıdır; zaman drift yaşayan bir Linux sunucu, Active Directory entegrasyonunda Kerberos bilet doğrulamasından TLS sertifika kontrolüne kadar pek çok yerde anlamsız hatalar üretir. Sertleştirme tek seferlik bir kurulum değil, aylık güvenlik denetimi ve yıllık CIS Benchmark kontrolü ile sürdürülen bir disiplindir; tıpkı binanın çevre güvenliğinin her yılın sonunda yeniden değerlendirilmesi gibi.

Linux Üzerinde Çalışan Kritik Araçlar

Büyük bir hastanenin teşhis cihaz parkını düşünün. Röntgen bir şeyi gösterir, MR başka bir şeyi; EKG kalbin ritmini canlı izler, kan tahlili metabolik durumu ortaya çıkarır, endoskopi iç gözlem yapar. Hiçbir cihaz tek başına hastanın tam resmini vermez; doğru teşhis birkaç cihazın birlikte kullanımıyla ortaya çıkar. Doktor hastaya bakıp hangi cihazın neyi ölçeceğini bilir, sonuçları birlikte yorumlar. Hastane için kritik olan “en pahalı cihazı almak” değildir; doğru cihaz setini kuracak ve sürdürecek ekibi beslemektir. Teşhis disiplini araç değil, süreçtir.

Kurumsal BT’de Linux üzerinde çalışan izleme, envanter ve analiz araçları tam olarak bu teşhis cihaz parkı rolünü üstlenir; her biri farklı bir boyutta altyapının nabzını tutar. GLPI (Gestionnaire Libre de Parc Informatique) envanter ve helpdesk platformudur; hangi bilgisayar kimde, hangi yazılım hangi sürümde, hangi arıza kaydı açık veya kapalı sorularının tek cevap adresidir. Türkiye’de açık kaynak envanter yönetiminde fiili standart haline geldi; detaylı mimari için GLPI nedir makalemize göz atabilirsiniz. Zabbix kurumsal ölçekte altyapı izleme aracıdır; sunucu, ağ cihazı, uygulama ve IoT sensörlerini aynı panelde toplar, SNMP veya agent tabanlı metrik toplama ile çalışır, belirli eşik aşıldığında uyarı üretir. Cacti SNMP tabanlı ağ grafikleme aracıdır; özellikle switch ve router bant genişliği, disk doluluk eğrisi gibi uzun vadeli trend analizlerinde klasik bir çözümdür, rolü daralmasına rağmen mevcut kurulumları hala aktif şekilde görev yapıyor. Grafana modern metrik görselleştirme platformudur; Prometheus, InfluxDB, Zabbix veya Elasticsearch gibi farklı veri kaynaklarına bağlanarak tek panoda canlı dashboard sunar, yönetici panolarından ağ operasyon merkezine kadar her seviyede yaygın biçimde kullanılır.

Sahada gördüğüm en sık hata, bu araçların her birini “var olsun” diye kurup sahip ve alarm politikası olmadan bırakmaktır. Zabbix bildirimi 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 (envanter için bir kişi, monitoring için başka bir kişi), alarmları kritik/uyarı/bilgilendirme seviyelerine ayırmak ve yalnızca kritik alarmları aktif bildirim kanalına yönlendirmektir. İkinci klasik hata, aynı metriği dört farklı araçta izleyip panoların çelişkili çıkması durumudur; Serçe Bilişim olarak projelerde Zabbix’i merkezi monitoring, GLPI’ı envanter ve helpdesk, Grafana’yı yönetici dashboard rolüyle konumlandırırız, Cacti ise genellikle yalnızca mevcut ağ omurga izleme için kalır. Araçları çoğaltmaktan çok, her aracın hangi soruyu cevapladığı konusunda netlik yaratmak asıl saha disiplinidir.

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. Synology DSM ve QNAP QTS gibi NAS işletim sistemleri kullanıcı ve grup yönetimi, ACL tabanlı yetkilendirme, kotalar, sürüm takibi (BTRFS snapshot), LDAP/Active Directory entegrasyonu ve Hyper Backup / Hybrid Backup Sync gibi çapraz yedekleme araçları 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.

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. Synology ile QNAP arasında seçim yaparken kararın kilit noktası genelde fiyat değil yazılım ekosistemidir: Synology daha oturmuş bir arayüz ve sabır gerektirmeyen güncelleme disiplini sunarken, QNAP daha zengin donanım yelpazesi ve sanallaştırma (Virtualization Station) özellikleri verir. Ama büyük bir uyarı: üretim ortamında tüketici sınıfı NAS (Synology Plus serisinin altı) kullanılmamalı; düşük yazma dayanıklılığı olan WD Red Green veya shingled (SMR) diskler 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 diziniştirmesi 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 Dell PowerStore, NetApp AFF, Pure Storage gibi all-flash diziler ve NVMe-oF protokolü standart olmuştur.

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 Kuralı

Ailenin çocukluk fotoğraflarını nasıl sakladığınızı düşünün. Salonun dolabında bir albüm duruyor: misafir geldiğinde çıkarılıp bakılan, yılların biriktirdiği fiziki bir kitap. Telefonunuzda da aynı fotoğraflar var; anlık paylaşım, hatırlama, aileye gönderme için her zaman elinizin altında. Bir de olası bir yangın, hırsızlık ya da telefon kaybına karşı fotoğraflar Google Photos, iCloud veya OneDrive ile bulutta senkronize, evin dışındaki bir sunucuda duruyor. Üç farklı kopya (albüm + telefon + bulut), iki farklı medya (kağıt baskı + dijital) ve bir kopya coğrafi olarak uzak lokasyonda. Bu tamamen farkında olmadan uygulanan bir yedekleme stratejisidir; kurumsal BT’de buna 3-2-1 kuralı diyoruz.

Kuralın özü basittir: en az 3 kopya veri bulunmalı, bu kopyalar 2 farklı medya türüne yayılmış olmalı ve 1 kopya offsite (başka coğrafi lokasyon) tutulmalıdır. “Üç kopya” dediğimizde üretim verisi ayrı sayılır: üretim + birinci yedek + ikinci yedek. “İki farklı medya” ifadesindeki tuzak şudur: aynı RAID havuzundaki iki disk iki medya sayılmaz; aynı storage, aynı controller, aynı oda, aynı ransomware. Disk + teyp, disk + bulut, veya disk + ikinci NAS kabul edilir ayrımlar. Yedekleme türleri de iş yüküne göre seçilir: Full yedekleme (tam kopya, en büyük, en hızlı geri dönüş), Incremental (son yedekten beri değişenler, en küçük, en yavaş restore), Differential (son full’den beri değişenler, orta yol). Kurumsal pratikte synthetic full ve GFS retention (Grandfather-Father-Son: günlük-haftalık-aylık döngü) standart hale gelmiştir.

Bugünün gerçekliğinde 3-2-1 artık taban kuraldır, tavan değil. Ransomware sonrası 3-2-1-1-0 güncel standart olarak kabul edilir: ekstra bir “1” immutable veya offline kopya (teyp, S3 Object Lock, Veeam Hardened Repository), sondaki “0” ise geri yükleme testi sırasında sıfır hata. Çünkü ransomware modern yedekleme depolarını hedef alır; erişilebilir bir yedek, şifrelenebilir bir yedektir. İkinci büyük tuzak bulut senkronizasyonunu yedek zannetmektir: OneDrive, Dropbox veya Google Drive bir dosyayı siler veya şifrelerseniz, değişiklik birkaç saniye içinde buluta senkronize olur ve yedeğiniz de siner. Bunlar sync servisleridir, versiyon tutan ve geri alınabilir backup servisleri değil. Ailedeki diploma analojisine dönersek: e-postadaki tarama kopyasının değeri, e-posta hesabı çalınsa bile anne babadaki renkli fotokopinin hâlâ durmasındadır. Stratejiniz tek bir yerin kaybını sindirebilmelidir.

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, Twitter’da kriz yayılıyor, rakip siteye trafik kaçıyor. İkinci saat veritabanı saatidir: sistem geri geldiğinde en son hangi ana kadar olan veriye güvenebiliriz? Son bir dakikada sepete eklenen ürünler, başlatılan ödemeler, kaydedilen adresler geri gelir mi, yoksa bu veriler sonsuza kadar kayıp mı? İşte RTO birinci saatin, RPO ikinci saatin adıdır.

RTO (Recovery Time Objective, Kurtarma Süresi Hedefi), bir olay sonrasında sistemin kabul edilebilir bir seviyeye dönmesi için üst limittir. “15 dakika RTO” demek, olay başladıktan 15 dakika sonra sistem tekrar çalışıyor olmalı demektir. RPO (Recovery Point Objective, Kurtarma Noktası Hedefi) ise ne kadar veri kaybının tolere edilebileceğini tanımlar. “5 dakika RPO” demek, olay anından en fazla 5 dakika öncesine geri dönülebilir, aradaki veriler kabul edilebilir kayıp demektir. Bu iki metrik yedekleme ve replikasyon mimarisini birebir belirler: RPO = 0 hedefi senkron replikasyon (aktif-aktif storage, metro cluster) gerektirir ve latency maliyetini üretime bindirir; RPO = 5 dakika genellikle asenkron replikasyon veya sık snapshot ile elde edilir; RPO = 24 saat tek gecelik bir yedek politikasıdır. RTO tarafında ise restore hızı, yedeklerin erişim süresi (teyp mı, diskte mi, bulutta mı) ve DR sitesinde altyapının hazır bekleme derecesi (hot/warm/cold site) doğrudan belirleyicidir. Klasik IBM DR tiering modeli bu ölçeği Tier 0 (sadece yerel yedek) ile Tier 6 (0 veri kaybı, anında geri dönüş) arasında tanımlar.

RTO ve RPO hakkında üretim ortamında gördüğümüz en sık hata bu değerleri BT ekibinin tek başına belirlemesidir. Bu iki sayı iş birimi kararıdır; BT yalnızca bu kararın teknik fizibilitesini ve maliyet yelpazesini sunar. CFO’ya “sipariş servisi RTO’su 15 dakika, bunun maliyeti yıllık 600 bin TL; 5 dakika olsa 1.8 milyon TL; 0 dakika olsa 4 milyonun üstü” şeklinde bir menü vermek zorundayız. İkinci sık hata tek bir RTO/RPO belirlemektir. Oysa her iş yükünün farklı kritikliği vardır: sipariş servisi RTO 15 dakika iken, muhasebe sistemi RTO 4 saat, arşiv sistemleri RTO 24 saat olabilir. Üçüncü ve en sinsi hata kağıt RTO ile gerçek RTO arasındaki uçurumdur. Belgede “RTO 30 dakika” yazabilirsiniz; ama hiç tam DR tatbikatı yapmamışsanız gerçek RTO’nuz 6 saattir ve bunu krizin ilk dakikasında öğrenirsiniz. Yılda en az iki kez tam kapsamlı bir DR drill yapmıyorsanız elinizdeki rakam hedef değil dilekçedir.

Yedekleme Araçları: Veeam, Acronis ve Bacula Karşılaştırması

Taşınıyorsunuz. Eşyanızın değerine, miktarına ve sigorta ihtiyacınıza göre birkaç farklı seçeneğiniz var. Öğrenci evinden öğrenci evine geçişte bir arkadaştan pikap ödünç alır, iki turda taşırsınız; ucuz, pratik ama bir tabak kırılırsa sizden bilir. Ev hayatına oturmuş bir aileseniz mahalle evden eve nakliye firması tutarsınız; koli, bant, naylon dahil, birkaç saatte yeni eve yerleşirsiniz. Bir holdingseniz kurumsal Aras-Yurtiçi düzeyinde bir nakliyat kontratı imzalarsınız; envanter çıkarılır, sigorta kapsamı yazılır, 7/24 destek vardır. Bir de müze varsa, sanat eserleri için iklim kontrollü konteyner, özel ekip ve eser başına bireysel sigorta devreye girer. Yedekleme araçları tam olarak bu spektrumu işgal eder; “en iyi yedekleme aracı” diye tek bir cevap yoktur, hangi ölçekte ve hangi SLA ile taşındığınıza bağlıdır.

Pratikte kategorileri şöyle gruplayabiliriz. Script ve açık kaynak seviyesi: Linux sunucularda rsync, dosya düzeyinde tar + cron, kurumsal sunucu yedeklemesi için BorgBackup, Restic ve Duplicati; Unix/Linux’ın kurumsal kökenli açık kaynak klasiği olarak Bacula / Bareos. Bu araçlar düşük maliyetli ve esnektir ama kurulum ve disiplin büyük ölçüde DevOps ekibine kalır. Orta ölçek ticari araçlar: Acronis Cyber Protect, NAKIVO Backup & Replication, Altaro (Hornetsecurity VM Backup); KOBİ’ler ve MSP’ler için entegre ajan + anti-ransomware + bulut hedef özellikleri sunar. Kurumsal standart: Veeam Backup & Replication; VMware, Hyper-V, Nutanix AHV, fiziksel, AWS, Azure, GCP, Microsoft 365, Kubernetes ve SAP HANA kapsaması ile piyasanın fiili standardıdır; Changed Block Tracking ile blok düzeyi incremental, instant VM recovery ile kurtarma, SureBackup ile otomatik doğrulama ve Hardened Repository ile immutable depolama sunar. Onun yanında Commvault, Veritas NetBackup, IBM Storage Protect (TSM) daha köklü kurumsal isimlerdir. Modern veri koruma platformları: Rubrik ve Cohesity; converged backup appliance yaklaşımıyla backup, arşiv, analiz ve siber koruma katmanlarını birleştirir. Bulut hedefleri: AWS S3 + Glacier, Azure Blob Cool/Archive, Backblaze B2 ve Wasabi; özellikle S3 Object Lock ile immutable retention kurulumu ransomware çağının güvencesidir.

Araç seçiminde bizim gözlemimiz şu: doğru tercih, ölçeğin iki numara üzerine atlamaktan değil, bir altına inmekten çıkar. Küçük bir mühendislik şirketinde Commvault kurmak, lise mezuniyet gezisi için otobüs yerine charter uçak kiralamak gibidir; fatura biner, özellikler kullanılmaz, lisans yenileme geldiğinde ekibin morali iner. Tersine 100 sunuculu bir KOBİ’de “biz zaten Windows Server Backup kullanıyoruz” demek ise sınavdan bir gece önce ders çalışmaya başlamak gibidir; çalışır görünür, patlama günü patlar. Pratik kural: 10 sunucuya kadar açık kaynak + disiplin; 10-100 arası Veeam Essentials veya eşdeğeri ticari; 100 üstü kurumsal platform. İkinci gözlem: yedekleme aracından bağımsız olarak hiçbir araç geri yükleme testinizi sizin yerinize yapmaz. Veeam’in SureBackup’ı veya Rubrik’in otomatik test işlevleri yardımcıdır, ama ayda bir gerçek bir restore senaryosunu masaya yatırıp kronometreyi çalıştırmayan hiçbir kurum gerçek anlamda yedekli değildir.

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 FortiAnalyzer gibi 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. 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.

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 (Dell/HPE/Lenovo OME, Lifecycle Controller), BIOS sürümleri, UPS akü testi (deşarj tatbikatı), out-of-band yönetim (iDRAC/iLO/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 Veeam 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

Kurucu | Ağ ve Sistem Yöneticisi

İ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.