Selam Ekip - E51 - Inventory

Selam ekip, ben Productivity ekibinden Erdem.

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 51.

bölümünde Inventory ekibiyle birlikteyiz.

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

Evet, hoş geldiniz arkadaşlar. Hoş geldiniz.

Hoş bulduk. Hoş bulduk.

Kısaca kendinizi bize tanıtabilir misiniz?

Selamlar, öncelikle ben başlayayım.

Adım Aytunç, 5 yıldır Trendyol'da çalışıyorum.

Daha öncesinde bir 4 yıllık spor eğlence geçmişim bulunuyor.

Trendyol'a başladığım zaman da yine şu anki tribe'ımız Pim adıyla geçiyordu ve 10-15 kişilik bir ekiptik.

Ekip büyüdükçe daha küçük 6-7 kişilik ekipler ortaya çıktı ve günün sonunda bu bölünen ekiplerden biri olan inventory takımında 1,5 yıldır çalışıyorum deyip sözü Hamza'ya vereyim.

Merhaba ben de Hamza.

Trendyol'dan önce 5 yıllık bir full stack developer geçmişim var.

Daha çok aktarılmış gerçeklik ve eğitim sektörlerinde çalışmıştım.

Son 2 yıldır da Trendyol'da çalışıyorum.

İlk indexing'de başladım.

Bir sene indexing'de çalıştım.

Son bir senedir de şu an inventory takımındayım.

Indexing de PIM'in altındaydı değil mi Hamza?

Indexing daha önce Discovery altındaydı.

Bu en son bir organizasyon değişikliğiyle beraber Product'a geçti.

Zaten o product'a geçmeyle beraber ben de inventory'e geçmiş oldum.

Anladım süper. Hayırlı olsun o zaman ekibim.

Hoş geldin. Sağ olun. Hoş geldiniz tekrardan.

Inventory takımı Trendyol'da ne yapar?

Aslında inventory deyince birazcık kendini açıklıyor gibi ama birazcık daha detay verebilirseniz süper olur.

Abi şöyle aslında inventory takımı Trendyol platformunda satılan tüm ürünlerin fiyatlı stoklarından sorumlu ekip diyebilirim.

Bunların işte management'ını yapıyor.

Stokların rezervasyonlarından.

arttırıp azaltılmasından ya da fazla ürün satılmasından satılmamasından sorumlu ekip diyebilirim.

Abi bu bir ara şey oluyordu.

Gerçi çoktandır denk gelmiyorum da şeyden eskiden aklımda kalmış.

Böyle bir sipariş veriyorsun.

Bir tane olan almışsın sonra böyle mail geliyor.

Aslında o ürün yok hani diye mail geliyor.

Kusura bakma ya da iade şeyi falan geliyor.

O zamanlardan kalma olan ekip burası mıydı?

Bağlantıyı kurdun mu çok emin değilim ama.

Aynen. Aslında o bahsettiğin sorumluluk şu an inventory takımına geçmiş oldu.

Daha öncesinde inventory diye bir takım yoktu aslında.

Sonradan kuruldu bu takım.

İşte o bahsettiğin yapıyı yöneten stok servis diye bir servis var.

Atıyorum son bir adet ürün kaldı.

Aynı anda iki kişi bunu sepete attı.

Kim ödeme adımına daha önce geçerse...

Aslında o kazanmış oluyor.

Diğerinde sepet adamında bu ürün satıldı diye uyarı veriyoruz şu anda.

Geçmişte demek ki böyle bir şey yokmuş ki bu sorunlar yaşanmış.

Evet evet benim senin çok eski bir haberim ama aklımda kalmış.

Acaba de numarası burayla bağlantılı mı?

Ama hala öyle mail gelme ihtimali var.

Ağzında olsa illa vardır diye tahmin ediyorum.

Birini aynı anda aldı diğeri ne bileyim butona bastı falan böyle ucu ucuna hani.

Bazen incident yaşar.

Ucu ucuna olur mu ondan emin değilim ama incident yaşarız ve stoku...

Doğru yönetemeyiz. O zaman out of stock satabiliyoruz yani o durumlarda.

Ya burada out of stock olma durumu sadece şöyle olabilir.

İşte seller deposunda iki ürün vardır.

Üç göndermiştir. Biz de üçünü de satmışızdır.

O son müşteriye işte ya üçünden biri aslında işte size gelen mailin aynı sonunda gidecek ve bunu tedarik edemiyoruz diyeceğiz aslında günün sonunda.

Ama onun haricinde bir tane olup da iki tane satma ihtimali şu an yok diyebilirim.

Ha okey okey ben daha onu düşünmüştüm ama senin dediğini anladım.

Hani seller'ın fazlan stok girmesi gibi bir şey aslında fiziksel karşılığı olmayan bir sayı girmesi gibi bir şey.

Evet evet yani bir onu da incidentsal bir case olarak düşünürsek işte seller'ın yaşadığı bir incident yüzünden.

Aynen. O yaşanabilir.

Anladım anladım. Güzel güzel çok kaliteli giriş yaptım bak şu an bu bölüm çok güzel geçecek.

Peki, inventör ekibi şu an bu bir tribe değil bu bir ekip.

Bu ekip de şu anda Hamza Fostek developer olarak önceden çalışmıştı.

Şu anda hala öyle mi bilmiyorum. Ama sizdeki bu dağılım şu anda nasıl?

Burada ben bahsedeyim biraz.

PM ile beraber aslında ekip de 7 kişilik bir ekipten oluşuyor.

Bir lead, iki senior, bir mid, bir de junior ve QA developerımız var.

Daha çok bizim ekip back-end developer üzerine kurulu.

Front-end yok öyle diyebilirim.

Ekran çalışmamız yok bizim.

Direkt backend'deki entegrasyonlardan oluşuyor aslında.

Biraz ihtiyaçlar doğrultusunda aslında geliştirilmiş bir ekip denilebilir.

Hiç ön yüz geliştirmesi yapmadığı için ya da bir internal site'da bir frontend ihtiyacı olmadığı için içeriğinde de frontend developer yer almıyor.

Ama önümüzdeki günlerde Excel ile aşırı neşir olmaya başlayacağız.

Onu da bir frontend olarak sayarsak.

Yine frontend, Excel. Aynen ya bizim Pim'de Excel zaten frontend gibi sayılabilir.

Aynen Erdem. Productivity ekibinden şey alacağız biraz sorumluluk bu noktada.

Aynen çok güzel olur abi. Pim'ler böyle tanıya bakın.

Pim Pim'i tanır.

Var ya devretmek istediğimiz bazı konular güzel olur.

Bizim ekip de böyle geçmişten bölünme sonrası oluşan bir ekip.

Birkaç farklı ekibin sorumluluğu da bizde devam ediyor.

Legacy projeler var. O yüzden böyle işte sonradan devrettiğimiz şeyler var.

İnventorya da gidecek. şeylerin olması güzel olacak bizim için.

Ben birazcık çalışma düzeninizden bahsedelim istiyorum.

Sprintleriniz nasıl? Bir hafta koşan var, iki hafta koşan var içeride.

Birazcık onlardan bahsedebilir misiniz bize?

Bizim çalışma düzenimiz oldukça düzenli ve işlevsel aslında.

Haftalık sprintler koşuyoruz.

Pazartesi günleri grooming yapıyoruz.

İşleri olabildiğince küçük parçalara bölmeye çalışıyoruz groominglerde.

Çarşamba günleri ise planning yapıp sprinti başlatmış oluyoruz aslında.

Geliştirmelerimizi yaparken de Future Flag kullanmayı tercih ediyoruz genellikle.

Çünkü işleri küçük parçalara böldüğümüz için bazen tam bitmeden ana koda birleştirmemiz gerekebiliyor veya diğer ekiplere bağımlı olmadan da Sprint'i tamamlayabilmemiz için Future Flag'li geliştirmemizi

ana koda birleştirebiliyoruz.

Daha sonra Sprint başladığında herkes istediği işi alabiliyor şeye çok dikkat ediyoruz.

Eğer büyük ve domayın bilgisi gerektiren bir iş ise genellikle orada peer ilerlemeye çalışıyoruz.

Bu şekilde diyebilirim. Burada peki Mesela bazı ekipler şey yapıyordu.

Örnek veriyorum. İşte biz bir haftalık sprint yapıyoruz ama retro'yu iki haftada bir yapıyoruz.

Bu tarz şeyler var mı? Yoksa retro'yu planlamadan önce yaparız sonra yaparız gibi bir şeyler var mı düzen?

Bizim tarafta da aslında benzer bir senaryo yaşanıyor.

Planlamadan önce değil de sonra yapıyoruz biz.

Yani atıyorum Sprint 30'u bitirdik.

31'i planladık.

Sprint 31 başladığı anda 30'un aslında retrosunu yapıyoruz.

Bunun sebebi de biraz şey işte Sprint 30'u tamamen komit edebilmek için böyle hep şey olur ya Sprint'in son günü, son saatler biraz fazla yapılacak.

Onun için dedik bir de oradaki işte bir saatimizi de Retro'ya harcamayalım.

Bir sonraki sprintin başında aslında bunu kullanıyoruz.

Anladım. Bu da farklı bir şeymiş bak.

Farklı bir olaymış bunu ilk defa duydum.

Bizde de çünkü şey oluyor. Planlamadan önce yapıyoruz.

Çünkü retro'da bazen şey oluyor.

Alacağımız aksiyon planlamayla alakalı oluyor.

Yani böyle ekipten ekibe tabii değişiyordur.

Bizde genelde aynı şey oluyor. Ya planlamada şunu şöyle yapalım.

Planlamadayken bunu böyle yapalım gibi.

Aksiyonların sayısı genelde daha fazla olabiliyor.

O yüzden böyle planlamadan önce yapmak daha kolay oluyor.

Çünkü planlamadan sonra yaparsak bir sonraki haftaya kayıyor gibi bir şey oluyor.

Ama tabii ekipten ekibe bu alacağın aksiyonların türü değiştiği için farklı olabiliyor.

Ya orada şöyle bir durum yaşanıyor aslında.

Retro'nun öncesinde ekip de kendi içerisinde konuşmalar yapıyor.

İşte birebirler oluyor. Orada ya işte bu task aslında atıyorum 3 puan değil de 5 puanlıkmış.

Burada neyi kaçırdık acaba diye kendi içerisinde bir konuştuğu için.

Retro'da kan ter gözyaşı dökülmeden önce biraz gündeme gelmiş oluyor bazı konular.

Zaten üzerinden geçiliyor.

Evet işte planlamayla alakalıysa o anki planlama içerisinde bir arkadaşımız bunu gündem edip ya bakın işte geçen hafta şöyle şöyle oldu.

Bu hafta da aynı hatayı yapmayalım deyip bir gündeme ediyor.

Orada hemen evet öyle yapıp hızlı bir aksiyon.

Sonrasında Retro'da da çat çut bir sonuca varmaya çalışıyoruz.

Mantıklı. O zaman retroda zaten hani ilk defa konuşulan şeyler daha az oluyordur diye tahmin ediyorum.

Evet evet abi. Retroda yani şöyle oluyor bizde.

Retroda bir madde varsa orada bir kan dökülecek gibi bir şey diyebilir miyim?

Bir şeyler olacak orada.

Evet. Bir aksiyon maddesi yazmamız lazım.

Mantıklı mantıklı. Peki burada abi siz entegrasyon ekibi olduğunu söylemiştiniz.

Entegrasyonda peki kullandığınız teknolojiler nedir?

Yani neler üzerinden iletişim kuruyorsunuz?

Ya da challenge'larından da bahsederiz ama ondan sonra bahsedelim.

Bence en başta kullanıcı teknolojilerden bahsedelim.

Çünkü bizim ekip de entegrasyon ekibi.

Sizler ne yapıyorsunuz? Önce onu öğrenmek istedim.

Biz aslında Kotlin ve Go ağırlıklı çalışan bir ekibiz.

Core servislerimizin çoğu hatta hepsi Kotlin.

Dışarıyı açtığımız reach servislerinin çoğu da...

Go ile yazılmış durumda.

İşte Trendyol'daki her ekip gibi biz de aslında Message Broker olarak Kafka kullanıyoruz.

Arka tarafta Elasticsearch'ımız var.

Bunu internal işlemler için kullanıyoruz.

Yani işte dışarıda read ve write modelini ki farklı data sourced'dan server edildiği bir yapımız şu anlık yok.

Ama gitmek istediğimiz dünya o.

Eğer latencyleri azaltabilirsek, yapıyı buna çevirebilirsek, gitmek istediğimiz dünya o.

Genel itibariyle bu şekilde diyebilirim.

Challenge'lara geldiğimizde diğer konuyla konuşuruz.

Ben Kotlin'in bu kadar yaygın olduğunu Selam ekiple birlikte öğrendim aslında.

Yani bu kadar çok aktif kullanıldığını bilmiyordum.

Kotlin genelde şey mi oluyor? Hani Java kullanan ekipler Kotlin'e mi geçiyor projeleri yoksa bildiğin saf Kotlin yazılmaya mı karar veriliyor?

Onun bir mantığı var mı yoksa denk mi geliyor?

Ya ben geçmişte yaşadıklarımdan örnekler vereyim.

İşte bahsetmiştim ya Pim ekibine katılmıştım diye.

Orada mesela Java ile yazılan bir servisimiz vardı.

Biz bunu ilk Kotlin'e çevirdik.

Kotlin'e çevirdikten sonra anladık ki Kotlin ile aslında yazılan kod daha okunaklı ve daha basit oluyor.

Yazımı da bir tık daha kolay.

İşte Java'dan Kotlin'e geçmek isteyen developer da aslında Sıkıntı çekmiyor.

Hatta bir noktadan sonra şöyle bir şey yaşamıştım.

O kadar çok Kotlin yazmışım ki Java'ya döndüğümde hala Kotlin yazmaya devam ediyordum.

Burası Java'ymış oluyor.

Bir de şimdi Kotlin içerisinde Java Class da barındırıyor.

Java kodlarını da çalıştırabiliyor ya.

O yüzden o konuda bir tık daha rahat oluyor aslında geçiş dönemi.

Ama geneli şey diyebilirim.

Yani Java ise Kotlin'e geçirelim.

Abi kafasında ilerleniyor diye düşünüyorum.

Ama şu var sıfırdan yeni bir uygulama yazacaksak ve Go geçmişi yoksa ekibin direkt Kotlin yazıyor.

Benim gözlerim o şekilde şu an.

Anladım, anladım. Güzel.

Demek ki Kotlin gerçekten şey olarak kullanılıyor ya.

Böyle core projede özellikle hani read service gibi performans bazı bir şey gerekmiyorsa Kotlin yürüyor gibi, akıyor gibi yani.

Aynen. Bizim tarafta da benzer şeyler var.

Yani bizim daha önceki ekibin Product Center tarafında da benzerdi yaklaşım.

Şu anda aynı şekilde. Şimdi ben bir de QA süreçlerinden konuşalım istiyorum.

QA tarafındaki süreç nasıl işliyor?

Testler aynı sprint içinde bitirebiliyor musunuz?

En büyük çalıştırdığım biri bu.

Benim gördüğüm. Bazı ekiplerde şeye dönüyor çünkü.

İşte bu sprint biten işin testi bir sonraki sprint yapılıyor gibi.

Bir haftalık sprint deyince özellikle o kısmı merak ettim ben.

Birazcık oradan bahsedebilir misiniz?

Genellikle ertesi haftaya test süreci aksamıyor.

Bir işleri küçük parçalara...

Böldüğümüz için test edilebilir küçük parçalara bölüyoruz ve bir haftalık sprintte tamamlanabilecek işler almaya dikkat ediyoruz.

CICD pipeline süreçlerimizde de unit test ve automation adımları var.

Developer geliştirmeye başlayıp kodunu gönderdiği zaman zaten eski kodda hata varsa direkt pipeline'da patlamış oluyor.

Ayrıca biz geliştirmeye başladığımız zaman da paralelde QA arkadaş şey yapmaya başlıyor.

Task'ın içindeki detaylara bakarak yeni case'leri var olan automation test projesine eklemeye başlıyor.

O şekilde paralel bir şekilde de çalışabiliyoruz.

Burada dikkat ettiğimiz nokta, planninglerde QA'ya ne kadar iş yükü biniyor, ona çok dikkat ediyoruz.

Eğer ona dikkat etmezsek dediğiniz olay yaşanıyor.

Testi yetişmiyor.

Çünkü tüm işler in QA'de...

Ready for QA'de birikmiş oluyor ve bir sonraki haftaya sarkabiliyor.

O yüzden genellikle biz planiklerde iş alırken QA'ya çıkacak iş yüküne de bakıyoruz.

Eğer iş yükü fazla olursa bazı taskları teknik tasklarla değiştirebiliyoruz.

Bu şekilde bizim sürecimiz.

Sıkıntı yaşamadık çok şükür şu ana kadar bir haftalık sprintte.

Hamza orada şey mi yapıyorsunuz?

Mesela bizde şey oluyor. Dediğin ya QA'yı bir yere kadar alıyorsunuz diye.

Biz mesela puanlama yaparken...

Developer puanı ayrı, developer test puanı ayrı.

İki tane paralelde götürüyoruz.

Hani hesaplıyoruz paralelde.

Hangisinin önce full dolarsa, örneğin atıyorum QA 14 SP alabiliyor hani ortalama diyelim genelde.

14'e varınca ondan sonra alabileceğimiz madde varsa da developer test yapabilir mi ya da testte ihtiyacı olmayan madde alabilir miyiz diye bakıyoruz.

Sizde de aynı mantık mı gidiyor orada?

Bizde tek bir puan var.

QA ve yani Development ve Test aynı şekilde ortak bir puandan geçmiş oluyor.

Genellikle bir işin Development yükü ile QA yükü birbiriyle orantılı gidiyor verdiğimiz Fibonacci sayısına göre.

ortaya çıkmış oluyor. Çünkü biz işi puanlarken sadece işte developmentdaki süresine değil de işin kompleksitesine göre de puan veriyoruz.

Yani development süresi artı kompleksiti gibi puanladığımız zaman o şekilde puanlıyoruz.

QA'ya iş yükü ne kadar çıkıyor diye baktığımızda da task'a bakıp bu business bir iş.

Business işlerinin hepsinde QA'ya iş çıkıyor zaten.

Hani business iş deyip QA'ya iş yükü fazla.

çıkacak deyip daha çok teknik işlere yönelebiliyoruz sonrasında da.

İki puan yok. Anladım anladım.

İki puan da yani eğer farklı bir şey denemek isterseniz bir deneyin isterim ben.

Hani bir bakın nasıl oluyor.

Farklı bir ekipte acaba nasıl oluyor emin değilim.

Çünkü biz yapıyoruz ama farklı ekip yapıyor mu ben de bilmiyorum.

Hani onların böyle yorumları da şey olabilir.

Çok böyle yararlı olabilir.

Burada hani QA'dan bahsetmişken bizim tarafta da QA'lerde mesela puanlama yaparken işte load testler, Veya işte otomasyonla ilgili zaten bir madde yaparken otomasyon puanı veriliyor.

Ama işte hafta yük testi yapılması gerekebilir.

Onun için de ayrı puanlandırmalar falan yapılıyor development test tarafında.

Direkt hani sadece onlar puanlıyor gibi şeyler oluyor.

Bizde tabii load testte bazen şeyler oluyor.

Hani entegrasyon ekibi olduğumuz için işte lifecycle'ın başlangıcıyla sonu biraz karışık.

Çünkü bir ekipten bir şeyler geliyor, diğer ekipten bir şeyler olması gerekiyor, o bizzat bağımlılıkları oluyor vs.

derken uygulamaları ona göre ayarlamaya çalışıyoruz veya yük testini ya da o ekiplerle beraber çalışıyoruz ya da nasıl izole olur diye bakıyoruz.

Sizin tarafta böyle otomasyon ve lot test süreçlerinde bu tarz böyle challenge'lar oluyor mu?

Ya da süreçler nasıl ilerliyor?

Otomasyon sürecinde...

Büyük işlerde genellikle bir planlama yapılıyor ekipler arasında ve o büyük iş bittikten sonra end-to-end test yapıyor tüm ekiplerin QA'ları bir araya gelerek.

O şekilde ilerliyor. Lot testi de aynı şekilde iş büyükse yine ekipler bir araya gelip lot testi planlayabiliyor.

Ama genelde yaptığımız işlerde bağımsız bir şekilde ilerleyebiliyoruz.

Load test olsun, automation test olsun.

Automation test de zaten mocklarla ilerliyordu.

Şöyle bir örnek verebilirim belki hani diğer ekiplerle olan.

İşte entegrasyon kısmında nasıl ilerliyoruz diye.

Şu an mesela gündemimizde bir right load test var.

İşte uçtan uca aslında bir ürünün life cycle'ını test etmemiz gerekiyor.

Bunun için işte ilgili ekiplerin liderleri toplanıp bir roadmap...

Belirlemeye çalışıyor işte nerelere ne koymamız lazım.

Bazılarını mesela feature flag ile ya da bazılarını da işte datasal değişikliklerle yönetmemiz gerekebiliyor.

Ki daha sonrasında ilgili bu işte write load testte oluşturulmuş olan dataları kolaylıkla bulup bir de sistemden silmemiz gerekiyor.

Sistemi temiz bırakmamız gerekiyor çünkü.

O tarz aksiyonlarımız da oluyor.

Yani aslında bir plan program çerçevesinde ilerlememiz gerektiği durumlar olabiliyor.

Güzel özetlediniz. Teşekkür ederim ben de.

En çok merak ettiğimiz, konuşmaktan keyif aldığımız konulardan biri de incidentlar.

Genelde birçok konuda sormaya çalışıyoruz aynen.

Bingo. Yakın zamanda yaşadığınız, bizlerle paylaşmak istediğiniz bir incident var mı?

Var. Şöyle ki aslında bizim tarafta bir incident yaşanınca...

Kritiklik seviyesi de ön plana çıkıyor da.

Son kullanıcıyı böyle direkt etkilediğimiz bir incident aklıma geldi şu anda.

Geçtiğimiz sene işte bu inventory takımında gerekli rotasyonlar yapıldıktan sonra yeni bir ekip oluşmuştu.

Ve ekibin know-how'ı aslında başka başka ekiplere dağılmıştı.

İçerideki yapıyı da öğrenebilmek için aslında biraz kurcalamamız gerekti.

İşte biz içeride Outbox...

Bir yapısı kullanıyoruz işte core servisler direkt kendileri ilgili mutationları Kafka'ya göndermiyor da Kafka'nın bize sunduğu DCP ile birlikte onları ayrı bir Kafka Event Publisher

ile aslında Kafka'ya gönderiyoruz.

Ve bunu yaparken de core servis ilgili domain objesinin içerisine events diye bir array ekliyor.

İşte gelişen trend yolla birlikte trafik arttı.

İçerideki ürün sayıları artmaya başladı ve aslında bu datalar büyüdü.

Bizde işte Couchbase'de aslında resursumuz kısıtlı.

Sürekli artırmamız gerekiyor ama elbet bir dokunalım.

Buraları bir araştıralım bakalım.

Buradan resurs kazanabilir miyiz dedik.

Ve aklımıza şey geldi.

İlgili mutation'ı işlerken dedik ki ya biz bunu zaten işledik.

Outbox bucket'ına da yazdık.

Yedeğimiz oluştu aslında.

Event'ı artık Kafka'ya gönderebiliriz.

O yüzden domain'in üzerindeki event array'ini boşaltsak bir sıkıntı yaşamayız diye düşündük.

Fakat o iş öyle olmuyormuş.

O iş öyle olmuyormuş.

Biz bu işlemi yaptık.

Aslında bir günde böyle çalışmıştık.

Sonra birden gördük ki domainlerin state'leri bozuluyor.

Yani versiyon 1 oluşuyor ardından versiyon 2 oluştururken tekrar versiyon 1'e düşüyor.

İlgili domainler daha doğrusu dokümanlar.

Sonra bunu araştırmaya çalıştık işte database ekibine gittik ya dedik böyle böyle.

Problem var. Nasıl çözeceğiz?

Onlar bir araştırdı.

Sonra dediler ki durability level kaynaklı olabilir.

Çünkü biz yüksek throughput'lara çıktığımız için Couchbase bucket'ında durability level'ı none kullanıyoruz.

Dediler ki bunu bir tık arttıralım.

İşte biz dedi code tarafında yapalım hızlıca.

Onlar dedi yok yok işte code level'da olmasına gerek yok.

Biz hemen server side'da yapar.

Anında geri alabiliriz.

Hay hay dedik işte bir atıyorum ertesi gün sabah saat 9'a sözleştik.

Sabah saat 9'da ilgili database ekibi durability level'ı güncellediği anda bizim Couchbase cluster'ı çöktü.

Bir problem yaşadık orada.

Ve ne yapacağımızı bilemedik.

Hatta şimdi anlatırken de heyecanlandım.

Ellerim titriyor bir anda.

Aynen aynen şu an ellerim titriyor.

Sonra tabii hemen bir incident derken Zoom'da buluştuk ne yapacağız ne edeceğiz yok yani bir şekilde soru cevap vermiyor.

Sonra Couchbase tarafıyla iletişime geçildi.

Tabii biz bir yandan işte ne yapabiliriz diye ikiye bölündük.

Bir diğer ekip de aslında yan tarafta yeni bir Couchbase cluster'ı ayağa kaldırmaya çalışıyor ki oraya geçeceğiz hızlıca çözemezsek.

Sonra Couchbase'den geri dönüş aldık ve dediler ki sizin kullandığınız Couchbase versiyonda böyle bir bug var.

Bunu şu versiyona geçirip çözebiliriz.

Ya da bir patch yapacağız kısmı oldu.

İşte patch yapıldı. Karşı bez ayağa kalktı.

Derken daha sonrasında tüm tren yolu genelinde bir versiyon upgrade furyası oluştu işte.

Her ekip bakıyor 6.5'ti galiba versiyon ya da 6.5'ti.

Virüs versiyonu geçirmeye çalıştık.

Öyle bir incident yaşamıştık.

Tabii biz bu incident'ı yaşadığımız anda da otomatikman tüm fiyat değişiklikleri aslında sisteme yansıtılamaz duruma gelmişti.

Orada bir gecikme yaşadık diyebilirim hatırladığım o var şu anda yani.

Olaylar olaylar çok iyi hikayeymiş.

Çok sevdim yani. Teşekkür ederiz.

Bir tane de ben anlatabilirim.

Gönder yaz. Uygulamalarımızı normalde biz Argo CD ile deploy ediyorduk ama tren yoldaki devekteki bir tren yol büyüldü platform diye bir platform kurdu ve artık oradan server

etmemizi istediler uygulamaların deploymentını.

Tüm uygulamalarımızı biz başarılı bir şekilde geçirmiştik.

Stock ve price servisini en sona bıraktık.

Çünkü kritik servisler ve bir problem yaşandığı zaman kullanıcı ne sepete ürün ekleyebiliyor ne de satın alma yapabiliyor.

İşte onu da tam stock servisi yaptık oldu mu diye bir kontrol ederken Slack'ten chat check out'tan yazdılar.

Servisten cevap alamıyoruz diye.

Biz daha kontrol edelim.

Bir yana geldiler.

bir anda geliyorlar. Onlar bu konuda çok hızlılar.

Tebrik etmek lazım. Bu gibi durumlarda bir dakika içinde falan yazıyorlar genelde.

Onlar yazdıktan sonra podları geri aldık falan ama 2-3 dakikalığına tren yolunda sepete ürün eklenememişti.

O şekilde. Zaten servisin ismi zaten korkutucu değil mi?

Price Service ve Stock Service.

Daha ne kadar temel olabilir ki?

Çok iyi. Checkout'ta mesela hani sadece prod'da değil stage'de de bir şey olduğu zaman checkout hemen yazıyor yani.

Stage alarmları da kurgulanmış güzel bir şekilde onların tarafından.

Tebrik ediyorum onları. Aynen.

Buradan da checkout'a selamlar olsun diyelim.

Peki hemen adamların alerjikleri çok iyiyse bu ekipten bahsedelim.

Bu ekipte alerjikler işte monitörler vesaire bunlar nasıl işliyor ya da İşte şunlar için özel monitoringler yapıyoruz gibi bir altyapınız vesaire bir şeyler oluyor mu?

Çünkü entegrasyondan dolayı farklı yerlere bağımlılıklarınız var diye tahmin ediyorum.

Bizde de olduğu için oradan çıkarım yaptım.

Sizler de bunlar için yaptığınız bir şeyler var mı özellikle?

Evet, genellikle zaten trenli yolda promotüs metriklerine besleniyor tüm.

Promotüse besleniyor tüm metrikler.

Grafana da dashboardlar hazırlıyoruz.

kontrol edebiliyoruz genelde sistemi.

Bu Prometheus metrikleriyle beraber de işte alarmlar tanımlayabiliyoruz.

Trendyol'da bir katalog reposu üzerinden base olarak onu kullanarak tüm ekipler alarmlarını Prometheus queryleriyle tanımlayabiliyor.

Trendyol'da on-call sistemi de var.

On-call sistemi sayesinde de biz bu tanımlanmış alarmları Slack kanalına mesaj olarak bastırabiliyoruz ve seviyesine göre de on-call eğer eknolda çevrilmezse alarma bizi telefon ondan arayabiliyor bu şekilde.

Bizde bu mesela 15 dakika gibi bir şey iken belki check out'ta 1 dakikadır bilmiyorum.

Bir saniye. 15 dakika ikna oluş vermezsek gibi bir ayar yapmıştık.

Aramaya başlıyor bu sefer on call.

O şekilde mesela response time'larımız için özel bir ayar yaptık.

P99'da 25ms'in üstüne çıktığı zaman direkt bize on call uyarıyor.

hemen kontrollerimizi yapıyoruz.

Bu şekilde yani alarm monitoringimiz.

Belki ek olarak şunlar da söylenilebilir.

İşte Kubernetes tarafta da aslında bazı alertlerimiz bulunuyor.

İşte pod restart oldu ya da available düştü gibi.

Buna ek olarak işte aslında Bizim sorumluluğumuz da olmayıp ama sadece kontrol etmek amaçlı koyduğumuz alertler de var.

İşte Couchbase'deki herhangi bir data nodun memorisinde ya da CPU'sundaki yükselişleri de takip ediyoruz.

Olası bir problemde yani database'deki zaten farkında oluyor bunun.

Ama biz de ister istemez ya şöyle bir alert geldi buradaki son durum nedir diye dürttüğümüz oluyor.

Evet yani şey çünkü etkileniyorsun ya.

Psikolojik olarak bende de şey oluyor bazen.

Kübanese geri alertler koyuyoruz.

Belki koymamamız gerekiyor. Hani ekstra alert.

Ama koyuyorum yani çünkü sonuçta sen etkileniyorsun ve hemen senin haberin olsun istiyorsun böyle.

Evet evet. Şey oluyor aslında.

Bizim de bilgimiz var.

Bir sıkıntı yaşıyoruz burada.

Deyip aslında karşı tarafta da ekip de etkilendi bundan.

Algısını uyandırmamıza olanak sağlıyor aslında bu durum.

Ya bir de onu koymadığın zaman mesela uygulamadan hata geliyor.

Sen hatayı inceliyorsun neden geliyor falan ama onu koyduğunda burada bir problem var.

Hata bundan kaynaklanıyor. Bağlantı kuruyorsun.

Direkt bağlantıyı da kurabiliyorsun.

Evet evet çat çat arka arkaya geliyorlar çünkü.

Mesela bunu birkaç kere yaşadık.

İşte ilk servislerde sıkıntı oldu.

Ardından konsümörde ve ardından çat kaç vez tarafında mesela.

Şu data notta şöyle şöyle CPU artışı oldu diye bir hata geldiğinde o zaman nokta atışı mesela bu infra problemidir diyebiliyoruz.

Ve direkt OpenStack ekibinin kapısını çalıyoruz mesela.

Abi burada yine bir problem var hepsinde.

Aynen çünkü yoksa şey oluyor OpenStack'te onlara alet gidiyor diyelim.

Ona bakarken zaten çalışırken sen sana gelen problemi paralelde bilmeden bakıyorsun.

Senin de zamanın boşa gidiyor. Evet evet kesinlikle.

Aynen ya benzer senaryolar bizim ekiplerde de çok oluyor.

Alertler zaten şey ya yani üstüne ayrı bir bölüm yapsak bayağı uzun uzun konuşabileceğimiz.

Bir de hiçbir zaman böyle ilk kurduğun anda zaten mükemmel olmayan zamanla geliştirdiğin tecrübelerine dayanarak güzel bir yapı oluyor genelde.

Hani ekip ne kadar uzun süredir varsa alert mekanizması da o kadar oturmuş oluyor benim gördüğüm kadarıyla.

Bunu artı 99 demek istiyorum abi çok haklısın ya.

Eyvallah. Şimdi ekip olarak aslında böyle birazcık şey, Pim'de de önemli bir yeriniz var.

Akışta da içerideki Lifecycle'da da önemli bir yeriniz var.

Farklı ekiplerle de çalışıyorsunuz.

Buradaki iletişim ve ortak çalışma kısmını nasıl yürütüyorsunuz?

Birazcık onlardan bahsedelim.

Burada şu pratiği uyguluyoruz mesela.

Bunu belki de Trendyol'daki diğer ekipler de uyguluyordur.

Bizim iletişimde olduğumuz her ekiple aslında işte inventory, listing.

Collab keyword'ünü kullandığımız collaboration kanallarımız var.

Atıyorum sadece listing ekibini ya da sadece işte örnek veriyorum productivity ekibiyle inventory arasındaki bir feature geliştirmesi ya da herhangi bir olay durumunda handshake yapılması

gerekiyorsa ilk olarak bu Slack kanalı üzerinden iletişime geçiyoruz.

Bazı durumlarda işte Zoom'da toplantılarımız oluyor.

Ne yapabiliriz, ne edebiliriz diye.

Arka tarafta sürekli takım liderleri kendi içerisinde yakın olduğu takımlarla birebir yapıp biz işte bazı noktalarda mimaride düşünmemiz gerekiyor.

İşte şu anki yapı böyle ama.

Biz burayı nasıl daha ileriye getirebiliriz ya da önümüzdeki engeller neler diye aslında sürekli iletişim halinde ekipler.

Gerek developerlar gerekse team leadler kendi içerisinde iletişim halinde.

Bu örnekleri verebilirim.

Belki bir soruyla alakalı. Çok güzel, çok güzel.

Aslında şu anda böyle teknikten biraz da böyle soft kısımlara geçmiş olduk.

Hani ekiplerle alakalı, iletişimlerle alakalı vs.

ya da soft skill'ler üzerine. Bunun dışında Aytun sen sanırım 5 yıldır buradaydın.

Hamza da 2 yıldır. Bunun dışında işte rotasyon yapıyorsunuz.

Sizin ekibe rotasyona gelen oluyor mu?

Ya da olduysa o gelen kişiler nasıl adapte oluyor ya da adapte olmakta herhangi bir zorluk yaşadıkları ortak bir nokta var mı sizin gördüğünüz?

Bizim ekibe rotasyon Komple rotasyon diyebiliriz sadece.

Ekibin kendisi rotasyon.

Evet. Şu an sadece bir tane dışarıdan bir alım yapılmış ekibi.

Diğer herkes rotasyon.

Pek bir sıkıntısını görmedik rotasyonla uyum sağlamanın.

Hatta rotasyondan gelen arkadaşlar sayesinde diğer ekiplerle iletişimimiz daha güçlü oluyor.

Bir dizayn çıkaracağımız zaman diğer ekiplerdeki bilgi birikimi de olduğu için dizaynı daha rahat da çıkarabiliyoruz.

Aytunç senin eklemek istediğin bir şey var mı buraya?

Aynen yani şöyle zaten kısaca bahsetmiştim ilk girişte.

Pim ekibindeydik işte 10-15 kişilik bir ekipti.

İşe alımlar yapıldıkça ekipler küçüldü ve içerideki eski olan arkadaşlarımız aslında sürekli bir rotasyonla diğer ekiplere geçti.

Ben ilk olarak işte Product Center tarafına oradan...

Kampanyanın tarafına şu anki adı Productivity olan ekibe.

Ardından onun adı değişti işte listing oldu.

Listing domenini de kattık kampanyanın yanına.

Derken en sonunda inventory'e rotate ettim.

Bu rotasyonun şöyle de bir artışı oluyor.

Belki o noktaya da değinmek gerekebilir.

İşte aslında sürekli gördüğünüz yapılar birbirinden farklı olduğu için kuş bakışı Trendyol platformunun görüntüsünü de daha net çizebiliyorsunuz.

İşte Product Center'da çalışan bir arkadaşı alıp listing, oradan da inventory, inventory'den indexing'e koyduğunuz noktada ürün ilk sisteme girip en son noktada search edilene kadar, PDP

ekranı oluşana kadar tüm sürece hakim olmuş oluyor.

Günün sonunda karar verilirken de ilgili arkadaş daha böyle nokta atışı cümleler kurarak diyeyim, böyle direkt kararlara entegre olabiliyor.

karar merciği olarak.

Bence öyle artıları var.

Yapıyı daha hızlı geliştirip daha stabil bir noktaya getirebiliyoruz.

Bir de benim değinmek istediğim bir diğer konuda şey.

Yani ekipten, işlerden, insanlardan bahsettik.

Sprintlerden bahsettik.

Bu sprint içerisinde tamamen işe mi odaklanıyorsunuz yoksa iş dışında kendinizi geliştirmek için ayırdığınız zamanlar, işte time slotlar var mı?

Sprint dışında bizim special interest time dediğimiz Her hafta pazartesi günleri, deli sonrasında başlattığımız ve sit adını verdiğimiz bir zaman aralığı

oluyor. Bu zaman aralığında ekip içerisindeki arkadaşlarımız kişisel gelişimlerine ya da merak ettiği konulara odaklanarak aslında bir çıktı üretmeyi amaçlıyor.

Bir ürün de olabilir ya da bir know-how da olabilir.

Gelip bunu aslında ekibe meet-up ile anlatıp ekibin de o alanda ya da yeni olan bir konuda kendini geliştirmesini olanak sağlıyor.

Buna ek olarak... Tribe altında yaptığımız Design Kata ismini verdiğimiz bir yapımız daha var.

Bu site göre 2-3 ayda bir yapılan ve süresi daha uzun olan bazen 2 günü bulabilen bir yapı.

Burada ne yapıyoruz aslında?

Hala hazırda herkesin kullandığı işte Trendyol gibi ya da online müzayede sistemleri gibi ya da ne bileyim işte DigitalOcean'ın ilç yapısı gibi sistemleri tasarlayıp işte atıyorum.

Tribe'da 50 kişi var.

Bu 50 kişiyi 4 erli ya da 5 erli gruplar halinde bölüp her ekip kendi dizaynını tasarlıyor.

İşte kimisi Couchbase kullanıyor, kimisi Relational Database kullanıyor, kimisi işte MongoDB ya da Go ya da Kotlin bazıları mikro servis kullanıyor, bazıları monitik yapı yapıyor gibi gibi.

Günün sonunda da bir günün sonunda ya da ertesi gün bir soru cevap sesini yapıp aslında ilgili projeyi...

ilgili ekiplerin sunmasını istiyoruz.

İşte o tasarımı siz nasıl yaptınız diye.

Bu soru cevapta da ekipler aslında birbirini geliştiren sorular soruyor.

Burada neden mesela load balansır kullanmadınız?

Ya da neden couch base'i tercih ettiniz?

De-relational database'i tercih etmediniz?

Gibi gibi sorularla aslında hala hazırda kullandığımız sistemlerin olası mimarilerini çıkarmaya çalışıyoruz diyebilirim.

Abi yaptığınız şeyler güzel ama ben isimlerini daha çok sevdim.

İkisi de çok havalıymış.

Birisi Special Interest Time, diğerisi Design Kata.

Evet evet. Çok havalı isimler yani.

Bunların isim babaları Kutlu ve Emre olabilir.

Onlar yönetiyor şu an yapıları.

Bence de çok faydası oluyor.

Ben ilk girdiğimde baya şaşırmıştım.

İlk girdiğim Design Kata şeydi online müzayede.

İşte bir de şey de oluyor mesela.

Detaylar oluyor bir tane. Excel diyorum.

Bu sheet oluyor. Evet.

Orada diyor ki anlık 1 milyon trafik olacak.

İşte aynı anda 50 bin kişi aynı PDP ekranını işte aynı prodakta verebilecek.

Teklif verebilecek.

Ama bir kişi kazanacak.

Ne bileyim kredi kartından provizyon çekilecek.

Sonrası EFT ile olacak.

Bula bula yani. O payment aşamalarını düşünmen gerekiyor senin.

Baya şey yani sadece üstün kök bir design sistem gibi değil.

Daha detaylı gibi. Yok ya bir tık detaylı ama mesela şey demiyorsun işte ne bileyim burada web soket kullanırım ama web soketin şu şu şu inceliklerini yaparım.

O kadar da değil aynen anladım. Sadece daha böyle dizayn zaten adı üstünde.

Teknoloji kullanmak. Çok iyi ya çok beğendim.

Peki burada ekip çağırsa bir adı yaptınız buna böyle uzun yani special interest sayım daha kısa süreli ama düzenli bir etkinlik gibi.

Dizayn kata daha...

Sık olmayan bir aralıkta ama uzun süreli bir toplantı gibi anladım.

Fakat hepimiz hani remote çalışıyoruz ya burada.

Bir araya gelip de yaptığınız fiziksel bir etkinlik vesaire ya da bir araya gelip işte kafa dağıtmak için yaptığınız, sosyal yaşamak için yaptığınız şeyler var mı?

İşte bunun için gurme ekipler var.

Belirli böyle yemek yerleri olan gidip yemekler yiyebiliyorlar bir araya gelip.

Onun dışında direkt oyunlar oynayan ekipler var.

Her ekip böyle kendine göre...

tarzı var. Sizde var mı tarz bir şey?

Bizde de var. Aslında onların yaptıklarının karışımı gibi diyebiliriz.

Like talk'lar yapıyoruz.

Like talk'larda teknik konulara girmeden normal muhabbet ediyoruz.

Örneğin bir arkadaşımız bir tur yaptı.

Bizi o turdan bahsedebiliyor.

Onun dışında bu like talk her hafta belli bir saatte olan toplantı.

Like talk gibi her hafta belli saatte olan bir de fun time diye bir vaktimiz var.

O Funtime'da da işte Codename, Sexball gibi oyunlar oynuyoruz.

Bazı Funtime'ları dışarıda ayarlıyoruz ve Bowling Lazer Tech gibi oyunlar oynuyoruz.

Yemekse olmazsa olmaz zaten.

Bence her ekip yapıyordur.

Dışarıda da yemek etkinlikleri yapıyoruz.

Belki fanları. Aynen aynen abi.

Funtime'da şöyle oluyor.

Cuma günü son bir saat.

Yani artık haftayı bitirmişiz üzerine bir Oyun çakıyoruz arkadaşlarla.

Aynen. Kafayı temizleyip öyle ayrılıyorsunuz değil mi?

Evet evet. Ya burada işte belli başlı oyunlar var aslında az çok herkesin oynadığı.

Onların üzerinden devam ediyoruz.

Çok iyi süper. Evet 51.

bölümde inventör ekibiyle birlikte olduk.

Teşekkür ederiz. Bir sonraki bölümde görüşmek üzere.

Teşekkürler. Görüşürüz. Bye bye.

Görüşmek üzere. Görüşmek üzere.