Felaket Kurtarma Planı Nasıl Yazılır? RTO/RPO’yu Kafada Netleştirip Yedek Testleri ve Runbook’ları Gerçekten Çalışır Hale Getirmek

Kahve Döküldü, Sunucu Gitti: DR Planına Sıcak Bir Giriş

Hiç sabah kahveni masaya bırakırken Slack’in bir anda alev alev yanmaya başladığı oldu mu? Bende oldu. Küçük gibi görünen bir ağ değişikliği, beklenmedik şekilde bir servisi düşürdü ve o an anladım: Felaket Kurtarma Planı kâğıtta durduğu gibi durmuyor, gerçekten nefes alan bir organizma gibi yaşamalı. O gün şunu düşündüm; çalıştığını sanmak ile gerçekten çalıştırmak arasında kocaman bir fark var. İşte bu yazıda tam da orayı dolduralım istedim.

Bir felaket derken aklına hemen devasa yangınlar gelmesin. Bazense tek bir hatalı komut, bir güncelleme, hatta bir faturayı gözden kaçırmak bile yeter. Soruyu kendine şöyle sor: “Elektrik gittiğinde, bulut sağlayıcı bölgede sorun yaşadığında, veritabanını bir saat önceki haline almak zorunda kaldığımda ne olur?” Cevabın “bakarız” ise, aslında ortada bir plan yok. Şimdi adım adım gidelim; RTO ve RPO’yu akılda netleştirelim, yedekleri yalnızca almakla kalmayıp test eder hale getirelim, ve bir felaket anında ilk dakikadan itibaren ne yapacağını söyleyen runbook’ları yazalım.

Mesela şöyle düşün: E-ticaret siten bir kampanya ortasında 20 dakika durdu. Telefonlar çalmaya başladı, ekip nefes almadan koşturuyor. O 20 dakika seni ne kadar geriye atıyor? Bu yazıda bunun hesabını basitçe çıkaracağız. Sonra da o hesabı gerçekleştirecek şekilde planını ete kemiğe büründüreceğiz. Söz veriyorum, teknik terimlere boğulmadan ama işi ciddiye alarak ilerleyeceğiz.

RTO ve RPO: İki Basit Cümlede Hayat Kurtaran İkili

RTO nedir, neden herkes ondan söz eder?

RTO (Recovery Time Objective) aslında şu sorunun cevabı: “Bir şeyler bozulduktan sonra, sistemi en geç ne kadar sürede ayağa kaldırmalıyım?” Bir saat mi, on dakika mı, yoksa bir gün mü? Bu süreyi telaffuz etmek bile gözünü korkutmasın. Önemli olan, gerçek hayatta tutabileceğin bir söz vermek. Mesela ödeme sayfası için on dakika çok uzun olabilir, ama raporlama servisi bir saat bekleyebilir. Bu farkı bilmek hem önceliklendirme yapmanı sağlar hem de ekipte kimsenin kaosa kapılmamasına yardım eder.

RPO nedir, neleri göze alıp alamayacağını söyler?

RPO (Recovery Point Objective) ise “Veriyi en fazla ne kadar geriye götürmeyi göze alıyorum?” sorusudur. On beş dakika veri kaybı sorun olmaz mı, yoksa bir dakikayı bile çok mu bulursun? Günlük yedek alan bir takım, gün içinde gerçekleşen işlemlerin bir kısmını kaybetmeyi peşinen kabul eder. Bu kötü bir şey değil; yeter ki bilinçli bir seçim olsun. E-ticaret sepetleri için on beş dakika kayıp can acıtır; blog yazıları için aynı acı hissedilmeyebilir. Her ikisi de doğrudur çünkü bağlam farklıdır.

RTO/RPO’yu belirlemenin pratik yolu

Bir toplantı odasında herkesin masaya “bence” koyduğu anları bilirsin. Burada küçük bir oyun işe yarıyor: Servisleri tek tek ele al, her biri için iki cümle yaz. İlki, “şu kadar sürede ayağa kalkmalı” cümlesi. İkincisi, “en fazla şu kadar veriyi kaybetmeyi göze alırım” cümlesi. Gülme, bu iki cümle yazıldığında sihirli bir şekilde öncelikler sıralanıyor. Sonra bunları teknolojiye çeviriyoruz: daha sık yedek, penceresi dar replikasyon, daha hızlı otomasyon. Ve tabii ki bütçe, çünkü her dakikanın bir maliyeti var. Pahalı demeden önce, kesintinin gerçek maliyetini bir günlüğüne sadece tahmini bile olsa yazmayı dene; bakış açın değişir.

Elinde Ne Var? Envanter, Bağımlılıklar ve Kırılgan Noktalar

Haritayı çizmeden yola çıkılmaz

Bir keresinde tüm servisleri bildiğimi sanıyordum. Meğer küçük bir webhook, görünmez bir düğüm gibi her şeyi birbirine bağlıyormuş. İşte bu yüzden envanter ve bağımlılıklar konusunu atlamak büyük risk. Uygulamalar, veritabanları, kuyruklar, dosya depoları, üçüncü parti API’ler, DNS kayıtları, e-posta sağlayıcıları… Hepsini bir anda çıkarmak göz korkutabilir ama parça parça mümkün. Bir beyaz tahta, birkaç kahve ve iki saatlik samimi bir beyin fırtınası yeterli olur.

Kritik yolun peşine düş

Mesela şöyle düşünün: Kullanıcı mobil uygulamadan üye oluyor, e-posta doğrulaması geliyor, ödeme alınıyor, sipariş kuyruğa düşüyor, faturası kesiliyor. Bu zincirde bir halkayı çekip çıkar, “bu olmasa sistem çalışır mı” diye sor. Cevap koca bir hayırsa, orası kritik yol. Kritik yolun her halkasının “tekli arıza noktası” olup olmadığını gör. Tek bir veritabanı? Tek bir CDN? Tek bir bölge? Hepsi yeniden düşünülmek için birer çağrı.

Gizli bağımlılıklar ve erişim

Felaket anlarında en sinir bozucu şey şudur: Her şey hazır sanırsın ama bir izin eksikliği yüzünden elin kolun bağlanır. Yönetim panellerine erişim, bulut hesabı kimlik bilgileri, domain kayıtçısına giriş, sertifikalar, kasada duran 2FA yedek kodları… Bunların nerede olduğu, kimin erişebildiği, acil durumda nasıl devreye alınacağı runbook’larda açıkça yazmalı. Yoksa o gün kimse şifreyi hatırlamayacak ve dakika sayan RTO bir anda hayal olacak.

Yedekleme Stratejisi: Almak Yetmez, Geri Dönüyor mu?

Yedekler sadece dosya değil, güven hissidir

Yedek almak kolay. Zor olan, geri dönmenin gerçekten çalıştığını bilmek. Bunu anlamanın tek yolu yedek testleri. Haftalık mini testler, aylık tam kurtarma provası, üç ayda bir de “oyun günü” gibi daha gerçekçi bir tatbikat. Küçükten büyüğe doğru giden bir ritim kur. Mesela her pazartesi bir dosya setini geri yükle, her ay veritabanının farklı bir zaman noktasına dönüşünü dene, üç ayda bir tüm uygulamayı baştan kurup trafik karşılayacak hale getir. İlk başta yorucu görünür ama birkaç seferden sonra akışın ritmi oturur.

RPO’yu yedeklemenin ritmi belirler

RPO’yu bir dakika hedefliyorsan, günlük yedek yetmez. Daha sık anlık görüntüler, sürekli replikasyon veya günlük yedeğin yanına eklenen artımlı yedekler gerekir. Burada mucize yok; ne kadar sık yedek, o kadar az veri kaybı. Ama sakın yedekleri tek yerde tutma. Bulutun başka bölgesine, hatta tamamen farklı bir sağlayıcıya kopya almak, korkulan gün geldiğinde oyunu çevirir. Şifrelemeyi ve erişimi de unutma; felaket bir taraftan gelirken yedeklerinin yanlış ellere gitmesi ikinci bir felaket olur.

Test ederken nasıl ölçersin?

Test günü geldiğinde önceden belirlenmiş iki şeyi özellikle ölç. Birincisi, geri dönüş ne kadar sürdü; yani RTO hedefini tutturdun mu. İkincisi, geri döndüğün veri ne kadar günceldi; yani RPO gerçekte ne oldu. Zamanları not et, eksikleri yaz, bir sonraki teste kadar iyileştirme maddelerini uygulamaya koy. Bu notlar altın değerinde. Bir sonraki felakette stresli anlarda kılavuzluk eder, doğru kararları hızlı almana yardım eder.

Gözün her şeyin üstünde olsun

Felaket kurtarma sadece yedekle değil, gözlemlenebilirlikle de yürür. Loglar, metrikler, alarmlar… Bunlar çalışmadığında, sorun fark edilmediği için RTO zaten baştan tutmaz. Bizim ekipte merkezi loglama kurduktan sonra karar alma hızımız belirgin şekilde arttı. Eğer bu dünyaya yeniyse, “VPS’te merkezi loglama ve alarm kurallarıyla sakin kalan bir zihin” anlatısını sevmiştim; oradaki pratikler DR hedeflerini besleyen sağlam bir temel oluyor.

Runbook’lar: Panik Anında Sakin Kalmanın Yazılı Hali

Runbook ne işe yarar?

Felaketin en zor yanı, herkesin bildiğini sandığı şeylerin bir anda buharlaşmasıdır. Runbook, o buharı dağıtan yazıdır. Kim, neyi, hangi sırayla yapacak? Hangi komutlar, hangi erişimlerle, hangi doğrulamalarla? Bir runbook, ilk dakikadan itibaren adım adım rehberlik eder. Uzun cümlelerle roman yazmana gerek yok; net, kısa ve uygulanabilir cümleler yeter. Ama en önemlisi, runbook sadece yazılmakla kalmamalı; düzenli aralıklarla tatbikatlarda okunup uygulanmalı.

Örnek bir runbook iskeleti

Başlık “Ödeme Servisi Felaket Kurtarma Runbook’u” olabilir. Amaç kısmında “Ödeme servisini Bölge-A’da yaşanan kesinti sonrası Bölge-B’de ayağa kaldırmak” gibi tek cümlelik bir hedef yaz. Başlamadan önce bölümünde önkoşulları belirt: Bölge-B kimlik bilgileri, yapılandırma dosyalarının yolu, DNS yönetimine erişim, uyarı sistemine giriş. Ardından adımlar gelir. Mesela ilk adım, servis durumunu doğrulamak ve etki alanını tanımlamak olabilir. İkinci adım, Bölge-B’de gerekli altyapıyı ayağa kaldırmak. Üçüncü adım, veritabanını belirlenen zaman noktasına döndürmek. Sonra uygulamayı başlatır, sağlık kontrollerini yapar, DNS yönlendirmesini değiştirir ve sonuçları izlersin. Her adımın sonunda doğrulama cümlesi yer alır. Son bölümde de geri alma planı ve iletişim notları bulunur.

Runbook yazarken küçük ama kritik detaylar

Komutlar ve ekran görüntüleri çok yardımcı olur ama değişen sürümler yüzünden yanıltıcı olabilir. O yüzden komutların yanında “bu komut şunu yapar, başarı kriteri budur” gibi tek cümlelik açıklamalar eklemek iyi iş çıkarır. Erişim gerektiren bölümlerde bir “Plan B” yaz. Mesela MFA cihazına erişilemediğinde yedek kodlar nerede, kimde, nasıl kullanılacak. Ayrıca runbook’un uçtan uca okunabilir olması için özet bir akış da ekle; “Problem tespiti → Altyapı açılışı → Veri dönüşü → Uygulama doğrulama → Trafik yönlendirme → İzleme” gibi bir çizgi, stres anında harikalar yaratır.

DR Stratejileri: Soğuk mu, Ilık mı, Sıcak mı? Cüzdan ve Risk Dengesi

Soğuk, ılık ve sıcak yaklaşımlar

Her sistem için tek tip bir doğru yok. Bazı projelerde yedekleri elde hazır tutup, felaket anında sıfırdan kurmak mantıklıdır. Buna soğuk yaklaşım gibi düşünebilirsin; maliyeti düşük, dönüş süresi uzun. Başka durumlarda altyapı hazır bekler, veri senkronize olur ama trafik yönlendirilmemiştir; ılık bir yaklaşım. Dönüş süresi daha kısa, maliyet orta. Bir de en uykusuz ama en hazırlıklı yaklaşım var; iki taraf da canlı, trafik dengeli veya anında devredebilecek halde; buna sıcak diyelim. Maliyet yüksek ama dönüş hızlı. Hangisini seçeceğin; RTO, RPO ve bütçe üçlüsünün kesişiminde netleşir.

DNS ve yönlendirme anı

Felaket anında trafiği nereye yönlendirdiğin her şeydir. DNS’de TTL ayarlarını daha önceden makul düzeye çekmek, servis kesintisi anında işleri hızlandırır. Ama yalnız başına yeterli olmayabilir. Uygulama düzeyindeki sağlık kontrolleri, altyapı orkestrasyonu ve otomasyon senin en yakın arkadaşındır. Bu noktada sağlayıcıların yol gösteren rehberleri çok yardımcı olur. “Felaketten sonra nasıl ayağa kalkarım?” sorusu için AWS’in felaket kurtarma rehberindeki pratik senaryolar hoş bir başlangıç sunuyor.

Veri tutarlılığı ve küçük sürprizler

Replikasyonda gecikme, yazma yönünü değiştirdiğinde “çifte yazma” hatası, zaman damgaları, sıra dışı cache davranışları… Hepsi pratikte çıkar karşına. Korkma; bu yüzden tatbikat yapıyorsun. Yedek dönüşünde uygulamanın tek tek kritik akışlarını dene. Kullanıcı giriş, ödeme, e-posta gönderimi, webhooks… İki dakikalık bir tıklama turu bile gözden kaçan bir yapılandırmayı öyle güzel ele verir ki, bazen uzun loglara bakmaktan daha etkilidir.

Tatbikatlar, İletişim ve Ekip İçi Ritüeller

“Oyun günü” kültürü

Benim sevdiğim bir ritüel var: Oyun günü. Gerçek trafiği riske atmadan, mümkünse staging ortamında veya kontrollü bir üretim segmentinde planlı bir kesinti simülasyonu yapıyoruz. Amaç kimseyi utandırmak değil; sistemin ve sürecin nerede tökezlediğini görmek. Tatbikat sonunda bir not defteri dolusu fikir çıkar: Runbook’ta net olmayan bir cümle, eksik bir erişim, ağır bir yedek dönüş adımı. Bir dahaki sefere daha iyi olmak için bunlar hazinedir.

İletişim planı olmadan plan yoktur

Felaket anında yazılım kadar iletişim de önemli. Kimin haber vereceği, hangi kanalların kullanılacağı, müşteriye ne zaman ve nasıl bilgi geçileceği, iç ekip güncellemelerinin sıklığı… Bunlar net değilse, teknik olarak toparlansan bile algı yönetimi elinden kayar. Dış iletişimde dürüst ve net olmak en doğrusu. “Sorunu tespit ettik, şu planı uyguluyoruz, şu saati hedefliyoruz” demek, tahmin oyunlarından daha güven verici olur. Etkili iletişim için pratik bir rehber arıyorsan, Atlassian’ın olay yönetimi sayfasındaki sade çerçeve anlaşılır bir başlangıç noktası.

Olay sonrası değerlendirme

Her felaket ve her tatbikat sonrası kısa bir değerlendirme yap. Ne işledi, ne işlemedi, hangi kararlar gecikti, hangi araçlar parladı? Bu geri bildirimleri suçlayıcı olmayan bir dille konuşmak kültürü besler. Sonuçları runbook ve planlara geri yazdığında döngü tamamlanır. Bir süre sonra fark edersin; sistemin hem daha sağlamdır hem de ekip fırtınada daha sakin kalır.

Bulut Notları, Otomasyon ve Güvenli Erişim

Altyapıyı yazıyla kur, yazıyla döndür

Felaket anında manuel tıklamalar risklidir. Altyapıyı kodla tanımladığında, aynı tanımı başka bir bölgede, başka bir hesapta, başka bir günde baştan kurmak çok daha güvenilir olur. Pipeline’lar, onay adımları, gizli anahtarların güvenli yönetimi… Hepsi bu oyunun parçası. Yalnız iyi yazılmış bir runbook, kodu da tarif eder; “bu pipeline’ı şu parametreyle çalıştır, başarı kriteri şu metrik” gibi cümleler, sisin içinden yolu gösterir.

Güvenli erişimi unutanın RTO’su uzar

Erişim olmadan hiçbir şey yapılamaz. O yüzden kimlik bilgileri, yedek erişim yöntemleri, mTLS veya IP kısıtları gibi güvenlik katmanlarının acil durumda nasıl geçici olarak esnetilip sonra nasıl geri alındığı planlanmalı. İdari panelleri ayrıca korumak için sertifikalı erişimler ve sıkı kurallar hayat kurtarır. Bu konuda üretimde en çok rahat ettiğim yaklaşımlardan biri, istemci sertifikalarıyla kapı tutmaktır. Sağlayıcıların da kendi rehberleri var; örneğin NIST’in kuruluşlara yönelik felaket kurtarma kılavuzu temiz bir çerçeve sunuyor.

Üçüncü taraf hizmetler ve sözleşmeler

DR, sadece kendi yazılımınla bitmez. Ödeme sağlayıcı, e-posta servisi, DNS, CDN, kimlik doğrulama… Hepsi birer halka. Sözleşmelerde yer alan SLA’ları, sağlayıcının bölge politikalarını, felaket anında hangi kanaldan destek verdiğini, hatta faturalandırma tarafında acil durum prosedürlerini not et. Basit gibi duran bu başlıklar, olayın göbeğinde zaman kazandırır. Bir keresinde destek kanalını değiştirmek zorunda kalmıştık; sadece bu geçiş bizden on beş dakika götürdü. O gün runbook’a bir satır ekledik ve mesele kapandı.

Hepsini Bir Araya Getirelim: Somut Bir DR Çalışma Planı

Yol haritasını üç hafta içinde hayata geçirmek

İlk hafta, envanteri ve bağımlılıkları çıkar. Her kritik servis için iki cümlelik RTO ve RPO hedefini yaz. İkinci hafta, yedekleme ritmini ve saklama yerlerini kesinleştir. Günlük ritimde bir küçük dönüş testi, aylıkta tam dönüş ve üç aylıkta oyun günü takvimini ekip takvimine işle. Üçüncü hafta, en kritik iki servis için runbook yaz ve uygulama tatbikatı yap. Her adımın süresini ölç, not al, bir sonraki denemeye kadar iyileştirme maddelerini kapat. Üç hafta sonunda elinde yaşayan bir plan olur. Mükemmele gerek yok; yeter ki başlasın ve her ay üzerine koy.

Performans ve güvenlik kardeştir

Çoğu zaman DR çalışmaları performans ve güvenliği da yanına alır. Önbelleklerin nasıl ısındığı, kuyrukların nasıl boşaldığı, sertifikaların nasıl yenilendiği, oturumların nasıl taşındığı gibi küçük ayrıntılar akışı hızlandırır. Mesela cache’leri ısıtmak için küçük bir trafik jeneratörü kullanmak, kullanıcılar gelmeden sistemin kendine gelmesini sağlayabilir. Bu da RTO’yu kısaltır. Aynı şekilde gizli anahtar rotasyonu ve erişim denetimi, panik anında gereksiz beklemeleri ortadan kaldırır.

Rehber niteliğinde kaynaklar

Tek bir tarif yok ama iyi çerçeveler var. DR senaryolarını akılda netleştirmek için AWS’in felaket kurtarma senaryoları pratik bir dille anlatıyor. Kurumsal düzeyde süreç ve rol tanımları için NIST’in SP 800-34 belgesi yol gösterir. Olay anındaki iletişim akışını düzenlemek için de Atlassian’ın olay yönetimi sayfası temiz, uygulanabilir bir çerçeve sunuyor. Bu kaynakları birer şablon gibi değil, birer fikir havuzu gibi kullanmak daha gerçekçi sonuçlar veriyor.

Kapanış: Bir Plan, Bir Nefes, Bir Sonraki Tatbikat

Bugün yazdıklarımızın özeti basit. Önce RTO ve RPO hedeflerini netleştir, sonra bu hedefleri destekleyecek yedekleme ve geri dönüş ritmini kur. Envanter ve bağımlılıkları görünür hale getir, runbook’ları kısa ve uygulanabilir cümlelerle yaz. En önemlisi, bunların hepsini düzenli tatbikatlarla yaşayan bir düzene dönüştür. Hem sistem hem ekip, pratik yaptıkça olgunlaşır.

Eğer içinden “nereden başlayayım” diye geçiriyorsan, küçükten başla. Tek bir servis, tek bir runbook, tek bir dönüş testi. Bir hafta sonra bir adım daha, bir ay sonra oyun günü. Şunu unutma: DR bir proje değil, bir alışkanlık. Bu alışkanlık yerleştiğinde, o panik dolu Slack bildirimlerinde bile kalbin daha yavaş atar. Umarım bu yazı yoluna ışık tutar. Sen de deneyimlerini not al, ekipçe paylaş, her tatbikattan sonra planını güncelle. Bir dahaki yazıda başka bir konuyu sıcak bir kahvenin eşliğinde konuşuruz; o zamana kadar planını nefes alır hale getir, için rahat etsin.