Selam Ekip - E05 - Product Information Management
23 Aralık 2020 · 41 dk
PlatformlardaSpotifyApple Podcasts
Transkript
Şu an itibariyle başladık galiba.
Enes az önce ben konuşurum, ben kayıdı açarım diyordu.
Topu Enes'e bırakıyoruz.
Evet, hoş bulduk abi.
Öncelikle ben bizden, Pim ekibinden bahsedeyim.
Pim ekibinin açılımı Product Information diye geçiyor.
Bizler ne yapıyoruz? Kısaca bahsedeyim.
Product Information ekibi aslında Trendyol'da ki tüm ürün datasının, ürün katalogunun olduğu ekip.
Bunun içinde neler var diye sorarsanız katalog bilgilerinin içinde...
Content'in kendisi, kategorisi, brand'i, bunların etribütleri.
Biz bunları Trendyol dünyasında varyantları diye adlandırıyoruz.
Aslında bu bilgilerin hepsi Trendyol'un içinde ilk PIM sisteminde oluşup daha sonra Trendyol'da ilgili ekiplere dağıtılıyor, event based asılıyor.
Tam gömeyinde diyebiliriz aslında.
Yani dışarıda bir satıcı dünyası var.
Excel'lerle dönen bir satıcı dünyası ya da integrasyonlarla.
Bu şeyden sonra...
İntegrasyonlardan sonra Trendyolab'a egzerler product information ekibi altında bir product anlamlı bir product haline getiriliyor.
Daha sonra Trendyolab'a satılabilir bir ürün haline geliyor.
Peki kayıttan önce şeyden bahsetmiştik.
Şimdi Black Friday'ı yeni atlattık.
Black Friday sonraki ilk programımız bu.
Kim ekibinin handle ettiği ürün sayısından bahsetmiştik.
Orada milyarlarca üründen bahsetmiştim.
Ben en son ne milyarlarca ürün dünya üzerinde var mı diye bir soru sormuştum.
Oraya bir açıklama getiriyordum.
Şu anki ürün hacminiz nedir?
Nereye kadar scale edecek aktif ürünler, pasif ürünler hepsi beraber mi var şu an sistemde?
Biraz oranın detayını verebilir misin?
Tabii. Aslında bizim en çok önemsediğimiz nokta burası.
Dışarıda ürün satmak isteyen, özellikle Trendyol'un son scale'lerinden sonra Trendyol'a dahil olmak isteyen birçok satıcı var.
Bu satıcılarda aslında dünyadaki herhangi bir ürünü Trendyol üzerinde satmak istiyorlar.
Ta 2 ay öncesine kadar aslında Trendyol'daki ürün hacmi yaklaşık %70 olarak büyüdü diyebiliriz.
Bu da şu anda kontrol ettim ben son baktığımda rakamları.
Trendyol'da şu anda satışa hazır diyebileceğimiz 44 milyon ürün var.
Ve her gün yaklaşık 500 bin ürün tekrar sisteme integre oluyor, işe alınıyor.
Bu bahsettiğim gibi aslında yeni ürünler diyebiliriz.
Çok hızlı bir şekilde büyüyoruz.
Bu anlamda biz de scale'i her gün düşünüp bir yıl sonra ne yapacağımızı karar vermeye çalışıyoruz.
Gerçekten zor bunlar. Çünkü miktar çok hızlı artıyor ve bu rakamlar...
bir ay yıl öncesinde varsayılı rakamlardan çok çok daha hızlı büyüyebiliyor.
O yüzden her gün yeni bir challenge önümüze çıkabiliyor bu anlamda.
Abi bu arada programa şimşek gibi şimşek gibi girdik ama sizi tanıtmadık.
Enes biraz düzelirken ben bahsedeyim mi?
Tabii. Yaklaşık 3 yıldır ben Trendyol'da çalışıyorum.
İçeri girdim de aslında Trendyol'da büyük bir dönüşüm vardı.
Trendyol'da daha yeni bir microservice dönüşümü yapılıyordu ve o zaman market presi bir ekip.
kurulmuştu. Bu ekip aslında şu anda alt domenleri bölünmüş ekibin anası diyebiliriz.
İlk geldiğimizde Java'ya dönüş de vardı aslında ekipler içinde.
O zaman da data state çok ağırdı ama monotik bir state vardı.
Bunu microservice'e nasıl dönüştürebiliriz diye.
Ekipler sürekli çalışıyordu.
Girmediğimizde aslında kod kalmamıştı o zamanlarda.
Stock API'inden, listing API'ine, price API'ine kadar birçok şey böyle sıfırdan yazılmaya çalışıyordu.
Çok heyecanlı zamanlardı.
Küçük bir ekipti. Hatırladığım kadarıyla 200 kişi belki vardık ya da yoktuk ama şu anda 600 kişiye kadar ulaştık.
3 yıl sonunda da bir süre sonra ben domenini değiştirerek Product Information ekibine geldim.
Yaklaşık 2 yıldır da burada çalışıyor durumdayım.
Yalın geliştirici olarak.
Merhaba ben de Nur Ceylan.
Ben de 4 yıldan uzun bir süredir Trendyol'dayım.
Ben başladığımda 60-70 kişi civarında bir ekipti teknoloji ekibi.
Şu anda 500'den fazla ekip arkadaşımız var içeride.
Bütün bu değişime şahit olmak inanılmaz güzel bir şey gerçekten.
Ben de Pim'e gelmeden önce içeride birçok ekipte çalıştım.
Mobil ekiple, web ekibiyle, hepsiyle deneyimlerim oldu.
Bunları deneyimlemek çok güzel bir şeydi benim için de.
Öyle. Biz takımımızın konumu gereği Legacy'e sync yapan takım olduğumuz için sizle aslında çok yakından birlikte çalıştık.
Hatta beraber öldürdük orayı.
Çok az bir kısmı kaldı.
Peki sizin ekibinizin çalıştığı, yakından çalıştığı diğer ekipler kimler?
Kimlerle beraber çalışıyorsunuz ve ne tarz zorluklar yaşıyorsunuz?
Abi şöyle anlatayım aslında PİM dediğimiz ekip bu Alibaba sürecinden sonra da yine bu çok vurgulandı ama aslında tam olarak Trendyol'un göbeğinde duruyor.
Trendyol'daki ilk giriş kapısı diye de adlandırabiliriz.
Biz ürün ekibi olduğumuz için ürünle ilişkisi, ilgisi olan tüm ekipler aslında PİM'le bir şekilde iletişim kuruyor.
Bu OMS'de oluyor, depoda oluyor, geri geliyor browsing ekibi, indexing ekibi.
İçeride sayılacağı tüm domainler aslında bir şekilde PIM'den bir bilgiye ihtiyaç duyuyor.
Kimi brand ihtiyacı duyuyor, kimi kategori bilgisine, kimi bu hierarşi bilgisine ihtiyacı duyuyor, kimi ürün üzerindeki metadata bilgisine ihtiyaç duyuyor, kimi kampanya datasına ihtiyaç duyuyor.
Bir şekilde PIM ekibi sürekli domainlerle iletişim halinde, aslında şöyle söyleyebiliriz, datayı sağlayan ekip diye adlandırabiliriz.
Genelde Trendyol sistemine data veren ekip oluyor.
Ama en çok iletişim kurduğumuz ekiplerden biri indexing ya da browsing ekibi adlandırılmaz.
Ürünü gösterimli yapan trend.com üzerinde ya da web mobil üzerinde ürün gösterimi yapan ekip diye adlandırabiliriz.
Sonuçta ürün olmazsa bir şey satamayız.
Yani hepsinin en başında ürüne ihtiyacımız var.
Ve Enes'in de söylediği gibi ürünle ilgili her şey satış olgunluğuna erişebilmek için öncesinde pimden geçmeli.
Buna işte tedarikçinin girdiği ürünler dahil.
Bizim kendi depomuzda bulunan ürünler dahil.
Bir de flow-through dediğimiz bir yapı var.
O da dahil olmak üzere.
Trendyol'un her yerine dokunuyoruz biz Pim ekibi olarak aslında.
Süper. Peki böyle Pim ekibinden de biraz bahsedebilir misiniz?
Yani sizde ne tür niteliklere sahip insanlar var?
Yani işte developerlar, şey kıyı vesaire falan.
Biraz da burada tabii kendinizde ne rol yaptığını, ne rolde bulunduğunuzu da anlatabilirsiniz.
Süper olur. Ben isterseniz kısaca anlatayım.
Pim ekibi aslında...
İlk başladığında çok çok kalabalıktı.
Şu son zamanlarda ihtiyaçtan doğan şey cahili süreçte işletebilmek adına ekipleri bölmeye başladık aslında.
Pim ekibi altında aslında product'ı ve kampanyayı manage eden hatta yakın zamanda kurulan inventory diye ayrı bir domen daha doğdu.
Aslında inventory domeninde price, stock, listing hareketlerini takip eden, bunların ilgili update'leri ve değişiklikleriyle ilgili sistemlere yeten ekip.
Bizim ekipte aslında product ve kampanya diye ikiye bölebiliriz.
Product tarafında da aslında ürün hareketleri, kampanya tarafında da kampanya hareketlerini inceleyip, buna ilgili eventlerle sistemleri besliyor durumdayız.
İçeride bu ekipleri üçe bölersek, totalde 20'yi aşkın kişi var.
Alt ekiplerde de yaklaşık 58 kişiden oluşan, içeride ANST'nin, developer'ın, tester'ın, backend ve frontend developer'ların olduğu ekipler var.
Deli değil ve teknoloji olarak bölersek, şundan bahsetmek isterim.
İlk Pim ekibi kurulurken biz özellikle ekibe sonradan dahil olan kişiler daha çok Java siteyine, JVM siteyine hakimdik.
Bizden önce de Pim sistemleri .NET üzerine yazılmıştı.
İki ekibin birleşip yeni bir ekip oluşması gerekiyordu.
Ali Baba'nın da önceliklerinden biri aslında Product Information.
Pim ekibinin replatform edilmesiydi.
Çünkü Pim ekibinin scale ihtiyacı vardı.
Pim ekibi scale olmayınca aslında Trendyol'un scale'i baltalanıyor durumdaydı.
Ürün girişi ne kadar iyi olursa o bazda da daha fazla ürün satabilecek durumdaydık.
Bu anlamda tren yoldaki ilk platform projelerinden biri de Pim'dir.
Pim projesi ilk platforma başladığında iki ekibin daha iyi konuşabileceği ortak bir dil arayışına girdik aslında.
Hem GVM siteyini hem DATTE siteyini bilen developer arkadaşlar vardı içeride.
Bu arayış da bizi en iyi tatmin eden ve yeni bir...
dil olması hasebiyle aynı zamanda Functional ve Object Oriented dil desteklemesi işte bir anlamda da bazı sorunları görüp çözmüş olan Kotlin diline geçiyor olduk.
Kotlin dili iki ekibinde artık ortak konuşabildiği bir dil oldu.
Kotlin dili çoğu anlamda hem Java'dan hem .NET'den hem Scala'dan aslında birçok dilin iyi yönlerinden alınmış bir mix bir dil aslında ve Şu anda bizim sorunlarımızın büyük birini
çözüp çok sevdiğimiz bir dil olma haline geldi.
Hatta projelerimizin çoğunu, önceden yazılmış projeleri de Java'dan, .NET'ten, Kotlin'e aslında taşıdık.
Çok da memnunuz. Bunu yaparken de aslında hiç de zorlanmadık.
Çünkü önceden bu siteye sahip olan arkadaşlar çok rahat bir şekilde adapte olabildi.
Abi son bir yıldır ben trend oldukları teknolojileri takip ediyorum.
Kotlin'i yazan genelde sizi görüyordum.
Yani sizin ekibiniz vardı. diyereklerde çok görmüyordum ama siz bunun böyle bayrakları oldunuz içeride.
Biz de ilk mikro servisimizi yazmaya başladık geçen hafta.
Çok da memnun kaldık gerçekten.
Siz nasıl oldu da böyle çok önceden bunun haberini alıp bunu sürecinize katabildiniz?
İçerideki arkadaşlar gerçekten yeni şeyleri öğrenip ve adapte etme anlamında çok heyecanlı arkadaşlar.
Kendi ekibim için bunu çok net bir şekilde söyleyebilirim.
Trendonun genelinde zaten var ama bizim ekip bazında bunu çok rahatlıkla söyleyebilirim.
Bir şey çıktığında Bizim Slack kanalında çok aktif kullanılır.
Sizler de biliyorsunuz. Slack kanalında sürekli böyle artık telefon elimden düşmüyor bazen.
Abi şu var deneyelim mi?
POC yapalım mı? İşte bu var buna bir bakalım mı diye sürekli böyle aramızda zaten yazışırız.
Kotlin'de ilk çıktığı zamanlarda böyle bir küçük bir POC ile başladı aslında yine hikayesi.
Alıp bir yazalım dedik.
Hiç bilmediğimiz değildi ama neredeyse birkaç gün içinde çok rahat bir şekilde böyle dilin sintaksına hakim olabildik.
Yazabildik. Bizim için çok...
akıcı geldi. Ondan sonra bir POC yapalım dedik.
POC yaptık. Ekip de beğendi.
İşte içindeki core ritimler asenkron akışlarının oluşu olması.
Dilin çok rahat anlaşılabilir ve hızlı şekilde adapte edebiliyor olması bizi memnun etti.
Bu şekilde biz de hızlı bir şekilde başladık aslında.
Biz de bir projeyi şeyde Kotlin'de denemek istiyoruz aslında.
Ufak bir giriş yapmak için. Biz de şu anda JVM sitemdeyiz ama Java kullanıyoruz ağırlıklı olarak.
Ben de .NET kökenliyim aslında da bazı yerlerde böyle .NET'in bazı özelliklerini aradığım oluyor.
Bazen de Java'da diyorum vay ne kadar güzel yapmışlar adamlar bunları.
Çok da şeyi duyuyorum yani dediğin gibi hem Java'nın hem de .NET'in böyle güzel yönlerini almış bir dil olduğunu duyuyorum da bir türlü deneme fırsatım olmadı.
Eğer bir projeyi deneyimlersek sizin de kapınızı çalarız büyük ihtimalle.
Şeyi sorayım ben, siz ikiniz de aslında Pim'e...
Daha sonradan dahil oldunuz.
Oradaki onboarding stratejisinden de biraz bahsedebilir misiniz?
Dahil olduğunuzda neler yaşadınız?
Siz dahil olduğunuzdan sonra şu ana kadar ne tür değişiklikler yaptınız?
Şu anda yeni birisi başladığı zaman sizin ekibe ne tür bir eğitimden, onboarding sürecinden geçiyor?
Biraz onlardan bahsedebilir misiniz?
İki ayağı böleyim. Ben isterseniz şeyden bahsedeyim.
Devolopment sürecinden. Nur da test sürecinden bahsedeyim.
Test ekipleri nasıl ilerletiyor diye.
Bizim tarafta şöyle, biz ilk başladığımızda aslında PIM çok da scale olabilecek bir yapıda değildi.
O zaman onboardinglerde aslında bu anlamda hem ekip olarak da scale olamıyorduk hem de teknoloji olarak scale olamıyorduk.
Bizim gelişimizden sonra event-based bir yapıya çevirdik.
İşte arkada domain-driven bir dizayn uygulamaya çalışmıştık.
Aynı zamanda SQLS yapıp hem scale'i API tarafını scale artırmaya çalıştık.
Aynı zamanda ekip anlamında da büyümeye gidiyor olduk.
Çünkü ekipler domeniler bölündükçe, API'ler bölündükçe çok rahat bir şekilde görev tanımını biliyorlardı.
Şu anda işe alım onboarding sürecinde şöyle ilerliyoruz.
Backend tarafında en azından söyleyebileceğim süreçti.
Trendyol genelinde ilerleten bir süreç var.
Önce adaylara İK sürecinde bir görüşme yapılıyor.
Buraya biz de dahil olabiliyoruz.
Adayı daha yakından tanıyabilmek için teknik anlamda da...
adayın potansiyelini ölçebiliyor olmak için.
Daha sonra bu süreçten sonra aday olunduysa bir case yollanıyor.
Bu case sonucunda yine biz içerideki arkadaşlarla case'leri inceliyoruz.
Belli parametrelerle case'ler ölçülüyor.
Bizim için okey olan başarılı bir case ise tekrardan adayı ikinci görüşmeye çağırıyoruz.
Bu ikinci görüşmeye yine biz dahil oluyoruz.
Bu ikinci görüşme aslında daha çok case'in üzerinden gittiğimiz, adayı daha çok teknik olarak challenge ettiğimiz bir görüşme oluyor.
Burada baktığımız bazı Özellikler var.
En en önceliklisi bence adayın egosuz olması, gelişime açık olması, öğrenmeyi seven, aynı zamanda paylaşmayı seven bir aday olması.
Çünkü biz Trendyol olarak paylaşmanın öğrenmeden geçtiğini biliyoruz.
Bu anlamda da daha çok paylaştıkça öğrendiğimize inanıyoruz.
İşte Medium kanallarında, Trendyol'un Meetup kanallarında, diğer kanalların hepsinde.
Birçok şeyi paylaştık.
Paylaşmaya da devam ediyoruz.
Bu adayları inceliktikten sonra aslında takıma da uyumu bizim için çok önemli.
Takımdaki dinamikleri de bozulmayacak şekilde uygun adaylarla görüşüp adapt etmeye çalışıyoruz.
Onboarding sürecinde aday ilk geldiğinde adayın tecrübesine bakmaksızın aslında adaya sprint üzerinden bir iş vermeye çalışıyoruz.
Bunu da yaparken de peer'li ilerlemeye çalışıyoruz.
Genelde içeride daha nispeten geçmişi olan bir arkadaşla peer olup hem sistemleri anlatmasını hem iş yaparken beraber kodlamasını sağlıyoruz.
Pay'leri çok uzun ömürlü tutmuyoruz.
Muhtemelen adaylar biri hastalık pay'ler oluyorlar.
Pay'leri değiştirmesi aday işinde iyi oluyor.
Sonraki pay'leri de yeni şeyler öğrenebiliyor.
Ben kısaca böyle bahsedebilirim.
Ben de bahsedeyim.
Ben ilk başladığımda Pim ekibine 3-4 kişi developer vardı.
2 kişi de biz testçi olarak başlamıştık.
O zamanlar Pim'den önce New Admin, One Admin diye 2 tane daha admin panelimiz vardı ve İçerideki Merchandiser ekiplerimiz o iki panele daha aşinalardı, daha pratikleri vardı.
Pimi de onlara kazandırmaya çalışıyorduk o zamanlar ve çok temel özelliklerini sunmaya başlamıştık.
O zamanlardaki problemlerimiz de şu anki problemlerimiz birbirinden çok çok farklı zaten.
Şu anda da o zamanlar daha fonksiyonel ilerliyorduk ama otomasyonla ilerleme ihtiyacımız doğdu test tarafında aslında zaman geçtikçe.
Performans testleri yapmamız gerekti.
Bazı kezleri otomatize etmemiz gerekti ki dönüp dönüp tekrar bakmayalım.
İşte otomasyon koşsun halletsin diye.
Şu anda da aramıza bir testçi arkadaşımız katıldığında ona böyle sırayla ilk olarak sistem nedir?
Nasıl çalışır? Biz niçin bu işi yapıyoruz?
Ve Pim'de gördüğün ekranlar, Pim'de gördüğün özellikler Trendyol'da neye karşılık geliyor diye böyle teker teker seçimler yapıyoruz.
Payrolluyoruz. İçerideki projelerimizi anlatıyoruz.
Onlardan küçük küçük destek olmalarını sağlıyoruz.
Ve zaten geldikten sonra biz de birlikte yine aynı şekilde test tarafında da pay-in olarak ufak tefek işler alarak başlıyorlar.
Bir süre test biraz daha riskli olduğu için bu konuda bir süre beraber ilerliyoruz.
Business bilgisi çünkü yeni başlayan birinin az oluyor.
Benim de öyleydi zamanında.
Sonrasında da artık özgür bir şekilde iş çıkarmaya başlıyorlar diğer arkadaşlarımızdan.
Böyle söyleyebilirim.
Ben tekrar teknolojiye biraz döneceğim.
Kotlin'den bahsettik ama bir de...
sanırım 44 milyon veriden, product'tan bahsettik.
Size büyük bir veri tabanı gerekiyor diye düşünüyorum.
Böyle veri tabanını da düşünerek teknoloji kararlarını nasıl verdiniz?
Nerede saklıyorsunuz verinizi mesela?
Ben onu merak ediyorum özellikle.
Bahsedeyim abi. İlk başta Davalı'da bu öngörülerin hepsini aslında düşünerek bunların hepsini skele edebileceğimiz bir model peşine düşüyorduk.
O zaman ekibin aslında DDD konusunda bir know-how'ı vardı.
Ben girdiğimde o know-how'a ekiptekiler kadar sahip değildim ama En güzel özelliği zaten bu ekip içindeki bilginin çok hızlı bir şekilde Trendyol'da dağılıyor olmasın.
Şimdi DD'ni modelleyerek nasıl scale edebiliriz?
SQRS patternlerini uygulayarak nasıl scale edebiliriz diye başladı.
Şöyle karar aldık.
Write konsörlüğümüzü bir relational database üzerinde tutalım.
Bu da MSSQL oldu. Ama read konsörlüğümüzü elastik üzerinde tutalım diye karar verdik.
Trendyol genelinde de benzer yapıları olsa da genelde Trendyol genelinde CouchPay üzerinde write konsörlüğünün tutulduğu read konsörlüğünde Elastik ve benzeri sistemler üzerinde tutuluyorduk.
Biz sadece burada şey, Translationality bizim için önemli olduğu için aslında biraz da Relational Database'i seçiyor olduk.
E-Converter'ın önce Elastik'i seçtik.
Burada her bir işlemden sonra buraları gerçekten çok iyi tasarlamaya çalıştık.
Yani bir event'in içeriği ne olmalı?
Event'in prefiksi ne olmalı?
Spesifik isimler nasıl verilmeli?
Hangi domain'e ait olduğunu nasıl verelim?
Bu konulara çok kafıyorduk.
Mesajlar için neler dönmeli, hıdırında ne olmalı, user e-mailler.
Çünkü bizim için şöyle oluyor. Bir ekran var, pime ekranı var ya da herhangi bir sistem var pime giren.
Bu sisteme giren kişinin sistemde bu işlemi kim yapıyor?
O bilgiyi alıp, ta en uçtan alıp, en arkaya kadar sistemlerde event olarak akıtıp her işlemi aslında kullanıcıya şunu öğretmeye çalıştık.
Senin burada yaptığın bir işlem eventual consistency'dir.
Yani anında olmayacaktır ama bir süre sonra yansıyacaktır.
Bunu kullanıcılarda öğretmek zaman aldı gerçekten.
Öncesinde hep sync olan bir süreçte çalıştıkları için işte işlemi yaptığında anında sonuç görmeye çalışıyor.
Ben işte ürünü ekledim ama hala siteye yansımadı.
Hala geliyor bu sorular. Fiyatımı attım ama fiyatım hala eskisi gibi görünüyor.
Hala gelmeye çalışıyor.
Bunu zamanlı kullanıcıya öğretmeye çalıştık.
Bir işlem yaptığında bu işlem bir süre sonra yansıyacaktır.
Ama yansıyacaktır. Biz arkadaşımız Outbox pattern'dir, ne gerekiyorsa artık.
Bunun gereği oldukça implement edip write kontrolümüzde Atlassian datapedi aldıktan sonra ilgili eventlerle sürekli bir projection oluşturup bunları elastik yazıp belli bir süre sonra da elastikten
aslında kullanıcıya ve diğer bütün sistemlere veriyor durumdayız.
Şu ana kadar scale'imiz konusunda bir sıkıntı yaşamadık.
Testlerimizde de işte rpm'lerde 2 milyon rpm'e kadar çıkıp elastik üzerinde.
Bunları işte yaklaşık 20-30 ms'e kadar maksimum sürelerde verebildik.
Bu da bizi çok memnun ediyor.
En azından gelecek Bir yıl içinde scale'imiz konusunda biraz daha rahat görünüyoruz.
Ama rakamlar aklımızın ucuna gelemeyecek rakamlar hızlı artıyorlar şu anda.
En son event'te son iki ayda %70 oranında bir ürün artışı oldu.
Demek ki gelecek event'te biz şu andaki scale'imizin belki %200, %300'ü büyümek zorundayız.
Database katmanında, API katmanında bunlara cevap vermek için çokça önümüzde challenge'lar gelecek gibi görünüyor.
Bir arşivlemek ihtiyacı var mı peki sistemde?
Bu datayı arşivlemek ihtiyacı.
Şöyle abi onun için de aslında tamamen şey event üzerinden gidiyoruz.
Şöyle yine aynı şekilde eventleri dinleyen başka bir sistemimiz var.
Auditing sistemi ve benzeri sistemlerde.
Bunlar audits olarak ayrıca yine başka bir yere yazıyor durumdayız.
Oradan yine işleniyor.
Bir de bazı datalar gerçekten arşivlenemiyor.
Ama kampanyanın ürünleri datası demiştik.
Kampanyanın içinde yaşayan ürün datası bir süre sonra arşivlenip sinilebiliyor.
Böyle bir artımız var. Çünkü kampanya dediğimiz şey belli bir tarih arasında yaşayabilen bir şey.
Kampanyayı belli bir süre yaşattıktan sonra onu arşivleyebiliyoruz.
Ama mesela bir product atıldığında asla arşivleyemezsin.
Trendyol'a giren bir product Trendyol'un hayatı boyunca yaşamak zorundadır.
Aynı şekilde listening dediğimiz kavram var.
Bunu da anlatmak gerekirse bir satıcının sattığı ürüne biz listening diyoruz.
Supplier'ın product'ı diye adlandırıyoruz.
Ya da seller'ın product'ı diye adlandırıyoruz.
Bunu da hiçbir şekilde biz arşivleyemiyoruz.
arşivleyebildiğimiz datalarda da yine özellikle DBA ekipleriyle beraber çalıştığımız konularda arşivleyebiliyoruz.
Şu anda arşivleyemediğimiz çok büyük data var.
Sürekli büyüyecek.
Bu konuda sürekli çalışıyoruz DBA'lerle.
Gelecek scale'ler konusunda her ay oturup toplanıp işte burada şu anda neredeyiz?
Alertlerimiz bize ne gösteriyor deyip konuşup planlamalar yapıyoruz.
Baya devasa bir sistem.
Şey peki product unification gibi bir şey var mı?
Yani bir product'ın birden fazla sistemde iki tane kayıt olmamasını sağlayan bir şey var mı?
Mekanizma. Abi şöyle ondan da bahsedeyim.
Hayatımızda bir yıl önce dahil olan Quark Qsü süreçleri var.
O süreçler aslında tamamıyla bunu yapmak üzere kurulmuş.
İki ana başlığa toplarsak bir item center bir de content center diye iki tane kavramdan bahsedeceğim.
Gitmek istediğimiz ve hayatımızda olan şeyi.
Content center dediğimiz katman ana data aslında referans nasıl tren dolda satılabilir ürün nasıl şu anda kimin olduğu data bir de item center dediğimiz seller'ın
ürünlerini attığı draft olarak tuttuğu datalar bunlar şu anda SPM sisteminde saklı bir önceki konuşmada elim arkadaşım bundan bahsetmişti SPM sistemindeki ürünlerden bahsetmişti draft satıcıların draft dataları aslında
satılmaya aday datalar bunlar milyonlarca milyarlarca olabilir ama satıcı bunun üzerine sürekli oynamalar yapıyor işte ben bunu atıyor içine ton değiştiriyor Pricen'ı değiştiriyor, adını değiştiriyor, ürünün etribütünü değiştiriyor, kategorisini değiştiriyor, her
şeyini değiştiriyor. Sonra bu ürünler ilgili queue sistemi.
Arada bir sistem düşünelim. Arada Quarkka sistemi.
Yine bununla ilgili bir Medium yazımız var.
Quarkka'nın nasıl skeli olduğu konusunda.
İlgili arkadaşlar yine Trendyol'un Medium kanalından bakabilir.
Quarkka'da SPM'den gelen bu ürünleri, seneden ürünlerini alıp ilgili Similarity API'leriyle ya da Similarity Data Science'ın çalıştırdığı belli algoritmalarla benzerlik bulmaya çalışıyor.
İşte bu ürünün resmiyle Şu anda Trendo sisteminde var olan, satışta olan birinin resmin benzerliği ne kadar?
Aynı kategoriye sahipler mi?
Aynı product koda sahipler mi?
Brandleri benziyor mu? İçeride gerçekten harika da science algoritmaları ve şeyler, problemler çözülüyor.
Bunlar sonucu similarity bize evet bu ürünler benzer derse ürünleri direkt zaten ilgili Trendo sistemindeki yani Content Center'daki bir ürünle eşleştirip bu ürün diye içeri alıyoruz.
Eğer eşleşmezse Quark'ların admin ekranlarına düşüyor.
Bu ekranlarda da bizim Yine arkadaşlarımız ürünleri alıp gerçekten benzer olup olmadıklarını manuel olarak ekranlardan bu ürüne bu ürün benzer deyip işaretliyor ya da bu ürün gerçekten bir telefondur,
gerçekten bir ayakkabıdır deyip onaylayıp gönderebiliyor kohakka sistemi üzerinden.
Bu entegrasyondan sonra zaten çok çok hızlı büyümeye başladı ve seller'lar çok hızlı bir şekilde Trendos sisteme entegre olmaya başladı.
Yani ben yeni satıcı olduğunu düşündüm ben.
Yeni bir ürün gireceğim zaman aslında bu tamamen böyle sistem tarafından kontrol ediliyor.
Artık çalışan işte şeyler, data science algoritmaları kontrol ediyor.
Benim girdiğim ürünün birçok propertiesine göre ve şey değil mi onu?
Daha önceden o ürünün olup olmadığını aslında kontrol edip doğru yere adresleyebilmek için.
Aynen abi. Çünkü biz şunu istemiyoruz.
Trendyol sisteminde aynı kontenti en tane kişisi aslında istemiyoruz.
Bir kontent. Yani biz single catalog yükseliyoruz aslında.
Trendyol'un en baştan beri.
istediği yapı bu. Tek bir ürünüm var ama bu ürünü satabilecek en tane satıcı var.
Bunu yapabilmek için de dediğin şeyi yapmaya çalışıyoruz.
Tabii bunu ben daha öncesinde algoritma çalışmadan önce yine satıcıya şey sunabiliyorum.
Elindeki barkodla benim sitemde bir arama yap ya da elindeki herhangi bir bilgiye arama yap ürün adıyla vesaire.
Gerçekten sitemde böyle bir şey buluyorsan, benim konten santral üzerinde böyle bir ürün buluyorsan bununla meşleyeceğim bir işaretle bana öyle gönder.
Ben bu algoritmayı çalıştırmayabilirim ama göndermezsen de ben zaten arkada bunları yapıyor durumdayım.
Peki şöyle şeyler olabiliyor mu?
Mesela Ben atıyorum telefon diye bir şey giriyorum ama aslında o telefon değil.
Başka bir şey giriyorum onun altına.
Ben bir satıcıyım. Kategori olarak işte telefon seçtim.
Atıyorum iPhone 11 seçtim ama girdiğim şey iPhone 11 değil.
Başka bir şey girdim. Bunu bir şekilde detekt edebiliyor muyum?
Orada da yine data science'ın çalıştığı şeyler var.
Ürünün üzerindeki görsele bakıyor.
Görsel üzerinden YouTube'u çıkarmaya çalışıyor.
Mesela adam bana telefon diye bir marka ya da brand üzerinden gelmiş.
Adını telefonda göndersin ama gönderdirir.
Resme bakıyorum ben. Bir etek.
Aslında oradan etübü çıkardın da kategorisi etek gibi çıkıyor.
O zaman yine algoritmalarla buna izin vermemeye çalışıyoruz.
Yine böyle akıllı şeyler çalıştırmaya çalışıyorlar aslında sistem üzerinde.
Çok güzelmiş ya. Abi ekibinizin baya bir sorumluluğu var.
Anlattığın kadarıyla. Tabi bir de bunu canlıya alma süreci var.
Ne yapıyorsunuz? Biriktirip mi canlıya alıyorsunuz yoksa hemen canlıya vuruyor musunuz?
Haftalı dip doyular mı? Evet haftalı dip doyular.
İsteyen bir trenler var mı?
Topu Nur'a bırakıyorum.
Nur o konuda zaten çok bilgili.
Daha detay verebilir.
Hemen veriyorum. Biz de yani mobil ekiplerde olduğu gibi böyle biriktirip tek bir pakette gönderme durumu yok.
Continuous deployment hemen bitirdiğimizde o işi küçücük de olsa büyük bir iş de olsa deployment'ını anında yapıyoruz.
Ama tabii ki çok merkezde olduğumuzu konuştuk.
Orada olduğumuz için yaptığımız işlerin etkisi de çok büyük olabiliyor küçücük bir değişiklik bile olsa.
Bu yüzden öncesinde çok fazla ekiple bir araya gelip bilgilendirmemiz gerekiyor yaptığımız işle ilgili.
Bu yüzden bunu kaçırdığımızda sonuçların çok kötü olduğunu gördüğümüz bazı senaryolar oldu.
O yüzden buna çok dikkat ediyoruz.
Test tarafı da aynı şekilde.
Bütün işlerimiz, hiçbir işimiz testiz çıkmıyor.
Sağolsun developer arkadaşlarımız da bu konuda çok özverili.
Biz de aynı şekilde elimizden gelen özveriyi gösteriyoruz ve bütün işlerimizin testini yaparak Ve anında deployment'ın en hızlı bir şekilde çıkmasını sağlamak için elimizden geleni yapıyoruz.
Orada aslında bir sürü ekip sizin API'larınıza bağlı durumda.
Çok merkezde olan API'ler var.
Kontrat testini yapıyor musunuz orada?
Böylece kontrat değişiminde herkesin patlaması sağlanabilir gibi.
Hacktio'yu kullanarak kontrat testi yazıyorduk.
Böyle bir tane, birkaç tane API'imiz var.
Bunlar çok önemli noktalarda diğer ekiplerle bir birebir iletişime olan API'ler ve bunlarla...
Karşılıklı kontraktımızın gerçekten de bozulmaması lazım.
Bozulursa direkt kendi yolun butik detayında, ürün detayında görünen ürünlerde sıkıntılar yaşayabiliyoruz.
Bu yüzden de Pecta'yı kullanarak bu tür uygulamalarımız için kontrakt test yazıyoruz.
Dediğim gibi çok merkezde olduğu için sizin API'lar deployment sıklığını ayarlayabilmek için doğru şekilde.
Dediğim gibi birçok farklı test.
bir yöntemine başvuruyorsunuzdur diye düşünüyorum.
İşte az önce saydım mesela kontrakt test yapıyorsunuz.
Onun dışında mesela TDD muhakkak yapıyorsunuz da işte kod coverage'ınızı kontrol ediyor musunuz ya da işte integration testler, extremity testler.
Bu taraflarda neler yapıyorsunuz?
Bu taraflarda bizde iş geleceği zaman zaten unit testinin ve integration testinin öncelikli olarak yazılmış olmasını bekliyoruz.
Bir tane test piramidi vardır bilirsiniz.
Üçgen şeklinde en altta unit test olur sonra integration test.
Onun üstüne Acceptance ve UI Test olmak üzere.
Code Coverage'ına gerçekten çok önem veriyoruz ve bunu düzenli aralıklarla kontrol ettiğimiz küçük bir uygulama da yazmıştık ekip içerisinde.
Code Coverage'e düştüğü zaman onun üzerinden takip edip Nasıl düşmüş, neler olmuş diye hemen onu düzeltecek hareketlerde bulunuyoruz.
Unit testler biraz developerların sorumluluğunda.
Bunun üzerine acceptance testlerimizi yazıyoruz.
Ekip içerisinde bunun için Java'nın REST eşit kütüphanesini kullanıyoruz API testlerimizi yazmak için.
Yakın bir zamanda da şuna başladık.
Acceptance testlerimizi deployment pipeline'larımıza bağladık.
İçeride Celures ekibinin yanlış hatırlamıyorsam bir projesi vardı GATEC diye.
Biz de onu uygulamaya başladık.
Onunla birlikte bir deployment olurken ilgili ortama çıkmadan önce acceptance testler de bir ortam ayağa kaldırılıp koşuluyor.
Ve orada acceptance testleri kıran bir durum olursa işin deploy olmasını engelleyecek bir yapı kısaca.
Bunu da sağlıyoruz. Bunun üzerine performans testleri içinde Python ve Locust kullanıyoruz.
Trendyol'un içerisinde zaten tüm ekipler olarak bunu tercih edip bunu kullanıyoruz.
Bu şekilde test süreçlerimiz.
Aslında çok da yoğun bir dönemden çıktık.
Hatta bizim de program yapmamın sebebimiz geçtiğimiz ay yaptığımız iki tane büyük kampanyaydı.
Şimdi oradan şeye geleceğim.
%70 oranında ürünün arttığını söylediniz.
Son Retro'da neler konuştunuz?
Yani geçen ayın bir etkisi olmuştur eminim.
Retro'dan neler çıktı ve neleri iletiştirdiniz?
Çok eğlendik. Son Retro'da goy goy yaptık yalan söyleyeyim.
Çok iyi aktı dedik.
O zaman bir kez daha Retro diyelim.
Bayağı iyi geçirdiniz o zaman Kasım'ı.
Biz de bugün retro yaptık.
Konu yoktu ya bizde de.
Hiçbir şey çıkmadı cidden.
Bizim de öyle oldu ya. Neden bilmiyorum.
Kasım ayı biraz daha böyle az yeni feature'ların çıktığı bir dönem olduğu için.
İyi hazırlandık gibi sanki tüm trend olarak.
Gördüğünüz rakamlar birkaç yıl öncesine kadar hayal edemeyeceği bir rakamdı.
Ben çok iyi hatırlıyorum şeyde. birkaç yıl öncesinde böyle 400, 500, 600 milyar falan olunca aa bir saniye ya ne yapıyoruz dediğimiz anları şimdi 1.8 milyonunu görünce heyecanlanmıyoruz bir duruma geldik artık.
Bayağı hızlı büyüyoruz.
Biz de mesela bu event döneminde önceden yaptığımız o yoğun hazırlık tarzından dolayı çok büyük bir gol yemedik.
Hatta hiç gol yemedik diyebilirim.
Herkesin buradan da eline sağlık.
Güzel bir dönem geçirdik.
Retro'da da aslında böyle Onun biraz şeyine ekmeğini yedik.
Oturduk muhabbet ettik. Şey yine kem açtık uzun üzerinden.
Birbirimizi gördük. Ne yapıyorsun?
Ne ediyorsun? Hatta şey yaptık.
Nurcelihan'da bir araba bakıyorduk.
Araba fiyatları da çok artmış.
Onun muhabbetini yapıyorduk.
Böyle geçti. Baya güzel geçti.
Şeyi hatırlıyorum ya. Sıfır araba modelleri ikinci el araba modellerinden daha uygunmuş.
Bunu konuşmuştuk. Evet ya o piyasada baya bir garip hale geldi.
Nasıl olabilir öyle bir şey ya?
0-3 piyasada olmadığı için galeriler almışlar önden arabaları.
0'dan pahalıya satıyorlar.
Yani 0'ı getirebilmek için 3 ay ya da 6 ay beklemen gerekiyor.
Galeriler sana diyor ki bak bende hazır var ama biraz daha pahalı.
Peki bütün araba marka ve modellerinde böyle mi?
Ben bu arada hiç arabalardan anlamadığım için böyle soruyorum.
Hiç bilmiyorum. Ben de bilmiyorum.
Ferrari'de falan böyle. Yani değişik olabilir ya.
Ferrari'de falan böyle. 5 bin araçların da öyle değil galiba.
Bir saniye Ferrari mi?
Hiç bakmadık ya. Araba dediğin o değil mi ya?
Siz bunu mu biliyorsunuz?
Onda ikinci eline binilmez ya.
Ya ben aklıma en başta da gelmişti.
Atladım. Sormak istiyorum.
Şimdi bir Pim ekibini zaten biliyorduk hepimiz.
Sonrasında Jim diye bir ekip çıktı.
Jim ekibi duydum ama tam olarak ne olduğunu veya bir ekip midir yoksa projenin ismi midir bilmiyorum.
Bunu da detayın gelmişken sizden öğrensem.
Yani bir şey aslında yine Trendo'nun hızla büyümesinden dolayı.
Yani bu tüm ekiplerde vardır neredeyse.
Bir şey gibi mitoz bölünme gibi sürekli çoğalıyordu böyle.
Ekipler büyüyor, büyüyor, büyüyor aslında.
Çünkü doğmaya ihtiyaçları bunlar.
Ve aslında her domain içinden yeni bir domain çıkarıyor.
Bizde de aslında benzer bir şey oluyor. Önceden PIM olarak bilinen, belki 4-5 kişiden oluşan bir ekipti.
Zamanla işte entegrasyonlarıyla, ilgili geliştirmeleriyle beraber büyüyen, developer anlamında da, anayasa anlamında da büyüyen ekip zamanla bölünmeye ihtiyacı duydu.
Çünkü bizler ECA ile inanın 7-8 kişiden fazlanın da aslında bir takım için yönetilemez olduğunu düşündüğümüz için bu ekip zamanla bölünmeye başladı.
product information, product datasını ve bunun akışlarını inceleyen bir ekip, bunu menajeden bir ekip de kampanyanın product ilişkisi olan kampanyada kampanyanın açılması, kapanması, ürüne
kampanya eklenmesi, işte kampanyada gizli görünürlük vesaire tüm akışların bizim için işletildiği bir CIM ekibi olmuştu aslında.
CIM, PIM ve bunun da altında çok yakın zamanda doğan bir inventory diye bir ekip daha oluştu.
Aslında bu üç tömeli bölünmüş diyebiliriz şu anda.
Programın başında şeyden bahsetmiştim.
Geçen aylara göre %70 daha fazla ürün girişi oldu demiştin şey sizin tarafa.
Büyük ihtimalle böyle business metriklerini de takip ediyorsunuz herhalde.
Bu tür takip ettiğiniz metrikler neler var başka?
Şöyle abi bahsettiğin metriklerin hepsi aslında bizim köşe süreçlerinde akan ürünler ve bunlar bir dashboard'a basılıyor durumda şu anda.
Biz şöyle anlatayım.
Uçtan uca aslında her şeyi...
iyi monitör etmeye çalışıyoruz ve belli metriklerin de ne kadar faydalı olduğunu görmeye çalışıyoruz.
İlk önce 4K Matrix'i zaten tüm tren yolu genelinde yaygınlaştırmaya ve bunu kullanmaya çalışıyoruz.
Bunun yanında ayrıca 4K Matrix'in bir parametresi olan monitoring süreçlerini biz işletmeye çalışıyoruz ve kullanıyoruz.
Bunu da nivreliği tüm tren yolu genelinde kullanmaya çalışıyoruz.
API'lerimizin tüm monitoringleri nivrelik.
Aynı zamanda da hepsinin alertleri tanımlanmış durumda.
50 ms ya da 100 ms'i geçerse alertler tanımlansın.
Bunlar da ilgili sinek kanallarına düşüyor durumda.
Bu sinek kanallarını da aktif şekilde kullanıyoruz.
Grafana'dan ilgili dashboardlarımı da oluşturup bu dashboardlardan da sürekli takip ediyoruz.
Oradan da yine belli alertler oluşturmuş durumdayız.
Buradan gelen alertleri de sürekli takip ediyoruz.
Deployment sürecimizi de Çok sıklıkla yapmaya çalışıyoruz.
Hiç bekletmemeye çalışıyoruz.
Sprintler de aynı şekilde olabildiğince hızlı şekilde iletmeye çalışıyoruz.
Bir sorun olduğunda çok hızlı şekilde cevap vermeye çalışıyoruz.
Bu arada ekibindeki arkadaşlar bu anlamda gerçekten çok çok hızlı reaksiyon veren arkadaşlar.
Bir sorun olduğunda hemen cevap verip sorunun çözümüne ulaşabiliyor durumdayız.
Bahsetti yine Nurcay ile.
Code coverage gibi parametre bakıyoruz.
Test süreçlerinde olmazsa olmazlarımız var.
Bazı konularda hiç toleransımız yok.
Çünkü bunun zamanında çok dilimiz yandı.
Küçük bir parçanın değişmesi zorunda büyük bir sorun ortaya çıkınca artık bu şeylerde hiç şakamız olmuyor.
Öyle özetleyebilirim. Abi az önceki soruyla aslında ben böyle biraz sert yaşanan olayları öğrenmek istemiştim Retro'dan.
Tekrar deniyorum. Canlı sistemi abi en son ne zaman patladı?
Ne oldu? Evet ya biz niye şey almadık retro sorusuna geçtik ama son retro hepimiz rahat geçti de bir önceki retrodan falan böyle bir şeyler çıkmaz mı?
Ya benim hatırladığım bu konuyla ilgili bir şey var.
Aslında son zamanlarda değil biraz daha eski ama hiç unutamıyorum bu olayı.
Şimdi kendi yolu önceden beden ve renk olmak üzere ürün kırılımlarını gerçekleştiriyordu sadece.
Bir süre sonra biz pimi refaktör etmemizle birlikte bunları slicer ve varianter isimlerini vererek.
iki kralım haline getirdim.
Eskiden beden ve renk olduğu için Trendyol'un içinde her yere beden için size hardcoded olarak yazılmış.
Bir gün içeride bütün ekranlarda da size olarak görünüyor beden.
Bir gün bunu beden olarak göstermeye karar veriyorlar.
Biz de bu değişikliği yapıyoruz.
Sadece bir string değişikliği ve gönderiyoruz.
Sonrasında her yer patlamıştı.
Her yer bunu size olarak görmek istemiş ama biz oradaki yaptığımız küçücük bir string değişikliği bile Trendyol'da çok büyük etkilere yol açmıştı.
Bunu test etmeden production'a ilerlemiştik.
Çünkü küçük bir şey olduğunu düşünmüştük.
Böyle bir hatamız olmuştu.
Ne yaptınız hemen? Böyle geri mi aldınız geliştirmeyi böyle panikle?
Önce anlamaya çalıştık aslında.
Yani bundan sebep olabileceğini hiç düşünmedik.
Sonrasında baktık ki buymuş.
Sonrasında geri almak durumunda kaldık.
Başka bir şekilde ilerledik.
Peki buradan eminim bir ders çıkarmışsınızdır.
Böyle sürecinizi bununla alakalı olarak değiştirdiniz mi?
Tabii tabii yani küçük büyük demeden bütün işlerimizde, bütün test özverimizi gösteriyoruz.
Hani nerelere etkisi dokunabileceğini, neler olabileceğini bazen tabii ki hepimiz gibi öngöremiyoruz.
Bu yüzden test çok önemli ekibimizin içerisinde.
Her şeyi daha çok test ederek, teste hep öncelik vererek ilerletmeye çalışıyoruz.
Bu da bize ders oldu birazcık o noktada.
Güzel, güzel. Lesson learned.
O zaman başka sorunu veya böyle konuşmak isteniniz, paylaşmak isteniniz, ekstra bilgi var mı?
Ben şeyden bahsedeyim.
Pim çek, bomba at.
Motlamışsın. Evet ya.
Problemin başladı.
Başladı şey derse böyle bir pim çekme şeyini abi konuşma başlarken diye tatlı olur.
Abi işte işte bilmem ben koymanız.
Evet ya. Kimapen bir de gerçekten kimapen var abi.
Her türlü şifrede 61 kullanıyor olmamız o da ayrı bir konu.
Evet abi. Şimdi security gelecek.
O zaman.
Çok teşekkürler. Bir dakika ama.
Evet biliyorum.
Kaçırır mıyım Barış sence?
Programın başında bize bir sözü vardı.
Hatta bir kukla okudum.
Kendisi bizimle bir şarkı söylemek istiyor.
Abi çocukken söylemiştim ya.
Şarkı şeydi. Le Mansan Rüzgar'dı.
Penceremin perdesini havalandıran rüzgar.
Denizleri köpük köpük dalga randıran rüzgar.
Gir içeri usul usul beni bu dertten kurtar.
Gir içeri usul usul beni bu dertten kurtar.
Komşular gelir abi şimdi şikayete.
Abi çok güzeldi. Gerçekten.
Bu konu nereden çıktı?
Efekli mefekli gelecek.
Çok hoşuna gidecek. Çocukken bunu söylemiştim.
Oradan geldi aslında. Biz konuşma öncesinde başlamıştık.
Çocukluk kasetlerinden falan bahsediyorduk.
Çocukken işte bir tane kasetimi bulduğumdan bahsettim.
Ergenlikte söylediğim bir şarkıymış.
Bu sesi duyunca falan kulaklarım ağrımıştı.
Ondan bahsediyorduk da. Bir gol yemiş oldum.
Ya ben kaset bulsam şu an mükeyyir bulamam.
Evde yokmuş. Aynen doğru diyorsun.
Sen nasıl buldun mükeyyiri?
5-6 yıl önce falandı bu dediğim olay.
O zaman da artık eski bir radyoda verilmiştim.
Şu anda zaten nerede hiç bilmiyorum.
Bir de onlar manyetikti galiba.
Baya kolay bozulabiliyordu değil mi?
Aynen doğrudur abi.
Kaybolan gençliğimiz değil.
Hepsi bir herhalde. Hüzünlü bir program dönüştü.
Abi biz teşekkür ederiz.
Konuşma fırsatı verdiğiniz için.
Teşekkür ederiz. Biz çok teşekkür ederiz.
Çok sağladınız bizi.
Kabul ettiğiniz için. Teşekkürler.
Kolay gelsin. Herkese iyi akşamlar.
Çok sağ olun. Herkese teşekkür ederim.
Bu transkript otomatik olarak çıkarıldı; kayıtla küçük farklar olabilir.