Başarısız otomasyon: yeniden denemeden önce neleri kontrol etmeli?

Bir otomasyon hata veriyor ve birisi «Yeniden Dene» tuşuna basmayı öneriyor. Önce daha somut bir soruyu yanıtlamak gerekir: Ne yapılması gerekiyor? Eylem, onayı veya sonraki bir adım eksik olabilir. Tüm akışı tekrarlamak bu durumlardan biri için işe yarar ve diğerlerini kötüleştirebilir.

Bir kurucu veya küçük bir ekip için, entegrasyonu kuran kişi olmasa bile araştırma devam edebilmelidir. Bu kılavuz, doğrulanmış olanı bilinmeyenden ayırmak için bir zaman çizelgesi ve bir olay kayıt formu sunmaktadır. Örnek kurgusaldır: Frihet’e ait bir olayı tanımlamaz veya gerçek hizmetler, müşteriler veya kimlik bilgileri kullanmaz.

Ekran Hatası ve İşin Durumu

Bir timeout, bir beklemenin zamanında bir yanıt olmadan sona erdiğini gösterir. Kendi başına hedefin bir şey kaydedip kaydetmediğini anlamaya izin vermez. AWS bu sorunu talep eden kişinin onay almamasına rağmen bir kaynak oluşturmuş olabilecek bir istekle açıklar. Bu belirsizliği çözmek, etkiyi ve kaynağını tanımlamayı gerektirir.

Üç durumla çalışın: onaylanmış etki, onaylanmış etki yokluğu ve bilinmiyor. «Ekranımda görünmüyor» ifadesi, filtreler, başka bir hesap, gecikmiş bir dizin veya hala aktif bir yürütme olabileceği sürece üçüncü duruma aittir. Ayrıca durumu kimin ve saat kaçta kontrol ettiğini de not alın: bir gözlem bağlama sahiptir, sonsuz geçerliliğe sahip değildir.

Kararı Değiştiren Bir Zaman Çizelgesi

Dahili bir görev oluşturan ve ardından referansını bir takip sayfasına kaydeden bir akış olduğunu varsayalım. Aşağıdakilerin hepsi varsayımsaldır. Zamanlar aynı simüle edilmiş saati kullanır; gerçek bir araştırmada her zaman damgasının zaman dilimini ve kaynağını koruyun.

Bir sonraki adım, belgelenmiş prosedürü kullanarak takibi kurtarmaktır. «Görev oluştur» adımından yeniden başlatmak, zaten çözülmüş bir şeye tekrar dokunmak anlamına gelir. Eğer son satır sadece «sayfada görmüyorum» deseydi, oraya yazmadan önce yine de gecikme, filtre veya aktif bir süreç olasılığını elememiz gerekirdi.

İşlem referansı sabit kalır; deneme tanımlayıcısı her yürütmede değişir. Alınan bir olay ve oluşturulan bir görev de farklı kimliklere sahiptir. Aynı işin iki denemesini iki meşru iş ile karıştırmamak için ilişkilerini koruyun.

Başka Birinin Devam Edebileceği Bir Kayıt Formu Tutun

Mevcut kayıtları koruyarak ve bu akış için öngörülen duraklatma mekanizmasıyla yeni yazma işlemlerini durdurarak başlayın. Bir duraklatma, yürütülenleri geri almaz veya halihazırda devam eden istekleri durdurmayı garanti etmez. Başka kimsenin işlem yapmayacağını varsaymadan önce kuyruğu ve bekleyen yeniden denemeleri kontrol edin.

Bu formu uygun erişime sahip dahili bir kayda kopyalayın. Paylaşılan belgelere sırları veya kişisel verileri yapıştırmaktan kaçınarak kanıtlara referanslar kullanın. Her düzeltme, önceki gözlemi silmeden tarihle eklenmelidir.

Olay: [dahili referans]
İstenen işlem: [tek ve somut bir sonuç]
Sağlayıcı / hesap / ortam: [hedefin bağlamı]
İşlem / olay / denemeler: [ID'ler ve ilişkiler]
Akışın versiyonu: [çalıştırılan versiyon]
Onaylanan son adım: [kanıt ve zaman dilimiyle birlikte saat]
Etkinin durumu: [onaylandı / onaylanmış yokluk / bilinmiyor]
Hedefin kanıtı: [referans, sorgu ve görünürlük sınırları]
Hala aktif olan iş: [istekler, kuyruk ve bekleyen yeniden denemeler]
Yeniden deneme sözleşmesi: [dokümantasyon, kapsam ve zaman aralığı]
Eksik veri: [karar vermek için gerekli kanıt]
Sonraki eylem: [sınırlı sorgu veya kurtarma]
Sorumlu / sonraki inceleme: [kişi ve tarih]
Sonraki sonuç: [yeni kanıt, önceki kaydın üzerine yazmadan]

«Onaylanmış yokluk», boş bir aramadan daha güçlü bir kanıt gerektirir: örneğin, hedefin belgelediği yürütme öncesi bir ret ve diğer denemelerin de herhangi bir sonuç üretmediğinin doğrulanması. Bu durumu haklı çıkaramıyorsanız, «bilinmiyor» olarak tutun.

İdempotens Anahtarının Sınırları Vardır

Belirli istek, hesap ve ortam için sağlayıcının sözleşmesini kontrol edin. Bir yazma işlemini koruyan bir anahtar, sonraki bir bildirimi veya başka bir hizmeti otomatik olarak korumaz. Ayrıca, anahtar olmadan zaten gönderilmiş bir isteğe geriye dönük olarak eklenemez. Form, yalnızca «idempotensimiz var» demek yerine ilgili dokümantasyonu bağlantılamalıdır.

Stripe’da, idempotens istekler — API v1, 500 hataları da dahil olmak üzere ilk yürütmenin kaydedilmiş sonucunu yeniden kullanır. Stripe parametreleri karşılaştırır ve anahtarları en az 24 saat sonra silebilir; silinmiş bir anahtarı yeniden kullanmak başka bir isteği başlatır. Hata kılavuzu, 500 sonrası olası etkiler hakkında uyarıda bulunur: anahtarı değiştirmek veya süresinin dolmasını beklemek, belirsiz bir eylemi tekrarlamanın güvenli olduğunu kanıtlamaz.

Yukarıdaki süre Stripe’a aittir. Başka bir hedef için, kendi zaman aralığını, tekrarlandığını düşündüğü kimliği ve eşzamanlı isteklerin işlenişini not edin. Bir kurtarma işlemi parametreleri değiştirmeyi gerektiriyorsa, bunu önceki etkilerin gözden geçirilmesiyle birlikte yeni bir karar olarak ele alın.

Kanıtlardan Yola Çıkarak, Adım Adım Karar Verin

Aşağıdaki tablo, evrensel bir sağlayıcı politikası değil, önerilen bir işletim kriteridir. Araştırmayı, veri değiştirme yetkisinden ayırın.

Geri alınamaz veya yüksek etkili yazma işlemleri, önerilen kurtarma işleminin insan tarafından incelenmesini gerektirir. Ne bir anahtar ne de yeşil bir düğme, tüm yolculuk boyunca «tam olarak bir kez» garantisi sunar.

Kimin Yeniden Deneyeceğini de Kontrol Edin

Otomasyon aracı, API istemcisi ve sağlayıcının kendi yeniden denemeleri olabilir. Stripe web kancalarında (webhooks), manuel bir yeniden gönderme otomatik yeniden denemeleri iptal etmez; ayrıca olaylar tekrarlanabilir ve sırasız gelebilir. Bir olayı yeniden göndermek, bir API yazma işlemini idempotens bir şekilde tekrarlamakla eşdeğer değildir: bunlar farklı mekanizmalardır.

Formu kapatmadan önce hedefin mevcut durumunu, bekleyen adımları ve sonradan gelebilecek denemeleri kontrol edin. Bir sonraki yürütmeyi kimin gözlemleyeceğini belirleyin. Formu kapatmak, işi çözmekle eşdeğer değildir: eğer bilinmeyen bir sonuç kalıyorsa, sorumlusu ve inceleme tarihi ile olayı açık tutun.

Daha sonra, akışın gereksiz işleri kaldırma, otomatikleştirme ve devretme yaklaşımı (İngilizce) kriteriyle otomatikleştirilmeye devam etmeyi hak edip etmediğini gözden geçirebilirsiniz. Eğer Frihet bağlantısı varsa, ilgili arayüzü bulmak için geliştirici dokümantasyonu ve entegrasyon kataloğu kısmından başlayın. Bu formu akışın yanında saklayın: bir sonraki kişi, son kontrol edilmiş durumu bir sohbetten yeniden oluşturmak zorunda kalmadan bulabilmelidir.

14 Eylül 2026 tarihinde başvurulan teknik kaynaklar. Formlar, kararlar ve DEMO referansları kendi eğitim önerilerimizdir; gerçek bir hizmette değişiklikleri uygulamak için talimatlar değildir.