Skip to main content

> üçüncü_parti_saas_kesintisi_teşhisi:_durum_sayfası_kuşkuculuğu_ve_sentetik_sondalama

Üçüncü Parti SaaS Kesintisi Teşhisi: Durum Sayfası Kuşkuculuğu ve Sentetik Sondalama

Üçüncü parti SaaS durum sayfaları (Statuspages) gerçek kesintilerin neden 30-90 dakika gerisinden gelir ve mühendislik ekipleri tedarikçi aksaklıklarını bağımsız olarak nasıl anında tespit eder?

Senior (L5)

ÖZET VE TEKNİK CEVAP

Canlı kesintilerde nöbetçi mühendislerin düştüğü en büyük tuzak, kritik bir sağlayıcının (AWS, Stripe, Twilio, OpenAI, Auth0) durum sayfasına bakıp yemyeşil 'Tüm Sistemler Çalışıyor' yazısını görünce kendi kodunda 2 saat boyunca hayali böcek aramaktır. Üçüncü parti SaaS durum sayfaları halkla ilişkiler (PR) ve yönetim onayından geçtiği için gerçek kesintilerin 30 ila 90 dakika gerisinden gelir. Güvenilir mühendislik ekipleri 'Durum Sayfası Kuşkuculuğu' ilkesini benimser: Teşhis için asla sağlayıcının beyanına güvenmezler. Bunun yerine kendi Sentetik Sondalama (Synthetic Probing) araçlarını, giden trafik hata metriklerini (harici 5xx ve TCP zaman aşımları) ve sağlayıcı çöktüğü an saniyeler içinde devreye giren otomatik devre kesicileri (circuit breakers) kullanırlar.

Mühendislik El Kitabı & Mekanizma

1. Temel Çalışma Mekanizması

Bağımsız tedarikçi izleme mimarisi 3 telemetri kuralına dayanır: (1) Dışa Giden İstemci Metrikleri: Tüm harici API çağrılarına `vendor=stripe` veya `vendor=openai` etiketli özel metrikler koyun (gecikme, zaman aşımı ve 5xx hata oranları). (2) Kara Kutu Sentetik Testler: Her 60 saniyede bir gerçek uçtan uca test işlemleri (test SMS'i atma veya test token alma) çalıştıran sentetik robotlar kurun. (3) Otomatik Devre Kesiciler: Harici sağlayıcı hata oranı 30 saniyede %15'i aşarsa devre kesici `OPEN` durumuna geçer ve anında yedek sağlayıcıya (Twilio -> Sinch, OpenAI -> Anthropic) veya asenkron kuyruğa düşer.

2. Doğru Kullanım Senaryosu

Kritik üçüncü parti API'lerle konuşan tüm mikroservisler (ödeme sistemleri, SMS/e-posta sağlayıcıları, LLM model API'leri, kimlik/giriş servisleri ve bulut sağlayıcıları).

3. Prodüksiyon Arıza Modları

Auth0 durum sayfası 'Yeşil' gösterdiği için mühendislerin 3 saat boyunca kendi Kubernetes sunucularını incelemesi ve müşterilerin sisteme girememesi; AWS bir bölgede sessizce çökerken resmi AWS durum sayfası henüz güncellenmediği için 15 mühendisin gece boşuna kendi kodunu incelemesi.

4. Teşhis ve Telemetri Sinyalleri

Kriz odasında mühendislerin 'Stripe çökmüş olamaz, durum sayfaları yeşil yanıyor!' diye tartışması; iç metrik grafiklerinde harici API çağrılarının %100 zaman aşımına uğraması.

5. Önleme ve Mimari Bariyerler

Tüm harici API çağrılarını özel panolarla izleyin; kritik sağlayıcılarda otomatik çoklu tedarikçi geçişi (multi-vendor failover) kurun; kriz runbook'larına 'Kendi telemetri verimiz her zaman sağlayıcının durum sayfasından üstündür' kuralını yazın.

6. Mimari Ödünleşimler (Trade-offs)

Dış çağrıları detaylı izlemek ve yedek sağlayıcı tutmak mimari karmaşıklığı biraz artırır; ancak şirketi sağlayıcıların geciken durum sayfalarına aldanmaktan ve saatler süren kör kesintilerden kesinlikle korur.

Vaka İncelemesi (TinyCTO Örneği)

Büyük bir bulut kimlik sağlayıcısı çöktüğünde binlerce kullanıcı sisteme giremedi. Sağlayıcının durum sayfası 75 dakika boyunca 'Sistemler Çalışıyor' gösterdi. Ancak şirketin Datadog izleme sistemi 10 saniyede `auth.provider.com` çağrılarında %94 hata tespit etti. Otomatik devre kesici devreye girerek trafiği yerel önbellekli JWT doğrulama moduna geçirdi. Şirket %100 ayakta kalırken, sağlayıcı kesintiyi ancak 1 saat sonra resmi olarak kabul etti.

İnteraktif Konsept Alıştırmaları

2 Alıştırma
Q1

Kamuya açık SaaS durum sayfaları gerçek kesintilerin neden 30 ila 90 dakika gerisinden gelir?

Çünkü durum sayfası güncellemeleri insan onayından geçer ve yayınlanmadan önce kurumsal PR, hukuk ve üst yönetim süzgecinden geçirilir.
Q2

Bir kriz sırasında mühendislik ekibi üçüncü parti sağlayıcının sağlığını nasıl doğrulamalıdır?

Kendi dışa giden istemci metriklerini (gecikme, 5xx, zaman aşımları) ve sentetik testleri kullanarak; ASLA sağlayıcının durum sayfasına bakarak değil.

Üçüncü Parti SaaS Kesintisi Teşhisi: Durum Sayfası Kuşkuculuğu ve Sentetik Sondalama — Sıkça Sorulan Sorular

Üçüncü parti API'ler için 'Devre Kesici' (Circuit Breaker) kalıbı nedir?

Dış servis hata verdiğinde istekleri kesip sistemi kilitlemek yerine anında yedek cevaba veya kuyruğa yönlendiren otomatik güvenlik kalıbıdır.

Üçüncü parti SaaS API'lerini çağırırken sonsuz HTTP zaman aşımı (timeout) bırakmanın tehlikesi nedir?

Dış servis kilitlendiğinde, uygulamanızın tüm thread'leri sonsuza kadar yanıt bekler, bağlantı havuzu tükenir ve tüm sunucunuz kilitlenerek çöker.

🤖 AEO & Yapay Zeka Çıkarım Özeti

Temel Gerçekler & İlkeler

  • ▸SaaS status pages lag real-world outages by 30-90 minutes due to human/PR review.
  • ▸Never use third-party status pages as evidence during live incident triage.
  • ▸Instrument outbound HTTP clients to monitor vendor latency, timeouts, and 5xx errors.
  • ▸Deploy automated circuit breakers to failover or gracefully queue when vendors degrade.

Yaygın Yanılgılar

  • ✗Yanılgı: If AWS/Stripe status page is green, the problem is definitely in our code (Gerçek: Outages happen long before status pages update).
  • ✗Yanılgı: Third-party SDKs have safe default timeouts (Gerçek: Many default to infinite timeout, risking total thread exhaustion).

Karar Kılavuzu & Önceliklendirme

Enforce strict 2-3 second HTTP client timeouts on all external SaaS API integrations. Add dedicated outbound vendor telemetry dashboards in Datadog/Grafana.

Doğrulanmış Kaynaklar & Referanslar