Konuklar: Arda Ulusoy, Ömer Faruk Erkul, Özge Şura İmdat
80. bölümümüzde konuğumuz Tex Middle Mile Core 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 Day Browsing ekibinden Cengiz.
Teknoloji ekiplerini tanıdığımız ve süreçler, teknolojiler gibi konuları konuştuğumuz Selam Ekip Podcast serisinin 80.
bölümündeyiz. Dile kolay. 80 bölüm.
80. bölümde Tex Middle Mile Core ekibi bizlerle birlikte.
Bu ekibi tanıyacağız.
Ekip yapısı, kullanılan teknolojiler, pratikler gibi konuları konuşacağız.
Arkadaşlar hepiniz hoş geldiniz.
Merhaba, hoş bulduk. Merhaba, hoş bulduk.
Merhabalar. Merhabalar, tekrar hoş geldiniz.
Yine hiçbir fikrimizin olmadığı güzel bir ekiple beraberiz.
Kısaca kendinizden bahsedebilir misiniz arkadaşlar?
Merhaba, ben Özge Şuraimdat.
Trendyol'da Logistics Techs Middle-Night Core ekibinde yazılım geliştirilmene çalışıyorum.
Backend Developer'ım. 3 yıldır aynı ekiple birlikteyim.
Bu sektörde de 7,5 yıl oldu varım bu şekilde.
Ben Devralıyım.
Selamlar, ben Ömer Faruk.
Ben de yaklaşık 3 senedir Trendyol'dayım.
Benim sürecim birazcık daha farklı.
Devin Test olarak başlamıştım Trendyol'a 1,5 senedir.
Software Developer olarak da 1,5 senesini harcadım Trendyol'da.
Bu gibi değişimleri de destekleyen bir şirket Trendyol zaten.
Tabii ki de Trendyol'da da Logistic Techs altındaki Middle Mile Core ekibine görev alıyorum.
Selamlar, ben Erdoğuk Unusoy.
Yaklaşık 1,5 senedir Trendyol'dayım.
Trendyol ilk iş tecrübem diyebilirim.
Logistik TechScribe altında Middle Mile Core ekibine göre alıyorum.
Tekrar hoş geldiniz arkadaşlar.
Çok güzel. Bugün böyle her renkten, her taraftan arkadaşlar bizlerle birlikte.
Bu da gerçekten çok keyifli.
Böyle bölümleri özellikle sevdiğimizi söyleyebilirim.
Tekrardan hoş geldiniz.
Arkadaşlar Techs Middle Mile Core ekibi.
Yani aslında ekibin adı bu şekilde.
Fakat yani okuduğumuz zaman aslında duyduğumuz zaman çok da bir şey.
anladığımızı söyleyemem.
Bu ekibi biraz tanıtabilir misiniz?
Bu ekip nedir?
Ne yapar? Tribe olarak ne yapar?
Yani aslında bir tribe bildiğim kadarıyla direkt olarak.
Biraz bahsedebilir misiniz bunlardan?
Tabii. Biz Middle Mile core ekibiyiz ve dediğim gibi aslında logistik tribe'ın bir parçasıyız.
Aslında adından anlaşılacağı biz tam ortada duruyoruz core adından da anlaşılacağı gibi.
Yani paketlerin Trendle Express toplama merkezlerinden toplanıp bizim tabirimizde TEX.
yapılacak şubeye kadar olan o kritik yolculuğunu biz yönetiyoruz aslında.
Yani şu şekilde ayrıştırması, yönlendirmesi, çuvallaması, paletleme, doğru araca ataması gibi bu kısacası paketin ben nereye gidiyorum ya diye düşündüğü her aşamasında biz
devredeyiz. Lojistik tribe ise bu sürecin tamamını kapsıyor.
Gönderilerin toplanmasından başlayıp teslim edilmesine ve gerektiğinde depolanmasına kadar olan tüm operasyonlar burada şekilleniyor.
Lojistik tribe'ının altındaki operasyonlar bu şekilde.
Yani paketin doğumundan varışına kadar olan tüm macerasını bizim tribe'ımız yönetiyor diyebilirim ben.
Evet değerli dinleyiciler, kargom nerede diye düşündüğünüz o muhteşem bölüme geldik.
Yani anladığım kadarıyla ben bir trend yol kullanıcısı olarak kargomla alakalı tüm süreçleri sizin sorumlusu olduğunuzu söyleyebilirim o zaman.
Aslında şöyle tabii hepsini biz yönetiyoruz diyemem.
Az önce anlattığım çuvallama paletleme işte doğru araca atama gibi neredeyim dediği yerde biz çalışıyoruz.
Tabii Trendal Express'in altında birçok ekip var.
Biz sadece onlardan biriyiz.
Yani bütün süreci biz yönetmiyoruz aslında.
Ömer Faruk her şeyden biz sorumlu değiliz.
Çırpınışına gerçekten bayıldım.
Süper anladım.
Yani aslında bir Trendyol gönderisinin, Trendyol Express gönderisinin başlangıcı ve işte paketlenmesi vs.
ve bunun işte lojistik anlamında nerede olduğunu falan siz yönetiyorsunuz.
Süper. Bu tribe altında benim anladığım kadarıyla yani bildiğim kadarıyla senin de dediğin gibi çok fazla ekip var, çok fazla takım var.
Siz de takım olarak birçok ekiple aslında beraber çalışıyorsunuz.
Biraz bahsedelim mi bunlardan?
Hangi ekiplerle, hangi takımlarla yakın halde çalışıyorsunuz?
Biz middle mile ekibiyiz ama yalnız değiliz tabii ki.
Aynı çatı altında core ve sorting olmak üzere iki kardeş ekibiz diyebilirim.
Biz core tarafında yer alıyoruz ama sorting ekibiyle de sürekli paslaşıyoruz.
Zaten lojistikte her şey bir zincir halinde ilerliyor.
Biz de zincirin tam ortasındayız.
Bu yüzden sadece kendi ekibimizle değil, text domain altındaki First Mile olsun, Last Mile, Infra, DFH raporlama ekipleriyle de yakın çalışıyoruz.
Kargo bir yandan yola çıkarken biz ortasını yönetiyoruz.
First Mile ekibi başlangıcını, Last Mile da son noktayı yönetiyor.
Süreçler domainler arasında bölünüyor ama iş birliği tam gaz devam ediyor.
Kısacası bizde işler biraz takım oyunu gibi.
Herkes kendi alanında oynuyor ama golü birlikte atıyoruz.
Süper. Yani bu şekilde structure olması, bu şekilde bölünmüş ve düzenli olması gayet güzel.
Ama tabii şöyle de bir nokta var.
Aslında bölündüğü şey yani bir operasyonun böyle bölünmesi basitliği ve işte verimliliğinin yanında bazı zorlukları da ortaya çıkarıyor diye düşünüyorum.
Burada zor olmuyor mu?
Nasıl yönetiyorsunuz diğer takımlarla bu şekilde çalışmayı?
Evet. Ekibimizin konumu gereği birçok ekiple çalışıyoruz ama bu durumu daha çok zorluktan ziyade bir avantajmış gözüyle bakıyoruz.
İletişimimizi mümkün olduğunca hem sade hem de hızlı tutmaya çalışıyoruz.
Bunun için de böyle Slack'te birlikte çalıştığımız her ekip için özel kanallarımız var.
Slack kanalları üzerinden haberleşiyoruz.
Yani şimdi kim hangi ekipleri de kime ne yazacağım gibi bir karmaşa yaşamadan doğrudan ekiplerle kanallar, ortak kanallar üzerine iletişim kuruyoruz.
Yani yazışmakla da kalmıyoruz genel olarak tabii ki.
Değişen ihtiyaçlara göre zaman zaman hem ofiste yüz yüze toplantılar hem yazılım üzerinden toplantılar ayarlıyoruz.
Bu şekilde iletişimi sürdürüyoruz.
Süper, güzel. Yani aslında her şeyi burada da basitleştirdiğinizi söyleyebiliriz.
Her şeyi burada da böyle verimli bir yola, verimli bir şekilde kıldığınızı söyleyebiliriz.
Zaten birçok ekiple birlikte çalışmak yani ne olursa olsun ne kadar süreçleri basitleştirirsek basitleştirelim.
Yine de tricky bir olay.
Birçok parametre gerektiriyor.
Sadece iyi bir iletişim değil, iyi bir koordinasyonu da gerektiriyor.
Bu da düzgün sağlayabilmek gerçekten çok değerli.
Peki biraz da ekip tarafından bahsedelim.
Artık Middle Mile Core ekibinde kaç developer var, kaç tester var?
Ekipteki dağılım nasıldır sizin tarafta?
Buna ben cevap verebilirim.
Ekibe en yeni katılan developer olarak.
En kalabalık teknoloji ekiplerindeniz biz.
Toplamda 11 kişilik bir kadroyuz.
Bayağı büyük bir kadro.
5 tane back-end developerımız var bu ekipte.
2 tanesi front-end developer.
2 devin test ve 1 tane staff engineerımız var.
E tabii ekibin içinde her şeyi bir ara tutan bir product managerımıza ihtiyaç var.
Tabii ki yolunuzu çizen de bir ekip liderimiz olmak zorunda.
Epey büyük bir domain yani.
İşlerimiz kalabalık değil.
Bir de kapsamlı olduğu için her açıdan güçlü bir ekip yapısına sahibiz.
Yani hem kod yazıyoruz, hem test ediyoruz, hem yön veriyoruz.
Takım olarak güzel bir denge yakaladık diyebilirim.
Güzel bir dağılımmış ya.
Yani gerçekten şey olarak yani bu ölçekli bir ekip için iyi bir sayı bu arada.
İddialı bir sayı. Yani 11.
Ama tabii şöyle de bir nokta var.
Her tarafına, senin de söylediğin gibi her tarafına dokunduğunuz bir geliştirme süreciniz var anladığım kadarıyla.
Yani işte front endidir, back endidir, testlidir vs.
Aslında her tarafına...
handle ediyorsunuz.
Bu da gayet güzel. Bir de şeyi sorayım.
Şimdi takım içerisinde nasıl ilerliyorsunuz?
Sprint mi koşuyorsunuz yoksa kanban mı ilerliyor?
Yani yoksa işte proje bazlı mı ilerliyor?
Sizin tarafta nasıl ilerliyor süreçler?
Yani bizim bu konuda aslında yöntemle denediğimiz bir sürecimiz var.
Biz uzun bir süre aslında sprint metodolojisiyle ilerledik.
Yani ancak zamanla böyle fark ettik ki bütün planninglerde taslara genelde benzer puanlar veriyoruz.
Sonrasında da hani bu bize aslında tasları iyi parçaladığımızı ve süreçleri sadeleştirmekte bir tık başarılı olduğumuzu düşündürdü ve gösterdiğini düşündük.
Bu yüzden de hem sprint ritüellerini harcadığımız zamanı daha verimli kullanalım hem de daha akışkan bir süreç elde etmek için Kanban'a geçmeyi denedik.
Gerçekten Kanban'a geçtiğimiz zaman verimlilik anlamında ciddi bir artış sağladık.
Bayağı bir süre Kanban'la devam ettikten sonra Trendyol'un şu anda da çok öncelikli olan metrik tarafı tabii ki ortaya çıktı.
Bu Trendyol'un 4K metrikleri Jira'daki sprint boardları üzerinden takip edildiği için Kanban'da Kanban'ın ekibin metrik ölçümlerinin verimli hale getirmediğini fark ettik.
Çünkü bizim Kanban boardumuz vardı ve ölçümler sprint boardları üzerine ilerliyordu.
Bu duruma da pratik bir çözüm ürettik aslında.
Kanbandan da vazgeçmedik.
Teknik olarak haftalık sprintboardlar kullanıyoruz.
Jira üzerinde ama süreç akışını kanban mantığı yürütüyoruz şu anda.
Böylece hem esnekliğimizi koruyoruz gibi hem de metrik tarafına uyum sağlıyoruz.
Ve şu anda böyle yürüyoruz.
Bir nevi aslında scramban yapıyorsunuz diyebiliriz o zaman.
Evet. Şimdi bunu sormamın nedeni şu genellikle böyle konuştuğumuz zamanlar işte scramban.
...dan bahsedildiği zaman insanlar biraz şey gibi davranıyor.
It's not a real thing yani böyle bir şey yok, sallıyorsunuz gibi söyleniyor.
Aslında yani bu dediğiniz yönelim, bu dediğiniz metodoloji biraz Scrum bana hit ediyor gibi duruyor.
Yani biraz ondan, biraz ondan.
Ama tabii bu arada yani bu tarz bir...
Sistemi kullanan Trendyol'da çok fazla ekip de yok bildiğim kadarıyla.
Ekipler ya sprint üzerinden gidiyorlar ya kanban üzerinden gidiyorlar.
Ama yani sizin sorununuzu bu çözüyorsa ve burada rahat bir şekilde ilerliyorsanız bence çok verimli, çok güzel bir yöntem.
Evet yani doğrudan kanban kullandığımız zaman da aslında dailylerimizi, retrolarımızı yapıyorduk.
Yani her zaman orada ilerlemişiz diyebilirim ben de.
Süper, süper.
Peki şimdi burada...
Şeyden konuştuk, ekipte backend tarafı var dedik, test tarafı, frontend tarafı vs.
Backend tarafıyla alakalı bir şeyi merak ediyorum.
Backend tarafında mimariyle alakalı sizin tarafta kararlar nasıl veriliyor?
Backend mimarisiyle ilgili kararları tabii ki de ekip olarak birlikte alıyoruz.
Yani product managerımızdan yeni bir ihtiyaç geldiği zaman...
Ekipçe bir araya gelip teknik analiz toplantıları yapıyoruz.
Bu gerekse full ekip oluyor, gerekse bazı fokus gruplar üzerinden oluyor.
O anki birden fazla işgenli durumunla alakalı biraz.
Mevcut sistemin yapısını ve ihtiyaç duyulan entegrasyonu birlikte değerlendiriyoruz.
Bu noktada genelde daha çok çizim araçlarını kullanmayı tercih ediyoruz.
Çünkü hem var olan sistemi görmek, hem yeni sistemi görmek, şablon olarak bile çizsek...
Bizim hem daha iyi gözlemlememizi, daha iyi karar almamıza büyük yardımcı olduğunu düşünüyoruz.
Eğer bazı konularda kararsız kalırsak ya da farklı alternatifler arasında imralamazsak, staff enjenerimizden, ekip liderimizin görüşlerinden fayda alıyoruz.
Yani karar süreci hem teknik hem de ekip dinamikleri açısından oldukça denge ilerliyor diyebiliriz.
Süper. Yani burada mimariyle alakalı kararlar önemli tabii.
Özellikle işte bekant tarafını konuştuğumuz zaman sağlam, düzgün bir mimari uygulamak, sağlam bir sistem kurabilmek çok önemli.
Burada tabii son teknolojileri kullanmak ya da işte verimli işlevsel teknolojileri kullanmak da önemli.
Bekant tarafında siz hangi teknolojileri kullanıyorsunuz?
Şöyle söyleyeyim. Biz bekant tarafında genelde trend yolda takip edilen best practice'leri kullanıyoruz.
Ağırlıklı olarak Go ve Java diline yer veriyoruz.
Mimari taraftaysa asenkron iletişimi tercih ediyoruz.
Burada en temel yapı taşımız Kafka diyebilirim.
Tabii sistem her zaman sorunsuz çalışmayabiliyor.
Bu yüzden olası senaryo hatalarında devreye giren bazı fallback mekanizmalarımız var.
Örneğin kaçırılan yönetileri yeniden işleyebilmek için shovel integrasyonumuz var.
Bunun dışında publish ettiğimiz verilerin...
Ulaşılabilirliğini sağlamak için Outbox Pattern kullanıyoruz.
Yani database'lerde mesela Kafka arasında köprü kuran bir Debezium konektörümüz var.
Yani event bazlı çalışıyoruz.
Esnek bir yapı kurmaya odaklanıyoruz diyebilirim.
Süper. Yani şey de çok garip ya.
Ben onu da hani çok fazla çalıştığım bir dil değil açıkçası ama hani Java'nın hala bu kadar sektörde domine haline gelmesi.
Mesela Go üzerine çalışmak anlayabileceğim bir şey.
Sonuçta son yıllarda çıkmış ve oldukça güçlü bir dil.
Son yıllarda artık 15 senesi falan yavaş yavaş olmaya başladı.
Ama Java'ya baktığımız zaman yeni bir dil olarak kalıyor.
Bu Java'nın sarsılmaz yeri beni çok garibime gidiyor.
Yazması da çok büyük bir eziyet olmasının yanında.
Seven insanın da bu kadar fazla olması, Trendyol'da hele ki çok fazla projede kullanılması da ayrı bir olay gibime geliyor.
Böyle bir düşüncemi de söylemek istedim sizlere.
Okey, süper.
Şimdi birazcık daha aslında öğrendik teknolojiden neler, işte ekip nasıl bir ekip, neler yapılıyor, neler ediliyor vs.
Birazcık daha işin civcivli konularına girebiliriz diye düşünüyorum.
Peki şöyle devam edelim.
QA taraflarını birazcık da konuşalım.
Test taraflarını birazcık da konuşalım.
Dediğim gibi birazcık daha işin artık test edilmesi, işte production'a gönderilmesi, sonrasında monitoring, insulin vesaire bu tarz konulardan devam edebiliriz.
Bunlar da daha önce de bahsettiğim gibi birazcık civcivli süreçler.
Sizde QA süreçleri nasıl ilerliyor arkadaşlar?
Yani bir işe alıyorsunuz, geliştiriyorsunuz, ilerletiyorsunuz.
Sonrasında testi nasıl yapılıyor ve ondan sonra nasıl ilerletiliyor?
Şöyle söyleyeyim aslında Tam böyle development sonrası test bizde çok fazla yok.
Şöyle var aslında test development'ın her yerine yayılmış durumda.
Ayrıca işte development süreci tamamlandığında da yani unit testlerimizi yapıyoruz.
Entegrasyon testlerini geçtiğinde de bizim deyimimizle artık stage ready oluyor.
Sürecin son aşamasına gelmiş oluyoruz bu noktada.
Bu noktada da acceptance testler devreye giriyor bizim için.
Acceptance testleri aslında devin test rolündeki arkadaşlarımızın iş yoğunluğuna göre Doğrudan onlar yazıyor ya da biz developerlar olarak onlarla birlikte ortaklaşı yazıyoruz.
Testler tamamlandıktan sonra da işin kontrol noktası olan UET sürecine geçiyoruz.
Burada product manager'ımız ve business developerlarımızla birlikte süreci gözden geçirip son oyun onayımızı alıyoruz aslında.
Yani işin tamamlandığında sadece kodun çalışması değil doğru ihtiyaca hizmet edip etmedi de belirliyor.
Diyebilirim yani sadece development'tan sonraki test süreci değil de bütün development cycle'ında bizim bir test sürecimiz var.
bu şekilde ilerliyoruz diyebilirim.
Ya son söylediğin o kadar doğru ve o kadar güzel bir şey ki.
Yani gerçekten sadece kolun çalışması değil.
Yani ürünün o anki o geliştirmenin verimliliği, doğruluğu işte herhangi bir noktada problem yaşanabilecek mi, yaşanacak mı falan filan.
Bunların hani test edilmesi direkt development ortamında oldukça önemli.
Çok tebrik ederim size yani böyle bir hassasiyetiniz, böyle bir bakış açınız olduğu için.
Trendyola'da zaten ekip genel olarak Tüm ekiplerde gördüğümüz şey yapılan geliştirmenin canlıya çıkmadan önce çok detaylı bir biçimde test edilmesi ve hataya neredeyse hiç fırsat bırakılmaması,
pay verilmemesi. Bu konuda da emeklileriniz için tekrar teşekkür ederim.
Peki burada geliştirmeyi yaptık ve ilerlettik falan.
Bu canlıya çıkma tarafında sonuçta şey var.
Ne kadar sürede canlıya çıkıldığı, ne kadar sürede uygulamaya canlıya çıktığınız falan bunlar...
önemli aslında yani çünkü işte pipeline süreleri, burada yapılan geliştirmenin canlıda direkt olarak görünmesi falan filan bunlar hızlı aksiyon alınması gereken şeyler.
Siz burada bu canlıya çıkma süresini, sürecini nasıl ölçüyorsunuz?
Burada herhangi bir tuttuğunuz bir veri var mıdır?
Evet var. Aslında bir an önceki sprint sorusunda da söylediğim gibi Trendyol'un metrikleri arasında bu ölçümün metriği de var.
Bu konuda genelde yine Trendyol genelinde kullandığımız Pandora'dan takip ediyoruz burayı.
Jira boardlarımızla entegre çalışıyor Pandora.
Yani yeni bir taskın development test ve deployment süreçlerini uçtan uca ölçen cycle time isimli bir metriğimiz var.
Burada Life Cycle'ı net olarak görebiliyoruz.
Aynı zamanda da Jira dashboardlarımız var.
Burada da haftalık sprintlerde ne kadar taslana çektiğimizi görüp ve üstümüzde bir artış ya da düşüş var mı bu veriler üzerinden takip edebiliyoruz.
Yani böylece ekip olarak veriye dayalı bir şekilde gözlem yapıp süreçte iyileştirilmesi gereken bir durum varsa iyileştirmeye gayret ediyoruz diyebiliriz.
Cycle Time ölçme konusu.
Genel olarak birçok ekipte aslında önemli bir konu.
Bizim ekiplerde de, benim çalıştığım ekipte de çok üzerine duyduğumuz, dikkat ettiğimiz bir konu.
Gerçekten burada sadece canlıya çıkma süresi değil, geliştirme tarafında da cycle time'ı ölçmek oldukça faydalı oluyor.
Birçok ekip bunu zaten uyguluyor.
Burada peki şimdi birazcık da şey konularından bahsederim artık biraz daha hani işte işin risk tarafı, incident tarafı, monitoring tarafına geçecek olursak.
Sonuçta bir deployment yapıldığı zaman, geliştirmeyi canlıya aldığımız zaman herhangi bir şekilde bir riskle karşılaşabiliriz, herhangi bir şekilde bir incidentle karşılaşabiliriz.
Burada siz bu yaşanabilecek riskleri, yaşanabilecek incidentleri en azından indirmek için, önlemek için neler yapıyorsunuz?
Bu risk kapsamında bizim ekip olarak dikkat ettiğimiz çok fazla konsernimiz var.
Çünkü biz strength-based development yazıyoruz.
Yani GitLab'de kullanılan branch'leri kullanmıyoruz.
Doğrudan master branch'ine merge'lıyoruz.
Bu yüzden de her yaptığımız geliştirmenin, her attığımız commit'in aslında doğrudan prodlanabilir mantığıyla atılması gerekiyor ve bu geliştirmelerimizi bu denli güvenli olacak şekilde yapmaya çalışıyoruz.
Bunu sağlamak için de feature togglerimiz var.
Feature Toggle'larımızı ekleyip eğer kodumuz biz testlerimizi tamamlamadan proda çıkmak durumunda kalırsa doğrudan Toggle'ı pasif olacağı için aslında aktif olarak çalışmıyor oluyor.
Bu da aslında bir noktada bir güven sağlamış oluyor.
Onun dışında biz servislerimizin hepsinde neredeyse acceptance testlerimiz var.
Kavuçlarımız çok iyi bir durumda.
Otomasyon testlerimizi çalıştırıp mevcut bizneslerimizi bozmadığımızdan emin olmaya çalışıyoruz ve ayrıyeten yeni geliştirdiğimiz feature'ın testlerini yazıyoruz.
Burada da aslında coverage'larımızı yukarıda tutarak da riski indirmeye çalışıyoruz.
Tabii ki unique testlerimiz falan doğrudan kapsamlı şekilde development aşamasında zaten yazılmış oluyor.
Bir de ekstra olarak deployment olarak general deployment entegrasyonu var bizim servislerimizde.
Yani konfigürasyonlar olarak belirlediğimiz pod sayısı kadar ilk başta ayağa kalkıyor.
Eğer onlardan yine bizim belirlediğimiz rate'de bir error gelirse o podlar hiç ayağa kalkmadan öldürülüyor.
Eski podlar devam ediyor hayatına.
Bu da aslında bizim riski indirmek için bizim production ortamında tahminleyemediğimiz bir sorun olduğunda bu durumları riskini en az indirmek için kullandığımız bir yöntem.
Süper. Burada her aşamada testin olması, her aşamada bir test edinmeye ihtiyacının giderilmesi oldukça önemli.
Feature toggle'lar, feature branch'lar üzerinden de öncesinde gidip bakması da bence çok güzel.
Biz de çok uyguladığımız bir taktik, uyguladığımız bir yöntem.
Bayağı iyi valla yani. Burada gayet güzel ilerliyorsunuz.
Burada tabii şey oluyor mu?
Sonuçta Bir monitoring işlemi yine de yapılması gerekiyor uygulamaların.
Aynı zamanda da performansını da ölçmek gerekiyor, bir optimizasyon da yapmak gerekiyor.
Monitör etmek ve optimizasyon konusunda yaptıklarınız nelerdir?
Performans bizim için sadece sistem hızlı çalışsın diye değil, kullanıcı deneyimi ve iş sürekliliği açısından da kritik bir konu.
Bu yüzden geliştirme yaparken performansı baştan itibaren göz önünde bulunduruyoruz.
Özellikle yüksek trafik alacağımız dönemler, Kasım ayları, örneğin Black Friday gibi dönemler bizim için yük testlerinin olmazsa olmaz olduğu zamanlar bu testlerle sistemin nerede zorlandığını önceden
görüp gerekli iyileştirmeleri yapıyoruz.
Monitörün tarafında ise elimiz boş değil.
Loglarımızı incelemek için Kibana kullanıyoruz.
Log yazarken de öyle her şeyi basalım geçelim gibi bir kafa yok.
Gerçekten anlamlı.
Sorunun kaynağına götürebilecek şekilde loglama yapıyoruz.
Bunun dışında Grafana dashboardlarımızla Servislerin genel sağlık durumunu takip ediyoruz.
CPU, memory, network gibi klasik metiklerin yanında Kafka logları, throughput ve response timeları da detaylıca izliyoruz.
Bir de OpenTelemetre entegrasyonlarımız mevcut.
Bunlar sayesinde servisler arası iletişimde nerede ne kadar zaman harcandığını gözlemleyebiliyoruz.
Yani bir sorun olduğunda acaba nerede takıldı bu ya diye tahmin yapmak yerine elimizde somut veriler oluyor.
Süper. Süper.
Buradaki ölçümler de çok önemli.
Monitoring zaten her bölümde aslında konuşuyoruz her ekibin.
Olmazsa olmazı haline gelmiş durumda.
Buradan ufak ufak incident ile alakalı soruya da geçeceğim ama öncesinde şeyi merak ediyorum.
Oncall artık yavaş yavaş bizim kültürümüzün bir parçası haline geldi.
Nöbetçilik. Dolayısıyla her ekipte de aslında bununla neredeyse tüm ekiplerde karşılaşıyoruz.
Sizde nöbet sorumluluğu konusu var mı?
Ve varsa hani bu haftaki sorumlulukları neler oluyor nöbetçinin?
Evet, ekibimizde haftalık olarak dönen bir nöbetçi sitemiz var.
Nöbetçi olan arkadaşımız, support kanalından gelen sağ destek ihtiyaçlarını takip ediyor.
Bunun dışında iletişimde olduğumuz diğer ekiplerden gelen destek taleplerini de izleyip gerektiğinde aksiyon alıyor.
Servislerimizin alert kanalları da nöbetçinin sorumluluğunda.
Hızlı çözüm gerektiren konuların takibini yapıyor.
Burada önemli olan şey destek talebini çözmek kadar.
Eğer çözemiyorsak da talebi doğru kişiye doğru şekilde yönlendirmek diyebilirim.
Bu süreci kolaylaştıran ekipçe geliştirdiğimiz Slogi adında bir aracımız da var.
Slogi aslında bir slag otomasyonu.
Farklı destek kanallarına gelen talepleri tek bir kanal altında topluyor.
Nöbetçi bu kanal üzerinden taleplerin takibini sağlayabiliyor.
talepleri assign edebiliyor, done olarak işaretleyebiliyor.
Bu çözülmüş talepler de otomatik olarak bir Google Sheet'e kaydoluyor.
Bu sayede geçmiş talepleri takip edebiliyoruz.
Hem de benzer bir durum yaşadığımızda önceki çözümler bize bir rehber oluyor.
Çok güzelmiş ya.
Bu Slack'taki botunuz herkese açık bir bot mu yoksa sadece siz mi kullanıyorsunuz?
Sadece biz kullanıyoruz.
O şekilde. Güzel, belki bunu ileride herkesin kullanabileceği şekilde getirmeyi düşünebilirsiniz.
Evet, çok iyi olur gerçekten.
Süper. Evet, şimdi ufak ufak son 2-3 sorumuz kaldı.
Artık yani o beklediğimiz acı dolu soruya geçebiliriz.
Incident sorusu. Daha doğrusu aslında böyle bir komik ya da ilginç bir hikaye rica edeceğim sizden.
Incident de olabilir, bu başka bir şey de olabilir.
Hani böyle başınızdan geçen...
Komik ya da ilginç bir hikaye oldu mu ekipçe?
Var abi. Şöyle söyleyebilirim.
Az önce konuştuk aslında acceptance testler, işte UAT'ler falan.
Ama yani ekibe yeni katılan bir insan için bunlar tabii ilk başta göremeyi biliyor insanlar.
Ben de onlardan biriydim aslında.
Benim de biraz trajikomik bir hikayem var ekibe yeni katıldığım zamanlarda.
Yakın çalıştığımız takımların kulağında bir proje vardı.
Onun geliştirmesini canlıya çıktığımızda Allah'tan ofis dedik diyeyim.
Bir de uygulamanın loglarını inceliyorduk.
Bir anda hataların arttığını gördüm.
Ekip arkadaşımla beraber şöyle bir konuşma geçmişti aramızda.
Ekip arkadaşım Hakan ona da buradan selam olsun.
Hata sayısının artması normal mi tarzında bir soru sordum.
O da şöyle bir durup normal değil gibi bir cevap verince bir bakabilir miyiz dedim.
Böyle bir anda her yerden böyle support kanallarından falan talepler yağmaya başladı.
Biz de işte deployment'ı hızlıca geri aldık.
Tek yapabileceğim şey oydu çünkü.
Yani toggle eklememiştik.
Toggle eklemeyince de böyle şeylerle karşılaşabiliyoruz.
Çok uzun süren bir incident değildi aslında.
Bir dakika falan sürdü yaklaşık.
Biraz donak aldım açıkçası.
Ekibe de yeni katılmıştım. Yani acaba çok yanlış bir şey mi yaptım tarzında düşünceler oldu.
Ama Trendyol'da aslında bu gibi şeyleri çok kızmıyor.
Aslında gelişiyoruz bir nevi.
Ama tabii bu hataları her zaman sürekli tekrardan yapmamaya çalışıyoruz.
Komik anımızın... Ufak bir kenarında da şu arda var aslında.
Duvara at location needs index yazmıştı.
Hala trend yolu duvarda durur o mesela.
Benim de komik bir hikayem var aslında.
Ekibe ilk katıldığım dönemde Özge bana body olarak atanmıştı.
Şirketi ekibi tanımamda bana baya yol gösterdi sağ olsun.
İlk task olarak da bana bir retention taskı vermişti.
Yani veri tabanındaki süresi dolmuş dataları temizleyen bir job tanımlamam gerekiyordu.
Sonra ne olduysa oldu. İşte bir retention taskı daha bir task daha derken.
Her serviste expired data temizlemeye başladım.
Bu durum biraz espri konusu oldu tabii.
Kendime The Retentionist demeye başladım.
Ekip de bu lakabı benimsedi.
Toplantılarda bunu The Retentionist yapar gibi şakalar dönmeye başladı.
Yani ekibe yeni katıldım ama kısa sürede veri temizleme konusunda mark yüzü oldum diyebilirim.
Süper. Valla yani bence güzel olmuş.
Hani girdiğin zaman çünkü bizim de ekipte mesela ben başladığım zaman bizim de Delphoi eventler oluyordu.
Böyle işte gönderdiğimiz şimdi Demeter kullanıyoruz.
Ama ilk girdiğim zamanlarda çok sık Delphoi işleri geliyordu.
Bizde de kulakları çınlasın Cuma diye bir arkadaşımız var.
Zamanında bütün Delphoi işleri deneyimli olduğu için ona gidiyordu.
Biz de ona böyle işte Delphoi Master tarzında bir isim falan vermiştik, takmıştık, lakap takmıştık.
O geldi aklıma öyle. Süper.
Peki ekip gelişimi konusunda neler yapıyorsunuz?
Yani böyle içeride sunumlarınız, işte lançerleriniz, aktarımlarınız vesaire oluyor mu?
Ekip olarak aslında gelişime çok önem veriyoruz.
Yani bunun için her hafta belirli tek review sesyonlarımız var.
Ve bunun takibini de Google Sheet üzerinden yapıyoruz.
Orada her tarihte kim ne anlatacak gibi bir plan çıkartıyoruz ortaya.
Bunu da ekiple aslında toplantı yaparak ayarlıyoruz.
Sunum yapmak isteyen arkadaşlarımız o uygun bir hafta seçip adını yazıyor.
Aslında bir tık randevu alır gibi diyebiliriz.
Hem öğrendiklerimizi aktarıyoruz bu seçimlerde hem de ekibe katkı sağlamış oluyoruz.
Ek olarak bir de kişisel hedeflerimiz de var zaten teknik gelişim hedefi.
Bu hedefleri gerçekleştirdikten sonra da yine aynı seçimleri kullanarak aslında ekiple paylaşıyoruz.
Bu da aslında bilgi paylaşımını epey destekleyen bir yapı haline geliyor.
Zaten Trendyol'da çalışmak da aslında ekip gelişimini...
kaçınılmaz kılıyor. O yüzden de sürekli dinamik bir yapımız olduğu için de öğrenmek bizim için kaçınılmaz oluyor ve güzel oluyor diyebilirim.
Kesinlikle katılıyorum.
Her türlü daha iyiye, daha verimli olan yola doğru giderken kendi gelişimimizi hem kendimizin gelişimi, kişisel gelişim hem de takımın gelişimini her türlü desteklememiz gerektiğini ben de düşünüyorum.
Süper. Çok keyifli bir sohbet.
Son olarak da bizim klasik sorumuz olan Ekip eğlenme işini nasıl yapıyor diyebiliriz.
Burada tabii hatırlatacak olursam araba sevdalısı olan ekiplerimiz var.
Nargileci ekiplerimiz var.
İşte mangala giden ekiplerimiz var.
Yemek yemeyi zaten Trendyol'da neredeyse tüm ekip seviyor ama işte bunun tiryakisi olan arkadaşlarımız var, ekiplerimiz var.
Birçok farklı farklı hobisi olan ekiplerimiz var.
Middle Mile Core ekibi eğlenmek için, ekip ruhunu pekiştirmek için neler yapıyor?
Ekip ruhunu pekiştirmek için klasik yöntemlerle başlayıp kendi tarifimizi oluşturduk diyebiliriz.
Öncelikle ekip yemekleri düzenliyoruz.
Ama öyle sıradan yemekler değil tabii.
İşte bol muhabbet ettiğimiz, bol kahkaha attığımız yemekler oluyor genelde.
Sadece yemekle de sınırlı kalmıyor tabii.
Zaman zaman sağ gezilerine çıkıyoruz.
Bu geziler hem sağdaki operasyonları daha iyi anlamamıza hem de birlikte bir şeyler deneyimlerimizle olanaklanıyor.
Ama en eğlenceli kısmı yıl sonunda geliyor.
Ekibimizin enlerini belirlediğimiz bol kahkahalı, bol nostaljili retrolarımız oluyor.
Mesela en çok komit atan, en çok destek atan gibi enleri belirliyoruz hep birlikte.
Özetle biz sadece birlikte kodu yazmıyoruz.
Birlikte yiyoruz, içiyoruz, gülüyoruz.
Bazen aynı nivrelik aletlerini üzülüyoruz.
Kısacası iyi günde, kötü günde tek yürek oluyoruz.
Evet, çok güzel.
Buradan da... Saha gezilerine çıkıyoruz dediğin için neredesin dediğim zaman abi depodayım çalışıyorum ben seni sonra arayayım mı ben sana sonra döneyim mi diyen sevgili diğer hostumuz, co-hostumuz
Fırat'a selamlar iletiyorum.
Kendisi ben depodayım dediği zaman salladığını düşünüyordum.
Benimle konuşmak istemediğini düşünüyordum.
Fakat anlıyorum ki saha gezileri gerçek bir şeymiş.
Fırat'cığım senden tüm kalbimle özür diliyorum buradan da.
Süper. Arkadaşlar çok teşekkür ederim.
Valla benim için çok keyifli bir bölümdü.
Sizin ekibinizi tanımak da gerçekten oldukça güzel oldu benim için.
Çok fazla şey öğrendim sayenizde.
Çok teşekkürler geldiğiniz için.
Biz teşekkür ederiz.
Harika. 80.
bölümde Selam Ekip Podcast serisinde Middle Mile Core, Tex Middle Mile Core ekibi bizlerle beraberdi.
Bir sonraki bölümde başka bir ekiple tekrar görüşüyor olacağız.
Bunun yanında bizim Trendyol Talks adında...
Farklı bir podcast serimiz de var.
O podcast serisinde işte çeşitli konular konuşuyoruz orada, kültürümüzle alakalı.
O podcast serisinde bütün podcast mecralarını da bulabilirsiniz diyeyim.
Kendinize iyi bakın. Bir sonraki bölümde görüşmek üzere.
Bu transkript otomatik olarak çıkarıldı; kayıtla küçük farklar olabilir.