Mühendislik Ekipleri İçin 10 Incident Management En İyi Uygulaması

Her mühendislik ekibi production incident'larıyla karşılaşacaktır. Bunları iyi yöneten ekiplerle yönetemeyenler arasındaki fark şans değil — hazırlıktır. İşte etkili incident müdahalesini kaotik yangın söndürmeden ayıran 10 uygulama.

1. Incident'ı Neyin Oluşturduğunu Tanımlayın

Her hata bir incident değildir ve her uyarı incident müdahalesi hak etmez. Net bir tanım olmadan, ekipler ya küçük sorunlara aşırı tepki verir ya da ciddi sorunlarda yetersiz kalır.

Yararlı bir çerçeve:

• Severity 1 (Kritik): Tüm kullanıcıları etkileyen tam hizmet kesintisi veya veri kaybı. Herkes göreve.
• Severity 2 (Büyük): Önemli özellik kullanılamıyor veya ciddi performans düşüşü. Özel müdahale ekibi.
• Severity 3 (Küçük): Kısmi etki, geçici çözüm mevcut. Mesai saatlerinde ele alınır.
• Severity 4 (Düşük): Kozmetik veya küçük sorun. Hata olarak takip edilir, incident olarak değil.

Bunu yazın. Ekip olarak üzerinde anlaşın. Üç ayda bir gözden geçirin ve ayarlayın.

2. Tespiti Otomatikleştirin

Ekibiniz kesintileri müşteri şikayetlerinden öğreniyorsa, zaten geride kalmışsınızdır. Otomatik monitoring, sorunları kullanıcılardan önce tespit etmelidir.

Temel otomatik tespit:

• Tüm kritik endpoint'ler için uptime monitoring (15-30 saniyelik aralıklar)
• Hata oranları taban çizgiyi aştığında tetiklenen hata oranı uyarıları
• Response time düşüşü için performans uyarıları
• Kaynak tükenmesi (CPU, bellek, disk) için altyapı uyarıları

Hedef: incident'ları 60 saniye içinde tespit etmek, ekibi 90 saniye içinde bilgilendirmek, 5 dakika içinde müdahaleye başlamak.

3. Net Sahiplik Oluşturun

Bir incident olduğunda, birinin sorumlu olması gerekir. Net sahiplik olmadan ya kimse yanıt vermez ya da herkes kaotik bir şekilde yanıt verir.

Incident'lardan önce rolleri tanımlayın:

• Incident Commander: Müdahaleyi koordine eder. Kararları verir. Durumu iletir. En kıdemli mühendis olması gerekmez — organize ve baskı altında sakin olması gerekir.
• Teknik Lider: Sorunu teşhis eder ve düzeltir. Etkilenen sistemin en derin teknik bilgisine sahip kişi.
• İletişim Lideri: Status page'i günceller, paydaşlarla iletişim kurar, müşteriye dönük mesajlaşmayı yönetir.

Küçük ekipler için bir kişi birden fazla şapka takabilir. Bu sorun değil — ancak roller yine de açık olmalıdır.

4. Yaygın Senaryolar İçin Runbook'lar Oluşturun

Aktif bir incident'ın baskısı altında, deneyimli mühendisler bile hata yapar. Runbook'lar, bilinen arıza modları için adım adım prosedürler sağlayarak bilişsel yükü azaltır.

İyi runbook'lar şunları içerir:

• Belirtiler: Bu arıza neye benzer?
• Tanı adımları: Kök neden nasıl doğrulanır.
• Çözüm adımları: Adım adım nasıl düzeltilir.
• Rollback prosedürleri: Son değişiklikler nedense nasıl geri alınır.
• Yükseltme kriterleri: Ek kişi veya ekipler ne zaman dahil edilir.

Başlangıç için yaygın runbook'lar:

• Uygulama sunucusu çökmesi / yeniden başlatma
• Database bağlantı tükenmesi
• SSL sertifika süre sonu
• DNS yanlış yapılandırması
• Deployment rollback
• DDoS azaltma

5. Erken ve Dürüst İletişim Kurun

Bir incident sırasındaki sessizlik, mümkün olan en kötü iletişim stratejisidir. Kullanıcılar sessizliği varsayımlarla doldurur ve bu varsayımlar her zaman gerçeklikten daha kötüdür.

Dahili iletişim:

• Hemen özel bir incident kanalı açın
• Düzenli güncellemeler yayınlayın (minimum her 10-15 dakikada bir)
• Dahil edin: ne bildiğinizi, ne bilmediğinizi, ne yaptığınızı
• Tüm önemli olaylar için zaman damgaları paylaşın

Harici iletişim:

• Incident'ı tespit ettikten sonraki 5 dakika içinde status page'inizi güncelleyin
• Durum geliştikçe güncellemeler yayınlayın
• Etki konusunda dürüst olun — küçümsemeyin
• Mümkün olduğunda tahmini çözüm süresi belirtin

6. Severity Tabanlı Müdahale Prosedürleri Kullanın

Farklı severity'ler farklı müdahale seviyeleri hak eder. Her soruna aynı aciliyeti uygulamak, küçük sorunlarda tükenmişliğe ve kritik sorunlarda kayıtsızlığa yol açar.

Severity 1 müdahalesi:

• Nöbetçi mühendise anında uyarı
• Incident Commander aktive edilir
• Status page 5 dakika içinde güncellenir
• Gerekirse tüm ekip göreve
• Her 10 dakikada güncellemeler
• Post-mortem zorunlu

Severity 2 müdahalesi:

• Nöbetçi mühendise Slack + email ile bildirim
• Status page 15 dakika içinde güncellenir
• Her 30 dakikada güncellemeler
• Post-mortem önerilir

7. Metrikleri Düzenli Takip Edin

Ölçmediğiniz şeyi iyileştiremezsiniz. Bu incident metriklerini takip edin:

• MTTD (Mean Time to Detect): Incident başlangıcından tespite kadar geçen süre. Hedef: Sev 1 için < 2 dakika.
• MTTR (Mean Time to Recovery): Tespiten çözüme kadar geçen süre. En önemli metriktir.
• MTTA (Mean Time to Acknowledge): Uyarıdan ilk insan yanıtına kadar geçen süre.
• Incident sıklığı: Haftalık/aylık incident sayısı, severity'ye göre.
• Müşteri etki süresi: Müşterilerin sorunu ne kadar süre deneyimlediği.

Bu metrikleri aylık gözden geçirin. İyileştirme hedefleri belirleyin. İlerlemeyi kutlayın.

8. Suçsuz Post-Mortem'ler Yapın

Post-mortem'ler gelecekteki incident'ları azaltmak için en değerli pratiktir. Ancak yalnızca doğru yapılırsa.

Suçsuz post-mortem yapısı:

1. Özet: Ne olduğunu anlatan bir paragraf.
2. Etki: Kim etkilendi, ne kadar süre, mümkünse nicelleştirilmiş.
3. Zaman çizelgesi: Tespiten çözüme dakika dakika hesap.
4. Kök neden: Sadece tetikleyici değil, altta yatan neden. Beş kez "neden" sorun.
5. Katkıda bulunan faktörler: Incident'ı ne daha kötü veya çözmeyi ne daha zor yaptı?
6. Ne iyi gitti: Müdahalenin hangi yönleri etkili oldu?
7. Eylem maddeleri: Spesifik, atanmış, süre sınırlı iyileştirmeler.

"Suçsuz" kısmı kritiktir. İnsanlar suçlanmaktan korkarsa bilgi saklarlar. Bilgi saklarlarsa incident'lardan öğrenemezsiniz. Bireylere değil, sistemlere ve süreçlere odaklanın.

9. Incident Zaman Çizelgesi Tutun

Aktif bir incident sırasında, her şeyi olurken belgeleyin:

• Sorun ilk ne zaman tespit edildi?
• İlk insan ne zaman bilgilendirildi?
• Hangi tanı adımları atıldı?
• Ne denendi ve işe yaramadı?
• Kök neden ne zaman belirlendi?
• Hangi düzeltme uygulandı?
• Hizmet ne zaman geri geldi?

Gerçek zamanlı belgeleme iki amaca hizmet eder: incident sırasında ekibe yardımcı olur (herkes mevcut durumu görebilir) ve sonraki post-mortem için ham malzeme sağlar.

10. Pratik Yapın ve İterasyon Yapın

Incident müdahalesi pratikle gelişen bir beceridir — ancak pratik yapmak için gerçek incident'ları beklemeye gerek yoktur.

Pratik yapma yolları:

• Game day'ler: Incident'ları simüle edin ve müdahale prosedürlerinizi uygulayın. Staging'de arıza enjekte edin ve runbook'larınızı çalıştırın.
• Masaüstü tatbikatlar: Ekip olarak varsayımsal senaryoları gözden geçirin. "Birincil database Cumartesi sabah 2'de çöker. Ne yaparız?"
• Chaos engineering: Monitoring, uyarı ve kurtarma mekanizmalarınızı test etmek için production'da (dikkatli bir şekilde) kasıtlı olarak arızalar oluşturun.
• Retrospektifler: Her gerçek incident'tan sonra neyi iyileştireceğinizi belirleyin ve değişiklikleri gerçekten uygulayın.

Başlarken

Incident management pratiğinizi sıfırdan oluşturuyorsanız, buradan başlayın:

1. Kritik hizmetleriniz için uptime monitoring kurun
2. Müşteri iletişimi için bir status page oluşturun
3. Severity seviyeleri ve müdahale prosedürleri tanımlayın
4. En olası 3 arıza modunuz için runbook'lar yazın
5. Bir sonraki incident'ınızdan sonra ilk post-mortem'inizi yapın

Birinci günde mükemmel bir sürece ihtiyacınız yok. Basit başlayın, her incident'tan öğrenin ve iterasyon yapın.

Incident müdahale temeli oluşturun. Ücretsiz başlayın — tek platformda uptime monitoring, incident takibi ve status page'ler.