Transkript
Biz mi giriyoruz? Bu sefer de böyle olsun ya.
Hep biz mi açacağız programı?
Selam ekip. Merhaba.
Herkese yeniden merhaba.
Olurmuş ama bizden influencer.
Bence çok enerjik ve yüksek girdiniz.
Ama biz programı bu kadar yüksek taşıyamayabiliriz.
Her gün böyle yüksek girmen lazım ama.
Bundan sonraki kariyer pedimiz buydu zaten bizim.
Bence çok iyi bir başlangıçtayız şu anda.
O zaman bize kendinizi biraz tanıtır mısınız?
Tabii ben başlayayım istiyorsanız.
Benim adım Ecem. 3 yıldır Trendyol ekibindeyim.
İlk Trendyol'a katıldığım zaman 6 kişilik bir User Checkout Payment ekibindeydim aslında.
Zamanla ekip büyüdükçe biz de daha küçük parçalara bölündük.
Yaklaşık 1,5-2 yıldır Payment tarafındayım.
Buradan önce de yine 2,5 yıl kadar başka bir e-ticaret sitesindekiyeydim.
Bu kadar. Ben de Aslıhan.
Yaklaşık iki yıldır Trendyol'dayım.
Üniversite dördüncü sınıfta stajyer olarak başlamıştım aslında.
Daha sonra full time'a geçtim ve o zamandan beri de Trendyol'dayım.
Daha öncesinde promotion kupon ekibinde çalışıyordum.
Sonrasında rotasyonla beraber payment ekibine geldim.
Bundan sonra da Ecem'le beraber aslında kariyerimizi influencerlik üzerinde devam etmeyi düşünüyoruz.
Bugünü de başlangıcımız olarak planlıyoruz değil mi Ecem?
Kesinlikle. Bizim için ne tarz bir şov hazırladınız peki bugün?
Gerçi influencerların öyle bir kaygısı yok galiba değil mi?
Onlar şov yapmıyor. Evet, influencer ediyorlar.
Umarım faydamız olabilir yani influencer olmamız için.
Bence bayağı bir giriş açısından güzel olacak diye düşünüyorum.
Ya şaka yapıyoruz herkes farkında değil mi?
Korktu. İçimde hep şeyin korkusu var.
Bunlar internette kayıtlı kalacaklar.
Payment influencerları.
Daha sonra çocukları izleyip böyle annelerimiz neymiş.
Çok cringe oldu. Hani Payment konuşacaktınız?
O zaman biraz daha farklı bir konuya gireceğim.
Biraz bir çalıştığınız domeniden bahsedebilir misiniz?
Öncelikle biraz daha ekibi de tanıyabilmek adına Payment ekibi ne yapar?
Ya da benim domain deyince ne anlamalıyız?
Ben tanıtayım ekibi o zaman.
Aslında şöyle düşünebiliriz.
Tepete ürün ekledik.
Adres onaylama sayfasına geldik.
Her şey muhteşem. Ödeme sayfasına geldik.
Bundan sonrası bizim aslında domainimizin sorumluluğunda.
İşte orada ödeme yöntemlerinin gösterilmesi.
Kayıtlı kartlarınız varsa onların gelmesi.
Kartların kaydedilmesi.
Kartların silinmesi tabii ki.
Sonrasında işte kart bilgilerinizi girmeye başladığınız, installmentların listelenmesi, vade farklarının hesaplanması, ödeme yapa bastıktan sonra işte bu ödeme 3D'li mi geçmeli, OTP mi sormalıyız gibi kuralların
işletilmesi bizim tarafımızda.
Tabii ödeme alabilmek için bankalarla entegrasyonlarımız var.
Wallet de bizim için bir ödeme yöntemi.
Wallet'la entegrasyonumuz var.
Strandyolun yurtdışı sistemi var biliyorsunuz.
Strandyolun oradaki ödeme entegrasyonlarıyla da biz ilgileniyoruz.
Daha sonra bir de satış sonrası tarafta bizim akışlarımız var.
İptal, iade, banka sorgulaması gibi ve reconciliation gibi akışlar Payment Domain'in içerisinde yer alıyor.
Kısaca bu şekilde özetleyebiliriz.
Aslında bayağı da bir farklı süreçten bahsettin.
Hangi domenlerle yakın çalışıyorsunuz?
Cem'in de dediği gibi aslında bayağı bir sürecimiz var.
Bu yüzden Trendyol içerisinde birçok ekibe dokunuyoruz biz.
Bu noktada klientlerle direkt iletişimimiz var.
En web olsun, web olsun, iOS ve Android için gelen bir FF olsun.
Direkt olarak ödemenin alınması için ya da kayıtlı kartların çekilmesi için bize geliyorlar.
Bunun dışında check-out ekibiyle bayağı yakın çalışıyoruz.
Sepet oluşturulduktan sonra ödeme başlatıldığı zaman ayrıca başka bir ödeme...
başlatılmasın, sepet bozulmasın diye sepetin laklanması olabilir.
Ya da daha sonrasında biz ödemeyi aldıktan sonra siparişin oluşup oluşmadığını bu mutabakat süreçlerimizde kontrol edebilmek adına siparişi oluştuğunu dinlediğimiz eventler
olsun. Bu tarz şeylerde de check-out ekibiyle beraber çalışıyoruz.
Bir de wallet ekibi var.
Wallet ekibi de aslında Bizim için bir post niteliğinde ödeme alacağımız zaman payment opsiyonu wallet olarak geldiyse wallet ekibine gidiyoruz biz de.
Bir de 3D akışları için ödeme başlatılmadan önce nasıl ilerleyeceği için Ecem'in dediği gibi bunların bazı kuralları var.
Biz de bazıları prefraud ekibinde.
O yüzden onlarla beraber de çalışıyoruz.
Satış sonrası işlemler için de yani siparişlerime girip refund'a tıkladığınız zaman, bir sipariş iadeye tıkladığınız zaman bize bir ekip geliyor.
Ecomcore ekibi onlar da.
O yüzden onlarla da beraber çalışıyoruz.
Bir de dataların analizini yapan Data Warehouse ekibiyle beraber çalışıyoruz.
Onlar da payment raporlamaları için bizimle beraber çalışıyorlar.
En başta da konuştuk daha öncesinde check-out tek ekipken işte ödeme, promosyon, kupon, check-out süreci hepsi tek ekipken.
Sonrasında bölünüyor.
Payment'tan da bildiğim kadarıyla geçen sene olması lazım.
Volt ekibi bölünüyor.
Şimdi de bildiğim kadarıyla kendi içinde de böyle bir şey var.
Çünkü Trendyol ekipler büyüdükçe, feature seti geliştirdikçe artık giderek domenler de kendi içinde bölünmesi gerekiyor.
Bildiğim kadarıyla henüz oldu mu nasıl bir şey oldu onu da tam bilmiyorum ama Payment'taki ekip yapısı nasıl bir ekip şey var?
Back-end developer, front-end developer gibi bakacak olursak ya da kendi içindeki alt domenlere kırılmış durumda mı?
Şöyle, şu an Payment ekibinde 12 kişiyiz.
Bir tane takım liderimiz var, 10 tane developer arkadaşımız var.
Bir tane QA var maalesef, o da benim.
Bir tane de PM'imiz var.
Senin dediğin gibi aslında yakın zamanda ekip içerisinde bir bölünme olmasını planlıyoruz.
Biraz önce de bahsettim ya yurt dışı sistemlerinde ödeme yöntemleri farklılık gösterebiliyor diye.
Burada dedike çalışacak bir ekibin çok daha verimli olacağını düşündüğümüz için yakın zamanda Payment ekibinin içinden de bir International Payment ekibi çıkacak.
Bir şey eklemek istiyorum. Payment ekibi böyle önce büyüyor, sonra içinden bir ekip çıkıyor, bölünüyor.
Bu sırada da 10 kişi ve bir Ecem şeklinde ilerliyoruz.
Bu Ecem'i bayağı bir zorluyor.
Evet ya, zor bir süreç.
Biraz bir şeyden bahsedebilir misin?
Onboarding stratejinizden.
Yeni gelen birisi Payment ekibine başladıktan sonra nelerle karşılaşıyor?
Onu neler bekliyor?
Biz bu süreçte İK ile beraber yakından çalışıyoruz.
Yeni gelecek arkadaş gelmeden önce bize haber veriliyor.
İK ile beraber onun gönderdiği bir egzel oluyor ve bize belirlediği bazı yapmamız gereken şeyler oluyor.
Mesela gelmeden önce yeni gelecek arkadaşı arıyoruz.
Halini hatırını soruyoruz.
Onu biraz rahatlatmaya çalışıyoruz.
Bilgisayarı ulaştı mı nasıl gibi muhabbetler ediyoruz.
Daha sonrasında işe başladığı gün tanışma toplantısı düzenliyoruz.
Hep beraber bütün ekip çayımızı kahvemizi alıyoruz, muhabbet ediyoruz.
Ve daha öncesinde hazırlamış olduğumuz bir aktarım toplantıları planı oluyor.
Bütün ekip hep beraber domeyn aktarımı yapıyoruz.
Aslında bizim domeynimizde neler yapılıyor, süreçlerimiz nasıl işliyor, servislerimizin mimarisi nasıl, ne nerede şeklinde böyle aktarım yapıyoruz.
Bu şekilde aktarım yaptığımız süreçlerin çok faydalı olduğunu düşünmediğimiz için buna ek olarak direkt ilk geldiği günden itibaren araya böyle peer de serpiştirmeye çalışıyoruz.
Bununla beraber aslında gelen arkadaş ilk günden itibaren beraber peer ile birlikte işleri canlıya kadar aslında ilerletiyor.
aslında yeni gelen arkadaşın ekibe adapte olmasını, servislere adapte olmasını daha da kolaylaştırıyor diye düşünüyoruz.
Bir de bu pandemiden dolayı remote çalıştığımız için yeni başlayan arkadaşların bu konuda çok zorlanacağını düşündüğümüz için sonuçta yüz yüze görüşemiyoruz, şakalaşamıyoruz.
Bu yüzden onların feedbacklerini alıp bu süreçte neleri daha iyileştirebiliriz diye sürekli ithal etmeye çalışıyoruz.
Team leadimiz, menajerimiz ve direktörümüzle birlikte birebirler düzenliyoruz.
Onlardan aldığımız feedbacklerle bu süreci geliştirmeye çalışıyoruz.
Bir de aslında gelmeden önce böyle bir doküman hazırlıyoruz.
Bütün aslında ekip içerisinde bir şeyi unuttuğumuzda da dönüp bakabilmek adına bizim için faydalı oluyor.
Bir payment wiki'miz var.
Böyle günlük operasyonel yaptığımız işleri oraya aktarıyoruz.
Biri bir iş aldığı zaman ya da operasyonel iş tekrardan geldiği zaman yeni başlayacak arkadaşlar için de faydalı oluyor.
Domain sözlüklerimiz var.
Domain sözlüğüne dersek de mesela bizim domainin içinde böyle çok sık kullanılan business'ın gerektirdiği bazı kelimeler oluyor.
Örneğin bin kod gibi. Kredi kartımın ilk altıhanesi şeklinde böyle açıklama yapıyoruz.
Oradan da aradığımız şeyleri bulabiliyoruz.
Bu şekilde yeni gelen arkadaşlarımızı onboard etmeye çalışıyoruz.
Yeni gelen arkadaşlardan feedback aldığınızı söylemiştim.
Böyle geliştirmemiz gereken bir yer çıkan bir feedback oldu mu?
Evet oldu. Yeni servisler yazmıştık.
Bu süreçte eski kalan Lucidchart diagramları vardı.
Eskiden bir A servisi B servisine gidiyormuş bir işi yapmak için.
Ama aslında biz orayı yenilemişiz ve C servisine gidiyor artık.
Bunları değiştirmeyi unutmuşuz bazı şeyleri aslında.
Onunla ilgili bir feedback almıştık.
Ondan sonra dokümanları daha sık güncellemeye başladık.
Süpermiş. Bu siteleri güncel tutmak gerçekten ciddi bir dert.
Genelde çünkü iş yaptıktan sonra unutulan yerlerden biri oluyor.
Kullandığınız teknolojiler neler?
Yani Trendol genelinde belli baş teknolojiler kullanılıyor ama siz neleri seçtiniz ve neden bunları seçtiniz?
Tabii. Biz aslında Payment ekibi olarak Trendyol'un başından beri aslında adı konulmasa da devam eden süreçleri kapsıyoruz.
Bu yüzden elimizde Legacy'den kalan böyle birkaç tane API'miz var.
Bunlardan bir tanesi Payment API.
Şu an .NET projesi ama biz scale problemleri nedeniyle onu yeni yazdığımız bir ödeme sistemi var.
Ona geçirmeyi planlıyoruz.
Yakın bir zamanda. Onun dışında yeni yazdığımız projelerde genellikle Java'yı kullanmaya çalışıyoruz.
Ama bu Java'yı daha çok kompleks domain lojikleri içeren projelerde kullanıyoruz.
Consumer gibi ya da sadece data çekmek gibi olan projelerde Go'yu tercih ediyoruz.
Bir de Node.js projemiz var şu an.
Onun dışında...
Message Broker olarak şu anda RabbitMQ da kullanıyoruz, Kafka da kullanıyoruz ama şirketin Kafka'ya dönme şeklinde bir süreci var.
Biz de yavaş yavaş süreçlerimizi Kafka'ya geçiriyoruz.
Onun dışında GitLab kullanıyoruz.
GitLab'ın da yakın zamanda geçtik aslında ama bizim için bayağı işleri kolaylaştırdı.
Yani hem kodu görüyorsun, hem pipeline'ları görüyorsun, hem deployment'ları aynı yerden yapabiliyorsun ya da rollback yapabiliyorsun.
açıkçası bizim için çok faydalı oldu.
İşler için de, işleri takip etmek için de Jira'yı kullanıyoruz.
Tabii biz çok efektif kullanamasak da Evrim bize bu konuda destek oluyor.
İşlerin takibi için ya da böyle ufak raporlamalar için de Jira'yı kullanıyoruz.
DB tarafında da Couchbase ve MSSQL kullanıyoruz.
Writes'ın çok yoğun olmadığı yerlerde, read yaptığımız yerlerde, multi-dc olacak projelerde şey kullanıyoruz.
Write yoksa MS SQL kullanıyoruz ama şu an genel olarak Couchbase'e geçiriyoruz.
Test tarafında ise Ecem'le beraber ortak bir dil kullanmak adına Java'yı kullanıyoruz ve TestNG framework'ını kullanıyoruz.
Ön yüz testleri içinde yeni bir POC aşamasındayız.
Cypress'i deniyoruz. Peki Node.js dediğin Node.js'i nerede kullanıyorsunuz ve ön yüz dediğin bu kayıtlı kartların listelenmesi?
Installment'lar, taksitler gibi yerler mi?
Evet. Kayıtlı kartların sunulduğu bir secure bir projemiz var.
Payment Gateway. Node.js projemiz o şu anda.
Kayıtlı kartların getirildiği yer, ekran diyelim.
Installment'ların getirildiği ekranı oradan servis ediyoruz.
Yani direkt client'la aslında backend arasında başka bir DFF gibi bir şey olmamış oluyor.
Galiba bir yandan da regulasyon sanırım değil mi?
Evet. Secure VLAN'dan sağlanması gerektiği için bizim tarafımız.
Doğru. Bir de öyle de bir şey var.
Normaldeki klasterlardan farklı bir yerde olması gerekiyor.
Secure VLAN'da olması gerekiyor bunların.
Öyle bir durum da var.
Evet evet. Regulatif açıdan hassas dataların, örneğin kart datası gibi dataların geçtiği projelerimizi Secure VLAN'da tutuyoruz.
Erişimin kısıtlı olduğu bir VLAN diyebiliriz.
Erişimleri sanırım sadece bizim ekip ve volut ekibinin olması lazım.
Diğer ekiplerden bu Secure VLAN'a erişim yok diyebiliyorum.
Peki ne kadar sürede bir deployment yapıyorsunuz?
O 4K metrikteki deployment frekansı hiç ölçtünüz mü?
Her gün deployment yapmaya çalışıyoruz aslında ve her günde yapıyoruz en az bir kere.
Ama birden fazla yaptığımız da oluyor.
Aslında o hafta sprint'e aldığımız işlerin büyüklüğüne göre birazcık da değişiyor bu durum.
Bir ödeme ekibi olduğumuz için işte işleri alırken ve...
feature toggle'la yapmaya çalışıyoruz.
Çünkü müşteriyi direkt etkileyen bir noktadayız ve böyle büyük incident'ları sebep olmak istemiyoruz.
Genelde bir sprint takışı şöyle oluyor bir deployment süreci.
Biz haftalık sprint yapıyoruz.
İşte kodlama kısmı bittikten sonra kod review kısmı başlıyor.
İki tane onay aldıktan sonra kod master'a çıkıyor ve o aşamada acceptance testlerimiz çalışıyor.
Testler zaten fail olursa pipeline kırılıyor.
Hiç proda çıkamıyor. Ama testlerinde geçtiğini düşünürsek prod için hazır hale geliyor.
Deployment'tan sonra şöyle bir aşamamız var aslında pipeline'ımızda.
İşte release tag atayıp 4K metric datalarını çıkartan bir kısım var pipeline'ımızda ve grafana üzerinden dashboardlardan takip ediyoruz bunları.
Her sprint sonunda bir KPI toplantısı düzenliyoruz ekipçe.
Bu KPI toplantısında işte O hafta ne kadar diplomat çıktık?
Bu çıktığımız diplomatlardan kaçı gerçekten featured?
Ne kadar bizim bug fiximiz, production fiximiz vardı?
İşte bir işin lead time'ı ne kadardı production'a çıkan?
çıkarken gibi dataları kontrol ediyoruz.
Aynı zamanda o sprint'e çıkan sprint development bug'ları da kontrol ediyoruz.
Bu KPI toplantıları aslında bizim için bayağı yararlı oluyor.
Çünkü buradan çok güzel retro maddeleri çıkartıyoruz.
Gerçekten bizi bloklayan şey neydi?
Doğru mu analiz yapamadık?
İşte bir prod'da bug çıktıysa düzgün mü test edemedik?
Unit testi mi eksikti?
Acceptance testi mi eksikti?
Ecem kötü mü test yaptı?
Falan gibi böyle bayağı yararlı olduğunu düşünüyoruz.
Genel olarak bir Deployment sürecimiz bu şekilde gerçekleşiyor.
Deployment süreçleriniz bayağı güzelmiş.
Oturmuş yani yerine. Şeyi sormak istiyorum ben de.
Biraz böyle az önce şeyden bahsetmiştim.
International'ın tarafta da olduğunuzdan bahsetmiştim.
Bir de Türkiye'ye ayağı var. Yani 24 saat aslında üzerinde yük olan bir sistem üzerinde çalışıyorsunuz.
Böyle olunca kalitede ilk önceliklerinizden birisidir diye düşünüyorum.
Biraz böyle buradaki süreçten bahsedebilir misiniz?
Yapıyor musunuz TDD ya da peer uyguluyor musunuz?
Burada hangi pratikleri uyguluyorsunuz acaba?
Biz bir işi yapıyorken aslında genel olarak peer şekilde gitmeye çalışıyoruz.
Peerleri de TDD şeklinde ilerletmeye çalışıyoruz.
Bunu da ping pong yaparak aslında sağlıyoruz.
Ping pong ne dersek de bir arkadaşımız peerde geçmeyen fail bir unit test yazıyor aslında.
Sonra diğer arkadaşımız alıp testi geçirmeye çalışıyor.
Sonra da Pay'il bir test daha yazarak diğer arkadaşa bırakıyor.
O da aynı şekilde testi geçirip yeniden yazıp bu şekilde devam ettiriyoruz.
Pay'ir olduğumuz süreçlerde bu şekilde ilerlediğimizde aslında iki tarafın da sürece çok daha iyi katıldığını gözlemledik.
O yüzden Pay'irken genelde bu şekilde ilerlemeye çalışıyoruz.
Yazdığımız kodlarda da Genelde clean koda ya da solid prensiplerine uymaya çalışıyoruz ve yazdığımız her kod içinde mutlaka unit test yazmaya çalışıyoruz.
Çünkü yani unit test yazmazsak bir şeyleri kavuramazsak gözden kaçan bir şeyler olma ihtimali çok daha arttığı için ve kritik bir domayında olduğumuz için aslında bizim için çok önemli bir hale geliyor.
Bu yüzden de...
Bir PR açtığımızda unit testlerin olup olmadığını çok daha fazla kontrol ediyoruz ve önem gösteriyoruz.
Zaten olmadığı zaman pipeline kırılıyor coverage'i düşürdüğümüz zaman.
Bu süreçte versiyonlama yaklaşımı olarak da git flow kullanıyoruz.
Ama yakın zamanda böyle trunk base'e geçmeye çalışıyoruz.
Bunun için de ufak ufak denemelere başladık.
Aslında böyle her gün commit atıp her gün...
Daha fazla bir şeyleri done ettik bunu hissetmek için trunk base'e geçmeye çalışıyoruz bu noktada da.
Bir de ben şundan bahsetmek istiyorum.
Payment ekibi olduğumuz için aslında OVAS top 10'i de çok sıkı takip etmemiz gerekiyor.
Bunu gerek security ekibi olsun gerek biz olalım.
Sıklıkla takip edip aslında bize bir probleme yol açacak bir şey var mı?
Süreçlerimizi gözden geçirmece şeklinde ilerliyoruz.
Bu yüzden de az önce bahsetmiştik ya, secure ortam diye.
Baştan sona kadar da aslında secure ortamı kullanıyoruz bu süreçlerde.
Ecem de belki biraz test tarafından bahsedebilir, integration testler nasıl ilerliyor şeklinde.
Tabii, ben de biraz test...
kısmını anlatayım. Aslında test süreçleri planlama aşamasında başlıyor bizde.
Bir işi alırken onun acceptance kriteriyelerini, test case'lerinizi de çıkartıyoruz o aşamada.
Çünkü son 5-6 aydır işte hep diyoruz ya trunk base'e geçmeye çalışıyoruz, pipeline'ımıza çok güvenmeliyiz, işte testlerimiz güvenilir olmalı, coverage'ı çok yüksek olmalı falan.
Ekipçe ne yapabiliriz diye düşündük ve developer arkadaşlarımız da test yazmaya başladı.
Integration test kısmında hep birlikte ilerliyoruz.
O yüzden planlama kısmında test case'lerin bir kısmını oluşturuyoruz.
Sonrasında aynı işte development projelerinde olduğu gibi bir kod review aşaması orada da oluyor.
Eksik bir case varsa daha sonradan aklımıza bir şey geldiyse onları ekleyip ilerliyoruz.
Mutlaka proda bir kod almadan önce testlerin yazılmış olmasını bekliyoruz ekip içerisinde.
Bir de tabii yük testlerimiz var.
Eğer sistemi etkileyeceğini düşündüğümüz bir iş çıkıyorsak öncesinde ve sonrasında mutlaka yük testi koşup sonuçlarını karşılaştırıyoruz.
Bence bu remote çalışmanın en büyük katkılarından bir tanesi de bu oldu.
Eskiden şirkete gidip test koşmak daha böyle maliyetle gelirken şimdi evden test koşabiliyoruz.
O artı oldu bence bu yönde bütün ekip içerisinde.
Bazen gerçi test koşarken uyuyan arkadaşlarımız oluyor akşamları ama uyuyakalanlar ve sesini kapatmayı unutanlar.
Evet, yani bu remote çalışmanın bize böyle bir getirisi de oldu.
Genel olarak bu şekilde test süreçlerimiz.
Böyle takip ettiğiniz bir sürü metrik vardır.
Çünkü hani sipariş sayısının azalması ya da işte bankalardan alınacak hataların artması sizi çok doğrudan etkiliyordur.
Burada size monitoring ve alortik mekanizmalarını soracağım.
Diyelim bir incident oldu, bunları nasıl yakalıyorsunuz?
Biz de dediğim gibi aslında bayağı bir alarmlarımızı takip ediyoruz.
Bu alarmlarımız neler? Nivrelik üzerinde alarmlar tutuyoruz.
Bunlar response time'ların yükselmesi olabilir, throughput düşmesi olabilir, error rate'in artması olabilir.
Ya da kibana ve grey log'da attığımız error log'larının belirli bir sayının üzerine çıkması olabilir.
Ya da bizim customize ettiğimiz grafana üzerinden takip ettiğimiz bazı metrikler var.
Bunlar olabilir. Bunlar belirli threshold'ları getiriyor.
Geçtiği zaman Slack üzerinden bize alarmlar düşüyor.
Ve biz aslında ekip içerisinde haftalık olarak nöbetçi belirliyoruz.
Nöbetçinin o haftaki öncelikli işi bu alarmları takip etmek oluyor.
Tabii ki sprint işlerini de yapmaya devam ediyor.
Sadece ekran izlemiyor ama öncelikli olarak onları da takip ediyor oluyor.
Bu süreçte tabii ki bütün ekip de bunları takip ediyor oluyor.
Ama nöbetçi direkt müdahalede bulunuyor.
O an çok yoğunsa ekip arkadaşlarımızdan birine paslıyoruz.
Bu şekilde alarmlarla beraber direkt haberdar olmaya çalışıyoruz.
Hatta buna ek olarak da son zamanlarda Payment ve Checkout ekibiyle birlikte PagerDuty denilen bir on-call uygulaması, incident management uygulamasını da deniyoruz.
Onda bayağı faydası olacak, bayağı da güzel bir uygulama gibi.
Peki şimdi baktığımız zaman bankalarla entegre oluyorsunuz ki böyle entegrasyon çok zor bir iştir.
Oradaki rezervliğinizi çok zor bir iştir, bir problemdir o.
Secure olması gerekiyor doğal olarak.
Az önce Barış'ın da dediği gibi direkt order sayısını etkileyecek bir konudan bahsediyoruz.
Siz böyle overall da bakıyorsak eğer Payment ekibinin en büyük challenge nedir?
En çok aslında kafa yormanız gereken tek bir şey seçseydiniz bu ne olurdu?
Buna ben cevap vereyim.
Trendyol sistemi biliyorsunuz her geçen gün daha fazla throughput alıyor.
Daha fazla kullanıcıya ulaşıyoruz ve dolayısıyla daha fazla ödeme isteği alıyoruz.
Bizi bu noktada en çok zorlayan kısım o bankalarla entegrasyon aşamasında yaşadığımız sıkıntılar.
Yani bankaların response time'ları bazen çok yükseklere çıkıyor, error rate'leri çok yükseklere çıkıyor ve sizin her zaman bir BC planınız olması gerekiyor bu aşamada.
Yani A bankasından ödeme alamıyorum diye akışı kesmememiz lazım.
Bu noktada...
Aslında bu son bir yılda çok büyük gelişme katettik.
İlk başlarda ben ilk işte trend yola başladığım zaman o hangi posttan ödeme geçeceğimize karar verdiğimiz yapı 6-7 tane böyle database tablosunun birbirine bağlanmış haliyle çok kompleks bir
yapıydı. Önce onu bir sadeleştirdik, yeniden dizayn ettik.
Sonra da bu sene Kasım eventinden önce devreye post switch denilen bir mekanizma koyduk.
Bu nasıl çalışıyor aslında?
Kısaca ondan bahsedebilirim.
A bankasının response time'ları çok arttı diyelim.
Biz bunu işte ya installmentlarını kapatıyoruz ya da A bankasını B bankasına switch edeceğimiz böyle bir iki saniyede yapabileceğimiz bir yapı geliştirdik.
Çünkü gerçekten böyle event dönemlerinde bazen 15-20 saniyelere varan ödeme istekleri olabiliyor ve bu sistemi kitliyor bir noktadan sonra.
Bir de inanılmaz bir müşteri memnuniyetsizliğine neden oluyor.
Bunu hızlı bir şekilde çözmemiz gerekiyor.
Bunun dışında işte yine bu banka entegrasyonlarından kaynaklı ya da entegratörlerden kaynaklı timeout aldığımız veya başarılı olduğu halde bize başarısız dönebildiği az da olsa case'ler yaşıyoruz.
Bunun için de arkadan çalışan bir reconciliation yapımız var.
Bu ne işe yarıyor? Aslında temelde şunu yapıyor.
İşte siparişi oluşturduk diyelim.
Trendyol'dan geçen her sipariş için.
Gidiyor daha sonrasında bankayla mutabakat kuruyor.
İşte bende para yok, sende de yok değil mi?
Bende var, sende de var gibi diye.
Ve eğer bir tutarsızlık olursa arkadan otorifat yapıyoruz.
Bu şekilde bunlar için önlemler almaya çalışıyoruz aslında.
Zor bir challenge gerçekten.
Şeyi merak ediyorum ben de bu retrospective toplantılarında son neler konuştunuz ve işte oradan nasıl bir aksiyon aldınız?
Biz bu retro konusunda aslında çok gülüyoruz.
Ecem her seferinde, biz retroları sırayla yönetiyoruz.
Ecem her seferinde bize retro tool'unu attığı zaman lütfen bu sefer kanlı geçsin, hadi kanlı bir şeyler olsun falan diye zorluyor ama hiç kanlı retro geçiremedik.
Hiç kimse bana uymuyor ekipteki maalesef.
Olsun ama Ecem ne yapalım?
Ama son zamanlarda odaklandığımız bir nokta oldu sorunun cevabına gelirsek.
Biz PR'ları açtığımız zaman çok fazla CodeReview'de beklediğini fark ettik.
Bütün arkadaşlardan aslında bu yönde bir feedback gelmişti.
Daha sonrasında incelediğimiz zaman PR'ların büyük olduğunu keşfettik.
Legacy projelerimiz de olduğu için bir yandan bir şeyler yazıyorken başka yerlere de dokunmamız gerekiyordu, refaktör yapmamız gerekiyor.
Ya da bir şeyleri geliştiriyorken başka yerlere gerçekten dokunmamız gerekli oluyordu.
Şöyle bir karar aldık aksiyon olarak da.
Refaktör yapacaksak daha önceden refaktörü yapalım, bunun PR'ini açalım hızlı bir şekilde.
Daha sonrasında bizzat işine başlayalım.
Onun PR'i ayrı olsun, okumak daha kolay olur diye düşündük.
Kalıcı çözüm için de aslında daha önce bahsetmiştim trend base'e geçmeye çalışıyoruz.
Daha küçük PR'ler, daha okunabilir PR'ler olması açısından.
Bu şekilde de bir aksiyon almış olduk.
Retro'nun tabii en büyük malzemelerinden bir tanesi incidentlar.
Canlı sistemi en son ne zaman patlattınız?
Öyle ne zaman serenler çalmaya başladı ve ödeme alamıyoruz, şu an siparişler geçmiyor lafını duyduk.
Bugünün en güzel sorusu bu galiba.
Ödeme ile ilgili değil de yakınlarda yaşadığımız bir incidentı anlatmak istiyorum.
Bizim bir tane post payment operation adında bir API'miz var.
Temelde bunu işte banka iptal, iade süreçleri için.
Ama zamanla böyle gelişen değişen istekler gelen istekler doğrusunda işte trend yol içerisindeki ekiplere ödemenin alıp alınmadığını dönen bir end point
ekledik. İşte gelip sorgulanabileceği şirket içerisindeki başka ekipler de kullanıyor.
Neyse biz refund için bir şey yaparken bu API'yi indirdik aşağı.
Ve hani şey düşünüyorduk sadece işte refund zaten iptal iade.
Asenkron bir akış bir 10-15 dakika sonra toplarız diye düşünürken bu bize ödemeyi sorgulamaya gelen ekiplerinden dolayı işte sipariş akışını kadar etkileyen böyle bir
zincirleme hatalar silsilesine dönüştü her şey ve korkunç bir hale geldi.
Bundan sonrasında da şöyle bir karar aldık yani bu API'yi ikiye bölmemiz gerekiyor.
Query ve işte refund işlemleri için ayrı ayrı öyle bir incident geçirdik çok yakın bir zamanda.
Çok geçmiş olsun. İnsanın bu işin kaderinde var galiba yani.
Evet ama çok olmuyor yani.
Sağlık olsun. Ecem hele de sen yani.
Kır ya ne olacak git.
Şey yaptım şu an. Devdeki kodu canlı yaptım.
Çünkü Ecem yayının başında yaptığım sihir numarasına ilk defa Ecem şey oldu böyle gözler üstü nasıl oldu falan oldu.
Canım sağ olsun Ecem.
Ama çok etkileyiciydi.
İnsanlar sihire aç.
Ben gülmedim diye devdeki kodu burada almayayım mı yani?
Sen iyice test et.
O zaman Ecem söz verdiğin gibi bir kuple şarkıyı da okursan programı ufaktan kapatabiliriz sanki.
Ben asla yani çok kötü.
Bunlar bir de internette kalacak biliyorsunuz çok kötü.
Ecem. Gerçekten yani.
Bir kuple. O kadar kötü ki yani.
Çok kötü. Olsun ya. Ya şarkı okumasın da.
Ecem'in Osman'a yazdığı bir şarkı var.
Bizim takım liderimize.
Kendileri çok iyi arkadaşlar.
Bence onu söylesin.
Çok daha güzel. Merak uyandırdı.
Osman beni siler yani.
Biz şarkı söyleme diyoruz.
Ecem şarkı besteliyormuş.
O da o kadar kötü ki.
Çocuk şarkısı yazdım Osman'a.
Ve böyle tanışmamızın üzerinden bir hafta falan geçmişti bunu yaptığımda.
Çok güzel. Çok güzel.
Lütfen. Biz okur musun bu şeyleri?
Kafamıza bir cevap ver. Peki evet.
Sanki Osman'a değil de başka birine yazmışsın gibi söyle.
Bir kelime de yok mesela.
Şöyle başlıyor. Hani anladın mı?
Aşırı kötü. Ne olur bana bu eziyeti yapmayın.
Öyle deme ya. Böyle şeyin içerisinde de böyle filmlerde de vardır ya.
Aşırı kötüdür ama o kötülüğü seni filmin içinde tutar.
İzlersin de şarkı falan vardır.
Bunların bir türü var hatta. Böyle bir şiir de olabilir yani.
İnfluencer olmak için. Yani sadece influencerlık şey değil.
Arkadaşlar aşağıda ürünler var değil yani.
Kontent de lazım. Ya ben size şey kapatınca söyleyeceğim.
Tamam. Biz de sanki kaydetmiyormuş gibi şey yaparız.
Vallahi olmaz yani.
O zaman kapattık mı? Evet arkadaşlar.
Gerçekten çok kötüsünüz lütfen.
Kapattık programı artık okuyabilir miyiz?
Evet evet artık. Görüyorum.
Bu kız kire kandıramazsınız.
Evet ya. Biz çok deniyoruz.
Peki o zaman.
Sağlık olsun. Geldiğiniz için çok çok teşekkürler arkadaşlar.
Çok keyifli bir program oldu. Evet.
Biz çok teşekkür ederiz.
Çok teşekkürler. Baştan alalım.
Biz çok teşekkür ederiz.
Hayır bir daha teşekkür ederiz.
Hayır. Şiir yazacağım.
Ya Onur var ya Osman beni mahvedecek ya.
Beni mahvettiniz hep birlikte.
Bence Ecem beni mahvedecek esas.
Söylemedin ki zaten. Başını söylemem bile onun için yeterliydi bence.
Ona şarkı yazdığımın bilinmesi bile yeterliydi.
Söyleseydin keşke Zorna'dan paylaşırdık en azından.
Programı kapattıktan sonra şarkıyı şey yaparız, şiiri alırız, ayrıca kaydedip paylaşırız.
O zaman hep beraber hoşçakalalım.
Hoşçakalın. Hoşçakalın.
Bu transkript otomatik olarak çıkarıldı; kayıtla küçük farklar olabilir.