Geri alma tatbikatı el kitabı: bozuk bir sürümü 5 dakikada geri yükleyin

Geri almalar neden korkutucu gelir (ve pratik neden yardımcı olur)

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” gerçekte ne demektir

“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.

5 dakika eylem içindir, tartışma için değil

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” ne sayılır

“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:

• Ana kullanıcı işlemi yeniden çalışıyor (giriş, ödeme, arama veya uygulamanızın yapması gereken tek şey)
• Hata oranı normale yakın dönüyor
• Gecikme kabul edilebilir aralığa dönüyor
• Çökme döngüsü ya da yeniden başlatma fırtınası yok

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.

Ekibinizin tekrar edebileceği bir geri alma yaklaşımı seçin

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ı:

• Geri alır mıyız yoksa hotfix mi yaparız?
• Ney geri alınır?
• Geri alma neyle tetiklenir?
• “Yap” demeye kimin yetkisi var?

Geri alma vs hotfix: varsayılanı seçin

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.

Geri alma hedefini seçin

Hedefiniz ekibinizin tartışmadan hızla seçebileceği bir şey olmalı. Çoğu ekip üç ortak hedeften biriyle sonuçlanır:

• Önceki sürüm (kontrolleri geçen son sürüm)
• Geri yükleyebileceğiniz bir dağıtım anlık görüntüsü
• Sadece konfigürasyon geri alma (özellik bayrağı veya ortam değişikliği)

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.

Tetikleyici ve yetkiyi tanımlayın

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.

Her sürüm öncesi alınacak anlık görüntüler

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.

Yakalamanız gereken beş şey

Her sürüm öncesi bu öğeleri arama yapmadan alabileceğinizden emin olun:

• Gönderdiğiniz tam uygulama derlemesi: commit hash, versiyon numarası ve build artifaktı (container tag, bundle veya paket).
• Veritabanı durumu ve göç planı: hangi migrasyonların uygulandığı ve geri alınabilir olup olmadığı. Riskli değişiklikler için hızlıca geri yükleyebileceğiniz bir yedek veya anlık görüntü alın.
• Dağıtım zamanındaki konfigürasyon: özellik bayrakları, ortam değişkenleri, üçüncü taraf uç noktaları ve neyin değiştiği. Secretlar güvenli bir sistemde kalmalı ama yine de değişikliklerin versiyonlu kaydına ihtiyacınız var.
• Altyapı ve yönlendirme ayarları: domainler, sertifikalar, load balancer kuralları ve trafik nereye gider anahtarları.
• Kısa bir sürüm notu: ne değiştiği bir cümleyle ve başarılı bir geri almanın nasıl doğrulanacağına dair bir cümle.

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.

Anlık görüntüleri saniyeler içinde bulabilmek için adlandırı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.

Roller: kimin neyi tıkladığı (ve kim sadece izler)

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):

• Olay lideri (zaman tutucu ve karar verici): başarı hedefini belirler ve geri alma çağrısını yapar.
• Deployer (klavyede işlem yapan): geri alma adımlarını tam olarak uygular ve ne yaptığını seslendirir.
• Verifier (doğrulayan): geçmesi gereken kontrolleri çalıştırır ve ana sinyalleri izler.
• İletişim sorumlusu (dışa tek ses): paydaşlara ve destek ekibine kısa, düzenli güncellemeler gönderir.

İ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:

• Deployer’a on-call rotasyonunda veya planlı tatbikat pencerelerinde geri alma yetkisi verin.
• Olay liderinin işlemi onaylamasına izin verin (butonu olmasa bile).
• Verifier’ın dashboardlara ve loglara salt okuma erişimi olduğundan emin olun.
• Bir kırmızı-düğme (auditanmış, zaman sınırlı erişim) seçeneği ayarlayın.
• Erişimi tatbikat kurulumunda test edin, 5 dakikalık zamanlayıcı sırasında değil.

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.

Adım adım: geri alma tatbikatı çalışma kitabı

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.

Başlamadan önce

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:

• Canlı sağlık sinyallerini görebildiğinizi doğrulayın (uptime, hata oranı, ana kullanıcı akışı)
• Son bilinen iyi sürüm kimliğini doğrulayın (tag, build, snapshot adı)
• Geri almaların nerede yürütüleceğini doğrulayın (CI/CD, hosting konsolu, platform UI)
• Yeni dağıtımları nasıl durduracağınızı doğrulayın
• Kimlerin zaman damgası kaydettiğini doğrulayın

5 dakikalık çalışma kitabı

1. Zamanlayıcıyı başlatın. Bir kişi tetikleyiciyi ve kararı yüksek sesle açıklar: “Şimdi geri alıyoruz.”

2. Değişiklikleri dondurun. Yeni dağıtımları durdurun ve sistemi geri alma sırasında değiştirebilecek gereksiz düzenlemeleri durdurun.

3. 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.

4. 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.

5. 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:

• Karar zamanı (tetikleyici belirtildi)
• Geri alma başlama zamanı (ilk tıklama/komut)
• Geri alma tamamlanma zamanı (önceki sürüm aktif)
• İlk başarılı doğrulama zamanı (ana kontrol geçti)
• Herhangi bir sürpriz (eksik izin, belirsiz buton, yavaş adım)

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 almadan sonra neyi doğrulamalısınız

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.

3–5 zorunlu kontrol

Hızlı çalıştırabileceğiniz, net geç/kalır kontroller kullanın:

• Kullanıcı giriş yapabiliyor (veya kayıt olabilir) ve ana ekrana hatasız ulaşabiliyor
• Ana işlem çalışıyor (checkout, rezervasyon, form gönderimi)
• Bir ana API uç noktası 200 döndürüyor ve cevap normal görünüyor
• Admin/destek bir kritik işlemi yapabiliyor (iade, iptal, durum güncelleme)
• Sık kırılan bir kenar akışı (şifre sıfırlama, dosya yükleme, arama) hâlâ çalışıyor

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).

“Her şey yolunda” ifadesini karar verin

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.”

Örnek: bozuk bir sürüm ve temiz 5 dakikalık geri yükleme

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.

5 dakikalık geri yükleme (nasıl görünebilir)

Tatbikatı yapmış ekip uzun tartışmalara girmiyor. Onaylıyor, karar veriyor ve harekete geçiyorlar.

• 10:03: On-call gerçek olduğunu doğruluyor ve bir olay lideri atıyor.
• 10:04: Geri alma kararı. Kural: giriş bozuksa ve 2 dakika içinde güvenli bir düzeltme yoksa geri al.
• 10:05: Deployer önceki bilinen iyi anlık görüntüye geri alma tetikliyor.
• 10:06: Trafik önceki sürüme dönüyor. Ekip web ve mobilde girişleri tekrar test ediyor.
• 10:07: Olay lideri “Giriş geri yüklendi, 10 dakika izleniyor” iletiyor ve destekten etkilenen kullanıcılara cevap vermesini istiyor.

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.

Neler iletilir (sırasında ve sonrasında)

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.”

Yaygın geri alma tatbikatı hataları (ve basit düzeltmeleri)

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.

Dakikaları boşa harcayan hatalar

• 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.

Hızlı kontrol listesi ve sonraki adımlar

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):

• Sürüm öncesi: geri alma noktasını (snapshot/sürüm) doğrulayın, beklenen “iyi” davranışı kaydedin, rolleri atayın (deployer, verifier, iletişim).
• Tetikleyici: “geri alma başlıyor” deyin, zamanlayıcıyı başlatın, yeni dağıtımları dondurun.
• Geri alma eylemi: son bilinen iyi sürümü geri yükleyin, hangi tıklamaların yapıldığını ve sırasını kaydedin.
• Doğrula: 2–3 kritik kontrol çalıştırın (giriş, ana akış, bir entegrasyon ya da API kontrolü), hata oranının düştüğünü onaylayın.
• Kapat: “servis stabil” deyin, üç not yazın (ne işe yaradı, ne yavaşlattı, ne değiştirilmeli), dağıtımları serbest bırakın.

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:

• Geri alma süresi (karar anından restorasyona kadar)
• Doğrulama süresi (restored to stable)
• Rol netliği (nerede tereddüt oldu veya işlerin çakıştı?)
• Eksik bilgi (kimlik bilgileri, izinler, anlık görüntü yeri)

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.