Felaket Kurtarma Ekibi: Rol ve Sorumluluk Tanımları

Tarafındankomut
0 Comments

Bir felaket anında panik kaçınılmazdır. Sunucular yanıyor, veriler uçuyor, yöneticiler telefona yapışmış durumda ve herkes “ne yapacağız?” diye soruyor. İşte tam bu noktada, önceden tanımlanmış bir Felaket Kurtarma Ekibi olmayan organizasyonlar ile olanlar arasındaki fark ortaya çıkıyor. Kurtarma süreci bir kaos ortamında değil, net roller ve sorumluluklar çerçevesinde yürütüldüğünde RTO (Recovery Time Objective) ve RPO (Recovery Point Objective) hedeflerine ulaşmak mümkün oluyor. Bu yazıda, gerçek bir DR ekibinin nasıl yapılandırılacağını, rollerin ne anlama geldiğini ve bu rollerin pratik olarak nasıl çalıştığını ele alacağız.

Felaket Kurtarma Ekibi Neden Bu Kadar Önemli?

Çoğu organizasyon DR planı yazıyor ama bu planın içindeki roller belirsiz kalıyor. “IT ekibi halleder” yaklaşımı, gerçek bir felakette işe yaramıyor. Çünkü felaket anında herkes aynı anda birden fazla şeyi yapmaya çalışıyor, iletişim kopuyor ve kritik adımlar atlınıyor.

Bunu bir örnek üzerinden düşünelim: 2021 yılında OVHCloud’un Strasbourg veri merkezinde yaşanan yangın, binlerce müşteriyi etkiledi. O gün doğru ekip yapısına sahip organizasyonlar saatler içinde ayağa kalkarken, hazırlıksız olanlar günlerce çevrimdışı kaldı. Fark sadece teknik altyapıda değil, insan organizasyonunda yatıyordu.

İyi bir DR ekibi şu sorulara net cevap verebilmelidir:

  • Felaket anında kim karar veriyor?
  • Kim teknik müdahaleyi yürütüyor?
  • Kim iletişimi koordine ediyor?
  • Kim sistemi eski haline getirmekten sorumlu?
  • Kim test senaryolarını yönetiyor?

Ekip Yapısı: Temel Roller

DR Program Yöneticisi (Incident Commander)

Bu rol, tüm kurtarma operasyonunun tepesinde oturuyor. Felaket anında teknik müdahaleye karışmıyor, bunun yerine büyük resmi görüyor ve karar alıyor. Bir anlamda sahne yöneticisi gibi düşünebilirsiniz.

Temel sorumluluklar:

  • DR planını devreye alma kararını vermek
  • Ekipler arası koordinasyonu sağlamak
  • Yönetim ve üst paydaşlara durum raporu vermek
  • Kurtarma aşamalarını onaylamak
  • “Sisteme dönüş” (failback) kararını vermek

DR Program Yöneticisi aynı zamanda tatbikat süreçlerini de yönetiyor. Aşağıdaki script, tatbikat zamanlamasını ve ekip bildirimlerini otomatize etmek için kullanılabilir:

#!/bin/bash
# DR Tatbikat Bildirim Scripti
# dr_notify.sh

DR_TEAM_EMAIL="[email protected]"
DRILL_DATE=$(date +"%Y-%m-%d %H:%M")
LOG_FILE="/var/log/dr_drills.log"

send_drill_notification() {
    local drill_type=$1
    local participants=$2
    
    echo "[$DRILL_DATE] DR Tatbikat Bildirimi Gonderiliyor: $drill_type" >> $LOG_FILE
    
    mail -s "[DR TATBIKAT] $drill_type - $DRILL_DATE" 
         -c "[email protected]" 
         "$DR_TEAM_EMAIL" << EOF
Merhabalar,

Asagidaki DR tatbikati planlanmistir:

Tatbikat Turu: $drill_type
Tarih/Saat: $DRILL_DATE
Katilimcilar: $participants

Lutfen hazirliklarinizi tamamlayiniz.

DR Program Yoneticisi
EOF
    
    echo "[$DRILL_DATE] Bildirim gonderildi: $drill_type" >> $LOG_FILE
}

send_drill_notification "Tam Sistem Kurtarma" "Tum IT Ekibi"

Teknik Lider (Technical Recovery Lead)

Teknik Lider, sahada çalışan ekibin başı. DR planındaki teknik adımları bizzat yürütmüyor ama teknik kararları alıyor ve ekibini yönlendiriyor. Bu kişi genellikle kıdemli bir sistem yöneticisi veya altyapı mimarı oluyor.

Temel sorumluluklar:

  • Teknik kurtarma prosedürlerini koordine etmek
  • Hangi sistemlerin hangi sırayla geleceğine karar vermek
  • Failover işlemlerini onaylamak
  • Teknik engelleri çözmek veya eskalasyon yapmak

Teknik Lider için sistem durumunu hızlıca görüntüleyen bir monitoring script’i kritik önem taşıyor:

#!/bin/bash
# Sistem Durumu Kontrol Scripti - Teknik Lider Araclari
# system_health_check.sh

REPORT_FILE="/tmp/dr_health_report_$(date +%Y%m%d_%H%M%S).txt"
CRITICAL_SERVICES=("nginx" "mysql" "postgresql" "redis" "haproxy")

check_service_status() {
    echo "=== SERVIS DURUM RAPORU ===" >> $REPORT_FILE
    echo "Kontrol Zamani: $(date)" >> $REPORT_FILE
    echo "" >> $REPORT_FILE
    
    for service in "${CRITICAL_SERVICES[@]}"; do
        STATUS=$(systemctl is-active $service 2>/dev/null)
        if [ "$STATUS" = "active" ]; then
            echo "[OK]      $service: $STATUS" >> $REPORT_FILE
        else
            echo "[KRITIK]  $service: $STATUS" >> $REPORT_FILE
        fi
    done
}

check_disk_usage() {
    echo "" >> $REPORT_FILE
    echo "=== DISK KULLANIMI ===" >> $REPORT_FILE
    df -h | awk 'NR==1 || $5+0 > 80 {print}' >> $REPORT_FILE
}

check_memory() {
    echo "" >> $REPORT_FILE
    echo "=== BELLEK DURUMU ===" >> $REPORT_FILE
    free -h >> $REPORT_FILE
}

check_replication_lag() {
    echo "" >> $REPORT_FILE
    echo "=== REPLIKASYON DURUMU ===" >> $REPORT_FILE
    # MySQL replikasyon lag kontrolu
    mysql -u monitor_user -p"$DB_PASS" -e 
        "SHOW SLAVE STATUSG" 2>/dev/null | 
        grep -E "Seconds_Behind_Master|Running" >> $REPORT_FILE
}

check_service_status
check_disk_usage
check_memory
check_replication_lag

echo "Rapor olusturuldu: $REPORT_FILE"
cat $REPORT_FILE

Sistem Kurtarma Uzmanları (Recovery Specialists)

Bu grup, teknik işleri bizzat gerçekleştiren uzmanlardır. Tipik olarak iki veya üç alt gruba ayrılır:

Altyapı ve Ağ Uzmanı:

  • Network failover işlemlerini yürütmek
  • DNS değişikliklerini uygulamak
  • Güvenlik duvarı kurallarını güncellemek
  • Load balancer yapılandırmalarını yapmak

Sunucu ve Uygulama Uzmanı:

  • Yedekten sunucu restore işlemi yapmak
  • Uygulama servislerini ayağa kaldırmak
  • Konfigürasyon dosyalarını doğrulamak
  • Servis bağımlılıklarını kontrol etmek

Veritabanı Uzmanı:

  • Veritabanı yedeğini restore etmek
  • Replikasyon senkronizasyonunu sağlamak
  • Veri tutarlılığını doğrulamak
  • Performans kontrolü yapmak

Veritabanı kurtarma süreci için örnek bir script:

#!/bin/bash
# PostgreSQL Yedek Restore Scripti
# pg_dr_restore.sh

DB_NAME="production_db"
BACKUP_DIR="/backup/postgresql"
RESTORE_LOG="/var/log/pg_restore_$(date +%Y%m%d_%H%M%S).log"
LATEST_BACKUP=$(ls -t $BACKUP_DIR/*.dump 2>/dev/null | head -1)

log_message() {
    echo "[$(date '+%Y-%m-%d %H:%M:%S')] $1" | tee -a $RESTORE_LOG
}

validate_backup() {
    if [ -z "$LATEST_BACKUP" ]; then
        log_message "HATA: Yedek dosyasi bulunamadi!"
        exit 1
    fi
    
    BACKUP_SIZE=$(du -sh "$LATEST_BACKUP" | cut -f1)
    log_message "Yedek dosyasi bulundu: $LATEST_BACKUP (Boyut: $BACKUP_SIZE)"
    
    # Yedek butunluk kontrolu
    pg_restore --list "$LATEST_BACKUP" > /dev/null 2>&1
    if [ $? -ne 0 ]; then
        log_message "HATA: Yedek dosyasi bozuk veya gecersiz!"
        exit 1
    fi
    log_message "Yedek butunluk kontrolu basarili"
}

restore_database() {
    log_message "Veritabani restore islemi basliyor..."
    
    # Mevcut baglantilari kes
    psql -U postgres -c 
        "SELECT pg_terminate_backend(pid) FROM pg_stat_activity WHERE datname='$DB_NAME';" 
        >> $RESTORE_LOG 2>&1
    
    # Veritabanini sil ve yeniden olustur
    dropdb -U postgres $DB_NAME >> $RESTORE_LOG 2>&1
    createdb -U postgres $DB_NAME >> $RESTORE_LOG 2>&1
    
    # Restore et
    pg_restore -U postgres -d $DB_NAME -v 
        "$LATEST_BACKUP" >> $RESTORE_LOG 2>&1
    
    if [ $? -eq 0 ]; then
        log_message "Restore islemi basariyla tamamlandi"
    else
        log_message "UYARI: Restore sirasinda bazi hatalar olustu. Log incelenmelidir."
    fi
}

verify_restore() {
    log_message "Restore dogrulama yapiliyor..."
    
    TABLE_COUNT=$(psql -U postgres -d $DB_NAME -t -c 
        "SELECT COUNT(*) FROM information_schema.tables WHERE table_schema='public';" 2>/dev/null | tr -d ' ')
    
    log_message "Restore edilen tablo sayisi: $TABLE_COUNT"
    
    if [ "$TABLE_COUNT" -gt 0 ]; then
        log_message "Dogrulama BASARILI: Veritabani erisimi saglandi"
    else
        log_message "Dogrulama BASARISIZ: Tablo bulunamadi!"
        exit 1
    fi
}

log_message "=== DR RESTORE ISLEMI BASLIYOR ==="
validate_backup
restore_database
verify_restore
log_message "=== DR RESTORE ISLEMI TAMAMLANDI ==="

İletişim Koordinatörü (Communications Lead)

Bu rol genellikle küçük organizasyonlarda göz ardı ediliyor, ama bir felakette en kritik rollerden biri. İletişim Koordinatörü teknik değil ama stratejik bir figür.

Temel sorumluluklar:

  • Müşteri ve kullanıcı iletişimini yönetmek
  • Durum sayfasını (status page) güncellemek
  • Üst yönetime ve yönetim kuruluna raporlama yapmak
  • Basın açıklamalarını hazırlamak (gerekirse)
  • İç ekip iletişim kanallarını aktif tutmak
  • Yasal bildirim yükümlülüklerini takip etmek (KVKK, GDPR vb.)

Otomatik durum bildirimi için bir script:

#!/bin/bash
# Durum Sayfasi Guncelleme ve Bildirim Scripti
# status_update.sh

STATUS_API_URL="https://api.statuspage.io/v1/pages/PAGE_ID/incidents"
API_KEY="your_statuspage_api_key"
SLACK_WEBHOOK="https://hooks.slack.com/services/YOUR/WEBHOOK/URL"
INCIDENT_TITLE=$1
INCIDENT_BODY=$2
INCIDENT_STATUS=${3:-"investigating"}  # investigating, identified, monitoring, resolved

update_status_page() {
    curl -s -X POST "$STATUS_API_URL" 
        -H "Authorization: OAuth $API_KEY" 
        -H "Content-Type: application/json" 
        -d "{
            "incident": {
                "name": "$INCIDENT_TITLE",
                "status": "$INCIDENT_STATUS",
                "body": "$INCIDENT_BODY",
                "components": {
                    "component_id": "degraded_performance"
                }
            }
        }"
}

notify_slack() {
    curl -s -X POST "$SLACK_WEBHOOK" 
        -H "Content-Type: application/json" 
        -d "{
            "text": ":rotating_light: *DR OLAYI*: $INCIDENT_TITLE",
            "attachments": [{
                "color": "danger",
                "text": "$INCIDENT_BODY",
                "footer": "DR Iletisim Koordinatoru | $(date)"
            }]
        }"
}

update_status_page
notify_slack
echo "Durum guncellendi: $INCIDENT_TITLE [$INCIDENT_STATUS]"

Doğrulama ve Test Mühendisi (Validation Engineer)

Bu rol kurtarma sürecinin en hafife alınan ama en kritik parçası. Sistemler ayağa kalktıktan sonra her şeyin gerçekten çalıştığını doğrulamak görevidir.

Temel sorumluluklar:

  • Smoke test senaryolarını çalıştırmak
  • Kritik iş süreçlerinin çalıştığını doğrulamak
  • Veri tutarlılığını kontrol etmek
  • Performans testleri yapmak
  • “Sisteme dönüş” onayını vermek
#!/bin/bash
# DR Dogrulama Test Suiti
# dr_validation.sh

PASS_COUNT=0
FAIL_COUNT=0
TEST_REPORT="/tmp/dr_validation_$(date +%Y%m%d_%H%M%S).txt"

run_test() {
    local test_name=$1
    local test_command=$2
    local expected=$3
    
    result=$(eval "$test_command" 2>/dev/null)
    
    if echo "$result" | grep -q "$expected"; then
        echo "[PASS] $test_name" | tee -a $TEST_REPORT
        ((PASS_COUNT++))
    else
        echo "[FAIL] $test_name (Beklenen: $expected, Alinan: $result)" | tee -a $TEST_REPORT
        ((FAIL_COUNT++))
    fi
}

echo "=== DR DOGRULAMA TEST SUITI ===" | tee $TEST_REPORT
echo "Baslangic: $(date)" | tee -a $TEST_REPORT
echo "" | tee -a $TEST_REPORT

# Web servisi kontrolu
run_test "HTTP Endpoint Kontrolu" 
    "curl -s -o /dev/null -w '%{http_code}' https://app.sirket.com/health" 
    "200"

# Veritabani baglantisi
run_test "Veritabani Baglanabilirlik" 
    "pg_isready -h db.sirket.com -p 5432" 
    "accepting connections"

# Cache servisi
run_test "Redis Baglantisi" 
    "redis-cli -h cache.sirket.com ping" 
    "PONG"

# DNS cozumlemesi
run_test "DNS Cozumlemesi" 
    "dig +short app.sirket.com" 
    "10."

# SSL sertifika gecerliligi
run_test "SSL Sertifika Kontrolu" 
    "echo | openssl s_client -connect app.sirket.com:443 2>/dev/null | openssl x509 -noout -dates" 
    "notAfter"

echo "" | tee -a $TEST_REPORT
echo "=== TEST SONUCLARI ===" | tee -a $TEST_REPORT
echo "Basarili: $PASS_COUNT" | tee -a $TEST_REPORT
echo "Basarisiz: $FAIL_COUNT" | tee -a $TEST_REPORT
echo "Toplam: $((PASS_COUNT + FAIL_COUNT))" | tee -a $TEST_REPORT

if [ $FAIL_COUNT -eq 0 ]; then
    echo "SONUC: TUM TESTLER GECTI - Sistem onaylanabilir" | tee -a $TEST_REPORT
    exit 0
else
    echo "SONUC: BAZI TESTLER BASARISIZ - Detaylar icin log incelenmelidir" | tee -a $TEST_REPORT
    exit 1
fi

RACI Matrisi Yerine: Sorumluluk Akışı

RACI matrisini tablo formatında vermek yerine, sorumluluk akışını senaryo bazında açıklamak daha pratik oluyor.

Senaryo: Veri Merkezi Enerji Kesintisi

  • DR Program Yöneticisi devreye alma kararını verir ve üst yönetime bilgi geçer
  • Teknik Lider failover’ın hangi sırayla yapılacağını belirler
  • Ağ Uzmanı DNS TTL değerlerini düşürür ve BGP yönlendirmesini günceller
  • Sunucu Uzmanı backup veri merkezindeki sistemleri hazır duruma getirir
  • Veritabanı Uzmanı replikasyonun son durumunu doğrular ve primary’i geçer
  • İletişim Koordinatörü kullanıcılara durum mesajı gönderir
  • Doğrulama Mühendisi sistemler ayağa kalktıktan sonra test suite’ini çalıştırır

Bu sıralama kritik çünkü herkesin ne zaman devreye gireceğini netleştiriyor.

Ekip Eğitimi ve Tatbikat Süreçleri

DR ekibi oluşturmak yeterli değil. Ekibin düzenli tatbikat yapması gerekiyor. Tatbikat türleri:

Masa Üstü Tatbikat (Tabletop Exercise): Gerçek sistem müdahalesi yok. Ekip bir araya gelir ve senaryo üzerinden konuşur. Ayda bir yapılması önerilir.

Fonksiyonel Tatbikat (Functional Drill): Belirli bir bileşen test edilir. Örneğin sadece veritabanı failover’ı. Çeyreklik yapılması idealdir.

Tam Ölçekli Tatbikat (Full-Scale Exercise): Tüm DR planı gerçek ortamda simüle edilir. Yılda bir yapılması minimum gereklilik.

Tatbikat sonuçlarını kayıt altına almak için basit bir log yapısı:

#!/bin/bash
# DR Tatbikat Kayit Scripti
# dr_drill_log.sh

DRILL_LOG_DIR="/var/log/dr_drills"
mkdir -p $DRILL_LOG_DIR

DRILL_TYPE=${1:-"tabletop"}
DRILL_LEADER=${2:-"belirtilmedi"}
TIMESTAMP=$(date +%Y%m%d_%H%M%S)
LOG_FILE="$DRILL_LOG_DIR/drill_${DRILL_TYPE}_${TIMESTAMP}.json"

# Tatbikat metriklerini hesapla
DETECTION_TIME=${3:-0}    # Dakika cinsinden algilama suresi
RESPONSE_TIME=${4:-0}     # Dakika cinsinden mudahale suresi
RECOVERY_TIME=${5:-0}     # Dakika cinsinden kurtarma suresi

cat > $LOG_FILE << EOF
{
    "drill_id": "DRILL-${TIMESTAMP}",
    "type": "$DRILL_TYPE",
    "leader": "$DRILL_LEADER",
    "date": "$(date -Iseconds)",
    "metrics": {
        "detection_time_min": $DETECTION_TIME,
        "response_time_min": $RESPONSE_TIME,
        "recovery_time_min": $RECOVERY_TIME,
        "total_duration_min": $((DETECTION_TIME + RESPONSE_TIME + RECOVERY_TIME))
    },
    "status": "tamamlandi"
}
EOF

echo "Tatbikat kaydi olusturuldu: $LOG_FILE"
echo "Toplam sure: $((DETECTION_TIME + RESPONSE_TIME + RECOVERY_TIME)) dakika"

# Onceki tatbikatlarla karsilastir
echo ""
echo "=== SON 5 TATBIKAT SURESI ==="
for f in $(ls -t $DRILL_LOG_DIR/*.json 2>/dev/null | head -5); do
    echo -n "$(grep 'drill_id' $f | cut -d'"' -f4): "
    grep 'total_duration_min' $f | awk '{print $2}' | tr -d ','
done

Rol Değişikliği ve Yedek Atama

Gerçek felaketler hafta sonu gece yarısı gelir. Birincil DR Program Yöneticisi tatildeyse ne olacak? Her rolün en az iki yedeği olmalı:

Birincil (Primary): Her zaman ilk aranacak kişi Birincil Yedek (Secondary): Birincil ulaşılamadığında devreye girer Üçüncül Yedek (Tertiary): Her ikisi de ulaşılamazsa son çare

Bu yedekleme listesi canlı tutulmalı ve iletişim bilgileri her üç ayda bir doğrulanmalı. Aşağıdaki script bunu otomatik kontrol edebilir:

#!/bin/bash
# DR Ekip Iletisim Dogrulama Scripti
# verify_contacts.sh

CONTACT_FILE="/etc/dr/team_contacts.conf"
REPORT_LOG="/var/log/dr_contact_verify.log"

if [ ! -f "$CONTACT_FILE" ]; then
    echo "HATA: Iletisim dosyasi bulunamadi: $CONTACT_FILE"
    exit 1
fi

echo "=== DR EKIP ILETISIM DOGRULAMA ===" | tee $REPORT_LOG
echo "Kontrol tarihi: $(date)" | tee -a $REPORT_LOG

while IFS=',' read -r role name phone email last_verified; do
    # Bos satirlari ve yorumlari atla
    [[ "$role" =~ ^#.*$ || -z "$role" ]] && continue
    
    # Son dogrulama tarihini kontrol et
    DAYS_SINCE=$(( ($(date +%s) - $(date -d "$last_verified" +%s 2>/dev/null || echo 0)) / 86400 ))
    
    if [ $DAYS_SINCE -gt 90 ]; then
        echo "[UYARI] $role - $name: $DAYS_SINCE gun once dogrulandi (Guncelleme gerekli)" | tee -a $REPORT_LOG
    else
        echo "[OK]    $role - $name: $DAYS_SINCE gun once dogrulandi" | tee -a $REPORT_LOG
    fi
done < "$CONTACT_FILE"

echo "" | tee -a $REPORT_LOG
echo "Dogrulama tamamlandi. Detaylar: $REPORT_LOG"

Yaygın Hatalar ve Kaçınma Yolları

Yıllar içinde gözlemlediğim en sık yapılan hatalar şunlar:

Tek kişiye bağımlılık: “Sadece Ahmet bey bu sistemi biliyor” durumu DR’ın en büyük düşmanı. Her kritik sistem için en az iki kişi bilgi sahibi olmalı.

Güncel olmayan runbook’lar: Altyapı değişiyor ama DR prosedürleri güncellenmiyor. Runbook’lar her altyapı değişikliğinde revize edilmeli.

Tatbikat yapmamak: Plan yazılı ama hiç test edilmemiş. Gerçek felaket anında planın işe yaraması garanti değil.

İletişim planı eksikliği: Teknik kurtarma yapılıyor ama müşteriler bilgilendirilmiyor. Bu durum teknik başarıyı iş başarısızlığına dönüştürebilir.

RTO/RPO hedeflerini bilmemek: DR ekibi üyeleri RTO ve RPO değerlerini bilmiyorsa neyi hedeflediklerini de bilmiyorlar demektir.

Sonuç

Felaket Kurtarma Ekibi, felaket anında bir arada tutulacak bir grup insan değil, önceden tanımlanmış roller ve sorumluluklar üzerine kurulu bir organizasyonel yapı. Her rolün net beklentileri, yetki sınırları ve yedek kişileri olmalı.

Teknik altyapınız ne kadar güçlü olursa olsun, arkasında koordineli çalışan bir insan ekibi olmadan DR planınız kağıt üzerinde kalır. Sunucular ne yapacağını bilir, yazılımlar ne yapacağını bilir; asıl soru insanların ne yapacağını bilip bilmediğidir.

Başlangıç için pratik adımlar şunlar:

  • Bu yazıdaki rol tanımlarını kendi organizasyonunuza uyarlayın
  • Her role birincil, ikincil ve üçüncül kişi atayın
  • Bir sonraki ayda en azından bir masa üstü tatbikat planlayın
  • İletişim listelerini güncelleyin ve 90 günde bir doğrulayın
  • Kurtarma scriptlerinizi belgelendirin ve ekiple paylaşın

DR ekibi kurmak bir kez yapılıp biten bir iş değil. Ekip değişiyor, sistemler değişiyor, tehdit ortamı değişiyor. Bu yapıyı canlı tutmak, teknik yapıyı canlı tutmak kadar önemli.

Bir yanıt yazın

E-posta adresiniz yayınlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir