Transkript
Selam Eki programından hepinize merhaba.
Aradan bir hafta geçti.
Bugün Erim Tal'i konuğumuz.
Erim SPM takımında çalışıyor ama ben SPM açılımını bilmiyorum.
Açılımı ne abi? Supplier Product Management.
Okey, düşünsem tahmin edilirmişim.
Hoş geldin abi.
Merhabalar, hoş bulduk. Nasılsın öncelikle?
Teşekkür ederim, sağ olun.
Sizleri sormalı. Bizler de iyiyiz.
İmentten imente koşuyoruz.
Aynen, aynen, aynen. Domain'i biraz açabilir misin?
Yani SPM dedik ki... Product Management demiştin.
Neler yapıyorsunuz? Tam olarak nereye dokunuyorsunuz?
Supply Product Management ekibi Trendyol'da 3 sene önce başlayan bir market phase projesinin parçası aslında.
Biz genel anlamıyla tedarikçilerin ürünlerini yönetiyoruz.
Yani tedarikçiler Trendyol sistemine kendi ürünlerini bir integratör aracılığıyla ya da işte Excel aracılığıyla gönderebiliyorlar ve biz tedarikçilerin bu ürünleri yönetmesini sağlıyoruz.
O konuda yardımcı oluyoruz.
Ona uygun servisler yazıyoruz diyebilirim.
Bu domainin içinde neler var?
Tedarikçinin ürün bilgileri yani stok fiyat ve metadata olarak değerlendirebiliriz.
Onun dışında tedarikçinin o ürünlerine uygulanacak komisyonlar var.
Tedarikçinin ürün görselleri var.
Bunları tedarikçiler yüklüyor.
Daha sonra bunlara güncelleme gönderiyorlar.
Ve biz bunları trendol sistemleri içine besliyoruz.
Ve tedarikçilere geri dönüş yapıyoruz gibi söyleyebilirim.
Pim diye bir ekibimiz daha var kendi yolu içerisinde.
Product'tan sorumlu. Senin bahsettiğin de yine Product ve şeylerin birleştiği bir domen oluyor.
Pim ile aranızdaki oradaki ilişki nedir?
Mesela fotoğrafı, Product'ın resmi bizde duruyor dedin ya.
Pim'de de yok mu bu?
Oradaki şeyler nedir?
Domenin sınırları nelerdir?
Ve bununla birlikte başka hangi domenlerle birlikte yakın çalışıyorsunuz?
Şöyle, Pim dediğimiz şey Product Information Management olarak geçiyor.
Pim bizim sistemlerimizde tedarikçiden bağımsız ürünü bir katalog halinde yöneten sistem olarak kabul edebiliriz.
Ve biz Pim'le çok yakın çalışıyoruz.
Yani bize yüklenen ürün, tedarikçinin SPM tarafına yüklediği ürün tam olarak sitede görünen ürün değil.
Pim özelinde o ürünün zenginleştirilmesi ve bir kampanyaya dahil edip yayına çıkarılması gerekiyor.
Biz Pim'e bize yüklenen ürünlerin bilgilerini veriyoruz belli yollarla.
İşte QC dediğimiz Quality Check üzerinden giden bir event sayesinde de olabilir.
Direkt PIM üzerinden bize gelen Excel'lerle de olabilir.
Yani Excel dosyalarıyla da olabilir.
QC de ayrı bir domain değil mi?
Evet QC de PIM'e bağlı ayrı bir domain.
O da işte ürünlerin otomatik olarak yayına çıkmasıyla ilgili çalışıyor.
Biz QC'yi de çok yoğun besliyoruz.
PIM'i de çok yoğun besliyoruz.
Daha sonrasında ürünler orada zenginleştiriliyor dediğim gibi yani.
Tedarikçinin görselleri bizde var.
Tedarikçi bizi iletiyor ama o görselleri daha sonra işte kampanya ya da ürün yayına çıkarken zenginleştirip düzenleyip ona göre yayına çıkarıyorlar.
Sitede o şekilde gözüküyor diyebilirim.
Biz daha çok draft bilgilerle tedarikçilerin draft bilgilerini single katalogda bir ürün yaratma üzerine pime besliyoruz.
Aramızdaki fark bu aslında.
Peki pime besledikten sonra ön yüze de sizin üzerinizden mi gidiyor şeyler, produklar yoksa siz?
Supplier ve supplier bu arada dinleyicilerimiz için söyleyelim.
Trendyol Marketplace sistemiyle de çalıştığı için dışarıda işte mesela bir telefon kabı satan bir bayiğiniz var.
Trendyol üzerinden satış yapabiliyorsunuz.
Biz bunlara seller, supplier gibi isimler veriyoruz.
Supplier diye geçiyor. Hatta supplier ile product arasında durup pimi besliyorsunuz.
Sonrasında ön yüze pim üzerinden mi çıkıyor bu ürünler?
Evet ön yüze pim üzerinden çıkıyor.
Ön yüze content olarak gidiyor aslında.
Content dediğiniz şey işte Çok basit bir örnekle şöyle anlatabilirim.
iPhone 8 GB siyah aslında bir kontenttir.
Bunun için de o ürünü satan tedarikçiler listelenir Trendyol sayfalarında.
Belki dikkat edenler olmuştur.
İşte bu ürünü hem Barış satıyor, hem Fırat satıyor, hem Onur satıyor.
O zaman aynı ürünün 3 tane farklı satıcısı olduğunu şeylerde de görmüşsünüzdür belki Trendyol ürün detay sayfalarında.
Biz Pim'e besledikten sonra Pim bu arkadaşları belli kampanyalara dahil ediyor ve ön yüze besliyor.
Ön yüzde de browsing ekibimiz var.
Browsing ekibi onları ön yüzde aramaya ve listelemeye açıyor diyebilirim.
Abi peki supplier ürünü size yüklüyor.
O ürünün daha önceden Trendyol'un olup olmadığını nasıl anlıyorsunuz?
Trendyol'da yayında olup olmadığını mı?
Daha önce böyle bir ürün yaratıldı mı?
Mesela iPhone 12 ilk defa çıkmış.
İlk defa bir saplaya ekliyor bunu.
Trendyol'da var mı yok mu kontrolü?
Kim yaratıyor bu ürünü? Ya bu şöyle.
Tedarikçilere aslında bu imkanları sağlayan modüllerimiz var.
Yani tedarikçi Trendyol'da daha önce satılan bir ürünü arayıp yani bar kodunu arayıp ya da ismini arayıp bu ürün varmış Trendyol'da tamam ben de bu ürünü ekleyeceğim deyip bize bir istek gönderip daha sonra bizim üzerimizden
o kontentin içine O barcode dahil edilebilir tedarikçi adına.
Böyle bir sistemimiz var.
Bunun dışında yaptığımız bazı eşleştirme modülleri var diyebilirim.
Mesela tedarikçi bir ürün yüklüyor.
Diyor ki bu ürün Trendyol'da satıyor.
Ben de bu ürünü yükledim. Ben de bunu satmak istiyorum ve eşleştire basıyor.
Bu aynı ürünü satıyorum ben de diyor.
Yine tedarikçi özelinden bize gelen bir istek var.
Aynı zamanda arka tarafta bizim bazı koştuğumuz servisler var.
Bu servislerden bir modülümüz şey yapabiliyor.
gidip filmde bu ürün var mı ve bu ürün yayında mı?
Yayındaysa o zaman bu tedavisinin ürününü de yayına çıkaralım gibi bazı aslında checker diyebileceğim modüller var.
Süpermiş. Buradan şeye geçmek istiyorum abi.
Bizim ekipte mesela şu an sanırım 5 developer var.
Bir QA var. Bir PM var.
Bir de ekip büyüdükçe bölme gibi yaklaşımlar var.
Sizin ekibiniz nasıl? Şu an kaç kişisiniz?
Hangi rollerde hangi arkadaşlar var?
Bizim ekibimiz de aslında ilk zamanlar yani ben Trendyol'da 2,5 senedir çalışıyorum.
İlk zamanlar daha büyük bir ekibimiz vardı.
Yani 20 kişiye yakın bir ekibimiz vardı.
Daha sonra domen özelinde işler, domen üzerinde ekipler bölünmeye başladıkça bizim de küçük ekiplere ayrılmamız gerekti.
Şu anda 5 backend developer'ız, 2 frontendçi arkadaşımız var, 2 QA arkadaşımız var, bir de product owner'ımız var.
Yani product manager, product owner olarak geçiyor.
Süpermiş abi. Peki ekip büyüdüğü zaman yeni arkadaşlar katılıyor içeriye.
Yeni arkadaşlar geldiği zaman onboarding sürecini nasıl hallediyorsunuz?
Aslında bir tık challenge yapan bir şey.
Yani challenge eden bir şey onboarding süreci.
Biz orayı şöyle çözmeye karar verdik.
Öncelikle pair oluyoruz onboardingde gelen şeylerimiz için arkadaşlarımızla beraber.
Yani herhangi bir sistemle alakalı herhangi bir şey öğrenmeden pair olup ona sistemi anlatıyoruz.
Ve Codebase'den biraz bahsediyoruz.
Kullandığımız teknolojilerden bahsediyoruz.
Daha sonra tasklar özelinde yine Payr olarak arkadaşımıza devam ediyoruz.
Bunun yanında onboarding sürecinin bir parçası olarak da Codebase'i daha rahat öğrenebilmesi için ve kullandığımız teknolojilere biraz daha aşina olabilmesi için teknik tasklar esayn edip onu takip ediyoruz.
Yani abi yardıma ihtiyacın var mı?
Destek lazım mı? şeklinde.
Bu şekilde onun bizim domeyine hem business özelinde hem teknolojik tek site gözetiminde alışmasına yardımcı olmaya çalışıyoruz.
Ne kadar sürüyor peki tahminen bir kişinin onboard olması?
Senioriteye göre de değişiyor olabilir ama.
Tabii yani. Hedefiniz var mı?
Kendi teknoloji, yani bize geldiği teknolojik bilgisiyle ya da işte dediğin gibi seniorite bilgisiyle farklılaşmakla beraber.
Kullandığımız tek siteye alışması çok uzun sürmüyor.
Ancak business biraz karışık.
Yani bizde çok fazla lojik koşan, çok fazla business yapan servisler var, API'ler var.
O yüzden onu öğrenmesi, aşağı yukarı biznesi öğrenmesi bir 2-3 ay sürüyor diyebilirim.
Normal teknoloji konusunda da 1-1,5 ayda alışıyor herkes.
Şey dedin abi, dojik olarak çok fazla dojiğimiz vardı dedin.
Sizde kaç mikro servis var şu an?
Şu an yaklaşık olarak 30 tane mikro servisimiz var.
Ve onun yanında koşan, işte başka arkada çalışan workerlarımızdan da bir 5-10 tane sayabilirim.
30-35 tane falan prodda çalışan servisimiz var diyebilirim.
Yani şimdi şey diyeceğim bizim legacy uygulamalarla beraber yaklaşık 70-80 tane mikro servisimiz var ama aslında bir ekibin kaldırabileceğinden biraz fazlası.
Sizin için nasıl bu? 30 mikro servis sizin böyle baş edebileceğinizden daha mı fazla yoksa tam ayarı mı?
Yani şöyle aslında daha fazla olması gerektiğini düşünüyoruz.
Çünkü bazı uygulamalarımız var çok fazla iş yaparak hem çok fazla resurs tüketiyorlar hem de yönetilmesi çok zor oluyor.
Ve biz bu yüzden elimizden geldiğince bölmeye uygulamaları ayırmaya ve daha fazla mikro servis.
üretmeye çalışıyoruz. Genelde yani bütün şeylerimiz bununla ilgili.
Refaktörlerimiz bununla ilgili.
Bence yani kişisel fikrim bir ekip için mikro servislerin sayısı çok önemli değil ama o mikro servislerin yönetilebilirliği ve monitoring edilmesi bir challenge yani.
Abi içeride 30 tane mikro servisiniz var dedin.
Büyük ihtimalle her şey içinde farklı ihtiyaçlarınız olmuştur.
Burada ne tür teknolojiler kullandınız?
Biraz onlardan bahsedebilirseniz.
Tabii. Bizim genel olarak tek siteyimiz JVM üzerinde koşuyor.
JVM siteyi koşuyor.
Ama biz teknolojiyi seçerken genel olarak ihtiyaçlarımıza göre seçmeye çalışıyoruz.
Yani buna ihtiyacımız var mı ya da buradan iyi kullanmalı şeklinde.
Java 8 var. Spring Boot var.
Birçok uygulamamız öyle. Onun dışında Go ile ve TypeScript ile yazdığımız bazı servisler var.
Genelde bunlar gateway'ler olarak geçiyor.
Trendyol içerisinde gateway olarak geçiyor.
Aggregation API'leri diyebiliriz bunlara.
Onun dışında database olarak en büyük data source'umuz Couchbase ve arama için Elasticsearch kullanıyoruz.
Bazı uygulamaların DB'leri de PostgreSQL.
Tamamen işte domain'e bağlı, oradaki lojiye bağlı olarak seçilmiş teknolojiler yani.
Biz üçümüz de Barış, Fırat, ben de daha çok order yazıldıktan sonraki süreçteyiz.
Product ise daha önceki bir süreç.
O yüzden böyle şeyi bilmiyoruz.
Oradaki yapıyı yani tahmin edebiliyoruz.
Çünkü aktarımında falan biz de çalışıyoruz.
Product'ın legacy aktarımında.
Şu an bir legacy database var.
Hepimizin, dördümüzün de gündemi yakın zamanda öldürmeyi planladığımız hatta Black Friday'e kadar.
Burada sizin legacy uygulamalarınız var mı?
Legacy database üzerinde çalışan veya legacy database üzerinde çalışmasa bile kendisi legacy olan uygulamalarınız var mı?
Yani aslında tam olarak legacy denebilir mi bilmiyorum.
Yani direkt öldürmeye çalıştığımız bir uygulama yok.
Ama mesela ekibin adından gelen SPM diye bir uygulamamız var.
Çok ağır ve çok yüklü bir uygulamaydı.
Biz mesela direkt öldürmek yerine içindeki modülleri farklı mikroservislere çıkararak o uygulamanın yükünü ve kullandığı resursu düşürmeye çalışıyoruz.
Onun dışında öyle legacy olarak direkt öldürebileceğimiz dediğimiz bir uygulama yok.
Ama öyle bir ihtiyaç doğduğu zaman genel olarak şöyle ilerliyoruz.
İlk olarak yaptığı işlerden neleri çıkarabiliriz?
Nasıl bir dizayna gidebiliriz?
Daha sonra o haline getirip uygulamayı ya tamamen kapatıyoruz ya da belli özellikleri oradan sağlamaya devam ediyoruz.
Bir de bu şeyle alakalı gelen lojiklerle gelen bizim trend yolu içinde yine ona şey deniyor.
Biznes isteri deniyor. Bizim biznes tarafından iç müşteriden gelen isteklere bağlı olarak.
legacy olmayan bir uygulamanın bile direkt ölmesi söz konusu olabiliyor.
Geçtiğimiz zannediyorum geçtiğimiz Black Friday'den önce 2019'daki Black Friday'den önce bu tarz bir geçiş yapmıştık.
Uygulamayı tamamen öldürüp yepyeni iki tane farklı uygulama çıkarmamız gerekmişti.
Ama bu legacy olduğundan değil istenilen sürecin çok daha farklı olmasından kaynaklıydı.
Anladım abi. Rica et gibi aslında yani tüm business prosesini değiştiriyorsunuz.
Ben Trendle ilk geldiğimde İlk mikro serviste bana dediler ki Java yazsan daha iyi olabilir.
Ben de Java'ya başladım. O zamana kadar .NET orijinli bir devap aradım ve .NET'te her şeyi en iyi şekilde yapabileceğimi düşünüyordum.
Daha sonra Java'dan sonra da Go'ya geçtim.
Ama benim favorim burada Java oldu ve ben bunun olacağını düşünmemiştim.
Çünkü bence her şeyi çok daha kolay yapabilmeyi sağlıyor ve çok fazla kaynak tüketiyor ama çok ciddi artılarını gördüm.
Sende de böyle bir bakış açısı değişimi oldu mu?
Yani ben gelmeden önce de Java yazıyordum.
Java tabanlıyım. Açıkçası diğer dilleri denemek, diğer farklı dilleri ya da frameworkları denemek çoğu zaman bir trade-off bence.
Ben de Java ile her şeyi çözebileceğimi düşünüyorum ama bazen Java yazmıyorum.
Her şeyi çözebileceğimi düşünmeme rağmen Java yazmıyorum.
Bu tamamen bir trade-off.
Dediğin gibi kullandığı resurslar, kullandığı framework da burada çok etkili.
Spring Framework'ün kullandığı resurslar da çok yüksek.
Kendi yüklediği klaslardan dolayı.
Go'da yazıyoruz biz. Ben biraz daha yeni yeni adapte olmaya başlıyorum.
İşte biraz TypeScript'le aram var.
Açıkçası seviyorum yani Node.js tarafında onunla uğraşmayı ama Go'ya hala ısınamadım.
Hala yani o Java şeyini atamıyorum.
Bir de şey oluyor. Böyle dilleri gerçekten kendi yazıldığı halleriyle yazmak gerekmiyor mu bilmiyorum.
Ben yanlış mı düşünüyorum. Biz genel olarak yani ben Go'yu da sanki Java gibi yazmaya çalışıyormuşum gibi geliyor.
Ya da ne bileyim TypeScript'te de benzer bir şey yaşadım yani.
Java gibi yazmışım. sanki oluyor.
Belki de orada biraz şey yapıyoruz.
Hata yapıyoruz. Bilemedim.
Evet ya. O bende de çok oluyor ya.
Yani ben de işte Fırat ve olur gibi yani buraya gelene kadar işte main şeyim .net yani C şarkı yazıyordum sürekli.
İşte burada ben de işte Java yazmaya başladım.
Benim de bakış açım bayağı değişti yani gerçekten.
Şu anda hani yeni bir projeye başlayacak olsam kendi kararımla büyük ihtimalle Java'yı seçerdim herhalde.
Go konusunda ben de aynı ya.
Burada işte bir go ile ufak bir Bizdeki eğitmeyi yazdık.
Yani kodu daha sonra okuduğum zaman bayağı böyle şeye benzetmeye çalışmışım.
Yani C şartta, Java'da yaptığım böyle yapıya benzetmeye çalıştığımızı görüyorum.
Yani orada gerçekten belki dilin şeyine uymak daha doğru olabilir ya.
Yani bulanım şekline.
Yani katılıyorum sana.
Abi öğrenme dediğin biraz öyle gelişiyor ya.
O yüzden onu kırmasın. Güç bence ama kesinlikle katılıyorum.
Kırmak gerekiyor. Daha önce öğrendiklerini de ilişkilendirerek öğreniyorsun ya.
O yüzden işte 10 yıldır Object Oriented yazıyorsan o paradigmayı değiştirmek gerçekten çok zor olabiliyor.
Bir de Functional gibi böyle çok daha önce kafa yormadığın, karşılaşmadığın bir paradigma karşına gelince daha önce Java'da, C Sharp'ta yaptığın şeyin aynısını Go'da yapmaya çalışıyorsun bu sefer.
Katılıyorum öyle bir şeyi var.
Erim peki 30 mikroservisten bahsettin ve baktığın zaman Trendyol'da Product Seller...
Supplier çok önemli. Çok önem verdiğimiz bir konu.
Burada sürekli yeni feature çıkıyordur diye tahmin ediyorum.
Hatta birçok feature sizin tarafa SPM üzerine geliyordur diye tahmin ediyorum.
Hem ön yüzünüze hem API'nize, oradaki yeteneklerinize.
Buradaki deployment süreciniz nasıl?
O CICD'yi nasıl kurguluyorsunuz?
Ne çalışıyorsunuz? Ve ne kadar sıklıkla deployment yapıyorsunuz?
Bizim çok değişken açıkçası.
Aldığımız tasklara, yaptığımız işlere göre değişebiliyor.
Mesela bir... taşıma ya da refaktör gibi bir iş aldıysak o API iki hafta boyunca deploy görmüyor olabiliyor.
Çünkü bütün parçasını taşıyıp ondan sonra deploy edip daha şey bir geçiş yapmak istiyoruz.
Bu tarz taşımalarda ya da geçişlerde daha smooth bir geçiş yapmak istiyoruz.
O yüzden bazı API'lerin özellikle üzerinde şu an teknik bir dep koşuyorsa, tek dep koşuyorsa deployları bir tık yavaşlayabiliyor ama tasklara bağlı olarak günde bir tane deploy olduğu da oluyor.
10 API'de deploy ettiğimiz oluyor.
Haftada yani hafta olarak veremem bu datayı büyük ihtimalle.
Çünkü yeni yeni tutmaya başladık.
Daha yeni takip etmeye başlayacağız.
Diplomat Frequency kederimizi.
Ama günde en az 2-3 Diplomat yapabiliyoruz diyebilirim.
Diplomat sıklığınızı Forky ile mi takip edeceksiniz?
Evet aynen. Orada zannediyorum şeyi kullanacağız.
Şu an çalışıyoruz üzerine Jira'yı ya da Git'le bir kullanacağız.
Bizim kullandığımız Ecel turlarının bize verdiği imkanları kullanacağız.
Kendimiz bir otomasyon, kendimiz bir şey yazmayacağız.
Bunun da takip edeceğimizi düşünüyorum.
Şu an üzerine çalışıyoruz. Bir aya falan yapmış oluruz.
Şey abi, bizim ekipten çıkma bir open source proje var.
Onu belki bulabilirsiniz.
Biz planıyoruz, bayağı memnunuz. Böyle proje bazlı şeyi veriyor aslında.
Haftalık kaç tane deployment olmuş, ne kadar fix çıkılmış gibi.
Ve böyle grafiteleştirip veriyor.
Güzel olabilir. Yani 4K projenin de ismi.
Harika. Bunu bir şey yapalım.
Konuşalım şeyden sonra.
Bu da olabilir. Çok güzel olur bizim için.
Tamamdır abi. Bu arada dinleyicilerimiz için de şey olsun.
GitHub'dan kendi organizasyonu altından veriş edebilirim.
4K. İki tane 4K projesi var orada.
Open Source. Onlara da bakabilirsiniz.
Hatta Accelerate kitabını da herkese şiddetle öneriyoruz.
Bence olarak bayağı kafamızı açan bir kitap oldu.
Evet. Görüşürüz.
Deed deployment'ın aslında sağlıklı olması için birçok adımdan değiştiriyoruz.
Code review'lar, unit test coverage'ları vs.
falan. Biraz bu konularda neler yapıyorsunuz?
Onlardan bahseder misin? Code review süreçleriniz nasıl?
TDD uyguluyor musunuz mesela?
Yani bunun iki cevabı var.
Pandemiden önce ve sonra olarak.
Pandemiden sonra tabii ister istemez peer ve TDD oranımız...
düştüğünü düşünüyorum ben.
Bizim ekip özelinde olabilir bu.
Tüm ekiplerde böyleyim bilmiyorum ama özellikle pair kısmında bir tık düştüğümüzü düşünüyorum.
O da biraz işte şey bizim bir retro konumuz.
Quadravim süreçlerini şöyle yapıyoruz.
Genel olarak işte kullandığımız versiyonlama şeyinde Bitbucket'de ya da GitLab'de PR'ler açılıyor.
O PR'ler onay ya da yorum alıyor.
Ona göre merge edilip pipeline'ler başlatılıyor.
Tabi bu daha böyle simple tasklar için.
daha böyle geniş baltayla girdiğimiz bir yerler olursa ekip olarak toplanıyoruz.
Yapan arkadaşlar, payerler bize neler yaptıklarından, nasıl yaptıklarından, ne düşündüklerinden bahsediyor.
Bu pandemiden önce bir toplantı odasında hep beraber toplanarak yapıyorduk.
Şimdisiyle Zoom'da toplanıyoruz.
Anlatıyor. Daha sonra biz işin yapılma şeklini, işin lojiklerini inceliyoruz.
Ondan sonra kodu genel olarak en azından ben şey yapıyorum.
Onların branjını bir de kendi tarafıma alıyorum.
Oradan bir review yapıyorum.
Daha sonra yine pipeline süreçlerine sokuyoruz.
Pipeline'de de şu anda GitLab ve Jenkins'i beraber kullanıyoruz biz.
Çünkü Jenkins'te çok fazla parametreyle koştuğumuz bazı workerlarımız ve tool'larımız var.
Onların GitLab'e geçişini biraz işte onlarla uğraşmamız lazım.
Genel olarak GitLab'teki geçişte Master Merge'den sonra Pro'da kadar uygulama çıkabiliyor.
Süpermiş. Bu arada Bizde de tam tersi bir şey oldu ya.
Pandemiden önce bu kadar çok fazla peer yapmıyorduk.
Pandemiden sonra bayağı yapmaya başladık.
Biz şey kullanıyoruz orada, used together diye bir tane tool var.
Onu kullanıyoruz.
Bayağı verimli geçiyor ya. Sizde nasıl bir şey Onur, Fırat?
Bizde daha çok şey üzerine ilerliyor.
Zoom üzerinden yapılıyor.
Bir de biz promotion kupon ekibinde bugün şöyle bir pratiğe geçtik.
Bolt ekibi yapıyormuş galiba.
Onu da tavsiye ederiz. Bir tane Slack kanalı var.
Payr kanalı. Burada sadece Zoom linkleri yaratılıyor burada.
Normalde backslash Zoom yazınca bir şey yaratabiliyorsun ya.
Zoom kanalı yaratıyorsun ya. Orada işte konu başlığını da yazabiliyorsun.
Zoom deyip meeting yazarsan ondan sonra boşluk bıraktıktan sonra orada görünüyor onun neyle ilgili oldu o Zoom linkini.
Orada işte iki kişi mesela Payr oluyor.
Yarım saat, bir saat bir kişinin bir boşluğu oldu.
O kişi de orada bakıp farklı bir sürü pair zoom'u görüyor.
İstediği kanala girip orada beraber pair yapabiliyor.
Böyle bir pratik faydalı olabilir.
Bir de şey fena olmayabiliyor.
Bütün ekibin gördüğü, kontribüt ettiği bir pair şartı güzel olabiliyor.
Kim ne kadar pair yaptı onu görüp retrolarda onun üzerine konuşup aksiyon almak yine pair sayısını arttırabiliyor.
Evet, biz bir ara onu çok şey tutalım.
Sıkıntı takip ediyorduk da. Son zamanlarda biraz bıraktık gibi oldu.
Ama dediğin gibi şeyde çok faydası oluyor.
Retrolarda falan. Mesela PR yapıyoruz.
PR sayısı yüksek çıkıyor ama bu sefer şeyde çıkabiliyor.
Sürekli benzer kişiler birbiriyle PR yapmış.
Bunu da fark etmemizi sağlıyordu aslında uçak.
Bir şekilde onu tekrar hayatımıza sokmaya çalışsak iyi olacak bizim.
Bizim için de aynı oldu ya.
Bizim de payır sayımız bayağı arttı.
Ama biz şey yapıyorduk abi.
Slack kanalında yazıyorduk. Payır arayan var mı?
Lütfen bana payır bulun gibi.
Böyle mesajlarla çözmeye çalışıyorduk.
Sizin yaklaşım mantıklıymış aslında.
Bana payır. Yani zoom açmak daha iyi.
Bana payır bulun. Sana payırımı getirin.
Bizde de aşağı yukarı öyle.
Fıratlardaki gibi. Payır olmayan var mı?
Ya da işte var mı bana destek atacak.
Şöyle bir işe gireceğim gibi.
Biraz öyleydi. Bu da her zaman çalışmıyor abi.
Çünkü hani o sırada sıraya da bakmamış olabiliyorlar falan.
Hazır linkler güzel fikir ya.
Çok iyi. Evet evet güzelmiş böyle.
Peki abi olmazsa olmazımız bizim de bugün yine yaşadığımız sorunlar oldu.
Monitoring tarafını nasıl hallediyorsunuz abi?
Ya da diyelim bir dert oldu.
Bundan nasıl haberiniz oluyor? Yani tren yolu genelinde kullanılan bir pratik.
Tabii ki de nevrelik alarmlarıyla.
Kendi belirlediğimiz thresholdlarda uygulamalar farklı bizim istemediğimiz bir davranış sergilerse.
Slack kanalımız var, ona basıyor.
DevOps tarafının bize sağladığı çok güzel bir özellik var.
Rabbit kullandığımız için oradaki dead letter'ları bize haber veriyor.
Ya da Rabbit'teki BQ'nun birikme sorununu bize haber veriyor.
DevOps tarafıyla orada bir şey yaptık, beraber çalıştık.
Onlar bize böyle bir tool sağladılar.
Genel olarak onun dışında Grafana üzerinden uygulama metriklerini takip ediyoruz.
Greylock'ta bir iki dashboard'umuz var.
Business logiklerinde çıkabilecek bazı...
logları gruplayarak orada dashboardlara vurduk.
O şekilde takip ediyoruz.
Peki milyonlarca product'ın olduğu bir sistem üzerinde monitoring'i de bu şekilde yapıyorsunuz ve hem seller'a hem de son kullanıcıya etki verebilecek bir yerde duruyorsunuz.
Ben çok ölçemedim.
Tam olarak sizin takım olarak sence en büyük challenge'ınız ne?
En çok ne sizin için problematik?
Teknik taraf mı? Bizans tarafını yönetmek mi?
Domain'in karmaşıklığını düzeltmek mi?
Sence nedir buradaki en büyük probleminiz?
Yani en büyük challenge tabii ki de tedarikçinin mutsuz olmaması.
Yani müşteri nasıl trendi yok, müşteriyi mutsuz etmemek için çalışıyorsa bizim müşterilerimizden bir tanesi de tedarikçiler.
Tedarikçilerin mutsuz olmaması.
İkinci aşamada iç müşterinin mutsuz olmaması.
Tabii bu challenge tedarikçi davranışlarıyla bizim onlara verdiğimiz servislerin, modüllerin sürekli değişip ve tedarikçilerin bunlara nasıl ayak uydurduğuyla ilgili.
oluyor genelde. Ama mesela en büyük challenge'ımızı şey olarak söyleyebilirim.
Fiyat ve stok güncellemeleri.
Gerçekten çok yoğun fiyat ve stok güncellemesi alıyoruz ve bunun birikmeden bir sıkıntıya uğramadan bir an önce ön yüze bizim üzerimizden gitmesi gerekiyor.
Günde yaklaşık 100 milyondan fazla şey alıyoruz.
Stok fiyat güncellemesi alıyoruz.
Ortalama bir günde. Bu tabi eventlerde çok daha fazla oluyor.
En büyük challenge'ımız bu.
Onun dışında işte Komisyonlar üzerinde çok büyük challenge'larımız var.
Çünkü çok karmaşık bir lojik var orada.
Çok detaylı anlatmayayım ama gerçekten karmaşık bir lojik var.
O da iç müşteriye hizmet eden, tedarikçilerin ürünlerine ait komisyonları yönettikleri servisler.
İkinci challenge'ımız da orada.
Orada da keza event dönemlerinde özellikle çok yoğun bir komisyon vade girişi çıkışı oluyor.
Bu ne demek? Başka sitede şu fiyatta satılıyormuş komisyon hemen düşürelim bizde de fiyatı düşürelim gibi böyle çok anlık bazı güncellemeler göndermeler yapmaları gerekiyor.
O yüzden iki büyük challenge'ımız onlar aslında.
Diğer kısımlar işte dediğim gibi API'lerin belli bir response time'ın altında sürekli seyretmesi belli bir throughput'ta.
Onun dışında hatalarımızı azaltmak ve sistemin bir nevi selametini korumak yani.
Abi genelde order'da...
Beraber çalışan takımların hatalarını stabilizasyondan fark edebiliyoruz ama ben sizin hiç hatanızı gördüğümü hatırlamıyorum.
Sizde sorun olduğunda kim size ulaşıyor?
Bizim yakalayamadığımız bir sorun olduğunda genel olarak iç müşteriden geldiği zaman bize işte bir kanalımız var.
Public bir kanalımız var. Oradan geliyor.
Yakalayamadığımız bazı sorunlar olabiliyor.
İç müşteriden bizim product manager'a ya da testçi arkadaşımıza oradan da bize gelebiliyor.
Ya da Farklı ekiplerle çalıştığımız için örneğin az önce Pim'i konuştuk.
Pim'le çok yakın çalıştığımız için Pim'le ilgili ortak bir kanalımız var.
Oradan ekip bazlı haberleşebiliyoruz.
Yani stabilizasyona çok yansımıyor dediğim gibi.
Yansıdığı zamanlar da oldu da çok yansımadan sorunları böyle bütün şey tren yolu özelinde çok büyütmeden, insanları şey yapmadan, rahatsız etmeden kendi aramızda yakalayıp hemen
çözmeye çalışıyoruz. Hemen anlık aksiyon almaya çalışıyoruz.
Ama stabilizasyona yansıyan çok büyük problemlerimiz de oldu zamanında.
Ben hatırlıyorum hiç unutmam yani.
Ne oldu abi? Çok büyük bir data center'da bir sorun yaşandı.
Çok uygulamalarımız indi ve komple yani her şeyimiz gitti.
Gelmesi bayağı uzun sürdüğünde biz de şey olarak çalıştık işte.
Uygulamaları nasıl geri getiririz, datalarımızı nasıl toplarız falan gibi.
Bayağı yoğun bir çalışma olmuştu.
O zaman yansımıştı stabilizasyona diye hatırlıyorum.
Peki bunun dışında böyle aklında kalan yani canlı sistemde yaşadığın büyük bir problem var mı?
Bize anlatabileceğim böyle bir hikaye tarzında.
Hikaye tarzında?
Hikaye tarzında olmasına gerek yok.
Böyle bir şey yaşadık da şöyle bir problem oldu gibi.
Yani direkt böyle çok hikayeleştirilmiş şey olarak şu an aklıma bir şey gelmiyor ama mesela şöyle bir şeyden bahsedebilirim.
Daha geçenlerde işte sistemde bir sorun yaşandı ve patladık.
event zamanından biraz sonra, birkaç gün sonra bir cluster geçişi oldu Kubernetes'te.
Cluster upgrade. Clusterlardan bir tanesi kapatılınca bir anda yük binmiş ve apilerden bir tanesi dağıldı.
Queue'lar birikti. Müşteri mutsuz.
Biz mutsuz. Sonra tabii onu hemen müdahale edip ayağa kaldırdık tekrar.
Queue'ları erittik. Abi tam bir resto konusu.
Arada yaşıyoruz böyle.
Evet evet. Yani arada yaşıyoruz böyle.
Yani bu... Bizden kaynaklı da olabiliyor, başka bir networksel de olabiliyor ya da ne bileyim database de olabiliyor, bizim çıktığımız bir kod yüzünden de olabiliyor.
Bunun neden olduğuyla açıkçası çok ilgilenmeden direkt müdahale edip sorunu çözüp ondan sonra bu bir daha yaşanmaması için ne yapabiliriz deyip ileri bakmakla uğraşıyoruz
yani. O süreci nasıl yürütüyorsunuz abi?
Çünkü biz mesela böyle bir soru yaşadığımızda genelde retroda konuşuyoruz ya da KPL toplantısında konuşuyoruz.
Retrodan ama güzel aksiyonlar çıkıyor.
Sizde nasıl yürütüyor? Retroya direkt aksiyon maddesi olarak girmiyor aslında bizim incidentlarımız.
Bizim incidentlarımız bir incident excelimiz var ona giriyor ve onun için o incidentı çözdüğümüz anlarda zaten aksiyon planını ve bir daha yaşanmayacak şeyi almaya çalışıyoruz.
Bunlarla ilgili işte hemen jira taskları açılıyor.
gerekli ekiplerle hemen konuşuluyor işte devops tarafında bir şey ise hemen devops arkadaşlarımıza ulaşıp abi böyle böyle bir sorun var şu anda şöyle çözdük ama bunu çözmemiz lazım gibi ya da database
ise işte bizim şöyle bir şeye ihtiyacımız var şöyle bir sorun yaşadık gibi daha böyle aksiyonlarımızı hemen belirleyip yani incident'ı yaşarken ve yaşadıktan hemen sonra belirleyip ona göre şey alıyoruz retrolarda
da hani böyle bir incident yaşadık evet doğru Bunu da çözdüğümüz şu oldu şeklinde konuşularak geçiyor.
Biz de orada aslında bir tık farklı olarak yine Fıratlar gibi yapıyoruz.
Anında yine tabii problemi çözmek için gerekli aksiyonları alıyoruz.
Ekstradan bir de aynı bizim yaptığımız retrolar oluyor.
O retrolarda da şeyleri konuşuyoruz aslında.
Bu ay mesela bu kadar instant yaşamışız.
Yani normalden atıyorum fazla yaşadıysak.
Bunun biraz daha aslında sebebini bulmaya çalışıyoruz gibi bir yönteme gittik aslında.
Onun dışında aslında yavaş yavaş programı da kapatabiliriz sanki.
Son böyle söylemek istediğin bir şey var mı?
Konuklarımıza, dinleyicilerimize diyeyim.
Teşekkür ederim beni davet ettiğiniz için.
Çok mutlu oldum. Biraz heyecanlıyım ben kusura bakmayın.
Umarım dinleyenler de memnun kalır.
Umarım hepimiz. Memnun kalmışızdır diyeyim.
Teşekkür ederim.
Ne demek. Heyecanlıysam da hiç belli olmuyor.
Gayet güzel geçti bizim açımızdan.
En başta da söyledim ki bizim çok bilmediğimiz bir alandı.
Product tarafı.
Order'dan öncesi.
Bizim için de gayet faydalı oldu.
Çok teşekkürler katıldığın için.
Diyoruz ve programımızın bir klasiği olarak Fırat'ın şarkılarıyla mı?
Erim şarkısı.
Biletmemiş miydim daha önceden?
Yerim sonuçlı selekten yazmıştım galiba.
Hiç görmedim gerçekten.
Çok ilancız çok.
Görmedin de kutlamazsın diye bir şey yok.
Gelmedi yani. Yazmadım.
Peki bir doğaçlama bir komple bir şeyden.
Şarkı söyleyecek olsa hangi şarkı söylerdin şu an?
Yani Deniz Üstü Köpürür söylerdim ama Cem Karaca'yı ayıp etmek istemiyorum o yüzden.
Beni pas geçirin.
O zaman Fırat sıra sende.
Aynen Fırat abi. Benim aklıma gelen şu an tek şarkı.
Trendyol.com Çok güzel.
Oyun oynuyor ve sürekli bu şarkı çalıyor.
Çünkü oyun arasında reklam dinliyor sürekli ve bu şarkı geliyor.
Bununla yatıyorum, bununla kalkıyorum.
Gerçekten. Trendyol reklamları her yerde.
Peki para aldın mı burayı?
Ben burayı indirmeyiz ondan da emin değilim.
Burayı yayınlayacağız.
Okey. Gerçekten var yani.
İlk ay gönderiyorum bu kaydı ve yavaştan kapatıyoruz.
Çok teşekkürler tekrar. Ben teşekkür ederim.
Dinleyicilerimize de iyi günler diliyoruz ve hoşçakalın.
Hoşçakalın.
Bu transkript otomatik olarak çıkarıldı; kayıtla küçük farklar olabilir.