---
title: "Otomasyonda Hata Yönetimi ve Yedek Plan | Designodin Türkiye"
description: "Otomasyonda hata yönetimi ve yedek plan nasıl kurulur? Retry, hata kuyruğu, manuel devir ve geri yükleme testlerini öğrenin."
source: https://designodin.com.tr/blog/otomasyonda-hata-yonetimi-yedek-plan
---

[← Tüm yazılar](https://designodin.com.tr/blog/)
[AI](https://designodin.com.tr/blog/kategori/ai/)

# Otomasyonda Hata Yönetimi ve Yedek Plan

15 Eylül 2026 · Designodin

**Otomasyonda hata yönetimi**, bir akış bozulduğunda veri, sipariş ve müşteri ilişkisinin ne olacağını önceden belirlemektir. Güvenilir bir yapı geçici sorunları yeniden dener, çözülemeyen kayıtları ayırır, çift işlemi önler ve otomasyon durduğunda insanın nasıl devreye gireceğini açıkça tanımlar.

Otomasyon bozulduğunda asıl sorun hata mesajı değildir. Hangi siparişin atlandığını, hangi verinin eksik kaldığını ve sorumluluğu kimin üstleneceğini bilmiyorsanız sorun büyür.

Birçok işletme otomasyonu kurarken yalnızca ideal akışı düşünür: form gelir, CRM kaydı açılır; sipariş gelir, ERP’ye aktarılır; ödeme alınır, müşteriye e-posta gider. Ödeme sağlayıcısı zaman aşımına düştüğünde, API limiti aşıldığında veya aynı webhook iki kez geldiğinde ise sistemin gerçekten ne kadar güvenilir olduğu ortaya çıkar.

Bu rehber teknik kavramları kod öğretmeden açıklar. Hangi hatalarda retry kullanılacağını, hangi kayıtların insan incelemesine gideceğini ve otomasyon tamamen durduğunda operasyonun nasıl devam edeceğini adım adım ele alır.

**Öne Çıkanlar**

- Retry yalnızca zaman aşımı, bağlantı sorunu ve rate limit gibi geçici hatalarda kullanılmalıdır; hatalı veri veya yetki sorununda aynı hatayı tekrarlar.
- Sipariş, ödeme ve stok akışlarında benzersiz işlem kimliği kullanmak çift kayıt, çift bildirim ve çift tahsilat riskini azaltır.
- Dead-letter queue, çözülemeyen kayıtları ana akışı tıkamadan saklar; hata kaydı kaybolmaz ve kontrollü biçimde yeniden işlenir.
- Yedek plan; teknik fallback, manuel operasyon süreci ve veri kurtarma planından oluşur. Yedek dosyası tek başına plan değildir.
- RTO ve RPO hedefleri teknik ekibin değil, işin ne kadar kesintiye ve veri kaybına dayanabileceğini bilen işletmenin kararıdır.

## Otomasyonda hata yönetimi neden iş sürekliliği konusudur

Otomasyon hataları ortadan kaldırmaz. Hatanın hızını ve etkilediği kayıt sayısını değiştirir.

Bir çalışan siparişi ERP’ye yanlış ilettiğinde hata genelde birkaç kayıtla sınırlı kalır. Aynı yanlış eşleme otomasyonda varsa, birkaç saat içinde yüzlerce sipariş yanlış hesaba, yanlış stoğa veya yanlış müşteri kaydına bağlanabilir. Doğru tasarım yoksa hız avantaj değil, hata çarpanıdır.

Kesintilerin önemli bir kısmı teknolojiden değil, uygulanmayan ya da eksik yazılmış prosedürlerden doğar. “Bir kişi bakar” bir süreç tanımı değildir.

Bir otomasyon için şu soruyu sorun:

“Akış çalışmadığında hangi ekran, hangi kayıt ve hangi müşteri etkilenir?”

“Entegrasyon çalışmıyor” teknik bir teşhistir. “Saat 14.00’ten sonraki 17 sipariş ERP’ye düşmedi” ise operasyonel teşhistir. Harekete geçmenizi sağlayan bilgi ikincisidir.

Örnek senaryo: Bir e-ticaret ekibinin sipariş aktarımındaki sorunu ancak ertesi sabah fark ettiğini düşünün. Ödemeler alınmış, siparişler mağaza panelinde görünmüş; fakat ERP bağlantısındaki yetki değişikliği nedeniyle kayıtlar aktarılmamıştır. Sistem hata üretmiştir, ancak uyarı eski bir çalışanın e-posta adresine gitmektedir. Ekip siparişleri elle girer. Otomasyon yeniden açılınca iki sipariş ikinci kez işlenir. Sorun bağlantının kesilmesi değildir. Hatanın sahibi ve mutabakat adımı tanımlanmamıştır.

Web sitesi üzerinden başlayan form, teklif ve müşteri akışlarında da aynı risk vardır. Bu tür süreçlerin izlenebilir mimariyle kurulması, özellikle [özel WordPress geliştirme](https://designodin.com.tr/hizmetler/wordpress/) projelerinde tasarımın sonradan eklenen parçası olmamalıdır.

## Önce kritik akışları ve kabul edilebilir kayıpları belirleyin

Her otomasyon aynı önemde değildir. Haftalık rapor e-postasının bir gün gecikmesi ile ödeme alınmış bir siparişin hiç işlenmemesi aynı müdahaleyi gerektirmez.

İlk iş, akışları “çalışıyor” ve “çalışmıyor” diye ayırmak değildir. Akışları iş etkisine göre sınıflandırın.

Akış İş etkisi Kabul edilebilir gecikme Kabul edilebilir veri kaybı Manuel yedek süreç

Yeni siparişin ERP’ye aktarımı Yüksek 15 dakika 0 kayıt Sipariş paneli her 30 dakikada kontrol edilir

Teklif formunun CRM’e aktarımı Orta 2 saat 1 kayıt Form e-postaları günlük kontrol edilir

Stok güncellemesi Yüksek 30 dakika 0 kayıt Kritik ürünler geçici olarak manuel güncellenir

Haftalık rapor e-postası Düşük 1 gün Rapor yeniden üretilir Manuel dışa aktarma yapılır

Bu tablo, teknik ekibe “daha dayanıklı sistem kurun” demekten daha işe yarar. Her akışın hangi koruma düzeyine ihtiyaç duyduğunu gösterir.

### RTO ve RPO kararını işletme verir

Burada iki kavram önemlidir:

- **RTO (Recovery Time Objective):** Sistemin yeniden çalışması için kabul edilebilir en uzun süre.

- **RPO (Recovery Point Objective):** Kabul edilebilir en fazla veri kaybı penceresi.

AWS’nin [recovery objectives rehberi](https://docs.aws.amazon.com/wellarchitected/2024-06-27/framework/rel_planning_for_recovery_objective_defined_recovery.html), bu hedeflerin kurtarma mimarisini belirlediğini açıkça tanımlar. Fakat RTO ve RPO teknik terim gibi görünse de işletme kararlarıdır.

Yeni sipariş aktarımında RTO 15 dakika, RPO ise sıfır kayıt olabilir. Haftalık raporda RTO bir iş günü, RPO ise raporun yeniden üretilmesi olabilir. Her süreç için anında geri dönüş ve sıfır veri kaybı istemek mümkündür. Ancak bu yaklaşım çoğu zaman gereksiz maliyet ve karmaşıklık yaratır.

Amaç riski tamamen yok etmek değil, iş etkisine uygun seviyeye indirmektir.

## Otomasyonda hata yönetimi için dört hata sınıfı

Hataları tek grupta toplarsanız yanlış müdahale edersiniz. Bir API’nin kısa süre yanıt vermemesi ile müşterinin geçersiz e-posta adresi göndermesi aynı tür problem değildir.

### Geçici teknik hatalar

Geçici hata, sistemde değişiklik yapmadan kısa süre sonra kendiliğinden düzelebilecek problemdir.

Örnekler:

- Ağ kesintisi veya zaman aşımı

- 429 rate limit yanıtı

- 502, 503 veya 504 sunucu hataları

- Kısa süreli bağlantı veya kimlik doğrulama problemi

Bu hatalarda doğru yaklaşım **sınırlı retry** kullanmaktır. İlk deneme başarısız olduğunda sistem hemen on yeni istek göndermemelidir. Denemeler arasındaki bekleme süresi zamanla uzamalıdır. Bu yönteme exponential backoff denir.

Örneğin üç deneme arasında sırasıyla 1 dakika, 5 dakika ve 15 dakika beklemek, sorun yaşayan servisi gereksiz isteklerle zorlamadan geçici kesintileri tolere eder.

### Kalıcı teknik hatalar

Kalıcı hata, otomasyon yeniden denense bile düzelmeyecek problemdir.

Örnekler:

- API anahtarının iptal edilmesi

- Hedef servisin kapatılması

- Endpoint veya veri şemasının değişmesi

- Yetkinin kaldırılması

Bu durumda retry çözüm değildir, yalnızca gürültü üretir. Sürekli yeniden deneme, zaten sorun yaşayan servisi daha fazla istekle zorlayabilir. Microsoft’un [yeniden deneme (Retry) deseni](https://learn.microsoft.com/en-us/azure/architecture/patterns/retry) de sürekli başarısız olan servislerde sonsuz deneme yerine devreyi geçici olarak kapatan bir yöntem (Circuit Breaker) önerir.

Yapılacak iş nettir: akışı güvenli biçimde durdurun, sorumlu kişiye bildirim gönderin ve etkilenen kayıtları koruyun.

### İş kuralı ve veri hataları

Bu kategoride kararı teknik ekipten çok operasyon ekibi vermelidir.

Örnekler:

- E-posta adresinin geçersiz olması

- Sipariş numarasının eksik gelmesi

- Ürün kodunun hedef sistemde bulunmaması

- Müşterinin CRM’de zaten kayıtlı olması

- Vergi kimlik numarası (VKN) veya teslimat bilgisinin eksik olması

Bu kaydı otomatik olarak tekrar tekrar göndermek sonuç vermez. Kaydı istisna kuyruğuna alın, veriyi düzeltin ve gerekirse denetimli biçimde yeniden işleyin.

### İnsan onayı gerektiren istisnalar

Bazı kararlar otomasyona bırakılmamalıdır. Özellikle maddi, hukuki veya müşteri ilişkileri açısından etkisi yüksek işlemlerde insan onayı gerekir.

Örnekler:

- İade tutarı ile sipariş tutarının uyuşmaması

- Stok seviyesinin eksiye düşmesi

- Olağandışı yüksek tutarlı sipariş

- Düşük güven skoruyla sınıflandırılmış AI destekli müşteri talebi

Bu noktada otomasyonun görevi işlemi tamamlamak değildir. Gerekli verileri toplar, taslağı hazırlar ve onay için doğru kişiye iletir.

**Otomasyonun amacı insanı süreçten tamamen çıkarmak değildir.** Amaç, doğru kişinin doğru istisnada yeterli bilgiyle devreye girmesidir.

## Retry her hatanın çözümü değildir

Retry faydalıdır, fakat yanlış kullanılırsa çift sipariş, çift fatura, çift e-posta veya stok hatası yaratabilir.

### Retry yapılabilecek durumlar

Aşağıdaki durumlar sınırlı yeniden deneme için çoğunlukla uygundur:

- Zaman aşımı

- Geçici ağ bağlantısı hatası

- API rate limit yanıtı

- Geçici 5xx sunucu hatası

- Kısa süreli üçüncü taraf servis kesintisi

Her denemeyi kayda alın. Kaç deneme yapıldığını, son hata mesajını ve sonraki denemenin ne zaman gerçekleşeceğini görünür tutun.

### Retry yapılmaması gereken durumlar

Aşağıdaki durumlarda yeniden deneme aynı hatayı yeniden üretir:

- Geçersiz veri nedeniyle gelen 400 seviyesi hata

- Hatalı API anahtarı veya yetki sorunu

- İş kuralı ihlali

- Eksik zorunlu alan

- İnsan onayı gerektiren işlem

- Aynı işlemin ikinci kez gerçekleşme ihtimali

Microsoft’un [Retry Pattern rehberi](https://learn.microsoft.com/en-us/azure/architecture/patterns/retry), ilk isteğin başarılı olduğu ancak yanıtın kaybolduğu senaryoya dikkat çeker. Sistem “başarısız oldu” sanıp aynı isteği yeniden gönderirse, ikinci bir işlem oluşturabilir.

### Idempotency çift işlem riskini keser

**Idempotency**, aynı istek yeniden geldiğinde sonucun ikinci kez oluşmamasıdır.

Sipariş oluşturma, ödeme alma, stok düşme ve fatura kesme gibi işlemlere benzersiz bir işlem kimliği verin. Aynı olay ikinci kez geldiğinde sistem yeni kayıt açmak yerine mevcut işlem kimliğini bulmalı ve kaydın daha önce işlenip işlenmediğini kontrol etmelidir.

Örnek senaryo: Ödeme sağlayıcısından gelen webhook’ların kısa süre geciktiği bir abonelik işletmesi düşünün. Otomasyon yanıt alamayınca aynı olayı iki kez işler ve müşterilere iki ayrı “ödemeniz alındı” e-postası gönderir. Tahsilat iki kez yapılmamıştır. Ancak destek ekibi iki gün boyunca müşteri endişelerini yönetmek zorunda kalır. Bir idempotency anahtarı bu durumu müşteri deneyimi sorununa dönüşmeden engelleyebilir.

**Kritik kural:** Bir işlemi yeniden denemeden önce, ilk denemenin gerçekten başarısız olduğunu ya da işlemi tekrar çalıştırmanın güvenli olduğunu doğrulayın.

## Çözülemeyen kayıtları ana akıştan ayırın

Her hata tüm otomasyonu durdurmamalıdır. Bunun için **dead-letter queue** (bu yazıda “istisna kuyruğu” diyoruz) kullanılır.

Dead-letter queue, normal akışta işlenemeyen kayıtların ayrı bir alanda tutulduğu yapıdır. Kayıt kaybolmaz, ancak ana kuyrukta bekleyip sonraki işlemleri de engellemez.

### Dead-letter queue ne işe yarar

İyi tasarlanmış bir istisna kuyruğu şunları sağlar:

- Hatalı kayıt ana akışı tıkamaz.

- Veri kaybolmaz.

- Teknik veya operasyon ekibi kaydı sonradan inceleyebilir.

- Sorun çözülmeden rastgele yeniden çalıştırma engellenir.

- Tekrarlayan hatalar görünür hale gelir.

İstisna kaydında en az şu bilgiler bulunmalıdır:

- İşlem kimliği

- Kaynak sistem

- Hedef sistem

- Hata kodu ve hata mesajı

- İlk hata zamanı

- Deneme sayısı

- Son deneme zamanı

- Sorumlu kişi veya ekip

- Yeniden işleme durumu

- Çözüm notu

Hata kuyruğu çöp kutusu değildir. “Sonra inceleriz” diye biriken kayıtlar, görünmeyen veri kaybının başka bir biçimidir.

Bir kaydı ana akışa yeniden göndermeden önce veriyi, şemayı, yetkiyi ve çift işlem riskini doğrulayın. Aksi halde hata kuyruğu, aynı problemin daha yavaş tekrarlandığı yere dönüşür.

## Otomasyonda yedek plan, yedek dosya demek değildir

Retry teknik bir yöntemdir. Yedek plan ise otomasyon devre dışıyken işin nasıl sürdürüleceğini tanımlar.

Kesinti anında yapılan yaygın hatalardan biri, bu iki kavramı birbirine karıştırmaktır.

Katman Amaç Örnek

Retry Geçici teknik sorunu otomatik aşmak API zaman aşımından sonra üç kontrollü deneme

Teknik fallback Alternatif teknik yol kullanmak Webhook gelmezse kaynak sistemden durum sorgulamak

Operasyonel fallback İnsanla süreci sürdürmek Sipariş panelini 30 dakikada bir kontrol etmek

Veri kurtarma Sistem ve kayıtları geri getirmek Yedekten akış tanımı ve işlem kayıtlarını geri yüklemek

### Teknik fallback

Teknik fallback, tek bir entegrasyona olan bağımlılığı azaltır. Örneğin webhook ile sipariş bildirimi alınamıyorsa sistem belirli aralıklarla kaynak sistemden en yeni siparişleri sorgulayabilir.

Bu yöntem her süreç için uygun değildir. Yine de kritik akışlarda “bildirim gelmezse ne olur?” sorusunun yanıtı olmalıdır.

### Operasyonel fallback

Otomasyon durduğunda işi insan devralır. Ancak “ekip ilgilenir” bir plan değildir.

E-ticaret siparişlerini ERP’ye aktaran otomasyonun durduğunu düşünün. Manuel devir planı şu kadar somut olmalıdır:

- **Operasyon sorumlusu:** Satış operasyonu rolü

- **Kontrol ekranı:** E-ticaret yönetim paneli

- **Kontrol sıklığı:** Her 30 dakika

- **Geçici kayıt alanı:** Kontrollü elektronik tablo veya ERP taslak ekranı

- **Mutabakat adımı:** Otomasyon geri geldiğinde sipariş numarasına göre çift kayıt kontrolü

- **Kapanış kriteri:** Son başarılı aktarım saatinden sonraki tüm siparişlerin ERP’de doğrulanması

NIST’in [contingency planning yaklaşımı](https://csrc.nist.gov/topics/security-and-privacy/security-programs-and-operations/contingency-planning), kesinti sonrası süreçlerin alternatif veya manuel yöntemle sürdürülebilmesini iş sürekliliğinin parçası olarak ele alır.

### Veri kurtarma planı

Veri kurtarma yalnızca veritabanı yedeği değildir. Otomasyonu yeniden kurabilmek için aşağıdakiler de gerekir:

- İş akışı tanımları ve sürümleri

- API anahtarları ve erişim yapılandırmaları

- Eşleme kuralları

- İşlem kayıtları

- Kuyruklar ve hata kayıtları

- Denetim logları

- Teknik dokümantasyon

- Manuel devir prosedürü

Özellikle AI destekli akışlarda insan onayı, güven skoru eşiği ve karar kaydı da tasarımın parçasıdır. [Yapay zeka ve otomasyon çözümleri](https://designodin.com.tr/yapay-zeka/) değerlendirirken, yalnızca akışın ne yaptığına değil; yanlış veya eksik çalıştığında ne yaptığına bakmak gerekir.

## Yedekleme geri yükleme testi olmadan tamamlanmaz

“Yedeğimiz var” demek tek başına güvence sağlamaz. Yedek dosyası bozuk olabilir, yapılandırmanın bir kısmını içermeyebilir veya hedeflenen sürede geri yüklenemeyebilir.

Bu nedenle yedek planının kanıtı, yedeğin alınmış olması değil, **geri yüklemenin test edilmiş olmasıdır**.

Geri yükleme testi şu soruları yanıtlamalıdır:

- Yedek dosyası gerçekten açılıyor mu?

- Son veri kaybı, belirlenen RPO hedefinin içinde mi?

- Sistem belirlenen RTO süresinde ayağa kalkıyor mu?

- Akış, hedef sistemlere yeniden bağlanabiliyor mu?

- Aynı kayıt tekrar işlenip çift sonuç yaratıyor mu?

- Erişim yetkileri ve gizli anahtarlar güvenli biçimde geri geliyor mu?

- Manuel devir prosedürü güncel mi?

Bu testi yılda bir kez, yalnızca prosedür gereği yapmak yeterli olmayabilir. Kritik sipariş, ödeme veya müşteri süreçlerinde değişiklikten sonra da test yapılmalıdır.

## Uyarı sistemi hata mesajı değil, aksiyon üretmelidir

Her hata için aynı kişiye, aynı kanaldan ve aynı aciliyet düzeyinde bildirim göndermek doğru değildir. Kritik olmayan uyarıların arasında kaybolan kritik hata, hiç uyarı göndermemekle benzer sonuç doğurur.

Seviye Örnek Bildirim Beklenen aksiyon

Kritik Sipariş veya ödeme aktarımı durmuş Anlık bildirim ve e-posta 15 dakika içinde kontrol

Yüksek CRM kaydı oluşmuyor E-posta ve görev kaydı Aynı iş günü çözüm

Orta Haftalık rapor başarısız Günlük özet Sonraki iş günü inceleme

Düşük Tekil geçersiz alan İstisna kuyruğu raporu Toplu inceleme

“Teknik ekibe bildirim gider” demek yeterli değildir. Uyarıyı kimin alacağı, o kişiye ulaşılamazsa ne olacağı ve kaç dakika ya da saat içinde aksiyon beklendiği yazılı olmalıdır.

Örnek senaryo: Form-CRM entegrasyonunun CRM API limitine takıldığı bir hizmet işletmesi düşünün. Uyarı yalnızca tek bir kişinin hesabına gidiyor ve o kişi ulaşılamıyor. Satış ekibi iki gün boyunca yeni talepleri yalnızca form e-postalarından manuel izler. Kayıtların büyük bölümü kurtarılır, ancak iki teklif talebi geç yanıtlandığı için kaybedilebilir. Bir bildirim kanalı vardır, fakat sahibinin kim olduğu belli değildir.

## Canlıya çıkmadan önce test edilecek 10 hata senaryosu

Otomasyon, yalnızca “başarıyla çalışıyor” diye canlıya alınmaz. Başarısızlık anındaki davranışı görülmeden güvenilir kabul edilmemelidir.

Test planınıza şu senaryoları ekleyin:

- Hedef API 10 dakika boyunca yanıt vermiyor.

- API rate limit yanıtı dönüyor.

- Aynı webhook iki kez geliyor.

- Webhook hiç gelmiyor.

- Kaynak sistemde eksik veya hatalı veri bulunuyor.

- API anahtarı geçersiz hale geliyor.

- Hedef sistemin veri şeması değişiyor.

- Otomasyon işlem ortasında kesiliyor.

- Aynı kayıt manuel olarak da işleniyor.

- Son yedekten geri yükleme yapılıyor.

Her test için yalnızca “başarılı” veya “başarısız” kaydı tutmayın. Beklenen davranışı, gerçekleşen sonucu, sorumlu kişiyi ve varsa düzeltme tarihini de kaydedin.

## Ajansa veya teknik ekibe sorulacak sorular

Otomasyon teklifi veya mevcut akış değerlendirmesinde şu soruların açık yanıtı bulunmalıdır:

- Hata olduğunda hangi kayıtların kaybolma riski var?

- Hangi hatalarda retry uygulanıyor; kaç kez ve hangi aralıklarla?

- Aynı işlem iki kez tetiklenirse ne olur?

- Çözülemeyen kayıtlar nerede tutuluyor?

- Hata bildirimi kime, hangi sürede gidiyor?

- Otomasyon tamamen durursa manuel süreç nedir?

- İş akışı, yapılandırma ve loglar nerede yedekleniyor?

- Geri yükleme en son ne zaman test edildi?

- Akışın ve entegrasyon kodunun sahipliği kimde?

- Sistem değiştiğinde güncel dokümantasyon teslim ediliyor mu?

Bu soruların yanıtı belirsizse otomasyon kurulmuş olabilir. İş sürekliliği kurulmuş değildir.

## Otomasyonun güvenilirliği hızından önce gelir

Hızlı çalışan ama hata anında veri kaybeden otomasyon iş sürecini iyileştirmez. Sorunu yalnızca daha geç fark edilen hale getirir.

Güvenilir bir akış, sınırlı retry, idempotency kontrolü, istisna kuyruğu, insan onayı, manuel devir ve geri yükleme testini baştan içerir. Bunlar sonradan eklenen teknik ayrıntılar değildir. Otomasyonun işletmeye zarar vermeden çalışmasının koşullarıdır.

Kritik akışlarda hata senaryosu, sorumlu kişi, veri sahipliği ve manuel yedek süreç işe başlamadan önce yazılmalıdır. Böylece sistem, belirsiz WhatsApp grupları ve kimin ilgileneceği belli olmayan hata mesajlarıyla ayakta tutulmaz.

## Sık Sorulan Sorular

### Otomasyonda hata yönetimi nedir?

Otomasyonda hata yönetimi, bağlantı kopması, hatalı veri, API limiti veya yetki sorunu gibi durumlarda akışın nasıl davranacağını belirleyen kurallar bütünüdür. Amaç sadece hata mesajı göstermek değildir. Veri kaybını, çift işlemi ve operasyonun durmasını önlemektir.

### Retry mekanizması her hata için kullanılmalı mı?

Hayır. Retry, geçici ağ kesintisi, zaman aşımı veya rate limit gibi kısa süreli sorunlarda uygundur. Hatalı veri, geçersiz yetki veya iş kuralı ihlalinde yeniden deneme aynı hatayı tekrar üretir.

### Dead-letter queue nedir?

Dead-letter queue, normal akışta işlenemeyen kayıtların ana kuyruğu tıkamadan tutulduğu ayrı bir alandır. Kayıt kaybolmaz. Ekip sorunu inceleyip düzelttikten sonra kaydı kontrollü biçimde yeniden işleyebilir.

### Otomasyonda yedek plan ne demektir?

Yedek plan, otomasyon teknik olarak çalışmadığında işin nasıl sürdürüleceğini tanımlar. Alternatif teknik akışı, insanın uygulayacağı manuel süreci ve gerekirse veri geri yükleme adımlarını kapsamalıdır.

### RTO ve RPO ne anlama gelir?

RTO, sistemin en fazla ne kadar süre kapalı kalabileceğini ifade eder. RPO ise kabul edilebilecek en yüksek veri kaybı penceresidir. RPO’su 15 dakika olan bir süreçte kesinti yaşanırsa, en fazla son 15 dakikalık verinin kaybedilip yeniden girilmesi kabul edilebilir demektir.

### Aynı işlemin iki kez çalışmasını nasıl önlersiniz?

Benzersiz işlem kimliği veya idempotency key kullanılır. Sistem aynı sipariş, ödeme ya da müşteri kaydını ikinci kez aldığında yeni işlem başlatmaz. Mevcut işlemi tanır ve sonucu yeniden üretmez.

### Yedek almak neden yeterli değildir?

Bir yedek dosyasının bulunması, geri yüklemenin çalışacağını kanıtlamaz. Yedek bozuk olabilir, eksik yapılandırma içerebilir veya hedeflenen sürede geri dönmeyebilir. Bu nedenle düzenli geri yükleme testi gerekir.

**Kritik akışlarınız hata anında da işlemeye devam etsin.**

Form, CRM, teklif ve sipariş süreçlerinde hata senaryosu, manuel devir ve veri sahipliği en baştan tanımlanmalıdır. Kapsamı yazılı olarak çıkarır, belirsiz noktaları proje başlamadan görünür hale getiririz.

[Projenizi anlatın, yazılı teklif verelim.](https://designodin.com.tr/iletisim/)

- #otomasyon
- #hata-yonetimi
- #is-surekliligi

## Bu konu sizin işinizde nasıl karşılık buluyor?

Genel geçer cevaplar yerine, sizin durumunuza bakalım. Kapsamı ve teklifi yazılı olarak veririz — satış baskısı yok.

[Projenizi anlatın →](https://designodin.com.tr/iletisim/)