1. GİRİŞ

Incident Management (Olay Yönetimi), üretim ortamlarında beklenmeyen olayların tespiti, sınıflandırılması, müdahalesi, çözümü ve sonrasında öğrenilmesi süreçlerini kapsar. Bulut‑native uygulamalar, mikroservisler, global dağıtımlar ve sürekli dağıtım (CI/CD) uygulamalarının yaygınlaşmasıyla birlikte servis güvenilirliği ve operasyonel olgunluk doğrudan iş başarısına etki eder. Bu nedenle incident yönetimi artık yalnızca operasyon ekibinin görevi değil; SRE, platform mühendisliği, güvenlik ve geliştirme ekiplerinin ortak sorumluluğudur.

Neden bugün önemli?

• Hizmet kesintileri (downtime) doğrudan gelir, kullanıcı güveni ve yasal uyumluluk üzerinde etkili olabilir.
• SLA/SLO hedeflerinin işletilmesi, incident’ların etkisinin ölçülmesini ve önceliklendirmesini gerektirir.
• Dağıtık sistemlerin karmaşıklığı, hızlı ve doğru RCA (root cause analysis) ihtiyacını artırır.

Kimler için önemli?

• SRE ve platform mühendisleri — MTTR azaltma, otomasyon ve runbook tasarımı için.
• Geliştiriciler — production hata senaryolarını anlamak ve daha dayanıklı kod üretmek için.
• Teknoloji yöneticileri ve CTO'lar — servis sürdürülebilirliği ve iş sürekliliği için.

Hangi problemleri çözüyor?

• Olay tespitini hızlandırma (observability + alerting).
• Yanlış alarmları azaltma ve on‑call burnout'unu önleme.
• Root cause'ı belirleme ve kalıcı düzeltmeler ile tekrar eden olayları engelleme.

2. KAVRAMSAL TEMELLER

2.1 Temel tanımlar

• Incident: Born-out of unexpected behavior that causes service degradation or outage, impacting SLOs or user experience.
• MTTR (Mean Time To Repair/Restore): Olayın tespitinden tamamen çözülene kadar geçen ortalama süre. MTTR, operasyonun performans metriğidir.
• MTTD / MTTD (Mean Time To Detect): Sorunun tespit edilme süresi.
• Runbook: Belirli bir tipteki incident için adım adım müdahale prosedürü; otomasyonla birlikte çalışır.
• Postmortem / Incident Report: Olay sonrası analiz dokümanı; root cause, timeline, remediation ve lessons learned içerir.
• Paging / On‑call rota: Sıradaki müdahale sorumlusunun (pager) çağrılması ve iletişim süreci.

2.2 Incident lifecycle (yaşam döngüsü)

1. Detection: Telemetri/alerting sistemleri olayı yakalar.
2. Response & Triage: Olay kategorize edilir, kritikliği (severity) belirlenir ve doğru ekip çağrılır.
3. Mitigation: Kullanıcı etkisini azaltacak geçici veya kalıcı müdahale yapılır.
4. Resolution: Sorunun kök nedenine yönelik fix uygulanır.
5. Postmortem: Olay belgelenir, root cause analysis yapılır ve önleyici faaliyet planlanır.

2.3 Terminoloji ve roller

• Incident commander: Müdahale sürecini yöneten, iletişimi ve kararları koordine eden kişi.
• Scribe / Note taker: Olay sırasında timeline ve alınan aksiyonları kaydeden kişi.
• Subject Matter Expert (SME): Olayın teknik detaylarında uzman olan kişi veya ekip.
• Communications lead: İç/dış paydaşlarla (müşteriler, yönetim) iletişim sağlayan kişi.

3. NASIL ÇALIŞIR? — TEKNİK MİMARİ VE VERİ AKIŞI

3.1 Observability & Alerting katmanı

Incident yönetimi için gözlemlenebilirlik (metrics, traces, logs) temel taşıdır. İyi tanımlanmış SLO'lar ve ilgili SLI'lar üzerinden kurgulanan monitoring, anormallikleri otomatik tespit eder. Alerting pipeline şu adımlardan geçer:

• Metric collection (Prometheus/OTel)
• Alert evaluation (PromQL/Alerting engine)
• Notification routing (Alertmanager, Opsgenie, PagerDuty)
• On‑call paging ve incident oluşturma

3.2 On‑call ve paging workflow

On‑call süreçleri, iyi tasarlanmış rota (rotation), eskalasyon politikası ve runbook'larla desteklenmelidir. İyi bir paging workflow şu özelliklere sahiptir:

• On‑call kişisinin reachable ve yetkin olması
• Escalation policy: belirli süre içinde cevap alınamazsa bir üst seviyeyle devam
• Silencing & deduplication: tekrarlayan veya bilinen false positive'lerin susturulması
• Alert enrichment: alert'e trace id, recent deploy, owner contact gibi bağlam eklenmesi

3.3 Incident coordination platformları

Modern incident platformları (PagerDuty, Opsgenie, VictorOps, xMatters) paging, escalation ve incident timeline yönetimini sağlar. Ayrıca otomasyon playbook'ları tetikleyip runbook adımlarını uygulayarak müdahaleyi hızlandırırlar. Bu platformlar aynı zamanda postmortem verisini ve incident metriklerini toplayıp raporlamada kullanılabilir.

3.4 Runbook ve otomasyon

Kısa sürede tekrarlanabilir müdahale adımları runbook olarak hazırlanmalı ve mümkünse otomatikleştirilmelidir (chatops, automation scripts, remediation lambdas). Otomasyonun faydaları:

• MTTR'yi düşürür — insan adımlarını azaltır
• Tutarlı müdahale — prosedürler her seferinde aynı uygulanır

3.5 Communication & incident status

İç ve dış iletişim (status pages, incident reports) şeffaf, doğru ve zamanlı olmalıdır. Status page (e.g., status.example.com) aracılığıyla müşterilere olayın kapsamı ve ETA hakkında güncelleme sağlanır. İçeride ise communications lead düzenli aralıklarla durumu bildirir ve stakeholder'ları bilgilendirir.

4. GERÇEK DÜNYA KULLANIMLARI

4.1 Netflix — Incident playbooks ve chaos engineering

Netflix, incident yönetimi için playbook'lar, otomasyon ve kaos mühendisliği uygulamaları ile bilinir. Kaos testleri ile sistemin zayıf noktaları önceden tespit edilir; playbook'lar sayesinde operasyon ekipleri bilindik senaryolara hızlı müdahale edebilir.

4.2 Uber — Event-driven alerting ve ops tooling

Uber gibi yüksek trafikli firmalar, olayları gerçek kullanıcının etkisine göre önceliklendirir. Business‑impact odaklı alerting ve otomatik mitigasyon (feature flag rollback, traffic routing) sık kullanılır.

4.3 Stripe / Fintech — Compliance ve forensic readiness

Finansal servislerde incident yönetimi hem operasyon hem de regülasyon açısından kritik. Immutable audit logs, timeline ve müşteri bildirim süreçleri iyi tanımlanmıştır. Ayrıca security incident yönetimi (SIEM + IR playbook) ile ortak çalışılır.

4.4 Startuplar — lightweight, but disciplined approach

Küçük ekipler için lightweight on‑call süreçleri, basic runbook'lar ve status page yeterli olabilir. Ancak discipline (postmortem, root cause takibi) erken dönemde kurulmalıdır; büyüdükçe otomasyon ve tooling yatırımı yapılmalıdır.

5. AVANTAJLAR VE SINIRLAMALAR

Avantajlar

• Daha kısa MTTR ve artan kullanıcı memnuniyeti.
• Kod ve altyapı kalitesinde iyileşme — postmortem'lerden öğrenme.
• SLO/SLI tabanlı önceliklendirme ile operasyonel kaynakların verimli kullanımı.

Sınırlamalar

• On‑call süreçleri yanlış yönetilirse ekip yorgunluğu (burnout) artar.
• Yanlış yapılandırılmış alerting yüksek noise üretir ve gerçek problemleri gizleyebilir.
• Incident yönetimi kültürü olmadan tooling tek başına etkili olmaz.

6. ALTERNATİFLER VE KARŞILAŞTIRMA

7. EN İYİ PRATİKLER

Production kullanım

• SLO‑first yaklaşımı: incident önceliğini SLO ihlaline göre belirleyin.
• Runbook & automation: sık görülen olaylar için otomatik playbook'lar oluşturun.
• Incident commander modelini uygulayın; net rol ve sorumluluk tanımları olsun.

Performans optimizasyonu

• Alert enrichment ile müdahale sürecini hızlandırın (deploy metadata, trace id, owner).
• Deduplication ve grouping ile noise azaltın; probabilistic alert suppression teknikleri uygulayın.

Güvenlik

• Incident tooling için RBAC ve auditing zorunlu olmalı.
• Otomasyon adımlarını güvenlik testlerinden geçirin; roll‑back mekanizmalarını önceden planlayın.

Ölçeklenebilirlik ve kültür

• Postmortem'leri blameless yapın; öğrenmeyi teşvik edin ve takip edilebilir remediation planları oluşturun.
• Incident metriklerini takip edin: MTTD, MTTR, incident frequency, pain index ve action completion rate.

8. SIK YAPILAN HATALAR

• Alerts'ı ham metriğe bağlamak: İş etkisi yerine teknik eşiklerle alarm üretmek.
• On‑call rotasını rastgele veya adil olmayan şekilde planlamak — tükenmişlik yaratır.
• Postmortem yapmamak veya yüzeysel yapmak — aynı hatalar tekrarlanır.
• Runbook'ları güncel tutmamak — uygulamalar ve altyapı değiştikçe runbook geçersiz hale gelir.

9. GELECEK TRENDLER

1. AI‑assisted incident response: Otomatik RCA, öneri destekli playbooklar ve önceliklendirme için ML modelleri kullanılacak.
2. Autonomous remediation: İnsan müdahalesini azaltan güvenli otomatik rollback ve self‑healing akışları yaygınlaşacak.
3. Observability‑driven ops: Telemetri ile tetiklenen otomasyon ve policy as code ile incident yönetimi daha proaktif hale gelecek.
4. Blameless & continuous learning culture: Organizasyonel öğrenme modelleri olgunlaşıp incident veri tabanları bilgi kaynaklarına dönüşecek.

EK BÖLÜMLER

Sık Sorulan Sorular (FAQ)

1. 1. Incident Management'e nereden başlamalıyım?

   Öncelikle SLO'larınızı ve kritik SLI'ları tanımlayın, basit runbook'lar oluşturun ve bir on‑call rotası kurun. Ardından observability ve alerting pipeline'ınızı SLO odaklı hale getirin.

2. 2. On‑call ekibinin tükenmesini nasıl önlerim?

   Adil rota planlaması, hızlı feedback, yeterli otomasyon, shadow on‑call uygulamaları ve blameless postmortem kültürü ile on‑call yükünü azaltın.

3. 3. Postmortem nasıl olmalı?

   Neden‑sonuç ilişkisi, timeline, root cause, action items ve owner'ları içermeli; blameless, yapıcı ve ölçülebilir olmalıdır.

4. 4. Hangi metrikler takip edilmeli?

   MTTD, MTTR, incident frequency, customer‑impacting incidents, error budget consumption ve action completion rate gibi metrikler önceliklidir.

5. 5. Otomatik remediation güvenli midir?

   Otomatik remediation faydalıdır ancak guardrails, canary releases ve rollback planları ile desteklenmelidir. Otomasyonun etkisi test edilmiş ve izlenebilir olmalıdır.

6. 6. Incident command structure nedir?

   Incident commander (yarı zamanlı), scribe, SME'lar ve communications lead gibi rolleri belirleyen yapı; karar almayı ve iletişimi netleştirir.

7. 7. Status page kullanmalı mıyım?

   Evet. Müşterilere dış iletişim için status page kullanımı şeffaflık sağlar ve destek trafiğini azaltır.

8. 8. Incident verilerini nasıl yönetmeliyim?

   Incident verilerini merkezi bir repository'de (incidents database) tutun; postmortem'leri, remediation takibini ve metrikleri ilişkilendirin.

Anahtar Kavramlar

Incident Commander

Müdahale sürecini yöneten ve koordinasyonu sağlayan kişi.

Runbook

Olay tipi için adım adım müdahale prosedürü; otomasyonla bağlanabilir.

Postmortem

Olay sonrası yazılı analiz; root cause, timeline ve action item'lar içerir.

MTTR / MTTD

Olay tespit ve çözüm süreleri için ölçümler; operasyonel performans göstergeleri.

SLO / SLI

Incident önceliklendirmesi ve impact değerlendirmesi için kullanılan hedefler ve göstergeler.

Öğrenme Yol Haritası

1. 0–1 ay: Temel observability (metrics, logs, traces), alerting ve SLO kavramlarını öğrenin; küçük bir uygulama için basic alert kurun.
2. 1–3 ay: Runbook oluşturma, on‑call rotası kurma ve basit automation (chatops, scripts) uygulamaları deneyin; postmortem süreçlerini uygulamaya koyun.
3. 3–6 ay: Incident orchestration tooling (PagerDuty/Opsgenie), alert enrichment, escalation ve deduplication stratejileri üzerinde çalışın; MTTD/MTTR metriklerini toplayın ve raporlayın.
4. 6–12 ay: Automated remediation, chaos engineering, AI‑assisted RCA ve enterprise seviyede incident management platformları ile çalışın; kültürel dönüşüm ve süreç olgunlaşmasını sağlayın.