Olaylar istisnai değildir; çalışan sistemlerin normal çıktısıdır. Ekipleri ayıran şey bir şeylerin bozulup bozulmaması değil, bozulduğunda ne kadar öngörülebilir tepki verdikleridir. Çalışan bir olay süreci tek sayfaya sığar: net önem seviyeleri, isimli roller, stres altında izlenebilen runbook'lar, kullanıcının yaşadığına bağlı alarmlar ve her olayı bir sistem iyileştirmesine çeviren postmortem alışkanlığı. Bu playbook her parçayı tek tek ele alıyor.

Önem Sınıflandırması

Önem seviyesi tek bir soruyu hızla cevaplamak için vardır: ne kadar sert seferber oluyoruz? Çoğu kurum için üç seviye yeter. SEV1: kullanıcılar ürünü kullanamıyor, veri risk altında ya da devam eden bir güvenlik ihlali var — herkes göreve, yönetime bildirim, herkese açık durum sayfası. SEV2: geçici çözümü olan ciddi bozulma ya da büyük bir özelliğin devre dışı kalması — adanmış müdahale ekibi, sabit aralıklarla paydaş güncellemesi. SEV3: küçük etki ya da yükselmiş risk — sahibi olan ekip mesai saatinde çözer.

Şemayı iki kural çalıştırır. Olayı herkes ilan edebilir — ilan yönetici onayı gerektiriyorsa, gecikmeyi tam da en çok acıtan yere eklemişsiniz demektir. Ve şüphede yüksek sınıfla, sonra düşür; tersi desen — olayı bir saat sonra yükseltmek — küçük kesintilerin uzun kesintilere dönüşme yoludur.

Roller: Olay Komutanı Debug Yapmaz

Çoğu ekibin yapabileceği en değerli yapısal değişiklik, koordinasyonu incelemeden ayırmaktır. Olay komutanı (IC) müdahalenin sahibidir: durumu takip eder, iş atar, hafifletme kararlarını verir ve olay kanalının "durum ne?" diye soran kırk kişiye dönmesini engeller. IC terminale dokunmaz. İletişim lideri dışa akışın sahibidir — durum sayfası güncellemeleri, paydaş mesajları, bir sonraki güncelleme sözü ve o sözün tutulması. Operasyon lideri gereken kişilerle birlikte teknik incelemeyi sürer.

Küçük bir ekipte SEV3 sırasında üç şapkayı tek kişi takabilir — sorun değil; yeter ki şapkalar var olsun ve bir SEV1 onları ayırsın. Tasarımla engellenecek başarısızlık modu şu: en iyi mühendisin aynı anda debug yapması, koordine etmesi ve yönetici sorularını karşılaması — üçünü de kötü yaparak.

Sabah 3'te Çalışan Runbook'lar

Runbook en kötü koşullarda yargılanır: sayfalanmış, yarı uykulu, bu alarmı ilk kez gören bir mühendis. Kalite çıtası budur. Sayfa-seviyesi her alarm doğrudan runbook'una link verir. İlk bölüm teşhistir — gerçekte ne olduğunu ortaya koyan üç komut — herhangi bir müdahaleden önce. Komutlar kopyala-yapıştır edilebilirdir, düzyazıyla anlatılmaz. Eskalasyon yolu bir ekip ve bir kanal ismi verir; geçen yıl ayrılan birini değil. Ve runbook'lar egzersiz edilir: nöbet rotasyonunu en kritik beş runbook'tan geçiren bir tatbikat günü, bayat olanları kesintiden önce bulur.

SLO'ya Dayalı Alarm

Nedenlere sayfalamak — CPU yüksek, disk %80'de, pod yeniden başlıyor — gürültü üretir; gürültü de görmezden gelinen sayfalar. Bunun yerine belirtilere sayfalayın: hizmet seviyesi hedefi (SLO) yanıyor. %99,9 erişilebilirlik vaat ediyorsanız hata bütçeniz isteklerin %0,1'idir; sayfa, o bütçe önemli olacak hızda tükenirken çalmalıdır. Prometheus dilinde %99,9 SLO için hızlı-yanma kuralı şöyle görünür:

- alert: HighErrorBudgetBurn
  expr: (
      sum(rate(http_requests_total{code=~"5.."}[5m]))
    /
      sum(rate(http_requests_total[5m]))
  ) > (14.4 * 0.001)
  for: 2m
  labels:
    severity: page
  annotations:
    summary: "Hızlı yanma: hata oranı %99,9 SLO bütçesinin 14,4 katı"

Hızlı-yanma kuralını (kısa pencere, yüksek çarpan, sayfalar) yavaş-yanma kuralıyla (uzun pencere, düşük çarpan, ticket açar) eşleştirin. Neden-bazlı sinyaller yine var — pano ve ticket olarak, sayfa olarak değil. Pratik sonuç: her sayfa kullanıcı etkileniyor demektir, dolayısıyla her sayfa ciddiye alınır. Güvenlik olayları da aynı disiplini hak eder; SIEM sistemleri yazımız tespit ve alarmın o tarafta nasıl birleştiğini anlatıyor.

Suçlamasız Postmortem'ler

Postmortem, olayın yatırıma dönüştüğü yerdir. Suçlamasız, sonuçsuz demek değildir; analiz insanların ellerindeki bilgiyle makul davrandığını varsayar ve sistemin yanlış eylemi neden kolay, doğruyu neden zor kıldığını sorar. İşe yarar bir postmortem şunları içerir: kesin bir zaman çizelgesi, katkıda bulunan etkenlerin tamamı — tek kök neden kurgusuna direnin — ve her birinin sahibi ve vadesi olan aksiyon maddeleri. Sahipsiz aksiyon maddesi bir dilektir. Açık maddeleri düzenli bir forumda gözden geçirin ve postmortem'leri geniş paylaşın: tüm organizasyonun ders çıkardığı bir kesinti tamamen boşa gitmemiştir.

Bunların hiçbiri yeni araç gerektirmez — süreci kesinti sırasında icat etmek yerine sakin koşullarda kararlaştırmayı gerektirir. Önem şemaları, nöbet yapısı ve SLO tabanlı alarm kurulumunda — ya da güvenlik olaylarını da kapsayan bir olay sürecinde — yardım isterseniz SecOps ekibimiz bu işi yapıyor; yönetilen hizmetler ekibimiz nöbet yükünü sizinle birlikte taşıyabilir.

Bunun hesaplarınıza karşı denetlenmesini ister misiniz? AWS güvenlik denetimimiz ISO 27001, SOC 2, NIS2 ve DORA'ya eşlenmiş 98 maddeyi kapsar — sabit fiyat, kanıtlar dahil.

Etiketler: #OlayMüdahalesi #SRE #SLO #Nöbet #Postmortem