Olay Müdahale En İyi Uygulamaları : Solo Dev Rehberi

Olay Müdahale En İyi Uygulamaları : Solo Dev İçin Pratik Rehber

Olay müdahale en iyi uygulamaları daima kurumsal ekipler için yazılır. Solo geliştirici değilsiniz. Bir yan projeyi yayınlarsınız, kullanıcılar bulur, ve bir sabah biri tweet atar: üç saattir down. Kimse seni uyarmadı. Alarm yok. Runbook yok. Status page yok.

Sen habersiz kalıp, ne yapacağını bilmiyorsun, ve kullanıcılar sen fark etmeden öğrendi. Hızlı kurulmuş birçok ürün için bu gerçek başarısızlık modu budur : ihlal değil, altyapı çöküşü değil. Sadece: koordinasyon kaos, uyarı sistemi hiç kurulu değil, acil durum prosedürü yazılı yok.

Buna 40 sayfalık playbook ya da PagerDuty, Opsgenie gibi kurumsal araç yığını gerekmiyor. Üç şey yeterli: bir şey ne zaman kırıldığını öğren, hızlı çözmek için bir plan yaz, ve durumu kullanıcılarına söyle. Bu rehber her birini solo yapıcı açısından kapsar : kendine inşa edeceğin ve existing araçlarla nasıl tele bağlayacağın dahil.

Solo ve On-Call Olduğunda İlk Kıran Ne?

Solo yönettiğin ilk olay, düşün: bir şey break oluyor, alarm alıyorsun, ve acı başlıyor. Hemen kod açıyorsun ama bekle : ne kırıldı? Production API'ın mı, database bağlantısı mı, yoksa bir third-party servisi mi? Cloudflare down mu? 12 dakika sadece bunları bulmaya harcanır. Çözmek için gerçek fix : kodu kontrol etmek, rollback yapmak, cı/cd pipeline'ı çalıştırmak : 4 dakika.

Gerçek maliyet budur. Downtime'ın kendisi değil. Bir kişilik ekibin koordinasyon ek yükü : hiçbir şey yazılmadığı için. Ortam değişkenleri nerede? Backup SSH key nerede? Deploy komutu ne? Database şifresi nerede yayınlanmış? Production secrets neresi? Olay penceresinde bulman gereken cevapları arıyorsun, ama cevapları 3 AM öncesi vermiş olman gerekti.

Çözüm karmaşık teknoloji değil. Çözüm cevapları önceden vermiş olmak. 22:00'de rahat rahat hazırlık yap, 3 AM'de aklı başında yönet.

Açık bir test var: produksiyonu şimdi kontrol et, bütün sistem down. 10 dakika var. Hızlı yapabilir misin: ilgili logları bul, başarısız bileşeni tanımla, çöz : ve esnasında açmak zorunda olmadığın beş web sitesine gitmek zorunda kalmadan? Hayırsa, tam da bunu olay müdahale çözer. İyi bir incident response sistemi 12 dakikalık debugging'i 3 dakikaya indirir.

Her İndie Olay Müdahale Setup'ı Gerçekten İhtiyaç Duyduğu Üç Şey

Herhangi bir şey inşa etmeden önce, sistem neyin yapması lazım diye anlaş:

• Sorun ile ilgili haberin var : bir kullanıcı DM atmadan, status page checkelemeden, sen know'la otomatik

• Ne yapacağını biliyorsun : yarı uyku, stresli, sadece alert mesajıyla ne yapacağını bilir misin, flow açık

• Kullanıcılarını bilgilendir : durumu söyle, çalışan bir sayfadan, ve "we are investigating" mesajından başka bir şey

PagerDuty'nin hepsi yapmaktan basit cron job'a kadar her olay müdahale aracı bu üçün birinin haritası. İyi bir setup hepsi yapan minimal versionu inşa eder, sonra dur. On-call rotation'a gerek yok, escalation policy'e gerek yok.

Kurumsal versiyona inşa etme tutkusu vardır: on-call zamanlaması, escalation politikası, P0 ile P5 arasında severity levelları, postmortem template'leri, on-call rotasyon, dependency tracking. 20 engineer ve 500K kullanıcıda evet, bunlar necessary. Bir dev ve 500 kullanıcıda bu araçlar hafta sonlarını yakıp da kullanılmaz. Minimal versiyon şu hafta sonu yapılabilir. Eğer bir şey break ise çöz. Bunu ilk yap, sonra optimize et.

Alert Katmanını İnşa Etmek: Yanlış Pozitiflerin Sorunu İlk Gelir

Kendi alarm sistemi inşa etmiş her dev aynı hikayeyi söyler: yazdığı ilk kural hatalı. Sistemin mesela HTTP endpoint check yapıyor ama eşik değeri bozuk. İki hafta içinde pager'ın neden her dakika uyandırdığını bilerek, kütüphanenin kapalı yapıp koydu. Bu duygu "boy who cried wolf" : sonra gerçek olay olduğunda, alarmı görmezden geliyor.

Basit başla. Bir kontrol. Bozuk bir health check endpoint yeterli.

# Simple health check endpoint (Express/Node)
app.get('/health', (req, res) => {
  res.json({ status: 'ok', timestamp: Date.now() });
});

Bir cron işi ekle, her 60 saniye ping et. Üç süreli başarısız olursa SMS yolla. Bu ilk uyarı katmanın. Bunu yap ilk, başka şey ekleme. Bu alone 80% kullanıcıyı etkileyen olayları yakalar. Istatistik.io 2026 guide'ında: manual koordinasyon 12 dakika kaybeder, otomasyon bunu üç dakikaya indirir.

Bu setupta yanlış uptime raporlarının oranı sıfıra yakın. Servis gerçekten down olduğunda pager alırsın. CPU spike'ı ya da bellek burst'ü yüzünden false alarm olmaz. Uyarı her zaman doğru olmalı. Yanlış uyarı öğretir beynini: bu alarmlara artık inanma, ignore et. Eğer ilk iki hafta alarm her gece geliyorsa, sen alarm kapatıp sistem çöktüğünde haberim olmaz durumda.

Log-tabanlı uyarı (disk space, request latency, error rate) uptime kontrol işe yaradığında ve güvenilir olduğunda sonra ekle. Kendini barındıran infra için Grafana daha düşük masrafta bunu iyi tutuyor. Datadog ikiden fazla ya da üç microservice'i yönettiğinde ve deploy pipeline'ına kolay entegrasyon ve unified view istediğinde sense başlıyor.

Runbook'lar : Dokuman Değil, 3 AM Eylem Listesi

Runbook belge değildir. Teknik belge "şu sistem şöyle işler" açıklar. Runbook sadece gelecek, stresli, yarı uyku sen'e "hemen bunu yap" söyler.

Yazılı olmayan runbook = ilk olayda 40 dakika boşa harcama. Yazılı, testlenmiş runbook = 6 dakika çözüm. Fark bu. Incident.io bulguları: postmortem yeniden yazılmadığında aynı sorun yüzde 60 olasılıkla tekrarlanıyor.

Solo proje'ler için işe yarar format sadece:

• Ne kırıldı? Bir cümle, gözlemlenebilir belirtiler sadece (API timeout? Database error? DNS fail? Memory spike?)

• Acil mi? Sağ ödeme müşterileri şu an etkilenir mi? Hangisi? Tümü mi partial mi?

• Ne yapıyorum? Üç ile beş numaralı adım, deneme yapılacak en hızlı şey ilk (restart app, check database connection, check deploy status, rollback)

Bu kadar. Daha fazla uzatma. Olay olmadığında, quiet office'de, bir fincan kahve ile yaz. Olay sonra kontrol et: runbook'u yardımcı mıydı, neyi unutmuşsun? Güncelleyin sonraki kez. Altı ay içinde runbook'lar pattern ortaya çıkarıyor.

Runbook'ları nereye kaydettiğin konu'dan daha az önem. Alışkanlık önemli. Notion sayfası, repo'daki Markdown dosya, shared doc, even bir Telegram note. Tek test: 30 saniyede, telefonda, 3 AM'de açabilir misin? Evet'se iyi.

Repo dosyasının üzerinde Notion'ın asıl argümanı mobile erişim. Üretim trafiği var, yeni deploy ettiğin kodla ilgili endişen var, uyku odasında telefon yanında yatıyorsun : o saatte repoyu SSH ile açmak can sıkıcı. Notion açılır. GitBook başka bir seçenek : daha structured, public developer docs olarak da çalışabilir.

Public Status Page İnşa Etmek: Kullanıcılar Gerçekten Ne İstiyor

Kullanıcılarının real-time observability dashboard gerekmiyor. Sadece iki şey merak ediyor: herkes için mi broken, ve sen farkında mısın?

Minimum viable status page üç unsur:

• Status göstergesi : en çok üç state: operational, degraded, down

• Geçerli state'in ne zaman güncellendiği (last updated timestamp)

• Bir şey yanlış gittiğinde açık bir cümle

Kullanıcı olay sırasında status page açıyor, "degraded: database maintenance" yazıyor, rahatlaşıyor. Çünkü şimdi sorun kendi setup'ında değil, sensinde. Kendisi sorun gidermekle vakit kaybetmemiş oluyor. Telefonda arkadaşlarına "sunucu down, çalışan işlem başladılar" yazdı.

İnşa etmek dört saat:

1. Static HTML + JavaScript, endpoint'ten status al, göster

2. Supabase table: status (enum) ve message (text)

3. Cron job: health check'i kontrol et, table'ı güncellesin otomatik

4. Admin endpoint: olay sırasında manual mesaj yaz, auth arkası

Zor kısmı inşa değil : JavaScript / cron zaten biliyor. Zor kısmı alışkanlık. Olay başladı, alarm alıyor, terminal açıyor : ilk şey: dashboard'u "degraded" olarak işaretle. Bu 30 saniye. Bunu yapmazsan, support e-mailleri başlıyor: "Site down mi? Ne oluyor?"

Senin açısından inşa etmenin başka argümanı: ticari status page araçları (Statuspage.io, Atlassian, others) hiç de kompleks değil : JSON endpoint + static sayfa. Ama aylık $30–$100 ücret. Yapı bir kez, sahip ol, kop'la. Kullanıcılar uzun bulutlu araç gerek yok.

Plus: status page ayrı domain'de host et. Main domain down bile hala erişilebilir kalır. Hatta ayrı infrastructure'da olmalı ideally.

Postmortem'ler : Sadece Kendin Suçlayacağın Zaman

Kurumsal setting'de postmortem'ler: bireyi suçlamamak, sistem sorunlarını bulmak. Solo, sen sistemsin. Kültür farklı, ama yazma alışkanlığı faydalı.

Neden solo postmortem'ler yazmalı: yazmazsan aynı bug'ı iki defa çözersin. Üç ay sonra database index'i eksik : bırakılan sorgu kilitleniyor. Vag hatırlaması var: "bunu daha önce gördüm mü?" Ama tam ne olduğunu hatırlamıyorsun, 40 dakika araştır. Yazılı postmortem'ler bu döngüyü kırıyor.

Tutuşan format, beş dakika yazma:

1. Ne oldu (bir paragraf, sadece gerçekler, suçlama yok)

2. Çözmek için ne yaptın (steps, timing)

3. Sistemde değiştirecek bir şey (proactive fix, monitoring rule, capacity planning)

4. Işlemin değiştirecek bir şey (runbook update, alerting rule, deploy checklist, etc.)

Runbook'ların yanında yaz. Otomatik entry'ye dönüş sonraki runbook güncelleme'sinde. Altı ay üzeri, bu lightweight kayıt sistem failure pattern'leri ortaya çıkarıyor. Üçüncü kez oluşan aynı database timeout? Bak postmortem'lere. Her kez kopyala - problem ise, daha derin fix yap. Belki connection pool'u artır, belki query index'le.

Bunu İnşa Etsen mi Yoksa Var Olanları Tele Bağlasan mı?

Dürüst cevap durumuna bağlı.

Sıfır ödeme müşteri: kütüphanenin hepsi inşa. Health check cron, status page, runbook'ları. Doğru öğrenme projesi. Bu hafta sonu imkan. Sana öğretir olay müdahale'nin gerçek çekirdeği ne. Eğer sonra "bu araç olarak satmak isterim" karar alırsan, gereksinimler kendinde doğrulanmış oldu. Prototip var, pattern öğrendin.

Bugün yapı müşterin var, production uptime önemli: var olan araçları tele bağla şu haftaya. Grafana Cloud free tier açar, basic uptime monitor ekler, Notion runbook'ları başlatır. Şu an coverage gerek. Sonra yavaş yavaş build ve optimize.

Nereye inşa etsen bağımsız: status page. Sahip ol, ayrı domain, bu hafta sonu. Diğer hepsi (alerting, runbook'lar, logging) existing tiers'den tele bağla aylarca, karmaşıklık sensini zorlayıncaya kadar. Bu yol daha hızlı ve daha risk-free.

Hiç Bir Olay Müdahale Rehberi Konuşmadığı Boşluk

Asıl problem araç değil. Asıl problem "uyarı setup etmeliyim" dediğin ile "gerçekten setup ettim" arasında 48 saatlik boşluk. Çoğu dev bu boşlukta kalır, ta ki bir şey break oluncaya kadar.

Çoğu solo dev stack gözlemlenebilirlik altyapısı vardır. Health check endpoint biryerde var. Error loglar dosyada ya da third-party servis'de. Deploy pipeline hata kontrol var. Ne eksik? 90 dakikalık odaklanmış tele bağlama: health check → cron uptime monitor → SMS alert → Notion runbook sayfası → Supabase status endpoint → static page. Bütün hafta sonu yapılabilir. Bunu.

Bu hafta sonu yap. 3 AM ilk olay, alarm alıyorsun, ne yapacağını biliyorsun, 4 dakika çözersin. Karşı durumda 40 dakika boşa harcardın. O fark kuru çöktüğünde, olay müdahale en iyi uygulamaları neden var anlayacaksın. Değil çünkü kurumsal ekip gerekli kılmış. Çünkü alternatif çok daha kötü.