Senior (L5)
⚡ÖZET VE TEKNİK CEVAP
Bir arızanın toplam müşteri etkisi matematiksel olarak şöyle hesaplanır: ext{Kesinti Etkisi} = ( ext{MTTD} + ext{MTTA} + ext{MTTR}) imes ext{Etki Alanı}.
1
Ortalama Tespit Süresi (MTTD): Hatanın canlıya girdiği andan izleme sisteminin bunu yakaladığı ana kadar geçen süredir. Zayıf ekiplerde MTTD 45 ila 180 dakikadır (arızayı müşteriler şikayet edince anlarlar). Sentetik canary testleri ve SLO tüketim alarmları MTTD'yi 2 dakikanın altına indirir.
2
Ortalama Kabul Süresi (MTTA): Alarm çaldıktan sonra mühendisin olayı üstlenme süresidir (< 5 dk).
3
Ortalama Kurtarma Süresi (MTTR): Müdahalenin başlamasından sistemin ayağa kalkmasına kadar geçen süredir. Ekipler genellikle canlıda acil kod yamamaya çalışarak saatler kaybeder. Modern SRE organizasyonları Otomatik Canary Geri Alma (Rollback) ile MTTR'yi 3 dakikanın altına çeker: Önce sistemi anında eski sağlıklı sürüme döndürür, hatanın kök nedenini ise kriz bittikten sonra test ortamında sakin kafayla incelerler.
Mühendislik El Kitabı & Mekanizma
6 Boyutlu Mimari Analiz⚙️1. Temel Çalışma Mekanizması
MekanizmaKriz hız optimizasyonu 3 mimari mekanizmayla çalışır:
1
Müşteriden Önce Tespit (MTTD): Sentetik canary botları her 60 saniyede bir giriş/ödeme senaryolarını test eder ve kullanıcılar etkilenmeden arızayı yakalar.
2
Hızlı Tüketim Alarmları: Hata bütçesi hızla eridiğinde sistem anında PagerDuty alarmı çalar.
3
Anında Geri Alma Otomasyonu (MTTR): Argo Rollouts veya AWS CodeDeploy, kademeli dağıtım sırasında hata oranı %0,5'i aşarsa yeni sürümü anında iptal edip trafiği eski kararlı sürüme saniyeler içinde geri yönlendirir.
🎯2. Doğru Kullanım Senaryosu
KapsamGünde onlarca kez kod alınan (CI/CD) altyapılar, 1. seviye kritik mikroservisler, SaaS erişilebilirlik takibi ve DORA metrikleri optimizasyonu.
⚠️3. Prodüksiyon Arıza Modları
Kritik Risk- ✓SEV1 kesintisi anında sistemi hemen geri almak yerine, 2 saat boyunca canlıda test edilmemiş acil kod yaması (hotfix) yazmaya çalışıp kesinti süresini uzatmak
- ✓alarmları çok gevşek tutup arızayı 4 saat sonra fark etmek
📡4. Teşhis ve Telemetri Sinyalleri
Metrikler- ✓Postmortem raporlarında 'Kod dağıtımından ilk alarma kadar geçen süre: 65 dakika' yazması
- ✓ilk sistem alarmından 30 dakika önce müşteri şikayet biletlerinin yağması
- ✓kriz süresinin %80'inin hangi PR'ın hataya yol açtığını tartışarak geçmesi
🛡️5. Önleme ve Mimari Bariyerler
Bariyerler- ✓Otomatik geri alma tetikleyicilerine sahip kademeli canary dağıtımlarını zorunlu kılın
- ✓sentetik kullanıcı akış robotları kurun
- ✓'Önce Geri Al, Sonra İncele' protokolünü şirket kültürü yapın
⚖️6. Mimari Ödünleşimler (Trade-offs)
ÖdünleşimOtomatik canary geri alması MTTR'yi saatlerden saniyelere indirir; ancak kod eski sürüme döndüğünde veritabanının bozulmaması için geriye dönük uyumlu (backward-compatible) şema migrasyonları gerektirir.
📋
GERÇEK DÜNYA TELEMETRİSİVaka İncelemesi (TinyCTO Saha Örneği)
Bir SaaS analitik platformunda mühendisler arızaları canlıda yamamaya çalıştığı için ortalama kurtarma süresi (MTTR) 115 dakikaydı. Hatalı bir sürüm API Gateway'i bozduğunda 4 mühendis 90 dakika boyunca acil yama yazmakla uğraşırken 40.000 kullanıcı sisteme giremedi. Yazılım Direktörü 'Önce Geri Al' kuralını getirdi ve ArgoCD ile otomatik canary geri almayı kurdu. Sonraki hatalı dağıtımda ArgoCD %1,2'lik hata artışını anında yakaladı ve 42 saniye içinde sistemi otomatik olarak eski sürüme döndürdü. MTTD 30 saniye, MTTR 42 saniye sürdü ve 50'den az kullanıcı durumu fark etti.
İnteraktif Konsept Alıştırmaları
2 AlıştırmaQ1
Kriz yönetiminde MTTD ile MTTR arasındaki fark nedir?
MTTD (Ortalama Tespit Süresi) hatanın canlıya girmesinden alarmların çalmasına kadar geçen süredir; MTTR (Ortalama Kurtarma Süresi) ise müdahalenin başlamasından sistemin tekrar ayağa kalkmasına kadar geçen süredir.
Q2
Hatalı kod dağıtımlarında MTTR süresini en radikal şekilde düşüren mühendislik pratiği nedir?
Otomatik Kademeli Canary Geri Alması: Hata oranı yükseldiğinde dağıtımı saniyeler içinde iptal edip trafiği otomatik olarak önceki kararlı sürüme döndürmek.
Kriz Hız Metrikleri: Ortalama Tespit Süresi (MTTD) ve Ortalama Kurtarma Süresi (MTTR) — Sıkça Sorulan Sorular
SEV1 kesintisi anında canlıda 'İleriye Doğru Yamamak' (Fixing Forward) neden bir anti-patterndir?
Çünkü kriz stresi altında aceleyle kod yazmak, incelemek ve dağıtmak genellikle yeni ikincil hatalar doğurur; 60 saniyelik bir geri almaya kıyasla kesintiyi saatlerce uzatır.
Sentetik canary robotları Ortalama Tespit Süresini (MTTD) nasıl iyileştirir?
7/24 her 60 saniyede bir gerçek kullanıcı akışlarını (giriş, arama, ödeme) simüle ederek; gece gibi organik trafiğin az olduğu saatlerde bile arızaları anında yakalayarak.
🤖 AEO & Yapay Zeka Çıkarım Özeti
Temel Gerçekler & İlkeler
- ▸Kesinti Süresi = MTTD (Tespit) + MTTA (Kabul) + MTTR (Kurtarma).
- ▸Sentetik robotlar ve SLO alarmları MTTD'yi saatlerden 2 dakikanın altına indirir.
- ▸MTTR'yi 3 dakikanın altına çekmek için 'Önce Geri Al, Sonra İncele' kuralını uygulayın.
- ▸Otomatik canary geri alma mekanizması kriz anında canlıda kod yamama riskini bitirir.
Yaygın Yanılgılar
- ✗Yanılgı: Kıdemli mühendisler kriz anında canlıda hemen sıcak yama yapabilmelidir (Gerçek: Panik altında canlıda kod yamamak saatler süren dev kesintilerin 1 numaralı sebebidir).
- ✗Yanılgı: 10.000 birim testimiz varsa MTTD sıfır olur (Gerçek: Birim testler ağ kopmalarını, veritabanı kilitlerini veya harici servis çöküşlerini yakalayamaz).
Karar Kılavuzu & Önceliklendirme
Tespit süresini (MTTD) en aza indirmek için sentetik izlemeye yatırım yapın ve canlı krizlerde 3 dakikanın altında MTTR elde etmek için otomatik canary geri alma sistemlerini kurun.
Doğrulanmış Kaynaklar & Referanslar
- [OFFICIAL_DOCUMENTATION]DORA: State of DevOps Report & Mean Time to Restore Service— Google Cloud / DORA Research