Geçen ay İstanbul’daki bir e-ticaret firmasında oturuyoruz. CTO masaya bir Excel atıyor: 47 sayfalık “Azure mimari değerlendirme” raporu. İlk üç sayfayı geçemeden takıldığımız şey şu oluyor — rapor güzel, başlıklar yerinde, ama hiçbir karar yok içinde. Sadece liste var.
Well-Architected Framework (WAF) tam burada işe yarıyor. Ama yanlış kullanılırsa o Excel’e dönüyor. Doğru kullanıldığında ise üretim ortamınızda neyi düzelteceğinizin sırasını net çıkarıyor.
Bu yazıda WAF’ın 5 sütununu sahadan baktığım haliyle aktarıyorum. Microsoft Learn’deki resmî tanımı kopyalamayacağım — onu zaten okudunuz. Onun yerine: hangi sütunu hangi sırayla değerlendiriyoruz, neyi atlıyoruz, hangi metrik gerçek karar üretir.
WAF aslında ne işe yarar?
Beş sütun var: Reliability, Security, Cost Optimization, Operational Excellence, Performance Efficiency. Bu kadar.
Asıl mesele şu: workload’ı bu beş başlığın altında değerlendirip trade-off‘ları açıkça konuşmak. Çünkü hiçbir mimari beş sütunda da 10/10 değildir. Reliability’ye baskın çıkan mimari pahalıdır. Cost’a odaklanan mimaride dayanıklılık riski vardır. WAF size bu pazarlıkları görünür hale getirir.
Saha kuralı: WAF değerlendirmesini iş hedefiniz olmadan yapmayın. Önce “bu workload neye hizmet ediyor, SLA hedefi nedir, kayıp tolerans bütçesi ne?” diye sorun. Cevap yoksa değerlendirme bir egzersize döner.
1. Reliability: Beklenen ve Beklenmeyen Hatalar
Bir bankanın çekirdek bankacılık API’si ile bir blog CMS’inin reliability beklentisi aynı olamaz. WAF burada size matematiği konuşturuyor.
Sahada en sık atladığımız şey RTO/RPO’yu kâğıda yazmamak. RTO (Recovery Time Objective) — ne kadar sürede ayağa kalkacağız. RPO (Recovery Point Objective) — ne kadar veri kaybını kabul ediyoruz. Bu iki sayı yoksa Azure Site Recovery’yi kuracağınız bölge bile keyfi olur.
Türkiye’de mantıklı topoloji genelde şu: birincil West Europe (Amsterdam) veya North Europe (Dublin), eşli bölge olarak West Europe + North Europe çifti. Hâlâ “Germany West Central’a koyalım latency düşer” diyenlere rastlıyorum — düşmüyor, ölçüm yapın. Trendyol bile Avrupa bölgelerini paralel kullanıyor; sadece tek bölgeye yaslanan büyük yük yok orada.
| Workload | Tipik RTO | Tipik RPO | Yaklaşım |
|---|---|---|---|
| Çekirdek bankacılık | < 15 dk | < 1 sn | Active-active, multi-region, sync replication |
| E-ticaret checkout | < 30 dk | < 1 dk | Active-passive + Front Door failover |
| İç ERP | 4 saat | 15 dk | Daily backup + ASR replication |
| Pazarlama sitesi | 24 saat | 24 saat | Backup + manuel restore yeter |
Reliability sütununda kontrol edeceğiniz sorular:
- Tek bir Availability Zone’a bağlı bir kaynağınız var mı? Varsa neden?
- Stateful kaynaklar (SQL, Cosmos, Storage) için cross-region failover senaryosunu son ne zaman test ettiniz?
- Health probe’lar gerçek bağımlılığı mı kontrol ediyor, yoksa sadece HTTP 200 mü dönüyor?
- Retry politikalarınız idempotent mi? (Burası en sık atlanan yer.)
2. Security: KVKK ve BDDK Türkiye’yi Farklı Yapıyor
Türkiye’de güvenlik mimarisi, küresel WAF tavsiyelerinin üzerine iki katman daha bindirir: KVKK ve sektörel düzenleyiciler (BDDK, EPDK, SPK).
BDDK’nın 2023 sonunda güncellediği bilgi sistemleri yönetmeliği, finans kuruluşlarının kişisel verilerini Türkiye sınırları içinde tutmasını gerektiriyor. Yani Azure tarafında hem region seçimi hem data residency kararı sadece performans değil, hukuki bir karar.
Microsoft, Türkiye’de doğrudan Azure region’ı sunmuyor (henüz). Bu da finans dışı pek çok kurumun Avrupa region’larını kullandığı, finans tarafında ise hibrit modele yöneldiği anlamına geliyor. Azure Stack HCI burada çözüm olabiliyor.
Tipik bir KVKK uyumlu Azure güvenlik temeli şuna benziyor:
# Subscription seviyesinde Defender for Cloud aktif et
az security pricing create --name VirtualMachines --tier 'Standard'
az security pricing create --name SqlServers --tier 'Standard'
az security pricing create --name AppServices --tier 'Standard'
az security pricing create --name StorageAccounts --tier 'Standard'
# Diagnostic logs Log Analytics'e + Türkiye'de tutmak istiyorsan on-prem agent'a
az monitor diagnostic-settings create
--resource-group rg-prod-tr
--name kvkk-audit
--workspace law-prod-tr
--logs '[{"category":"Administrative","enabled":true,"retentionPolicy":{"days":730,"enabled":true}}]'
730 gün retention KVKK için emniyetli aralık. Yönetmelik 2 yıl diyor; biz 730 gün set edip resmî yazışmalarda kanıt tutuyoruz.
Security sütununda gözden kaçırılan üç şey:
- Managed Identity yerine service principal kullanmak — secret yönetimi gerek olmayan yerde gerek üretiyorsunuz.
- Network Security Group kurallarına “Allow Any” koymak — “sonra düzelteceğiz”in mezarlığı.
- Key Vault’ta soft-delete + purge protection açık değil — bir gün biri yanlış komut atar, iflahınız kesilir.
3. Cost Optimization: Para Sayar Karar Verir
Cost optimization sütunu, üç ay önce Ankara’da bir kamu projesinde gözümün önüne en somut hâliyle geldi. Aynı workload’ın iki ayrı sürümü vardı: biri Pay-As-You-Go, diğeri Reserved Instance + Hybrid Benefit kombinasyonu. Aradaki fark aylık 14 bin dolar. Yani neredeyse %52.
WAF cost sütununda bakacağınız sıra şu olmalı:
- Right-sizing: Azure Advisor önerilerine bir göz atın. “Average CPU < 5%" diyen 23 VM'iniz varsa duralım.
- Reserved Instances + Savings Plans: Stabil yükler için 3 yıllık RI %72’ye varan tasarruf yapar. Esnek yükler için Savings Plans daha uygun.
- Azure Hybrid Benefit: Lisansınız varsa Windows Server ve SQL Server tarafında %85’e varan kazanç.
- Auto-shutdown / scaling: Dev/test ortamlarınız gece 19:00’da kapanmıyorsa, sabah 8:00’a kadar parayı yakıyorsunuz demektir.
- Storage tiering: Cool ve Archive tier’lar var, kullanmıyorsanız sebep nedir?
FinOps tarafında benim en sevdiğim metrik: unit cost. Yani “sipariş başına maliyet”, “transaction başına maliyet”, “kullanıcı başına maliyet”. Toplam fatura yanıltıcıdır. Sipariş başına maliyetiniz ay ay düşüyorsa, faturanız büyüse de doğru yoldasınız.
Maliyet anti-pattern: Sadece Azure portal’dan “Cost Analysis” ekranına bakıp ay başında haykırmak. Yapın bir KQL sorgusu, dispatch edin Slack’e veya Teams’e — ekibin gözüne ay sonu değil her sabah sokun.
// Last 30 day cost trend by service, grouped by week
KubePodInventory
| where TimeGenerated > ago(30d)
| summarize PodCount = count() by Namespace, bin(TimeGenerated, 7d)
| render columnchart
4. Operational Excellence: Manuel İşi Bitirme Sanatı
WAF’ın bu sütunu, çoğu ekibin atladığı sütundur — çünkü “çalışıyor zaten” der geçer. Ama bir gün biri tatildedir, başka biri istifa etmiştir, yeni gelen birisi bilmediği bir şeyi değiştirir. O an operational excellence’in olmadığı görülür.
Sahada baktığım üç ana kalem:
4.1. Infrastructure as Code dışında hiçbir şey üretime gitmesin
Bicep veya Terraform fark etmiyor. Önemli olan portalda “Deploy” tıklamamak. Yeni bir kaynak gerektiğinde:
git checkout -b feature/add-redis-cache
# infra/redis.bicep dosyasını yaz
az deployment group what-if
--resource-group rg-prod-tr
--template-file infra/main.bicep
# PR aç, code review al, merge et, GitHub Actions deploy etsin
What-if çıktısını okumayan ekipte gerçek operational excellence yoktur. “Sadece Redis ekliyoruz” diye aldığınız PR’ın yan etkisinde NSG kuralı silinmiş olabilir.
4.2. Observability sözden öteye geçmiş olsun
Application Insights kurmak observability değil. Observability:
- Her servis, transaction ID ile log atıyor mu? (correlation ID)
- Üretim hatası geldiğinde hangi dashboard’a bakacaksın, paylaşılmış URL var mı?
- Alert’leriniz “CPU > 80%” gibi gürültü mü, yoksa “checkout success rate < 99.5%" gibi anlamlı mı?
- Runbook’larınız Confluence’ta toz tutuyor mu, yoksa son 30 günde okundu mu?
4.3. Drift detection
Bir ay içinde altyapınızın IaC ile uyumu %2 bozulur. Üç ayda %15. Yıl sonunda terraform plan komutu 4 saat sürer ve kimse uygulamaya cesaret edemez. Drift detection için Azure Policy + GitHub Actions cron işleri ile haftalık kontrol kurun. Sapan kaynak varsa Slack/Teams’e mesaj gelsin, aynı gün düzelin.
5. Performance Efficiency: Doğru Soruyu Sormak
Performans iyileştirmesi yanlış sorularla başlarsa parayı çöpe atarsınız. “Veritabanı yavaş” cümlesi soru değildir. “Checkout endpoint’inin p95 latency’si 480 ms; hedefimiz 200 ms; en yavaş query hangisi?” sorudur.
Azure tarafında performans için pratik karar listesi:
| Belirti | Yanlış Refleks | Doğru Adım |
|---|---|---|
| SQL yavaş | Daha büyük SKU al | Query Performance Insight + execution plan oku, index ekle |
| App Service yavaş | Premium V3’e geç | Profiler aç, hot path bul, async/await pattern uygula |
| Kubernetes pod CPU throttle | Limit’i 2 vCPU yap | HPA ayarla, container gerçekten kaç istek alıyor öğren |
| API yavaş | CDN aç | Önce cache stratejini kur — Redis veya Front Door rules |
Sahada en sık karşılaştığımız performans sorunu: synchronous bağımlılık zinciri. Üç servis sırayla beklerse, en yavaş halkanın p99 değeri tüm transaction’ı bağlar. Asynchronous queueing (Service Bus, Event Grid) buranın ilacıdır.
WAF değerlendirmesini gerçekten yapmak: 90 dakikalık şablon
Microsoft’un Well-Architected Review aracı (waf.azure.com adresinde) güzel bir başlangıçtır ama biz sahada şu şablonu kullanıyoruz:
- 0–15 dk: Workload tanımı. Ne, kim için, SLA hedefi, mevcut sorunlar.
- 15–35 dk: Reliability — RTO/RPO, failover testi geçmişi, single point of failure listesi.
- 35–50 dk: Security — KVKK kapsamı, network izolasyonu, identity yönetimi, secret rotasyonu.
- 50–65 dk: Cost — son 90 günlük fatura kırılımı, Reserved coverage, anomali listesi.
- 65–80 dk: Operations — IaC kapsama oranı, runbook tazeliği, alert kalitesi.
- 80–90 dk: Performance — p50/p95/p99 metrikleri, en yavaş 5 endpoint, aksiyon listesi.
Çıktı: 5–10 maddelik öncelikli aksiyon listesi. Hangisi ne kadar süreceği, ne kadara mal olacağı, hangi sütunu iyileştireceği yazılı olsun. “Bütün bunları yapmak lazım” yetmez; “önce şunu, çünkü şu” gerekir.
Sık Sorulan Sorular
WAF değerlendirmesini ne sıklıkla tekrarlamalıyım?
Workload kritikliğine göre değişir. Kritik üretim için 6 ayda bir, mimari değişikliklerden sonra mutlaka, yıllık ise minimumdur. Her major release sonrası birkaç saatlik mini-değerlendirme de yapın.
Beş sütundan hangisine öncelik vermeliyim?
İş hedefinize göre. Yeni başlayan bir startup için Cost Optimization ve Operational Excellence kritiktir. Olgun finans kuruluşu için Reliability ve Security öncelikli. Büyüyen e-ticaret için Performance Efficiency ve Cost Optimization birlikte.
WAF Microsoft danışmanı olmadan yapılır mı?
Yapılır. Microsoft Learn’deki ücretsiz WAR aracı ve dokümantasyon yeterli. Önemli olan dürüst cevap vermek. Danışman daha çok dış göz olarak değerlidir, sırf rapor için değil.
Azure dışındaki kaynaklarımı (on-prem, AWS) WAF ile değerlendirebilir miyim?
Prensipler evrenseldir, evet. Azure spesifik kontroller (Defender for Cloud, Advisor) işe yaramayacaktır. Ama 5 sütunun mantığı her bulutta ve on-prem’de çalışır. AWS’in kendi Well-Architected Framework’ü de var, oraya da bakılabilir.
WAF değerlendirme sonuçlarını üst yönetime nasıl sunarım?
Risk ve maliyet tablosuyla. Her aksiyonun yanına “yapmazsak ne olur” senaryosunu yazın. “Cost Optimization sütununda 3 öneri ile aylık $14K tasarruf” cümlesi, 47 sayfa rapordan daha etkili.
Sonuç olarak
Well-Architected Framework, Azure üzerinde mimari kararı keyfilikten çıkarıp ölçülebilir hâle getirir. Beş sütunu birden mükemmel olamayacağınızı kabul ederek başlarsanız, hangi trade-off’u neden seçtiğinizi belgeleyebilirsiniz. Bu da bir gün denetim geldiğinde, bir gün ekipte değişiklik olduğunda ya da bir gün yeni bir teknoloji çıktığında kararlarınızı savunulabilir kılar.
Eğer kendi workload’ınızda nereden başlayacağınızı bulamıyorsanız, CloudSpark ekibi 90 dakikalık ücretsiz bir WAF mini-değerlendirme oturumu yapıyor. İletişim sayfasından bize ulaşabilirsiniz.
