BT Mimarisi ve Bulut Danışmanlığı
Uygulamalarınızın genel bulutta mı, kendi veri merkezinizde mi, yoksa ikisinin birlikte kullanıldığı hibrit bir yapıda mı çalışacağına veriye dayanarak karar vermenize yardımcı oluyoruz. Hedef mimariyi ve yol haritasını hazırlıyor, iş yüklerini planlı biçimde buluta ya da hibrit yapıya taşıyor ve maliyeti izlenebilir hale getiriyoruz.
- Ortamlar
- AWS, Azure, Google Cloud, yerel bulut sağlayıcıları, kendi veri merkeziniz
- Dönüşüm yönü
- Buluta geçiş, buluttan geri dönüş, hibrit ve çoklu lokasyon
- Yaklaşım
- Seçenekler maliyet, risk ve süreyle karşılaştırılır
- İlk adım
- Ücretsiz ön görüşme ya da ücretsiz değerlendirme
Mimari ve bulut kararları ne zaman gündeme gelir?
Mimari kararlar uzun yıllar boyunca maliyeti, güvenliği ve esnekliği etkiler. Bu yüzden karar öncesinde seçenekleri aynı ölçütlerle karşılaştırırız.
- Bulut maliyetlerinin daha iyi izlenmesi gerekiyor. Harcamanın hangi ekip ve ürüne ait olduğunu görmek, bütçeyi planlamayı kolaylaştırır.
- Buluta taşınan iş yüklerinden beklenen verim alınamadı. Olduğu gibi taşınan sunucuların yönetilen servislerle ve doğru boyutlandırmayla yeniden ele alınması gerekebilir.
- Veri merkezindeki donanımın yenileme dönemi yaklaşıyor. Yenilemek, buluta geçmek ya da hibrit bir yapı kurmak arasında karşılaştırmalı bir karar gerekiyor.
- Kritik sistemler tek bir lokasyona bağlı. Bir sunucu, bölge ya da bağlantı devre dışı kaldığında hizmetin nasıl süreceği planlanmalı.
- Veri yerleşimi ve regülasyon gereksinimleri netleşmeli. Hangi verinin nerede tutulabileceğinin belirlenmesi, projelerin ilerlemesi için ön koşul.
- Sanallaştırma lisans koşulları değişti. Mevcut platformda kalmanın ve alternatiflere geçmenin toplam maliyeti ve riski karşılaştırılmalı.
Bulut ve BT mimarisinde neler yapıyoruz?
Altyapı ve bulut mimarisinde tasarım, geçiş ve işletim planlaması.
Hedef mimari ve yol haritası
İş hedeflerinizden yola çıkan, seçeneklerin gerekçeleriyle yazıldığı, aşamalı ve bütçelenebilir bir mimari plan.
Bulut temeli (landing zone)
Hesap yapısı, kimlik ve yetki, ağ, güvenlik politikaları ve maliyet etiketleri; iş yükleri gelmeden kodla kurulan temel.
İş yüklerinin buluta taşınması
Fiziksel ve sanal sunuculardaki iş yüklerinin envanter, taşıma stratejisi ve kesinti planıyla buluta taşınması.
Buluttan geri dönüş
Maliyet, performans ya da regülasyon gerekçesiyle iş yüklerinin kendi veri merkezinize ya da yerel bir bulut sağlayıcısına planlı taşınması.
Hibrit, çoklu bulut ve çoklu lokasyon
Veri merkezi, şube ve bulut ortamları arasında ağ, kimlik, yedekleme ve yönetimin tek bir bütün olarak tasarımı.
Maliyet yönetimi (FinOps)
Ekip ve ürün bazında maliyet görünürlüğü, bütçe alarmları, doğru boyutlandırma ve düzenli maliyet gözden geçirmeleri.
Sanallaştırma ve VMware alternatifleri
VMware, Hyper-V, Proxmox ya da OpenStack ile sanallaştırma; lisans koşulları değişen platformlardan planlı geçiş.
Süreklilik ve felaket kurtarma
Yüksek erişilebilirlik, yedekleme stratejisi, kesinti süresi ve veri kaybı hedefleri (RTO/RPO), düzenli kurtarma tatbikatları.
Her uygulamanın taşınması gerekmez.
Buluta geçişte her uygulama için uygun strateji ayrı ayrı seçilir. Kimi zaman en doğru karar, bir uygulamayı yerinde bırakmak ya da kullanımdan kaldırmaktır.
Yeniden barındırma
Uygulamayı olduğu gibi taşımak. Hızlıdır ama kazancı sınırlıdır; çoğu zaman ilk adımdır.
Yeniden platformlama
Küçük değişikliklerle yönetilen servislere geçmek; örneğin veritabanını yönetilen servise almak.
Yeniden tasarım
Uygulamayı buluta özgü mimariye dönüştürmek. En çok emeği ister, en çok esnekliği sağlar.
Yeniden satın alma
Kendi geliştirdiğiniz uygulamayı, ihtiyacı karşılayan hazır bir SaaS ürünüyle değiştirmek.
Yer değiştirme
Sanallaştırma katmanını uygulamalara dokunmadan, bütün olarak başka bir altyapıya taşımak.
Yerinde bırakma
Taşımanın bugün bir gerekçesi yoksa uygulamayı olduğu yerde bırakıp ileride yeniden ele almak.
Kullanımdan kaldırma
Artık kullanılmayan uygulamaları kapatmak; taşıma kapsamını ve maliyetini doğrudan azaltır.
Karar uygulama bazında
Her uygulama için strateji; maliyeti, riski ve iş değeriyle birlikte ayrı ayrı belirlenir.
Karar vermeden önce ölçüyoruz.
Her mimari öneri mevcut durumun verisine ve iş hedeflerinize dayanır. Neyi neden önerdiğimizi yazılı gerekçesiyle sunarız.
Mimari kararlarda gözettiklerimiz
Her seçeneği aynı ölçütlerle karşılaştırırız:
- Toplam sahip olma maliyeti
- Güvenlik ve regülasyon uyumu
- Ölçeklenebilirlik ve performans
- Ekibinizin işletme yetkinliği
Envanter ve analiz
Uygulamaları, bağımlılıkları, veri akışlarını ve mevcut maliyetleri çıkarırız.
Çıktı: Envanter ve bağımlılık haritasıSeçenekler ve hedef mimari
Alternatifleri maliyet, risk ve süre açısından karşılaştırır, birlikte karar veririz.
Çıktı: Hedef mimari dokümanTaşıma planı
Dalgalar halinde taşıma sırasını, geri dönüş planını ve kesinti pencerelerini belirleriz.
Çıktı: Aşamalı taşıma planıUygulama
Altyapıyı kod olarak kurar, iş yüklerini dalgalar halinde taşır ve doğrularız.
Çıktı: Taşınmış ve doğrulanmış iş yükleriOptimizasyon ve devir
Maliyet ve performansı ayarlar, maliyet takibini ekiplerinize yerleştirir; dokümantasyon ve eğitimle devrederiz. İsterseniz dönemsel maliyet incelemesiyle sürdürürüz.
Çıktı: Optimizasyon raporu, dokümantasyonMimari ve geçiş çalışmasının çıktıları.
Çıktılar işin kapsamına göre belirlenir; kararların gerekçesi ve kurulan yapının tanımları belgelenmiş olarak elinizde olur.
Mimari dokümantasyon
Hedef mimari, ağ ve güvenlik tasarımı, karar kayıtları.
Maliyet analizi
Mevcut ve hedef maliyet karşılaştırması, tasarruf önerileri.
Altyapı kodu
Uygulama projelerinde yeni ortamın Terraform ve Ansible ile yazılmış, sürümlenen tanımları.
Taşıma, geri dönüş ve çıkış planları
Her dalga için adımlar, kontroller ve geri dönüş yolu; gerektiğinde sağlayıcı değiştirmenin yolu.
Felaket kurtarma planı
Yedekleme, kurtarma prosedürleri ve tatbikat sonuçları.
Bilgi aktarımı
Ekibinize yeni yapının işletimi üzerine uygulamalı eğitim.
İhtiyaca göre seçilen teknolojiler.
Seçenekleri gereksinimlerinize, mevcut yatırımlarınıza ve ekibinizin işletme kapasitesine göre değerlendiririz. Mümkün olan yerde açık standartları ve taşınabilir araçları tercih ederiz.
Genel bulut
- AWS
- Microsoft Azure
- Google Cloud
Yerel ve özel bulut
- Yerel bulut sağlayıcıları
- OpenStack
- VMware vSphere
- Proxmox
- Hyper-V
Ağ ve kimlik
- VPN / Direct Connect / ExpressRoute
- Entra ID (Azure AD)
- Keycloak
- Active Directory
Yedekleme ve kurtarma
- Veeam
- Velero
- Bulut yerel yedekleme servisleri
Ölçeğinize göre bulut ve mimari çalışmaları.
KOBİ'ler
Çoğu zaman bir donanım yenileme ya da ilk bulut kararıyla başlanır; sade ve maliyeti öngörülebilir bir yapı hedeflenir.
Büyüyen şirketler
Bulut harcamasını görünür kılmak, hesap yapısını düzenlemek ve yeni lokasyonları ortak bir mimariye bağlamak.
Regülasyona tabi ve kurumsal yapılar
Veri yerleşimi, süreklilik ve denetim gereksinimlerini mimariye baştan yerleştirmek.
İlk görüşmeyi verimli kılmak için.
Hiçbiri ön koşul değil; elinizde ne varsa ilk görüşmeyi o kadar somut kılar.
Varsa hazırlayabilecekleriniz
- Son birkaç ayın bulut faturası dökümü ya da donanım ve lisans maliyetleri
- Uygulama ve sunucu envanteri, varsa mimari şemalar
- Donanım ve lisans yenileme tarihleri
- Veri yerleşimi, süreklilik ve regülasyon gereksinimleri
BT mimarisi ve bulut hakkında
Kaynaklar ve standartlar
- AWS Well-Architected (yeni sekmede açılır)AWS mimari ilkeleri
- Azure Well-Architected Framework (yeni sekmede açılır)Azure mimari ilkeleri
- Google Cloud Architecture Framework (yeni sekmede açılır)Google Cloud mimari ilkeleri
- FinOps Foundation (yeni sekmede açılır)Bulut maliyet yönetimi uygulamaları
- NIST SP 800-34 (yeni sekmede açılır)BT süreklilik planlama rehberi
İhtiyacınızı birlikte netleştirelim.
Ücretsiz ön görüşmede mevcut durumunuzu ve hedeflerinizi ele alıyor; ilk izlenimimizi ve olası sonraki adımları aynı görüşmede paylaşıyoruz.
- Konunuza uygun uzmanlarla teknik bir görüşme
- Durumunuza ilişkin ilk izlenim ve olası yaklaşımlar
- Uygunsa sonraki adım: değerlendirme, proje önerisi ya da danışmanlık
- Gerektiğinde görüşme öncesinde gizlilik sözleşmesi
- Taleplere mesai saatlerinde 4 saat içinde dönüş
Mimari ve bulut uygulamadan örnekler
Geçiş, bulut temeli, süreklilik ve maliyet çalışmalarının nasıl ilerlediğini temsili senaryolarla gösteriyoruz.
Buluta taşıma dalgası
İş yükleri tek seferde değil, bağımlılıklarına göre gruplanmış dalgalarla taşınır. Her dalganın kabul ölçütü ve geri dönüş planı önceden yazılıdır.
Envanter
Fiziksel ve sanal sunucular, uygulamalar, aralarındaki bağımlılıklar ve kullanım verileri çıkarılır.
- 48 sanal sunucu · 17 uygulama · 6 veritabanı
- bağımlılık haritası: 63 bağlantı
Strateji
Her uygulama için yol seçilir: olduğu gibi taşıma, platform değiştirme, yeniden tasarım, yerinde bırakma ya da kapatma.
- rehost: 9 · replatform: 4 · refactor: 1
- retain: 2 · retire: 1
Bulut temeli
İş yükleri gelmeden hesap yapısı, kimlik, ağ ve güvenlik kuralları kodla kurulur (landing zone).
- $ terraform -chdir=landing-zone apply tfplan
- ✓ Apply complete! Resources: 64 added, 0 changed, 0 destroyed.
Dalga ve geçiş
Her dalga test, veri eşitleme ve planlı bir geçiş penceresiyle taşınır.
- Dalga 2 · 4 uygulama · Cumartesi 22:00–02:00
- veri eşitleme gecikmesi: 2 sn
- DNS TTL 300 sn'ye düşürüldü
Kabul ve geri dönüş
Kabul ölçütü sağlanırsa geçiş tamamlanır; sağlanmazsa yazılı adımlarla eski ortama dönülür.
- sağlık kontrolleri ✓ · yanıt süresi ✓ · iş testi ✓
- ✓ Dalga 2 tamamlandı
Boyutlandırma
Taşıma sonrasında kaynaklar gerçek kullanıma göre yeniden boyutlandırılır.
- ortalama CPU %11
- ✓ 8 sanal makine bir alt boyuta indirildi
- Azure Migrate / AWS Application Migration Service
- Terraform
- DNS
Bulut temeli (landing zone)
Landing zone; hesap yapısı, kimlik, ağ, güvenlik kuralları, kayıt tutma ve maliyet etiketlerinden oluşan temeldir. İş yükleri bu temelin üzerine taşınır.
Hesap yapısı
Üretim, test, paylaşılan hizmetler ve güvenlik için ayrı hesaplar ya da abonelikler açılır.
- kurum/
- ├─ guvenlik ├─ paylasilan
- ├─ uretim └─ test
Kimlik
Erişim merkezi kimlik sağlayıcısından, rol tabanlı ve çok faktörlü doğrulamayla yapılır.
- SSO: Entra ID → bulut hesapları
- roller: platform-yonetici · gelistirici · salt-okur
Ağ
Merkez-uç (hub-spoke) ağ yapısı, IP planı ve şirket ağıyla güvenli bağlantı kurulur.
- hub 10.0.0.0/16 · uretim 10.10.0.0/16 · test 10.20.0.0/16
- ✓ site-to-site VPN: bağlı
Koruma kuralları
İzin verilmeyen bölgeler, şifrelenmemiş depolama ve herkese açık kaynaklar politika ile engellenir.
- allowed-regions · require-encryption · deny-public-storage
- ✓ 3 politika atandı
Kayıt ve etiketler
Bütün hesapların kayıtları merkezi bir hesapta toplanır; her kaynak ekip, proje ve ortam etiketi taşır.
- denetim kayıtları → log-arsiv hesabı
- ✓ zorunlu etiketler: ekip, proje, ortam
- Terraform
- AWS Organizations / Azure Management Groups
- Entra ID
Felaket kurtarma tatbikatı
Yedekleme veriyi korur; yüksek erişilebilirlik tek bileşen arızasında hizmeti sürdürür; felaket kurtarma ise bütün bir ortam kaybedildiğinde hizmetin başka yerde açılmasıdır. Plan, tatbikatla doğrulanır.
Hedefler
Her sistem için kabul edilebilir kesinti süresi (RTO) ve veri kaybı (RPO) iş birimleriyle belirlenir.
- siparis-db RTO 4 sa · RPO 15 dk
- dosya-sunucusu RTO 24 sa · RPO 24 sa
Yedek ve kopya
Yedekler ayrı bir bölgeye ve değiştirilemez depolamaya kopyalanır.
- işlem günlüğü: 15 dk'da bir · tam yedek: günlük
- ✓ ikinci bölge kopyası · değiştirilemez 30 gün
Tatbikat
Planlı bir tatbikatta sistem ikinci bölgede yedekten ayağa kaldırılır.
- 12:00 tatbikat başladı
- 12:41 veritabanı geri yüklendi
- 13:22 uygulama ikinci bölgede çalışıyor
Ölçüm
Gerçekleşen süre ve veri kaybı hedeflerle karşılaştırılır.
- ✓ gerçekleşen RTO 1 sa 22 dk (hedef 4 sa)
- ✓ gerçekleşen RPO 9 dk (hedef 15 dk)
İyileştirme
Aksayan adımlar işletim kılavuzuna işlenir ve bir sonraki tatbikat tarihi belirlenir.
- aksiyon: DNS geçişi otomatikleştirilecek
- sonraki tatbikat: 6 ay sonra
- Yedekleme yazılımı
- İkinci bölge
- Runbook
Bulut maliyet gözden geçirmesi (FinOps)
FinOps, bulut harcamasını görünür kılıp teknik ve finans ekiplerinin birlikte yönetmesidir. Amaç yalnız kısmak değil, harcamanın karşılığını bilmektir.
Görünürlük
Harcamalar etiketlerle ekip, proje ve ortama dağıtılır.
- etiketli harcama oranı: %62 → %97
Analiz
Boşta kalan, gereğinden büyük ya da unutulmuş kaynaklar listelenir.
- bağlı olmayan disk: 23 · durdurulmuş sunucu: 6
- ortalama CPU < %10: 14 sunucu
Düzenleme
Kaynaklar gerçek kullanıma göre boyutlandırılır; test ortamları mesai dışında kapatılır.
- test ortamı: hafta içi 08:00–20:00
- ✓ 14 sunucu bir alt boyuta indirildi
Taahhüt
Sürekli çalışan iş yükleri için rezervasyon ya da tasarruf planı değerlendirilir.
- öneri: 1 yıllık taahhüt · temel kullanımın %70'i
Bütçe ve takvim
Ekip bazında bütçe ve alarm tanımlanır; aylık gözden geçirme takvime bağlanır.
- bütçe: uretim-ekip-a · eşik %80 ve %100
- ✓ aylık maliyet gözden geçirmesi planlandı
- Etiketleme
- Bulut maliyet aracı
- Bütçe alarmları