Bir n8n akışını çalıştırmak ile o akışı üretime almak arasında, çoğu ekibin fark ettiğinden daha büyük bir mesafe var. Demoda her şey yolunda gider: form dolar, kayıt açılır, bildirim düşer. Üretim başka bir yer — gecenin üçünde dış servis 502 döndüğünde, aynı webhook iki kez geldiğinde, üç ay önce kurulan bağlantının yetkisi sessizce dolduğunda ne olduğuyla ilgilenir.

Bu yazı, bir iş akışını pilottan çıkarıp kimsenin başında beklemesi gerekmeyen bir sisteme dönüştürmenin adımlarını anlatıyor. n8n üzerinden anlatıyorum ama idempotency, hata yolu, izleme gibi başlıkların çoğu Make ve Zapier için de aynen geçerli.

Uçtan uca ne demek, ne demek değil

"Uçtan uca" ifadesi genelde "süreç baştan sona otomatik" anlamında kullanılıyor. Pratikte daha yararlı bir tanım şu: akış bir hafta boyunca kimse bakmadan çalışabiliyorsa üretimdedir. Bu tanım kulağa iddialı gelebilir ama ayırt edici olan tam da bu. Haftada iki kez birinin girip "bakayım çalışmış mı" demesi gereken bir akış otomasyon değil, yeri değişmiş manuel iştir.

Pilot akış mutlu yolu kapsar. Üretim akışı mutsuz yolları da kapsamak zorundadır: dış sistemin yavaşladığı, verinin beklenen formatta gelmediği, aynı olayın tekrarlandığı, kimlik bilgisinin süresinin dolduğu durumlar. Kurulum süresinin büyük bölümü de zaten oraya gider. Kabaca oran şöyle: mutlu yolu kurmak işin üçte biri, geri kalanı dayanıklılık.

Hangi süreç uçtan uca otomasyona uygun?

Üç ölçüt kullanıyorum. Üçü birden sağlanmıyorsa süreci ya daraltıyoruz ya da listenin altına alıyoruz.

1. Tekrar sayısı ölçülebilir olmalı

"Çok vakit alıyor" yeterli değil. Haftada kaç kez yapıldığı ve her seferinde kaç dakika sürdüğü yazılabilmeli. Bu sayı hem önceliklendirmeyi hem de sonradan "işe yaradı mı" sorusunun cevabını mümkün kılıyor. Haftada 40 kez tekrarlanan 6 dakikalık bir iş, ayda yaklaşık 16 saat demek — bu, birkaç günlük kurulum emeğini rahatlıkla karşılar. Haftada 2 kez yapılan 10 dakikalık iş ise genellikle karşılamaz.

2. Kural yazıya dökülebilir olmalı

Süreci yapan kişiye "hangi durumda ne yapıyorsun" diye sorduğunuzda cevap "duruma bakıyorum" ise, orada otomatikleştirilecek bir kural yok demektir. Böyle süreçlerde önce kararın kendisini netleştirmek gerekiyor; bu çoğu zaman otomasyondan bağımsız olarak da faydalı oluyor. İstisnası çok olan süreçlerde iyi bir ara çözüm var: akış kararı vermez, hazırlık yapar ve onayı insana bırakır.

3. Hata maliyeti geri alınabilir olmalı

İlk otomatikleştirilecek süreç, yanlış çalıştığında müşteriye yanlış fatura kesen süreç olmamalı. Yanlış etiketlenmiş bir talep, eksik doldurulmuş bir CRM kaydı, geç gitmiş bir bildirim — bunlar düzeltilebilir hatalar. Para hareketi, resmi bildirim ve dışarıya giden taahhüt içeren adımlar ilk turda değil, akışa güven oluştuktan sonra devreye alınır.

Akışın iskeleti: tetikleyici, adımlar, karar noktaları

Her akış bir tetikleyiciyle başlar ve tetikleyici seçimi sonradan en çok pişmanlık üreten karardır.

Webhook mümkünse tercih edilir: olay olduğu anda gelir, boşuna sorgu yapılmaz. Karşılığında iki yükümlülük getirir — aynı olayın birden fazla kez gelebileceğini kabul etmek ve gelen isteği doğrulamak (imza ya da paylaşılan gizli anahtar).

Zamanlanmış sorgulama (Schedule) karşı tarafta webhook yoksa kalan yoldur. Burada kritik nokta, "en son nereye kadar aldım" bilgisinin bir yerde tutulması. Bunu tutmazsanız akış ya aynı kayıtları tekrar işler ya da bir çalıştırmayı kaçırdığında arasındaki veriyi sonsuza kadar atlar. n8n'de bu bilgiyi bir veritabanı tablosunda ya da statik veri alanında tutmak yeterli.

Adımlar konusunda tek kural: bir node bir iş yapsın. Kırk node'luk tek bir akış, altı ay sonra kimsenin dokunmaya cesaret edemediği bir yapıya dönüşüyor. Bunun yerine akışı alt akışlara bölmek (Execute Workflow) hem test edilebilirliği hem de yeniden kullanımı ciddi biçimde artırıyor. "Müşteri kaydını normalize et" gibi bir alt akış, beş farklı ana akışta kullanılabiliyor.

Üretime alan dört şey

Idempotency: aynı olay iki kez gelirse

Bu, en sık atlanan ve en pahalıya patlayan başlık. Webhook'lar tekrar gönderilir — karşı taraf yanıtınızı alamadığında, ağ koptuğunda, kendi kuyruğu yeniden denediğinde. Akışınız buna hazır değilse aynı müşteri iki kez açılır, aynı e-posta iki kez gider.

Çözüm karmaşık değil: her gelen olayın kaynak sistemdeki kimliğini (sipariş numarası, form gönderim kimliği, mesaj kimliği) taşıyın ve hedef sistemde bu kimlikle arayıp yoksa oluşturun, varsa güncelleyin. Yani insert değil upsert. Hedef sistem bunu desteklemiyorsa, işlenmiş kimlikleri tutan küçük bir tablo aynı işi görür.

Hata yolları: mutlu yolun dışı

n8n'de her akış için bir Error Workflow tanımlanabiliyor; akış hata verdiğinde devreye giren ayrı bir akış. Bunu tanımlamak beş dakika sürüyor ve üretimdeki her akışta olması gerekiyor. İçeriği basit olabilir: hangi akış, hangi node, hangi kayıt, hata metni — ve ekibin gerçekten baktığı bir kanala bildirim.

Node seviyesinde "Continue on Fail" ayarını dikkatli kullanın. Hatayı yutup akışı devam ettirmek, sorunu görünmez yapar. Bilinçli tercih şu şekilde olmalı: geçici hatalarda yeniden dene, kalıcı hatalarda (400, doğrulama hatası, bulunamayan kayıt) akışı durdur ve bildir. İkisini aynı kefeye koymak, saatlerce boşa dönen akışlar üretiyor.

Yeniden deneme ve geri çekilme

429 (hız sınırı) ve 5xx yanıtları geçici hatalardır ve yeniden denenmelidir — ama hemen değil. Artan bekleme süresiyle denemek (önce birkaç saniye, sonra daha uzun) hem karşı sistemi rahatlatır hem de başarı oranını yükseltir. n8n'in node ayarlarındaki yeniden deneme seçeneği çoğu durum için yeterli; daha uzun beklemeler gerektiğinde Wait node'u ile kurgulanıyor.

Bir deneme sayacı tutmayı ihmal etmeyin. Sayaç yoksa, kalıcı olarak bozulmuş bir kayıt akışı sonsuza kadar meşgul edebiliyor.

Kuyruk ve eşzamanlılık

Kampanya günü ya da toplu içe aktarım anında akışa aynı anda yüzlerce olay gelebilir. Varsayılan kurulumda bu, sunucunun tıkanması demek. n8n'in kuyruk modu (Redis ile) işleri sıraya alıp kontrollü biçimde işliyor. Ayrıca eşzamanlılık limiti koymak, karşı sistemin hız sınırına takılmayı da önlüyor.

Sıranın kendisi önemliyse — örneğin aynı müşteriye ait güncellemelerin sırayla işlenmesi gerekiyorsa — o grubun tek bir işleyiciye yönlendirilmesi gerekir. Bu detay atlandığında ortaya çıkan hata, tekrarlanabilir olmadığı için en zor teşhis edilen hatalardan biri.

İzleme: akış sessizce ölürse ne olur?

Üretimdeki akışların en pahalı arızası hata vermek değil, sessizce durmak. Bağlantının yetkisi dolmuştur, tetikleyici bir güncelleme sırasında pasife düşmüştür, karşı sistem alan adını değiştirmiştir. Hata alarmı kurmuşsanızdır ama hata da gelmez — çünkü akış hiç çalışmamaktadır. Bunu üç hafta sonra, birileri "şu kayıtlar neden gelmiyor" diye sorduğunda fark edersiniz.

Bu yüzden üç sinyali birden izlemek gerekiyor:

  • Hata oranı — çalıştırmaların ne kadarı başarısız.
  • Son başarılı çalışma zamanı — akış en son ne zaman düzgün tamamlandı. Beklenen aralığı aştıysa alarm.
  • İş hacmi — normalde günde 30 kayıt işleyen akış bugün 0 işlediyse, teknik olarak hata yok ama iş olarak arıza var.

Üçüncüsü en çok atlananı ve genellikle en erken uyarı vereni. Kurulumu da basit: günlük çalışan küçük bir kontrol akışı, sayıyı okur ve eşiğin altındaysa bildirir.

Bildirimin nereye gittiği de önemli. Kimsenin açmadığı bir e-posta kutusuna giden alarm, alarm değildir. Ekibin gün içinde zaten baktığı kanala düşmeli.

Veri, kimlik bilgileri ve KVKK

Akıştan kişisel veri geçiyorsa üç soruyu yazılı olarak cevaplayabilmek gerekiyor: hangi veri geçiyor, nereye gidiyor, ne kadar süre duruyor.

Ne kadar süre duruyor sorusu n8n'de özellikle önemli, çünkü araç çalıştırma kayıtlarını (execution data) varsayılan olarak saklıyor ve bu kayıtlar akıştan geçen veriyi içeriyor. Saklama süresini sınırlamak ve hassas alanları kayıtlara hiç yazmamak, yapılması gereken ilk iki ayar. Kendi sunucunuzda çalıştırıyorsanız bu tamamen sizin kontrolünüzde.

Kimlik bilgileri node içine sabit yazılmaz; n8n'in kendi kimlik bilgisi deposunda tutulur. Kendi sunucunuzda çalıştırıyorsanız şifreleme anahtarının yedeği kritik — o anahtar kaybolduğunda kayıtlı tüm bağlantılar kullanılamaz hale geliyor. Bu, yedekleme planında ayrıca not edilmesi gereken bir madde.

Akışta bir dil modeli kullanıyorsanız, oraya giden içeriğin ne olduğu ayrı bir başlık. Pratikte en çok işe yarayan adım, model çağrısından önce veriyi sadeleştirmek: isim, telefon ve kimlik numarası yerine yalnızca kararı etkileyen alanları göndermek. Bu konuyu kurumsal veriyi yapay zekâya vermek yazısında ayrıntılı ele aldım.

Sürüm kontrolü ve ortamlar

n8n akışları JSON olarak dışa aktarılabiliyor. Bu, akışları sürüm kontrolüne almak için yeterli. Tam bir CI/CD kurmak çoğu ekip için gereksiz olabilir ama en azından şu ikisi olmalı: akışların düzenli olarak dışa aktarılıp bir depoya konması, ve canlı akışın doğrudan üzerinde çalışılmaması.

Ayrı bir test ortamı ideal olan. Bu mümkün değilse, en azından akışın bir kopyası üzerinde çalışıp test edildikten sonra devreye alınması gerekiyor. "Canlıda küçük bir düzeltme yapayım" cümlesi, otomasyon arızalarının önemli bir bölümünün başlangıç noktası.

Maliyet: gerçek kalemler

n8n'in kendi kendine barındırma seçeneği ücretsiz olduğu için maliyet konuşulurken genelde sadece sunucu ücreti hesaplanıyor. Oysa gerçek kalemler şunlar:

  • Sunucu ve — kuyruk modu kullanılıyorsa — Redis.
  • Yedekleme ve izleme.
  • Güncelleme emeği: n8n hızlı gelişen bir araç, sürüm atlamaları elden geçirme gerektirebiliyor.
  • Akış bakımı: karşı sistemlerin API'leri değişiyor, kurallar değişiyor.

Asıl maliyet lisans değil, bakım. Birkaç akışın çalıştığı bir kurulumda bu, ayda birkaç saatlik bir yük. Bunu baştan planlamayan ekiplerde akışlar altı ay içinde birer birer bozuluyor ve kimse fark etmiyor. Bulut sürümünü tercih etmek bu yükün bir kısmını devrediyor; karşılığında verinin nerede durduğu konusundaki kontrolü azaltıyor. Hangisinin doğru olduğu, akıştan geçen verinin hassasiyetine göre değişiyor.

Uçtan uca örnek: web formundan teklife

Somutlaştırmak için sık kurduğum bir akışı adım adım anlatayım.

  1. Webhook web sitesindeki teklif formundan gelen gönderimi alır ve paylaşılan gizli anahtarla doğrular.
  2. Normalizasyon adımı telefon ve e-posta biçimini düzeltir, boş alanları işaretler, zorunlu alan eksikse akışı burada sonlandırıp bildirim gönderir.
  3. CRM'e upsert — form gönderim kimliği anahtar olarak kullanılır. Aynı form iki kez gelirse ikinci kayıt açılmaz, mevcut kayıt güncellenir.
  4. Zenginleştirme — firma bilgisi dış bir servisten çekilir. Bu adım hız sınırına takılabildiği için yeniden deneme açık; üç denemede de başarısız olursa kayıt "zenginleştirilmedi" etiketiyle devam eder, akış durmaz.
  5. Yönlendirme kuralı — bütçe bandı ve talep edilen hizmet tipine göre talep ilgili kişiye atanır. Kural tablosu akışın içinde değil, ayrı bir tabloda tutulur; böylece değiştirmek için akışa dokunmak gerekmez.
  6. Teklif taslağı — şablon üzerinden hazırlanır, açıklama kısmı için dil modeli kullanılır. Model boş ya da anlamsız dönerse akış düz şablona geri düşer. Bu geri düşüş yolu olmadan, modelin kötü bir günü doğrudan müşteriye yansıyor.
  7. Bildirim — atanan kişiye, ekibin kullandığı kanaldan.
  8. Hatırlatma — 24 saat içinde talebe dokunulmamışsa ikinci bir bildirim gider.

Bu akışta gerçekten kritik olan adımlar 3, 4 ve 6'daki geri düşüş yolları. Onlar olmadan akış ilk yoğun günde ya çift kayıt üretir ya da tamamen durur.

En sık yapılan altı hata

  1. Tek dev akış. Kırk node'luk yapı, altı ay sonra dokunulamaz hale geliyor.
  2. Hata yolu tanımlamamak. Error Workflow beş dakikalık iş, yokluğu haftalarca fark edilmeyen arıza demek.
  3. Idempotency düşünmemek. Çift kayıt, çift e-posta, çift fatura.
  4. Kimlik bilgisini node'a gömmek. Hem güvenlik hem de ortam değiştirme sorunu.
  5. İzleme kurmamak. Sessizce duran akış, hata veren akıştan daha pahalı.
  6. Tek kişiye bağımlılık. Akışı kuran kişi ayrıldığında sistem de gidiyor. En az iki kişinin akışı okuyabilmesi ve kısa bir devir notunun bulunması gerekiyor.

Akışı ekibe devretmek

Otomasyon projelerinin sessiz başarısızlık biçimi şu: akış çalışıyor, kimse anlamıyor. Kuran kişi ayrıldığında ya da başka işe geçtiğinde sistem teknik olarak ayakta kalıyor ama kimse dokunamıyor. Bir süre sonra küçük bir değişiklik gerekiyor, yapılamıyor, süreç elle yapılmaya geri dönüyor.

Bunu önleyen üç şey var ve üçü de kurulum aşamasında yapılırsa neredeyse ek maliyet çıkarmıyor:

  • Akış içinde açıklama. n8n'de node'lara not eklenebiliyor. Özellikle karar noktalarında "burada neden bu kural var" bilgisi, altı ay sonraki okuyucu için akışın kendisinden daha değerli.
  • Tek sayfalık devir notu. Akış ne yapıyor, hangi sistemlere bağlanıyor, hangi kimlik bilgilerini kullanıyor, bozulursa nereden bakılır, kime haber verilir. Bir sayfayı geçmesine gerek yok.
  • İkinci bir kişi. Akışı en az iki kişi okuyabilmeli. Kurulum bittiğinde yarım saatlik bir gezinti çoğu zaman yeterli oluyor.

Ben projelerde bunu bilinçli olarak işin parçası tutuyorum; en iyi sonuç, ekibin akışı devraldığı ve benim aradan çekildiğim kurgudan çıkıyor. Devredilemeyen otomasyon, uzun vadede otomasyon sayılmıyor.

Nereden başlamalı

Tek bir süreç seçin. Ölçülebilir, kuralı yazılabilir ve hatası geri alınabilir olsun. Önce mutlu yolu kurun, sonra bu yazıdaki dört başlığı (idempotency, hata yolu, yeniden deneme, izleme) tek tek ekleyin. İlk akış üretimde bir hafta sorunsuz çalıştığında, ikincisi çok daha hızlı gelir — çünkü artık iskelet hazırdır.

Hangi sürecin buna uygun olduğundan emin değilseniz, n8n ile otomasyon sayfasında süreç seçimi ve tipik akış kurgusunu daha kısa biçimde anlattım. Kurumda yapay zekâ tarafını da işin içine katmayı düşünüyorsanız şirkette yapay zekâya nereden başlanır yazısı bu yazının doğal devamı.