Transkript
Selam ekip, hoş geldiniz. Ben Customer Service ekibinden Fırat Özbolat.
Ben chat ekibinden Barış Özaydı.
Ve ben Checkout Promotion ekibinden Onur Aykaç.
Biz üçümüz teknoloji ekibinde birbirine yakın domenlerde çalışıyoruz.
Bizim çalıştığımız ekipler dışında Trendol'da da 50'ye yakın domen ekibi var.
Her ekip bir startup gibi otonom çalışıyor ve dolayısıyla her ekibin iş dinamiği, kullandığı teknolojiler farklılaşabiliyor.
Ve bu sayede de... Çok farklı problemlere çözüm getirebiliyorlar.
Biz de bu ekibleri aslında dışarıda tanıtabilmek için bir podcast yapmaya karar verdik.
Bugün OMS ekibinden Erdem'i ağırlayacağız.
Öncelikle kendini tanıtması için topu Erdem'e bırakıyorum.
Evet, selamlar. Ben Erdem Erbaş.
Ben de Order Management Sistem'de çalışıyorum Trendyol'da.
Bugün burada bu programın konuğu olmanın haklı gururunu yaşıyorum.
O şekilde. Erdem, bizim üçümüzünde Fırat, Barış ve benim çok yakından çalıştığımız bir ekiple çalışıyor.
OMS ekibinde çalışıyor.
Trendyol da zaten. Trendyol demek order demek.
Order demek her şey demektir.
O yüzden Erdem'le başlayalım dedik.
Erdem biraz order diyoruz, OMS diyoruz.
Sizin ekipte neler yapılıyor?
Bu domain içerisinde neler var?
Biraz bunlardan bahseder misin?
Tabii ki. Order dediğimiz zaten direkt sipariş.
Bizim ekibin Türkçe'ye çevrilmiş resmi de sipariş yönetim sistemi olarak geçiyor.
Sizin sipariş verdikten sonraki yani ödemeyi onayladıktan sonraki siparişinizin yaşadığı bütün hayat döngüsü bizle başlıyor.
Bizde bitiyor. Nasıl biter?
Sipariş verdiniz. Ay yanlış kartla öderim veya ya ben large giyiyordum niye medium söyledim ki çok kilo vereceğimi falan mı düşünüyorum gibi bir karar verirsiniz.
Siparişi iptal edersiniz.
Öyle siparişinizin hayat döngüsü bitebilir.
Veya ürününüz size geldi.
Kalitesini beğenmediniz.
Veya ya ben gerçekten kilo vermişim large aldım ama medium daha güzel olur deyip large'ı iade etmeye çalıştınız.
Bu iadeniz sonlandığı zaman yine bizim sistemimizdeki siparişin hayat döngüsü bitiyor.
Bir siparişin maksimum 2 yıl hayat döngüsü olabiliyor çünkü çoğu garantiler 2 yıl sürüyor.
2 yıl içinde de iade süreci her an başlayıp her an bitebiliyor.
Bizim domen aslında bu kadar özet olarak.
Peki abi o zaman hangi domenlerle veya takımlarla yakın çalışıyorsunuz?
Tabii ki şimdi bu kadar geniş bir yerde çalışınca tabii ki her işi bizim yapmamız mümkün değil.
Yapamayız da zaten çünkü çok fazla iş bilgisi gerektiriyor.
O yüzden farklı ekiplerle yani bir sürü farklı ekiple bağlantılarımız var.
En basitinden müşteri gözüyle bahsedeyim.
Sizin siparişlerinizi gördüğünüz ekranları tamamı biz yapmıyoruz.
Biz bu ekranların arkada bilgisini sağlıyoruz.
Aradaki Storefront ekibi, Zeus ekibi bunları işte müşteriye verebilmek için, sizlerin daha güzel görebilmeniz için ekstra çalışmaları yapıyorlar.
Veya sizin siparişlerinizle alakalı bir şeyler oldu, müşteri hizmetlerinin bu siparişleri görüp sizi daha detaylı bilgilendirmesi gerekir.
veya iptalleri, iadeleri gerçekleştirmeleri gerekir.
Bunun için de Fıratlarla ve Barışlarla beraber daha yakın çalışıyoruz.
Ayrıca e-sipariş aldınız.
Bu sipariş size bir şekilde gelecek.
Bu işlemi sağlayan Delivery ekibiyle çok yakın çalışıyoruz.
Delivery ekibi de özet olarak bizim teslimatlarımızı yöneten, 3.
parti kargo firmalarıyla entegrasyonumuzu sağlayan, iletişimimizi sağlayan bir ekip.
Peki yani Order hakikaten Trendyol'da zaten Trendyol.com'da ana domainlerden birisi de şimdi Order ya.
Kaç kişilik bir ekiple bunu yapıyorsunuz?
İçerideki ekip yapısından biraz bahseder misin?
Son zamanlarda özellikle bayağı değişti sanırım sizin ekibin yapısı.
Aynen yeni gelen projelerle biraz değişebiliyor.
Hatta yani domain büyüdükçe büyüyor.
Belki fark etmişsinizdir.
Yani dinleyenler de fark etmiş olabilir.
Hızlı market siparişleri başladı.
Bunun gibi bir iki hali hazırda devam eden projelerimiz de var.
Bunun için biz kendi içimizde ekibi biraz daha organize etme yoluna gidiyoruz.
Şu an için ekipte 17 kişiyiz toplam olarak.
Evet böyle sürü gibi çok kalabalık diyebilirsiniz.
Fakat yani gerçekten yeterli değil.
Daha fazla insana ihtiyacımız var ve bunun için de gereken aksiyonları alıyoruz.
Ekip dağılımını şöyle anlatayım.
Yaklaşık iki buçuktan üç tane testçi QA arkadaşlar aramızda.
Neden iki buçuktan üç derseniz bir tane testçi arkadaşımız developer olarak kariyerine devam etmek istiyor.
O yüzden yeni gelen bir testçi arkadaşa aktarım yaparken yarı test, yarı developer olarak devam ediyor.
Güzelmiş. Aynen yani bugün fırsatlar da oluyor.
Ya ben test yaptım sıkıldım, development da yapmak istiyorum derseniz tabii ki neden olmasın burası çalışanla güzel imkanlar sağlayabiliyor o konuda.
Bunun yanında bir önceki bahsettiğim konuya bağlı olarak da 12.5'dan 13 kişi developer'ız.
İki adet dedicated yani tamamen front-end'e hizmet veren developer arkadaşımız var.
Geriye kalan 11 kişimiz çoğunlukla back-end'e yoğunlaşıyoruz.
Yanlış saymadıysam iki tane de product'ımızın olması lazım.
Bu product'larımız da bizim iş süreçlerini yönetmemize yardımcı oluyorlar.
Business tarafından gelen istekleri, gelen ihtiyaçları bize daha rahat anlatmamızı sağlıyorlar.
Özet olarak bu şekilde şimdi 17 kişiyiz, 17 kişi bir ekip çok kalabalık diyebilirsiniz.
Fakat işte dediğim gibi yeni bir organize olma yoluna gidiyoruz.
Hani bu 17 kişiden şu an için 2 ekip olarak ayrıldık.
Kalabalık olan tarafta tekrardan ayrılmaya devam edecek.
Ben de tam şeyi soracaktım.
Az önce bahsettiğim ilk tediyadeler işte order'ın kendisi gibi böyle süreçler, paketleme gibi süreçler vardı.
Bütün ekip buna mı dedikeli şekilde çalışıyor diyecektim ama zaten şu an içeride bununla ilgili bir ayrılma var sanırım.
Farklı dikeyler çıkarma gibi.
Aynen. Bu ayrılma var işte.
Bunun ilk adımını o bir ekibe ayırarak başlattık.
Daha fazla kişi aldıkça bu ayrılmaları da devam ettirmek istiyoruz.
Çünkü yani bir dikeye bir kişi bırakıp da hadi Allah'a emanet.
Burası artık sende koçum.
Hadi bismillah deyip gidemeyiz.
Onun yanına en azından orada çalışmaya devam eden bir yani hali hazırda bu ekipte çalışan iki kişi artı yeni gelen bir iki kişi vererek sorumluluğu biraz daha dağıtmak.
geçişi rahatlaştırmak asıl amacımız.
Ben şey soracağım ya. 17 kişi ekip çok büyük ya.
Böyle sabah toplantısı bile bitmez aslında.
Herkes bir dakika konuşsa 17 dakika oluyor.
Herkes bir buçuk dakika konuşsa şu an hesaplayamıyorum ama daha fazlası oluyor.
Böyle 20 dakika falan oluyor. O hiç olmadı yani.
Yani ne zorluklar yaşıyorsunuz böyle çok fazla büyük ekipte?
Ayrılmadan önce senin dediğin gibi zaten sabah bir toplanıyoruz.
Böyle sanki... Hani halı saha maçı ile gidecekmiş gibi.
İki takım birleşik.
Böyle bir toplantıya giriyorduk.
Tabii ki biraz uzun sürüyordu.
Ama işte bu ilk ekibi ayırdıktan sonra o ayrılan ekip şu an nasıl söyleyeyim?
17 kişiydik.
7 kişi bir ekipte, 10 kişi bir ekipte gibi düşünebilirsiniz.
7 kişi olan ekip bayar atladı daha kısa sürüyor.
Bizim için de 10 kişiyiz.
Nereden baksanız yarısına indik.
O bayar atlatıyor.
Kalabalık olunca bir de şu da oluyordu.
E kalabalıksınız, çok işiniz var.
Bir sürü iş, kim hangi işi yapıyor, hangi iş ne süreçte.
Bunları takip etmesi zorlaşıyor.
Takip etmesi zorlaştıkça da insanlar domen hakimiyetini biraz kaybedebiliyor.
Yani bunun gibi zorluklar da yaşıyorduk.
Artı QA arkadaş sayımız biraz az, developer'a göre bakınca.
Yani işler test tarafında biraz beklemeye başlıyor ki onların hiçbir suçu yok.
Yani 15 kişi. Ahak yapıyor.
İki kişi de fazla ne yapsın yani?
Kaleci de yoktur. Kaleci testlerinizi yapmanız lazımdı ya.
Hiç yakışmıyor mu?
Neyse. Bunu sonra konuşuruz.
Şeyi söyleyeyim mi abi o zaman?
Yani büyüyen bir ekipsiniz.
Sürekli işte yeni arkadaşlar aranıza katılıyor.
Peki bu arkadaşlar aranıza katıldığı zaman onların onboarding süreçleri nasıl geçiyor?
Bildiğin kadarıyla zor da bir domain.
İçeri yani o kişi geldiği zaman İşte atıyorum böyle bir şeyiniz var mı?
Şu kadar süre sonra işte production ilk konunu şey yapmış olur, komitlemiş olur vesaire gibi bir şeyiniz var mı?
Ya da o süreci nasıl böyle iyileştirmek için neler yapıyorsunuz?
Tabii ki onlardan da bahsedeyim biraz.
Şimdi direkt böyle taşa yazılı bir şeyimiz yok.
Hani ilk sen geldin, bir hafta içinde production'a kod çıkacaksın gibi bir şeyimiz yok.
Fakat şunu yapmaya çalışıyoruz.
Zaten çoğu işi hani iki developer bir arkadaş bir araya gelip ikisi beraber yapıyor.
Zaten bir işi öğrenmenin en kolay yolu bilen birinden bu işin yolunu yordamını öğrenmektir.
O yüzden bu işi iki kişi yapıyoruz.
Bir kişi zaten daha önceden de orada çalışan, domene biraz daha hakim biri olacak.
Yanına da yeni gelen arkadaşı dahil edip, yani belki de çıkması çok kritik olan bir iş olursa aynı gün, bilemediniz belki ikinci, üçüncü gün bile kodu canlıya çıkıyor olabiliyor.
Zaten ilki çıktıktan sonra gerisi akıyor, direkt gidiyor.
Hiç farkına bile varmıyorsun benim ne kadar kodum çıktı, ne oldu, ne bitti.
Bir bakmışsın zaten productiondaki kodların %25'i.
Ekip kaç kişiyse %10'a her şeyi senden yani.
İpi ucunu kaybedebiliyorsunuz.
Production'a kod çıkma sürecimiz bu şekilde ilerliyor.
Yani dediğim gibi her şeyi oluruna bırakıyoruz.
Tabii ki bu süreci çok geciktirmemeye çalışıyoruz.
Bunun yanında onboarding tabii ki...
Pandemiden önce çok daha güzel oluyordu.
Sonuçta fiziksel olarak bir arada olduğumuz insanlarla kaynaşması çok daha rahat oluyor.
Hani yüz ifadelerinden, neviklerinden insanların bazen anlaması çok daha kolay olabiliyor.
Ama ne yazık ki içinde bulunduğumuz durumdan dolayı çizgisi olarak bir araya gelemiyoruz.
Onun yerine biz de bunları remote olarak yürütmeye çalışıyoruz.
Ne yapıyoruz? Yeni gelen arkadaşın ilk değerisinde genelde böyle update'lere çok odaklanmak yerine işte merhaba ben Erdem, ben Onur.
Ben Onur. Ben Onur. Ekipte üç tane Onur var.
Gibi kendimiz tanıtma yollarına gidiyoruz.
Ve hani adamı yani yeni gelen insanı ilk günden ekibin içerisine katmaya çalışıyoruz.
Onun dışında böyle bazen sigara moraları verip sigara içmek zorunda değilsiniz.
Kahvenizi alıp da gelebilirsiniz.
Çayınızı da sodanızı da ne isterseniz.
Alıp gelip böyle arada küçük modalar verip oralarda da sohbet edip hani gerçekten yeni gelen arkadaşımızı yabancı hissettirmemeye çalışıyoruz.
Yani o şekilde onboarding sürecimizi ilerletmeye çalışıyoruz.
Peki gelen arkadaşa böyle bir ecaili, ecaili, yani muhtemelen Scrum yapıyorsunuz diye tahmin ediyorum.
Scrum implementasyonunuzun nasıl olduğunu falan, boardlar nerededir, iş nasıl gelir, bunları da anlatıyor musun onboarding sürecinde?
Tabii ki zaten yeni başlayan bir arkadaşımız olduğu zaman ona bir tane buddy atıyoruz.
Eğer ofiste olmuş olsaydık sürekli beraber kol kola gezecekleri.
ekibin içinde gezip herkese el sallayıp merhaba arkadaşımız yere geldi diyeceğimiz biri olacaktı.
Fakat işte dediğim gibi bu remote yaparken öyle olmuyor.
Onun yerine şu şekilde oluyor.
Sürekli Zoom'da berabersiniz.
Bir tane kanalınız var.
Birini sohbete atmak istiyorsanız ona direkt bu Zoom linkini veya Meeting linkini paylaşıp ona oraya olabiliyorsunuz.
E tabii ki bu süreçlerden bahsediyoruz.
Developerlar hani development süreçlerinden bahsediyor.
Product arkadaşlarımız İş nasıl gelir?
Nasıl yönlendiririz?
Nasıl analiz ederiz? İşte boardumuz dijital olarak nerede?
Bunun gibi şeyleri anlatıyor.
Yani her şeyin üstünden geçmeye çalışıyoruz.
Fakat tabii ki yani bunları anlamasının alışmasının en iyi yolu bu işin içine girmek de oluyor.
O yüzden abi geldin mi?
Hoş geldin. Onboarding toplantın var mı?
Yok. Gel o zaman hadi işi yapıyoruz.
Bunu da bugün yarın canlıya çıkıyoruz.
Yapıştır gitsin. İşi yaparken neler kullanıyorsunuz?
Teknolojiler, kullandığınız frameworkler, database, queue yapısı.
Nasıl bir yapı var sizin taraftan?
Şöyle backend tarafında uygulamalarımızın domain ağırlıklı olanları yani iş süreçlerini yoğun işlettiklerimiz Java ile yazıyoruz.
Java'nın da Spring Boot Framework'ünü kullanıyoruz.
Zaten en popüler olanlardan biri de bu.
Onun yanında hani çok böyle iş...
bilgisi ağırlığı olmayan projelerimizde Golang kullanıyoruz.
O da yapıştıra gitsin, hızlı olsun, wow gibi bu şekilde ihtiyaçlarımız olan şeylerde kullanıyoruz.
Frontendlerde Micro Frontend mimarisi kullanıyor arkadaşlarımız.
Onunla beraber zaten istedikleri frameworkleri, istedikleri JavaScript frameworklerini kullanıp yazabiliyorlar.
Benim şu an bildiğim bizim ekranlarımızda React ve Vue kullanılıyor.
Database olarak Postgre kullanıyoruz, Couchbase kullanıyoruz ve Cassandra kullanıyoruz.
Yeni projelerimizde genellikle daha çok Couchbase kullanıyoruz.
Hali hazırdan evraldığımız projelerde Postgre.
Cassandra'yı da böyle küçük audit bir projemiz var.
Orada kullanıyoruz. Bu şekilde aslında kullandığımız şeyler.
Trendyol genelinde genelde database konusunda MSSQL var, Postgre var.
NoSQL kullanacaksa Couchbase var.
Ama siz Cassandra'yı tercih ettiniz.
Nasıl tercih ettiniz? Nasıl o yola gittiniz?
POC mi yaptınız? Ona şöyle karar verdik.
Bu Cassandra'yı kullanacağımız proje bizim sipariş üzerinde yapılan işlemleri tutmak için kullanacağımız bir database olacaktı Cassandra.
Hani siparişte adrese eşitliğine zaman nasıl yapılmış?
Neydi? Ne oldu? İptali kim yaptı?
Nasıl yaptı? Nereden yaptı?
Bunun gibi bilgileri tutacaktık.
Yani böyle olunca read ve insert operasyonları çoklukta oluyor.
Update operasyonumuz hiç olmuyor.
Çünkü her bir operasyon yeni bir kayıt kafasıyla gidiyoruz.
Cassandra'da da burada kendini biraz öbür database'lerden ayırıyor.
Çünkü ağırlıklı olarak insert ve read yaptığı zaman performansı gayet güzel oluyor.
Fakat update için çok optimize edilmiş bir database değil.
Biz de bunu okuduk, araştırdık, ettik.
Küçük bir iki POC'ler yaptık.
Kullanabiliyor muyuz? Kullanımı nasıl?
Yeni bir siteye geçmeye değer mi?
Gibisinden küçük... POC'ler yaptık.
Baktık gerçekten işimize yarayabilecek bir şey.
Artı her zaman fırsat var yeni bir şeyle uğraşmayı.
En azından kendi adımla konuşayım.
O yüzden burada Cassandra'yla gitmeyi tercih ettik.
Bu yüzden Cassandra.
Güzel. Şeyi soracağım ben de.
Bu kart, aslında içeride Go dediğin Java kullanıyoruz dedin.
Üst tarafında React vs.
gibi farklı farklı teknolojiler var.
Peki sizin deployment süreçleriniz nasıl ilerliyor acaba?
Türk tool'lar kullanıyorsunuz ya da işte bu deployment süreçlerini hızlandırmak için ya da kaydırmak için kullandığınız şeyler neler?
Hesabımlardan biraz bahsedebilirsen.
Tabii orada continuous development ve continuous integration olarak pipeline'larda GitLab kullanıyoruz.
Zaten GitLab'ı projelerimizi tutmak için de bir reposter olarak kullanıyoruz.
Pipeline'lar da orada. Hepsi bir arada çok güzel bir sinerji yakalıyorlar.
Daha önceden Jenkins kullanıyorduk.
Jenkins'ten GitLab'e geçirdik hepsini.
Arka tarafta bunların üzerinde koştuğu da Kubernetes clusterlarımız var.
Bunlar da bizim orchestration olarak ihtiyacımızı görüyor.
Yani arkada güzel bir stack olduğunu düşünüyorum ben.
GitLab CI kullanması gerçekten rahat bu arada.
Alıştıktan sonra benim için en azından Jenkins'ten çok daha kullanışlı geldi.
Bunları hızlandırmak için ne yapıyoruz?
GitLab'deki süreçlerimizi basitleştiriyoruz.
Pipeline aşamaları kendini...
Bayağı açıklayıcı.
Pipeline dosyaları okuması basit.
En azından okuduğunuz zaman burada ne oluyor ya diye kafanız karışmıyor.
Ne olduğunu açık açık görebiliyorsunuz.
Bu da orada yapmanız gereken herhangi bir işlemi kolaylaştırıyor zaten.
Ve dokumentasyon da gayet iyi.
Communities de gayet iyi. Bu şekilde.
Kesinlikle katılıyorum. Biz de gitle kullanıyoruz.
Bayağı memnunum.
Çok güzel tool gerçekten. Peki abi okey.
Kodumuzu sonuçta diplo ediyoruz ama kodumuzu diplo edene kadar da bunun bir geliştirme aşaması var.
Kodu nasıl geliştiriyorsunuz?
Yani kod review yapıyor musunuz?
Test süreciniz nasıl? Dediğim gibi mesela sektördeki çokça tartışılan konulardan biri.
Herkes yapmak ister ama çoğunluk yapamaz.
Siz yapıyor musunuz mesela? Pay yapıyor musunuz?
Gibi böyle bir sürü sorun varsa.
Tabii onlardan da bahsedeyim biraz.
Zaten dediğim gibi kodu geliştirirken genelde payr olarak gidiyoruz.
Hani böyle çok.
Basit işler olmadığı sürece hani siparişçisine bir tane alan eklenecek.
Genelde basit bir iştir. Buraya iki kişilik iş gücünü harcamaktansa orayı bir kişi tamamen bitirebiliyor.
Fakat böyle hani biraz daha business logic olan şeyler olduğu zaman payer'ı giriyoruz kartlara.
O zaman da zaten payer mi gidiyor cevabını vermiş oluyorum biraz.
Yani kartların %80'de %90'da payer olarak işlerimizi yapıyoruz.
Payroll olarak işini yaptın.
Kodunu yazdın. Güzel.
Direkt mesela bunu göndermiyoruz bu kodu.
Repoya göndermiyoruz.
Bunun öncesinde küçük bir yanımıza bir arkadaşımız daha alıp abi biz böyle bir şey yaptık.
Hani ne düşünürsün?
Olmuş mu? Olmamış mı?
Biz bunu böyle göndersek bize sorar mısın?
Gibisinden sorular sorup onu da görüşlerine alıp öyle gönderiyoruz.
Bu kodu yazdık.
İyi güzel. Review'ını da yaptık.
Gönderdik. Her hafta 2 saatlik sessionlarımız oluyor.
Burada da tamam ekipten 3 kişi kodu gördü ama geri kalanı yani belki kendi bakmıştır belki görmemiştir yoğunluğuna göre değişir.
Burada herkes o hafta yapılan işleri görüp kendi görüşlerini paylaşıyor ve herkes de güncel koda hakim olmuş oluyor.
TDD uygulamaya çalışıyoruz genelde kodları yazarken.
Genelde de uyguluyoruz.
Uygulamadığımız zaman bir payrover'ına genelde abin almayanınca testini yazalım edelim gibisinde atıflarda bulunabiliyor.
Test süreçlerimizde iyi güzel kodu yazdık, development'ını bitirdik, review'ünü yaptık, gönderdik.
Zaten ideal olarak kartlara başladığımızda hem product'la hem de testçi arkadaşlığımızla beraber bir kick-off yapıyoruz.
Bu karttan istenen tam olarak nedir, bu kart yapıldıktan sonra ortaya ne çıkmalı gibisinden.
Zaten bunları yaptıktan sonra testçi arkadaşla sürece hakim olup, geliştirme süreci bittikten sonra direkt test süreçlerini devam ettirebiliyor.
Test süreçleriyle ilgili biz geçtiğimiz aylarda şöyle bir şey yaptık.
Reform ekibinde.
Hakikaten şey problem oluyor.
Developer olarak işte 5 kişi 10 kişi böyle şey yapıyorsun.
Scale ediyorsun ekip olarak.
Fakat test tarafında 2 kişi oluyor maksimum.
3 kişi oluyor belki ve her zaman orada bottleneck oluyor.
Çünkü çok daha fazla iş bitiriyorsun ve o tarafa yığıyorsun.
Mesela in test'te işler birikmeye başlıyor ya.
Onun için şöyle bir şey yapmıştık.
Developer arkadaşlar acceptance testleri testçi arkadaşlarla beraber yazıyorlardı.
Tabi testçi arkadaşa şey değil olması gerekiyor.
Must değil. İşte yazıyorsun mesela.
İkimiz yazıyoruz herhalde. Sonrasında testçi arkadaşa da işte edge case'ler konusunda onu da fikrine alıyoruz.
Ona da soruyoruz. Eğer o bu kadarı okey dediği noktada onu zaten direkt şey yapıyoruz.
Canlıya çıkıyoruz gibi bir yapıya bürümüştük.
Hani o belki de az önce yayının başında da söyledin ya.
O bottleneck olması konusunda işinize yarayabilir.
Acceptance testleri ekip olarak yazması gibi düşünüyorum ben.
Buradan da şeye varacaktım.
Şimdi testler çok önemli.
Test yazıyoruz ama test yaptıktan ne kadar yaparsan yap bir de işinde monitörlük yine yapman gerekiyor.
Çünkü bir şey gözden kaçırdıysan bunu da fark etmen gerekiyor.
Bir alert mekanizması kurman gerekiyor.
Sizin bu tarz mekanizmalarınız var mı?
Neler kullanıyorsunuz burada? Bir şey kaçarsa yakalayabilmek için.
Zaten şirket olarak nivredik kullanıyoruz.
Hepleri monitör etmek için. Buna ne kadar bir yük geliyor?
Bu yüke nasıl karşılık veriyor?
Response time'ları çok yükseldi mi etmedi mi sürekli monitoring olarak bunu kullanabiliyoruz.
Bunun dışında öbür ekiplerle yaptığımız iletişimleri monitör edebilmek için hani her şey tabii ki eşit gibi kollar üzerinden dönmüyor.
Rabbit veya Kafka kullandığımız yerler olabiliyor.
İşte buralardaki queue'larda bekleyen çok fazla mesaj iş var mı gibisinden bu alakaları kurabilmek için Prometheus ve Grafana kullanıyoruz.
Prometheus zaten Grafana'ya datayı aktarıyor.
Prometheus üzerinden de alarmlarınızı kullanıyorsunuz Alert Manager'la.
Veya Grafana üzerinden de kurabiliyorsunuz.
Artı bunları görselleştirebiliyorsunuz.
Biz burada Grafana'yı tercih ediyoruz.
Grafana'dan alertlerinizi tanımlıyoruz.
Zaten Grafana'dan alert tanımladığınız zaman direkt Sile'ye mesaj göndertebiliyorsunuz.
Süper abi. Şeyi merak ettim ben.
Hani monitoring olarak bunları yapıyorsunuz.
Güzel. Peki şey takip ettiğiniz metrikler neler?
Yani şey işte bu...
Az önce saydınız ki throughput'u vs.
takip ediyorsunuz.
Onun dışında takip ettiğiniz bazı metrikler var mı?
Günde kaç sipariş yaratılıyor Erdem?
Şimdi gizli bilgilere girmeyelim Fırat'cığım.
Herkesin domeni kendine.
Ne tür metrikleri takip ediyorsunuz?
Abi şu an zaten bununla alakalı bir çalışma da yapıyoruz.
Elimizde tuttuğumuz bir metrik datası var tabii ki fakat nasıl daha...
Güzel datalar bize daha yararlı datalar tutabiliriz gibi.
Onunla ilgili hatta Fırat'a sormayı unutmuştum.
Soracaktım sizin tuttuğunuz metriklerle alakalı dokümanlar varsa farklı ekiplerden bunları toplayıp kim nedir ne yapıyor bir pazar araştırması yapıyoruz.
Ama bizim kendi şu an tuttuklarımız aralık aralık apilerimize gidip bu monitoring tool'larından average throughput'umuz nedir, response time'ımız nedir, error rate'lerimiz nedir veya kodun
unit test coverage'ı nasıldır.
Veya Sonar Cube tool'unu kullanarak bu kodun kalitesi nasıldır?
Gibi dataları tutuyoruz.
Zaman aralıklarında bunu böldüğümüz zaman zaten şey çıkıyor.
Abi çok yoğunmuşuz.
Test coverage biraz düşmüş.
Çok kabul edilebilir bir şey değil.
Hemen bunu zaten tespit ettiğimiz zaman yazıp bunun kapsama yüzdesini arttırmaya çalışıyoruz.
Her takımın kendi özgü challenge'ları var Trendyol içerisinde.
Checkout mesela sipariş alınamadığında yanıyor.
Sizin böyle challenge'larınız neler?
Nelerle uğraşıyorsunuz? Böyle en uğraştığınız sağlam problemler neler?
Biraz anlatabilir misin? Sizin challenge'ınız ne abi takım olarak?
Yani böyle ne bileyim check out siparişleri alıyor.
Sipariş alamayınca patlıyor falan ya.
Sizdeki challenge'ler neler?
Böyle şu kadar bilmem ne geliyor.
Şunu yapmak zorunda kaldık falan.
Ya da şey kompleks domain olması ya da işte çok fazla...
Client'ınızın olması, çok fazla müşterinizin olması, backlog'un her yerden beslenmesi gibi şeyler de olabilir.
Ortada bir domen olman zaten direkt sipariş deyince çok fazla şeyi kapsıyor ediyor.
O yüzden çok fazla ekiple zaten bağlantımız olduğunu en başlarda söylemiştim.
Genelde zaten bir yazılım yapmaya çalıştığınızda ekstra servislerle bağlantınızı ne kadar azaltabilirseniz o kadar güzel bir şeydir.
Ki uygulamanız tek başına sağlıklı olarak hayatta kalabiliyor olsun.
Fakat bu kadar göbekte olan bir şey olunca bunu yapması gerçekten zor oluyor.
O konuda çok büyük challenge'lar yaşıyoruz.
Hani bir sorun yaşadığımızda farklı ekipleri engellemeden nasıl bunu atlatabiliriz?
Veya farklı bir ekip sorun yaşadığında biz bundan en az nasıl etkilenebiliriz?
Gibisinden bunlar en fazla challenge'lik şeyler oluyor bizim için.
Bunun yanında bir de şu geçtiğimiz zamanlarda bizi çok fazla zorlamıştı.
Trendyol'da eskiden kalma bir adet bir database'ımız var.
Farklı ekipler datayı oradan okuyordu, farklı ekipler datayı bizim sunduğumuz datadan okuyordu.
Bu mesela şirket içinde baya karışıklığa sebep oluyordu.
Bunu ortadan kaldırmaya çalışıyoruz şu an ki datanın gerçek kaynağı tek bir yer olsun.
Tek bir ekip olsun.
Hani oradan gördüm böyle, buradan gördüm böyle gibi eventual consistent yapıdaki sistemlerle karşılaştığımız bu yansıma sürelerinde etkilenmesin kimse.
Bu kapsamda yaptığımız şeyler gerçekten çok çalışık olmuştu.
Ama bir yandan da başardığımız zaman beni en tatmin eden şeylerden biri olmuştu.
Hani ne zamanki bir müşteriye OMS datasından hizmet vermeye başladık.
Ekip olarak yani herkes ekten dört köşeydi.
Hatırlıyorum ya o süreci.
Eğlenceli bir zamandı.
Hemen oraya bir şey konuşayım.
Aslında hani bu... büyük challenge'lardan bahsettim.
Bir de bildiğim kadarıyla siz DDD uyguluyorsunuz.
Aslında trend yolda da hemen hemen yeni yeni böyle tüm ekipler benimsemeye başladı aslında DDD'yi uygulayabilen ekipler diye.
Sizin içinde bildiğim kadarıyla sizin domen için bayağı uygun bir şey.
Siz orada böyle herhangi bir zorlukla karşılaştınız mı ya da size faydalıları neler oldu?
Kısaca biraz ondan da bahsedebilsem.
Kesinlikle zaten bizim domain için bunu kullanması neredeyse yani zorunlu gibi bir şey.
Çünkü DDD dediğin zaman herkes sadece domaine'e odaklanıp domain dilinden konuşmaya başlıyor.
Ve herkesin kafa tek bir yere gidiyor.
Domain küçük olsa bir şekilde belki buradaki farklılaşmaları tolere edebilirsiniz ama domain büyüyünce yani burada farklılaştığı zaman herkes ayrı kafadan konuşmaya başlıyor.
Ortalık çok fena karışıyor.
Yani en basitinden bu konuda bize çok büyük yarar sağladı.
Artı yani mesela biraz önce dediğim gibi bu müşteriye sipariş datasını bizim servis etmeye başlamamıza olanak veren sistemi yaparken tasarlamayı tamamen DDD
olarak ilerlettik.
Hani Event Storming diye bir etkinlik var.
Hani DDD'nin böyle güzel etkinliklerinden, yorucu ve zaman alıcı etkinliklerinden bir tanesi.
Tamamen o event üzerinden, yani o etkinlik üzerinden ilerleyip uygulamamızı en düzgün, en güzel şekilde, en güvenilir şekilde nasıl yaparız?
Full DDD olarak ilerlemeye çalıştık.
Hem kod, hem düşünme, hem de ilerleme aşamalarında denetlemeye çalıştık.
En azından denedik.
Süper abi. Yani Trendol içinde de yayılmaya devam ediyor bu arada DDD.
Şirketin de bu yönde bir girişimi var zaten.
Eğitimler paylaşılıyor sürekli falan.
Güzel bir ortam var içeride. Ben şeyi soracağım.
Benim en sevdiğim aslında Scrum etkinliği Retro'lar.
Çünkü böyle takıma kendini iyileştirmesi için bir fırsat tanıyor.
Bazen de böyle biraz sert geçebiliyor.
Çünkü bazen bir taraf çok göremeyebiliyor bazı şeyleri ve diğer taraflar onu söyleyebiliyor.
Sizin son Retro'nuz nasıl geçti?
Ya açıkçası son Retro, yani son birkaç Retro'muz bizim gayet sessiz, sakin geçti.
Ya ekiple yaklaşık bir, bir buçuk yıldır beraberiz.
Hani gerek bu datavezleri ayırma işi olsun, gerek yeniden yazılmış şeyler olsun.
Birbirimize bayağı kaynaştık.
Artı hani kişisel olarak olan şeyler o kişisel olarak birine karşı düşündüğünüz, söylemek istediğiniz bir şey olursa bunları zaten feedback saçında birbirimize veriyoruz.
Ve hani çok daha etkili oluyor ekibin beraber çalışabilmesi için.
Retro'da genelde yakındığımız şey yani sistemin çalışmasıyla ilgili oluyor.
Hani birbirimizle alakalı ekip içinde yaptığımız şeylerde çok problem yaşamıyoruz.
En büyük yaşadığımız şey şu olabiliyor.
Ya bu sprintte çok fazla kart aldık.
Herkes gerçekten çok yoruldu.
Hani neden böyle yaptık?
Planlamayı daha iyi yapamaz mıydık?
Gibisinden şeyler çıkıyor.
Bunda zaten en basitinden okey puanlamalarımızı daha buna uygun vermeye çalışalım.
Planlamamızı daha uygun yapmaya çalışalım.
Bizim bir sprintte rahatça yapabileceğimiz puan sayısı budur.
Kendimizi çok kasarsak yapabileceğimiz puan sayısı budur.
İşlerin aciliyetine göre bunların ortasında bir nokta bulmaya çalışıp.
Oradan ilerleyelim. Gibisinden maddeler çıkıyor.
Çok güzel, politik bir cevap verdin ama ben biraz daha zorlayacağım buradan.
Yemezler canım. Sence peki takımın kendi böyle retrolarda, az önce Fırat'ın da dediği gibi kendi geliştirmesi için, takımın kendi geliştirmesi için bir fırsat ya.
Sizin takım sence hangi alanda kendini geliştirmesi gerekiyor?
Zor bir soru oldu biraz.
O kadar risk ediyorsun.
Kendi üzerinden cevaplar.
Kendi üzerinden. Zor bir soru bu arada.
Düşünecek olursan takım olarak rutine binmiş bir şekilde sürekli bir şeyleri değiştirmeye çalışıyorsun.
Mesela GitLab geçişi aslında böyleydi değil mi?
CIT'li süreçlerimizi iyileştirmek için ya da Kafka'yı aktif aktif çalışabilmek için yaptığımız bir şeydi.
Ama bir anda sorunca evet biraz insanın aklına gelmeyebiliyor.
Katılıyorum bu konuda. Peki o zaman ben sana çok merak ettiğin başka soruyu soracağım.
Şimdi canlı sistemi böyle ayakta tutmak yine bizim sorumluluklarımızdan birisi.
Zor da bir konu. İşte monitörlükten bahsettik, az önce test süreçlerimizden bahsettik.
Ama illaki bir şeyler kaçıyor abi.
Yani bir şeyler olabiliyor.
Siz peki en son yaşadığınız böyle bir incident hatırlıyor musun?
Ve neydi, neyden kaynaklandı?
Şöyle büyük eğlenceli ekibi böyle tutuşturan bir incidentınız var mı son zamanlardan?
En yakında yaşadığımız aslında yani bakınca öyle çok vav öldürdük patlattık gibisinden değildi.
Biz paketlerimiz üzerinde bir tane alan tutuyoruz.
Bu paketin hızlı market siparişi olduğuna mı yoksa belli saatler arasında teslim edilmesi gerektiğine mi yoksa normal bildiğimiz sıradan bir sipariş olduğuna dair mi?
Hatta benim yaptığım işte oldu bu.
Küçük bir tane bu alanı setlemeyi unuttum.
Şimdi bu alanında kullanan sevgili Fırat ve Barış arkadaşlarımızın ekibi bu siparişleri görüntüleyemedi.
Ama neyse ki bunu çabuk fark ettik.
Gerçi fark etmemizde herhangi bir alarm olmadı.
Normalde sistem için daha kritik olan şeylere alarm kuruyoruz.
Paketlerin oluşmasında sorun çıktığı zaman, ilerlemesinde sıkıntı çıktığı zaman.
Bunun gibi şeyler alarmlarımıza giriyor.
Ama bu bir tane alan gözden kaçmış bir şekilde.
Product arkadaşımız örnek bir siparişe bakarken fark etti.
Hani boş gelmemesi gerekmiyor muydu ya?
Hani ben de yani evet öyle gerekiyordu.
Haklısın hani hemen düzeltelim bir şeyini yapalım.
Hatamızı düzeltelim gibisinden bir yola girdik.
Koddaki yanlış düzelttik.
Onu hemen canlıya çıktık.
Daha sonrasında bu yaklaşık bir gün boyunca canlıda kalmış bir koddu.
Bu bir gün boyunca oluşan bütün paketlerin üzerindeki bu alanları doğru değere set etmeye çalıştık.
Biraz sıkıntılı geçti fakat neyse ki çoğu müşteri siparişi verdiği gün müşteri hizmetleriyle iletişime geçmiyormuş ki çok fazla şey çıkmadan, insanlar fark etmeden bunu çözebildik.
Peki buradan retroya bir madde çıktı mı?
Şunu böyle yapsaydık bunu çözmezdik falan postun ortamını yaptınız mı bunun?
Aynen hatta şeylerde, eksemptoslarda şurada burada yani böyle çok basit hani her alanın.
her değerine bazen bakmayabiliyorsunuz.
Yani ben nasıl set etmediysem köy arkadaş da onu kontrol etmemiş olabiliyor.
Yani bunun gibi fine tuningleri biraz daha ayarlamamıza yol açıyor.
Bunun gibi olaylar. En güzel soruyu ben soracağım.
Gerçi soruldu aslında ama ben şeyi anlatmak istiyorum.
Biz en son ne zaman yaşadık?
Yine bir OMS hapisini kullanmaya karar verdik biz.
Bir tane search filtresi için.
Seri çok güzel çalıştı.
Sonra canlıya aldık. Sonra agentler bize Hiçbir search'u yapamıyoruz demeye başladı.
Biz de kontrol ettik.
Nasıl olabilir böyle bir şey? Yani her şey çok düzgündü.
Sonra denedik. Biz de hata aldık.
Sonra elastik index fail hatası aldık ve geri aldık.
Rollback yaptık. Biz de aslında kendimize buradan sonucunu çıkardık.
Biz demek ki canlıda integration test koşmuyoruz.
Bunu koşmamız lazım. Koşmuş olsaydık müşterilerimiz bunu yaşamazdı.
Ya da preparator tamımız olsaydı bunu yaşamazdık gibi bir şey çıktı bize de.
Bize de ders oldu. Yazımda implementasyondan ziyade aslında bu sürece biraz böyle geriye çekilip ben gündelik rutinde neler yapıyorum, neleri iyileştirebilirim diye düşünmek gerekiyor değil mi?
En çok atladığımız yerlerden birisi bu olabiliyor.
Kodumu yazdım değil, kodumu yazdım, sürecim böyle ama sürecim bir adım ileriye nasıl taşınır?
Evet, genelde CRC süreçlerinden mesela çok şey çıkabiliyor, iyileştirme alanları çıkabiliyor.
Deyip az önce deyip diyemedim.
O zaman şimdi deyip inceden kapatalım mı?
Kapatmayalım mı? Erdem deyip fıkra anlatsın o zaman.
Ya da şarkı söylesin.
Evet. Şarkı söylemekte çok başarılı değilim açıkçası ya.
Ama bu programımızın bir parçası Erdem.
Her zaman. Değil de söylediğim şarkıyı belki.
Erdem çok teşekkürler.
İlk programımızda bizlerle birlikte olduğun için.
Rica ederim ne demek ya.
Benim için gerçekten büyük bir zevkti zaten.
Sizlerle ofiste olsaydık her boş vaktimizde sohbet ediyorduk.
Buraya en azından o sohbet tekrar canlandırmak için güzel bir bahane olmuş oldu.
Asıl ben teşekkür ederim.
Bizim için de çok keyifli oldu.
O zaman programı yavaştan kapatalım.
Bu ilk programımızda...
Biraz böyle biz de heyecanlıydık.
Yani bizi ekşi sözlükte fazla gömmeyin lütfen arkadaşlar.
Umarım da gittikçe biz de daha iyi olacağız diyoruz.
Ve o zaman hoşçakalın diyoruz.
Teşekkürler o zaman. Görüşmek üzere.
Hoşçakalın. Hoşçakalın.
Çok teşekkürler dinlediğiniz için.
Bu transkript otomatik olarak çıkarıldı; kayıtla küçük farklar olabilir.