“Üretim çöktü” mesajının geldiği gece yarısı, hangi şirketin gerçekten incident response disiplininde olduğunu ortaya çıkarır. PagerDuty’nin 2026 State of Digital Operations raporuna göre olgun bir incident response programına sahip şirketler ortalama MTTR’i (Mean Time to Resolve) 240 dakikadan 32 dakikaya indirebiliyor — bu fark milyonlarca dolar gelir kaybı demek. Türkiye’de incident response olgunluk düzeyi ortalama olarak seviye 2 (5 seviyeli skalada) — yani çoğu organizasyon hâlâ ad-hoc, yorgun on-call ekiplere bağımlı. Aynı zamanda BDDK Bilgi Sistemleri Yönetmeliği madde 30 ve KVKK 72 saat ihlal bildirim süresi, incident response sürecini regülatör tarafından da denetlenen bir alana taşıdı.

Bu rehberde modern incident response pratiğini, on-call rotasyonunu, postmortem disiplinini ve araç stack’ini somut sayılarla aktarıyoruz. Hedef kitle: SRE liderleri, mühendislik müdürleri, on-call yorgunluğunu azaltmak isteyen ekipler ve compliance audit’ine hazırlanan IT direktörleri.

Incident Severity (SEV) Sınıflandırma

SEVTanımYanıt
SEV1Tüm müşterileri etkileyen toplam outage< 15 dk, war room
SEV2Geniş kullanıcı etkisi, parçalı outage< 30 dk, dedicated channel
SEV3Sınırlı kullanıcı, workaround var< 4 saat, business hours
SEV4Düşük etki, low priority< 1 iş günü

On-Call Rotation

  • Primary on-call: İlk yanıt veren, 1 hafta nöbet.
  • Secondary: Primary cevap vermezse devreye girer.
  • Manager on-call: SEV1’lerde devreye, escalation.
  • Follow-the-sun: TR + EU + US ekipleri.
  • Burnout önleme: max 2 page/gece, sonraki gün izin.
  • On-call compensation: nakit ödeme veya zaman izni (yasal/etik tartışma yıllık review’da).
Incident response dashboard, SEV durum ve MTTR metrikleri
Incident response dashboard, SEV durum ve MTTR metrikleri

Yanıt Akışı

  1. Detect: Alarm (PagerDuty, Opsgenie) → primary’e gider.
  2. Acknowledge: < 5 dk içinde “alındı”.
  3. Triage: SEV belirleme, ekip toplama.
  4. Communicate: Status page güncellenir, Slack #incidents.
  5. Investigate: Logs, metrics, traces — incident commander koordine eder.
  6. Mitigate: Acil çözüm (rollback, feature flag off, scale).
  7. Resolve: Servis normale döner.
  8. Postmortem: 1-3 gün içinde blameless dokuman.

Roller

  • Incident Commander (IC): Karar verir, koordine eder. Teknik çözüm yapmaz.
  • Communications Lead: Status page + müşteri iletişim.
  • Subject Matter Experts (SME): Teknik çözüm yapar.
  • Scribe: Tüm aksiyonları timeline’a yazar.
  • Customer Liaison: Anahtar müşterilere doğrudan dönüş (Enterprise SaaS için).
Incident response akis diyagrami, detect to postmortem stages
Incident response akis diyagrami, detect to postmortem stages

Araç Stack

  • Alerting: PagerDuty, Opsgenie, Squadcast.
  • Communication: Slack + dedicated incident channel.
  • Observability: Grafana, Datadog, New Relic, Honeycomb.
  • Status page: Statuspage.io, Better Stack, instatus.
  • Runbook: Notion, Confluence, Backstage.
  • Postmortem: Jeli, Blameless, Notion template.
  • ChatOps automation: Slack bot ile kanal otomatik oluşturma, IC atama, scribe başlatma.

Blameless Postmortem

  • “Kim hata yaptı” değil “Sistem nasıl hata yapmaya izin verdi”.
  • Timeline: ne oldu, ne zaman, kim yaptı.
  • Root cause analysis: 5 Whys, Ishikawa.
  • Action items: tekrarlanmasını önleyecek somut adımlar.
  • Public paylaşım (kurum içi) → öğrenme kültürü.
  • Action item completion oranı %80+ — yoksa kültür retoriği boştur.

Blameless postmortem disiplini DevSecOps shift-left kültürü ile beraber çalışır — güvenlik incident’leri de aynı şablonu kullanır.

SRE ekibi war room incident yanit toplantisi
SRE ekibi war room incident yanit toplantisi

Metrik’ler

  • MTTD (Mean Time to Detect): Alarm gelene kadar.
  • MTTA (Mean Time to Acknowledge): Yanıt verene kadar.
  • MTTR (Mean Time to Resolve): Çözüm.
  • MTBF (Mean Time Between Failures): Aralık.
  • Incident rate: Aylık SEV1/SEV2 sayısı.
  • On-call load: Hafta başına page sayısı.
  • Postmortem action item completion rate: Tamamlanan / toplam.

SLO ve Error Budget

  • Servis için SLO (örn. %99,9 uptime).
  • Error budget = %0,1 (yılda 8,76 saat allowed downtime).
  • Budget tüketildiğinde feature freeze, reliability work önceliği.
  • Error budget remaining metric’i dashboard’da görünür olmalı.
  • SLO seçimi: kullanıcı deneyimine bağlı (latency p99, success rate), iç metrik değil.

Güvenlik Incident’leri Özel Akışı

Güvenlik incident’leri klasik availability incident’lerinden farklı bir disiplin gerektirir:

  • Forensics önce, fix sonra: Saldırgan hâlâ içerideyse fix saldırganı uyarır — önce log/artifact topla.
  • Legal hold: KVKK ihlal bildirimi 72 saat → Hukuk + Uyum erken devreye girer.
  • Customer notification: SOC 2 ve GDPR/KVKK gereği etkilenen kişilere bildirim.
  • USOM/CERT bildirim: Kritik altyapı sektörlerinde zorunlu.
  • Public disclosure timing: Bug bounty ile gelen ifşa varsa koordineli açıklama — bkz. bug bounty rehberimiz.

Türkiye Sektörel Pratik

  • Bankacılık: BDDK Bilgi Sistemleri Yönetmeliği madde 30 — incident bildirim 24 saat, kök neden raporu 30 gün.
  • E-ticaret: Ödeme kesintisi → MTTR 15 dk hedef, PagerDuty + Statuspage.io standart.
  • Fintech: Karma stack — Grafana + PagerDuty + Slack ChatOps bot.
  • Kamu/SGK/Sağlık: Yerel SOC + on-prem alert sistemleri; Statuspage genelde internal.
  • SaaS B2B: Public status page artık satış pre-req, müşteriler abone oluyor.

Sık Sorulan Sorular

Küçük ekipte on-call nasıl olmalı?

5 kişiden az ise rotasyon zor. Hibrit: birkaç senior + manager. Yıllık 10K-30K USD outsourced SOC opsiyonu.

AI tabanlı incident yönetimi var mı?

PagerDuty AIOps, Datadog Watchdog, Jeli AI postmortem — log/metric’ten anomaly + suggested action. 2026’da hızla yayılıyor.

Postmortem zorunlu mu?

SEV1 + SEV2 her zaman. SEV3 önemli pattern varsa. Sayısal hedef: SEV2+ için 100% postmortem oranı.

Status page açık mı yoksa private mı?

SaaS B2B için public şart (müşteri güveni). Internal sistem için private. Hibrit: public + internal detaylı sayfa.

On-call yorgunluğu nasıl yönetilir?

Haftalık page/kişi metriği 2-3’ün altında olmalı. Aşıldığında alarm tuning + on-call rotation büyütme şart. Gece 0-6 arası page sonrası 1 gün izin, sürekli pager bekleyen mühendise %10-15 ek ödeme yaygın. Google SRE Book’un belirttiği gibi “on-call yorgunluğu” sessiz bir productivity katili.

Ömer Önal’dan pratik not: Türkiye’de incident response programı kurulumuna danışmanlık verdiğim e-ticaret ve fintech projelerinde gözlemlediğim en kritik fark, “MTTR’i düşürelim” demekle yetinip postmortem action item completion oranını ölçmemek. SEV1 sonrası güzel bir doküman yazılıyor, 5-7 action item çıkıyor — 3 ay sonra dönüp baktığında %20’si tamamlanmış. Aynı incident 6 ay sonra tekrar oluyor. Doğru disiplin: postmortem action item’ları sprint’lere düşmeli, completion oranı dashboard’da görünür olmalı, %80’in altına düşerse “feature freeze” tetiklenmeli. Bir diğer kritik nokta: incident commander rolünü engineering manager veya senior IC’nin sırtına yıkmamak — incident commander rotasyonu olmalı, 3-5 senior eğitilmeli; tek IC ile %100 SEV1 ekibin %5’ini boğar. Güvenlik incident’lerinde “fix before forensics” anti-pattern’i Türk ekiplerde çok yaygın, oysa saldırgan hâlâ içerideyken erken fix saldırganı uyarır. Sizin ekibinizde son 6 ayda yapılan postmortem’lerin action item completion oranı nedir — %50’nin altında mı?

Sonuç

Incident response, modern operasyonel mükemmelliğin en önemli pratiklerinden biri. Doğru tasarlanmış bir program (PagerDuty + Slack + blameless postmortem + SLO/error budget) MTTR’i %87 azaltır, müşteri güvenini korur, ekip burnout’unu önler. Disiplini backup ve DR, threat modeling, bug bounty programları ve PAM JIT access içeriklerimizle bütünleştirin. İletişim formundan projeniz için incident response danışmanlığı talep edebilirsiniz.

Dış otorite kaynaklar: PagerDuty Incident Response · Google SRE Book · Atlassian Incident Handbook · NIST SP 800-61

Ömer ÖNAL

Yazılım Mimarı | Yapay Zeka LLC. Ölçeklenebilir SaaS, .NET Core altyapıları ve Otonom AI süreçleri inşa ediyorum. Kod değil, sistem tasarlarım.

Yorum (1)

  1. Ömer ÖNAL
    Mayıs 17, 2026

    Türkiye’de incident response programı kurulumuna danışmanlık verdiğim e-ticaret ve fintech projelerinde en kritik fark, “MTTR’i düşürelim” demekle yetinip postmortem action item completion oranını ölçmemek. SEV1 sonrası güzel bir doküman yazılıyor, 5-7 action item çıkıyor — 3 ay sonra %20’si tamamlanmış oluyor; aynı incident 6 ay sonra tekrar geliyor. Doğru disiplin: action item’lar sprint backlog’una düşmeli, completion oranı dashboard’da görünür olmalı, %80’in altına düşerse feature freeze tetiklenmeli. Bir diğer kritik nokta: incident commander rolünü tek engineering manager’a yıkmamak — IC rotasyonu olmalı, 3-5 senior eğitilmeli; tek IC ile %100 SEV1 ekibin %5’ini boğar. Güvenlik incident’lerinde “fix before forensics” anti-pattern’i Türk ekiplerde yaygın, oysa saldırgan hâlâ içerideyken erken fix saldırganı uyarır — önce log/artifact toplamak şart. BDDK Bilgi Sistemleri Yönetmeliği madde 30 bankacılık için 24 saat bildirim, KVKK 72 saat ihlal bildirimi süreyi sıkıştırıyor; Hukuk + Uyum erken devreye girmeli. Sizin ekibinizde son 6 ayda yapılan postmortem’lerin action item completion oranı nedir — yüzde olarak ölçüyor musunuz?

Yorum Yap

E-posta adresiniz yayınlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir