Skip to main content

> sre_operasyonel_standartları:_canlıya_çıkış_hazırlık_i̇ncelemesi_(prr)_ve_dağıtım_kapısı_denetimleri

SRE Operasyonel Standartları: Canlıya Çıkış Hazırlık İncelemesi (PRR) ve Dağıtım Kapısı Denetimleri

Canlıya yeni alınan mikroservisler ilk 30 günlerinde neden önlenebilir arızaların %80'ine yol açar; Google SRE'ın Canlıya Çıkış Hazırlık İncelemesi (PRR) işletilemeyen servisleri nasıl engeller?

Staff/Principal (L6+)

⚡ÖZET VE TEKNİK CEVAP

Yazılım takımları yeni bir mikroservisi alelacele canlıya aldığında, mesailerinin %100'ünü ürün özelliklerine, %0'ını ise operasyonel işletilebilirliğe ayırırlar. Yeni servis canlıya sağlık kontrolü (health check) olmadan, Prometheus metrikleri olmadan, koda gömülü veritabanı havuzlarıyla ve sıfır kılavuz dokümanıyla çıkar. 2 hafta içinde servis çöktüğünde nöbetçi mühendisin bunu nasıl düzelteceği veya yeniden başlatacağı konusunda hiçbir fikri yoktur. Google SRE bu problemi yok etmek için Canlıya Çıkış Hazırlık İncelemesini (Production Readiness Review - PRR) geliştirdi: Her yeni servisin gerçek müşteri trafiği almadan önce geçmek zorunda olduğu objektif bir kalite kapısıdır. PRR 8 Temel Operasyonel Sütunu denetler:
1
Gözlemlenebilirlik: SLI/SLO metrikleri, dağıtık izleme ve hazır paneller.
2
Acil Kurtarma: Otomatik acil durum kılavuzları, zarif kapanma (SIGTERM) ve devre kesiciler.
3
Kapasite ve Ölçeklenme: Yük testi sonuçları ve otomatik ölçekleme kuralları.
4
Güvenlik ve Uyumluluk: JIT erişimi, şifre yenileme ve güvenlik taramaları.

Mühendislik El Kitabı & Mekanizma

6 Boyutlu Mimari Analiz

⚙️1. Temel Çalışma Mekanizması

Mekanizma
PRR yönetişimi otomatik puanlama panelleri ve SRE ortaklığıyla yürütülür:
1
Otomatik Servis Kataloğu Puanlaması: Backstage veya Cortex aracı kod deposunu kurallara göre otomatik tarar ('Healthcheck var mı?', 'Prometheus metriği veriyor mu?', 'Kılavuz linki tanımlı mı?').
2
Erken PRR Tasarım Eşleşmesi: Canlıya çıkıştan bir gün önce değil, mimari tasarım aşamasında bir SRE mühendisi takımla eşleşip olası arıza modlarını belirler.
3
Canlı Öncesi Kontrol Denetimi: Takım harici bir servis çöktüğünde uygulamanın zarifçe ayakta kaldığını simülasyonla kanıtlar.
4
Operasyonel Devir: Servis Altın seviye PRR puanı aldığında SRE ekibi operasyonel nöbet ortaklığını imzalar.

🎯2. Doğru Kullanım Senaryosu

Kapsam
Yeni mikroservis dağıtımları, büyük mimari yeniden yazım projeleri, 1. Seviye kritik sistem taşımaları ve üçüncü parti entegrasyon çıkışları.

⚠️3. Prodüksiyon Arıza Modları

Kritik Risk
  • ✓
    PRR incelemesini pazarlama lansmanından 10 dakika önce üstünkörü doldurulan anlamsız bir formalite gibi görmek
  • ✓
    veritabanına giden çağrılarda zaman aşımı (timeout) veya hız limiti (rate limit) olmadan servisi canlıya salmak

📡4. Teşhis ve Telemetri Sinyalleri

Metrikler
  • ✓
    Canlıya yeni çıkan servislerin eksik ortam değişkenleri yüzünden 1. günde çökmesi
  • ✓
    nöbetçinin hiçbir panel veya kılavuzu olmayan meçhul bir servis için gece aranması
  • ✓
    takımların 'Metrikleri 2. Fazda ekleriz' bahanesine sığınması

🛡️5. Önleme ve Mimari Bariyerler

Bariyerler
  • ✓
    Backstage üzerinden PRR doğrulamalarını otomatikleştirin
  • ✓
    PRR temel şartlarını sağlamayan servislere canlı DNS yönlendirmesi yapılmasını teknik olarak engelleyin
  • ✓
    'Kılavuz Yoksa Canlı da Yok' kuralını tavizsiz uygulayın

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

Ödünleşim
PRR denetimleri yeni servis kaynaklı canlı arızalarının %80'ini yok eder ve gözlemlenebilirliği standartlaştırır; ancak geliştirme takımlarının proje süresinin %10-15'ini operasyonel hazırlığa ayırmasını gerektirir.
📋

Vaka İncelemesi (TinyCTO Saha Örneği)

GERÇEK DÜNYA TELEMETRİSİ
Bir bankacılık takımı yeni bir Yapay Zeka Dolandırıcılık Tespit mikroservisi geliştirdi. Canlı öncesi otomatik PRR denetiminde SRE ekibi 3 büyük açık yakaladı:
1
Ana bankacılık sistemine giden çağrılarda hiçbir zaman aşımı (timeout) yoktu,
2
40 adet pod'un her birinde veritabanı bağlantı havuzu 100 olarak bırakılmıştı (toplam 4.000 bağlantı açıp PostgreSQL'i anında çökertecekti), ve
3
/healthz sağlık kontrolü yoktu. PRR kapısı dağıtımı durdurdu. Takım havuz boyutunu düzeltti, devre kesici ekledi ve metrikleri bağladı. Servis 50.000 istek/sn canlı yük altına girdiğinde tek bir veritabanı arızası bile yaşanmadan kusursuz çalıştı.

İnteraktif Konsept Alıştırmaları

2 Alıştırma
Q1

Google Site Reliability Engineering (SRE) disiplininde Canlıya Çıkış Hazırlık İncelemesi (PRR) nedir?

Bir yazılım servisinin canlı kullanıcı trafiği almasına izin verilmeden önce gözlemlenebilirlik, acil durum kurtarma, kapasite ve güvenlik gibi temel operasyonel standartları karşılayıp karşılamadığını denetleyen yapılandırılmış objektif bir değerlendirmedir.
Q2

Bir proje yaşam döngüsünde PRR süreci ne zaman başlamalıdır?

Canlıya çıkıştan bir gün önce değil, henüz ilk mimari tasarım aşamasında başlamalıdır; böylece operasyonel gereksinimler yazılımın temeline en baştan entegre edilir.

SRE Operasyonel Standartları: Canlıya Çıkış Hazırlık İncelemesi (PRR) ve Dağıtım Kapısı Denetimleri — Sıkça Sorulan Sorular

Bir PRR denetiminde kabul edilebilir bir acil durum kılavuzunun (runbook) temel unsurları nelerdir?

Servis mimari şeması, olası alarm durumlarında izlenecek adım adım terminal komutları, geri alma (rollback) adımları ve kriz anında aranacak sorumlu kişilerin iletişim bilgileri.

Mühendislik organizasyonları PRR puanlama tablolarını büyük ölçekte nasıl otomatikleştirebilir?

Spotify Backstage veya Cortex gibi geliştirici portalları kullanarak; kod depolarını ve CI/CD hatlarını zorunlu sağlık kontrolleri, metrikler ve dokümantasyon için programatik olarak tarayarak.

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

Temel Gerçekler & İlkeler

  • ▸
    PRR denetimleri servislerin canlı trafik almadan önce operasyonel standartları sağlamasını garanti eder.
  • ▸
    8 Temel Sütunu denetleyin: Gözlemlenebilirlik, Acil Kurtarma, Ölçeklenme ve Güvenlik.
  • ▸
    PRR çalışmalarını lansmandan bir gece önce değil, ilk sistem tasarımı aşamasında başlatın.
  • ▸
    Hazırlık puan tablolarını Spotify Backstage veya Cortex servis kataloglarıyla otomatikleştirin.

Yaygın Yanılgılar

  • ✗
    Yanılgı: PRR ürün çıkışlarını yavaşlatan bürokratik bir engeldir (Gerçek: PRR yol haritasını haftalarca felç eden ilk gün arızalarını önleyerek uzun vadede hızı artırır).
  • ✗
    Yanılgı: Canlıya şimdi çıkalım, metrikleri ve kılavuzları 2. Fazda ekleriz (Gerçek: 2. Faz asla gelmez; izlenmeyen servisler kaçınılmaz olarak canlıyı çökertir).

Karar Kılavuzu & Önceliklendirme

İşletilemeyen eksik mikroservisleri engellemek ve canlıya çıkışta operasyonel mükemmelliği garanti altına almak için Backstage entegrasyonlu Canlıya Çıkış Hazırlık İncelemelerini (PRR) uygulayın.

Doğrulanmış Kaynaklar & Referanslar