Bu geri alma tatbikatını, bozuk bir sürümü 5 dakikada geri yüklemeyi prova etmek için kullanın: hangi öğelerin anlık görüntüsünün alınacağı, nelerin doğrulanacağı ve tatbikat sırasında kimin neyi tıklayacağı.
Bir sürüm testte iyi görünebilir, sonra gerçek trafikte ilk beş dakika içinde bozulabilir. Korkutucu olan genellikle hata değil. Belirsizliktir: ne değişti, güvenle neler geri alınabilir ve geri almak işleri daha da kötüleştirir mi?
Sürümden hemen sonra hatalar çoğunlukla basit ve acı verici şekilde görünür. Yeni bir buton mobilde sayfayı çökertiyor olabilir. Bir backend değişikliği yanlış veri yapısı döndürebilir, bu yüzden ödeme aşaması başarısız olur. Küçük bir konfigürasyon değişikliği girişleri, e-postaları veya ödemeleri bozabilir. Düzeltme kolay olsa bile, kullanıcılar izlediği için baskı artar ve her dakika pahalı hissedilir.
Panik, geri alma yolu belirsiz olduğunda başlar. İnsanlar aynı anda aynı soruları sorar: Anlık görüntümüz var mı? Hangi sürüm son iyi olan sürümdü? Uygulamayı geri alırsak veritabanı ne olacak? Kimin erişimi var? Bu cevaplar önceden yazılı değilse ekip zamanını servis yerine tartışmaya harcar.
Bir olay esnasında tahmin yürütmenin gerçek bir maliyeti vardır. Zaman kaybedersiniz, kullanıcılar güvenini kaybeder ve aceleyle yapılan değişiklikler ilk kesintinin üzerine ikinci bir kesinti getirebilir. Mühendisler de aynı anda çok fazla yönlere çekilir: hata ayıklama, mesajlaşma ve karar verme.
Bir prova, belirsizliği kas hafızasıyla değiştirdiği için ortamı değiştirir. İyi bir geri alma tatbikatı sadece “kodu geri alabiliyor muyuz” değildir. Tekrarlanabilir bir rutindir: neyi anlık görüntüleyeceksiniz, neyi geri yükleyeceksiniz, neyi doğrulayacaksınız ve kimin işlem yapmaya yetkisi var. Birkaç prova sonrası geri alma başarısızlık gibi değil, bir güvenlik aracı gibi hissedilir.
Eğer dağıtım düzeniniz zaten anlık görüntüleri ve geri yüklemeyi destekliyorsa (bazı platformlar, Koder.ai dahil, bunu sürüm akışına entegre eder), tatbikatlar daha kolay olur çünkü “bilinen iyi sürüme dön” normal bir eylemdir, özel bir acil durum prosedürü değil. Her halükarda amaç aynıdır: an geldiğinde kimse doğaçlama yapmamalı.
“5 dakikada geri yükle” her şeyin mükemmel olduğu anlamına gelmez. Kullanıcıları hızlıca çalışan bir sürüme geri döndürebildiğiniz anlamına gelir, yeni sürüm hâlâ bozuk olsa bile.
Servis önce, düzeltmeler sonra. Servisi hızlıca geri getirebilirseniz, gerçek hatayı bulmak için sakin zaman satın alırsınız.
Sayaç, “Geri alıyoruz” konusunda anlaşmaya vardığınızda başlar. Bu, her şeyin kendi kendine toparlanıp toparlanmayacağı hakkında uzun bir tartışmayı içermez.
Geri alma tetikleyicinizi önceden belirleyin. Örneğin: “Dağıtımdan sonra 3 dakika boyunca checkout hataları %X’in üzerinde kalırsa geri alırız.” Tetikleyici gerçekleştiğinde senaryoyu izlersiniz.
“Geri yüklendi”, kullanıcılara güvenli olduklarını ve sistemin stabil olduğunu söyleyen küçük bir sinyal seti olmalı. Sıkı ve kolay kontrol edilebilir tutun:
Bu sinyaller iyi görünüyorsa 5 dakikalık zamanlayıcıyı durdurun. Geri kalan her şey bekleyebilir.
Tatbikatı dürüst tutmak için, 5 dakikalık yolda yapmadıklarınızı açıkça belirtin: derin hata ayıklama, kod değişiklikleri veya acil düzeltme sürümleri ve mühendislik işi haline gelen her şey.
Geri alma ancak karar çoğunlukla önceden verilmişse hızlı hisseder. Çoğu olay için işe yarayan bir yaklaşım seçin, sonra sıkıcı olana dek pratiğini yapın.
Tatbikatınız dört soruyu yanıtlamalı:
Yeni sürüm kullanıcıları veya veriyi aktif olarak zedeliyorsa ve bilinen iyi bir sürüme dönme imkanınız varsa geri alma en iyisidir. Etki küçük, değişiklik izole ve güvenle yamalanabileceğinden eminseniz hotfix tercih edilir.
Basit bir varsayılan iyi işler: kullanıcılar ana işlemi tamamlayamıyorsa (checkout, giriş, kayıt) veya hata oranları sıçrama yapıyorsa önce geri al, sonra ileriye doğru düzelt. Hotfixleri can sıkıcı ama tehlikeli olmayan sorunlar için saklayın.
Hedefiniz ekibinizin tartışmadan hızla seçebileceği bir şey olmalı. Çoğu ekip üç ortak hedeften biriyle sonuçlanır:
Güvenilir dağıtım anlık görüntüleriniz varsa, bunları varsayılan yapın çünkü baskı altında en tekrar edilebilir olandır. Konfigürasyon yolunu, kod iyi ama bir ayar yanlışsa kullanılacak ayrı bir yol olarak tutun.
Ayrıca “önceki iyi”nin ne sayıldığını tanımlayın. Bu, izleme kontrollerini tamamlayan ve aktif bir olayı olmayan en yakın sürüm olmalı; insanların hatırladığı sürüm değil.
Bir olay sırasında toplantı beklemeyin. Geri almayı başlatacak tetikleyicileri yazın ve onlara bağlı kalın. Tipik tetikleyiciler arasında ana akışın birkaç dakikadan uzun süre bozulması, hata oranı veya gecikmenin belirlenen eşikleri aşması, veri riski (yanlış yazmalar, çift ücretlendirme) ve sürümün getirdiği herhangi bir güvenlik/mahremiyet endişesi bulunur.
Sonra geri almayı onaylayabilecek kişiyi belirleyin. Bir rol seçin (olay lideri veya on-call), artı bir yedek. Diğer herkes tavsiye verebilir, ama engelleyemez. Tetikleyici çaldığında ve onaylayan “geri al” dediğinde ekip her seferinde aynı adımları uygular.
Bir geri alma tatbikatı, bilinen iyi bir duruma hızlıca dönebilirseniz işe yarar. Anlık görüntüler sadece “iyi olur” değil. Ne çalıştığını, ne değiştiğini ve nasıl geri döneceğinizi kanıtlayan makbuzlardır.
Her sürüm öncesi bu öğeleri arama yapmadan alabileceğinizden emin olun:
Veritabanı güvenliği genelde tuzaktır. Hızlı bir uygulama geri alması, veritabanı artık yeni şemayı bekliyorsa yardımcı olmaz. Riskli migrasyonlar için iki adımlı bir sürüm planlayın (önce yeni alanları ekleyin, sonra kullanmaya başlayın) böylece geri alma mümkün kalsın.
Her yerde tek bir adlandırma kuralı kullanın ve sıralanabilir olsun:
prod-2026-01-09-1420-v1.8.3-commitA1B2C3
Ortam, zaman damgası, versiyon ve commit’i ekleyin. Araçlarınız bir UI’da anlık görüntüleri destekliyorsa, orada da aynı adlandırma kuralını kullanın ki herhangi biri olay anında doğru geri yükleme noktasını bulabilsin.
Geri alma tatbikatı, herkes kendi şeridini bildiğinde daha hızlı ve sakin olur. Amaç “herkes atla” değil. Bir kişi karar verir, bir kişi işlemi yapar, bir kişi çalıştığını doğrular ve bir kişi diğerlerini bilgilendirir.
Küçük ve orta ölçekli ekipler için bu roller iyi çalışır (bir kişi iki şapkayı giyebilir, ama tatbikat sırasında Deployer ve Verifier’i birleştirmekten kaçının):
İzinler bu planı gerçek yapar veya sadece güzel bir belge haline getirir. Tatbikattan önce kimin prod’u geri alabileceği konusunda anlaşın ve acil durumların nasıl işleyeceğini belirleyin.
Basit bir kurulum:
Koder.ai gibi snapshot ve geri alma destekleyen bir platform kullanıyorsanız, kimlerin snapshot oluşturabileceğine, kimlerin geri yükleyebileceğine ve bu eylemin nerede kaydedileceğine karar verin.
Geri alma tatbikatı, yangın tatbikatı gibi hissettirdiğinde en iyi çalışır: aynı adımlar, aynı kelimeler, aynı yerlerde tıklama. Amaç mükemmellik değil. Nöbetçi olan herkesin tartışmadan son bilinen iyi sürümü hızlıca geri getirebilmesi.
Bir açık tetikleyici seçin ve tatbikat başladığında yüksek sesle söyleyin. Örnekler: “Checkout 1 dakikadan uzun süredir 500 dönüyor” veya “Dağıtımdan hemen sonra hata oranı normalin 5 katı.” Yüksek sesle söylemek ekibin sorun giderme moduna kaymasını önler.
Runbook’un yanına kısa bir hazırlık kontrol listesi koyun:
Zamanlayıcıyı başlatın. Bir kişi tetikleyiciyi ve kararı yüksek sesle açıklar: “Şimdi geri alıyoruz.”
Değişiklikleri dondurun. Yeni dağıtımları durdurun ve sistemi geri alma sırasında değiştirebilecek gereksiz düzenlemeleri durdurun.
Son şans anlık görüntüsü alın (yalnızca güvenliyse ve hızlıysa). Bu, bozuk durumu daha sonra yeniden oluşturma gerekirse koruma sağlar. Net bir ad verin ve devam edin.
Geri alma eylemini tam olarak dokümante edildiği gibi çalıştırın. Doğaçlama yapmayın. Onay istemlerini yüksek sesle okuyun ki kaydedici ne olduğunu yazabilsin.
Geri almanın tamamlandığını tek bir güvenilir yerde doğrulayın. Her seferinde tek bir ekran ve tek bir sinyal kullanın (dağıtım geçmişi görünümü, “mevcut sürüm” etiketi veya net bir durum göstergesi).
İşlemden hemen sonra, taze iken önemli olanları yakalayın:
Geri alma 5 dakikadan uzun sürerse, bunu geçiştirmeyin. Yavaş adımı bulun, runbook’u düzeltin ve tatbikatı yeniden çalıştırın.
Geri alma ancak kullanıcılar bunu hissettiğinde “başarılı” sayılır. Amacınız eski sürümün dağıtıldığını kanıtlamak değil. Servisin tekrar kullanılabilir ve stabil olduğunu kanıtlamaktır.
Doğrulamayı küçük ve tekrarlanabilir tutun. Liste beşten uzunsa insanlar stres altındayken atlar.
Hızlı çalıştırabileceğiniz, net geç/kalır kontroller kullanın:
Fonksiyonel kontrollerden sonra, güvendiğiniz en basit sistem sağlık sinyaline göz atın. Hata oranının birkaç dakika içinde normale dönmesini ve gecikmenin durmasını görmek istersiniz.
Ayrıca görünmez parçaların tekrar hareket ettiğini doğrulayın. Arka plan işleri işleniyor ve kuyruklar azalıyor olmalı, büyümüyor olmamalı. Veritabanı kontrolleri hızlı ve sıradan olmalı: bağlantılar stabil, kilit birikintisi yok ve uygulama yazabiliyor.
Son olarak, dış dünyayı test edin. Güvenli yapabiliyorsanız bir ödeme testi çalıştırın, e-posta iletiminin bounce etmediğini doğrulayın ve webhookların kabul edildiğinden emin olun (veya en azından başarısız olmadıklarını kontrol edin).
Kimsenin doğaçlama yapmaması için önceden yazılmış bir cümle hazırlayın:
“Geri alma tamam. Ana akışlar doğrulandı (giriş + checkout). Hata oranı ve gecikme normale döndü. 30 dakika izleme. Bir sonraki güncelleme 14:30’da.”
Salı günü 10:02. Yeni bir sürüm çıktı ve bir dakika içinde bazı kullanıcılar giriş yapamıyor. Bazıları “geçersiz oturum” alıyor, bazıları hiç bitmeyen bir yükleme çubuğu görüyor. Kayıtlar çalıştığı için sorun ilk başta kolay kaçabiliyor.
İlk sinyal genellikle dramatik bir kesinti değildir. Destek taleplerinde artış, başarılı girişlerde düşüş ve birkaç kızgın kullanıcı mesajı gelir. On-call “giriş başarı oranı 5 dakika içinde %18 düştü” uyarısını görür ve destek: “3 kullanıcı güncellemeden sonra giriş yapamıyor” diye bildirir.
Tatbikatı yapmış ekip uzun tartışmalara girmiyor. Onaylıyor, karar veriyor ve harekete geçiyorlar.
Geri alınanlar: web ve API servisleri için uygulama kodu ve konfigürasyon. Sabit kalanlar: veritabanı ve kullanıcı verileri.
Eğer sürüm bir veritabanı migrasyonu içeriyorsa, tatbikat kuralı basittir: 5 dakikalık yolda veritabanını asla geri alma. Migrasyonları geriye dönük uyumlu yapın veya dağıtmadan önce ikinci bir göz isteyin.
Geri alma sırasında olay lideri her birkaç dakikada kısa güncellemeler gönderir: kullanıcıların ne gördüğü, hangi eylemin yapıldığı ve bir sonraki güncellemenin ne zaman olacağı. Örnek: “Girişi geri yüklemek için son sürümü geri alıyoruz. Bir sonraki güncelleme 2 dk içinde.”
Geri alma sonrası kapanış: “Giriş normale döndü. Kök neden incelemesi sürüyor. Ne olduğunu ve tekrar olmaması için ne değiştirdiğimizi paylaşacağız.”
Bir geri alma tatbikatı sıkıcı hissetmeli. Eğer stresli hissediyorsa tatbikat gerçek eksikleri ortaya çıkarıyor demektir: erişim, eksik snapshotlar veya sadece birinin kafasında olan adımlar.
Pratiği varsayılan erişimle yapıyorsunuz, gerçek izinlerle değil. İnsanlar olay sırasında deploy edemeyeceklerini, konfigürasyon değiştiremeyeceklerini veya dashboardlara erişemeyeceklerini keşfeder. Düzeltme: tatbikatı olayda kullanacağınız aynı hesaplar ve rollerle çalıştırın.
Anlık görüntüler var ama eksik veya bulması zor. Ekip uygulamanın anlık görüntüsünü alıyor ama ortam değişikliklerini, özellik bayraklarını veya yönlendirmeyi unutuyor. Ya da anlık görüntü adı anlamsız. Düzeltme: anlık görüntü oluşturmayı bir sürüm adımı yapın, bir adlandırma kuralı kullanın ve tatbikatlarda anlık görüntünün görünür ve hızlıca geri yüklenebilir olduğunu doğrulayın.
Veritabanı migrasyonları geri almayı güvensiz kılıyor. Geriye dönük uyumsuz bir şema değişikliği hızlı geri almayı veri sorununa dönüştürebilir. Düzeltme: eklemeli migrasyonları tercih edin. Kaçınılmaz ise sürümü açıkça etiketleyin: “geri alma izinli: evet/hayır.”
Başarıyı kullanıcıların hissettiğini kontrol etmeden ilan ediyorsunuz. Uygulama dağıldı ama giriş hâlâ bozuk veya işler takılı. Düzeltme: doğrulamayı kısa ama gerçek tutun ve zamanlayın.
Tatbikat tekrarlanamayacak kadar karmaşık. Çok fazla araç, çok fazla kontrol, çok fazla ses. Düzeltme: tatbikatı tek sayfaya ve tek bir sahibi olacak şekilde küçültün. Eğer tek bir runbook ve tek bir iletişim kanalıyla yapılamıyorsa, baskı altında işlemeyecektir.
İyi bir geri alma tatbikatı bir alışkanlıktır, kahramanca bir performans değil. Sakin bitiremiyorsanız adımları azaltın, sonra gerçekten riski düşürenleri ekleyin.
Geri alma tatbikatı herkes aynı tek sayfalık kontrol listesini izlediğinde en iyi çalışır. Ekibinizin gerçekten baktığı yerde sabitleyin.
10 dakikadan kısa sürede çalıştırabileceğiniz kompakt versiyon (kurulum ve doğrulama dahil):
Adımları normal hissettirecek kadar sık prova edin. Aylık varsayılan olarak iyi bir frekanstır. Ürününüz günlük değişiyorsa iki haftada bir çalıştırın, ama doğrulamayı en önemli kullanıcı yoluna odaklı tutun.
Her tatbikattan sonra aynı gün runbook’u güncelleyin. Bunu sürüm notlarıyla saklayın ve “son test” satırı ekleyin ki kimse bayat prosedüre güvenmesin.
Sadece gelişmenize yardımcı olacak metrikleri ölçün:
Eğer ekibiniz Koder.ai üzerine kuruyorsa, anlık görüntüleri ve geri almayı alışkanlığın bir parçası yapın: anlık görüntüleri tutarlı adlandırın, on-call’da kullanacağınız aynı arayüzde geri yüklemeleri prova edin ve doğrulama adımlarına hızlı custom-domain ve entegrasyon kontrolleri ekleyin. Bunu runbook’ta belirtmek tatbikatı gerçekte nasıl dağıttığınızı yansıtacaktır.
A rollback drill is a practice run where you simulate a bad release and follow a written routine to restore the last known-good version.
The goal isn’t to “debug fast”—it’s to make restoring service repeatable and calm under pressure.
Use a pre-set trigger so you don’t debate in the moment. Common defaults:
If the trigger hits, roll back first, then investigate after users are safe.
It means you can get users back onto a working version quickly—even if the new release is still broken.
In practice, “restored” is when a small set of signals look healthy again (core user action works, error rate and latency return near normal, no crash loop).
Pick a target you can select in seconds, without discussion:
Define “previous good” as the most recent release with normal monitoring and no active incident—not the one people remember.
At minimum, capture these before every release:
Database changes are the common trap—an app rollback may not work if the schema isn’t compatible.
Name them so they sort and can be found fast, for example:
prod-YYYY-MM-DD-HHMM-vX.Y.Z-commitABC123Include environment + timestamp + version + commit. Consistency matters more than the exact format.
A simple, repeatable split for small teams:
Avoid having the Deployer also be the Verifier during drills; you want an independent “did it really work?” check.
Keep it tiny and pass/fail. Good must-pass checks include:
Then confirm error rate and latency settle back near normal, and queues/jobs aren’t backing up.
Don’t make “rollback the database” part of the 5-minute path. Instead:
This keeps the quick rollback path safe and predictable.
If your platform supports snapshots and restore as part of the release flow, drills get easier because “go back to known good” is a normal action.
On Koder.ai specifically, decide ahead of time:
The drill still needs roles, triggers, and a short verification list—tools don’t replace the routine.