Incident anında iki uç vardır: ya hiç veri yoktur ya da “her şeyi topla” diye sistemi log/pcap’a boğarsın. İkisinin de ortak sonucu aynıdır: postmortem’de “tam olarak ne oldu?” sorusuna kanıt yerine yorumla cevap verilir.
Benim sahada en çok işe yarayan yaklaşım: Delil Toplama Kiti (evidence kit) + rol dağılımı. Bu ikisi, incident’ı sadece söndürmek değil, aynı zamanda bir sonraki incident’ı ucuzlatmak için çalışır.
Neyi hedefliyoruz?
- Olayı çözerken kanıtı öldürmemek
- Olaydan sonra “şansa bağlı” değil, kanıta dayalı iyileştirme yapmak
- Güvenlik (forensics) ihtiyacı doğarsa, başlangıç verisini hazır tutmak
Rol dağılımı: üç kişi, üç sorumluluk
Küçük ekiplerde bile bu ayrım işe yarar:
- Incident Commander (IC): karar alır, öncelik belirler, iletişimi yönetir
- Scribe: zaman çizelgesi tutar, alınan aksiyonları ve sonuçlarını yazar
- Evidence Owner: kanıt checklist’ini yürütür (log/snapshot/konfig)
Bu üç rol tek kişide toplanırsa, genelde kanıt kısmı kaybolur.
Delil Toplama Kiti: “minimal ama geri üretilebilir”
Ben kit’i 6 parçaya ayırıyorum. Her parça için “neden var?” sorusunun cevabı nettir.
1) Zaman standardı
- Tüm sistemlerde NTP/Chrony sağlık kontrolü
- Incident’ta tüm kayıtların UTC veya tek bir saat standardıyla toplanması
Pratik kontrol:
timedatectl status
chronyc tracking 2>/dev/null || true2) Değişiklik izi (change evidence)
Olayın en sık kök nedeni: “az önce bir şey değişti.”
Topla:
- Deploy/CI/CD logu (commit SHA, pipeline id)
- Config management değişiklikleri
- Firewall/LB/policy değişiklikleri
3) Erişim izi (access evidence)
Topla:
- Bastion/SSO audit
- Privileged komut kayıtları (auditd, shell history değil; audit)
- Break-glass kullanımı (kim, ne zaman, neden)
4) Servis sinyali (service evidence)
Topla:
- Hata oranı, latency, saturation (SLO/SLI)
- En kritik dashboard ekran görüntüsü veya export
- Alarm fırtınası varsa “hangileri semptom, hangileri neden” notu
5) Sistem sinyali (host evidence)
Topla:
- CPU/memory/disk/net temel metrikleri
- Son 30–60 dk kernel logları
- OOM, conntrack table full, filesystem error gibi “tek satırlık” kritik sinyaller
Pratik:
uptime
free -m
df -h
dmesg -T | tail -n 200
journalctl --since "-60m" --no-pager | tail -n 2006) Konfig snapshot (config evidence)
Amaç: “şu anki hâli” dondurmak.
- Edge: routing table / policy snapshot
- Uygulama: feature flag durumu, env/secret versiyonu (değer değil, sürüm)
- Infra: LB pool üyeleri, weight’ler, health-check state
Incident akışına nasıl bağlanır?
En pratik model:
- IC ilk 5 dakikada containment kararını verir
- Scribe, her aksiyonu “timestamp + komut + sonuç” olarak yazar
- Evidence Owner, containment sonrası ilk sakinleşme anında kit’i tamamlar
Bu sayede “yangın söndürme” ile “kanıt üretme” aynı anda yürür.
Sonuç
Delil toplama kiti, incident’ı yavaşlatmaz; doğru kurulduğunda incident’ı hızlandırır. Çünkü ekip, panik anında “ne toplayalım?” diye düşünmez; standart çalışır. Operasyonel liderlik burada başlar: sadece sistemi değil, olayı yönetme sistemini de tasarlamak.