Selam Ekip - E38 - Fraud

Selam ekip, ben Storefront TR ekibinden Cengiz.

Ben Fulfillment Order Master Data ekibinden Fırat.

Teknoloji ekiplerini tanıdığımız ve süreçler, teknolojiler gibi konuları konuştuğumuz Selam Ekip Podcast serisinin bugünkü bölümünde Fraud ekibiyle birlikteyiz.

Fraud ekibini tanıyıp, ekip yapısı, kullanılan teknolojiler, pratikler gibi konuları konuşacağız.

Arkadaşlar hoş geldiniz. Hoş geldiniz.

Hoş bulduk. Hoş bulduk.

Bugün çok güzel konular hakkında konuşacağız, ekibinizi tanıyacağız.

Öncelikle kendinizi ve ekibi bir tanıtabilir misiniz acaba?

Ben başlayayım. Ben Onur.

Yaklaşık 5 yıl bir trend yolda çalışıyorum.

Bu süreç içerisinde OMS ekiplerinde bulundum.

Fraud ekibi de şu an OMS ekibi altında bulunan bir ekip.

Zaten Fraud'un ne yaptığıyla ilgili konuşuyor oluruz.

Ömer sen kendini tanıt, sen devam et.

Ben de 2 senedir trend yolda çalışıyorum.

2 senedir aslında Fraud ekibindeyim.

Backend ve frontend olarak devam ediyorum burada.

Çok iyi. Burası full stack mi çalışıyor abi?

Şu anda bu ekibi kısaca bir tanıtmadan önce.

Fullstack dikkatimi çekti. Bunu bir not aldım.

En başta bir kısaca ekipten bahsedebilir miyiz?

Fraud nedir? Fraud ekibi ne işe yarar?

Fraud nedir? Kısaca Fraud ekibinden bahsedelim.

Üç developer, bir product manager, bir QA olarak çalışıyoruz.

Genelde ekibin hepsi Fullstack.

Çünkü hem agentlere sunduğumuz bir ön yüz ekranımız var.

Hem de Fraud kurallarını işlettiğimiz servislerimiz var.

O yüzden ekibimiz genel olarak Fullstack çalışıyor.

Bu kadar diyebilirim ekibimizin genel yapısı aslında.

Burada Fraud ekibi tam olarak neler yapıyor?

Fraud ne işe yarıyor?

Fraud ekibi aslında totalde iki ayağı var.

Biri müşteri tarafı, biri satıcı tarafı.

Müşteri tarafında aslında müşterilerimiz alışverişlerini yaparken hem güvenli yapmalarını istiyoruz, hem de olabildiğince en kısa sürede yapmalarını istiyoruz.

O tarafta bazı çalışan kurallarımız var.

İşte müşterinin geçmiş siparişlerine dayanarak ya da ilişkili oldu diyen müşterilerle olan siparişlerine dayanarak belli başlı kurallarımız var.

Manuel süreçte ilerliyor.

O tarafta da satıcının aslında fraud risk'i taşıyıp taşımadığı, yapılan yorumlar, yapılan favorilere göre aslında bir organik büyüme mi yoksa daha yapay bir şekilde mi bot mu kullanılmış gibi süreçlerimiz

var aslında. Genel olarak fraud ekibi müşteriye ve satıcıya daha güvenli bir ortam sunmak için çalışmalar yapıyor.

Biz de o yapılan çalışmalar sunucunda bir şey otomatikleştirilebiliyorsa, otonom hale getirebiliyorsa orayı handle ediyoruz aslında.

Ben hep fraud deyince abi müşterinin Yani adam işte hesabı çalınmış mı, kredi kartı saatte mi ne bileyim o tarz şeyler de düşünmüştüm ama satıcı kısmını hiç düşünmemiştim.

Aslında satıcılarda da bu tarz durumlar olabiliyor değil mi yani?

Nasıl mesela? Olan bir şey var mı ya da verebileceğim bir örnek?

Örnek vereyim abi. Mesela bir satıcı Trendyola yeni açıldığında genelde puanı olmadığı için kendisine satın alın yapabiliyor.

Yani nasıl yapıyor? İşte bardak satıyor diyelim.

Gidiyor kendisine 10 tane bardak alıyor müşteri açıp.

Bu sayede aslında listeler de yukarıda gözükmeye başlıyor.

Ama aslında o 10 tane satın alımı yaptığı bardak bir organik bir şey değil.

Hani bir müşterinin değerlendirmesi değil.

Hatta bunun en büyük örneğine Twitter'da bir olay olmuştu.

Orada yaşamıştık. Trendyol yemek olarak artık müşterilerin satın aldığı siparişlerin detayını göstermeye başladık.

Yorumlarda müşterinin yazdığı mesela kebap çok güzel yazmış.

Ama müşterinin su söylemiş.

Oradan... bir şekilde patlak vermişti mesela orası.

O gibi şeyler var aslında.

O çok şeymiş ya. Üç su verip direkt kebaba yazması.

Çok dikkat çekmiş yani.

Bu beni de çok şaşırtmıştı.

Yani açıkçası hiç böyle bir şey aklıma gelmezdi.

Çünkü dışarıdan baktığım zaman bir kullanıcı gözüyle bakıldığı zaman yemek çok güzel, lahmacun çok güzel, kebap çok güzel falan okuduğumuz zaman evet evet yani işte diyorsun

tamam ne güzel falan ama Baktığın zaman tamamen farklı aslında arkasındaki olay.

O yüzden gerçekten bunun böyle ortaya çıkarılması oldukça iyi bence.

Biraz daha ben ekipteki süreçler hakkında merak ediyorum.

Ekipteki süreçleri merak ediyorum.

Ekipte süreçler nasıl ilerliyor?

Hangi metodolojileri kullanıyorsunuz abi?

Burada ben bahsedeyim.

Ekibimizde neler yapıyoruz?

Nasıl süreçlerle ilerliyoruz?

Aslında Trendyol içerisindeki çoğu ekipte olduğu gibi biz de...

Ecail Scrum olarak ilerliyoruz.

Sprintler halinde işlerimizi planlıyoruz.

Orada bir haftalık sprintler dediğimiz bir haftalık sprint koşulları yapıyoruz.

Bazı ekiplerde Trendyol içerisinde iki haftalık da olanlar oluyor.

Bazı ekiplerde kanbanla ilerleyebiliyor.

Biz bir haftalık sprinti tercih ediyoruz.

Aslında kısaca bundan bahsedebilirim.

Ecail Scrum konusunda zaten çoğu arkadaşımız biliyordur.

Orayı tekrardan açmak istemedim.

Retrolar da mı haftalık oluyor sizde?

Retroları aslında haftalık birazcık kısa olduğunu gördükten sonra iki haftaya çevirdik.

Yani iki sprintin retrosunu yapmış oluyoruz.

İki haftaya çevirmiştik.

Çünkü her hafta retro birazcık şey olabiliyor.

Aynı şeyleri tekrar ediyormuşuz gibi olabiliyor.

Onu biz de bir ara düşünmüştük de yani şöyle.

Her hafta yapınca bazen şey oluyor.

Bir sprint çok normal geçiyor.

Çok düz hani sorunsuz ama her şey çok normal.

Standart geçiyor ve şey oluyorsun.

Bortta bazen çok bir şey olmayabiliyor.

Çünkü her hafta yapıyorsunuz sonuçta.

İki buçuk günlük bir gelişme süresi oluyor.

Acaba dedik iki haftada bir yapsak mı diye biz de bir keresinde düşünmüştük ama sonra da mesela atıyorum o hafta bir şey oldu ve konuşmak istiyorsan onu bir sonraki hafta konuşman gerekecek ya.

O bekleme kısmı hani ne kadar doğru olur ya da sağlıklı olur mu bundan emin olamamıştım mesela bende.

Sizde mesela bu iki haftaya geçince hani nasıl oldu sence?

Yararını gördün mü yoksa bir hafta daha mı iyiydi diyorsun karşılaştırdığında?

Yani Retro'daki iki haftalık Retro'da zaten bu deneyimlediğimiz bir süreçti.

Bir haftalıkları denediğimizde böyle konuşulacak maddeler çıkmamaya başlamıştı.

Aslında iki haftaya geçince daha verimli retrolar yaşamaya başladık.

Onu net bir şekilde söyleyebilirim.

Tabi burada bazı konular geçen sprintten kaldığında böyle unutulabiliyor edilebiliyor.

Bu konuları da hatırlamak adına arkadaşlarımızla biz de ben de aynı şekilde bunları not alarak süreci de böyle biraz daha kafamızda oluşacak şekilde not alarak ondan bahsediyoruz retrolarda.

Retro'ların sonucunda da işte çıkan aksiyonları aslında bir sprinte değil de iki sprinte eritmeye çalışıyoruz.

O da verimli olduğunu rahat bir şekilde söyleyebilirim yani.

Çok iyi ya. Güzelmiş.

Yani deneyen birinden böyle öğrenmek yararlı oluyor genelde.

Tecrübe her zaman daha iyi teoriden.

Peki abi burada ekip olarak sizler hangi teknolojileri ve dilleri kullanıyorsunuz ya da neler yapıyorsunuz Fraud tarafında?

Böyle projeler çok büyük mi oluyor mesela?

Fraud deyince sanki milyonlarca şeyle uğraşmış olabilirsiniz.

Çok az şeyle çünkü şey yapamıyorum.

Hayal edemiyorum yani Fırat deyince.

Tabii bahsedeyim bizim teknoloji sistemimizden de bahsetmiş olalım.

Ekip olarak içerimde dil bağımsız yaklaşıyoruz aslında her bir projeye.

Bu projeye başlarken aslında ilk önceliğimiz ekibimizin teknolojinin ne olacağına bakarak doğru bir yazılım diline karar vermek, doğru bir teknolojiye karar vermek.

Kullandığımız yazılım dilleri çok çeşitli diyebiliriz aslında.

Belki de Trendos içerisinde bütün dilleri kullanan ekiplerden Bir tanesi de biziz.

Go'yu kullanmaya başlamıştık.

Geçen sene itibariyle .NET projelerimiz var.

Zaten Fallout ekibi çok eski bir ekip bu arada.

Burada da Legacy çok fazla kodumuz da var aynı şekilde.

Onlarla bahsediyor oluruz zaten challenge'larımızda konuşuyorken.

.NET ağırlıklı bir ekipti.

Onu işte yavaş yavaş daha farklı yazılım dillerine geçirmeye başladık.

İşte en son yeni bir app'imizi yazdığımızda orada kod dilini tercih edelim, onu kullanalım.

Aspect Oriented'da daha böyle bize kolaylıklar sağladığını düşünerek Kotlin'e geçmiştik.

Daha böyle minimal, daha performanslı olacağını düşündüğümüz yerlerde Go'ya geçmeye başladık.

Böyle aslında yazılım dili açısından pazemiz bayağı geniş.

Yani Java, Kotlin, .NET, Go, bütün stackler bulunuyor aslında.

Peki abi test konuları nasıl ilerliyor sizle?

Fraud ekibi hani burada bunları konuşuyoruz bir biznes açısından farklı bir şey aslında baktığımız zaman.

Test tarafları da yani her hafta konuştuğumuz ekiplerle aynı mı ilerliyor burada?

Bizde de benzer süreçler ilerliyor aslında.

Ama hani bizim şöyle bir yaklaşım değişikliğimiz oldu.

Önceden test, driving, development yapmıyorduk aslında.

Bir sene önceye kadar falan belki.

O yapıya geçtikten sonra aslında bizim çok fazla QA'yı o dönemlerde, Samet abi QA'yı da.

çok fazla manuel yükü biniyordu.

Ama TDD'ye geçtikten sonra zaten unit test kavrışlarıyla ilk adımda onun bir yükünü azaltmış olduk.

Sonrasında genel olarak Trendyol'da pipeline süreçlerinde işleyen acceptance testler, integration testler zamanla dahil etmeye başladık.

Şu anda kavrış anlamında iyi olduğumuzu söyleyebiliriz.

Ama bir sene içinde bunu geliştirdik diyebiliriz.

Ondan önce tam oturmuş bir yapımız yoktu aslında.

Ve hani legacy kodda test yazmak çok yorucu olduğu için, uğraştırıcı olduğu için.

tercih etmeye elimizle gitmiyordu.

Ama Legacy Code'u refaktör ettikçe aslında testinde gücünü gördükçe aslında bizim nerede işe yaradığımızı anladıkça daha da yapı oturdu.

Şu an tüm trend yoldaki ekiplerin işlettiği acceptance test, TDD süreçlerini biz de işletmeye başladık ve devam ediyoruz.

Süper. Harikaymış.

Haberinize sağlık. Bir şey tarafına geçmek istiyorum.

Şimdi fraud ekibi olarak fraud nedir?

Ekip olarak neler yapıyorsunuz?

Hangi durumlar fraud falan bunları konuştuk.

Peki burada içeride fraud olan durumları nasıl belirliyorsunuz?

Yani bir fraud durumu olduğu zaman bu nasıl belirleniyor?

Orada aslında şöyle bir süreç var.

Belki onu anlatmak gerekiyor ilk başta.

Fraud iki adımdan oluşuyor aslında.

Birincisi ödeme öncesi.

Yani bir insan sipariş vermeden önce Ona SMS mi sorulacak, 3D mi sorulacak yoksa hiçbir şey sorulmayacak mı?

Bunun kararı aslında bizden geliyor.

Orada bir ilk önce aslında orada bir elemeye tabi tutuluyor aslında.

Bir insan 3D sorulmuşsa ve 3D başarılı geçmişse aslında o siparişin herhangi bir fırat sürecine takılma gibi bir durumu yok.

Çünkü biz sorumluluğumuzu yapmış oluyoruz, 3D gösterilmiş oluyor ve sipariş yapışına devam ediyor.

İkinci bir seçenek ise bunların hiçbirini almadığında siparişin yaratıldığı andan sonraki İşte kargo süreçleri başlamadan önce, satıcı tarafına iletilmeden önceki süreç var.

Biz buna genelde post fraud diyoruz.

İşte order verildikten sonraki süreç aslında.

Bu süreçte de bizim bir fraud havuzu dediğimiz bir mekanizma var.

Belli başlı kurallarımız var.

70-80 tane böyle zamanda fraud agentlarının bu havuz sayesinde belirlediği, işte şu olursa bu havuza düşsün, bu olmazsa düşmesin gibi belli başlı...

Biznes dojikleri bize vererek detayını anlatamayacağım.

Çünkü detayının fraud'a sebep olabileceğini bildiğim şeyler olduğu için.

Bize sunduğu case'leri bizim konsümerler sayesinde, Trendion'un içindeki event drive'ın yapı sayesinde bir order yaratıldığında işlettiğimiz bir yapımız var.

Bu sayede bir havuza düşüyor.

Bu havuzu da fraud agentleri manuel olarak görebiliyorlar.

Ve aslında onlar günün sonunda siparişin fraud olup olmadığına karar veriyorlar.

Ve bazen orada bazı yeni case'ler yakalıyorlar.

Diyelim ki yeni bir şey bulunmuş, fraud yapılabilecek.

Bu case bulunduktan sonra bir sonraki siparişle bu başımıza gelmesinde business tarafı bize bir kural implement etmemiz gerektiğini söylüyor.

Biz de analiz ediyoruz, data'ya bakıyoruz.

Ona göre implement ediyoruz.

Sonra o süreci de takip ediyoruz.

Çünkü bazen şöyle bir şey oluyor.

Bir şey yakaldığımızı düşünüyoruz.

Bir kural implement ediyoruz.

Bir bakıyoruz ki 3D oranı artmış ve aslında masum müşteriye de 3D sormuşuz.

Ve bu istemediğimiz bir şey. Kimsenin sürecini engellemek istemediğimiz bir durum.

Bu şekilde aslında bir manuel prosesi de söz konusu incelemek için.

Masum müşteri. Çok iyi.

Peki abi burada yani sipariş sürecinde tam olarak nerelerden sorumluyuz?

Yani bir sipariş oluşuyor.

Oluştuktan sonra hem bunun öncesi var hem sonrası var demiştin sanırım.

Bir öncesinde...

yapılan şeyler var. Bir de sonrasında yani siparişten sonra da bir kısımda hala müşteriye dokunuyoruz diye anlıyorum.

Tabii ki. Yani fraud aslında sadece öncesini kapsamıyor.

Yok. Aynen. Bir sipariş verildikten sonra aslında ödemesi yapıldığını düşünelim.

Ödemesi yapıldıktan sonra seller tarafına aktarılmadan, kargo süreçleri başlamadan önce aslında OMS ekipleri bizim fraud tarafından bir notification bekliyor.

Biz buna not fraud eventi diyoruz.

Yani bu sipariş artık kargoya akabilir.

cevabını biz veriyoruz aslında.

Yine onu da eventle veriyoruz ve onlar da bizi eventle dinleyerek aslında siparişin bir sonraki aşamaya kargosuna oluşabilmesine, shipment adımına geçirebiliyorlar.

Bunun iki türlü siparişte.

Kurallara takılmadıysa çok otomatik bir şekilde oluyor.

Kurallara takıldıysa manuel olarak fraud havuzundan fraud agentleri inceleyip not fraud'ı seçmesi gerekiyor.

Fraud'ı seçer ise o kullanıcının o güne kadar olan, aktif olan tüm siparişleri iptal oluyor.

Çünkü bir siparişten bir Kullanıcı fraud yaptıysa aslında genel gördüğümüz bir şey yani o müşterinin mesela kartını çalındığını düşünelim.

Bir anda kartı çalınan bir insanın hesap açıp 10 tane verdiği sipariş genelde 10'u da fraud oluyor.

Hani kendisi bir tane normal bir sipariş vermiş 10 tanesi fraud vermiş gibi olmuyor.

Sipariş sonraki süreçte de aslında diğer ekipler bizim not fraud eventinin çıkmamızı bekliyor.

O yüzden orada bir siparişin hızlı alınıp verilmesiyle ilgili yani orada bir süreç etkimiz olabiliyor bazen.

İncident yarattığımızda da. Siparişler aslında sizden bir geçiyor diye anlıyorum.

Tüm yemek market veya trend yol, international tarafı şu anda.

Tüm sipariş süreçlerin aslında shipment adımına geçmesinden bir sorumluyuz.

Peki yani bu aslında oldukça sorumluluğu yüksek bir durum.

Yani fraud'u yakalamak, fraud'u önlemek, bunun daha yaşanmadan önlenmesiyle alakalı işte geliştirmeler yapmak, işler yapmak vs.

düşündüğüm zaman birçok challenge çıkartıyor aslında sizin bu oyunuza.

Fraud ekibinin challenge'ları bu tarafta nelerdir?

Şöyle bahsedebilirim de aslında challenge'larımızdan.

Biraz önce de bahsetmiştim.

Burada Fraud ekibi çok eski bir ekip aslında.

Trendyol'un en eski ekiplerinden bir tanesi.

Bunu da bahsetmişken Trendyol içerisinde yaklaşık 100'den fazla ekip var.

Fraud ekibi de bunlardan bir tanesi.

Fraud ekibi ama Trendyol'un en eski ekiplerinden bir tanesi.

Yaklaşık bir 10 yıllık bir geçmişi var diyebiliriz.

Bu ekipler ayrılıştırmaya başladıktan sonra Fraud ekibi değişti.

Bir 10 yıllık bir ekip diyebiliriz aslında.

10 yıllık ekip derken aslında bizim kodlarımızda 10 yaşından fazla bulunan kodlarımız da var.

Legacy'den bahsederken çok yakın bir legacy değil.

Yani yaklaşık bir 10 yıllık kod bezlerimiz de bulunuyor.

Bunları da manage etmek ve bunları manage ediyorken Yeni teknolojileri de kullanarak yeni şeyler ortaya çıkartmak bizim aslında en büyük challenge'ımız.

En son yaptığımız bir projemiz var.

Zaten oradaki challenge'ımızdan da bahsediyor oluruz.

Unification adı altında yaptığımız bir projemiz var.

Onun haricinde Fraud ekibinde denemek istediğimiz yani aslında gitmek istediğimiz nokta manuel süreçleri tamamen ortadan kaldırmak ve şu anda ilerleyen manuel süreçleri de yapay zeka

teknolojilerini...

adapte ederek aslında oradaki karar verme mekanizmasını kendisi öğrenen, fraud'u kendisi öğrenen, kendisi karar veren yapıya geçirmek.

Bu bizim en büyük challenge'miz diyebiliriz aslında.

Abi orada User Unification'de bir projeden bahsettin.

Bir biraz bahsedebilir misin? Nedir o?

Tabii abi bahsedeyim.

Aslında son 4-5 aydır canlıda kullandığımız Şu anda bu sistemi kullanan müşterilerimize hizmet sunduğumuz bir yapı.

Aslında kendini birazcık kanıtlamış bir yapı.

Bahsederken deneyimlerimizden de bahsediyor olurum.

Unification projemiz bizim şu anda Trends.org içerisinde promotion ekiple beraber aslında böyle bir detektifimiz ortaya çıktıktan sonra karar verdiğimiz bir süreçti.

Bu yemek ve market tarafında tanımlanan bazı promotionlar oluyordu.

Ve bunları bu promotionlar bir kullanıcının bir defa kullanması beklenen bir promotionlar.

Buradaki challenge'da kullanıcının mail veyahut da herhangi bir işte telefon değiştirerek, adres değiştirerek yani herhangi bir değiştirerek yenilen o kullanıcı sipariş verdiğinde bu promotion

'u kullanabiliyor. Aslında buradaki işte ilk gelen promotion diye adlandırılan promotion'lar var.

Bazı yemek ve market kanalı sadece tek kullanımlı promotion'lar çıkarttığı promotion'lar var.

Bunun aslında gerçekten bir kullanıcının bir kere kullandığını teyit etmek için Bizim bunu sağlayacak bir servise ihtiyacımız vardı.

Bu servis aslında buna hizmet ediyor.

Unification projesi bunu yapıyorken de birçok veriyi aslında birleştiriyoruz.

Unification projesiyle bizim hedeflediğimiz şey bahsettiğim gibi bir kullanıcının aslında...

o tanımlı olan promotion'u veyahut da herhangi bir şeyi sadece bir kere kullanabilmesini teyit etmek.

Buna hizmet ederken de arkada aslında kullandığımız bağlama logiklerimiz var.

Orada işte neden bazı false positive bağlamaları yapmış olabiliyoruz.

Bazı kullanıcılar hiç o kullanıcıyla eşleşmemişken onunla eşleşmiş oluyor.

Burada çalışlarımız bu noktada aslında Unification projesi üzerinde.

var diyebiliriz. Yani gelişme yollarımız hala var.

Hala mevcut. Oranın da kendisi öğrenen kendini geliştiren yapıya geçirme hedeflerimiz var.

Bunlardan bahsedebilirim kısaca.

Burada araya girip bir şey söyleyeyim belki de abi.

Belki hepimiz üniversitede ya da öğrencilik çağında ileriki yapmışızdır.

Yeni bir uygulamada işte promosyon kullanabilmek için birden çok üyelik açıp ama belki hep aynı cihazı kullanıp işte yemek promosyonu kullanmaya çalışmışızdır.

Burada genelde Şöyle bir yaklaşım var zaten.

Eğer işte o kullandığınız uygulama mesela Trendyol üzerinde konuşalım.

Hani sen promosyonu görüp kullanabildiysen zaten orada sorumluluk bizde oluyor.

Hani onu göstermemeye yönelik bir şeyler yapmaya çalışıyoruz bizde.

Bunu anlamak için de aslında hani yandan da burada veri kullanırken yasal zorunluluklar da var.

Onları da gözeterek aslında sen yeni bir üyelik açıp geldiğinde eğer eskiden bu promosyonu bir şekilde kullandıysan aynı e-maille, aynı telefonuna falan.

Sana bunu göstermemeye çalışıyoruz ama bu verdiğim örnek e-mail, telefondan bağımsız başka şekilde de yapılabiliyor.

Amacımız o aslında ama müşterimiz promosyonu gördükten sonra kullanırsa orada sorumluluk bize geçmiş oluyor.

Bu bizi aslında bir Furaat tarafında eksi olarak...

Gözden kaçan bir şey gibi oluyor.

Tabii ki, aynen. Biz de onları göstermeden hem de müşteriyi mağdur etmeden çünkü o promosyonu normalde görmemesi lazım.

Görüyorsa oradaki sıkıntı bizde oluyor zaten.

Burada şeye de bağlayabilirim, tek tek de bahsetmedik ama aslında biz genelde datastore olarak da normalde ekip içlerinde genelde Trendyol'a, Couchbase, PostgreSQL gibi ev tabanları kullanılıyor.

Burada bizim challenge'ımızı handle etmek için aslında biz GraphDB kullandık.

Çünkü SQL bazlı, KeyWall bazlı bir yapıda bunu yakalayamayacağımızı fark ettik.

O yüzden aslında mesela burada GraphDB kullanmaya başladık.

Yani o anlamda da tek sitemizi genelde böyle sadece bildiklerimizle değil, yeni kapıları açmak için...

Zorluyoruz. Hatta hani Microsoft'la mailleşmelerden bugünlere gelip sonra şu an Neo4j tarafında bir Graph TV kullanıyoruz.

Neo4j çok iyi. Gerçekten çok iyi.

Yani teknik detayı da, business detayı da yüksek bir iş oluyor gibi duruyor.

Bir de ben şey konusuna biraz merak ediyorum.

Genellikle böyle işlerde illa ki bir incident yaşanır.

Yani sonuçta...

Aslında hataya elverişli bir koşul yani hem kullanıcı tarafında hem geliştirici tarafında hataya elverişli bir koşul oluyor ve biraz da biznessel açıdan da zor bir.

field aslında. Burada incident sıklığınız ne oluyor ve bu incidentlar geldiği zaman nasıl handle ediyorsunuz?

Genelde ayda bir oluyor.

Yani bu bahsettiğimiz kuralların çalıştığı yerdeki lojiklerde bir sıkıntı olduğunda ya da hani tren yol içinde genelde event drive'ın yapı kullanıldığı için mesela Kafka'da bir sorun olduğunda direkt sipariş akışı durmaya başlıyor.

Bunları handle ederken aslında monitoring tool'larla işte önce log'larımıza bakıp sonra hani en son ne çıkmıştık acaba yakın zamanda bir şey değiştirdik mi deyip ilk başta hatayı kendimizde aramaya başlayıp sonra böyle dışa doğru hani belki

teknik bir sorundur. Belki hani bir ekipten dolayı etkilenmiştir deyip daha dışa doğru hani daha bireyselden dışa doğru çıkmaya çalışıyoruz öyle hata handle ederken.

Yakın zamanda yaşadığımız aslında bu promosyon tarafı için oldu.

Şöyle bir örnek görebilirim.

Şu anda Mena'da yani işte Orta Doğu ve Afrika taraflarında tren yoldan sipariş verilebiliyor.

Normalde bizim tren yolda Türkiye'deki sipariş akışında telefon onaylanarak aslında bir üyelik açabiliyorsun.

Ve biz hani o telefonun gerçekten bir telefon olduğunu bilebiliyoruz.

Ama Mena tarafında bu süreç farklı ilerliyordu.

Ve bizim bundan haberimiz yoktu.

Yani oraya 11 tane 0 girebiliyorlardı.

Ve mesela 1000 tane user işte 100 tane user 11 tane 0 girdiğinde bizim için aslında Unification tarafında sanki...

Hepsi bir müşteriymiş gibiydi ama aslında...

Aynı adam tüm ülkeden sipariş vermiş gibi bir şey mi oluyor?

Evet. O yüzden oradaki lojimiz mesela telefon bazlı patladı.

Ama bunu canlı da görmeden de test edebilme gibi bir ihtimalimiz belki iletişimle olabilirdi ama kaçırdığımız bir nokta oldu.

Zaten insanda sebep olan şey de o oluyor.

Küçük şeyler kaçınca böyle büyük bir şey de oluyor.

Yakın zamanda yaşadığımız bir o vardı.

Öyle örnek verebilirim. Vallahi oldukça sıkıntılı durumlar abi.

Yani kolaylıklar diliyorum şimdiden.

Rotasyon düşünüyorsanız güzel olur.

Evet onu da söyleyelim. Fraud ekibi rotasyonlarınızı bekliyor arkadaşlar.

Ben bir de bir örnek rica edeceğim sizden.

Böyle Fraud'un yaşadığı böyle ilginç ya da böyle her gün duymayacağımız incidentlardan bir örnek verebilme şansınız var mı acaba?

Bir tane verebilirim aslında. Bayağı oldu yaşa.

İki sene falan oldu. Şimdi ürünlerin detayında şey görüyorsunuzdur.

İşte bu üründen 10 tane sipariş verilebilir gibi.

Bir detay var aslında.

Aynen. Stok yapılmasın diye.

Yani onun çalışma lojiyi de bizde aslında.

Hani sen o gün içinde 11.yi verdiğinde iptal etmeyi de sağlayan biziz.

O yapı çıkmadan önce bir gün...

işte eski 2 sene önce Hüseyin vardı LİT olarak Kuralt'ta.

Ona bir telefon gelmişti gerçekten.

Hani markete çektiler kamyonu.

Tüm bebek bezlerini alıyorlar gibi bir şikayet gelmiş.

Yani bir indirim tanımlanmış bir tane üründe.

Ve hani satın alım sınırıyla ilgili bir orada bir sıkıntı çıkmış.

Ve o yüzden aslında gerçekten kamyon çeker gibi çekip hani yüzlerce bebek bezi işte toplu alım yapmışlar.

Sonradan işte toplu alım diye bir senaryo çıktı bizim için de.

Onun için de şu an ayrı bir yapımız var.

Yürüyen bir yapımız var. Onun sayesinde handle ediyoruz.

Ama hani bu yaşanana kadar böyle bir şeyin yapılmasını ümit etmiyorduk.

Ama görmüş olduk.

Abi biraz öyle Fraud şey gibi ya.

Hukuk gibi geliyor. Mesela hukukta bir şey yaşanır ve yaşandıktan sonra onun böyle kanunu çıkar ya.

Çünkü biliyorsun hani onun gibi olmuş böyle sanki.

Fraud'da da bir şey yaşanıyor ve abi böyle bir şey varmış.

Hani bu da yapılabiliyormuş diyorsun.

Ve onun kuralını yazıyorsun gibi geldi.

Orada ikillilik şey oluyor abi işte böyle dilenmesi aslında.

Bir, bunu yaparken de hızlı yapmalıyız.

Çünkü siparişin verilme süreci aksamasın.

İkincisi, kullanıcılar genel olarak mesela 3D'yi çok görmek istemiyor.

Yani daha hızlı bir şekilde sipariş vermek istiyor.

Ya da mesela aynı evde yaşayan iki çift düşünelim.

İşte 3D diyelim ki eşine gidecek.

Onunla uğraşmak istemediği için aslında bir şekilde onlara bizim whitelist yapıp hani daha...

masum kullanıcı diye söylediğim daha verifike ettiğimiz kullanıcılar haline getirip onları bunlarla uğraştırmak istemiyoruz.

Bunları yaparken de fraudçı arkadaşlarımız bunları yakalayabiliyorlar nasıl yaptığımızı.

T artı birde de işte bir dahaki gelecek zamanda da aslında bunu nasıl yaptıklarını çözmeye çalışıyoruz.

Yani ne kadar çok fraud yapılırsa aslında biz o kadar daha çok handle etmeye başlıyoruz gibi bir şey de oluyor gerçekten.

Güzel ya zevkli. Peki abi ileride böyle yaşanan fraud durumlarını engellemek için ne gibi aksiyonlar düşünüyorsunuz?

Neler olabilir? Orada bir yapay zeka mabet duymuştum.

O havalı duruyordu. Aslında onunla ilgili çalışmamız var.

İçeride Trendol ekibinin içerisinde destek aldığımız Data Science ekibiyle birlikte yaptığımız bir veri modeli var.

O modelle bizim şu anda çalışan modeli kıyasladığımızda işte biz manuel süreçler için atıyorum günlük 600 adet kadar manuel bir süreç ortaya çıkartıyorsak o yapay zekadan

geçen İşte o modeli kullanarak yaptığımız şeyde işte bu yaklaşık 60'a kadar düştüğünü görüyoruz.

Tabii o birazcık gelişecek bir model.

Henüz tam canlıda böyle time to live şeklinde kullanabileceğimiz bir yapı değil.

O birazcık background process gibi çalışıyor.

Bize işte onu evirmeye çalışıyoruz aslında.

Onu kullanabileceğimiz bir yapıya getirmeye çalışıyoruz.

O bizim hem fraud yakalama kezlerini hem...

işte Fraud'da kaçırdığımız kezler varsa onları da handle edeceğini düşünüyoruz.

Yani aslında şu anki birinci önceliğimiz o.

Süper abi çok güzel. Abi harika.

Yani elinize sağlık her konuda.

Son olarak ben biraz daha kendinizle alakalı takım içerisinde bir soru sormak istiyorum.

Genelde böyle bu tarz yoğun işlerde insanın kendine çok fazla vakit ayırmaya böyle şey olmuyor.

Enerjisi ya da vakti.

Olmuyor. Biraz daha şeyi sormak istiyorum.

ARGE için neler yapıyorsunuz?

Kendinizi geliştirmeye vaktiniz, zamanınız oluyor mu?

Aslında bahsettiğim gibi yoğun bir backlogumuz oluyor.

Yani Trendyol içerisinde her ekibin böyle olduğunu tahmin ediyorum.

Birçok ekiple beraber çalıştığımız için aslında ne kadar bir koşturma içinde olduğumuzu biliyorum.

Buradaki süreyi...

Sürecimizi güzel yönetmek için aslında yaptığımız bazı sessionlarımız oluyor kendimiz için.

Launch and Learn'a da verdiğimiz sessionlarımız oluyor.

Oralarda aslında yeni deneyimler, yeni teknolojileri getirip orada biraz daha update kalmak için bir session planlıyoruz ve onu uygulamaya çalışıyoruz.

İçerideki yoğunluktan bahsetmiştik.

Yoğunluğumuz, ekibimiz çok büyük olduğu için.

Trendyol ekibi, teknoloji ekibi çok büyük bir ekip.

Burada da ekip içerisinde...

Yeni sistemler, sistemde yeni değişiklikler olduğu zaman bütün ekipler olarak bunlara adapte olmamız gerekiyor.

Ve aynı zamanda kendi business backlogumuz, technical backlogumuz varken bunları birlikte armağanladığımızda böyle gayet bayağı yoğun bir gündemimiz oluşuyor.

Ama bu gündem içerisinde kendimize de vakit ayırıp kendi gelişimimize devam ettirmeye çalışıyoruz.

Devam ettirmeye çalıştığımız, gelişmeye çalıştığımız sesyonlarımıza işte Launch & Learn adı verdiğimiz sesyonlarımızı düzenliyoruz.

Launch & Learn aslında teknoloji dünyasında çok uygulanan bir kullanımdan biterim, uygulanan bir metodoloji.

Launch & Learn böyle bir saatlik bir sesyon diyebiliriz aslında.

Hem yemeğimizi yiyorken hem birlikte orada bir arkadaşımızın seçtiği bir konu, seçtiğimiz bir arkadaşımız anlatacağı bir konu, yeni bir konu, yeni bir teknoloji.

Bunu paylaşarak aslında bunu...

bizim domenimizde, bizim ekibimizde nereye hit edebilir, nerede kullanabiliriz?

Konuştuğumuz bir session aslında.

Bu sessionları düzenleyerek hem up-to-date kalarak hem de şu anki legacy sistemimizin net noktalara gidebileceğini ve platformik süreçlerimizin kafada daha bir oturmasını sağlayacağımız sessionlar

düzenliyoruz. Aslında kişisel gelişimimizde hem legacy platforma giderken hem refactorik yaparken yeni oluşan fikirlerle devam ettirmeyi sağlamış oluyoruz.

Süper. Ağzınıza sağlık abi.

Çok teşekkür ederiz.

Bugün konuğumuz Frout ekibiydi.

Arkadaşlar geldiğiniz için çok teşekkür ederiz.

Çok teşekkür ederiz efendim. Ağzınıza sağlık.

Çok keyifliydi bu arada ya.

Frout konuları çok ilgi çekiciymiş.

Yani ben sevdim bayağı.

Umarım bundan sonra işler katlanarak güzel şekilde devam eder.

Bir sonraki bölümde farklı bir ekiple muhabbetimize devam edeceğiz.

Kendinize iyi bakın. Bir sonraki bölümde görüşmek üzere.

Bye bye.