Pazaryerinde SLA ve SLO Yönetimi: Kesintisiz Hizmet İçin Ölçülebilir Operasyon Rehberi

Bir pazaryerinde teknik sorun yalnızca teknik ekiplerin problemi değildir. Ödeme sayfasının birkaç dakika açılmaması, satıcının ürün yükleyememesi ya da sipariş durumunun kargoya zamanında aktarılmaması doğrudan geliri, güveni ve platformun itibarını etkiler. Üstelik büyüyen bir pazaryerinde “sistem çalışıyor” demek yeterli değildir. Hangi hizmetin ne kadar erişilebilir olduğu, hangi işlemin kaç saniyede tamamlandığı ve sorun çıktığında ne kadar sürede müdahale edildiği ölçülmelidir.

SLA ve SLO yaklaşımı bu noktada devreye girer. SLA, platformun müşterilerine veya iş ortaklarına verdiği hizmet taahhüdünü tanımlar. SLO ise bu taahhüdü teknik olarak ölçülebilir hedeflere çevirir. Birlikte kullanıldığında ekiplerin sezgiyle değil, ortak bir hizmet standardıyla çalışmasını sağlar. Bu rehberde pazaryeri sahipleri ve operasyon yöneticileri için SLA, SLO ve ilgili göstergelerin nasıl tasarlanacağını; hedeflerin nasıl ölçüleceğini ve günlük operasyona nasıl yerleştirileceğini ele alıyoruz.

SLA, SLO ve SLI arasındaki fark nedir?

Bu üç kavram birbirine yakın görünür, ancak farklı sorulara cevap verir:

• SLI (Service Level Indicator): Hizmetin gerçek performansını ölçen göstergedir. Örneğin ödeme API'sinin başarılı istek oranı veya ürün arama yanıt süresi birer SLI'dır.
• SLO (Service Level Objective): SLI için belirlenen hedef aralıktır. Örneğin son 30 günde ödeme işlemlerinin yüzde 99,9'unun başarılı olması.
• SLA (Service Level Agreement): Müşteriye, satıcıya veya entegrasyon ortağına verilen resmi taahhüttür. Hedef tutmazsa hizmet kredisi, ücret indirimi ya da başka bir telafi mekanizması içerebilir.

Kısaca SLI ölçer, SLO hedef koyar, SLA ise bu hedefi ticari bir sözleşmeye dönüştürür. Bir pazaryeri için önce doğru SLI'ları belirlemek, sonra gerçekçi SLO'lar tanımlamak daha sağlıklıdır. Ölçmediğiniz bir performans için söz vermek, ileride hem operasyonel hem de hukuki risk yaratabilir.

Örneğin “platformumuz hızlıdır” bir pazarlama cümlesidir. “Kategori sayfalarının yüzde 95'i 1,5 saniyeden kısa sürede, yüzde 99'u 3 saniyeden kısa sürede yanıtlanır” ise ölçülebilir bir SLO'dur. Satıcı paneli için de “ürün güncelleme isteklerinin yüzde 99,5'i beş saniye içinde sonuçlanır” gibi bir hedef tanımlanabilir.

Pazaryerinde hangi hizmetler için hedef belirlenmeli?

SLA ve SLO çalışmasına bütün sistemi tek parça kabul ederek başlamak çoğu zaman hatalıdır. Kullanıcıya görünen kritik yol ile arka plandaki destek servislerini ayırın. Her hizmetin iş üzerindeki etkisi farklıdır.

Alıcı deneyiminin kritik adımları

Alıcı tarafında aşağıdaki akışlar doğrudan satışla bağlantılıdır:

1. Ana sayfa, kategori ve ürün sayfalarının açılması
2. Arama ve filtreleme sonuçlarının dönmesi
3. Sepete ürün ekleme ve sepetin güncel kalması
4. Ödeme başlatma ve ödeme sonucunun doğrulanması
5. Sipariş onayının oluşturulması
6. Kargo ve teslimat bilgilerinin görüntülenmesi
7. İade talebinin başlatılması

Bu akışlarda yalnızca erişilebilirlik değil, yanıt süresi ve işlem başarısı da ölçülmelidir. Bir ödeme servisi HTTP düzeyinde çalışıyor görünebilir, fakat bankadan dönen sonuçların sisteme işlenmesi gecikiyorsa kullanıcı deneyimi yine bozulur.

Satıcı operasyonlarının kritik adımları

Satıcılar için hizmet standardı farklılaşır. Ürün oluşturma, toplu katalog aktarımı, stok güncelleme, fiyat değişikliği, sipariş kabulü, fatura yükleme ve kargo etiketi alma gibi işlemler satıcının günlük iş akışını belirler.

Bir satıcı stok bilgisini güncellediğinde bu değişiklik alıcı tarafında ne kadar sürede görünmelidir? Beş dakika içinde görünmesi gereken bir bilgi iki saat gecikiyorsa, sistem tamamen kapalı olmasa bile ticari olarak güvenilmezdir. Bu nedenle veri tazeliği de bir SLI olarak izlenmelidir.

İç ekiplerin kullandığı servisler

Raporlama, komisyon hesaplama, satıcı ödemeleri, bildirim gönderimi, arama indeksleme ve moderasyon servisleri çoğu zaman doğrudan alıcı ekranında görünmez. Buna rağmen aksaklıkları birikerek büyür. Örneğin komisyon hesabı gece çalışmadığında ertesi gün satıcı bakiyeleri ve finans raporları yanlış görünebilir.

Bu servisler için gerçek zamanlı erişilebilirlik yerine işin zamanında tamamlanması daha anlamlı bir hedeftir. “Günlük komisyon hesaplama işi her gün 06.00'ya kadar yüzde 99,9 oranında tamamlanır” buna örnek verilebilir.

İyi bir SLO nasıl yazılır?

İyi bir SLO; hizmeti, ölçüm yöntemini, zaman aralığını ve başarı koşulunu açıkça belirtir. “Sistem hızlı olacak” bir hedef değildir. Hedef şu dört soruyu yanıtlamalıdır:

• Ne ölçülüyor?
• Nereden ve hangi kullanıcı yolundan ölçülüyor?
• Hangi zaman penceresinde değerlendiriliyor?
• Başarılı kabul edilme koşulu nedir?

Örnek bir SLO şöyle yazılabilir: “Üretim ortamında, aylık ölçüm döneminde, ödeme başlatma isteklerinin en az yüzde 99,9'u beş saniye içinde başarılı sonuçlanacaktır.” Burada işlem, süre, oran ve dönem bellidir.

Pazaryeri için kullanılabilecek örnek hedefler:

Bu rakamlar her işletme için doğrudan kopyalanmamalıdır. Trafik yoğunluğu, üçüncü taraf bağımlılıkları, ekip kapasitesi ve müşterinin beklentisi dikkate alınmalıdır. Ulaşılması imkânsız hedefler ekipleri sürekli alarm durumuna sokar; çok düşük hedefler ise gerçek sorunları gizler.

Hata bütçesiyle hız ve güvenilirliği dengeleyin

Yüzde 100 erişilebilirlik pratikte gerçekçi bir hedef değildir. Yüzde 99,9 erişilebilirlik bile ay boyunca sınırlı bir hata payı bırakır. Bu paya hata bütçesi denir. Hata bütçesi, ekiplerin yeni özellik geliştirme hızı ile hizmet güvenilirliği arasında bilinçli bir denge kurmasını sağlar.

Bir hizmetin aylık SLO'su yüzde 99,9 ise teorik olarak ayın yüzde 0,1'lik kısmı hedef dışında kalabilir. Ancak yalnızca toplam süreye bakmak yetersizdir. Ödeme servisinde on dakikalık kesinti ile düşük trafikli bir raporlama servisinde on dakikalık kesinti aynı ticari etkiye sahip değildir. Bu nedenle hata bütçesini işlem sayısı, gelir etkisi ve kritik saatler ile birlikte yorumlayın.

Hata bütçesi hızla tüketiliyorsa yeni özellik dağıtımlarını yavaşlatmak, riskli değişiklikler için ek test istemek veya kapasite çalışmasına öncelik vermek mantıklıdır. Bütçe korunuyorsa ekip kontrollü deneyler yapabilir. Böylece “geliştirme mi, istikrar mı?” tartışması kişisel görüşlerden çıkar ve ölçülebilir bir karara dönüşür.

Burada önemli bir ayrım vardır: İş ortağı veya ödeme kuruluşu kaynaklı sorunlar da müşterinin deneyimini etkiler. Sorumluluk sınırını sözleşmelerde açıkça tanımlayın; fakat izleme sisteminde bu hataları görünmez yapmayın. Kök neden dışarıda olsa bile kullanıcıya verilen hizmetin toplam başarısı ayrıca raporlanmalıdır.

Ölçüm mimarisi nasıl kurulmalı?

SLO'ların güvenilir olabilmesi için verinin tek bir kaynaktan değil, farklı katmanlardan toplanması gerekir. Dört ölçüm katmanı pazaryerlerinde genellikle yeterli bir başlangıç sağlar.

Gerçek kullanıcı ölçümü

Tarayıcı ve mobil uygulama üzerinden alınan veriler, kullanıcının gerçek deneyimini gösterir. Farklı şehirlerdeki ağ koşulları, cihazlar ve tarayıcılar hesaba katılır. Sadece sunucu yanıt süresine bakıp sayfanın kullanıcıya hızlı göründüğünü varsaymayın.

Sentetik testler

Önceden belirlenmiş senaryolar belirli aralıklarla otomatik çalıştırılır. Arama yapılır, ürün sayfası açılır, sepete ürün eklenir ve test ödeme akışı başlatılır. Gerçek trafik olmasa bile kritik yolun çalışıp çalışmadığı görülür.

Uygulama ve altyapı metrikleri

CPU, bellek, veritabanı bağlantıları, kuyruk uzunluğu ve hata oranı gibi teknik metrikler neden analizi için gereklidir. Bunlar tek başına müşteri deneyiminin ölçüsü değildir; iş metrikleriyle birlikte değerlendirilmelidir.

İşlem ve veri kalitesi metrikleri

Siparişin oluşması, stok değişikliğinin yayılması, komisyonun doğru hesaplanması ve bildirimin teslim edilmesi gibi iş olayları ayrıca izlenmelidir. Bir servis yeşil görünüp yanlış veri üretiyorsa kullanıcı açısından başarılı sayılmaz.

Metrikleri ortak bir olay kimliğiyle ilişkilendirmek faydalıdır. Örneğin sipariş kimliği, ödeme kimliği ve kargo kimliği arasındaki bağlantı korunursa sorun incelemesi saatler değil dakikalar sürer. Pazaryeri özellikleri sayfasında anlatılan modüler işlevleri değerlendirirken bu servisler arasındaki gözlemlenebilirlik ihtiyacını da planlamak gerekir.

Alarm tasarımında sık yapılan hatalar

Her metrikte küçük bir değişime alarm üretmek ekipleri kısa sürede alarma duyarsız hale getirir. Alarm, bir kişinin harekete geçmesini gerektiren durumlarda gönderilmelidir. Bilgi amaçlı kayıtlar ayrı kanallarda tutulabilir.

İyi bir alarmın üç özelliği vardır:

• Kullanıcıya veya gelire etkisi anlaşılırdır.
• Ekipten beklenen ilk adım bellidir.
• Yanlış alarm oranı kontrol altında tutulur.

Örneğin “CPU yüzde 80'i geçti” çoğu zaman doğrudan eylem söylemez. “Ödeme başarı oranı son 10 dakikada yüzde 98'in altına indi; yeni ödeme denemeleri etkileniyor” daha anlamlıdır. Uyarıyı hizmet, etki, zaman ve sorumlu ekip bilgisiyle birlikte tasarlayın.

Mesai dışı nöbet düzeni olan ekiplerde kritik ve kritik olmayan uyarılar ayrılmalıdır. Kritik bir ödeme kesintisi telefonla bildirilirken, düşük öncelikli arama gecikmesi çalışma saatlerinde incelenebilir. Nöbetçi kişiye yalnızca alarm göndermek yerine runbook bağlantısı, son dağıtım bilgisi ve ilgili dashboard'u da sunun.

Olay yönetimi ve geriye dönük inceleme

SLO raporu sorun çıktıktan sonra hazırlanan bir tablo olmamalıdır. Olay sırasında ekiplerin hangi sinyallere bakacağı, kimin iletişim kuracağı ve hangi karar yetkisinin kimde olduğu önceden belirlenmelidir.

Bir olay yönetimi akışı şu adımları içerebilir:

1. Olayı tek bir kayıt altında açın ve etkilenmiş hizmeti belirtin.
2. Etki alanını ölçün: kaç kullanıcı, satıcı veya sipariş etkileniyor?
3. Geçici çözümü uygulayın; örneğin riskli dağıtımı geri alın veya kuyruğu yavaşlatın.
4. İç ekipleri ve gerekiyorsa iş ortaklarını bilgilendirin.
5. Hizmet normale döndükten sonra veri kaybı ve yanlış sipariş kontrolü yapın.
6. Kök neden incelemesini suçlayıcı olmayan bir formatta tamamlayın.
7. Tekrarlanmayı önleyecek aksiyonlara sahip ve tarih verin.

Geriye dönük inceleme yalnızca “hangi sunucu bozuldu?” sorusuna odaklanmamalıdır. Alarm neden geç geldi, dokümantasyon yeterli miydi, satıcıya yanlış bilgi gitti mi, telafi süreci çalıştı mı gibi sorular da önemlidir. İyi bir postmortem yeni kontrol listeleri ve otomasyonlar doğurur.

Ticari SLA metninde neler bulunmalı?

Teknik hedeflerin ticari taahhüde dönüşmesi için kapsam dikkatle yazılmalıdır. Hangi hizmetlerin SLA kapsamında olduğu, bakım pencereleri, üçüncü taraf kesintileri, ölçüm yöntemi, bildirim kanalı ve telafi koşulları açık olmalıdır.

Satıcılara verilen SLA ile alıcılara gösterilen hizmet standardı aynı olmak zorunda değildir. Satıcı paneli için destek yanıt süresi ve veri aktarım süresi öne çıkarken, alıcı tarafında ödeme ve sipariş akışı daha kritik olabilir. Her iki taraf için de tanımların sade olması gerekir.

Bir SLA metninde hedefleri aşırı çoğaltmayın. Beş ila sekiz kritik hizmet için net taahhüt, onlarca belirsiz maddeden daha değerlidir. Ayrıca ölçemediğiniz bir hedefi sözleşmeye koymayın. Pazaryeri fiyatları gibi ticari sayfalarda maliyet ve paket bilgisi sunulurken, hizmet kapsamının yanında destek ve süre taahhütleri de anlaşılır biçimde açıklanmalıdır.

SLA ihlali halinde otomatik telafi her durumda doğru çözüm değildir. Küçük bir kesinti için hizmet kredisi, tekrarlayan ihlaller için iyileştirme planı veya kritik olaylar için yönetici incelemesi gibi kademeli modeller tasarlanabilir. Hukuk ve müşteri başarı ekipleri teknik ekiplerle birlikte çalışmalıdır.

İlk 30 gün için uygulanabilir plan

SLA ve SLO programını bir kerede bütün platforma yaymak yerine küçük bir kapsamla başlatın.

İlk hafta: Ödeme, arama ve sipariş oluşturma gibi üç kritik kullanıcı yolunu seçin. Her yolun sahibi olan ekipleri belirleyin. Mevcut erişilebilirlik, yanıt süresi ve hata oranı verilerini çıkarın.

İkinci hafta: SLI tanımlarını netleştirin. Başarı koşullarını ve ölçüm pencerelerini yazılı hale getirin. Veri eksikse önce ölçüm ekleyin; hedefi tahmin ederek belirlemeyin.

Üçüncü hafta: Gerçekçi SLO'lar oluşturun ve dashboard hazırlayın. Kritik alarmları tanımlayın. Her alarm için ilk müdahale adımını ve sorumlusunu yazın.

Dördüncü hafta: Bir olay tatbikatı yapın. Ödeme sağlayıcısının yavaşladığı, stok kuyruğunun biriktiği veya arama indeksinin geriden geldiği bir senaryoyu ekipçe deneyin. Sonuçlara göre hedefleri ve runbook'ları düzeltin.

Bu süreçte hedefler düşük görünse bile sorun değildir. İlk amaç kusursuz bir oran yakalamak değil, hizmetin gerçek durumunu görmek ve ortak bir dil kurmaktır. Zamanla geçmiş veriler biriktikçe SLO'lar daha doğru hale gelir.

Pazaryerinin büyümesi, yalnızca daha fazla ürün ve satıcı eklemekle ölçülmez. Siparişin her aşamasında öngörülebilir hizmet sunmak, güvenilir bir marka oluşturmanın temelidir. SLA ticari beklentiyi, SLO operasyonel hedefi, SLI ise gerçek durumu görünür kılar. Bu üç katmanı birlikte kurduğunuzda ekipler neyi koruduklarını, ne zaman müdahale edeceklerini ve iyileştirmenin nereden başlayacağını bilir. Bugün üç kritik akışı seçip ölçmeye başlamak, kusursuz bir sistem beklemekten daha değerlidir.

Sık Sorulan Sorular

S: Küçük bir pazaryerinin SLA ve SLO çalışmasına ihtiyacı var mı?

C: Evet. Kapsam küçük tutulabilir. Ödeme, sipariş ve satıcı paneli gibi üç kritik hizmet için basit hedefler belirlemek bile sorunların görünür olmasını sağlar. Ekip büyüdükçe kapsam genişletilebilir.

S: SLA ile yüzde 100 erişilebilirlik sözü verilebilir mi?

C: Teknik olarak yüzde 100 hedefi sürdürülebilir değildir. Bakım, üçüncü taraf sorunları ve beklenmeyen arızalar için hata payı gerekir. Daha gerçekçi bir hedef, ölçüm yöntemi ve telafi koşulu birlikte tanımlanmalıdır.

S: SLO hedefleri ne sıklıkla gözden geçirilmeli?

C: İlk dönemde aylık gözden geçirme uygundur. Sistem ve trafik olgunlaştığında üç aylık değerlendirme yapılabilir. Büyük mimari değişikliklerden veya ciddi bir olaydan sonra hedefler ayrıca incelenmelidir.

S: Üçüncü taraf ödeme veya kargo servisinin hatası SLA hesabına dahil edilir mi?

C: Bu konu sözleşmede açıkça yazılmalıdır. Sorumluluk üçüncü tarafta olsa bile son kullanıcı deneyimindeki toplam başarısızlığı izlemek gerekir. Teknik raporda dış bağımlılık ayrı bir neden olarak sınıflandırılabilir.

S: İlk ölçülmesi gereken pazaryeri metriği hangisidir?

C: İş etkisi en yüksek kritik kullanıcı yolunu seçin. Çoğu pazaryerinde ödeme ve sipariş oluşturma iyi bir başlangıçtır. Erişilebilirlik ile birlikte işlem başarı oranı ve yanıt süresini de ölçün.