Felaket Kurtarma Planı Dokümantasyonu Nasıl Yazılır

Tarafındankomut
0 Comments

Yıllarca sistem yöneticiliği yaptıktan sonra şunu fark ettim: Felaket kurtarma planı olmayan bir şirket, emniyet kemeri takmadan araba kullanan biri gibidir. Belki hiçbir zaman kaza yapmaz, ama yaparsa sonuçları çok ağır olur. Bu yazıda sıfırdan gerçekçi ve işe yarayan bir felaket kurtarma planı (Disaster Recovery Plan – DRP) dokümantasyonunun nasıl hazırlanacağını anlatacağım.

Felaket Kurtarma Planı Nedir ve Neden Önemlidir

Felaket kurtarma planı, bir organizasyonun kritik sistemlerini ve verilerini beklenmedik bir olay sonrasında nasıl geri getireceğini tanımlayan belgedir. Bu belgeler sadece büyük şirketler için değil, 10 kişilik bir ekibin bile ihtiyaç duyduğu pratik dokümanlar olmalıdır.

Gerçek bir örnek vereyim: Tanıdığım bir e-ticaret şirketinde gece 2’de ana veritabanı sunucusu çöktü. Nöbetçi sistem yöneticisi panikle doğru sunucuya bağlanamadı, yanlış backup’ı restore etmeye çalıştı ve 4 saatlik veri kaybına yol açtı. Eğer elimde düzgün bir DRP belgesi olsaydı, o gece 20 dakikada çözülmesi gereken sorun 6 saatte çözüldü. Para kaybı, itibar kaybı, uykusuz geceler…

Temel Kavramları Belgeye Ekleyin

DRP yazarken herkesin aynı dili konuşması gerekir. Belgenizin başına mutlaka şu metrikleri ve tanımları ekleyin:

RTO (Recovery Time Objective): Sistemin kabul edilebilir maksimum kesinti süresi. “E-ticaret sistemimiz maksimum 2 saat offline kalabilir” gibi.

RPO (Recovery Point Objective): Kabul edilebilir maksimum veri kaybı süresi. “Son 4 saatlik veriyi kaybedebiliriz” anlamına gelir.

MTTR (Mean Time to Repair): Ortalama onarım süresi.

Kritik Sistem: İş süreçlerini doğrudan etkileyen, durması halinde gelir kaybına neden olan sistem.

Tier 1 Sistem: 0-1 saat içinde kurtarılması gereken sistemler.

Tier 2 Sistem: 1-8 saat içinde kurtarılması gereken sistemler.

Tier 3 Sistem: 8-24 saat içinde kurtarılması gereken sistemler.

Envanter ve Sistem Haritası

Hiçbir DRP, sistemlerin tam listesi olmadan işe yaramaz. Aşağıdaki script ile mevcut sistemlerinizin temel envanterini çıkarabilirsiniz:

#!/bin/bash
# Sistem envanteri çıkarma scripti
RAPOR_DOSYA="/opt/drp/sistem_envanteri_$(date +%Y%m%d).txt"

echo "=== SISTEM ENVANTERI ===" > $RAPOR_DOSYA
echo "Tarih: $(date)" >> $RAPOR_DOSYA
echo "" >> $RAPOR_DOSYA

# Hostname ve OS bilgisi
echo "--- SUNUCU BILGILERI ---" >> $RAPOR_DOSYA
echo "Hostname: $(hostname)" >> $RAPOR_DOSYA
echo "OS: $(cat /etc/os-release | grep PRETTY_NAME | cut -d= -f2)" >> $RAPOR_DOSYA
echo "Kernel: $(uname -r)" >> $RAPOR_DOSYA
echo "Uptime: $(uptime -p)" >> $RAPOR_DOSYA

# Disk durumu
echo "" >> $RAPOR_DOSYA
echo "--- DISK DURUMU ---" >> $RAPOR_DOSYA
df -h >> $RAPOR_DOSYA

# Çalışan servisler
echo "" >> $RAPOR_DOSYA
echo "--- KRITIK SERVISLER ---" >> $RAPOR_DOSYA
systemctl list-units --type=service --state=running >> $RAPOR_DOSYA

# Network konfigürasyonu
echo "" >> $RAPOR_DOSYA
echo "--- NETWORK BILGILERI ---" >> $RAPOR_DOSYA
ip addr show >> $RAPOR_DOSYA

echo "Rapor kaydedildi: $RAPOR_DOSYA"

Bu scripti cron’a ekleyerek haftalık otomatik envanter tutabilirsiniz. Ama asıl önemli olan bu çıktıyı DRP belgenize bağlamak ve güncel tutmaktır.

DRP Belge Yapısı

İyi bir DRP belgesi şu bölümlerden oluşmalıdır:

Bölüm 1 – Giriş ve Kapsam

  • Belgenin amacı
  • Kapsadığı sistemler
  • Kapsam dışı sistemler
  • Belge sahibi ve son güncelleme tarihi

Bölüm 2 – Risk Analizi

  • Olası felaket senaryoları
  • Her senaryonun olasılık ve etki değerlendirmesi
  • Öncelik sıralaması

Bölüm 3 – İletişim Planı

  • Kimin kimi arayacağı (call tree)
  • Acil durum iletişim listesi
  • Müşteri/paydaş bildirim prosedürleri

Bölüm 4 – Kurtarma Prosedürleri

  • Her sistem için adım adım kurtarma talimatları
  • Gerekli araçlar ve erişim bilgileri
  • Doğrulama kontrol listeleri

Bölüm 5 – Test Planı

  • Yıllık test takvimi
  • Test senaryoları
  • Başarı kriterleri

Bölüm 6 – Bakım ve Güncelleme

  • Belge güncelleme takvimi
  • Değişiklik yönetimi prosedürü

İletişim Planı ve Call Tree

Felaket anında iletişim karmaşıklığı, kurtarma sürenizi ikiye katlar. Basit ama etkili bir iletişim scripti:

#!/bin/bash
# Acil durum bildirim scripti
# /opt/drp/notify_team.sh

OLAY_TURU=$1
SUNUCU_ADI=$2
ACIKLAMА=$3

# Slack webhook ile bildirim
SLACK_WEBHOOK="https://hooks.slack.com/services/XXXXX/YYYYY/ZZZZZ"

curl -X POST -H 'Content-type: application/json' 
  --data "{
    "channel": "#sysadmin-alerts",
    "username": "DRP-Bot",
    "icon_emoji": ":fire:",
    "text": "*FELAKET UYARISI*nOlay: ${OLAY_TURU}nSunucu: ${SUNUCU_ADI}nAçıklama: ${ACIKLAMА}nZaman: $(date)nNöbetçi: $(cat /opt/drp/nobetci.txt)"
  }" 
  $SLACK_WEBHOOK

# Aynı zamanda e-posta gönder
echo "Olay: ${OLAY_TURU} | Sunucu: ${SUNUCU_ADI} | ${ACIKLAMА}" | 
  mail -s "[DRP ALERT] Kritik Sistem Sorunu - $(date +%Y%m%d-%H%M)" 
  [email protected]

Belgenizde iletişim hiyerarşisi net olmalıdır:

  • Seviye 1 (0-15 dakika): Nöbetçi sistem yöneticisi sorunu tespit eder ve değerlendirir
  • Seviye 2 (15-30 dakika): Sorun Tier 1 kategorisindeyse Altyapı Yöneticisi aranır
  • Seviye 3 (30-60 dakika): IT Direktörü ve ilgili departman yöneticileri bilgilendirilir
  • Seviye 4 (60+ dakika): CTO ve CEO’ya durum raporu sunulur

Kurtarma Prosedürlerini Nasıl Yazmalısınız

Bu bölüm DRP’nin kalbidir. Kurtarma prosedürü yazarken altın kural şudur: O prosedürü hiç görmemiş bir junior sysadmin, belgeyi takip ederek sistemi geri getirebilmeli.

Pratik bir PostgreSQL veritabanı kurtarma prosedürü örneği:

#!/bin/bash
# PostgreSQL Felaket Kurtarma Prosedürü
# Versiyon: 1.2
# Son Güncelleme: 2024-01-15
# Sorumlu: Ali Yilmaz ([email protected])

# ADIM 1: Durumu doğrula
echo "[ADIM 1] Mevcut durumu kontrol ediliyor..."
systemctl status postgresql
pg_isready -h localhost -p 5432

# Eğer servis çalışmıyorsa devam et
if ! pg_isready -h localhost -p 5432 -q; then
  echo "PostgreSQL çalışmıyor. Kurtarma prosedürü başlatılıyor..."
fi

# ADIM 2: Son backup'ı bul
echo "[ADIM 2] En son backup aranıyor..."
BACKUP_DIR="/backup/postgresql"
SON_BACKUP=$(ls -t $BACKUP_DIR/*.tar.gz 2>/dev/null | head -1)

if [ -z "$SON_BACKUP" ]; then
  echo "HATA: Backup bulunamadı! Manuel kontrol gerekli."
  echo "Backup konumu: $BACKUP_DIR"
  exit 1
fi

echo "Kullanılacak backup: $SON_BACKUP"
echo "Backup tarihi: $(stat -c %y $SON_BACKUP)"

# ADIM 3: Onay al
read -p "Bu backup'ı restore etmek istiyor musunuz? (evet/hayir): " ONAY
if [ "$ONAY" != "evet" ]; then
  echo "İşlem iptal edildi."
  exit 0
fi

# ADIM 4: Mevcut veriyi yedekle (güvenlik önlemi)
echo "[ADIM 4] Mevcut bozuk veri yedekleniyor..."
BOZUK_BACKUP="/backup/bozuk_veri_$(date +%Y%m%d_%H%M%S)"
cp -r /var/lib/postgresql/14/main $BOZUK_BACKUP
echo "Bozuk veri kaydedildi: $BOZUK_BACKUP"

# ADIM 5: Restore işlemi
echo "[ADIM 5] Restore başlatılıyor..."
systemctl stop postgresql
rm -rf /var/lib/postgresql/14/main
tar -xzf $SON_BACKUP -C /var/lib/postgresql/14/
chown -R postgres:postgres /var/lib/postgresql/14/main

# ADIM 6: Servisi başlat ve doğrula
echo "[ADIM 6] PostgreSQL başlatılıyor..."
systemctl start postgresql
sleep 5

if pg_isready -h localhost -p 5432; then
  echo "BASARI: PostgreSQL başarıyla restore edildi!"
  echo "Restore edilen backup: $SON_BACKUP"
else
  echo "HATA: PostgreSQL başlatılamadı. Log kontrol edin:"
  echo "journalctl -u postgresql -n 50"
  exit 1
fi

Her kurtarma prosedürünün sonunda mutlaka bir doğrulama kontrol listesi olmalıdır:

  • Servis çalışıyor mu kontrol edildi mi?
  • Kritik tablolara sorgu atıldı mı?
  • Uygulama servisi yeniden başlatıldı mı?
  • Monitoring uyarıları temizlendi mi?
  • Olay kaydı (incident log) oluşturuldu mu?

Backup Durumu Monitöring Scripti

Belgenizde backup sisteminin sağlıklı çalıştığını doğrulayan otomatik kontroller olmalıdır:

#!/bin/bash
# Backup sağlık kontrol scripti
# Her sabah 08:00'de çalışır

BACKUP_DIZINLERI=(
  "/backup/postgresql"
  "/backup/web_dosyalar"
  "/backup/sistem_konfigurasyonu"
)

UYARI_SAATI=24  # Kaç saatten eski backup uyarı versin
HATALI_BACKUP=0

for DIZIN in "${BACKUP_DIZINLERI[@]}"; do
  if [ ! -d "$DIZIN" ]; then
    echo "HATA: $DIZIN dizini bulunamadı!"
    HATALI_BACKUP=1
    continue
  fi

  SON_BACKUP=$(ls -t $DIZIN/*.tar.gz 2>/dev/null | head -1)
  
  if [ -z "$SON_BACKUP" ]; then
    echo "UYARI: $DIZIN dizininde backup dosyası yok!"
    HATALI_BACKUP=1
    continue
  fi

  # Son backup'ın yaşını hesapla (saat cinsinden)
  BACKUP_YASI=$(( ($(date +%s) - $(stat -c %Y $SON_BACKUP)) / 3600 ))

  if [ $BACKUP_YASI -gt $UYARI_SAATI ]; then
    echo "UYARI: $DIZIN son backup $BACKUP_YASI saat önce alındı!"
    HATALI_BACKUP=1
  else
    echo "OK: $DIZIN - Son backup $BACKUP_YASI saat önce. Dosya: $(basename $SON_BACKUP)"
  fi
done

if [ $HATALI_BACKUP -eq 1 ]; then
  echo "" | mail -s "[KRITIK] Backup Sorunları Tespit Edildi" [email protected]
  exit 1
fi

echo "Tüm backup'lar sağlıklı."

Test Senaryoları ve DRP Tatbikatı

Yazılmış ama hiç test edilmemiş bir DRP, hiç yoktan daha tehlikelidir. Çünkü insanlara yanlış bir güven hissi verir. Yılda en az iki kez tatbikat yapın.

Tatbikat türleri şunlardır:

Masabaşı Tatbikatı (Tabletop Exercise): Ekip bir araya gelir ve “senaryo şu, ne yaparsınız?” diye tartışılır. En az zahmetli test türüdür, yeni başlamak için idealdir.

Teknik Tatbikat: Gerçek sistemler üzerinde, ama kontrollü ortamda kurtarma prosedürleri uygulanır. Test ortamında yapılır.

Tam Tatbikat: Production benzeri ortamda, gerçek backup’lar restore edilir. En değerli ama en riskli test türüdür.

#!/bin/bash
# DRP Test otomasyonu - Tatbikat scripti
# Bu script test ortamında çalıştırılmalıdır!

ORTAM=$(hostname | grep -c "test|staging")
if [ $ORTAM -eq 0 ]; then
  echo "DIKKAT: Bu script sadece test/staging ortamında çalışır!"
  echo "Production'da çalıştırmak için kodu manuel inceleyin."
  exit 1
fi

TATBIKAT_LOG="/var/log/drp_tatbikat_$(date +%Y%m%d_%H%M%S).log"
BASLANGIC_ZAMANI=$(date +%s)

echo "=== DRP TATBIKAT BASLIYOR ===" | tee $TATBIKAT_LOG
echo "Tarih: $(date)" | tee -a $TATBIKAT_LOG
echo "Test ortamı: $(hostname)" | tee -a $TATBIKAT_LOG
echo "" | tee -a $TATBIKAT_LOG

# Test 1: Backup erişilebilirlik kontrolü
echo "[TEST 1] Backup erişilebilirlik..." | tee -a $TATBIKAT_LOG
if ls /backup/postgresql/*.tar.gz > /dev/null 2>&1; then
  echo "GECTI: Backup dosyaları erişilebilir" | tee -a $TATBIKAT_LOG
else
  echo "BASARISIZ: Backup dosyalarına erişilemiyor!" | tee -a $TATBIKAT_LOG
fi

# Test 2: Restore süresi ölçümü
echo "[TEST 2] Restore süresi ölçülüyor..." | tee -a $TATBIKAT_LOG
RESTORE_BASLANGIC=$(date +%s)
# ... restore işlemleri ...
RESTORE_BITIS=$(date +%s)
RESTORE_SURESI=$((RESTORE_BITIS - RESTORE_BASLANGIC))
echo "Restore süresi: $RESTORE_SURESI saniye" | tee -a $TATBIKAT_LOG

# RTO kontrolü (örnek: 7200 saniye = 2 saat)
if [ $RESTORE_SURESI -lt 7200 ]; then
  echo "GECTI: RTO hedefi karşılandı" | tee -a $TATBIKAT_LOG
else
  echo "BASARISIZ: RTO hedefi aşıldı! Hedef: 7200s, Gerçek: ${RESTORE_SURESI}s" | tee -a $TATBIKAT_LOG
fi

BITIS_ZAMANI=$(date +%s)
TOPLAM_SURE=$((BITIS_ZAMANI - BASLANGIC_ZAMANI))
echo "" | tee -a $TATBIKAT_LOG
echo "=== TATBIKAT TAMAMLANDI ===" | tee -a $TATBIKAT_LOG
echo "Toplam süre: $TOPLAM_SURE saniye" | tee -a $TATBIKAT_LOG
echo "Tatbikat raporu: $TATBIKAT_LOG"

Olay Kaydı Tutma

Her gerçek olay veya tatbikat sonrasında ayrıntılı olay kaydı tutun. Bu kayıtlar hem DRP belgenizin güncellenmesine hem de gelecekteki incelemelere kaynaklık eder.

#!/bin/bash
# Basit olay kaydı oluşturma
# Kullanım: ./incident_log.sh "Veritabanı kesintisi" "PostgreSQL servisi çöktü"

OLAY_BASLIK=$1
OLAY_ACIKLAMA=$2
KAYIT_DOSYA="/var/log/drp_olaylar.log"

TIMESTAMP=$(date '+%Y-%m-%d %H:%M:%S')
KULLANICI=$(whoami)

echo "---" >> $KAYIT_DOSYA
echo "Zaman: $TIMESTAMP" >> $KAYIT_DOSYA
echo "Kullanıcı: $KULLANICI" >> $KAYIT_DOSYA
echo "Başlık: $OLAY_BASLIK" >> $KAYIT_DOSYA
echo "Açıklama: $OLAY_ACIKLAMA" >> $KAYIT_DOSYA
echo "Sunucu: $(hostname)" >> $KAYIT_DOSYA
echo "---" >> $KAYIT_DOSYA

echo "Olay kaydı oluşturuldu: $TIMESTAMP - $OLAY_BASLIK"

DRP Belgesinin Güncellenmesi

Bir DRP belgesi yazıldıktan sonra rafta bekleyen bir dosya haline geliyorsa, değeri yoktur. Güncelleme için şu tetikleyicileri kullanın:

  • Her büyük altyapı değişikliğinden sonra (yeni sunucu ekleme, yazılım yükseltme)
  • Her gerçek olaydan sonra (olaydan öğrenilenler bölümü ekle)
  • Her yıl en az bir kez periyodik revizyon
  • Organizasyonel değişiklikler sonrasında (yeni ekip üyeleri, rol değişiklikleri)
  • Üçüncü taraf hizmet sağlayıcı değişikliklerinde

Belge versiyonlamasını Git ile yapabilirsiniz. DRP belgelerini Git’e almak hem değişiklik geçmişini tutar hem de birden fazla kişinin katkısını kolaylaştırır:

#!/bin/bash
# DRP belge güncelleme scripti

DRP_REPO="/opt/drp-docs"
VERSIYON_DOSYA="$DRP_REPO/VERSION"

# Mevcut versiyonu oku
MEVCUT_VER=$(cat $VERSIYON_DOSYA 2>/dev/null || echo "1.0.0")

# Patch versiyonunu artır
YENI_VER=$(echo $MEVCUT_VER | awk -F. '{$NF+=1; print}' OFS=.)

echo $YENI_VER > $VERSIYON_DOSYA

cd $DRP_REPO
git add -A
git commit -m "DRP Güncelleme v${YENI_VER} - $(date '+%Y-%m-%d') - $USER tarafından"
git push origin main

echo "DRP belgesi v${YENI_VER} olarak güncellendi ve commit edildi."

Sık Yapılan Hatalar

Yıllar içinde gördüğüm en yaygın DRP hatalarını burada paylaşmak istiyorum:

Erişim bilgilerini belgede saklamak: Parolaları veya SSH anahtarlarını DRP belgesine yazmayin. Bir parola kasası (Vault, Bitwarden Teams) kullanın ve belgede sadece “Parola: vault.sirket.com/drp/db-admin” şeklinde referans verin.

Sadece lead engineer’in anlayacağı belgeler yazmak: Her adımı açık ve anlaşılır yazın. “DB’yi restore et” yazmak yetmez, komutları ve parametreleri tek tek gösterin.

Backup’ları test etmemek: Backup aldığınızı sanıyorsunuz ama restore edip test etmiyorsunuz. Ayda en az bir kez rastgele bir backup’ı test ortamında restore edin.

İletişim planını güncel tutmamak: Çalışan işten ayrıldı, telefon numarası değişti ama iletişim listesi güncellenmedi. Bu durumda kriz anında kimi arayacaksınız?

Sadece teknik ekibi dahil etmek: DRP, sadece IT’nin sorunu değil. İK, muhasebe, satış gibi departmanlar da kendi iş süreçlerini belgelemelidir.

Sonuç

Felaket kurtarma planı dokümantasyonu, en iyi ihtimalle hiç kullanmayacağınız ama yazdığınıza her zaman değer duyacağınız bir belgedir. Mükemmel bir belge oluşturmaya çalışmayın, işe yarayan bir belge oluşturmaya odaklanın.

Küçük başlayın: Bu hafta en kritik sisteminiz için tek sayfalık bir kurtarma prosedürü yazın. Sonra onu bir test ortamında deneyin. Ardından genişletin. Bir sonraki haftaya bir şey daha ekleyin. Altı ay sonra dönüp baktığınızda elinizde gerçek bir DRP olduğunu göreceksiniz.

Unutmayın, gece 2’de panik yaparken doğru kararlar vermek son derece zordur. Ama elinizde adım adım bir prosedür belgesi varsa, o gece sadece bir scripti çalıştırmak ve listeyi takip etmek kalır. Ekibinizin ve şirketinizin güvenliği için bu zahmete değer.

Son bir not: Bu belgeyi yazıp bitirdikten sonra en az iki kişiyle paylaşın ve “Bu belgeyi kullanarak sistemi kurtarabilir misin?” diye sorun. Alacağınız geri bildirim, belgenizi gerçekten değerli kılacaktır.

Bir yanıt yazın

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