Konuklar: Gizay Eroğlu Tekin, Bedirhan Argün, İsa Mert Gürbüz
94. bölümümüzde konuğumuz StoreAds 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 Storefront Web Search ekibinden Cengiz.
Teknoloji ekibini tanıdığımız ve süreçler, teknolojiler gibi konuları konuştuğumuz Selam Ekip Podcast serisinin 94.
bölümündeyiz. Ve 94.
bölümde bu bölümde konuğumuz Store Ads ekibi oldu.
Store Ads ekibiyle beraberiz.
Bu ekibi tanıyıp ekip yapısı, kullanılan teknolojiler, pratikler gibi konuları konuşacağız.
Arkadaşlar hepiniz hoş geldiniz.
Selamlar. Süper.
Bugün yine harika bir ekiple beraberiz.
Bizim ETS ekiplerimiz bundan birkaç bölüm daha hani birkaç sonraki bölümlerde de ETS ekipleriyle, diğer ETS ekipleriyle yine bölümlerimiz olacak.
Daha öncesinde de ETS ekipleriyle bölümlerimiz oldu.
Bugün de Storex bizim konuğumuz.
Kısaca kendinizden bahsedebilir misiniz arkadaşlar?
Okey, başlayayım ben istiyorsan abi.
İsa ben. 5 seneyi geçkindir herhalde Trendyol'dayım.
Staff olarak çalışıyorum. Hatta daha önceden işte bahsettiğin ekiplerden birisi Product Ads.
O ekiple de çalışıyorum. Store ekibiyle de beraber çalışıyorum.
Geldiğimden beri de Ads ekiplerindeyim.
Bayağı bir bölündük falan.
Bir şeyler de oldu. Büyüdük.
İlk başta bir ekip vardı. Şimdi 5-6 ekipe kadar çıktık.
Bu şekilde... Ben de sözü diğer arkadaşlara bırakayım.
Selamlar herkese.
Ben Bedirhan. 28 yaşındayım.
Yaklaşık 5 yıldır Trendyol'dayım.
5 yıldır Ads ekiplerinde görev alıyorum ben de İsa gibi.
Şu anda Story Ads takımında Backend Developer olarak çalışıyorum.
Bu şekilde özetleyebilirim. Selamlar herkese.
Ben de yaklaşık 5 yıldır Trendyol'dayım.
Daha önce Storefront, PDP, WebMobil, Web ekiplerindeydim.
Yaklaşık 2,5 senedir de Ads takımlarına destek veriyorum.
Bu şekilde benlerle. Süper.
Teşekkür ederim. Hoş geldiniz.
Gizayla da biz daha öncesinde aynı ekipte çalışmıştık.
Hatta işte o ekipte de beraber podcast kaydetmiştik.
Bugün de Storex için beraberiz.
Valla açıkçası yani X ekipleri bizim Trendyol'da biz de client ekibi olduğumuz için aralarda oldukça sık sık.
karşılaştığımız ekiplerden oluyor.
Tabi işte şeyi ben çok fazla bilmiyorum aslında.
Ben de öğrenmiş olacağım. Dinleyenler de öğrenmiş olacak.
Hani Ets'in bu kadar ayrılıyor olması ve işte hangi Ets ekipleri falan.
Bunlar tabi birçok bölümde.
Başka başka bölümlerde de öğreneceğimiz bir şey.
Bugün Store Ets tarafını konuşacağız.
Şimdi ufaktan şeyle başlayalım isterseniz.
Store Ets yani isminden de birazcık belki anlaşılabilir ama Stores takımının Trendyol içerisindeki sorumluluğu tam olarak nedir?
Öncelikle Stores'in ne olduğundan bir bahsedeyim.
Stores, satıcıların reklam oluştururken seçtiği ürünlerin arama sayfasında satıcı bilgileriyle birlikte göründüğü bir reklam çözümümüz aslında.
Ek olarak satıcılar bu reklamlara banner ve video gibi görsel içerikler de ekleyebiliyorlar.
Ekibimiz ise bu reklamın yönetilmesi, harcamaların takibi, satıcılara reklam performansının gösterilmesi, yayına girmesi, yayından çıkması gibi konularla uçtan uca ilgileniyor.
Client olarak da 3 farklı platformdan sorumluyuz aslında burada.
Satıcı reklamları için web ve mobil desteğimiz var.
Mağaza reklamları için de web platformu ile hizmet veriyoruz.
Mağaza reklamları dediğimiz olguyu da hemen ufacık açıklayayım.
Aslında mağaza dediğimiz şey, brand reklamı.
reklamları dediğimiz şey Apple markasının altındaki TRO'ya reklam verebiliyor olması.
Seller reklamları dediğimiz şey de TRO'yun kendine reklam açabiliyor olması.
Bunlar için ayrı platformlarda hizmet veriyoruz.
Süper. Okey. Biraz daha şeyden aslında içerikten bahsedeceğiz tekrar.
Biraz da ekiple alakalı hani üzerine konuşalım istiyorum.
Şu an Store Ads ekibindeki ekip dağılımı nasıl?
Kaç developer var? Kaç desto var?
Nasıl bir dağılım var orada? Ekip 6 kişiden oluşuyor.
Bir takım lideri var. Bir product manager var.
Development tarafında da işte bir tane QA ve 5 tane developer arkadaşımız var.
Bir de ben staff olarak destek veriyorum bu ekibe.
Dediğim gibi Ads'de işte 5 tane falan ekip var.
Mesela daha önceden Burada yine Product Ads da çıktı galiba podcast'ta.
Onlara da çok benziyoruz.
Hatta ekiplerin ayrılması yakın zamanda oldu sayılır.
Yani bir seneyi geçkindir değil.
Süreç yanılıyorsam düzeltin beni.
Tarihler de pek önemli değil. Çok benziyor Ads içerisindeki ekipler.
Herkes bu büyüklükte.
Tabii gelen oluyor, giden oluyor vs.
ama amaç da birazcık şey zaten.
İş dağılımını doğru bir şekilde bölebilmek.
Bu ekiplerin bölünmesinin temelindeki sebep de o.
Business çok hızlı geliyor. Çok hızlı geldiği için bizim işleri hızlı bir şekilde deliver etmemiz lazım.
Bunu da yapabilmek için Workstream'le göre ekipleri bölüp doğru sayıda kişiyle oluşturup ecail bir takım kurmaya çalışıyoruz.
Ondan ötürü de AdSense'in içerisindeki bütün ekip arasından birbirine benziyor.
Storage'de bir istisna değil burada.
Bu şekilde bir süreç var.
Süper. Süper. Aslında yani baktığımız zaman böyle single domain içeren yani daha doğrusu hani tek amaca yönelik ekiplere baktığımızda şey anlamında iyi bir dağılım diyebiliriz.
Yani işte Beş Devleti özelinde konuşuyor.
İyi bir dağılım diyebiliriz.
Bence güzel bir sayı yani şey için, ekip için.
Bir de şey sormak istiyorum ekiple alakalı.
Hani bizim ads tarafında bildiğim kadarıyla çok fazla...
yan ekip var. Yani işte çalıştığınız çok fazla ekip var.
Çünkü client ekipleriyle yani ads birçok yerde reklam olabildiği için hani mobil tarafta da çalışıyorsunuzdur.
İşte web tarafıyla da çalışıyorsunuzdur.
Başka reklamın gösterildiği yerlerde falan.
Bu ekiplerle iletişim işte beraber ortak çalışma zor olmuyor mu sizin tarafta?
Bu süreci böyle Sağlıklı iyi bir biçimde nasıl yönetiyorsunuz?
Abi orada dediğin gibi biz Stolets ekibi olarak birçok farklı ekiple çalışıyoruz.
Ekipler arası iletişimde ilgili ekipte kurduğumuz ortak kanallarımız oluyor.
Bir sorun veya ekiple ilgili yapılan bir toplantı sonrasında da alınan kararları kanaldan yazılı bir biçimde iletmeye özen gösteriyoruz.
Bu sayede işte toplantıda alınan kararlar yazılı bir hale gelmiş oluyor.
Sonrasında oluşacak yanlış anlaşımlarının önüne geçmiş oluyoruz.
Ayrıca günlük olarak nöbet sistemimiz var.
O gün nöbetçi olan arkadaşımızda bir sorun olduğunda yine ya da soru sorulduğunda o kanallardan dönüş yapıyor.
Ekip içinde iletişimde yine gün içinde gelişen önemli konuları ekip kanalı içinden birbirimize duyuruyoruz aslında.
Bir de ets ekipleriyle iletişimimiz daha sıkı olmak zorunda tabii.
Aynı platformları ya da çok benzer platformları kullanıyoruz çünkü.
O yüzden Seder Ads altında da chapter yapısından faydalanıyoruz.
Ads altında chapter topluluklarımız var front-end, back-end test chapter olarak.
Düzenli olarak iki haftada bir toplanıp ekiplerden birer ikişer kişi chapter toplantılarına katılıyor.
Ve aslında teknik ya da tüm platformları, tüm Ads platformlarını etkileyen biznes işleri tartışıyoruz ve aslında parçalayıp back-end'lere götürüyoruz.
Ben burada şeyi biraz merak ediyorum aslında.
Çünkü bizim de bir iki defa başımıza geldi bu konu.
Mesela bir kanaldan bir şey yazılıyor ve bu yazılan şey birçok ekibi ilgilendiriyor.
Mesela bir iki defa şey olmuştu böyle versiyon update vesaire gibi konularda ekibin de bilgilenmesi lazım.
Ekibin işte bu şeyi görmesi lazım.
Ama bu kanalları takip etmeyen ekipler de olabiliyor ya da gözden kaçma gibi durumlar olabiliyor.
Böyle breaking şeyler olduğu zaman ya da önemli bir şey çıkılacağı zaman, önemli bir şey yapılacağı zaman falan şeyden nasıl emin oluyorsunuz?
Yani o kanalların takip edildiği ya da işte şey mekanizması var mı aslında biraz onu merak ediyorum.
Hani bizim bir fallback mekanizmamız var işte şu fallback mekanizması.
Hani işte bu olmazsa şu olabilir ya da hani burada önemli kontak...
Kurduğumuz insanlar var gidip onlara özellikle söylüyoruz falan dediğiniz bir yapı var mı?
Yoksa hani biz hani burada takip etmesi gereken sonuç da onlar diyerek buradaki sorumluluk iki taraflı değil.
Hani şey gibi aslında yani buradaki sorumluluk konsümördedir diyoruz burada.
Yani tabii öyle demek doğru olmaz.
Günün sonunda... Bizim biznesimiz, bizim sorumluluğumuz da şeyin ayrımını yapmak lazım birazcık belki hani iki türlü de dipende olduğumuz yer var.
Şimdi bir downstream bizim gönderdiğimiz şeyleri konsüm edenler var.
Bizim upstream olduğumuz veya başka upstreamlere gittiğimiz durumlar var.
Orası artık şeye göre değişiyor.
Nasıl diyeyim? İşin ne olduğuna göre değişiyor.
Bazen... Mesela bizim çok fazla yaşadığımız bir şey hatta Storefront'la falan da çalıştığımız durumlar oluyor.
Bu clientlerin event göndermeleri vs.
Bu eventler için iyi bir koordinasyon gerekiyor.
Çünkü bizim bütün consumption flow'umuz ve bütün dinlediğimiz ve satıcılara yansıttığımız harcamaların temel dayanağı bu eventlerin doğru atılması üzerine kurulu.
Burada da iyi bir iletişim kurmak gerekiyor.
Nasıl? İşte biz her türlü şey yapmaya çalışıyoruz.
Ekiplerle elayn olmaya çalışıyoruz. Kanallar var, kanallar üzerinden konuşuyoruz.
Kontaklar var, kontaklar üzerinden konuşuyoruz.
Bir değişiklik yapacağımız zaman herkesin elayn olduğundan emin olduktan sonra ilerletmeye çalışıyoruz.
Veya işte bu client ekiplerinin bizi elayn etmelerini istiyoruz herhangi bir değişiklikle beraber.
Bunun yanında değişiklikleri back-to-compatible yapmaya çalışıyoruz.
Gibi gibi yani duruma göre spesifik özel çözümler üretip ilerletiyoruz.
Silver Bullet yok yani burada maalesef keşfi olsaydı.
Çünkü zaten işin en zor kısmı da buradaki alignment'ı doğru sağlayabilmek.
Süper, süper. Yani zaten kesinlikle şeye katılıyorum.
Yani Silver Bullet muhabbetine kesinlikle katılıyorum.
Birçok ekipte fallback çözümleri de.
olması gerekiyor.
Çünkü yani bir şekilde çözülmüyor çoğu zaman.
Başka başka şeyler yapılması gerekebiliyor.
Bundan güzel pratikler çıkabiliyor açıkçası.
Sizdeki yapılan da gayet güzel.
Biraz şeyden bahsedelim o zaman.
Teknoloji tarafından da biraz bahsedelim.
Ekip olarak tek steyniniz nasıldır?
Hani böyle front end, back end test.
tarafından hangi teknolojileri kullanıyorsunuz?
Ben backend tarafından bahsedebilirim.
Backend tarafında aslında birçok farklı teknolojiyi kullanıyoruz.
Servislerimizde yine de Java, Node.js ve Golang kullanıyoruz.
Database tarafında ise NoSQL DB olarak Couchbase, Relational DB olarak da Postgre kullanıyoruz aslında.
Frontend tarafında da Brand Center'daki mikro app'imiz için Svent, Seller Center'da da React kullanıyoruz.
State Management Tool olarak MobX var orada.
App içinde şey var, React Native kullanıyoruz.
Süper. Biraz da aslında nasıl ilerliyor işler, ondan bahsedelim istiyorum.
Storex ekibi içerisinde nasıl çalışıyorsunuz, sprintleriniz nasıl ilerliyor?
Biraz bunlardan bahsedebilir misiniz?
Tabii bahsedelim.
İki haftalık sprintler koşuyoruz öncelikle onu belirteyim.
Daily'leri işte her sabah kısacık dün ne yaptık, herhangi bir problemimiz var mı, blocker var mı, çözemediğimiz bir sorun varsa yardım istiyoruz.
Daily sonunda hemen önceliklendirip konuşup o soruna çözüm iletiyoruz bir blocker varsa.
Her sprint sonu taskları analiz ediyoruz bir.
Bu sprint nasıl ilerledik, nerede takıldık, neyi daha iyi yapabilirdik.
Sprint analizlerini tamamlıyoruz.
İki haftada bir o toplantımız var.
Code review için de aslında takım kanallarını kullanıyoruz.
Developer'ların olduğu bir takım kanalımız var.
MR açtığımız anda işte oraya linkini atıp review istiyoruz.
Orası da hızlı ilerliyor. Mutlaka her gün review gelmiş oluyor.
Gündelik olarak takip ediyoruz orayı da.
Sprint içerisindeki diğer toplantılarımızdan kısaca bahsetmem gerekirse de grooming ve technical grooming var.
Grooming biznisten gelen işlerin işte PO aracılığıyla geldiği ve aslında tartıştığımız önceki...
eforunu konuştuğumuz toplantılar.
Technical grooming de bizim developerlar arasında yaptığı, aslında P.O.'nun biraz daha dahil olmadığı kısım burası.
Teknik olarak borçlarımız neler?
Teknik olarak neyi yapmamız gerekiyor?
Bunların öncelikleri neler? Onları tartışıp aslında yine sprint'e getirip P.O.'ya ve takım liderine anlatıp hani bunları almamız gerekiyor diye getirdiğimiz tasklar oluyor.
Bu toplantılarımız var.
Bir de OKR review toplantıları yapıyoruz.
Biliyorsunuz Trendyol'da OKR hedeflerimiz oluyor.
Dönemlik 3 aylık hedefler tutuyoruz.
Bu hedeflerin de ne kadarını başardık, neyi yapmamız gerekiyor, yine sprint'e hangilerini almamız gerekiyor.
Onları takip ettiğimiz aylık OKR toplantılarımız oluyor.
Bir zaman aslında iki haftalık sprint içerisinde hani iki haftaya bölünmüş ama yani yine de oldukça fazla toplantı var gibi duruyor.
Ben bir de şeyi sormak istiyorum biraz yani bu kadar toplantı arasında aslında bu biraz daha sof bir soru.
Bu kadar toplantı arasında çalışmak, bir şeyleri yetiştirmek, yürütmek sizce nasıl ilerliyor?
Bu toplantıların tabii ki hepsi çok gerekli ve işte mutlaka işte amaca yönelik toplantılar.
Zaten öyle olmasalar düzenlersiniz muhtemelen.
Bu kadar toplantı arasında...
İş yetiştirmek, çalışmak.
Bunun size yönlerine baktığınız zaman nasıl bir psikolojide ilerliyorsunuz?
Çünkü bazı ekiplerde bu çok zor olabiliyor yönetmesi.
Burada ekip içerisinde birbirinize nasıl destek veriyorsunuz?
Ben biraz onları dinlemek istiyorum.
Ben şey kısmından bahsedeyim ufak bir.
İki haftalık sprint mevzusundan bahsedeyim.
İki haftalık sprint aslında bu dediğin semptomların...
Sonucunda ortaya çıktı ilk başta.
Çünkü tek hafta koşunca işte toplantılarla beraber düşündüğün zaman ya çok fazla bölünüyorduk ve çok fazla sıkıntı yaşıyorduk.
Uzun bir süre önce iki haftaya taşıma kararı aldık bunu.
Neden iki haftaya taşıma kararı aldık?
İşte toplantıları beçleyebiliyorduk bu sayede.
Bu da biraz daha nefes alma aralığı sağlıyor bize ve çalışma aralığı sağlıyordu.
Bu bir aspekti için. Bunun dışındaki başka kısımlar da var.
İşte içeride kendi aramızda yaptığımız alignment toplantıları, buna gerek var mı, şuna gerek yok mu, ne yapalım, nasıl ilerletelim buraları gibisinden.
Way of working'i biz de tartışıyoruz sürekli.
Oradan çıkan sonuçlar da uygulanıyor.
Süper. Valla yani çok güzel cevap oldu İsa.
Çok teşekkür ediyorum. Aslında bu soruyu sormamdaki ana amaç şu.
Birçok ekipte, bizim ekibimiz dahil, çok böyle...
Fazla toplantı olduğu zaman yani gerekli toplantılar da olduğu durumda haftalık akışta yani iki haftada olsa sprint çok aksamalara yol açabiliyor.
Hani işte iş konusunda da olabiliyor böyle şeyler hani işte toplantılara.
tam olarak odaklanma konusunda da olabiliyor.
Sonuçta yoğun çalışıyoruz ve her sektördeki her şirket gibi aslında.
Bir şeyleri böyle belli oranda iyi planlamak, iyi yapmak oldukça önemli hale geliyor.
Biraz ondan dolayı sordum bu soruyu.
Süper. Peki bir şeyi merak ediyorum.
Şimdi sizin ekibiniz aslında dışarıdan da ben daha önce duymuştum.
Rotasyon olayları da olabiliyor ya da yeni biri de gelebiliyor ekibe.
Ekibe yeni biri katıldığı zaman, yeni birisi katıldığında onboarding süreciniz nasıl işliyor, nasıl ilerliyor?
Bu onboarding süreci aslında ekibe yeni biri katıldığı zaman ona bir body atanıyor ekipten.
Arkadaşım işe başlamadan önce body olan kişiyi...
arayıp kısa bir tanışma gerçekleştiriyor.
Ekibe başlamadan önce de kendisine anlatılacak konularla ilgili bir plan çıkarıyoruz ekip içerisinde.
Konuları anlatacak kişiler belirleniyor.
Böylelikle yeni katılan arkadaşımız ekibin her üyesiyle birebir sessionlarda tanışma fırsatı oluyor.
Hem de ekibi olan adaptasyonu hızlanmış oluyor.
İşe başladığında ise öncelikle bu toplantıları gerçekleştiriyoruz ve onun know-how kazanmasını sağlıyoruz.
Bu toplantılarından sonra ise bir arkadaşımızla pay olup genelde ilk komitini...
atmasını sağlıyoruz. Güzel yani aslında baktığımız zaman kişi geldiği zaman direkt olarak süreçlere sokuyorsunuz.
Direkt olarak hani bir iş içerisinde olmasını sağlıyorsunuz.
Ben bunu çok değerli buluyorum bu arada yani diğer ekiplerde de bizim ekibimizde de işte özellikle dikkat ettiğimiz bir konu çünkü biz nasıl çok yoğun olabilir çok böyle dikkat edilen durumlar olabilir ama hani günün sonunda
bir sürece sokmak, o kişiyi bir süreç içerisinde ilerlemek oldukça kıymetli.
Bu kişinin de özgüvenini iyi ölçüde ilerletiyor.
Aynı zamanda 2000 süreçlerine de alışma konusunda güzel bir nokta oluyor.
Hele ki işte böyle bir işi yürütüp beraber deploy etmek.
Deployment'ta da bir. katkı sağlamasını sağlamak gayet güzel oluyor.
Diplomik demişken sizin ekipte diplomik süreci işte diplomik sıklığı nasıl ilerliyor?
Aslında testten ve UAT'den sonra QA arkadaşımızla Slack üzerine iletişim kuruyoruz.
O bize yazıyor bu işi deploy etmeyi düşünüyorum.
Herhangi bir blocker'ı var mı? Bağımlı olduğu bir task var mı diye.
Eğer çok büyük bir feature değilse işte birbirine bağımlı projeleri içermiyorsa QA tek başına ilerletiyor Sinan burada.
Zaten tek bir tuşa basıyor ve ondan sonrası akıyor diyebilirim.
Ki bana da logları takip ediyoruz herhangi bir sorun oluştu mu diye.
Deployment'ı Sinan çıkıyor eğer küçük bir tasksa dediğim gibi ama çok büyük bir feature çıkıyorsak, birbirine bağlı projeler çıkıyorsa.
Developer ve QA birlikte payer yapıyor ve beraber deployment'ı çıkıyoruz sıra sıra logları takip ederek.
Deployment sıklığımızda Trendyol içerisinde deployment metriklerini takip ettiğimiz dashboardlarımız mevcut.
Bu metrikleri her sprint aslında takip ediyoruz.
Neredeyiz, ne kadar gelişmemiz gerekiyor diye.
Her gün deployment çıkıyoruz diyebilirim.
İyileşime gerekli gördüğümüz durumlarda da çabucak aksiyon almaya çalışıyoruz.
Gayet güzel bu arada süreçleriniz yani her şeyi aslında böyle nokta nokta takip ettiğiniz ve hiçbir aşama atlamadığınız bir süreciniz var.
Burada aslında nokta nokta derken hani bizim her podcast'a artık klasik olarak sorduğumuz işlerinizi nasıl takip ediyorsunuz tarafına biraz geçmek istiyorum.
Burada sizin işlerinizi artık işte hazırladınız, çıktınız, diplo ettiniz vs.
Sonrasında da bir monitoring süreci işte herhangi bir...
Sıkıntı bir durum söz konusu olursa bir alert mekanizması içerisinden geçmesi falan gerekiyor.
Burada sizin monitoring sistemleriniz, alert mekanizmanız nasıl işliyor?
Mesela bir incident olduğu zaman önden nasıl haberdar oluyorsunuz?
Bir de tabii klasik her ekibe sorduğumuz böyle anlatabileceğiniz bir incident varsa.
Onu da dinlemek isteriz. Tabii tabii.
Olmaz olur mu? Yani doğardır zaten.
Şimdi monitörlük süreciyle alakalı konuşayım.
İçeride zaten oldukça mevcut bir ekosistem var monitörlükle alakalı.
Biz de bunların aslında kullanıcısıyız.
Loglarımız Kibana'ya düşüyor. İçeride bir on-call sistemi var.
Ekip buraya dahil. Burada bir on-call rotasyonu var.
İşte çeşitli adörtler geldiği zaman site kanallarını düşüyor.
On-call rotasyondaki arkadaşlar bunları inceliyor, triyajını yapıyor.
Ekiple gerekirse iletişime geçiyor vesaire.
Burada gayet oturmuş bir sistem var hali hazırda.
Onun dışında işte içeride yine Mergen diye bir platformumuz var.
Onu kullanıyoruz. Oradan... uygulamaların metriklerini vesaire takip ediyoruz.
Bu şekilde ilerliyor. Belki bunun üzerine yaptığımız ekstra Bir şey olarak da kendi kullandığımız yine bir tool var.
AdSense'liklerin içerisinde kullandığımız bir tool var.
Bu da bize şöyle bir avantaj sağlıyor.
Uygulamalar deployment olmadan veya feature'lar geliştirdikten sonra deployment'ını yapmadan önce bizi bununla alakalı alertimiz var mı yok mu diye uyaran bir sistemimiz var.
Aslında deployment'ları vesaire de bunun üzerinden yapıyoruz.
Örnek veriyorum mesela işte yeni bir uygulamam vardı.
Uygulamama Kafka bağladım.
Pro'da gönderdim ben bunu. Bir topic consume'e gönderdim artık.
Deployment testinde aslında bu bahsettiğim tool...
Bunu görüp diyor ki senin uygulaman Kafka kullanıyor.
İşte şu topiyi konsüm ediyorsun ama neden bununla alakalı alörtün yok?
Gibi böyle tırnak içerisinde intelligent uyarılar yapan bir sistemimiz de var.
Bu sayede hani production'a çıktığımız zaman hazırlıksız çıkmıyoruz.
Böyle güzel bir yana var o tool'un. Belki şeyden de bahsederim burada bir incident.
Aklıma direkt olarak incident gelmiyor ama incident'ımsı bir olay var.
İlginç. Biraz uzun zamanda oldu yapalı bu mevzuyu.
Şöyle bir şey olmuştu zamanında.
Bir migration yapmak istiyorduk.
Bu migration'da data BigQuery üzerinde.
BigQuery'den de datayı alıp bir database'e yazacağız.
İçerideki bir database'e yazmamız lazım.
BigQuery'de yeni yeni kullanıyoruz o zamanlar.
Çok bilmediğimiz için bir plan yaptık işte.
Dedik ki datayı şöyle alırız. Çeşitli market edeceğimiz AdWords'lar var.
Bu AdWords'ları sırayla gezeriz. BigQuery'den datasını alır.
Gerekli yeri yazarız. Tamam dedik.
Arkadaşla el sıkıştık. Arkadaş script'i yazdı.
Ben de herhalde hacker news'e falan girdim.
O sırada bir bakınıyorum, bir şeyler okuyorum.
Bir tane bildirim geldi.
Bir yarım saat sonra. Şu an ne yapıyorsanız durun.
diye. Allah Allah dedim ben ya ben bir şey yapmıyorum ekranı sokuyorum çok da duracak bir şey yok diye bir düşünürken bildirime gittim girdim bir tane grafik atılmış.
Grafik işte zaman ve para eğrisi.
Zaman eğrisinde grafik gayet şey düz gidiyor.
Bir anda sonlara doğru tepe yapıyor.
Big credit şeymiş. Ne kadar para harcadığımızla alakalı bir grafikmiş.
Son yarım saat içerisinde bir anda inanılmaz bir artış var.
harcadığımız para da onu durdurmamızı istiyorlarmış.
Ne olabilir diye bir düşünce aklıma ben de işte o migration script'i geldi.
Arkadaş yazma hemen bir durduralım bunu ne oluyor falan bakalım diye.
Big Query'de şöyle bir şey var. Meğerse işte hani Query başına para alıyorlar.
En azından tam olarak böyle olmayabilir de kafamdaki mental model bu şekilde.
Query başına para alıyorlar. Query'nin büyüklüğü o kadar hani esnetmiyor parayı diyeyim.
Ama hadi Query başına belirli bir para aldıkları için çok fazla Query atarsan çok fazla para gidiyor.
Dolayısıyla biz de migration'ı planlarken İşte market edeceğimiz item başına bir query atalım gibisinden bir şey yapmıştık.
Batch olarak gidelim değil de her bir market edeceğimiz şeyi bir queryden gidip çekelim gibisinden çok da basit queryler aslında bir tane veri çekiyor.
Ama bundan on binlerce atınca binlerce dolar yakmışız.
Normalde atıyorum otuz kuruşa mal edebileceğimiz bir migration binlerce dolara mal olmuştu.
O esnada da şeyde düşündüğümü hatırlıyorum.
Hani artık migration'in yüzde doksanını falan gelmişiz.
Ya dedik hani script'ı değiştirmesek bir 5 bin dolar daha yaksak da migration'ı tamamlasak olur mu diye bir düşündüm ama yani saçmaydı.
1 doları hallettik daha sonrasında migration'ı böyle ilginç bir olay olmuştu.
Valla çok ilginçmiş gerçekten.
Ama tabii şey yani 1000 dolarlar senin o an cebinden çıkmadığı için.
30 bin dolarlık migration yani herkesin yaptığı bir şey değildir diye düşünüyorum.
Vallahi çok iyi. Yani muhtemelen şeyde BigQuery tarafında bu hareketleri izleyen biri varsa o da şaşırmıştır.
Yani Allah Allah. Yani hani neden böyle bir şey yapıyorlar ki diye.
Tabii tabii yani direkt mesaj atılmış.
Ne yapıyorsanız durdurun diye.
Yani böyle bir mesaj geldi.
Birileri takip ediyormuş demek ki şükür en azından.
Vallahi çok iyi. Yani gerçekten aslında böyle şeyler, böyle zamanlar bize bir şeyleri öğretebiliyor.
Yani bu her incident konuştuğumuz zaman aslında tekrar tekrar söylediğimiz bir şey.
Yani incident yapmak. insanın olması değil sonrasında çıkardığımız ders sonrasında ne yaptığımız aslında çok önemli.
Bu da bence gayet güzel bir örnek.
Dediğimiz gibi aksilikler her zaman yaşanabiliyor.
Bundan ders çıkarmamız önemli.
Bir de tabii takım içerisinde de bu tarz durumlar yaşanabiliyor.
Bunun da işte ders çıkarmak, tecrübe edinmek falan bunları yapabilmenin de en iyi yollarından biri de retro toplantıları.
Onu da sormuş olayım. Storex ekibi retrolarını nasıl yapıyor?
Hemen bahsedeyim abi. Stories ekibi olarak dizaynında bahsettiği gibi 2 haftalık sprintler koşuyoruz.
Her sprint sonunda da mutlaka retro toplantısını yapmaya çalışıyoruz.
Aksatmamaya özen gösteriyoruz.
Özellikle büyük bir proje çıktığımızda retro toplantılarını daha da uzun tutuyoruz.
Bu projede neleri iyi yaptık, nelerde zorlandık gibi konuları detaylıca konuşuyoruz aslında.
Action item'lar çıkarıyoruz ve her retroda bu item'ların üzerinden geçiyoruz.
Aynı sorunların tekrarlanmasını bu sayede önleyebiliyoruz.
Süper. Burada aslında retro toplantıları her ekip için oldukça önemli.
Bizim de içeride kendi geliştirdiğimiz retro tool'ları, retro süreçleri de var.
Retro trend yolu içerisinde oldukça önemli de bir süreç.
Oldukça önemli bir toplantı.
Yani retroya da aslında direkt olarak zorunlu bir şey gibi bakmaktan ziyade iyileştirici, kapsayıcı bir şey gibi bakmak oldukça önemli.
Süper. Yavaş yavaş sonuna geliyoruz bölümümüzün.
Bizim her bölümde sorduğumuz klasik bir soru var kapatırken.
Onu sormak istiyorum ve sonrasında kapatalım istiyorum.
Bizim ekip iletişimi konusunda, ekip iletişimi geliştirme konusunda aslında farklı farklı şeyler yapan ekiplerimiz var.
İşte araba sevdalısı ekiplerimiz var, nargileci ekiplerimiz var, işte yeme üzerine böyle çok ilginç şeyler geliştiren ekiplerimiz var.
Size de sormak istiyorum, ekip iletişimini geliştirmek için neler yapıyorsunuz arkadaşlar?
Abi ben cevaplayabilirim. Aslında ekibimizde İzmir ve Ankara'da yaşayan arkadaşlarımız da var İstanbul dışında.
O sebepten ekip iletişimini canlı tutmak bence birinci önceliğimiz bizim ekip olarak.
Bu sebepten iki haftada bir oyun sesyonlarımız mevcut.
Bu sesyonda işte ekip... bir araya gelip oyun oynayıp sohbet ediyoruz.
Online seyşinlerin dışında da belirlediğimiz tarihlerde fiziksel olarak bir araya gelerek farklı etkinlikler düzenleyebiliyoruz.
Genelde oyun sonrası yemek oluyor et üzerine, et ağırlıklı yemek oluyor.
O şekilde aslında bir araya geliyoruz.
Süper. Yani klasik aslında Trendyol'daki birçok ekip gibi oyun ve yemek üzerine bizim de ilerliyor süreçler.
Yine bu ekiple de aynı durum söz konusu.
Süper. Arkadaşlar çok teşekkür ederim geldiğiniz için.
Benim için oldukça keyifli oldu.
Tekrar çok teşekkür ediyorum.
Biz teşekkür ederiz. Harika.
94. bölümde Storex ekibiyle beraberdik.
Bu ekibin pısımları, kullanılan teknolojileri, pratikleri gibi konular üzerine konuştuk.
Sonraki bölümlerde başka ekiplerle görüşmek üzere.
Bu transkript otomatik olarak çıkarıldı; kayıtla küçük farklar olabilir.