İş Sürekliliği Planı Nasıl Hazırlanır?

Bir sabah işe geldiğinizde sunucuların ayakta olmadığını, veritabanının erişilemez durumda olduğunu ve müşterilerin telefonu başında beklediğini hayal edin. Bu senaryo her sysadmin’in kabusudur. Peki böyle bir anda ne yapacağınızı biliyor musunuz? İş Sürekliliği Planı (Business Continuity Plan – BCP) tam olarak bu sorunun cevabıdır. Panik yapmadan, sistematik biçimde hareket etmenizi sağlayan bu plan, felaket anında değil öncesinde hazırlanır. Bu yazıda gerçek dünya senaryolarıyla birlikte kapsamlı bir BCP nasıl hazırlanır, adım adım ele alacağız.

İş Sürekliliği Planı Nedir ve Neden Kritiktir?

İş Sürekliliği Planı, bir kuruluşun beklenmedik olaylar karşısında kritik operasyonlarını sürdürebilmesini ya da en kısa sürede normale dönebilmesini sağlayan belgelenmiş prosedürler bütünüdür. Felaket Kurtarma Planı (Disaster Recovery Plan – DRP) ile sık sık karıştırılır. Aradaki fark şudur: DRP teknik sistemlerin kurtarılmasına odaklanırken BCP tüm iş süreçlerini kapsar. DRP, BCP’nin bir alt bileşenidir.

Gerçek dünyadan bir örnek verelim. 2021 yılında Türkiye’de yaşanan büyük orman yangınları sırasında bazı veri merkezleri ciddi güç kesintisi yaşadı. Hazırlıklı olan şirketler birkaç saat içinde yedek sistemlerine geçti. Hazırlıksız olanlar günlerce kesinti yaşadı. Fark, planın varlığıydı.

Bir BCP’nin kapsadığı başlıca alanlar şunlardır:

İnsan kaynakları: Kilit personel yoksa kim devreye girer?
Teknik altyapı: Sunucular, ağ, depolama sistemleri nasıl kurtarılır?
İletişim: Müşteriler, çalışanlar ve yönetim nasıl bilgilendirilir?
Yasal yükümlülükler: Veri koruma ve raporlama gereksinimleri nasıl karşılanır?
Tedarik zinciri: Kritik satıcılar ve servis sağlayıcılar erişilemez olursa ne olur?

Temel Metrikler: RTO ve RPO

Her şeyden önce iki kritik metriği anlamanız gerekir.

RTO (Recovery Time Objective): Sistemin kesintiden sonra kabul edilebilir sürede yeniden çalışır hale gelmesi için hedeflenen maksimum süre. Örneğin “e-posta sistemi 4 saat içinde ayakta olmalı.”

RPO (Recovery Point Objective): Kabul edilebilir maksimum veri kaybı süresi. Örneğin “en fazla 1 saatlik veri kaybedebiliriz” diyorsanız yedekleriniz en az saatte bir alınmalıdır.

Bu değerleri belirlemek için şu bash betiğini kullanarak mevcut yedekleme sıklığınızı analiz edebilirsiniz:

#!/bin/bash
# Yedekleme geçmişini analiz et
BACKUP_DIR="/var/backups"
LOG_FILE="/var/log/backup_analysis.log"

echo "=== Yedekleme Frekans Analizi ===" > $LOG_FILE
echo "Tarih: $(date)" >> $LOG_FILE
echo "" >> $LOG_FILE

# Son 30 günün yedeklerini listele
find $BACKUP_DIR -name "*.tar.gz" -mtime -30 -exec ls -lh {} ; | 
  awk '{print $6, $7, $9}' | sort >> $LOG_FILE

# Yedekler arası süreyi hesapla
echo "" >> $LOG_FILE
echo "=== Yedekler Arası Maksimum Boşluk ===" >> $LOG_FILE
find $BACKUP_DIR -name "*.tar.gz" -mtime -30 -printf "%T@n" | 
  sort -n | awk 'NR>1{diff=$1-prev; if(diff>max) max=diff} {prev=$1} END{printf "Max gap: %.2f hoursn", max/3600}' >> $LOG_FILE

cat $LOG_FILE

Kritik Sistemlerin ve Süreçlerin Belirlenmesi

BCP hazırlamanın ilk adımı İş Etki Analizi (Business Impact Analysis – BIA) yapmaktır. Hangi sistemler durduğunda iş gerçekten durur? Bunu belirlemek için her departmanla görüşmeniz gerekir.

Teknik tarafta kritik sistemleri otomatik olarak tespit edip bir envanter çıkarmak için şu araçları kullanabilirsiniz:

#!/bin/bash
# Kritik servislerin anlık durumunu kaydet
SERVICES=("nginx" "mysql" "postgresql" "redis" "elasticsearch" "sshd")
REPORT_FILE="/etc/bcp/service_inventory_$(date +%Y%m%d).txt"

mkdir -p /etc/bcp

echo "=== Kritik Servis Envanteri ===" > $REPORT_FILE
echo "Oluşturulma: $(date)" >> $REPORT_FILE
echo "Hostname: $(hostname -f)" >> $REPORT_FILE
echo "" >> $REPORT_FILE

for service in "${SERVICES[@]}"; do
    STATUS=$(systemctl is-active $service 2>/dev/null || echo "not-installed")
    PID=$(systemctl show -p MainPID $service 2>/dev/null | cut -d= -f2)
    MEM=$(ps -p $PID -o rss= 2>/dev/null | awk '{printf "%.1f MB", $1/1024}')
    echo "Servis: $service | Durum: $STATUS | PID: $PID | Bellek: $MEM" >> $REPORT_FILE
done

echo "" >> $REPORT_FILE
echo "=== Disk Kullanimi ===" >> $REPORT_FILE
df -h | grep -v tmpfs >> $REPORT_FILE

echo "" >> $REPORT_FILE
echo "=== Aktif Network Baglantilari ===" >> $REPORT_FILE
ss -tulnp | grep LISTEN >> $REPORT_FILE

echo "Envanter raporu olusturuldu: $REPORT_FILE"

Bu komut dosyasını cron’a ekleyerek haftalık çalıştırın ve sisteminizin anlık görüntüsünü düzenli olarak alın. Bir felaket sonrasında “normal” duruma neyin karşılık geldiğini bilmek paha biçilmezdir.

Felaket Senaryolarının Belirlenmesi

Gerçekçi bir BCP hazırlamak için hangi felaket türleriyle karşılaşabileceğinizi belirlemeniz gerekir. Genel kategoriler şunlardır:

Doğal afetler: Deprem, sel, yangın, fırtına
Teknik arızalar: Disk çökmesi, güç kesintisi, ağ arızası, hardware failure
Siber saldırılar: Ransomware, DDoS, veri ihlali
İnsan hataları: Yanlış silme, hatalı konfigürasyon
Tedarikçi kesintileri: Bulut sağlayıcı outage, ISP arızası
Salgın veya kriz: Personelin uzaktan çalışması gerekebilir

Her senaryo için şu soruları yanıtlayın:

Olasılık: Bu senaryonun gerçekleşme ihtimali nedir?
Etki: Gerçekleşirse ne kadar süre ve hangi sistemler etkilenir?
Tespit: Bu durumu nasıl anlayacağız?
Müdahale: İlk 15 dakikada ne yapılacak?

Yedekleme Stratejisi ve Otomasyonu

Etkili bir BCP’nin omurgası sağlam bir yedekleme stratejisidir. 3-2-1 kuralı hala geçerliliğini korur: 3 kopya, 2 farklı medya, 1 uzak lokasyon.

Günlük yedekleme için kapsamlı bir betik:

#!/bin/bash
# BCP-uyumlu yedekleme betiği
# /etc/bcp/backup.sh

set -euo pipefail

# Konfigürasyon
BACKUP_DATE=$(date +%Y%m%d_%H%M%S)
LOCAL_BACKUP_DIR="/var/backups/daily"
REMOTE_BACKUP_HOST="backup.sirket.com"
REMOTE_BACKUP_DIR="/backups/$(hostname)"
RETENTION_DAYS=30
LOG_FILE="/var/log/bcp_backup.log"
ALERT_EMAIL="[email protected]"

# Kritik dizinler
BACKUP_PATHS=(
    "/etc"
    "/var/www"
    "/var/lib/mysql"
    "/home"
    "/opt/apps"
)

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

alert() {
    echo "$1" | mail -s "BCP ALERT: $(hostname) - $2" $ALERT_EMAIL
    log "ALERT gonderildi: $2"
}

# Yerel yedekleme
mkdir -p $LOCAL_BACKUP_DIR
BACKUP_FILE="$LOCAL_BACKUP_DIR/full_backup_$BACKUP_DATE.tar.gz"

log "Yedekleme basliyor: $BACKUP_FILE"

tar -czf $BACKUP_FILE 
    --exclude='/var/lib/mysql/*.pid' 
    --exclude='/var/lib/mysql/*.sock' 
    "${BACKUP_PATHS[@]}" 2>> $LOG_FILE

if [ $? -eq 0 ]; then
    log "Yerel yedekleme basarili: $(du -sh $BACKUP_FILE | cut -f1)"
    # MD5 checksum olustur
    md5sum $BACKUP_FILE > "${BACKUP_FILE}.md5"
else
    alert "Yerel yedekleme BASARISIZ!" "BACKUP_FAILURE"
    exit 1
fi

# Uzak konuma kopyala
rsync -avz --progress 
    $BACKUP_FILE 
    "${BACKUP_FILE}.md5" 
    ${REMOTE_BACKUP_HOST}:${REMOTE_BACKUP_DIR}/ 2>> $LOG_FILE

if [ $? -eq 0 ]; then
    log "Uzak yedekleme basarili"
else
    alert "Uzak yedekleme BASARISIZ! Yerel kopya mevcut." "REMOTE_BACKUP_FAILURE"
fi

# Eski yedekleri temizle
find $LOCAL_BACKUP_DIR -name "*.tar.gz" -mtime +$RETENTION_DAYS -delete
log "Eski yedekler temizlendi ($RETENTION_DAYS gundan eski)"

log "Yedekleme tamamlandi"

Yedek Doğrulama: Gerçek Sınavı

Yedekleme almak yeterli değil. Yedekten geri yükleme yapabildiğinizi düzenli olarak test etmelisiniz. Çoğu ekip bu adımı atlar ve felaket anında yedeklerinin bozuk olduğunu öğrenir.

#!/bin/bash
# Yedek dogrulama ve test geri yukleme betiği
# Her hafta cron ile calistirin

BACKUP_DIR="/var/backups/daily"
TEST_RESTORE_DIR="/tmp/backup_test_$(date +%Y%m%d)"
LOG_FILE="/var/log/backup_verification.log"
ALERT_EMAIL="[email protected]"

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

# En son yedeği bul
LATEST_BACKUP=$(ls -t $BACKUP_DIR/*.tar.gz 2>/dev/null | head -1)

if [ -z "$LATEST_BACKUP" ]; then
    echo "KRITIK: Hic yedek bulunamadi!" | mail -s "BCP: Yedek Bulunamadi" $ALERT_EMAIL
    exit 1
fi

log "Test edilecek yedek: $LATEST_BACKUP"

# MD5 dogrulama
CHECKSUM_FILE="${LATEST_BACKUP}.md5"
if [ -f "$CHECKSUM_FILE" ]; then
    if md5sum -c $CHECKSUM_FILE >> $LOG_FILE 2>&1; then
        log "MD5 dogrulama: BASARILI"
    else
        echo "KRITIK: MD5 dogrulama BASARISIZ - yedek bozuk olabilir!" | 
            mail -s "BCP: Yedek Bütunluk Hatasi" $ALERT_EMAIL
        exit 1
    fi
fi

# Test ortamında geri yükleme dene
mkdir -p $TEST_RESTORE_DIR
log "Test geri yukleme basliyor: $TEST_RESTORE_DIR"

tar -xzf $LATEST_BACKUP -C $TEST_RESTORE_DIR --strip-components=1 
    ./etc/nginx/nginx.conf 2>> $LOG_FILE

if [ $? -eq 0 ]; then
    log "Test geri yukleme: BASARILI"
    # Kritik dosyanin varlığını kontrol et
    if [ -f "$TEST_RESTORE_DIR/nginx.conf" ]; then
        log "Kritik konfigurasyon dosyasi dogrulandi"
    fi
else
    echo "KRITIK: Test geri yukleme BASARISIZ!" | 
        mail -s "BCP: Geri Yukleme Testi Basarisiz" $ALERT_EMAIL
fi

# Temizlik
rm -rf $TEST_RESTORE_DIR
log "Dogrulama tamamlandi"

İletişim Planı ve Eskalasyon Matrisi

Felaket anında “kim kimi arar” sorusunun cevabı önceden belirlenmiş olmalıdır. İletişim planı karmaşık belgelerden oluşmamalıdır. Hızla erişilebilir, basit bir yapıda olması kritiktir.

İletişim planında bulunması gerekenler:

Birinci kademe: İlk müdahale ekibi (on-call sysadmin, ekip lideri)
İkinci kademe: Departman müdürleri, CTO
Üçüncü kademe: Üst yönetim, iletişim departmanı, hukuk
Dış paydaşlar: İnternet servis sağlayıcı, bulut sağlayıcı destek, kritik yazılım satıcıları

Her kişi için şu bilgiler hazır olmalıdır: iş telefonu, kişisel telefon, e-posta, alternatif iletişim yöntemi.

Sistemin kendisi etkilendiğinde kullanabileceğiniz otomatik bildirim sistemi:

#!/bin/bash
# Felaket anı iletişim betiği
# Kritik sistem arızasında otomatik bildirim gonder

INCIDENT_ID="INC-$(date +%Y%m%d%H%M%S)"
SEVERITY=$1  # critical, high, medium
SYSTEM=$2    # etkilenen sistem adı
DESCRIPTION=$3

# Bildirim listesi (severity'e gore)
CRITICAL_CONTACTS="[email protected] [email protected]"
HIGH_CONTACTS="[email protected] [email protected]"
MEDIUM_CONTACTS="[email protected]"

# Slack webhook (önceden ayarlanmış)
SLACK_WEBHOOK="https://hooks.slack.com/services/YOUR/WEBHOOK/URL"

# E-posta bildirimi
send_email_alert() {
    local contacts=$1
    local subject="[$INCIDENT_ID] $SEVERITY - $SYSTEM Sistemi Etkilendi"
    local body="
Olay ID: $INCIDENT_ID
Zaman: $(date)
Siddet: $SEVERITY
Etkilenen Sistem: $SYSTEM
Aciklama: $DESCRIPTION
Hostname: $(hostname -f)
IP: $(hostname -I | awk '{print $1}')

BCP Proseduru icin: https://wiki.sirket.com/bcp/procedures
    "
    echo "$body" | mail -s "$subject" $contacts
}

# Slack bildirimi
send_slack_alert() {
    curl -s -X POST $SLACK_WEBHOOK 
        -H 'Content-type: application/json' 
        -d "{
            "text": ":rotating_light: *[$INCIDENT_ID] $SEVERITY ALERT*",
            "attachments": [{
                "color": "danger",
                "fields": [
                    {"title": "Sistem", "value": "$SYSTEM", "short": true},
                    {"title": "Zaman", "value": "$(date)", "short": true},
                    {"title": "Aciklama", "value": "$DESCRIPTION", "short": false}
                ]
            }]
        }" > /dev/null
}

case $SEVERITY in
    "critical")
        send_email_alert "$CRITICAL_CONTACTS"
        send_slack_alert
        # SMS servisi entegrasyonu (örneğin Twilio)
        ;;
    "high")
        send_email_alert "$HIGH_CONTACTS"
        send_slack_alert
        ;;
    "medium")
        send_email_alert "$MEDIUM_CONTACTS"
        ;;
esac

echo "Bildirimler gonderildi. Olay ID: $INCIDENT_ID"

Felaket Kurtarma Prosedürleri

Her kritik sistem için adım adım kurtarma prosedürü hazırlanmalıdır. Bu prosedürler stresin yoğun olduğu bir anda okunacağından net ve kısa olmalıdır.

Örneğin bir MySQL veritabanı kurtarma prosedürü:

#!/bin/bash
# MySQL Felaket Kurtarma Proseduru
# BCP-DB-001 - Versiyon 2.1
# Son Guncelleme: 2024-01-15
# Sorumlu: DBA Ekibi

set -euo pipefail

BACKUP_DIR="/var/backups/mysql"
MYSQL_DATA_DIR="/var/lib/mysql"
MYSQL_USER="root"
RESTORE_DATE=${1:-$(ls -t $BACKUP_DIR/*.sql.gz | head -1 | grep -o '[0-9]{8}')}
LOG_FILE="/var/log/mysql_recovery_$(date +%Y%m%d_%H%M%S).log"

log() { echo "[$(date '+%H:%M:%S')] $1" | tee -a $LOG_FILE; }

log "=== MySQL Kurtarma Proseduru Basliyor ==="
log "Hedef yedek tarihi: $RESTORE_DATE"

# Adim 1: MySQL servisini durdur
log "Adim 1: MySQL servisi durduruluyor..."
systemctl stop mysql
sleep 3

# Adim 2: Mevcut veri dizinini yedekle
log "Adim 2: Mevcut veri dizini yedekleniyor..."
mv $MYSQL_DATA_DIR "${MYSQL_DATA_DIR}_pre_recovery_$(date +%Y%m%d%H%M%S)"

# Adim 3: Yedek dosyasını bul
BACKUP_FILE=$(ls $BACKUP_DIR/*${RESTORE_DATE}*.sql.gz 2>/dev/null | head -1)
if [ -z "$BACKUP_FILE" ]; then
    log "HATA: $RESTORE_DATE tarihli yedek bulunamadi!"
    exit 1
fi
log "Kullanilacak yedek: $BACKUP_FILE"

# Adim 4: Veritabanini geri yukle
log "Adim 4: Veritabani geri yukleniyor (bu islem uzun surebilir)..."
mkdir -p $MYSQL_DATA_DIR
chown mysql:mysql $MYSQL_DATA_DIR

systemctl start mysql
sleep 5

zcat $BACKUP_FILE | mysql -u $MYSQL_USER 2>> $LOG_FILE
log "Geri yukleme tamamlandi"

# Adim 5: Dogrulama
log "Adim 5: Dogrulama yapiliyor..."
DB_COUNT=$(mysql -u $MYSQL_USER -e "SHOW DATABASES;" 2>/dev/null | wc -l)
log "Veritabani sayisi: $DB_COUNT"

log "=== Kurtarma Proseduru Tamamlandi ==="
log "Log dosyasi: $LOG_FILE"

Test Senaryoları ve Tatbikatlar

Plan hazırlamak yeterli değildir. Düzenli tatbikat yapmak zorundanız. Bir BCP hiç test edilmemişse işe yaramaz plan demektir.

Önerilen test takvimi şöyledir:

Masaüstü tatbikat (Tabletop Exercise): Ayda bir, senaryoları kağıt üzerinde tartışın. Katılımcılar: BT ekibi, departman yöneticileri. Süre: 2 saat.
Teknik kurtarma testi: Çeyreklik, gerçek ortamda yedekten geri yükleme yapın. Katılımcılar: Sysadmin ekibi. Süre: Yarım gün.
Tam tatbikat (Full Simulation): Yılda bir, gerçeğe yakın senaryo. Tüm paydaşların katılımı. Süre: Tam gün.

Her tatbikat sonrası şu sorulara yanıt aranmalıdır:

Ne iyi gitti? Planın çalışan kısımları teyit edildi mi?
Ne kötü gitti? Hangi adımlar başarısız oldu veya uzun sürdü?
Boşluklar neler? Hangi senaryolar plana dahil edilmemişti?
Güncellemeler: Plana ne eklenmeli veya değiştirilmeli?

Tatbikat sonuçlarını kayıt altına almak için sistematik bir yaklaşım şarttır. Test sonuçlarını otomatik raporlayan basit bir monitoring kontrolü:

#!/bin/bash
# BCP Test Metrikleri Toplayici
# Tatbikat sonrasi calistirin

TEST_DATE=$(date +%Y%m%d_%H%M%S)
REPORT_DIR="/etc/bcp/test_reports"
REPORT_FILE="$REPORT_DIR/test_$TEST_DATE.txt"

mkdir -p $REPORT_DIR

echo "=== BCP Tatbikat Raporu ===" > $REPORT_FILE
echo "Tarih: $(date)" >> $REPORT_FILE
echo "Test Yapan: $(whoami)@$(hostname)" >> $REPORT_FILE
echo "" >> $REPORT_FILE

# RTO Olcumu - Servis baslatma suresi
echo "=== RTO Olcumu ===" >> $REPORT_FILE
start_time=$(date +%s%N)

# Test servisi yeniden baslat
systemctl restart nginx 2>/dev/null
sleep 2

# Servisin ayaga kalkmasini bekle
timeout 300 bash -c 'until systemctl is-active nginx > /dev/null 2>&1; do sleep 1; done'

end_time=$(date +%s%N)
elapsed_ms=$(( (end_time - start_time) / 1000000 ))
echo "nginx restart suresi: ${elapsed_ms}ms" >> $REPORT_FILE

# Yedek boyutu ve sikligi
echo "" >> $REPORT_FILE
echo "=== Yedekleme Metrikleri ===" >> $REPORT_FILE
LATEST_BACKUP=$(ls -t /var/backups/daily/*.tar.gz 2>/dev/null | head -1)
if [ -n "$LATEST_BACKUP" ]; then
    echo "Son yedek: $(stat -c %y $LATEST_BACKUP | cut -d. -f1)" >> $REPORT_FILE
    echo "Boyut: $(du -sh $LATEST_BACKUP | cut -f1)" >> $REPORT_FILE
    
    # Son yedekten bu yana gecen sure (RPO kontrolu)
    BACKUP_AGE=$(( ($(date +%s) - $(stat -c %Y $LATEST_BACKUP)) / 3600 ))
    echo "Yedek yasi: ${BACKUP_AGE} saat" >> $REPORT_FILE
    
    if [ $BACKUP_AGE -gt 25 ]; then
        echo "UYARI: Son yedek 25 saatten eski - RPO ihlali riski!" >> $REPORT_FILE
    fi
fi

echo "" >> $REPORT_FILE
echo "Rapor tamamlandi: $REPORT_FILE"
cat $REPORT_FILE

Planın Yaşatılması ve Sürekli Güncellenmesi

BCP hazırlandıktan sonra rafa kaldırılırsa değer taşımaz. Planın canlı tutulması için şu pratikleri benimseyin:

Her sistem değişikliğinde güncelleyin: Yeni sunucu eklendiğinde, uygulama değiştiğinde BCP otomatik olarak gündeme gelmelidir. Bunun için değişiklik yönetim sürecinize BCP güncelleme adımını ekleyin.

Yıllık gözden geçirme toplantısı: Tüm departman yöneticilerinin katıldığı yıllık bir toplantıyla planı baştan sona inceleyin. İş gereksinimleri değişmiş olabilir.

Versiyon kontrolü kullanın: BCP dökümanlarını Git ile yönetin. Kim neyi ne zaman değiştirdi, tarihçe takibi yapın.

Kolay erişilebilir tutun: Plan sadece bir sunucuda değil, bulut depolama, fiziksel baskı ve yetkili kişilerin kişisel cihazlarında da bulunmalıdır. Felaket sırasında sunucuya erişemeyebilirsiniz.

Personel değişimini takip edin: İletişim listesindeki kişiler şirketten ayrılmış olabilir. Çeyreklik olarak iletişim bilgilerini doğrulayın.

Yasal gereksinimleri takip edin: KVKK, GDPR ve sektörel düzenlemeler BCP gereksinimlerini etkileyebilir. Uyumluluk ekibiyle koordineli çalışın.

Gerçek Dünya Senaryosu: Ransomware Saldırısı

Bir müşterimizin yaşadığı gerçek bir olaydan ilham alarak tasarladığım bu senaryo, planın önemini somutlaştırıyor.

Cuma akşamı saat 23:00’da monitoring sisteminden uyarı geldi: sunucudaki bir çok dosyanın uzantısı değişmiş, disk I/O anormal derecede yüksek. Klasik ransomware belirtileri.

Planlı müdahale adımları şöyle işledi:

0-5. dakika: On-call sysadmin alarmı aldı, ilk triage yaptı ve incident ID oluşturdu
5-15. dakika: Etkilenen sistemleri ağdan izole etti, yayılmayı durdurdu
15-30. dakika: Ekip liderini ve CTO’yu aradı, iletişim planı devreye girdi
30-60. dakika: Temiz yedek doğrulandı, yedek sistemlere geçiş başladı
2. saat: Kritik sistemler yedekten geri yüklendi, iş süreci kısmen devam etti
4. saat: Tüm kritik sistemler çalışır durumda, forensic analiz başladı

Bu kadar hızlı müdahale edilebilmesinin nedeni şuydu: her adım önceden yazılı olarak belirlenmişti. Felaket anında kimse “ne yapacağız” diye sormadı.

Aynı şirketin bir yıl önceki benzer olayda planı yoktu ve 3 günlük kesinti yaşandı. Fark ortada.

Sonuç

İş Sürekliliği Planı hazırlamak bir defaya mahsus yapılan bir proje değil, sürekli bir süreçtir. Bugün başlamanın en iyi zamanıdır; çünkü felaket ne zaman geleceğini söylemez.

Özetlemek gerekirse temel adımlar şunlardır:

RTO ve RPO metriklerinizi belirleyin, iş birimlerinin kabul edebileceği değerleri netleştirin
Kritik sistemleri ve süreçleri dokümante edin, BIA yapın
3-2-1 yedekleme stratejisini uygulayın ve yedeklerinizi düzenli test edin
Her felaket senaryosu için adım adım kurtarma prosedürü yazın
İletişim planını ve eskalasyon matrisini hazır tutun
Düzenli tatbikatlar yapın ve sonuçları kayıt altına alın
Planı yaşayan bir belge olarak sürekli güncelleyin

Bir sysadmin olarak yıllarca edindiğim en önemli ders şudur: en iyi felaket kurtarma planı, hiç kullanmak zorunda kalmadığınız ama kullanmak durumunda kaldığınızda kusursuz çalışan plandır. Bu dengeyi kurmak zaman ve emek ister. Ama o kritik anda paha biçilemez.

Herkese kesintisiz sistemler dilerim.

İş Sürekliliği Planı Hazırlama Rehberi