Bir bulut sağlayıcısını yalnızca işlemci, RAM kapasitesi, depolama alanı ve aylık liste fiyatı üzerinden değerlendirmek, kurumsal satın alma süreçlerinde yapılan en kritik stratejik hatalardan biridir. İki farklı sağlayıcıdan alınan teklifi düşünün: İlk sağlayıcı çok daha düşük bir aylık fiyat sunarken yedekleme, 7/24 teknik destek ve felaket kurtarma hizmetlerini ek ücrete tabi tutar. İkinci sağlayıcı ise daha yüksek bir başlangıç fiyatı sunmasına rağmen teklife kapsamlı destek planını, açık SLA şartlarını ve belgelenmiş kurtarma süreçlerini dahil eder. Hangi teklifin kurumunuz için daha kârlı olduğu; tamamen iş yükünüzün kritiklik seviyesine, risk toleransınıza ve hesaplanmayan gizli maliyetlere (TCO) bağlıdır.
Bu rehber, bulut sağlayıcısı seçerken sağlayıcıları aynı kriterlerle karşılaştırabileceğiniz, teklifleri şeffaf bir şekilde değerlendirebileceğiniz ve satın alma kararını teknik verilerle gerekçelendirebileceğiniz 30 soruluk bir RFP (Request for Proposal – Teklif Talebi) kontrol listesi sunmaktadır.
Bulut Sağlayıcı Seçiminde RFP Nedir?
Kurumsal altyapı ihtiyaçlarında doğru tedarikçiyi bulmak için sürecin adımlarını ve kullanılan dokümanları netleştirmek gerekir.
RFP, RFI ve RFQ Arasındaki Fark
- RFI (Request for Information – Bilgi Talebi): Pazardaki sağlayıcıların genel yetenekleri, sundukları hizmet modelleri ve teknik kapasiteleri hakkında ön bilgi toplamak için kullanılır.
- RFP (Request for Proposal – Teklif Talebi): Kurumun spesifik ihtiyaçlarına yönelik olarak sağlayıcılardan çözüm mimarisi, hizmet kapsamı, SLA şartları ve detaylı teklif istenen dokümandır. Karşılaştırma bu belge üzerinden yapılır.
- RFQ (Request for Quotation – Fiyat Talebi): Kapsamı, mimarisi ve teknik detayları tamamen netleşmiş standart bir hizmet için doğrudan fiyat teklifi toplama adımıdır.
Bulut Hizmeti Satın Alırken RFP Neden Kullanılır?
- Tüm aday sağlayıcıları standart ve nesnel kriterlerle karşılaştırmak.
- Altyapı, güvenlik ve operasyonel gereksinimleri net bir şekilde belgelemek.
- Bant genişliği, API istekleri veya destek gibi gizli maliyetleri önceden ortaya çıkarmak.
- Güvenlik, uyumluluk (KVKK vb.) ve sertifikasyon kanıtlarını resmi olarak talep etmek.
- Hizmetten çıkış (exit strategy) ve veri taşıma koşullarını sözleşme öncesi belirlemek.
RFP Hazırlamadan Önce Hangi Bilgiler Belirlenmeli?
- İş yükünün türü (E-ticaret, ERP, test ortamı vb.)
- Beklenen anlık trafik ve maksimum kapasite gereksinimi
- Performans (IOPS, ağ gecikmesi) gereksinimleri
- Sistem erişilebilirlik (Uptime) hedefleri
- Veri hassasiyeti ve yasal uyumluluk zorunlulukları
- Kesinti durumundaki kurtarma hedefleri (RTO ve RPO)
- Kurum içi teknik ekibin kapasitesi ve yönetilen destek ihtiyacı
Bulut Sağlayıcı Seçerken Sorulacak 30 Soru
Aşağıdaki sorular, sağlayıcıların teknik kapasitelerini ve sözleşme taahhütlerini ölçmek için RFP dokümanınıza eklemeniz gereken temel kriterlerdir.
1. Sağlayıcı hangi bulut hizmeti modellerini sunuyor?
Neden önemli? İhtiyacınız IaaS (Hizmet olarak Altyapı) olabilir, ancak gelecekte PaaS (Hizmet olarak Platform) veya Kubernetes kümelerine geçiş yapmak isteyebilirsiniz. Sağlayıcının ekosistemi, büyüme planlarınızla örtüşmelidir.
İstenecek kanıt: Güncel hizmet kataloğu ve mimari dokümantasyon.
Yanıt değerlendirmesi: Tüm modellerin desteklendiğini iddia eden genel geçer yanıtlar risklidir; belirli hizmetlerde uzmanlaşıldığını gösteren teknik kapsam belgeleri olumludur.
2. Altyapı hangi veri merkezlerinde barındırılıyor?
Neden önemli? Veri merkezinin fiziksel konumu ağ gecikmesini (latency) ve yasal uyumluluğu doğrudan etkiler. Sağlayıcının kendi veri merkezini mi işlettiği yoksa Tier III/IV standartlarında üçüncü taraf bir veri merkezinden alan (colocation) mı kiraladığı bilinmelidir.
İstenecek kanıt: Veri merkezi konum bilgileri, tesis sertifikasyonları ve mülkiyet/kiralama altyapı sorumlulukları.
3. Kaynaklar nasıl ölçeklendiriliyor?
Neden önemli? Trafik artışlarında kaynakların (CPU, RAM) dikey olarak veya sunucu sayısının yatay olarak nasıl artırıldığı sistemin dayanıklılığını belirler. Otomatik ölçeklendirme (auto-scaling) her mimaride varsayılan değildir.
İstenecek kanıt: Ölçeklendirme API dokümantasyonu, limitler ve yapılandırma rehberleri.
4. Kaynak izolasyonu ve performans garantileri nasıl sağlanıyor?
Neden önemli? Paylaşımlı bulut altyapılarında “Noisy Neighbor” (gürültülü komşu) sorunu yaşanabilir. Kaynakların sanal makineler (VM) veya fiziksel sunucular (Bare Metal) seviyesinde ne kadar izole edildiği, disk IOPS ve ağ performansını doğrudan etkiler.
İstenecek kanıt: Kaynak tahsis modeli, hipervizör politikaları ve IOPS/Ağ bant genişliği limitleri.
5. Hizmetin erişilebilirlik hedefi ve SLA şartları nedir?
Neden önemli? %99.9 ile %99.99 uptime arasındaki fark, yıllık dakikalarca kesinti anlamına gelir. Bu oranın neleri kapsadığı (sadece ağ mı, yoksa disk ve sanallaştırma katmanı mı) ve planlı bakımların hesaba katılıp katılmadığı kritiktir.
İstenecek kanıt: SLA dokümanı, ölçüm metodolojisi ve hariç tutulan (istisna) durumlar.
6. Donanım ve ağ yedekliliği nasıl tasarlanıyor?
Neden önemli? Tek bir switch veya jeneratör arızasının tüm hizmeti durdurmaması gerekir. Güç (N+1, 2N), soğutma ve ağ yedekliliği fiziksel altyapının temelidir.
İstenecek kanıt: Veri merkezi mimari şeması, hata etki alanları (fault domains) açıklaması.
7. Felaket kurtarma (Disaster Recovery) planı var mı?
Neden önemli? Veri merkezinin tamamen devre dışı kalması (yangın, doğal afet, büyük çaplı siber saldırı) durumunda, iş yükünüzün farklı bir coğrafi bölgede yeniden ayağa kaldırılabilmesi gerekir.
İstenecek kanıt: Sağlayıcının felaket kurtarma politikası, test sıklığı ve örnek senaryolar.
8. RTO ve RPO hedefleri nedir?
Neden önemli? RTO (Kurtarma Zamanı Hedefi), sistemin ne kadar sürede geri geleceğini; RPO (Kurtarma Noktası Hedefi) ise geriye dönük ne kadarlık verinin feda edilebileceğini belirler. Bu değerler SLA’nın ötesinde iş sürekliliğinin ölçütüdür.
İstenecek kanıt: Hizmet bazlı (veritabanı, depolama, VM) RTO/RPO matrisi.
9. Yedekleme hizmeti neleri kapsıyor?
Neden önemli? Yedekleme, felaket kurtarma ile aynı şey değildir. Günlük veya saatlik yedeklerin nerede tutulduğu, değiştirilemez (immutable) olup olmadığı fidye yazılımı (ransomware) koruması için şarttır.
İstenecek kanıt: Yedekleme politikası, saklama (retention) süreleri.
10. Geri yükleme testleri ne sıklıkla yapılıyor?
Neden önemli? Alınan yedeğin çalışıp çalışmadığı ve ne kadar sürede geri yüklendiği test edilmeden bilinemez.
İstenecek kanıt: Test prosedürleri ve ortalama geri yükleme hızı (MB/s veya GB/dakika).
11. DDoS saldırılarına karşı hangi korumalar mevcut?
Neden önemli? Hacimli (Volumetric) DDoS saldırıları altyapınızı erişilemez kılabilir. Sağlayıcının L3/L4 ağ katmanı korumasını standart olarak sunup sunmadığı ve L7 (uygulama katmanı) için ek ücret talep edip etmediği netleşmelidir.
İstenecek kanıt: DDoS koruma kapasitesi (Tbps), müdahale RTO’su ve ek maliyet tablosu.
12. Ağ güvenliği nasıl sağlanıyor?
Neden önemli? Sunucularınızın genel internete kapalı özel ağlarda (VPC/Private Network) çalıştırılabilmesi ve donanımsal/yazılımsal güvenlik duvarları arkasında yapılandırılabilmesi gerekir.
İstenecek kanıt: Ağ segmentasyon yetenekleri, Firewall ve VPN konfigürasyon seçenekleri.
13. Kimlik ve erişim yönetimi (IAM) nasıl çalışıyor?
Neden önemli? Kontrol paneline kimin, hangi yetkiyle eriştiği loglanmalıdır. Çok Faktörlü Kimlik Doğrulama (MFA) ve rol bazlı erişim kontrolü (RBAC) zorunludur.
İstenecek kanıt: IAM dokümantasyonu, audit log (denetim izi) kapsamı.
14. Veriler aktarım sırasında ve depolama sırasında şifreleniyor mu?
Neden önemli? At-rest (depolanan) ve in-transit (aktarılan) verinin şifrelenmesi veri hırsızlığını önler. Anahtarların yönetiminin (KMS) müşteriye bırakılıp bırakılamayacağı sorgulanmalıdır.
İstenecek kanıt: Şifreleme standartları (AES-256 vb.) ve anahtar yönetimi politikası.
15. Güvenlik olayları nasıl tespit ediliyor ve bildiriliyor?
Neden önemli? Altyapıda bir sızıntı veya ihlal tespit edildiğinde müşteriye bildirim süresi, olay müdahalesinin hızını belirler.
İstenecek kanıt: Olay müdahale (Incident Response) prosedürü ve yasal bildirim süreleri taahhüdü.
16. Hangi güvenlik sertifikaları ve bağımsız denetimler mevcut?
Neden önemli? ISO 27001, SOC 2 Type II, PCI-DSS gibi sertifikalar sağlayıcının süreçlerini kanıtlar. Ancak bu sertifikaların sağlayıcının tüm tesisleri için mi yoksa sadece ofisi için mi geçerli olduğu incelenmelidir.
İstenecek kanıt: Güncel sertifika kopyaları ve geçerlilik kapsamı (Scope of Applicability).
17. Veri konumu ve veri egemenliği nasıl yönetiliyor?
Neden önemli? KVKK veya GDPR gereği verilerinizin nerede barındırıldığı kritiktir. Türkiye’deki bir veri merkezi tek başına yeterli değildir; yedeklerin veya destek personelinin yurt dışından erişim sağlayıp sağlamadığı da önemlidir.
İstenecek kanıt: Veri işleme sözleşmesi ve yetkili alt işleyen (sub-processor) listesi.
18. KVKK ve diğer uyumluluk gereksinimleri nasıl destekleniyor?
Neden önemli? Sağlayıcı fiziksel güvenliği sağlarken veri güvenliği sorumluluğu müşteridedir. Sağlayıcının bu uyumluluğu kolaylaştıracak hangi araçları sunduğu değerlendirilmelidir.
İstenecek kanıt: Veri sorumlusu/işleyen sorumluluk matrisi.
19. Teknik destek hangi saatlerde ve hangi kanallardan sağlanıyor?
Neden önemli? Sorun anında yalnızca e-posta veya ticket üzerinden sağlanan mesai içi destek, kritik iş yükleri için yetersizdir. Telefonla 7/24 doğrudan bir mühendise erişim imkanı sorgulanmalıdır.
İstenecek kanıt: Destek paketi kapsamları, iletişim kanalları.
20. Kritik arızalar için müdahale ve çözüm hedefleri nedir?
Neden önemli? İlk yanıt süresi (SLA) ile sorunun çözüm süresi farklıdır. “15 dakikada yanıt” taahhüdü, sorunun 15 dakikada çözüleceği anlamına gelmez.
İstenecek kanıt: Arıza öncelik seviyeleri (Sev1, Sev2 vb.) ve eskalasyon hiyerarşisi.
21. İzleme ve performans raporları sunuluyor mu?
Neden önemli? Kaynak tüketimi, ağ trafiği ve erişilebilirlik verilerinin müşteriye şeffaf bir portal veya API üzerinden sunulması kapasite planlaması için şarttır.
İstenecek kanıt: İzleme paneli demosu veya metrik dışa aktarma (export) yetenekleri.
22. Hizmetin toplam maliyeti (TCO) nasıl hesaplanıyor?
Neden önemli? Etiket fiyatı yanıltıcıdır. Giden ağ trafiği (egress), yedekleme depolama alanı, yönetilen hizmet bedelleri ve destek paketleri eklendiğinde toplam sahip olma maliyeti katlanabilir.
İstenecek kanıt: Kalem kalem ayrılmış, şeffaf bir fiyatlandırma simülasyonu.
23. Kullanım arttığında maliyet nasıl değişiyor?
Neden önemli? Başlangıçta ucuz olan bir hizmet, trafik veya depolama eşikleri aşıldığında agresif şekilde pahalılaşabilir. Aşım ücretleri net olmalıdır.
İstenecek kanıt: Kota aşım birim fiyatları ve ölçeklendirme maliyet tablosu.
24. Hizmet kesintisi durumunda SLA telafisi nasıl uygulanıyor?
Neden önemli? SLA ihlal edildiğinde faturaya yansıyacak iade kredilerinin (service credits) hesaplanma yöntemi ve talep süreci bürokratik olmamalıdır. SLA telafisi hiçbir zaman kaybedilen ticari kârı karşılamaz, sadece hizmet bedelini iade eder.
İstenecek kanıt: Sözleşmedeki SLA ihlal ve iade prosedürü maddeleri.
25. Mevcut altyapıdan geçiş (migration) desteği sunuluyor mu?
Neden önemli? Verilerin mevcut ortamdan kesintisiz veya minimum kesintiyle yeni sağlayıcıya taşınması operasyonel bir yüktür. Sağlayıcının bu süreçte mühendislik desteği verip vermediği sorgulanmalıdır.
İstenecek kanıt: Geçiş planı metodolojisi ve ilgili sorumluluk matrisi.
26. Sağlayıcı değiştirmek istediğimizde verilerimizi nasıl alabiliriz?
Neden önemli? Hizmetten memnun kalmazsanız verilerinizi açık bir formatta (VHD, VMDK, SQL dump vb.) dışa aktarabilmeniz ve bu işlem için fahiş ağ çıkış ücretleri ödememeniz gerekir.
İstenecek kanıt: Exit strategy (Çıkış planı) ve veri dışa aktarma (export) maliyetleri.
27. Vendor lock-in (Sağlayıcıya bağımlılık) riski nasıl azaltılıyor?
Neden önemli? Açık kaynak kodlu teknolojiler (KVM, OpenStack, Kubernetes) yerine tamamen sağlayıcıya özgü (proprietary) servisler kullanmak, gelecekte başka bir sağlayıcıya geçişi teknik olarak imkansız hale getirebilir.
İstenecek kanıt: Altyapı teknolojileri listesi ve açık standart uyumluluğu.
28. Altyapı yönetimi ve operasyonel sorumluluk kimde?
Neden önemli? Sunucu kiralandığında işletim sistemi güncellemesi, güvenlik yamaları ve uygulama katmanı izlemesi kime aittir? Bu, “Yönetilmeyen” ve “Yönetilen (Managed)” hizmetler arasındaki temel farktır.
İstenecek kanıt: Paylaşımlı sorumluluk (Shared Responsibility) modeli dokümanı.
29. Hizmet büyüdüğünde sağlayıcı aynı gereksinimleri karşılayabilir mi?
Neden önemli? Start-up aşamasındaki ihtiyaçlarınızla, kurumsal faza geçtiğinizdeki ihtiyaçlarınız farklı olacaktır. Sağlayıcının donanım havuzu genişleme hızı ve ağ omurgası büyüme vizyonunuzu desteklemelidir.
İstenecek kanıt: Donanım rezervleri, ağ kapasitesi ve teknolojik yol haritası.
30. Sözleşme, fesih ve hizmet sonlandırma şartları nelerdir?
Neden önemli? Uzun dönemli sözleşmelerde fiyat artış oranları (TÜFE/ÜFE veya döviz bazlı), erken fesih cezaları ve sözleşme bitiminde sunuculardaki verilerin güvenli imhası (data wiping) yasal güvenceye alınmalıdır.
İstenecek kanıt: Örnek sözleşme taslağı ve veri silme sertifikasyon prosedürü.
Bulut Sağlayıcı RFP Kontrol Listesi Nasıl Kullanılır?
Yukarıdaki 30 soru tek başına bir işe yaramaz; bunları bir tedarikçi değerlendirme sürecine dönüştürmelisiniz.
- Her Sağlayıcıdan Aynı Bilgileri İsteyin: Farklı sağlayıcılardan gelen farklı formatlardaki teklifleri karşılaştırmak imkansızdır. Kendi RFP şablonunuzu oluşturun ve sağlayıcıların doğrudan bu şablondaki sorulara yanıt vermesini zorunlu tutun.
- Beyan ile Kanıtı Birbirinden Ayırın: Sağlayıcıların “Askeri düzeyde şifreleme sunuyoruz” veya “Sıfır kesinti garantisi” gibi pazarlama odaklı beyanlarını kabul etmeyin. Her beyan için SLA belgesi, sızma testi özeti, sertifika ve mimari şema gibi teknik kanıtlar isteyin.
- Zorunlu ve Tercih Edilen Gereksinimleri Ayırın: Tüm gereksinimlerin ağırlığı aynı değildir. Verilerinizin Türkiye’de kalması (KVKK) zorunlu (Must-have) bir kriter iken, API tabanlı otomatik ölçeklendirme tercih edilen (Nice-to-have) bir özellik olabilir.
- Yanıtları Yazılı Olarak Kaydedin: Toplantılarda verilen sözlü taahhütlerin geçerliliği yoktur. Tüm teknik destek sürelerinin, donanım garantilerinin ve SLA telafilerinin sözleşme ekinde yazılı olarak yer aldığından emin olun.
Sağlayıcıları Karşılaştırmak İçin Örnek Puanlama Modeli
Bulut sağlayıcılardan gelen RFP yanıtlarını nesnel bir şekilde karşılaştırmak için aşağıdaki ağırlıklandırılmış puanlama tablosunu kullanabilirsiniz. Ağırlıklar, kurumunuzun risk profiline göre değiştirilmelidir.
| Değerlendirme Alanı | Örnek Ağırlık |
|---|---|
| Teknik altyapı ve performans | %15 |
| Erişilebilirlik ve felaket kurtarma (DR) | %20 |
| Güvenlik, veri konumu ve uyumluluk | %20 |
| Teknik destek ve operasyonel yönetim | %15 |
| Toplam sahip olma maliyeti (TCO) | %15 |
| Ölçeklenebilirlik ve esneklik | %5 |
| Veri taşınabilirliği ve çıkış planı (Exit Strategy) | %10 |
| Toplam | %100 |
Sağlayıcıları 1–5 Arasında Puanlama
Her bir RFP sorusu için sağlayıcı yanıtlarını aşağıdaki ölçeğe göre puanlayın:
- 1 Puan: Gereksinim karşılanmıyor veya yanıt yok.
- 2 Puan: Gereksinim kısmen karşılanıyor, ciddi operasyonel eksikler veya riskler var.
- 3 Puan: Gereksinim standart düzeyde karşılanıyor.
- 4 Puan: Gereksinim iyi seviyede karşılanıyor ve belgelerle kanıtlanabiliyor.
- 5 Puan: Gereksinim güçlü biçimde, endüstri standartlarının üzerinde karşılanıyor ve kapsamlı kanıt mevcut.
En Ucuz Bulut Sağlayıcısı Her Zaman En İyi Seçim midir?
Liste fiyatı ile Toplam Sahip Olma Maliyeti (TCO) tamamen farklıdır. Sadece sunucunun işlemci ve RAM birim fiyatına bakılarak yapılan seçimler, aylar içinde ciddi bütçe aşımlarına yol açar. Gerçek TCO hesabına temel işlem ve depolama maliyetine ek olarak; giden ağ trafiği (Egress), yedekleme saklama alanı ücretleri, teknik destek paketleri, lisanslar ve sistemleri yönetecek kurum içi personelin iş gücü maliyeti eklenmelidir.
Hangi Bulut Sağlayıcısı Hangi İş Yükü İçin Uygun?
- Web Siteleri ve E-Ticaret: Ağ bant genişliği limitleri esnek olan, yük dengeleme ve L7 DDoS korumasını güçlü sunan, yatay ölçeklenmeye yatkın sağlayıcılar.
- Kurumsal Uygulamalar ve Veritabanları: IOPS değeri garantili depolama sunan, RTO ve RPO süreleri dakikalar seviyesinde olan ve yüksek erişilebilirlik (HA) mimarisini destekleyen sağlayıcılar.
- SaaS ve Ürün Şirketleri: API yetenekleri, IaC (Infrastructure as Code) desteği ve otomasyon araçlarına uyumluluk maliyet öngörülebilirliği.
- Kritik İş Yükleri (Finans, Sağlık): Felaket kurtarma senaryoları kanıtlanmış, regülasyonlara %100 uyumlu ve 7/24 mühendis seviyesinde olay müdahalesi sunan özel bulut çözümleri.
Bulut Sağlayıcı Seçiminde Son Karar Nasıl Verilmeli?
Bulut altyapısı satın alma kararı verirken üç temel kuralı ihlal etmemelisiniz: Öncelikle şirketinizin teknik iş yüklerini, uyumluluk sınırlarını ve kabul edilebilir kesinti riskini netleştirmeden sadece “fiyat karşılaştırması” yapmayın. İkinci olarak, tedarikçilerin satış toplantılarındaki sözlü beyanlarına değil; mimari belgelere, SLA metinlerine, sertifikasyon kapsamlarına ve PoC (test) sonuçlarına güvenin. Son olarak satın almayı, sadece bugünün faturası olarak değil; toplam sahip olma maliyetinin (TCO) bir yatırımı olarak görün.
