Selam Ekip - E61 - Buyer Product Indexing & Seller Product Indexing

Selam ekip, ben Productivity ekibinden Erdem.

Teknoloji ekiplerini tanıdığımız ve süreçler, teknolojiler gibi konuları konuştuğumuz Selam Ekip Podcast serisinin 61.

bölümünde Buyer Product Indexing ve Seller Product Indexing ekipleriyle birlikteyiz.

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

Hoş geldiniz arkadaşlar. Hoş bulduk, selamlar.

Hoş bulduk. Evet, kendinizi kısaca tanıtabilir misiniz bizlere?

Tabii, merhabalar tekrardan.

Ben Seray. Yaklaşık 2,5 yıldır Trendyol'dayım.

Daha öncesinde de Fullstack Developer olarak 3,5 yıl kadar banka sektöründe çalışmıştım.

Şu anda Buyer Product Indexing ekibinde Backend Developer olarak çalışıyorum.

Selamlar ekip. Ben de Kerem.

Yaklaşık olarak 2,5 yıldır Trendyol'dayım.

Backend Developer rolünde çalışıyorum.

Selamlar. Ben de Mert.

Yaklaşık ben de 7 yıldır Trendyol'dayım.

Daha önce Search ekibinde başladım.

Sonrasında Browsing altında ekiplerde çalıştım.

maceram oldu diyebilirim.

Şimdi de Bayır Product Indexing ve Seller Product Indexing ekipleriyle birlikte çalışıyorum diye özetleyebilirim.

Süper, hoş geldiniz tekrardan.

Şimdi ilk olarak bu iki ekibin trend yoldaki sorumluluğu nedir?

Aslında bununla başlayabiliriz.

Ben başlayayım isterseniz.

Bayır Product Indexing ve Seller Product Indexing temelde aslında arkitektür olarak birbirine yakın ekipler ama Sorumluluk anlamında, business domain anlamında farklı sorumluluklara sahipler.

İsminden de anlaşılacağı üzere aslında Bayer Indexing ekibi Bayer'a data sağlayan ekip, Seder Indexing ekibi ise Seder'a data sağlayan ekip gibi kısaca özetleyebiliriz.

Bu ekipler neler yapıyor derseniz de aslında satılabilir ürün datasını çeşitli ekiplerden eventler dinleyerek up-to-date bir halde son kullanıcıya sağlamaya çalışıyor diye özetleyebilirim.

Bunu sağlarken de hangi ekipler bizden faydalanıyor gibi söylersek de aslında aklınıza gelebilecek ön yüzde ürün datasını gösteren bütün ekiplerle iletişim halindeyiz gibi söyleyebilirim.

Onlara ürün datasını biz sağlıyoruz.

Bu şekilde özetleyebilirim.

Bu ekipler neler derseniz de işte Product Detail ekibi, PDP ekibi, Search ekibi, Recommendation, Favori, Just For gibi featureler.

Bu tarz ekiplere aslında data sağlıyoruz.

Bununla birlikte DVH, Data Engineering gibi data platform ekipleri bizden data alıyor.

Gibi kısaca özetleyebilirim Bayer tarafını.

Seller tarafında ise ağırlıklı hizmet ettiğimiz yer Seller Center tarafı.

SPM diye tabir ettiğimiz ekip aslında.

Burada da aslında Seller'ın görmek istediği ürün datası, yayını açıp kapatmak istediği ürün dataları vesaire gibi feature'lara destek sağlıyoruz diye özetleyebilirim.

Eksik kaldığım yerler varsa siz tamamlayın arkadaşlar.

Size bırakayım. Aslında Buy Product Indexing ekibinde belki Buy Box'dan da bahsedebiliriz.

Domenimiz içerisinde Buy Box'ın hesaplanmasını da biz yapıyoruz.

Bu Buy Box nedir?

Bir ondan bahsedeyim kısaca. Aynı ürünü birden fazla satıcı satabiliyor.

Fakat trende ulaştığımızda bir satıcının ürünü daha öncelikli olarak görünüyor.

İşte buradaki bu sıralamayı yapmamızı sağlayan puana da Buy Box puanı diyoruz.

Satılabilir ürün datasının son halini de biz oluşturduğumuz için.

Mert'in dediği gibi buyer product indexing ekibi oluşturduğu için.

Bu son bilgiyi kullanarak da buybox puanının hesaplanmasını da biz yapmış oluyoruz.

Süper. Peki şimdi birazcık da ekipteki rol dağılımından bahsedebilir miyiz?

Ekiplerdeki developer, QA, PM yapısını da merak ediyorum.

Onlardan bahsedebilir miyiz biraz? Tabii ben BPI'den bahsedeyim.

BPI ekibi 5 tane backend developer ve bir de developer in test'ten oluşuyor.

Yani toplamda 6 kişiyiz.

Bir de development ekibimizin dışında...

PM'imiz var. SBA için de Mert'e verebilirim sözü.

SBA için de benzer bir kadro var aslında.

Beş bekent developer, bir devin test arkadaşımız var, bir de product manager arkadaşımızla çalışıyoruz gibi.

Kısaca özetleyebilirim ben de.

Ben de Mert'e ek olarak şunu ekleyebilirim.

Beş bekent developer'ından birisi en son talent programına aramıza katılan bir arkadaşımız.

Trendyol bildiğiniz gibi bir talent program yürütüyor.

O talent program içerisinde henüz daha mezun olmamış veya mezun olmaya yakın yeni mezun olmuş arkadaşlarımız içinden bazı elemeler yapıp o arkadaşlara ekipte yer veriyoruz.

SP ekibinde de bir tane talent programdan arkadaşımız var.

Süper. Şimdi zaten birazcık da şey oralara değindiğimiz noktalara da geleceğiz.

Benim şimdi konuşmak istediğim bir diğer konu da anladım.

Kader'le böyle bayağı çok sayıda ekiple bir arada çalışıyorsunuz.

Oradaki iletişimi nasıl sağlıyorsunuz?

Yani bu aslında çok da kolay bir şey değil.

Birazcık da o kısımdan bahsedebiliriz.

Bu kısımdaki çalışmalarımızı iletişim platformu aslında Silek üstünden sağlıyoruz.

Genelde yakın çalıştığımız ekiplerin hepsiyle bir collaboration kanalımız oluyor.

Hızlı bir şekilde iletişime geçebileceğimiz.

Bu kanalları düzenli olarak takip ediyoruz.

İşleri yürütmek için. Onun dışında ekiplerin kendi public kanalları var.

Yani çok sık çalışmadığımız ekiplerin aslında public kanalları aracılığıyla iletişime geçtiğimiz durumlar oluyor.

Bunlar Slack içerisindeki genelde iletişim yöntemlerimiz.

Bunlar dışında ekiplerin PO'larının katıldığı toplantılar oluyor.

PO seviyesinde işte business işlerinin tartışıldığı, hangi ekibe ne iş çıkıyor gibi aslında işlerin ekiplere getirilip grum edildiği bir iletişim şeklimiz de var.

PO'lar üstünden akan. Bunlar dışında bu collaboration'dan konuşulan veya piyoların getirdiği konuların aslında teknik seviyede nasıl yapılacağıyla ilgili sürekli RFC'ler yazıyoruz.

Bunlar bizim teknik dokümanlarımız.

Bir konu üstünde hangi ekip konuya nasıl dahil olacak, hangi ekipten nasıl bir data gelecek, nasıl bir data başka ekiplere verilecek gibi tüm sürecin aslında tek bir doküman üstünden görülebildiği RFC'lerle

bu konuyu yürütüyoruz.

Anladım. Süper. Bizim ekipte de benzer yaklaşımlar var.

Collaboration kanalları zaten birazcık da şey gibi trend yolu içerisinde yaygın bir şekilde aslında kullanılan ve bence de çok faydalı olan bir yöntem gibi.

Şimdi yakın zamanda ekibe bir arkadaşın da katıldığından bahsettiniz aslında.

Burada genelde katılan ekiplere bu soruyu da soruyoruz.

Onboarding süreçleriniz nasıl?

Yeni ekibe dahil olan biriyle nasıl bir iletişim kuruyorsunuz?

Nasıl süreçlerden geçiyor bu arkadaş ekibe dahil olduktan sonra?

Onlardan bahsedebiliriz birazdan.

Ekibe yeni bir arkadaşımız katıldığında aslında mutlaka bir body'siyle ekibe adapte olmaya başlıyor.

Onu söyleyebilirim. Başta bir body atanarak ekibe dahil oluyor.

Aslında hızlı bir şekilde planlama ve grumi itilere dahil edip biraz o ortamı, havayı koklamasını da sağlıyoruz.

Yine bu body'siyle birlikte bir onboarding plan da çalışıyoruz gibi söyleyebilirim.

İşte burada daha önce hazırladığımız dokümentasyonları, bootcamp videolarını, oluşturduğumuz bootcamp videolarını, RFC'leri vs.

bu arkadaşla paylaşıp aslında ekibe hızlı bir şekilde domainini anlamaya çalıştırıyoruz gibi söyleyebilirim.

Bununla birlikte aslında ekipteki herkesle birer böyle session da düzenleyip herkesin kendi açısından güçlü olduğu know-how'ları arkadaşımıza aktarmasını da sağlıyoruz bir yandan.

Bununla birlikte tabii IK onboarding süreçleri de var.

Bunları da yine ekip arkadaşımıza yönlendiriyoruz.

Hani kısaca böyle açıklayabilirim.

Genel olarak böyle gidiyor ve ağırlıklı payer çalıştığımız için de arkadaşımızın adaptasyonu biraz daha hızlanıyor gibi söyleyebilirim.

Ek olarak yaptığımız bir pratik de şu.

Şu anda tabii remote çalıştığımız için ağırlıklı olarak Zoom üzerinden çalışıyoruz ve Zoom'da da breakout room'larda çalışıyoruz aslında.

Bu breakout room'lar her gün belli bir sayıda açılıyor ve bütün gün aslında bu breakout room'larda duruyoruz gibi söyleyebilirim.

Yani pair yapanlar aynı odada kalıyor, pair yapmayanlar tek başına bir odada kalıyor.

Bu bize şu avantajı sağlıyor aslında.

Gün içinde hızlı bir şekilde istediğimiz arkadaşa ulaşabiliyoruz ve o iletişim ve adaptasyon körbü oldukça azalıyor gibi söyleyebilirim ben de.

Gayet güzel. Bu zaten şey bahsettiğim breakout room yaklaşımını uygulayan farklı ekipler de duymuştuk daha önce.

Bizim ekipte de aynı şekilde ilerliyoruz.

Gerçekten şey havası yaratıyor böyle bir sanal ofis havası yaratıyor.

Birine bir soru soracağın zaman hemen tık yan odaya geçsin soruyu sorup sonra kendi odaya geçip bireysel takılmaya devam edebiliyorsun.

Yani özellikle remote çalışan ekiplerde bence güzel bir pratik.

Ona da değinmemiz güzel oldu.

Kesinlikle. Çok etkinliğindeydik ve ek olarak sana şunu da ekleyebilirim belki.

Yani bir incident olduğunda ya da bir case'e bakıldığında da bir araya geliyor ekip ve bunu da çok hızlı bir şekilde yapmayı sağlıyor bize bu aslında blackout durumlar.

Ek olarak yeni katılan arkadaşımız da tabii neye nasıl baktığımızı, nasıl case review ettiğimizi vs.

bunları görmüş oluyor bir yandan hızlı bir şekilde.

Ofis ortamında bilgisayarı yanına alıp işte...

Klavyeyi yanına alıp böyle gittiğin arkadaşınla konuştuğun sohbet edin ya bu nasıl oluyor falan dediğin süreçleri biraz böyle sanal ortamda yaratmaya çalışıyoruz aslında kısaca.

Aynen aynen. Peki biraz da ekiplerin tek siteyinden bahsedebiliriz bence.

Tahmin ediyorum ki iki ekip çok benzer yapıda olduğu için aynı tek siteyi paylaşıyordur.

Ama kullandığınız teknolojilerden birazcık bahsedebilirsek güzel olur.

Dediğim gibi aslında ortak tekste kullanıyoruz yakın çalıştığımız için.

Ağırlıklı olarak Go dilinde aslında kodlama yapıyoruz.

Bazı eski uygulamalarımız vardı.

Bunlar işte Java, Scala, Kotlin gibi uygulamaları da aslında kısa süre içerisinde Go'ya taşımış olduk.

Daha çok performans aldığımız için.

Veri saklama olarak aslında Couchbase ana veri tabanımız olarak söyleyebilirim.

Key value veri tabanı tercih ediyoruz burada.

Queryable data'yı tuttuğumuz yerde Elasticsearch.

Elasticsearch'ü de o amaç için kullanıyoruz.

Couchbase ve Elastic arasında data'yı aslında sync ettiğimiz tren yol bünyesi altında geliştirilen bir open source projemiz var.

Couchbase Elastic Connector diye.

Bunu da dinleyen arkadaşlar GitHub üstünden bakabilirler.

projeye katkı sağlayabilirler.

Genel olarak tek isteklerimiz bunlar.

Seray'ın eklemek istediği bir şeyler varsa o da girebilir.

Yok aslında birebir aynı.

Ben belki ek olarak şeyi söyleyebilirim.

Bunlar haricinde tabii Kafka'da kullanıyoruz.

Belki onu da ek olarak söyleyebiliriz.

Çok yoğun Kafka kullanan ve hemen hemen bütün böyle ayrıntılarını bilmeye bizi zorlayan bir domaindeyiz gibi söyleyebilirim.

Arkitektür anlamında da buna çok yani Drivan'a çok Yakın bir yer olduğumuz için bunu bayağı buraya gelen arkadaşlar hissediyorlar gibi söyleyebilirim bu ekiplerde çalışanlar.

Onu da ek olarak eklemiş olayım.

Kafka zaten tren yolda göz bebeğimiz diyebiliriz bence.

Kafkasız nasıl bir dünyamız olurdu çok hayal edemedim ben de.

Peki şimdi böyle biliyorsunuz.

En önemli aslında takip ettiğimiz konulardan biri de 4K metrikler.

Sizin tarafta burada nasıl bir yaklaşım var?

Yakından takip ediyor musunuz?

İyileştirme yapmak için neler yapıyorsunuz?

4K metrikleri aslında uzun bir süredir haftalık olarak takip ediyoruz.

Önce onu söyleyeyim. İki ekipte de haftalık olarak takip ediliyor.

Öncesinde aylık olarak takip ediyorduk ama aylık olarak takip ettiğimizde şöyle dezavantajları vardı bizim açımızdan.

Örnek veriyorum işte bir deployment yapılmış ve incident'a yol açmış.

O da meantime to restore'u arttırmış vs.

Ya bu niye olmuş falan diye baktığımızda böyle birazcık açıkçası hatırlamakta zorluk çektiğimiz durumlar oluyordu.

Ve üzerinden çok zaman geçtiği için biraz hani olayın kök nedenini, root sorunu, nasıl çözdüğümüzü vs.

konuşmak biraz zorluyordu bizi.

Ya da bununla ilgili aksiyon planı çıkartmak daha zor oluyordu açıkçası.

Yeni yapıda yani haftalık baktığımız senaryodaysa biraz daha hızlı aksiyon alabiliyoruz.

Hemen aksiyonun sonucunu bir sonraki hafta görmeye çalışıyoruz.

çalışıyoruz vs. gibi söyleyebilirim aslında.

Haftalık olarak deployment frequency, meantime to restore, cycle time ve change failure rate takip ediliyor.

Bunlara da yine OKR'larımızda ve KPI'larımızda hedef olarak kendimize giriyoruz ve şu an hedeflerimize aslında iki ekipte de yaklaştık diye söyleyebilirim.

Hemen hemen hedefi tutturarak gidiyoruz.

Ay bazılığına baktığımızda.

Bir tek seller product indexing ekibinde cycle time ile ilgili sorunumuz vardı.

O da birazcık o ekipte bir süre kanman çalıştığımız için cycle time'larımız biraz yükselmişti.

Şimdi de sprint'e geri döndük orada da.

O yüzden hani tekrardan normal bir seviyeye geldik.

Burada özellikle hani en çok takip ettiğimiz metric cycle time.

Cycle time'ın içinde de tabii aksiyon olarak çıkartmak için açıkçası yani daha iyi nasıl yaparız diye düşündüğümüzde Buradaki alt maddelere, alt başlıklara bakıyoruz daha çok.

Nerelerde ne kadar vakit harcamışız?

Merge gestim review etme süremiz nedir?

Pick up time'ımız nedir? Bunlara bakıyoruz ve bunlara yönelik aslında somut aksiyonlar almaya çalışıyoruz.

Bunları böyle görünür hale de geldi en son Pandora kullanımımızla birlikte.

Artık orada biraz daha rahat bir şekilde hangi Merge Quest'e ne kadar comment girilmiş, hangi Merge Quest ne kadar sürede ilerlemiş, hangi issue ne kadar sürede ilerlemiş, nerede takılmış, kaç sprint sürmüş gibi şeyleri

detaylı arkadaşlarla çalışarak burada bir planlama eksikliği mi yapmışız, bir analiz eksikliği mi var, işi doğru anlayamamış mıyız gibi aslında neyi daha iyi yapabiliriz ya da test süreçlerinde iyileştirmemiz gereken noktalar

var mı? Development süreçlerinde iyileştirmemiz gereken noktalar var mı?

Gibi üzerine aslında istişare ederek aksiyon, somut aksiyonlar çıkartmaya çalıştığımız bir dönem geçiriyoruz gibi söyleyebilirim.

Genel olarak ortalamanın altında, ortalamanın yani şey anlamında, cycle time anlamında ortalamanın altında kalıyoruz genelde teknoloji ortalamasının gibi söyleyebilirim.

Buradaki şeylerimiz, folkimetriklerimiz fena değil yani onu söyleyebilirim.

Anladım, süper. Cycle time konusu açılınca direkt ben şeyi merak ediyorum.

Sprint süreniz ne kadar?

Bir hafta mı iki hafta mı? Onu söylemeyi unuttuk aslında.

İyi hatırlattın. Ya haftalık sprint koşuyoruz iki ekipte de.

Onu söyleyebilirim. Daha önce iki haftalık sprint koştuğumuz ekiplerde de çalışmıştım.

Haftalık sprint koşmak açıkçası böyle biznesi daha mutlu eden bir yaklaşım diye düşünüyorum.

Daha yani şimdi trend yolu ortamı daha ecel bir ortam.

Zaman zaman scope creep işleri almamız gereken durumlar ortaya çıkabiliyor.

Burada böyle hızlı aksiyon almak, daha hızlı test süreçleri entegre etmek, daha hızlı development yapma, daha kaliteli işler üretme anlamında ben haftalık sprint'i daha iyi görüyorum açıkçası.

Daha küçük parçalar alarak hızlı paketler deliver etme noktasında biraz daha bizi hem challenge ediyor hem de daha iyi bir noktaya götürüyor gibi görüyorum ben.

O yüzden haftalık ilerliyoruz iki ekipte de şu anda.

Geçmişte konuk aldığımız ekiplerden haftalık ya da iki haftalık yapanlar vardı.

Ben böyle hala şey taraftayım ya.

İki tarafın da artıları eksileri çok var gerçekten.

Biz şu anda iki hafta yapıyoruz.

Bir haftaya döner mi dönmez mi onu çok bilmiyorum ama genelde şeyi de duydum ama.

İki haftalık yaparken bir haftalık denedik ve memnunuz böyle gidiyoruzu duydum.

Hep bir şey kaygısı da oluyor tabii.

Daha fazla toplantı mı yapacağız?

İşleri nasıl böleceğiz?

Bölemediğimiz, çıkaramadığımız işler olursa nasıl ilerleyeceğiz gibi.

Ama denemeden de çok sanırım anlaşılmayacak bir konu gibi.

Her ekibin çünkü dinamikleri de farklı.

Her ekipte bir haftalık sprint çok mantıklı olmayabilir.

Ama faydasını gördüyseniz süper.

Onu merak etmiştim. Onu da bir detaylı sormak istedim.

Peki şimdi sprint demişken sprintlerdeki işleyişiniz nasıl?

şeyi de konuşabiliriz belki.

Mert'in, Seray'ın, Kerem'in bir günü nasıl geçiyor?

Tabii ben şöyle kısaca bahsetmeye çalışabilirim kendi günümü özelinde en azından.

Daha önce de aslında konuştuk bir önceki soruda.

Sprintlerimizi haftalık koşuyoruz.

Haftalık bir düzenimiz var.

Burada biz BPI'da, Value Product Indexing'de salı günleri öğleden sonraları yeni bir sprint'e başlıyoruz.

Bunu planlama toplantısıyla başlatıyoruz.

Ardından da Genelde bunu iki haftalık düzende yapıyoruz.

Retro toplantılarımız var.

Geliştirme tarafına bakarsak aslında büyük ve karmaşık işleri genellikle peer olarak yapmaya çalışıyoruz.

Böylece hem üzerimizdeki yükü dağıtmış oluyoruz hem de aslında farklı görüşleri de o iş içerisinde almış olabiliyoruz.

Daha küçük ve basit işler içinse...

tek kişi olacak şekilde aslında geliştirme yapabiliyoruz.

Özellikle birden fazla ekibi ilgilendiren ya da kendi ekibimize özel bir iş bile olsa karmaşıklığı yüksek kişiler için de mutlaka bir analiz işi alıyoruz.

Gerekli olduğu durumlarda işi Sprint'e getirmeden önce ya da analiz sırasında konuları netleştirebilmek için business toplantıları yapmaya çalışıyoruz.

Geliştirme tamamlandıktan sonra eğer Codebase'imiz çok büyükse, Codebase'de çok büyük bir değişiklik olduysa o zaman da Code Review Session'ları düzenliyoruz.

Böylece ekipçe yapılan değişikliklerin üzerinden geçiyoruz.

Code review'un da daha hızlı bir sürede tamamlanmasını sağlıyoruz.

Sprint içerisinde backlog'un yoğunluğuna da bağlı olarak bir ya da iki grooming toplantısı yapıyoruz.

Ve burada bu toplantılarda tasklarımızı puanlıyoruz.

Böylece planlama sırasında puanlanmış taskları...

alarak planlamanın da daha hızlı ilerlemesini sağlıyoruz.

Bunu Mert söylemişti sanırım.

Incident'ımız olduğu zaman alabileceğimiz aksiyonları ve çıkaracağımız dersleri de konuşmak için incident toplantıları yapıyoruz.

Bunu daha önceden daha geniş aralıklarda işte aylık düzende yapıyorduk.

Fakat burada üzerinden vakit geçtiği zaman konuları unutabiliyoruz, ne yaşandığını unutabiliyoruz.

Etkileri aslında unutulabiliyor.

Bu yüzden de bu incident'lar yaşandıktan sonra kısa bir süre içerisinde bu toplantıları yaparak Üzerinden geçmiş oluyoruz konuların.

SERE'ye ek olarak aslında aylık bazda baktığımızda KPI ve OKR toplantılarımız oluyor.

Burada kişisel olarak aslında gelişimimizi takip ettiğimiz ve ekibin gelişim yönlerini aslında takip ettiğimiz toplantılar yapıyoruz.

Bunda aksiyon maddeleri çıkartmaya çalışıyoruz.

Bunun yanı sıra tren yol genelinde ekiplerin katkı sağladığı guild toplantılarımız oluyor.

Bunu herhangi bir konuyla ilgili düşünebilirsiniz.

Elastik GUID'lerimiz, sistem algoritm GUID, GO ile ilgili GUID'ler gibi pek çok konuda aslında o konuyla ilgilenen kişilerin bir araya gelip çeşitli konular anlattığı, bazı konular tartıştığı ve Trendyol

içerisindeki know-how'ı birbirimize aktardığımız çeşitli toplantılarımız da oluyor.

Kerem'e ek olarak da şunları söyleyebilirim belki.

Biz de ek olarak hem SPA hem BPA ekiplerinde aylık gitmiş toplantıları yapıyoruz product manager'larla.

Bu da bize şeyi sağlıyor aslında, o aylık olarak roadmap'i görmemiz, bu ay neler planlıyor, business bizden neler bekliyor, biz teknik olarak neler, hangi işleri yapmamız gerekiyor, bunların üzerinden geçiyoruz.

Daha sonra bir aligned oluyoruz ekiple beraber gibi söyleyebilirim.

Bu da bizim için önemli bir toplantı oluyor.

Bunun haricinde yine diğer ekiplerle brainstorming session'larımız oluyor.

Teknik analizlerin üzerinden geçiyoruz, RFC'lerin üzerinden geçiyoruz.

Burada da hem fikir alışverişi yaptığımız, hem de gelen business feature'ın uygun domayinde, uygun kontekste, yapılmasını sağlamaya çalıştığımız toplantılar oluyor.

Bunların da yine çıktılarını paylaşıyoruz.

Buna yine ekipten developer arkadaşlarımızla dahil ettiğimiz durumlar oluyor.

Bu şekilde böyle aslında align olup ilerlediğimiz süreçler oluyor gibi söyleyebilirim.

Gayet güzel toparladınız.

Teşekkür ediyorum tekrar. Böyle birazcık ben hani bir gününüz nasıl geçiyor diye sormuştum ama bayağı toplam detaylı aylık noktaya kadar geldik.

Güzel oldu. Şimdi birazcık daha böyle şey Derin konulara girmek istiyorum aslında.

Biliyorsunuz incidentlar illaki yaşanıyor.

Burada öncelikle ben şeyi merak ediyorum.

Sizin ekipte tren yolu tarafında yaygın kullanılan pratikler var ama onlardan da bahsedebiliriz.

Sizin kendinize has uyguladığınız pratikler varsa onlardan da bahsedebiliriz.

Monitörlük ve alert mekanizmanız nasıldır?

Buradaki işleyişiniz nasıldır?

Birazcık onlardan konuşabiliriz.

Tabii. Genel olarak belki Trendol genelinde pek çok ekibin yaptığı pratikleri biz de uyguluyoruz.

Domenimiz gereği bizim çok fazla Kafka topiği ile çalışmamız gerekiyor.

Bu topiklerin konsüm edilmesinde herhangi bir problem olup olmadığını devamlı takip etmeye çalışıyoruz.

Hangi konsümörümüzde bir problem var, bir süredir çalışmıyor olabilir bu gibi durumlar için kendimize alertler tanımlıyoruz.

Burada Trendol içerisinde oluşturulmuş bir katalog adı verilen bir...

alert template riposu var.

Bu template'i kullanarak da hangi consumer'ımızda böyle bir problem var veya işte bir lag birikti, trash olduğunu üzerinde bunları takip edebiliyoruz.

Aynı şekilde response time'larımızı da takip etmeye çalışıyoruz.

Çünkü herhangi bir bizim domenimizde invalidasyon olarak geçiyor.

Ürün üzerinde yapılacak herhangi bir update'in, güncellemenin ürün üzerine hızlı bir şekilde yansıması bekleniyor.

Buradaki yavaşlığın önceden fark edebilirsek eğer buna göre gerek kendi tarafımızda gerekse bağımlı olduğumuz diğer ekipler tarafında çözülebilmesi için gerekli aksiyonları alabiliyoruz.

Burada response time'larımızı o yüzden yine bir alert üzerinden takip etmeye çalışıyoruz ve önceden belirlediğimiz thresholdların üzerine çıktığı durumda yine bize uyarı geliyor.

Buna benzer olarak yanlış formatta bir event gelmiş olabilir veya servislerin gittiğimiz servislerden biri hata almaya başlamış olabilir.

Ya da yeni bir geliştirme çıkıp buradan hataya neden olmuş olabiliriz.

Bir farklı bir değişiklik yapmış olabiliriz.

Bu gibi durumları yakalayabilmek için de yine error log alertlerimiz bulunuyor.

Bunların dışında Kubernetes'de kodların restart durumlarını, availability'lerini takip ettiğimiz bazı alertlerimiz var.

Aynı zamanda direkt bizimle alakalı olmayan ama yine kendi uygulamalarımızı etkileyebilecek olan Couchbase, Elastic gibi için alertlerimiz de bulunuyor.

Bu alertleri ama sadece takip ve farkındalık için kullanıyoruz.

Gerekli olursa da ilgili ekiplere yine bildiriyoruz.

Bütün bu alertleri de yine ekip olarak takip ettiğimiz bir Slack kanalımız var.

Buraya yönlendiriyoruz. Bu kanalda gelen alertleri acknowledge edebiliyoruz ya da kapatabiliyoruz.

Kendi belirlediğimiz süre içerisinde eğer alerti acknowledge etmediysek, bu sefer de on-call sistemi üzerinden bir telefonla aranıyoruz.

O günün on-call'ı kimse, o kişi aranıyor.

Acknowledge durumunu da bütün ekip görebiliyor bu arada ve bu sayede de aslında o anda o problemle ilgileniliyor mu, destek gereken bir konu var mı gibi durumları da daha rahat takip edebiliyoruz ekip olarak.

Alertlerin dışında... Monitoring de bizim için çok önemli.

Burada genel olarak Trendal içerisinde metrikler Prometheus'a basılıyor, besleniyor.

Biz de bu metrikleri kullanarak Grafana dashboardlarımızı oluşturduk.

Business bazlı akışlarımız var.

Bunları takip edebileceğimiz ayrı dashboardlarımız var.

Aynı zamanda uygulama bazlı ayırdığımız dashboardlarımız da var.

Bu şekilde aslında hep gözümüzün önünde bir problem var mı?

Bunları kontrol etmeye çalışıyoruz diyebilirim.

Mert ve Kerem size bırakayım sözü yine.

Teşekkürler Seray. Bu arada güzel açıkladın.

Ben Sera ek olarak şunları söyleyebilirim belki.

Bizim ekip, iki ekip için de söyleyebilirim.

Yani hem SPI'de hem BPI'de hem işte böyle prize gibi, stok gibi çok kritik işte label gibi ürünün fiyatını, stonu etkileyen, satışı etkileyen işte promosyon, kupon gibi eventleri dinleyip anında

bütün ürünlere yani near real time bütün ürünlere yansıtmaya çalışan bir ekip olduğu için Bizim hani bu tarz şeylerde bir anomali durumunda hızlı haberdar oluyor olmamız gerekiyor açıkçası.

Bizim domainin en kritik yanı bu.

Yani bizim en büyük challenge'ımız scalability aslında.

Hep bunun üzerine yatırımlarımızı yapıyoruz.

Burada da farklı farklı işte böyle scaling çalışmalarımız oldu.

Onları belki çok detayına girmem doğru olmaz burada ama ek olarak şunları da söyleyebilirim.

Örnek veriyorum böyle kritik gördüğümüz işte ürün sayısının azalması gibi ya da price invalidasyonlarının price invalidasyonlarının son kullanıcıya yansımasının süresinin artması gibi ya da stock invalidasyonlarının son kullanıcıya

yansımasının süresinin artması gibi anomaly detection alertlerimiz de var aslında.

Yani bu tarz böyle işte örnek veriyorum %10 ürün silindiği zaman bizim direkt haberimiz oluyor, kanallara alertler geliyor.

Ya da işte price stock indexing timeları belli bir saniyenin üzerine çıktığı zaman yine haberimiz oluyor.

Bu bizim aslında bir nevi şeyi de gösteriyor.

Son kullanıcıya bazı feature'ları yansıtırken direkt şikayet gelmesin.

Biz önden haberimiz olsun ve aksiyon alabilelim.

Bunları da önden görebiliyoruz diye söyleyebilirim kısaca.

Peki şimdi en sevdiğim sorulardan biri, konuşmaktan en keyif aldığımız, muhtemelen de dinleyicilerin en çok merak ettiği noktaya geldik.

Aklınızda kalın, unutamadığınız, yakın zamanda yaşadığınız, bizimle paylaşmak istediğiniz bir incident var mıdır?

Ben buna bir şeyler anlatarak başlayayım.

Muhtemelen herkesin anlatacak bir hikayesi olur bu soruya.

Geçen sene Temmuz'da rotasyonla SP ekibine geldiğimde aslında hem onboarding sürecinde yeni yeni daha uygulamaları tanıyoruz.

Bir data bozuldu supplier ile ilgili.

Bu datanın düzeltilmesi gerekiyor.

Burada da biz etki olarak 68 milyon civarı bir reindex yapacağımızı öngördük.

Bu sayılar bizim için bu arada ufak sayılar.

Yani milyarlık dokümanlarla uğraşıyoruz.

Onların içinde 68 milyonlu küçük bir reyindeks yapacağız diye başladığımız yolda günün sonunda biz 8 milyar event publish etmiştik.

Diğer bütün ekipler tabi bu eventleri konsüme etmesi, Kafka'da saklaması yani bir uçtan bir uca gitmesi dert olan şeyler.

Event sayısı çok yüksek. Hiçbir ekip hazırlıklı olmadığı için epey bir yerden alert almıştık.

Hani işlemi durdurun diye ama başladıktan sonra durdurması da birazcık zor oluyor.

Böyle bir şey vardı, anımız vardı.

68 milyonla başlayıp milyarlarca eventle tren yolu salladığımız birazcık sevinçli, birazcık üzüntülü bir anı.

Bayağı sağlam bir anıymış ya.

Dediğin gibi her ekipte illa bir şeyler çıkıyor.

Sizinkisi de güzel, sağlam donanelerden biri oldu.

Var mı başka eklemek istediğiniz?

Kerem'e ek olarak ben de bir şey anlatabilirim.

Benimki biraz daha eski tabii. 4-5 sene evvelin konusu aslında.

2020 ya da 2019 olması lazım.

Tam net hatırlayamıyorum ama. O dönemde de şöyle bir şey olmuştu.

Jenkins'den GitLab'e geçiş yapıyorduk aslında.

Ve hemen hemen tüm ekiplerde.

Yeni entegre oluyorduk işte pipeline'ları kuruyoruz vesaire.

Bizim de bir tane consumer'ımız var.

Böyle translation consumer gibi söyleyebilirim aslında.

İşte Conf'i de Türkiye hariç diğer culture'lar diyor gibi anlatabilirim kısaca pasifçe.

Çok teknik detaya girmeden. Ben de GitLab'e geçirirken yanlışlıkla Türkiye culture'ını da translation consumer'ına geçmişim aslında.

Bununla birlikte şey olmaya başladı.

İşte o zaman tabii international ürün çok azdı.

Yani yaklaşık herhalde 2 milyon falan anca ürün vardır toplamda international'da.

Bu ürünlerin bazıları invalidasyon aldıkça Türkiye'deki ürünler de Almanca'ya çevrilmeye başladı.

Benim en büyük hikayem herhalde budur Trendyol'daki.

Birdenbire işte ürünler Almanca olmaya başlıyor falan diye bir şey yazılmaya başladı her yerden böyle.

15-20 dakika içerisinde.

Tabi bunu hızlıca fark edip geri aldık.

Sonrasında reyindex yapmıştık ve düzelmişti ama tabi benim en unutamadığım andı yani bir anda sitedeki ürünleri Almanca görmek euro fiyatından satıyor görmek falan bayağı şeydi.

Sıkıntılı bir keyifti hepimiz için.

Bayağı iyiymiş aynen.

Müşteri tarafından bir şey geldi mi peki?

Tabi müşteri tarafından satın almalar olmuş ve köresi kontrolü de yokmuş.

Dolayısıyla hani böyle 100 TL'lik ürün sağlıyorum işte 10 euroysa 10 TL'den satılmış gibi bir durum olmuş yani.

Hem Almanca hem de fiyat olarak da bir indirimle uygulamışız gibi söyleyebilirim kısaca.

Benim herhalde en büyük incident'ım ve en büyük yaşadığım şey budur Trendyol'daki.

Süpermiş aynen. Benim de duyduğum en büyük dersten biri bu bu arada.

Gayet güzel örnekler oldu.

Teşekkür ediyorum. Son olarak genelde diğer ekiplere de soruyoruz bunu.

Çok farklı örnekler duyduk.

İşte birlikte mangala gidenler oldu.

Dediğini söyleyenler oldu. İşte böyle lezzet turuna çıkan ekipler varmış.

Onları öğrendik. Sizin tarafta ekip içi iletişimi kuvvetlendirmek için yaptığınız şeyler nelerdir?

Bizde de benzer şeyler diyebilirim.

Maalesef şey olmuyor.

Lezzet turuna çıkmadık henüz.

Belki ileride. Ekiplerimizde bizim yine farklı şeylerde bulunan arkadaşlarımız da var.

Aslında ekip içi etkileşimi offline'da olduğu kadar online'da da sağlamamız gerekiyor.

Bu yüzden... Ekip dinamiklerini de koruyabilmek için, aynı zamanda bu yeni başlayan arkadaşlarımızla ekip kültürünü de paylaşabilmek için sürekli olarak online ortamda da etkinlikler düzenlemeye çalışıyoruz.

Her hafta Cuma günleri Light Talks buluşmalarımız var.

Bu buluşmalarda isteyen kişi istediği konuda bir sunum yapabiliyor veya konuşabiliyor.

Teknik de olabilir bu arada bu konular fakat herhangi bir alanda konuşma yapabiliyoruz.

Atıyorum geçenlerde dalışla ilgilenen bir arkadaşımız ekibe bu konu hakkında bir sunum yaptı veya birisi kahvelerle...

Ve kahve makinesi almıştır atıyorum.

Bununla alakalı bir sesyon düzenleyebilir.

Ülkemizin farklı illerindeki kokteyl barlarla alakalı sunumlarımız oluyor mesela.

Bununla alakalı konuşmak isteyen birisi varsa yine aynı şekilde bunlarla alakalı sesyonlar düzenleyebiliyoruz.

Light Talks'un dışında ekipçe oyun oynadığımız sesyonlarımız da var.

Bunlarda da... Farklı oyunları yine online ortamda oynayarak hem haftanın stresini üzerimizden atıyoruz hem de ekip için sosyalleşmeyi arttırmış oluyoruz bu sayede.

Ekipçe offline ortamda da tabii ki böyle etkinlikler yapmaya çalışıyoruz.

İstanbul içerisinde mesela arkadaşlarımızla, çalışan arkadaşlarımızla Quiz Night'e gitmiştik Aşk-ı Memnu için.

bir Quiz Night düzenlenmişti.

Buradaki yine Aşk-ı Memnu ile alakalı hiçbir ilgimiz olmasa bile yine sosyalleşmek için böyle bir etkinlik yapmıştık.

Aynı zamanda Java Day gibi işte Go'nun etkinlikleri gibi farklı böyle teknik etkinliklere de yine farklı şeylerden gelen arkadaşlarımızla katılıyoruz.

Böylece düzenli olarak aslında ekip için sosyalliği de korumuş oluyoruz.

Bahsetmişti, Zoom'da da bu arada breakout roomlarda çalışıyoruz ve bu da bizim sosyalleşmemiz için, ekip içi iletişimi canlı tutabilmek için yaptığımız şeylerden bir tanesi.

Böylece aynı ofiste çalışıyormuşuz gibi, sanki yan masadaki arkadaşımın yanına gidiyormuşum gibi farklı odalara giderek aslında hızlı bir şekilde...

istediğim kişiye ulaşabiliyorum.

Her ay tabii ki ofis buluşmaları yapıyoruz.

Buralarda da amacımız genellikle sosyalleşmek oluyor.

Bunun dışında şehir dışındaki arkadaşlarımızla da yüz yüze görüşebilmek için yine ekip etkinlikleri planlamaya çalışıyoruz ayrıca.

Yılda birkaç defa yine tribe geneli etkinliklerimiz oluyor.

Buralarda da genellikle mangal etkinliği düzenliyoruz.

Yine burada yakın çalıştığımız ekiplerle bu sefer aslında sosyalleşme imkanımız oluyor diyebilirim.

Gayet güzel, keyifli şeyler yapıyormuşsunuz.

Özellikle Quiz Night olayını çok merak ettim.

İstanbul'da bizde bir ekip etkinliğinde belki o tarz bir şey yaparız diye düşünüyorum.

Şu anda kitlik arkadaşlarla paylaşacağım ben de.

O zaman katıldığınız için teşekkür ediyorum.

Güzel, keyifli bir sohbet oldu.

Biz teşekkür ederiz. Gayet keyifliydi.

Teşekkür ederiz. Güzel sohbetti.

Evet, çok teşekkür ederiz.

Evet, katıldığınız için tekrar teşekkürler.

Bugün Bayır Product Indexing ve Seller Product Indexing ekipleriyle birlikteydik.

Sonraki bölümlerde görüşmek üzere.