Konuklar: Ahmet Hatipoğlu, Göksel Küçükşahin, Halime Eda Kaçmaz, Sıla Çınar
93. bölümümüzde konuğumuz CRM ekibi oldu. Ekip yapısını, projelerini, teknoloji stack seçimlerini ve çok daha fazlasını konuştuk! Trendyol Talks'da Trendyol'daki kültürümüzü, kültürümüzden beslenen iş yapış biçimlerimizi ve ritüellerimizi konuşuyoruz. Trendyol Talks podcast kanalımızı takip etmeyi unutmayın!
Transkript
Selam ekip, ben Collection Favorites ekibinden Kübra.
Ben Storefront Web Search ekibinden Cengiz.
Ben de Seller Order Experience ekibinden Fatiha.
Teknoloji ekiplerini tanıdığımız ve süreçler, teknolojiler gibi konuları konuştuğumuz Selam Ekip Podcast serisinin 93.
bölümünde CRM ekibiyle birlikteyiz.
Bu ekibi tanıyıp, ekip yapısı, kullanılan teknolojiler, pratikler gibi konuları konuşacağız.
Öncelikle hoş geldiniz arkadaşlar.
Nasılsınız? İyiyiz, teşekkürler.
Teşekkürler. Böyle şeyle başlayalım çok, ısınalım.
Küçük sorularımızdan başlayalım.
Kendinizi bize kısaca tanıtabilir misiniz?
Kaç yıldır Trendyol'dasınız?
Kaç yıldır sektördesiniz?
Neler yapıyorsunuz? Tabii, ben başlayayım.
Merhabalar, ben Göksek Çuşay'ın.
27 yaşındayım. CRM yani Catalog Rule Management ekibinde bir buçuk yıldır backend engineer olarak çalışmaktayım.
Geçtiğimiz yılda da sektördeki dört buçukuncu yılımı tanıdım.
Neredeyse beş yıl olacak bu yılın sonunda.
Ben de sözü bir sonraki akşam arkadayım.
O zaman sözü ben alayım.
Merhabalar, ben Eda.
29 yaşındayım, yaklaşık 6 yıldır sektördeyim.
Bu trend yoldaki 4.
yılım. Catalog Rule Management ekibinde Developer in Test olarak çalışıyorum.
Ekipteki de yaklaşık 1 yıl doldu geçtiğimiz ay diyebilirim.
Ben de sözü yine başka bir arkadaşıma bırakayım.
Selam, ben Ahmet.
30 yaşındayım.
Yaklaşık 6,5-7 yıldır sektördeyim.
4,5 yıldır tren yoldayım.
Bekan İnjeneri olarak görev alıyorum.
İlk 2 yıl içerisinde Product Detail Page ekibinde çalıştım.
Örün Detay sayfasında. Sonrasında Inventory ekibine, rotasyona geçtim.
Kısa bir süre sonra da Catalog Room Management ekibine geçtim.
Catalog Room Management ekibinde yaklaşık 2 ya da 1,5 yıldır çalışıyorum.
Göksel'le, Eda'yla, Sıla'yla birlikte.
Topo Sıla'yı atabilirim en son.
Selamlar, ben de Sıla.
5 aydır CRM yani Catalog Rule Management ekibindeyim.
Yaşımı söylemiyorum. Yaklaşık şöyle söyleyebilirim, 8 yıldır sektördeyim.
Catalog Tribe'ına da 1 seneden biraz fazla bir süredir rotate oldum.
Onun öncesinde Haziran 2023'te girdim Trendyol'a.
Onun öncesinde de Stellar Engagement ekibi altında Q&A ekibinde çalışıyordum.
Benden de bu kadar. Hepiniz tanıttınız galiba.
Güzel. Sizleri tanıdık.
Şimdi biraz ekibinizi tanıyalım.
Catalog Rule Management takımı tam olarak Trendyol'da ne yapıyor?
Sorumlulukları nelerdir? Bahseder misiniz?
Ben başlayayım. Catalog Rule Management ekibi kısa olarak CRM.
CRM deyince de insanlar böyle Customer Relation gibi düşünüyor ama aslında öyle değil.
Catalog Rule Management gerçekten.
Aslında ana olarak 3 tane bacağı var.
Bir tanesi Lookup, diğeri Eligibility dediğimiz akışlar ve bir de Label.
Ben Lookup tarafından bahsediyor olacağım.
Genel olarak e-ticarette katalog dediğimiz bazen ürün koleksiyonu gibi anlaşılabilir.
Genel olarak e-ticaret sitelerinde bu ürün koleksiyonları belli kurallara göre açılıp kapanabilir.
İstediğiniz ürünü sunmak istersiniz ama belli kategorinin altında olsun, belli olgunlukta olsun ki satışa çıksın.
Lookup tarafı şununla ilgileniyor.
Diyelim ki siz bir satıcısınız, o platformda bir ürün satmak istiyorsunuz.
Diyelim ki tişört satmak istiyorsunuz.
Ürünün kategorisi nedir ilk olarak?
Tişörtür diyelim. Tişörtün üründen bağımsız herhangi bir tişörtü düşünürsek eğer, tişörtün özellikleri olur.
Ne gibi özellikleri olur?
Fiziksel özellikleri olur, rengi olur, bedeni olur, yaka tipi olur, kumaş tipi gibi şeyler olur.
Farklı kategori düşünürsek eğer hani buzdolabı mesela onun enerji sınıfı olur, no frost mu, statik mi, hac mi gibi farklı farklı özellikler.
Bu özellikler aslında kategoriye ait özellikler, üründen bağımsız.
Bunlara biz lokak diyoruz aslında yani ürün açılmadan önce hangi özelliklerle nasıl açılacağına dair belirleyen kurallar gibi.
Bu özelliklerinde de aynı zamanda değerleri olur deriz biz.
Değerler dediğimiz zaman hani bedenin small, medium'u, large'ı, x large gibi şeyler dediğim gibi.
Bunlarda da aslında bir relation, büyük relation tablosu oluşturur bizde.
Kategori, kategorinin atribütleri de özellikleri dediğimizde.
Özelliklerinde de değerleri de olur.
Bunları birlikte hani tek düşündüğümüz zaman Bir katalog ruhlu oluşturur aslında.
Bu katalog, bu ürünlerin hangi kurallara göre açılıp kapandığına dair bir kuralların seti gibi düşünebiliriz.
Genel olarak bunlar aslında ülkeden ülkede de değişiklik gösterebilir.
Mesela bazı ülkelerde XL satmak istemeyiz.
O yüzden spesifik ülkedeki katalogdaki değer yani XL değerini kaldırıyoruz.
Bazı ülkelerde de izin veriyoruz gibi.
Bu da işte 175 milyon.
Relation oluşturuyor da tabi izliğimizde.
Bu da Lukap tarafı olur.
Legal Rule tarafına da bir göksele topu atayım.
Teşekkür ederim Ahmet Lukap tarafını paylaştığın için.
Ben de Legal Rule, International Eligibility ve Coefficient Rate tanımlarından biraz bahsedeceğim.
Aslında bunlar gibi birkaç tane daha rulemuz var ama.
Konuyu uzatmak adına ben 3'ünden bahsetmek istiyorum daha çok.
Bunlar nedir? Tren yolunu biliyorsunuz ki aslında ana olduğu bölge Türkiye ve ürünlerimizi aslında Türkiye'den satıyoruz.
Ama yakın zamanda şey geçtik, yaklaşık 3-4 yıldır yurt dışına satış yapıyoruz.
Ve bu yaptığımız satışları işte mikroeksport olsun, first party satışlar olsun farklı kanallardan yürütebiliyoruz.
Ve birden fazla ülkemiz var sattığımız.
Legal rule aslında kısaca şudur.
Bir Türkiye'de satılan bir ürünün başka hangi diğer ülkelerde satılabilirliğini, legalitesini belirlediğimiz bir kural.
Bu kural nasıl çalışıyor? Kategori, marka ve satıcı üzerinden biz bu kuralları işleterek hangi kategorideki, hangi markanın, hangi satıcının, hangi diğer storefront yani ülkelere satılabildiğini
belirttiğimiz aslında bir doküman.
Bu dokümanın niçin ihtiyacımız var?
Neden böyle bir kural işletiyoruz?
Bunun da aslında asetlerinden bir tanesi şu.
Her ülkenin farklı regulasyonları, yasal süreçleri ve ürünlükleri var.
Bunlara uyum sağlamak, veteran yolun bunlardan zarar görmeden ilerleyebilmesi için işlettiğimiz aslında bir kural ve şeyi de belirliyoruz bu sayede.
Satılabilir ürünlerin, atıyorum karlılığı yüksek ürünleri belli ülkeye satmak isteyebiliriz veya belli ürün gruplarını belli ülkelerde satmanın yasal olarak sıkıntı olabilir, gümrükten geçmeyebilir.
En örnek verebileceğim şey mesela kültürel sebepler.
Örnek mesela United Arab Emirates UAE'de mesela yılbaşı temalı ve Christmas temalı ürünlerin satması mesela yasak.
Bu yüzden herhangi bir üzerinde çam ağacı, Noel Baba, motifleri olan bir tişörtü satamıyoruz.
Bunun gibi kurallara yönettiğimiz aslında kural diyebilirim.
LGBT'de kategori brand ve satıcı bazlı kıramadığımız ama ürünün üzerindeki işte başlık, açıklama, görsel, işte Ahmet'in biraz önce bahsettiği gibi look up üzerindeki özelliklerine verilen değerler gibi farklı sebeplerden
satışında engel ya da kısıtlama olabilir.
Bunları anlamak için de biz Quality Enrichment Service ve işte Media Service data center ekiplerinden yardım alıyoruz.
Ne yapıyoruz? Ürün üzerindeki işte bahsettiğim gibi açıklama başlık, görsel bilgilerini gönderip onlardan bu ürünün tamam satılabilir ama hakikaten başka bir görselinde sakıncalı bir şey var mı?
Veya bir engel oluşacak bir nokta var mı?
Gibisinden yollayıp onlardan alıp işletiyoruz.
Buna da eligibility diyoruz. Yani yasal olarak satılabilir olması sadece yeterli değil.
Aynı zamanda eligible olması da lazım.
Yani uygun da olması lazım. Son olarak bir de şeyden bahsedeyim.
Co-efficient rate'den bahsedeyim.
Aslında bu bizim kısaca fiyat çarpanımız diyebilirim.
Trendyol'un yurt dışına satıştaki karlılık, profesyonel ve lojistik maliyetlerini kapsayabilmesi için, bunları giderebilmesi için Türkiye'ye sattığı ürünün belli bir çarpanıyla yurt dışındaki ülkelere satıyoruz.
İşte buradaki ürünlerin çarpanların sayılarını biz bellemiyoruz ama işleten ekip biziz.
Buradan biziz tarafından gelen bu çarpan bilgilerini biz uygun kategori ve kontent üzerine yansıtmakla sorunluyuz.
Ben de bir sonraki madde olan...
Label için Sıla'ya söz vereyim.
Teşekkürler Göksel. Ben de label akışımızdan bahsedeyim.
Aslında label nedir? Ürünlere kupon veya promosyon tanımlanabilmesi için bu ürünleri gruplayan, onları aslında etiketleyen bir süreçten bahsediyoruz.
Burada business ekipleri bizim sağladığımız bu labellama işlemiyle tarih yani bu label'lara bir tarih vererek ve culture dediğimiz ülke bilgisiyle label oluşturup bu label'lar üzerinden grupladıkları
ürünleri örneğin mesela ne gibi bir şeyden bahsediyorum sepette x indirim gibi bir promosyona atayabiliyorlar.
Aslında bu bir label olmuş oluyor ürüne atalan.
Ön yüzde de sizler de yani bu ürünlerde sepette x indirim veya işte kargo bedava gibi bu label'ları görebiliyorsunuz.
Bizim içeride internal olarak kullandığımız PIM ekranları dediğimiz ekranlardan Excel üzerinden bu business ekipleri label'lara, ürünlere label ekleme işlemlerini yapabiliyorlar.
Biz bunu sağlıyoruz onlara.
Burası P1 seviyesi bir domain Trendyol içerisinde.
Yani P1 dediğimiz Priority One yani kritik seviyede bir domain.
Burada milyonlarca kontent etki eden operasyonlar yönetiliyor.
O yüzden buradaki scalable timiz bizim için önemli.
Bu kadar bahsedebilirim. Süper.
Valla yani aslında dolu dolu bir sorumluluk.
Birçok noktada noktaya parmak basıyorsunuz.
Bu baya güzel. Bu kadar çok yere ayrılması vesaire oldukça fazla sorumluluk da gerektiriyor.
Bu noktada ben şey sormak istiyorum.
Ekip dağılımı nasıl? Sizde yani sizin ekipte kaç developer var, kaç tester var?
Nasıl bir dağılım söz konusu burada?
Ekibimiz toplamda 6 kişiden oluşuyor.
Bir takım liderimiz, bir product managerımız var.
Development tarafında da bir devin test yani ben ve 3 developer arkadaş olarak çalışıyoruz.
Yani CRM ekibimiz bu şekilde oluşuyor.
Peki. Anladığım kadarıyla siz böyle bayağı ortada bir ekipsiniz.
Birçok ekiple beraber çalışıyorsunuz.
Benim eski ekibim de böyleydi.
Ve ekiplerle iletişim ve ortak çalışma biraz zor oluyor açıkçası.
Çok fazla ortada bir ekip olunca.
Siz bu süreci nasıl sağlıklı yürütüyorsunuz?
Aslında gerçekten bazen zor olabilir.
Günün sonunda da herkes belli işlerin peşine koşmaya çalışıyor.
İnsanların anlayış biçimi olsun ya da iletişim.
tarzı falan farklı olabilir.
Fakat günün sonunda da bence de benim gördüğüm kadarıyla Trendyol'da çalıştığım sürelerde ortak bir noktamız var hepimizin.
Ortak bir anlayış noktamız var.
O da hepimiz aynı müşteriye aynı değere sunmaya çalışıyoruz günün sonunda.
Aynı amacıyla çalışıyoruz.
Bir örnekten bahsedeyim.
Diyelim ki bir tane ekipte bir dependency'imiz var.
Belli bir ekipten belli bir data alıyoruz normalde.
Belli bir feature'ı da geliştirmeye çalışıyoruz biz de ve bu ekibe gidiyoruz.
Hani diyoruz ki böyle bir data'ya ihtiyacımız var.
Siz bunu bize ne zaman sağlarsınız?
Şimdi diğer ekipte de şu da diyebilir normalde de.
Şu an çok yoğunum.
Daha öncelik işlerim var.
Anca 2-3 hafta sonra analiz etmeye başlayabilirim.
Şimdi burada da aynı zamanda da hani...
Aynı müşteriye çalıştığımız için onu anlıyoruz ama yine de öncelik konusu da işe giriyor.
Bizde de şunu anlamamız lazım aslında.
Aynı zamanda her zaman birinci öncelikte de olamayız bir ekip olarak.
Diğer ekiplerin daha farklı öncelikleri de olabilir.
Biz ikinci öncelikte olabiliriz.
Genel itibariyle baktığınız zaman en ince ekip öncelikte olabiliriz.
Sonucu da en öncelikte de olabiliriz.
Böyle olduğunuzda ve bunu anladığımız noktada aslında biraz daha sağlıklı, biraz daha demeyeyim ama sağlıklı yürüyebiliyor.
Aynı amacada çalışıyoruz ekibimiz.
Ve mutavazı da olmamız gerekiyor aynı zamanda.
Bu şekilde çatışmaları yapıcı bir şekilde de yönetebiliriz aslında.
Ya da şunu diyebilirim. Mesela bir tane dependisimiz var o ekiple de.
Bu ekipte de şunu da anlayabiliyor aynı zamanda.
Bu son müşteriye bu değeri yaratabilmek için sadece benim çalışmam gerekmiyor da diğer ekiplerde de o loop'un içinde olması gerekiyor aynı zamanda.
Yani bu iki prensiple hem de müşteriye odaklı olma konusunda hem de mutavazı olma konusunda bu konular daha sağlıklı yürüyebiliyor diyebilirim.
Bir sonraki soru biraz benzer de ben biraz parafraz etmeye çalışıyorum bu soruyu.
Birçok ekip ledifandan çalışıyorsunuz.
Hem teknik hem biznes geliştirmelerde burada belirlediğiniz bir standartınız var mı?
İletişiminiz, genel olarak akışınız nasıl ilerliyor?
Bunu ben cevaplayabilirim. Aslında buradaki sürecimiz şu ilerliyor.
Eğer tek basit bir taskın ötesine geçip artık böyle 2-3 taskın ve 2-3 sprintin ötesine geçiyorsa artık yani bir etik seviyesine geldiyse genelde bu tip konuşmaları Slack üzerinden veya Zoom üzerine yapmak yerine ufak da olsa bir RFC açıp
buradan halletmeye çalışıyoruz.
Böylelikle RFC üzerinde işte API olsun, Kafka topikleri olsun, bunun gibi kontraktları el sıkışıp işte yaşanan ambigütleri burada belirsizlere giderebiliyoruz.
Bu doküman üzerinden gelen itiraz ve soruları da aynı şekilde tek bir yerde olduğu için Hani şey durumunu düşünmüyoruz.
Ya biz bu konuda aslında Zoom'da konuşmuştuk deyip kaybolmuyor.
Tek bir doküman üzerine tutuyoruz.
Güzel tarafta şu oluyor. Aradan zaman geçip o dokümanda ne yapıldığına bakıldığınız zaman da şeyi anlayabiliyoruz.
Geçmişte yapılan... işinde neler konuşulduğunu görebiliyoruz.
Bizans tarafı içinde aslında biraz daha şey gibi dolaylı bir iletişimimiz var.
Biz ekiplere doğrudan değil de PM arkadaşımız üzerine iletişim kuruyoruz.
Bizasından gelen istekler bize PM üzerinden veya bizim bizansı olan taleplerimize yine PM üzerinden iletişime geçip bu şekilde ilerliyoruz.
Ama her zaman böyle dolaylı olması da zaman kaybı yaratabiliyor.
Acil kritik bir problem olduğunu atıyorum.
Bizansın kullandığı kritik bir ekranda bir problem olduğunda veya acil bir ekleme çıkartma düzenleme gerektiği zaman Pandora üzerinde QA'yı aktif olarak kullanıyoruz.
Business keyifleri buradan bize hızlıca talep açıp, support ticket açıp bizim önümüze düşürebiliyor.
Bu açılan ticketler bizim özel ayrılmış bir site kanalımıza düşük.
Oradan öncelikli olarak nöbetçi arkadaşımızın önüne düşüyor.
Eğer onun müsait olmadığı veya destek istediği konuda biz de yardımcı oluyoruz.
Ama aslında öncelik burada genelde on call yani nöbetçi kişi de oluyor.
Genelde de bir günü geçmeden aynı gün içerisinde çözme çalışıyoruz buradaki istekleri.
Eğer şey durumu olursa da, hani oradaki problem hemen çözülecek bir şey olursa da geçici çözüm yapıp Kalıp çözüm için taslandırıyoruz.
Bu şekilde diyebilirim sürecimiz.
Süper. Peki biraz da şeyden bahsedelim arkadaşlar.
Aslında biraz böyle bahsettik, giriş yaptık ama daha detaylı dinlemek istiyorum.
Nasıl çalıştığınızdan bize bahsedebilir misiniz?
Yani CRM ekibi... Nasıl çalışıyor?
Daily sprintler mesela. Nasıl ilerletiyorsunuz?
Diğer toplantılarınız nasıl ilerliyor?
Nasıl bir akışınız var burada?
Tabii ben anlatayım. Biz haftalık sprint koşuyoruz.
Sabahları 8.45 daily'imiz var.
Akşamları da genelde ofis günleri haricinde kapanış daily'si yapıyoruz.
Daily denir mi bilmiyorum. Kapanış daily'si yapıyoruz.
Genelde sabahları update'lerimizi konuşuyoruz.
Akşam mayıs'a hani bir blocker işimiz var mı?
Ya da hani gün içerisinde zaman bulamadığımız bir konu var mı?
Veya destek beklediğimiz bir konu.
Onları dile getirmek. için tekrar updateleşiyoruz.
Onun dışında haftalık groomingimiz, planningimiz, retromuz bunlar klasik olarak yapıyoruz.
Groominglerde PM ile beraber taskanın üzerinden geçiyoruz.
Puanlıyoruz. Daha sonra planningde de haftalık kaç puan iş alacağımızı da genelde bir önceki haftaların metriklerine bakarak Haftadan haftaya değişiklikler göstererek planlıyoruz diyebilirim.
Bir tane kod review süreci nasıl akıtıyoruz?
Ondan bahsedeyim ki CRM PR kanalımız var.
Bu kanaldan kod review'larımızı paylaşıyoruz.
Altına hepimiz mutlaka komentlerimizi giriyoruz.
Burada asinkilerliyoruz. Burada da zaten amaç OKR hedeflerimizden biri kod review süremizi kısaltmak.
Buraya da özen gösteriyoruz diyebilirim.
Onun dışında takım bazlı 3 aylık periyotlar için hedefler belirliyoruz.
Ve bu hedeflerdeki ilerlemeyi takip etmek için aylıkta OKR toplantılarında bu hedefleri değerlendiriyoruz diyebilirim.
Ağzına sağlık Sıla.
Peki bu yoğunluğun içinde ben böyle kalabalık bir domen olduğunu anladım bu anlattıklarınızdan.
Bunlar için hangi teknolojileri kullanıyorsunuz?
Tekstilinizde neler var hem back-end, front-end ve test tarifi için özellikle?
Bunu da ben cevaplayabilirim.
TechStack'imiz aslında ekibimizin sorumlulukları kadar aslında çeşitli diyebilirim.
Backend tarafında ağırlıklı olarak Go ve JVM dillerinden Java ve Kotlin tercih ediyoruz.
Ama daha önce yazılmış veya bize bir şekilde...
Diğer ekiplerden gelen işte Python'dır, Node.js'tir uygulamalarımız da var.
Ama ağırlıklı olarak yine yapıldığımız uygulamaları Go veya Kotlin üzerine yazmaya özen gösteriyoruz.
Database tarafında ise Trendyol'un genelinde olduğu gibi bizde de Couchbase yoğunluklu bir kullanım mevcut.
Ama buradaki kullanımlarımızı artık yavaş yavaş Postgres SQL'e kaydemeye çalışıyoruz her geçen gün.
Yeni açtığımız DB'leri de olabildikçe Postgres üzerinde kurguluyoruz.
Mikro servislerimizi event driven mimari olarak tasarlıyoruz.
Bu event driven mimari kullandığımız event broker'ımızı da genelde Trendyol'un genelde kullandığı gibi Kafka'yı tercih ediyoruz.
Kafka'nın sayesinde aslında birazcık daha yatayda scale'imizi maksimize edebiliyoruz.
Son olarak şeyden bahsedebilirim.
Frontend tarafında ne kullanıyoruz?
Bizim aslında ağırlık olarak backend tarafında iş yapmamıza rağmen biziz ekipleri ve diğer ekiplerin kullandığı Trendyol içerisinde kullanılan bazı ekranlarımız var.
Pim ve... Lookup adını verdiğimiz iki arayüzümüz var.
Bunlardaki ekranları geliştirmek için React ve Vue.js'den yardım alıyoruz.
Buradaki geliştirmeleri aramızda fark ettiyseniz bir frontend engineer arkadaşımız yok.
Bir AI yardımıyla genelde bizler yürütüyoruz ve test ediyoruz.
Dışı açılmayan ufak ekranlar olduğu için de genelde bizi kurtarıyor diyebilirim.
Test tarafını anlatması için Eda'ya söz verebilirim.
Teşekkür ederim Göksel.
Ben de CRM tarafının test kısmını özetleyecek olursam biz CRM tarafında aslında mümkün olduğunca test süreçlerini otomatize etmeye çalışıyoruz.
Hatta definition of'dan maddelerimizden bir tanesi de test otomasyon yazılması ve her sprint mutlaka otomasyonsuz iş ilerletmemeye çalışıyoruz.
Onun haricinde ağırlıklı olarak API testlerimiz bulunuyor.
Her bir app içinde ayrı test projemiz var.
Yani biz aslında acceptance testlerimizi ana projede değil de ayrı birer projede tutuyoruz.
Acceptance testlerimizi Java ya da Kotlin'le yazıyoruz.
REST Assured Library'sini kullanıyoruz.
Aynı zamanda biz testlerimizi koşarken servislerimizi bir konteyner içinde ayağa kaldırıyoruz ve izole bir ortamda...
testleri koşuyoruz.
Bunun için de aslında GATEC adını verdiğimiz internal bir tool'umuz var.
Bu zaten Trendyol genelinde de kullanılan bir tool, yaygın bir tool.
Burada her test koşumunda izole bir ortam oluşturmamıza imkan sağlıyor ve her seferinde temiz bir başlangıç yapıyoruz.
Datamız da temiz oluyor ve testlerimiz daha stabil oluyor.
Başka ortamlardaki kirli datalara maruz kalmıyoruz.
Onun haricinde external API'ler için YMOG kullanıyoruz.
Yine Acceptance test coverage'larımızı da ölçüyoruz.
Bunun için de Go projelerinde Goch, Java Kotlin projelerinde Jacoco kullanıyoruz.
Yine aylık koştuğumuz performans testlerimiz var.
Kontrakt testlerimiz, mutation testlerimiz.
Bunlar için yine ortak bir tool kullanıyoruz.
Ares adını verdiğimiz. Bu da yine Trendyol genelinde kullanılan bir tool.
Biz de bu süreçleri aslında oradan takip ediyoruz diyebilirim.
Güzel, teksteğinizi tanımış olduk.
Şimdi biraz da observability'den bahsedelim.
Alert mekanizmalarında neler var genel olarak?
İncident oluştuğu zaman önceden nasıl haberdar oluyorsunuz?
Ya da güzel bir incident örneğiniz varsa bizimle paylaşabilir misiniz?
Ben bahsedeyim. Monitoring tool'ları olarak biz yine Gravify'ın aydaşı bordlarını takip ediyoruz bir holder üzerinden.
Neleri takip ediyoruz? İşte Application Performance, Cluster ve Kafka metrikleri, CPU, Memory gibi Resource metrikleri.
Bu metrikler üzerinden de alert tanımlamaları yapıyoruz.
Yani ek olarak nivrelik kullanıyoruz.
Yani zaten Trendyol genelinde de kullanılıyor.
Ancak şu anda Trendyol'da bir internal tool geliştirildi mergen diye.
Hepimiz bu tool'a geçmeye çalışıyoruz zaten tam olarak da bu dönemde.
Tüm alertlarımızı da bu mergene geçiş yaparak nivrelikten egzit etmiş olacağız.
Quarter sonunda diye umuyorum.
Ne yapıyoruz? Yani aslında Slack'te...
Tanınmadığımız alarm kanalları üzerinden bu platformlardan gelen alarmlar sayesinde alert oluyoruz.
On-call mekanizmamız, biz günlük on-call oluyoruz.
Ekipteki herkes, işte developerlar, R2QA, Devin Test arkadaşımızla beraber.
Bu ne gibi alert tiplerimiz var?
Örneğin Kafka Topic Leg Alertleri, CPU Memory Usage, Latency Alertleri, PodRit Start Alertleri dahil olmak üzere çeşitli alertlerimiz var.
On-calllarımız bu alertlere ilk responsif veren ve takip eden kişi.
oluyor genelde ama yani burada bütün ekip dahil olmaya çalışıyoruz.
Müdahale edebilecek bir durum ise anda müdahale ediyoruz.
Arkasından da yani ilk müdahalemiz yaptıktan sonra kök neden araştırması yapmaya başlıyoruz.
Veyahut da arkasından bir task açılması gerekiyorsa bu taskı açıp sprintte önceliklendirmeye çalışıyoruz.
Onun dışında da business metriklerle alakalı alertlerimiz de var.
Bunlardan da örnek vermek gerekirse translationları yapıyoruz biz tüm lookup datamızın.
Bunlar için translation Missing alertlerimiz var.
Veya işte ürünlerin LGBT'sini hesapladığımız durumda statue not processed gibi alertlerimiz var.
Böyle durumlarda da yine ekipçe alert oluyoruz diyebilirim.
Şöyle bir incident'tan bahsedeyim ben.
Geçen biz yemeğe çıktık Göksel Kerem'le.
Yanımıza da bilgisayar almadık aslında da.
Öyle çıktık hani 30 dakikalıktan bir şey olmaz diye.
Çıktık dışarıya yemek yerken de bir tane alert geldi.
Alert de label ile ilgili. Şimdi label aslında genel olarak promosyonları, kuponları direkt etkilediği için bizim genel olarak bir KBT yani Key Business Transaction olarak tanımladığımız alertlerimiz var.
30 dakika içerisinde bir tane label tanımlanırsa aslında can hani son müşteriye Trendyol.com'a da yansıması gerekiyor gibi bir threshold'umuz var.
Ona karşılayamadığı zaman alert oluşuyor.
Niye bu kadar sıkı tutuyoruz bunları?
Şeyden dolayı bir tane label tanımlandığında aslında direkt promosyona yansıması gerekiyor.
Para kaybına yol açabilir.
Satıcılar tanımlamaya çalışıyor ama hemen yansımıyor gibi problemler.
Label problemi geldi. Aslında Kafka alerti geldi.
Yani 10 milyon bir lag oluşmuş sanırım yanlış hatırlamıyorsam.
Bu 10 milyon lag de birikmiş 30 dakika boyunca eritemediğimiz için.
Geldi bize. Bir baktık telefonlara.
Label geliyor. Label'lar genelde hani priority olarak P1, P2, P3, P4 dediğimiz alertler sınıfları var da bizim.
Label baya bir P0 falan normalde yani.
Kerem'le çıktık.
Bir şey dedik.
Tamam biz buna bakmamız lazım.
Burger'imi bitirelim. Hemen mi dönelim?
Bir hemen dönelim dedik.
Böyle ben aldım burger'i.
Burger elimde durdu.
Kerem'in burger'i de elinde duruyor.
Geri kalanları Göksel'e de paket aldırdık falan.
Ondan sonra biz çıktık.
Böyle yürüyoruz ofise doğru.
Ben de burger yiyorum falan.
Kerem'le de burger yiyor ofise doğru yürüyoruz.
Ofise gelene kadar aslında leger imiş.
Bir sıkıntı yok.
Business as usual. Her şey güzel.
İlerliyor. Yine de günün sonunda hani bunların root cause'unu bulmamız lazım.
Bir daha tekrarlanır mı?
Yani bilemezsiniz belki de işte CPU'lar çok kötü, memurlar çok kötü, lag eriyemiyor, bir daha yaşanabilir.
Oturup çözmeye başladık.
Bir iki üç saatimiz aldı.
Root cause'unu bulduk, çözdük aslında.
Sistemsel olarak genel olarak RCA formu falan da tanımlıyoruz sisteme.
İşte action point'lara da girmeye çalışıyoruz.
Saat vesaire tutmaya da çalışıyoruz.
Ne zaman yaşandı? Ne zaman mitigate ettik?
Bazı metrikleri de takip ediyoruz bunlarla ilgili.
Mean time to close, mean time to resolve, mean time to mitigate gibi.
Mitigate aslında problemi daha...
Şimdi biraz ateşi söndürdük biraz.
Resolve artık bir daha bugün içinde yaşanmaz ama belki de tekrar yaşanabilir başka günde ya da şu an düzeldi gibi şimdilik.
Meantime to close'da kalıcı aksiyon alana kadar ne kadar sürdü?
Geometriklerle takip edilir sistemde.
Bizim in-house'da tasarlanan bir incident takip mekanizması ile bunları takip ediyoruz aslında.
Genel olarak priority'ye göre aslında bunlar önceliklendiriliyor.
P4 bir incident yaşanırsa belki...
Bir hafta daha bekler, iki hafta daha bekler close edene kadar.
Ama P1, P0 gibi bir incident yaşanırsa belki de scope creeple bir iş çıkarıp hemen kalıcı aksiyonu alıyoruz.
Belki de bir sonraki sprintte de bekleyebilir diyebilirim.
Valla geçmiş olsun Ahmet.
Özellikle bu incidentta burger yediğiniz kısma.
Özellikle bu. Valla yani gerçekten böyle ne zaman geleceği de belli olmayan şeyler oluyor.
Bizim de çok yaşadığımız şey var yani.
Böyle işte ne bileyim öğle arasında yemeğe gitmişiz olabiliyor.
İşte akşam... Gece bizim tabii şey yani biz client ekibi olduğumuz için gece alertleri bizde çok fazla var.
Dolayısıyla böyle gecenin üçünde bir gözün açık uyanınca ne oluyor falan diye anlamam birazcık zaman alıyor.
Tabii yani incident'ın hiçbir türlüsü keyifli değildir ama güzel bir hikayeymiş.
Tekrar geçmiş olsun diyelim.
Süper. Şimdi ufak ufak biraz daha şeylerden bahsedelim istiyorum.
İşte başka projeler, yeni projeler işte buradaki işte re-performing, onboarding vesaire falan bunlardan bahsedelim.
Öncelikle şeyi sormak istiyorum.
Siz yeni projeler geldiğinde veya bir replatforming ihtiyacı doğduğunda nasıl ilerliyorsunuz?
Burada ilk olarak tabii ki bir analiz sürecimiz oluyor.
Ekipten bir arkadaşımız bu süreci drive eden kişi oluyor.
Yani sürecin driverı oluyor. Bu analizi üstleniyor.
Ancak tüm ekip mutlaka biz de bir ucundan dahil oluyoruz.
Genelde RFC dokümanı üzerinden ilerliyoruz.
Takınca yine komentlerimizi bu doküman üzerinden...
Biz çok fazla cross team çalıştığımız için özellikle tribe içerisindeki farklı ekiplerle SPI gibi, QC gibi, listing gibi mutlaka bu RFC üzerinden onlar da yorumlarına giriyorlar ilgili
oldukları kısımlara. Ortak Slack kanallarımız, collaboration kanallarımızdan bu RFC'yi paylaşıyoruz ve karşılıklı yine asing bir şekilde süreci ilerletiyoruz.
Gerekli gördüğümüz noktalarda discussion sessionları yapıyoruz.
Bazen hani kendi içimizde veya işte dediğim gibi yine diğer ekiplerle birlikte.
Özellikle büyük teknik mimari kararların alınması gereken durumlarda brainstorm sessionlarında bu konuları değerlendiriyoruz.
Burada metrikleri çok önemsiyoruz.
Yani yaptığımız bir platforming.
Sonucunda ne bekliyor ne gibi bir iyileşme bekliyoruz ne bekliyoruz öncesinde ne durumdayız gibi dataları mutlaka konuşuyoruz.
Neden bu işe girişmeliyiz gerçekten belirlediğimiz süre işte harcayacağımız efor bu işin getirisine değer mi gibi değerlendirmeler yapıyoruz.
Deployment tarafından da bahsedebilirim ben aslında.
Yeni projelerde de aslında daha klantımız yok.
Deployment'lar, rollout'lar kolay olabilir.
Yani sistemi biz rollout ediyoruz hemen.
Sonrasında client'lar entegre oluyor.
Kompleksitesi yok o tarafın ama her platforminglerin kompleksitesi yüksek.
Onun nedeni de canlı olarak hali hazırda client'lar bağlanıyor bize.
Aynı zamanda da client'lar bağlanıyor bize sürekli ve biz downtime yaşatmıyor olmamız lazım.
Hiçbir şekilde client'lar etkilenmiyor olmamız lazım.
Hatta da bazen haberi de olmayabilir bizim platformingden yaptığımız.
Dolayısıyla bazı prensiplere göre hareket ediyoruz.
Onlar da şöyle, biz analizi yaptıktan sonra tasklandırıp o analizi implementasyona başlamadan önce de ya da implementasyonla birlikte yürüttüğümüz bir rollout ve rollback planlarımız hazır oluyor.
Amacımız genel olarak şu, her şeyi bitirdikten sonra implementasyon açısından biz nasıl rollout etmemiz lazım?
Client'ları hiç sıkıntı yaşatmadan, downtime yaşatmadan nasıl rollout edebiliriz?
Adım adım bunları bir liste halinde yazıyoruz ve bunları takip ediyoruz aslında deploy ettiğimiz zamanda da.
Teknik olarak da shadow sistemlerde de kurmaya çalışıyoruz.
Eski sistem yeni sistemle birlikte aynı anda yürüyecek şekilde de deploy ediyoruz.
Ondan sonra trafiği belki eski sistemden yeni sisteme yavaş yavaş yüllendirerek de ilerleyebiliriz.
Bazen pat diye de geçirebiliriz.
Duruma göre, değerlendirdiğimiz duruma göre feature flaglerimizde de mutlaka hazır oluyor.
Hızlıca clientları eski sistemden yeni sisteme ve rollback gerektiğinde de Yeni sistemden eski sisteme switch edebilmek için.
Ve bunları da test ediyoruz aslında staging ortamında production'a çıkmadan.
Yani biz staging ortamında da rollout yaptığımızda da prod'da yapacakmışız gibi de yapıyoruz.
Sonra olası bir sıkıntı yaşarsak nasıl rollback etmemiz gerekiyor?
Stage ortamında da rollback ediyoruz.
Bu şekilde biraz o deneyimi edindikten sonra artık production'a çıkmaya hazır bir yöne gelmiş oluyoruz.
Güzel. Bayağı challenging bir replatforming süreçleriniz oluyor anladığım kadarıyla.
Peki ekibe yeni birisi katıldığında onu nasıl on-board ediyorsunuz?
Ben yanıtlayabilirim bunu da.
Ekibe yeni bir arkadaşımız katılacağı zaman kendisine bir body atanıyor.
Body on-boarding sürecinin asıl sorumlusu oluyor.
İşte anlatılacak konuları planlıyor.
İşte business, teknik konular, test süreci vs.
Ve süreci takip ediyor.
Aslında yeni katılan arkadaşın oryantasyonu sadece body'ye ait değil, ekipteki herkes bundan sorumlu oluyor.
Ve belirlenen yani herkes bu konuları paylaşıp yeni katılan arkadaşa bir session düzenliyor ve bir aktarım yapılıyor.
Bunun yanı sıra da teknik ve business dokumentasyonlarımızı da güncel tutmaya çalışıyoruz.
İşte sessionlarda kayıt almaya çalışıyoruz.
Aldığımız kayıtları drive'a yüklemeye çalışıyoruz sonradan da bakabilmek için.
Ve oryantasyon sürecini...
Şimdi Payer olarak ilerlemeye de çalışıyoruz.
Payer çalıştıkça çünkü aslında yeni katılan arkadaşımız sadece teorik bilgiyle kalmıyor.
Direkt iş akışının içine giriyor.
Yani ekran onda oluyor, klavye onda oluyor ve aslında direkt hani işin içine atlamış oluyor.
Böylelikle hem adaptasyonu hızlanıyor hem de onboarding aslında ekip içinde paylaşılmış oluyor diyebilirim.
Güzelmiş valla yani bizim ekiplerde de bu yapılan bir durum.
Yapılan bir süreç. Böyle şey örneğine benzetiyorum.
Ruslarda bebekleri direkt soğuk suyun içine atma örneğine benzetiyorum.
Aslında çok da işe yarayan bir şey.
Çünkü mesela bizim şeylerde de bu çok fazla oluyor.
Yeni bir takıma geçtiğin zaman, rotasyon aldığın zaman o alışma sürecinde kesinlikle ufak tefek de olsa işler verilip işte code base'i öğrenmesi, süreçleri öğrenmesi önemli.
Yeni katılan arkadaşlarım.
İşte ne bileyim deploymentlar nasıl yapıyor falan filan.
Bunlar da önemli.
Diploymentlar demişken şeyi de biraz sormak istiyorum.
Burada deployment süreçleriniz sizin nasıl ilerliyor?
Hani sık sık deployment çıkıyor musunuz?
Süreçte neler yapıyorsunuz?
Neleri takip ediyorsunuz?
Diployment süreçlerinizden de birazcık bahsedelim.
Bunu da ben cevaplayabilirim. Yani deployment sürecimizi genelde şöyle yürütüyoruz.
Çoğu ekibin aksine aslında bizim...
süreçlerimiz geliştirmeyi yapan kişi tarafından yürütülüyor.
Bunun da ana sebeplerinden bir tanesi genelde bizim işlerimizde tek bir kod çıkmak yerine config gibi feature flag gibi ekstra adımlar da olabiliyor.
Veya database üzerinde ekstradan field veya table açılması veya güncellemesi gerekebiliyor.
Bu durumları daha iyi yönetmek için genelde geliştirmeyi yapan kişinin deployment sürecinde olmasını istiyoruz.
Ama eğer bu süreç çok kritik ve riskli bir süreç ise genelde bir rollback planı ve bir deployment planı ile yola çıkıyoruz.
Ve en azından bir kişi payer alarak ilerliyoruz ki olası hataları, human errorları minimize etmek için.
Diploma sürecimizi ve sıklığımızı şöyle açıklayabilirim.
Genelde bu cycle time'larımızı ve for key metiklerimizi her sprint sonundaki ertesi gün Sabah saatlerinde değil sonrasında ufak bir 10-15 dakikalık toplantıyla bunları konuşuyoruz ve takip ediyoruz.
Olası bir sprintteki gecikme, önceki sprintteki gecikmeleri daha retroya bile gelmeden orada konuşup ya burada biz neyi yanlış yaptık, burada daha neyi iyileştirebiliriz gibi noktaları sprintin hemen sonunda konuşup bir sonraki sprintte
ona göre belki aksiyon almaya çalışıyoruz.
Bunun haricinde şeyi söyleyebilirim hani sıklığımız kaç dersek işte son baktığımda Founder üzerinden ortalama günlük 3.3 deployment alan bir ekibiz.
Şey diyebilirim. Trend yol ortalamasının biraz üzerinde deployment alan bir ekibiz diyebilirim.
Güzel. Deployment frequency'niz baya yüksekmiş.
Elinize sağlık. Peki aksikler her zaman yaşanabiliyor.
Zaten hayatımızın bir parçası ama önemli olan buradan bir ders çıkarmamız, tecrübe edinmemiz.
Bunun da genelde yolu verimli retro toplantıları.
Sizin ekibinizdeki retro toplantılar nasıl geçiyor?
Yani CRM ekibi olarak aslında retrolarımızın çok verimli geçtiğini söyleyebilirim.
Zaten retroları düzenli olarak yapıyoruz.
Genellikle her sprint sonuna denk getirmeye çalışıyoruz.
Çıkardığımız aksiyon maddelerini de sonraki retrolarda da takip ediyoruz.
Neleri tamamladık, neler halen devam ediyor şeklinde.
Böylelikle hem hataların tekrarlanmasını önlüyoruz hem de bireysel ve ekip olarak kendimizi geliştiriyoruz.
Biraz önce Göksel de biraz değindi.
Yani sprint boyunca nerede hata yaptık?
Neyi iyi yaptık? Neyi daha iyi yapabilirdik?
Hiç çekinmeden konuşabiliyoruz.
Bunu retro boardumuza yazabiliyoruz.
Ve aslında aksiyon maddelerimizle birlikte learningler de çıkarıyoruz.
Sonraki tecrübelerimiz için ışık tutuyor bize.
Yani o açıdan retrolarımız oldukça verimli geçiyor diyebilirim.
Süper, süper. Retro konusu da çok önemli.
Buradan da ufak bir reklam da yapmış olalım Trendyol içindeki arkadaşlara.
Grubu diye bir tool'umuz var.
İçinde de retro özelliğimizi de ekledik.
Oldukça da güzel bir tool arkadaşlar.
Size de tavsiye ederim.
Araya bir reklam sıkıştırayım dedim.
Süper. Yavaş yavaş artık bölümümüzün sonuna geliyoruz.
Çok keyifli bir sohbetti.
Son sorumuzu da soralım.
Ondan sonra ufaktan kapanışımızı yapalım.
Her ekibe sorduğumuz klasik bir soru var.
Sizler CRM ekibi ekip iletişimini geliştirmek için Neler yapıyorsunuz?
Bizim araba sevdalısı arkadaşlarımız var.
Bilardoca arkadaşlarımız var.
İşte oyunlara giden arkadaşlarımız var.
Tabii ki yemek muhabbeti en büyük kültürlerimizden biri.
Size de soralım hani burada iletişimi geliştirmek için neler yapıyorsunuz?
Yani biz tabii bir tren yolu klasiği olarak ekip buluşmaları düzenliyoruz İstanbul'da.
Ben bir tek ekipte İstanbul dışındayım, İzmir'deyim.
Onun dışında ekip zaten İstanbul'da bol bol görüşüyor ofiste.
Öğle araları burger yemeye gidiyorlarmış.
Onu öğrendim. Onun dışında böyle hani zaman bulabildikçe böyle gündemi değerlendirilmiş küçük sohbet sesyonları düzenliyoruz.
Hani biraz random yani bu planlı.
Hani oyuna falan maalesef zaman bulamıyoruz.
Ama şöyle bir örnek verebilirim.
Ben İstanbul'a gittiğimde yani öylesine hani şirket etkinliğine değil de kendi inisiyatifimle gittiğim zamanlarda ofise uğruyorum ve ekip mutlaka geliyor beni yalnız bırakmıyor.
Teşekkür ediyorum onlara. Öyle biz zaten ekip içinde iletişimi kuvvetli bir ekibiz.
Böyle olduğunu düşünüyorum.
Bu konuda bir sıkıntı çekmiyoruz.
Onun dışında da bu kadar diyebilirim.
Süper süper. Valla harika arkadaşlar.
Çok teşekkür ederim. Çok keyifli bir bölümdü.
Geldiğiniz için tekrar çok teşekkürler.
Biz de teşekkür ederiz. Teşekkür ederiz.
Süper. Teşekkür ederiz.
93. bölümde CRM ekibi konuğumuzdu.
Bir sonraki bölümde başka bir ekiple tekrar görüşmek üzere.
Bu transkript otomatik olarak çıkarıldı; kayıtla küçük farklar olabilir.