Küçük ekiplerde olay müdahalesi: Sistem çöktüğünde ilk 30 dakika

Canlı sistem çöktüğünde küçük ekiplerin ihtiyacı büyük bir prosedür değil, önceden konuşulmuş birkaç basit kuraldır: kim yönetir, ilk ne yapılır, müşteriye ne zaman ve nasıl haber verilir, sistem nasıl geri getirilir. Bu yazıda olay müdahalesini (incident response) iki-beş kişilik ekiplere uygun, sade bir akışa indiriyoruz.

Küçük ekiplerde olaylar genelde aynı şekilde yaşanır: Bir müşteri "site açılmıyor" diye yazar, üç kişi aynı anda sunucuya bağlanır, biri servisi yeniden başlatır, diğeri aynı anda log siler, kimse müşteriye dönmez. Sorun çözülür ama ne olduğu tam anlaşılmaz ve iki hafta sonra tekrar eder.

Önce tanım: "olay" nedir?

Her hata olay değildir. Basit bir ayrım yeterlidir:

Seviye	Örnek	Tepki
Kritik	Site veya API tamamen kapalı, veri kaybı riski, ödeme alınamıyor	Hemen müdahale, gece de olsa
Önemli	Bir özellik çalışmıyor, sistem belirgin yavaş	Mesai içinde aynı gün
Düşük	Görsel hata, tek kullanıcıyı etkileyen sorun	Normal iş kuyruğu

Seviyeyi önceden tanımlamak, gece 3'te "bu beni uyandırmaya değer mi?" tartışmasını ortadan kaldırır.

Roller: küçük ekipte bile iki şapka

Olay sırasında en sık yapılan hata herkesin aynı anda teknik çözüme koşmasıdır. İki kişi bile olsanız iki rol ayırın:

• Olay sorumlusu: Kararı verir, kimin ne yaptığını takip eder, zaman çizelgesini not alır. Gerekirse kendisi teknik iş yapmaz.
• Çözen kişi: Sorunu teşhis eder ve düzeltir. Yaptığı her değişikliği kanala yazar.

Tek kişiyseniz bile iki şapkayı bilinçli olarak değiştirin: önce not alın, sonra müdahale edin.

İlk 30 dakika akışı

1. Doğrula (0–5 dk): Sorun gerçekten var mı, kimi etkiliyor? Dış izleme aracına, hata oranına ve son deploy zamanına bakın.
2. Kanal aç (5. dk): Tek bir olay kanalı ya da başlığı açın. Tüm konuşma ve komutlar orada olsun.
3. Etkiyi durdur (5–20 dk): Amaç önce kök nedeni bulmak değil, kanamayı durdurmaktır. Son deploy şüpheliyse geri alın, sorunlu özelliği kapatın, trafiği sağlıklı sunucuya yönlendirin.
4. Haber ver (15. dk): Etkilenen müşterilere kısa bir bilgi gönderin: ne biliyoruz, ne yapıyoruz, bir sonraki güncelleme ne zaman.
5. Doğrula ve izle (20–30 dk): Düzeltmeden sonra metrikleri izleyin; sorunun gerçekten bittiğinden emin olmadan olayı kapatmayın.

Geri alma ancak önceden hazırsa hızlıdır. Bunun için CI/CD hattınızın tek komutla bir önceki sürüme dönebilmesi ve yedeklerinizin gerçekten geri yüklenebilir olması gerekir.

Müşteriyle iletişim

Teknik ekipler çoğu zaman "önce çözelim, sonra söyleriz" der. Oysa sessizlik, kesintiden daha çok güven kaybettirir. İyi bir ilk mesaj kısadır:

• Ne etkileniyor (örneğin "sipariş ekranı açılmıyor")
• Ne zamandan beri
• Üzerinde çalıştığınız
• Bir sonraki güncellemenin saati

Kesin süre vermeyin, tahmini bir sonraki güncelleme saati verin. Basit bir durum sayfası ya da sabit bir mesaj şablonu bu işi dakikalar içinde halleder.

Görmeden müdahale edilmez

Olay müdahalesinin hızı, gözlemlenebilirliğin kalitesine bağlıdır. En azından:

• Sistemi dışarıdan kontrol eden bir erişilebilirlik izleme (uptime) aracı
• Hata oranı ve yanıt süresi için birkaç anlamlı alarm
• Merkezî bir yerde aranabilir loglar
• Her deploy'un zamanını gösteren bir kayıt

Bunları nasıl sade tutacağınızı gözlemlenebilirlik yazımızda anlattık.

Olay sonrası: suçlamasız değerlendirme

Olay kapandıktan sonraki birkaç gün içinde 30 dakikalık bir değerlendirme yapın. Amaç kimin hata yaptığını bulmak değil, sistemin neden buna izin verdiğini anlamaktır. Kısa bir şablon:

• Ne oldu, zaman çizelgesi
• Etki: kaç kullanıcı, ne kadar süre
• Kök neden ve katkıda bulunan etkenler
• Ne iyi gitti, ne zorlaştı
• 2–3 somut aksiyon, her birinin sahibi ve tarihi

Aksiyonlar küçük olmalı: bir alarm eklemek, bir runbook adımı yazmak, bir testi otomatikleştirmek. "Daha dikkatli olacağız" bir aksiyon değildir.

Küçük ekipler için hazırlık listesi

• Olay seviyeleri yazılı ve herkes biliyor
• Nöbet ya da "kim aranır" listesi güncel
• Tek komutla geri alma denenmiş
• Yedekten geri yükleme en az bir kez test edilmiş
• Müşteri bilgilendirme şablonu hazır
• Sık görülen sorunlar için kısa runbook'lar var
• Olay sonrası değerlendirme şablonu hazır

Staging ortamı olan ekipler bu adımları canlıya dokunmadan prova edebilir.

SSS

Küçük bir ekip için nöbet sistemi gerekli mi?
Kritik seviye olaylar mesai dışında da oluyorsa, en azından kimin aranacağı belli olmalıdır. Haftalık dönüşümlü basit bir liste çoğu ekip için yeterlidir.

Kök nedeni bulmadan sistemi geri getirmek doğru mu?
Evet. Önce etkiyi durdurun. Log ve metrikler korunduğu sürece kök neden analizi sonra yapılabilir.

Her olay için değerlendirme toplantısı yapmak gerekir mi?
Kritik ve önemli seviyedeki olaylar için evet. Düşük seviyedeki tekrar eden sorunlar ayda bir toplu olarak gözden geçirilebilir.

TW Bilişim bu konuda ne yapıyor?
Küçük ekiplerin altyapısına izleme, alarm, tek komutla geri alma ve test edilmiş yedekleme kuruyor; olay seviyeleri, runbook'lar ve değerlendirme şablonlarını ekiple birlikte hazırlıyoruz.

Sonuç

İyi olay müdahalesi kahramanlık değil, hazırlıktır. Önceden tanımlanmış seviyeler, net roller, hazır bir geri alma yolu ve suçlamasız bir değerlendirme alışkanlığı, küçük bir ekibin de büyük kesintileri sakin ve hızlı atlatmasını sağlar.

Altyapınızı olaylara hazırlamak için destek isterseniz: iletişim veya [email protected].