Otomasyon akışlarında hata yakalama, yeniden deneme ve toparlanma tasarımı

Otomasyon neden bozulur, hata yönetimi neden ayrı bir beceridir?

Bir otomasyon çalışırken dışarıdaki birçok şeye bağımlıdır: başka bir uygulamanın hizmeti, bir kullanıcının girdiği veri, bağlantı izinleri, ağ erişimi. Bunlardan biri değiştiğinde akış durur ya da, daha kötüsü, yanlış çalışmaya devam eder. Kurulumu yapan kişi 'her şey yolunda giderse' senaryosunu tasarlar; hata yönetimi ise yolunda gitmeyen durumları önceden düşünme işidir.

Hata yönetimi yokluğunun bedeli çoğu zaman gecikmeli ortaya çıkar. Haftalarca sessizce hata veren bir akış, müşteriye gitmeyen e-postalar, kaydedilmeyen siparişler ya da eksik raporlar bırakır. Bu yüzden iyi bir otomasyon yalnız doğru çalışmakla değil, bozulduğunda da fark edilebilir ve onarılabilir olmakla ölçülür.

Aşağıdaki yöntem kodsuz ve düşük kodlu araçların (Make, Zapier, n8n gibi) hepsinde uygulanabilir. Arayüz adları araçtan araca değişir, ancak mantık aynıdır.

Önce hatayı sınıflandırın: geçici mi, kalıcı mı, veri kaynaklı mı?

Her hataya aynı tepkiyi vermek yanlıştır. Önce hatanın türüne bakılır: • Geçici hata: Karşı servis kısa süre yanıt vermedi, ağ kesildi ya da istek sınırına takıldınız. Biraz bekleyip yeniden denemek çözer. • Kalıcı hata: Yetki iptal oldu, hesap silindi, kaynak yok ya da alan adı değişti. Yeniden denemek sonucu değiştirmez; biri müdahale etmelidir. • Veri hatası: Gelen kayıt eksik, biçimsiz ya da beklenmeyen değer içeriyor. Akışın tamamını durdurmak yerine o kaydı ayırıp inceleme sırasına almak gerekir. • Mantık hatası: Akış hata vermeden yanlış sonuç üretiyor; yanlış alana yazıyor, yanlış kişiye gönderiyor. Bu tür hatalar en tehlikelisidir çünkü kimse uyarılmaz. Doğrulama kontrolleriyle yakalanır.

Sınıflandırma, tepkiyi belirler. Geçici hatada otomatik yeniden deneme, kalıcı hatada bildirim ve duraklatma, veri hatasında karantina ve inceleme, mantık hatasında ise doğrulama ve örnekleme kontrolleri uygulanır.

Yeniden deneme mantığı: ne zaman, kaç kez, ne kadar bekleyerek?

Yeniden deneme yalnız geçici hatalar için anlamlıdır. Her denemede bekleme süresini katlayarak artırmak, karşı servisin toparlanmasına zaman tanır ve onu istek yağmuruyla boğmaz. Bekleme süresine küçük bir rastgelelik eklemek, birçok akışın aynı anda yeniden denemesini engeller. Deneme sayısına bir üst sınır koyun; sonsuz yeniden deneme hem maliyet hem sorun yaratır.

Sınır dolduğunda ne olacağı da tasarlanmalıdır. Başarısız kaydı kaybetmek yerine 'başarısız işler' diye ayrı bir kuyruğa ya da tabloya yazın: ne zaman, hangi akış, hangi veri, hangi hata. Bu kayıt hem inceleme hem de sorun giderildikten sonra yeniden işleme için gereklidir.

Kodsuz araçların çoğu yeniden deneme, hatayı yoksayma ya da alternatif dala geçme seçeneklerini sunar. Hangi seçeneğin hangi adım için uygun olduğunu şöyle düşünün: Önemsiz bir bildirim adımı başarısız olursa akış devam edebilir; kayıt oluşturma adımı başarısız olursa sonraki adımlar çalışmamalıdır. Her adımın akış için ne kadar kritik olduğunu belirlemek, doğru tepkiyi seçmenin temelidir.

Mükerrer işlem riski: yeniden deneme güvenli mi?

Yeniden deneme tehlikeli bir tuzak taşır: işlem aslında başarılı olmuş ama yanıt gelmemişse, tekrar denemek aynı işi yeniden yapar. Aynı müşteriye mükerrer e-posta gitmesi can sıkıcıdır; aynı ödemenin tekrar alınması ya da aynı siparişin tekrar açılması ise ciddi bir sorundur.

Bunu önlemenin yolu, işlemlerin tekrarlandığında aynı sonucu vermesidir. Bu özelliğe tekrarlanabilirlik denir. Pratik yöntemler: • Her işleme benzersiz bir kimlik verin ve işlemden önce 'bu kimlikle kayıt var mı' diye kontrol edin. • Kayıt oluşturmak yerine 'varsa güncelle, yoksa oluştur' mantığını kullanın. • Bildirimlerde, gönderilmiş olanları bir tabloda işaretleyin ve işaretlilere yeniden göndermeyin. • Para ve stok gibi kritik işlemlerde dış sistemin sunduğu tekrar koruma mekanizmalarını kullanın.

Örneğin sipariş akışında 'siparişi muhasebe sistemine yaz' adımı zaman aşımına uğradıysa, yeniden denemeden önce sipariş numarasıyla muhasebe sisteminde arama yapılır. Kayıt varsa deneme sonlanır, yoksa yazılır.

Bildirim, kayıt ve görünürlük: hata kimseye duyulmadan ölmemeli

Hata yönetiminin en az maliyetli ama en çok ihmal edilen parçası görünürlüktür. Her kritik akış için kimin, nasıl haberdar edileceği önceden belirlenmelidir.

İyi bir hata bildirimi şu bilgileri taşır: hangi akış, hangi adım, ne zaman, hangi kayıt, hata mesajı ve olası ilk müdahale. Bildirimi yalnız bir kişiye göndermeyin; paylaşımlı bir kanala ya da bir nöbet listesine yönlendirin. Çok sık gelen gürültülü bildirimler ise zamanla göz ardı edilir; geçici hatalarda yeniden deneme başarılı olduysa bildirim göndermeyin, yalnız sonunda başarısız olanları bildirin.

Görünürlüğü artıran diğer uygulamalar: • Her çalıştırmayı kimlikle ve zamanla kayda geçirin. • Başarı ve hata sayısını haftalık bir özet olarak raporlayın. • 'Hiç çalışmama' durumunu da izleyin: Bir akış normalde her gün çalışırken sessiz kalmışsa, bu da bir hatadır. Bunu yakalamak için beklenen çalışma gelmediğinde uyarı veren kontrol akışı kurulabilir.

Girdi doğrulama, insan müdahalesi ve toparlanma planı

Hataların büyük bölümü akışın içinde değil, girdide başlar. Gelen veriyi işlemeden önce doğrulayın: zorunlu alanlar dolu mu, e-posta ve telefon biçimi geçerli mi, tutar beklenen aralıkta mı, kayıt daha önce işlendi mi? Doğrulamayı geçemeyen kayıt, akışın ortasında hata vermek yerine başta ayrılır ve incelemeye alınır.

Bazı kararlar otomasyona bırakılmamalıdır. Tutarı yüksek işlemler, müşteriye gidecek hassas iletiler ve yapay zeka çıktısına dayanan yanıtlar için araya bir insan onayı koymak, hatanın etkisini sınırlar. Onay adımında karar bekleyen kayıtların da süresi dolmamalı; bekleyen işlerin listesi görünür olmalıdır.

Toparlanma planı ise şu soruları yanıtlar: Akış durduysa kayıtlar nerede bekler? Sorun çözülünce kaçırılan kayıtlar nasıl işlenir? Yanlış işlenmiş kayıtlar nasıl geri alınır? Bir sipariş tamamlanmadan kaldıysa önceki adımların etkisi nasıl telafi edilir? Bu planı akış kurulurken yazmak, olay anında panikle karar vermekten çok daha ucuzdur.

Sık yapılan hatalar ve kontrol listesi

• Hata bildirimi kurmadan canlıya almak. Önlem: her kritik akışa bildirim ve sahip atayın.
• Her hatayı yeniden denemek. Önlem: geçici ve kalıcı hatayı ayırın.
• Sınırsız yeniden deneme. Önlem: deneme sayısı ve bekleme süresine üst sınır koyun.
• Başarısız kaydı kaybetmek. Önlem: kuyruk ya da tabloya yazın.
• Tekrarlanabilirliği düşünmemek. Önlem: kimlik ve varlık kontrolü ekleyin.
• Mantık hatasını göz ardı etmek. Önlem: örneklemeyle düzenli kontrol yapın.
• Hatayı yoksayma seçeneğini kolaylık için kullanmak. Önlem: yoksayma yalnız önemsiz adımlarda ve gerekçesiyle kullanılsın.

Canlıya almadan önce kısa bir kontrol: Her adımın hata durumunda ne yapacağı belli mi? Bildirimin sahibi var mı? Aynı kayıt tekrar işlenirse ne olur? Kayıt kaybolursa nereden bulunur? Sorun giderilince bekleyen kayıtlar nasıl yeniden işlenir?

Mindset programlarında bu beceriyi nerede çalışırsınız?

n8n ile Kod Yazmadan AI Asistanı Tasarımı Eğitimi; n8n arayüzü ve iş akışı tasarımı, veri kaynakları ve API bağlantıları, gelişmiş özellikler ve otomasyon senaryoları, kendi AI asistanını yayına alma ve ölçekleme modül başlıklarına sahiptir. Akışların gelişmiş senaryolarla yayına alınması ve ölçeklenmesi, hata ve yeniden deneme mantığının pratik karşılığıdır. Operasyon ve otomasyon uygulayıcıları ile yapay zeka asistanı kuran ekipler için uygundur.

Yapay Zeka ve Otomasyon Uzmanlığı Sertifika Programı - Uygulamalı ise no-code otomasyon temelleri ve AI destekli otomasyon tasarımı ile veri doğrulama ve eleştirel kullanım başlıklarını içerir; yapay zeka çıktısını doğrulamak, girdi ve çıktı doğrulama mantığıyla birleşir. Kurumsal ekipler için içeriğin uyarlanmasını Mindset kurumsal eğitim ekibiyle görüşebilirsiniz.