eber
Yapay zeka destekli bir iş akışı kayıt oluştururken zaman aşımına uğrarsa, yani beklenen sürede yanıt alamazsa, hemen yeniden göndermeyin. Önce hedef sistemde işlemin sonucunu doğrulayın. Kayıt oluşmuş olabilir; ekranın yanıt vermemesi, işlemin yapılmadığını göstermez. Tekrarın ikinci bir kayıt oluşturmayacağı doğrulanmadıysa sonuç belirsizken yeniden göndermeyi bekletin.
Bu ayrım özellikle talep açan, görev atayan veya başka bir yazılıma kayıt aktaran akışlarda önemlidir. Microsoft’un yeniden deneme rehberi, bir hizmetin işlemi tamamladığı hâlde yanıtı iletemeyebileceğini açıklar. Bu durumda aynı isteği tekrar göndermek ikinci bir kayıt oluşturabilir.
Aynı bakım talebini iki kez açmayın
Kurgusal bir örnek düşünelim: Çalışan, toplantı odasındaki arızalı klima için mesaj gönderiyor. Yapay zeka mesajı özetliyor; çalışan özeti onaylıyor ve otomasyon bakım sisteminde iş emri açıyor. Tam bu sırada bağlantı kesiliyor.
Çalışan “Gönderilemedi” uyarısını görünce yeniden basıyor. Arka plandaki otomasyon da tekrar deniyorsa aynı ihtiyaç için iki iş emri açılabilir. Bakım ekibi hangisinin geçerli olduğunu araştırmak, talep sahibi de durumunu yeniden anlatmak zorunda kalır.
Burada ihtiyaç, daha iyi bir özetten önce hata durumunda ne yapılacağının belli olmasıdır. Süreç otomasyonu tasarımında işlemi kimin takip edeceğini ve belirsizliğin nasıl çözüleceğini de belirleyin.
Sonucu dört durumdan biriyle kaydedin
Aşağıdaki tabloyu mevcut iş akışınıza uyarlayabilirsiniz. Bu, belirli bir ürünün hazır özelliği değil; iş ve teknik ekiplerin birlikte dolduracağı bir karar çalışma sayfasıdır.
| Gözlenen durum | Ekip ne yapmalı? | Sonucu doğrulayan bilgi |
|---|---|---|
| İş emri oluştuğu doğrulandı | Yeniden oluşturmayın; mevcut kaydı gösterin. | Hedef sistemdeki kayıt kimliği ve talep eşleşmesi |
| İşlem hâlâ sürüyor | Yeni gönderimi bekletin; mevcut işlemi izleyin. | İşlemin tamamlandığını veya sonlandığını bildiren durum |
| İşlemin gerçekleşmediği kesinleşti | Hatanın nedenini inceleyin; uygunsa kontrollü tekrar planlayın. | Hedef sistemin güvenilir durum bilgisi |
| Sonuç bilinmiyor | Tekrarın ikinci bir kayıt oluşturmayacağı doğrulanmadıysa otomatik ve elle yeniden göndermeyi durdurun; sorumluya aktarın. | Mevcut talebin sonucunu açıklığa kavuşturan inceleme |
Bir aramada kayıt bulamamak tek başına üçüncü satıra geçmek için yeterli olmayabilir. Sistemin kayıtları ne zaman görünür kıldığını ve durum sorgusunun neyi garanti ettiğini teknik ekibinizle netleştirin. Ayrıntılı bağlantı hazırlığı için mevcut yazılıma yapay zeka bağlantısı rehberine bakabilirsiniz.
Her denemeye değil, işleme kimlik verin
Teknik ekipten şu ayrımı göstermesini isteyin: “Klima için iş emri oluştur” bir işlemdir; bağlantı sorunu nedeniyle tekrar göndermek aynı işlemin yeni denemesidir. Her denemede yeni işlem kimliği üretmek bu ilişkiyi kaybettirir.
Teknik adıyla idempotent bir işlem, aynı istek tekrarlandığında ek bir iş sonucu üretmez. Bunu destekleyen servisler aynı isteği tanımak için bir anahtar kullanabilir. Ancak bir anahtar eklemek tek başına koruma sağlamaz; hedef sistemin bunu nasıl işlediği belirleyicidir. AWS’nin idempotent API rehberi, isteği gönderen sistemin verdiği kimliği, aynı kimlikle farklı içerik gönderilmesini ve kimliğin ne kadar süre saklandığını ayrı tasarım konuları olarak ele alır.
Servis aynı anahtarla tekrarı güvenli biçimde destekliyorsa, belgelenmiş sınırlar içinde otomatik tekrar yapılabilir. Bu güvence yoksa belirsiz sonuç önce araştırılır.
Bakım örneğinde ilk gönderimin kimliği, onaylanmış talep içeriği ve varsa hedef kayıt kimliği birlikte tutulmalıdır. Arıza yeri sonradan değişirse bunu sessizce eski isteğin tekrarı saymayın; önceki işlemin durumunu açıklığa kavuşturup değişikliğin nasıl uygulanacağını belirleyin.
Yeniden deneme kararını tek yerde toplayın
Çalışan ekranındaki düğme ile arka plan otomasyonu birbirinden habersiz hareket etmemeli. Güvenli tekrar desteği bulunmayan bakım sistemi için şu çalışma kuralını yazabilirsiniz: “Sonuç belirsizken yeni talep açılmaz. İncelemeyi görevli kişi devralır; sonucu kaydetmeden otomatik akış yeniden başlatılmaz.”
Geçici bağlantı hataları için sınırlı ve aralıklı tekrarlar düşünülebilir. Yetki veya geçersiz veri sorununda ise aynı isteği tekrarlamak yerine neden düzeltilmelidir. Microsoft’un yeniden deneme stratejileri rehberi, iç içe tekrar mekanizmalarının gecikmeyi artırabileceğine dikkat çeker. Tekrar kuralları hata türüne göre belirlenmelidir.
Bu kuralların uygulanması için yazılım geliştirme ve entegrasyon çalışmasının kapsamına yalnızca başarılı senaryoyu değil, kesinti ve yeniden başlatma testlerini de alın.
Ekibinizle dolduracağınız kontrol kartı
Bir sonraki toplantıda tek bir akış seçip şu alanları doldurun:
- İşlem: Hangi kaydı oluşturuyoruz ve kim onaylıyor?
- Kimlik: İlk gönderimi sonraki denemelere nasıl bağlıyoruz?
- Doğrulama: Sonucu hangi sistemden, hangi bilgiyle kontrol ediyoruz?
- Belirsizlik: Ne zaman duruyoruz ve kim devralıyor?
- Tekrar sınırı: Hangi hatalarda, hangi sınırlarla yeniden deniyoruz?
- Kapanış: Çalışan işin tamamlandığını nereden görecek?
Ardından gerçek iş emirlerini etkilemeyen bir test ortamında üç deneme yaptırın: kayıt oluşup yanıt kaybolsun; çalışan iki kez göndersin; bağlantı kesildikten sonra uygulama yeniden başlasın. Her denemede aynı bakım ihtiyacının izini sürün. Sonuç yalnızca “hata göstermedi” olmamalı: tek bir geçerli iş emri oluşmalı, doğru kayda ulaşılmalı, belirsiz durum görünür kalmalı ve devralan kişi ne yapacağını bilmelidir.
Bu kartı doldurmakta zorlanıyorsanız otomatik tekrar ayarından önce iş akışını netleştirin. Yapay zeka danışmanlığı kapsamında süreç ve pilot değerlendirmesi, hangi adımın otomasyona bırakılacağını ve kabul ölçütlerinin ne olacağını belirlemek için kullanılabilir. Başlangıç sorusu basittir: Bağlantı koptuğunda işin sonucunu kimin, nasıl doğrulayacağı belli mi?
