Teknik

Epin Yazılımında Bulut mu Kendi Sunucun mu? Sahiplik Sandığın Şeyin Aslında Kime Ait Olduğunu Rakamlarla Gösteriyorum

Epin scriptini bulutta mı kendi sunucunda mı çalıştırmalısın? Sahiplik, maliyet, yedek, güvenlik ve KVKK tarafını karşılaştırmalı tabloyla açıklıyoruz.

Epin Yazılımında Bulut mu Kendi Sunucun mu? Sahiplik Sandığın Şeyin Aslında Kime Ait Olduğunu Rakamlarla Gösteriyorum

Çoğu kişi şunu sanır: sunucu benimse sistem de benimdir, kimse fişi çekemez, tam bağımsızlık. Kulağa mantıklı geliyor. Ama gerçekte kendi sunucusunu kiralayan çoğu işletme sahibi, bir sabah "veritabanı bağlantısı kurulamadı" hatasıyla uyanıp, ne olduğunu anlamaya çalışırken sekiz saat satış kaybeder. Sahiplik, kontrolle aynı şey değil; sorumlulukla aynı şey.

Bu yazıda iki ayrı kavramı birbirinden ayıracağım: lisans sahipliği ve sunucu sahipliği. Bunları karıştırmak, sektörde en pahalıya patlayan hatalardan biri. Sonrasında maliyet, hız, yedek, güvenlik ve veri sorumluluğu tarafını rakamlarla karşılaştırıp, hangi ciroda hangi modelin doğru olduğunu netleştireceğiz.

2 kalemSahiplik ikiye ayrılır: lisans ve sunucu
8-14 saYanlış yapılandırmada tipik kesinti süresi
%70Kesintilerin yapılandırma kaynaklı olma oranı
3-2-1Uygulanması gereken yedekleme kuralı

Kendi sunucun tam sahiplik demek sanıyorsun, faturayı görünce fikrin değişir

Kendi sunucun dediğin şey de aslında kiralık. Bir veri merkezinin kabininde, birinin elektriğiyle, birinin ağıyla çalışıyor. Fark şu: o makinedeki işletim sistemi, güvenlik duvarı, PHP sürümü, veritabanı ayarları, yedek planı ve saldırı yönetimi tamamen senin sorumluluğunda. Kimse senin yerine güncelleme yapmaz.

Bu sorumluluğun gizli bir bedeli var: zamanın. Sistem yöneticiliği bilmiyorsan ya birine ödeyeceksin ya da öğrenmeye vakit ayıracaksın. Aylık sunucu 400 lira görünür ama düzgün kurulum, izleme ve müdahale için bir teknik desteğe ihtiyaç duyduğunda gerçek maliyet üçe katlanır. Sunucu ucuz, sunucuyu ayakta tutmak pahalı.

Lisans sahipliği ile sunucu sahipliği neden farklı şeyler?

Burada net olmak lazım. E-pin scripti aldığında sahip olduğun şey kullanım hakkıdır: kaynak kodu sende, domainin sana ait, veritabanı senin. Bu, sunucunun nerede durduğuyla ilgili değil. Aynı lisansı bulut tarafında yönetilen bir ortamda da çalıştırabilirsin, kendi kiraladığın makinede de.

Yani "bulutta olursa yazılım benim olmaz" cümlesi teknik olarak doğru değil. Dikkat etmen gereken tek şey sözleşmede şunların yazılı olması: kod sana teslim mi, veritabanının tam yedeğini alabiliyor musun, istediğin an başka bir ortama taşıma hakkın var mı. Bu üç maddeyi garanti eden bir e-pin satış yazılımı nerede barındığından bağımsız olarak senindir. Pinova'nın yaklaşımı da bu: barındırma tercihi ayrı, lisans hakkı ayrı.

KriterYönetilen bulutKendi sunucun (VPS/VDS)
Kurulum süresiSaatler1-3 gün (tecrübeye göre)
Aylık görünen maliyetSabit, öngörülebilirDüşük görünür
Gerçek toplam maliyetTek kalemSunucu + teknik destek + zaman
Güncelleme sorumluluğuSağlayıcıSen
YedeklemeOtomatik, planlıKurmazsan yok
Trafik patlamasıÖlçeklenebilirManuel yükseltme, kesinti riski
Özel yapılandırma özgürlüğüSınırlıTam
Arıza anında müdahaleSağlayıcı ekibiSen veya kiraladığın kişi
Uygun ciro bandıBaşlangıç - ortaOrta - yüksek hacim

Trafik patlaması geldiğinde hangisi ayakta kalıyor?

Dijital ürün satışında trafik düz gitmez. Popüler bir oyun yeni sezon açar, indirim yapar, yayıncı senin sitenden bahseder ve on dakikada normalin on katı ziyaretçi gelir. İşte o an gerçek test başlar. Sabit kaynaklı bir sunucuda bellek dolar, veritabanı bağlantı limitine dayanır, sayfalar açılmaz. En çok satış yapabileceğin anda site kapanır.

Bu senaryoya hazırlanmanın iki yolu var: ya normal zamanda gereğinden büyük bir sunucu kiralayıp boşa para ödersin, ya da esnek ölçeklenen bir ortam kullanırsın. Ayrıca kullandığın dijital ürün satış scriptinin önbellekleme, sorgu verimliliği ve statik dosya servisi tarafında düzgün yazılmış olması gerekir. Kötü yazılmış bir yazılımı en güçlü sunucu bile kurtarmaz; sadece çöküşü biraz geciktirir.

Epin sitelerinde yaşanan kesintilerin kaynak dağılımı

  • Hatalı yapılandırma ve güncelleme 45%
  • Kaynak yetersizliği / trafik 25%
  • Saldırı ve güvenlik olayı 20%
  • Veri merkezi kaynaklı 10%

Yedek, güncelleme ve güvenlik yamalarını kim yapacak?

Bu soru şaka gibi görünür ama işin kaderini belirler. Yedeği olmayan bir epin sitesi, bir veritabanı hatasında tüm satıcı bakiyelerini, sipariş geçmişini ve kullanılmamış kod stoğunu kaybeder. Bu kayıp geri gelmez. Uygulanması gereken kural basit: en az üç kopya, iki farklı ortam, bir kopya tamamen ayrı yerde.

Güvenlik tarafı da benzer. PHP ve veritabanı sürümlerinin güncel tutulması, yönetim paneli yolunun gizlenmesi, iki adımlı doğrulama, yönetici oturumlarının IP kaydı. Kendi sunucundaysan bunların hepsi senin listende. Yönetilen ortamda büyük kısmı sağlayıcının işi olur. Hangi yolu seçersen seç, epin yazılım katmanında yönetici işlem günlüğünün tutulması pazarlık konusu değildir; bir gün "bu bakiyeyi kim düşürdü" sorusunun cevabını arayacaksın.

Geri dönüş provası yap

Yedeğin var demek yeterli değil. Üç ayda bir yedeği ayrı bir test ortamına gerçekten geri yükle. Çalışmayan bir yedek dosyası, olmayan yedekten daha tehlikelidir çünkü sana boş bir güven verir.

E-pin stoğu ve müşteri verisi nerede duruyor? KVKK tarafı

Sen bir veri sorumlususun. Müşterinin adı, telefonu, e-postası, sipariş geçmişi ve ödeme izleri senin sisteminde. Verinin hangi ülkede, hangi sağlayıcıda tutulduğu ve kimlerin erişebildiği kayda geçmeli. Yurt dışındaki bir sağlayıcıda barındırıyorsan aydınlatma metninde bunun belirtilmesi gerekir.

Bir de teknik hijyen meselesi var: kullanılmamış epin kodları veritabanında açık metin olarak durmamalı, şifrelenmiş saklanmalı. Kodun görüntülenme anı loglanmalı. Yönetici bile kodu gereksiz yere görememeli. Bu davranışlar barındırma tercihinden bağımsız olarak e-pin satış scriptinin içine yazılmış olmalı. Sunucu seçimi bu açığı kapatmaz; sadece kimin sorumlu olduğunu değiştirir.

Karar: hangi cirodan sonra kendi sunucuna geçmelisin?

Pratik eşik şudur: günlük sipariş sayın üç haneli değilse, özel bir entegrasyon zorunluluğun yoksa ve bünyende sistem yöneticiliği yapabilecek biri yoksa yönetilen ortamda kal. Enerjini ürün, fiyat ve pazarlamaya harca. Sunucuyla uğraşmak sana bir kuruş ek satış getirmez.

Kendi sunucuna geçmenin mantıklı olduğu an şu: hacim büyümüş, kaynak ihtiyacın öngörülebilir hale gelmiş, özel işler yapman gerekiyor ve teknik bir sorumlu var. O noktada kontrol gerçekten değer üretmeye başlar. Bu kararı verirken yazılımın taşınabilirliğini kontrol et: veritabanı ve dosya yapısı temiz bir şekilde dışa aktarılabiliyorsa geçiş bir hafta sonu işidir.

Kontrol maddesiNeden gerekliDurum
Kaynak kodun sana teslimiLisans sahipliğinin somut kanıtıZorunlu
Tam veritabanı yedeği indirme hakkıTaşınabilirlik ve bağımsızlıkZorunlu
Otomatik günlük yedek + dış kopyaVeri kaybının tek gerçek panzehiriZorunlu
Epin kodlarının şifreli saklanmasıSızıntıda zararı sınırlarZorunlu
Yönetici işlem günlüğüİç kaynaklı kayıpları tespit içinZorunlu
Yedeği geri yükleme provasıYedeğin çalıştığını doğrulamakÖnerilir
Kesinti izleme ve uyarıMüşteriden önce haberdar olmakÖnerilir
Taşıma desteği taahhüdüModel değişiminde kilitlenmemekÖnerilir

Barındırma tercihini yazılım belirlemesin

Pinova lisansı, kodun ve verinin sende kalması esasına dayanır; bulutta da kendi sunucunda da aynı sistemi çalıştırırsın.

Bulutta barındırırsam yazılım gerçekten benim olur mu?

Evet, sahiplik barındırma yerinden değil lisans sözleşmesinden gelir. Kaynak kodun sana teslim edilmesi, tam veritabanı yedeğini indirme hakkın ve istediğin an başka bir ortama taşıma imkânın varsa yazılım her koşulda senindir.

Kendi sunucum daha mı ucuz?

Görünen aylık tutar genelde daha düşüktür, toplam maliyet ise değildir. Kurulum, güncelleme, izleme, güvenlik ve arıza müdahalesi ya teknik bir kişiye ödeme ya da senin zamanın olarak faturalanır. Bu kalemler eklendiğinde fark çoğu zaman kapanır.

Trafik patladığında sitem çökmemesi için ne yapmalıyım?

Önce yazılım tarafında önbellekleme ve verimli sorgular, sonra altyapı tarafında esnek kaynak gerekir. Kampanya öncesi kaynak artışı planla, statik dosyaları ayrı servis et ve kesinti izleme kur ki sorunu müşteriden önce sen görsün.

Epin kodlarını veritabanında nasıl saklamalıyım?

Kullanılmamış kodlar açık metin olarak tutulmamalı, şifrelenmiş biçimde saklanmalıdır. Kodun kim tarafından ne zaman görüntülendiği loglanmalı ve yönetici erişimi bile gereksiz görüntülemeye izin vermeyecek şekilde sınırlandırılmalıdır.

Barındırma kararını vermeden önce sistemin kendisini görmek işini kolaylaştırır. Panel yapısını, sipariş akışını ve stok yönetimini canlı demo üzerinden incele; ihtiyacın olan kaynak seviyesini oradaki modüllere bakarak tahmin et, sonra lisans ve destek seçeneklerini karşılaştır.

Daha Fazlasını Keşfedin

Dijital ürün satışı ve otomasyon üzerine güncel rehberlere göz atın.

Tüm Yazıları Gör →
Bu yazıyı paylaşın
Bu yazıyı beğendiniz mi?
Teşekkürler!
← Tüm yazılar