Blog / Teknoloji / Röportajta Sorulacak 12 Kritik Soru: Lig Teknoloji Sağlayıcısı — Latency, Yedekleme, SLA ve Şeffaf Veri Politikaları
Röportajta Sorulacak 12 Kritik Soru: Lig Teknoloji Sağlayıcısı — Latency, Yedekleme, SLA ve Şeffaf Veri Politikaları
Teknoloji

Röportajta Sorulacak 12 Kritik Soru: Lig Teknoloji Sağlayıcısı — Latency, Yedekleme, SLA ve Şeffaf Veri Politikaları

Lig yönetimi, teknik ekip veya satınalma sorumlusuysanız, teknoloji sağlayıcısıyla yapacağınız röportaj başarı ve güvenilirlik açısından belirleyici olabilir. Bu yazıda sağlayıcıya yöneltebileceğiniz 12 kritik soruyu, her sorunun ardındaki mantığı, takip sorularını ve dikkat etmeniz gereken 'kırmızı bayrak' işaretlerini pratik örneklerle anlatıyorum.

Neden bu soruları sormalısınız?

Bir lig platformu sadece maç skorlarını yayınlayan bir yazılım değil; canlı skor, bahis entegrasyonu, yayın senkronizasyonu, oyuncu verileri, izleyici analitiği ve ödeme sistemleri gibi kritik bileşenleri barındırır. Bu yüzden latency, yedekleme, SLA, veri güvenliği ve şeffaflık stratejileri doğrudan operasyonel sürekliliğinizi etkiler.

12 Kritik Röportaj Sorusu ve Açıklamaları

  1. 1) Gerçekleştirdiğiniz uçtan uca latency ölçümleri nelerdir? (p50/p95/p99)

    Açıklama: Sadece ortalama latency değil, yüzde tabanlı (p95/p99) değerler kritik. Örneğin; canlı skor gösterimi için p95 < 100 ms, kritik işlem çağrıları için p99 < 300 ms gibi hedefler önemlidir.

    Takip soruları: Ölçümleri hangi coğrafi bölgeler için alıyorsunuz? Hangi yöntemle (synthetic transactions, gerçek kullanıcı telemetry)?

    Red flag: "Ortalama latency 200 ms" gibi belirsiz cevaplar; p99 verisi yoksa uyarı sinyali.

  2. 2) Trafik artışlarına karşı nasıl ölçekleniyorsunuz? (auto-scaling, CDN, edge)

    Açıklama: Ani kullanıcı patlamalarında statik içerik CDN, dinamik iş yükleri için otomatik yatay ölçekleme ve konum bazlı edge çözümleri gerekir.

    Örnek: Büyük final maçında 10 kat trafik bekleniyorsa, sağlayıcının load test sonuçları ve auto-scaling tetik eşikleri görmek istersiniz.

  3. 3) Yedekleme ve felaket kurtarma (DR) stratejiniz nedir? RTO/RPO değerleri nelerdir?

    Açıklama: RTO (Recovery Time Objective) ve RPO (Recovery Point Objective) somut SLA öğeleridir. Önerilen hedefler: RTO ≤ 30 dakika (kritik servisler), RPO ≤ 5 dakika (gerçek zamanlı veri gerektiren işlemler).

    Takip: Yedeklerden düzenli restore testleri yapıyor musunuz? Restore süresi ölçümleri paylaşılabilir mi?

    Red flag: Yedekleme sadece günlük snapshots, restore testleri yok.

  4. 4) SLA detayları: çalışma süresi (uptime), performans taahhütleri ve ceza mekanizmaları nelerdir?

    Açıklama: SLA sadece % uptime belirtmek değil; downtime tanımı, ölçüm penceresi, kredi/ceza hesaplaması ve bildirim süreçleri önemlidir. Tipik SLA örneği: %99.95 aylık uptime ve % üzerinden kredi tablosu.

    Takip: SLA ihlali durumunda tazminat süreci nasıl işliyor? Üçüncü taraf bağımlılıkları nasıl etkiliyor?

  5. 5) İzleme, uyarı ve telemetri: Hangi metrikleri gerçek zamanlı takip ediyorsunuz?

    Açıklama: Sağlayıcının uygulama performans izleme (APM), altyapı metrikleri, iş-kritik iş akışı göstergeleri ve synthetic transaction kontrolleri olmalı.

    Örnek metrikler: p95 latency, error rate, queue length, database replica lag, disk I/O.

  6. 6) Olay yönetimi: 24/7 destek, on-call rotasyonu ve eskalasyon matrisiniz nasıl çalışıyor?

    Açıklama: Bir kesinti anında kim devreye girer? İletişim kanalları, ilk yanıt süresi (ack) ve tam çözüm süresi (MTTR) beklenen ölçütlerdir.

    Hedef örneği: ilk yanıt ≤ 15 dakika, kritik olaylarda MTTR ≤ 2 saat.

  7. 7) Güvenlik ve uyumluluk: Hangi sertifikalara/denetimlere sahipsiniz? Penetrasyon testleri yapılıyor mu?

    Açıklama: ISO27001, SOC2 tipi sertifikalar, düzenli üçüncü taraf pentest raporları, ve CVE yönetimi gereklidir.

    Takip: Son pentest sonuçları paylaşılabilir mi? Kritik zafiyetler için SLA nedir?

  8. 8) Veri politikaları: Veri saklama, şifreleme, erişim kontrolü ve veri taşıma politikalarınız nelerdir?

    Açıklama: Veriler hem transit hem de at-rest şifrelenmeli (örn. TLS1.2+/AES-256). Veri erişimi ilkesi (least privilege), KMS ile anahtar yönetimi, ve erişim günlükleri (audit logs) kritik.

    Red flag: "Erişim kayıtları 30 gün saklanıyor" gibi kısa saklama veya anahtar yönetimi yoksa sorun olabilir.

  9. 9) Veri sahipliği ve şeffaflık: Kullanıcı verileri üzerinde hangi haklara sahipsiniz? Üçüncü taraf paylaşımı nasıl yönetiliyor?

    Açıklama: Sözleşmede verilerin kimin olduğuna, üçüncü taraf işleyicilere erişim şartlarına, veri silme/görme taleplerine ilişkin açık maddeler olmalı. GDPR/KVKK uyumluluğu örnek koşullardan biridir.

    Takip: Veri ihlali durumunda bilgilendirme süresi (örn. 72 saat) nedir?

  10. 10) Değişiklik yönetimi: Yayın penceleri, canary rollout, feature flags ve rollback süreçleri nelerdir?

    Açıklama: Üretime sık deploy yapan sağlayıcılar için kontrollü rollout (canary), otomatik rollback ve planlı bakım pencereleri beklenir.

    Örnek: Haftalık deploy var ama canlı maç yayın saatlerinde blokaj uygulanıyor mu?

  11. 11) API ve entegrasyon stabilitesi: Sürümleme, sözleşme değişiklikleri ve geriye dönük uyumluluk nasıl sağlanıyor?

    Açıklama: API sürüm politikasını, geriye dönük uyumluluk süresini ve breaking change bildirim süreçlerini öğrenin. Webhook/retry mantığı ve idempotency önemli detaylardır.

  12. 12) Test kültürü: Yük testleri, felaket senaryosu tatbikatları ve düzenli restore testleri yapıyor musunuz?

    Açıklama: Yedeklerin alınıyor olması yetmez; düzenli restore ve DR tatbikatları zorunludur. Ayrıca load test sonuçları gerçek trafik benzetimleriyle uyumlu olmalı.

Pratik İpuçları: Röportajda Nelere Dikkat Etmeli?

  • Somut veri isteyin: Sadece "yüksek performans" demek yeterli değil; p95/p99, RTO/RPO, MTTR değerleri gibi rakam isteyin.
  • Dokümantasyon talep edin: SLA dokümanı, DR planı, pentest raporu (özet), mimari diyagramları görmek isteyin.
  • Test etmeyi şart koşun: Anlaşmaya periyodik restore testi ve performans testi maddeleri koyun.
  • Rol bazlı örnekler: Eğer maç sırasında kontrol paneli yanıt vermezse, kimin hangi adımı atacağını önceden belirleyin.

Kırmızı Bayraklar (Red Flags)

"Sözleşmede açık metrik yok, sadece iyi niyet beyanları var."

Belirsiz yanıtlar, paylaşılmayan test raporları, sertifika eksikliği, yedeklerin restore edilmediği veya restore sürelerinin bilinmemesi ciddi uyarılardır.

Sonuç

Röportajlarınızda hedef, sadece teknik bilgi toplamak değil; sağlayıcının operasyonel olgunluğunu, şeffaflığını ve kriz yönetimi kapasitesini ölçmektir. Yukarıdaki 12 soru hem teknik hem sözleşmesel açıdan kapsamlı bir başlangıç sağlar. Her sorunun ardından somut kanıt (metrik, rapor, SLA maddesi) istemeyi unutmayın — iyi cevaplar rakamlara ve belgeye dayanır.

Hazırlıklı röportaj, riski düşürür; net SLA ve veri politikaları ise operasyonel güveni sağlar.