Felaket Kurtarma Runbook’u Nasıl Hazırlanır? Teknik Şablon

Gece 02:00’de depolama dizisi düştüğünde strateji belgesi kimseyi kurtarmaz. Eksik kadroyla, stres altında çalışan sistem yöneticisinin hangi sunucuyu hangi sırayla, hangi komutla açacağını ve işin bittiğini nasıl anlayacağını bilmesi gerekir. Runbook bu boşluğu dolduran teknik uygulama dokümanıdır. Aşağıda bir DR runbook’unun bölümlerini, geri dönüş sırasını, adım şablonunu ve dokümanı canlı tutan döngüyü örnek bir bölümle birlikte veriyoruz.

Runbook ile iş sürekliliği planının farkı

İş sürekliliği planı (BCP) “ne kadar sürede, hangi iş fonksiyonları, kimin kararıyla” sorularını yanıtlar; kriz yönetimi, iletişim ve alternatif çalışma düzenlemelerini içerir. Bu yönetim düzeyi yapı iş sürekliliği planının içeriği yazısında anlatılıyor. Runbook ise BCP’nin teknik kurtarma bölümünün sahadaki karşılığıdır: komut, ekran, parametre, beklenen çıktı ve sorumlu kişi düzeyinde yazılır.

İyi bir runbook’un basit bir testi var: sistem altyapısını tanıyan ama o sistemi hiç kurmamış bir ekip üyesi dokümanı tek başına uygulayabiliyor mu? Bir adım “gerekli yapılandırmayı yapın” diyorsa o runbook değil, hatırlatma notudur. Sahada en sık gördüğümüz runbook’lar tam olarak böyle: yazanın kafasındaki bilgiye dayanır, yazan izindeyse işe yaramaz.

Runbook’un bölümleri

Runbook tek ve uzun bir belge olmak zorunda değil. Ana belge artı sistem bazlı ekler şeklinde düzenlemek güncellemeyi kolaylaştırır. Ana belgede şu bölümler bulunur:

1. Kapsam ve sürüm: Hangi sistemleri kapsadığı, son güncelleme tarihi, son tatbikat tarihi, sürüm geçmişi.
2. Tetikleme kriterleri: Runbook’un hangi durumda devreye alındığı ve bu kararı kimin verdiği. Örnek: “Birincil veri merkezindeki depolama dizisine 60 dakikadır erişilemiyor ve üretici destek kaydı onarım süresini 4 saatin üzerinde öngörüyor.” Belirsiz ölçüt karar gecikmesi doğurur; kesintinin en pahalı dakikaları çoğu zaman “bekleyelim mi, geçelim mi” tartışmasında harcanır.
3. Senaryo seçimi: Tek sunucu kaybı, depolama kaybı, site kaybı ve fidye yazılımı farklı yollar izler. Fidye senaryosunda temiz kurtarma noktası seçilmeden geri yüklemeye başlanmaz.
4. Roller ve iletişim: Kurtarma koordinatörü; sistem, ağ, veritabanı ve uygulama sorumluları; her biri için yedek kişi ve iletişim kanalı. E-posta sunucusu çalışmıyorsa nasıl haberleşileceği de yazılı olmalı.
5. Geri dönüş sırası: Bağımlılık haritası ve dalga planı.
6. Sistem ekleri: Her sistem için adım adım kurtarma prosedürü.
7. Kapanış: Kullanıcılara açılış kararı, failback planı, olay sonrası değerlendirme.

Geri dönüş sırası ve bağımlılıklar

Sistemler iş önceliğine göre değil, teknik bağımlılığa göre açılır. ERP iş açısından en önemli sistem olabilir; ama kimlik doğrulama ve veritabanı ayakta değilken ERP’yi açmak hiçbir şey kazandırmaz. Tipik bir dalga planı:

Bağımlılık haritasını çıkarırken gizli bağımlılıkları arayın: lisans sunucusu, zaman senkronizasyonu (NTP), sertifika iptal listesine erişim, SMTP rölesi, entegrasyonun kullandığı servis hesabı, uygulama yapılandırmasına gömülmüş IP adresleri. Bunlar çoğunlukla ilk tatbikatta ortaya çıkar. Kâğıtta görünmezler. Sistemlerin hangi RTO kademesinde olduğu ve buna uygun teknoloji seçimi için RPO/RTO hedefine göre teknoloji seçimi yazısına bakın.

Adım şablonu: komut, doğrulama, sorumlu

Sistem eklerindeki her adım aynı alanları taşımalı:

• Adım no ve başlık: Kısa, emir kipiyle (“DC01’i geri yükle”).
• Ön koşul: Bu adım başlamadan hangi adımın bitmiş olması gerektiği.
• Eylem: Çalıştırılacak komut veya izlenecek ekran yolu; sunucu adı, IP ve parametreler açık yazılır.
• Beklenen sonuç: Başarılı çıktının nasıl göründüğü.
• Doğrulama: Adımın gerçekten tamamlandığını kanıtlayan bağımsız kontrol.
• Tahmini süre: Son tatbikatta ölçülen süre.
• Sorumlu ve yedeği.
• Başarısızlık durumunda: Alternatif yol veya kime eskale edileceği.

Doğrulama komutları runbook’un en değerli kısmıdır. “Servis başladı” ile “sistem çalışıyor” aynı şey değildir; NTDS servisi çalışırken replikasyonun kırık olması ya da SQL servisi açıkken veritabanlarının RECOVERY_PENDING durumunda beklemesi sahada sık görülür. Kimlik ve veri dalgaları için örnek doğrulama komutları:

# Dalga 1 – AD DS ve DNS doğrulama
dcdiag /s:DC01 /q
repadmin /replsummary
nslookup erp.contoso.local DC01
Get-Service NTDS, DNS, Netlogon, DFSR -ComputerName DC01

# Dalga 2 – SQL Server veritabanı durumu
sqlcmd -S SQL01 -E -Q "SELECT name, state_desc FROM sys.databases WHERE state_desc <> 'ONLINE'"

# Dalga 3 – uygulama servis portu
Test-NetConnection -ComputerName APP01 -Port 443

SQL sorgusu boş sonuç döndürüyorsa tüm veritabanları ONLINE demektir. dcdiag /q yalnız hataları yazdırır; temiz çıktı beklenir. Veritabanı geri yüklemesinin T-SQL adımları SQL Server yedekleme stratejisi yazısındaki geri yükleme sırasıyla uyumlu olmalı.

Erişim bilgileri ve çevrimdışı kopya

Runbook, felaketten etkilenmeyecek bir yerde ve biçimde durmalı. Paylaşımlı klasörde veya SharePoint’te duran tek kopya, tam ihtiyaç anında erişilemez olabilir. Fidye yazılımı dosya sunucusunu şifrelediğinde runbook da içindedir. Sahada şu katmanlar birlikte kullanılır:

• Basılı kopya: Kilitli dolapta, ikinci lokasyonda; her sürüm değişikliğinde yenilenir.
• Çevrimdışı dijital kopya: Şifreli USB bellek veya kurumsal ağdan bağımsız bir depolama alanı.
• Kimlik bilgileri: Runbook’a parola yazılmaz; parola kasasının adı ve kasa erişilemezse kullanılacak acil durum (break-glass) hesaplarının yeri yazılır. Parola kasası şirket içinde ve domain’e bağlıysa çevrimdışı dışa aktarımı veya mühürlü zarfta tutulan kopyası olmalı.
• Anahtarlar ve erişimler: Yedek şifreleme parolaları, BitLocker kurtarma anahtarları, DSRM parolaları, hipervizör ve depolama yönetim hesapları, güvenlik duvarı yönetim erişimi, lisans anahtarları ve üretici destek sözleşme numaraları.
• Kurulum medyası: Yedek yazılımının kurulum dosyası ve yapılandırma yedeği; yedek sunucusu kaybedilirse önce onu ayağa kaldırmak gerekir.

Yedek sunucusu domain’e bağlıysa, AD’nin kaybedildiği senaryoda yedek konsoluna erişim zorlaşır. Runbook bu “tavuk-yumurta” durumlarını açıkça yazmalı: AD yoksa yedek sunucusuna hangi yerel hesapla, hangi IP üzerinden bağlanılacağı. Bu satır yoksa ilk saat kaybolur.

Örnek runbook bölümü

Aşağıdaki tablo, Veeam ile yedeklenen bir ortamda birincil SQL Server sunucusunun DR sitesindeki bir host’a geri yüklenmesini runbook formatında gösteriyor. Ön koşul: 1. dalga (kimlik ve DNS) tamamlanmış olmalı. Adlar örnektir; süre bilgisini kendi tatbikat ölçümlerinizle ekleyin.

2.5 numaralı adımdaki “son işlem zamanı” gerçekleşen RPO’nun kanıtıdır ve tatbikat raporuna yazılır. Domain controller’lar bu kalıba uymaz: çalışan DC’ler varken eski bir DC yedeğini sıradan bir VM gibi geri yükleyip ağa bağlamak dizin tutarlılığı sorunlarına yol açabilir. DC adımları AD’ye özgü prosedüre göre yazılır; senaryoya göre yöntemler Active Directory yedekleme ve geri yükleme yazısında.

Tatbikat ve güncelleme döngüsü

Hiç uygulanmamış runbook bir varsayımlar listesidir. Dokümanı canlı tutan döngü dört adımdır:

1. Tatbikat: Masa başı gözden geçirme (adımlar sesli okunur, eksikler not edilir), kısmi teknik test (tek sistem izole ağda geri yüklenir) ve planlı tam test. Kritik sistemler için kısmi testin birkaç ayda bir, tam testin yılda en az bir kez yapılması yaygın bir uygulamadır.
2. Ölçüm: Her adımın gerçek süresi, beklenen sonuçtan sapmalar, belgede olmayan ama yapılması gereken işler.
3. Güncelleme: Tatbikattan sonraki bir hafta içinde runbook düzeltilir, sürüm numarası artırılır, basılı ve çevrimdışı kopyalar yenilenir.
4. Değişiklik tetikleyicileri: Yeni sunucu, IP değişikliği, uygulama sürüm yükseltmesi, yedek yazılımı değişimi veya ekipte görev değişikliği runbook güncellemesini zorunlu kılar. Değişiklik yönetimi formuna “DR runbook etkileniyor mu?” sorusunu eklemek bu bağı kurmanın en basit yoludur.

Tatbikatta ölçülen süreler hedef RTO ile karşılaştırılır; aradaki fark ya teknolojiyle (replikasyon, daha hızlı depolama) ya da süreçle (otomasyon, paralel adımlar) kapatılır. Çoğu zaman ikincisi daha ucuzdur. Kamuya açık bir çerçeve arıyorsanız NIST SP 800-34 Rev. 1 bilgi sistemleri olasılık planlaması rehberi iyi bir başlangıçtır.

Kontrol listesi

• Tetikleme kriterleri ölçülebilir ve karar yetkilisi belli.
• Geri dönüş sırası teknik bağımlılığa göre dalgalara ayrıldı.
• Her adımda eylem, doğrulama, süre ve sorumlu alanları dolu.
• Runbook’un basılı ve çevrimdışı kopyası ikinci lokasyonda.
• AD olmadan yedek konsoluna erişim yolu yazılı ve test edildi.
• Şifreleme parolaları ve kurtarma anahtarları runbook’tan bağımsız, erişilebilir yerde.
• Son tatbikat tarihi ve ölçülen RTO belgenin başında.

Runbook hazırlığı, bağımlılık analizi ve tatbikat planlamasında yedekleme ve felaket kurtarma ile altyapı danışmanlığı sayfalarımızda destek kapsamını bulabilirsiniz.

Sık sorulan sorular

DR runbook ile iş sürekliliği planı aynı belge olabilir mi?

Küçük ortamlarda aynı belgede tutulabilir, ama ayrı bölümler halinde. İş sürekliliği planı karar ve iletişim düzeyinde, runbook komut ve doğrulama düzeyinde yazılır; ikisini karıştırmak teknik adımları okunmaz hale getirir.

Runbook’a parolalar yazılmalı mı?

Hayır. Runbook’ta parolanın kendisi değil, parolanın bulunduğu kasa ve kasa erişilemezse kullanılacak acil durum hesabının yeri yazılır. Kasanın da felaketten etkilenmeyecek bir çevrimdışı kopyası olmalı.

Runbook ne sıklıkla güncellenmeli?

Her tatbikattan sonra ve altyapıda runbook’u etkileyen her değişiklikte. Değişiklik yönetimi sürecine runbook etkisi sorusunu eklemek güncellemenin unutulmasını önler.

Geri dönüş sırası neye göre belirlenir?

İş önceliğine değil, teknik bağımlılığa göre. Önce ağ, hipervizör ve depolama; ardından kimlik ve DNS; sonra veritabanları, uygulamalar ve kullanıcı erişim katmanı açılır.