Selam Ekip - E84 - Data Reliability

Selam ekip, ben Storefront Web Search ekibinden Cengiz.

Teknoloji ekiblerini tanıdığımız ve süreçler, teknolojiler gibi konuları konuştuğumuz Selam Ekip Podcast serisinin 84.

bölümündeyiz. Ve 84.

bölümde Data Reliability ekibiyle beraberiz.

Bu ekibi tanıyacağız, kullanılan teknolojiler, ekip yapısı, pratikler gibi konuları konuşacağız.

Arkadaşlar hepiniz hoş geldiniz.

Hoş bulduk abi. Süper.

Bugünkü ekibimiz...

Data Reliability yine çok güzel şeyler öğreneceğimizi, çok güzel insanlarla tanışacağımızı düşünüyorum.

Arkadaşlar kendinizi kısaca tanıtabilir misiniz?

Selamlar herkese, Çağdaş ben.

Yaklaşık 3 senedir Trendyol'da DBH Development ekibinde developer olarak çalışıyorum.

Toplamda da yaklaşık 5 senedir bu sektördeyim.

Selamlar, ben de Fikri.

Ben de bir yılı part-time, iki buçuk yıl full-time olmak üzere yaklaşık üç buçuk yıldır Trendyol'dayım.

Aynı şekilde DVH ekibinde developer olarak görev almaktayım.

Yani sektöre burada başladım ve burada devam ediyor diyebilirim.

Selamlar, ben Emir.

Yaklaşık iki yıldır Trendyol'a DVH ekibinde data developer olarak çalışıyorum.

Burası benim ilk işlerim aynı zamanda.

Selamlar, Cihangir ben de.

Ben de iki yıldır Trendyol'da data developer olarak çalışıyorum.

Burası benim data alanındaki ilk iş deneyimim.

Farklı bir alandan geçtim diyeyim.

Süper arkadaşlar tekrar hoş geldiniz.

Aslında biraz diverse bir ekiple beraberiz.

Yani biraz böyle işte her şeyden, her deneyimden olan bir ekiple beraberiz.

Şimdi Data Reliability isimden de aslında birazcık bir şeyler bize anlatıyor ama biraz hikayesini de dinlemek istiyorum.

Data Reliability ekibi nasıl kuruldu, nasıl bir hikayesi var?

Trendyol'daki sorumluluğu tam olarak nedir?

Yani aslında Trendyol'daki sorumluluğundan başlamam gerekirse Data Quality ve Reliability konuları bizim DVH özelinde ele aldığımız konulardı.

Ama her zaman gündemimizde de olan bir konuydu.

DVH ekibi olarak verilerimiz üzerinde sürekli Data Quality rule'ları çalıştırmaya özen gösteriyorduk.

Yeni kurduğumuz her pipeline'da ister Near Real Time ister T-1 akışı olsun DQ rule'larını tanımlamaya özen gösteriyorduk.

Sonrasında bu ihtiyacın platformlaşması ve tren yol geneline yayılması için Diğer ekiplerin de kendi verileri üzerinde anomallerini tespit yapabilmesi için as a service olarak bir

hizmet sunabilir miyiz sorusu belirdi akıllarımızda.

Yani aslında bu amaçla takımımız kuruldu diyebilirim.

DVH'den başlayıp bütün trend yola yayıldık.

Reliability konularını örneğin PolicyTech, Data Catalog, Data Observability Platform bizim sorumlulukla yürütmekle sorumlu olduğumuz işlerden bazıları diyebilirim.

Hani data quality deyince aklımıza sadece tablodaki veri gelmesin.

Mesela farklı ekiplerdeki ihtiyaçlar farklılaşabiliyor.

Yani yine örnek vermem gerekirse Kafka legleri veya herhangi bir inframetri üzerinde de data quality yani anomali tespiti yapabiliyoruz.

Pipeline'larımızı bozan her veri için reliability'yi sağlamak ve ekiplere destek olmak istiyoruz.

Aslında bakış açımız ekipler artık veri sorunlarını sonradan fark etmek yerine gerçek zamanlı olarak takip edebilip önleyebiliyor olması.

Bu da hem teknik hem de biznes tarafında büyük bir değer yaratıyor diye özetleyebilirim.

Çağdaş burada DVH'dan birkaç defa bahsettik.

DVH tam olarak nedir bir onu da söyleyebilir miyiz?

Yani açılımı vesaire nedir?

Tabii ki DVH aslında Data Warehouse olarak bir açılımı var.

Okey. Yani aslında daha öncesinde Data Warehouse tarafında Data Reliability tarafı o tarafa bağlıydınız.

Artık tüm Trendyol genelinde işte verinin reliable kalması, verinin güvenilir ve işte sağlam kalması aslında tam olarak şeyin detayını konuşuruz tabii ama tam çevirdiğimiz

zaman o karşılığa geliyor değil mi?

Evet abi tam olarak öyle aslında.

Tamam süper. Çok teşekkürler.

Peki ekip yapısı nasıl burada?

Data Reliability ekibi kaç kişiden oluşuyor?

Dağılım nasıldır? Aslında Data Reliability ekibimiz toplamda 5 kişiden oluşuyor.

Sevgili liderimiz Aylin ve Fikri, Cihangir, Emir ve ben olmak üzere.

Ama LX projesinde de birlikte çalıştığımız farklı arkadaşlarımız var.

Onlar Data Reliability ekibine doğrudan bağlı olmasalar da...

Data Reliability ekibinin fahri üyeleri diyebiliriz aslında.

Yani o arkadaşlarımız da örneğin Gizem bize PM olarak destek veriyor.

Gökberk Frontend tarafında bize destek veriyor.

Yani aslında toplamda 7 kişi diyebiliriz ama bunların dediğim gibi ikisi fahri üyemiz.

Bugün o zaman buradaki herkes backend developer diyebilir miyiz?

Buradaki herkes backend developer diyebiliriz bence.

Çünkü herkes işin bir ucundan tutuyor.

Yani aslında herkes geliştirmenin bir tarafına dokunuyor diyebilirim.

Örnek vermem gerekirse ben model tarafında da geliştirme yapıyorum.

Backend tarafında da geliştirme yapıyorum.

Aslında biraz ihtiyaca yönelik farklılaşıyor diyebilirim dokunduğumuz yerler.

Süper. Çok iyi. Çünkü bunu sormamın sebebi genelde Fırat bugün burada yok bizim diğer hostlarımızdan biri.

Öyle olsa muhtemelen Frontend'e biraz giydirecekti.

Bugün Fırat olmadığı için. Fakat ben Fırat gibi biri olmadığım için Backend'e giydirmeyeceğim.

O yüzden sizlere tekrar hoş geldiniz demek istiyorum.

Okey tamam süper.

Aslında yani...

Kompakt bir ekip bugün bizim konuğumuz.

Kompakt bir ekipsiniz ve diğer tarafta size yardımcı olan böyle ortak arkadaşlarınız da var.

Peki bu böyle bir ekipte sprintler nasıl ilerliyor?

Nasıl çalışıyorsunuz? İşlerinizi nasıl yürütüyorsunuz?

Burada da ben cevaplayayım.

Aslında Çağdaş da biraz bahsetti.

Şu an Reliability'nin en büyük önceliği ve hot topic konusu Helix projesi diyebiliriz.

Data Observability platform.

Burada da haftalık olarak sprint koşuyoruz.

Yine Çağdaş'ın bahsettiği gibi Gökberk ve Gizem.

bize katılıyor daily'lerimizde.

Her sabah sabah 9.45 civarında daily'imiz oluyor.

Orada update'lerimizi veriyoruz ve eğer sorun yaşadığımız veya bayrak aldırmamız gereken bir konu varsa da daily'nin sonunda müsait olan arkadaşlarla devam ediyoruz.

Bunun dışında yine haftalık olarak refinement'ta task'larımızı birlikte değerlendiriyoruz.

Sprint'i hazır hale getiriyoruz ve bunlarla birlikte aslında development'ımızı ilerletiyoruz diyebilirim.

Süper. Süper.

Aslında burada anladığım kadarıyla ecal bir sistem koşuyorsunuz.

Çünkü bazı ekipler kanban koşuyor, bazı ekipler scramban koşuyor.

Siz anladığım kadarıyla ecal koşuyorsunuz burada.

Evet. Aslında bazen bize gelen talepler hızlı çıkabileceğimiz şeylerse sprint'e aradan task'ı almadığımız olmuyor değil ama onun dışında sprint'e uymaya çalışıyoruz.

Süper. Süper. Harika. O olacak ya o maalesef olacak yani her zaman hani böyle bir iş ortamında böyle büyük ve işte proaktif çalışan ekipler olduğu bir ortamda bir şirkette

acil işler tabii ki gelecek ve bir şekilde çıkacak yani ama tabii ki bunları nasıl handle ettiğimizde genellikle bizi gösteriyor.

Peki Helix'den bahsettiniz geçen hafta bir tech meetup'da da bundan bahsetmiştiniz sanırım burada bir ana bir platform geliştiriliyor.

Tam olarak Helix nedir? Amacı nedir burada?

Ne kazandırıyor bize? Biraz bundan bahsedebilir misiniz?

İsmi mesela neden Helix'tir falan.

Biraz bahsedebilir misiniz projeden?

Tabii abi ben bahsedeyim o taraftan da istersen.

Helix'e aslında kısaca bir data observability servisi diyebiliriz.

Yani burada da kullanıcılar, örneğin bir kullanıcı olduğunu düşünürsek senin, sen abi datanla alakalı her şey yolunda mı veya senin datana ilişkin tanımlamış olduğun rullara göre her şey gidiyor mu, bu rulları ihlal eden bazı

kaçaklar var mı gibi sorulara cevap vermeye çalışan bir servis olarak ortaya çıktı aslında.

Dolayısıyla aslında Helix'in amacı da ekiplerin verisine güvenmesini sağlamak diyebiliriz.

Aynı zamanda bu verinin üzerine sonuçta kararlar da alıyor ekipler ve bu veri ilişkin bir problem olursa da işte ben Helix tarafından evet bir alarm zaten alacağım deyip bunun güveniyle aslında süreçlerine rahatlıkla

devam etmelerini hedefliyoruz.

Bizim temel maksadımız bu diyebilirim.

Ortaya çıkış süreci de şöyle oldu abi.

Bizim DVH ekibimizde 3 seneye yakın lisanslı bir data quality monitor tool'u kullandık biz.

Ama sonrasında bu lisanslı tool'u başta ihtiyaçlarımızı özelleştirme konusunda işte çeşitli limitasyonları oldu.

Bizi epey kıstadığı alanlar oldu.

Third party bir tool olduğu için sadece metadata ile ilerleyebildiğimiz bir süreç takip ediyorduk orada.

Dolayısıyla aslında kendi platformumuzu yapmamız gerekti günün sonunda diyebilirim.

Sonrasında da D-Wedge için geliştirmeye başladığımız bu platformu kendi datasını, kendi datasına ilişkin tanımladığı DQ rullarını gözlemlemek isteyen her trend yol ekibine de sunabilmek için bir

yola koyulduk. Bu sürecinde aslında...

Başladık diyebilirim hani devam ediyoruz farklı farklı ekiplere çeşitli hizmetler sunmaya çalışıyoruz.

İsim seçimi de ama yani diğerlerinin aksine biraz uzun süren süreçlerimizden bir tanesi oldu burada.

Üç farklı isim değiştirdik.

En son Helix'de mutabık kaldık farklı isimlerden geçerek.

Helix ismi de aslında böyle çoğunlukla evrenin gözü olarak da anılıyor.

Bir nebuladan alıyor ismini.

Bu da uzaktan bakıldığında daha çok göze benzeyen ve böyle hani ince detayları olan bir yapı aslında.

Biz de burada Trendyol'da bizim veriye bakan bir gözümüz olduğunu düşündük Helix'in.

Özetlemem gerekirse de yani Helix bizim için sürekli dataları izleyen, hataları hızlıca yakalayan ince detaylarına kadar ve ekiplerin veriye güvenmesini sağlayan bir göz gibi düşünebiliriz.

Astronomide de zaten bu Helix Nebulası hani...

göze çarpan böyle en parlak ve en çok fotoğraflanan yapılardan da bir tanesi.

Bizim de zaman içinde hedefimiz aslında Helix'in Trendyol bazında da böyle göze çarpan, parlak ve ekiplerin ihtiyaçlarına hızlıca karşılık veren bir data quality platform haline gelmek diyebilirim.

Çok iyi ya. Yani Trendyol'da en beğendiğim şeylerden biri bu benim.

Hani evet biz işte kendi sorunlarımızı çözmek için tool'lar yapıyoruz.

Fakat aslında mühendislikten daha çok kültürel olarak da Gelişmiş bir ekip olmamız beni çok mutlu ediyor.

Mesela bunu ilk Beholder tarafında görmüştüm.

Beholder ekibiyle bir podcast yaparken.

Mesela onların ismi de böyle bir antik bir şeyden geliyor.

Hani işte antik bir tanrı isminden falan geliyor gibi bir durum vardı sanıyorum.

Yanlış hatırlamıyorsam. Ya da işte bir fiction karakterdi yani ikisinden biri.

Keza işte Mergen de öyle.

Keza işte sizin Helix de öyle.

Bu çok güzel bir şey bence yani.

Tam amaca uygun. Aynı zamanda da entelektüel bir seçim.

Tebrik ederim. Bu tool da gayet güzelmiş bu arada yani hani bizim şimdi ben client ekibinde çalıştığım için direkt olarak bana hit eden bir benim ekibime hit eden bir tool değil ama hani özellikle backend ekiplerinin bence ve data ekiplerinin çokça

kullanacağı bir tool haline platform daha doğrusu platform haline geleceğini düşünüyorum.

Çok güzel olmuş. Ellerinize sağlık diyeyim.

Şeyi merak ediyorum. Datanın güvenilirliği vesaire bunları üzerinden geçtik.

Data hani ekiplerin kendi datalarına Baktığı işte kendi datalarını kontrol ettiği durumlarda çeşitli anomali durumları da gözlemlenebiliyor sanıyorum.

Burada data anomali sizin için tam olarak ne?

Nasıl kontroller bulunuyor?

Mesela diyelim ben bir ekip olarak gelip kendi datama bakmak istiyorum.

Nasıl bir yol izlemem gerekiyor?

Ben aldım sözü izninizle.

Öncelikle güzel feedbacklerin için çok teşekkür ederiz.

Burada data anomaly bizim için veride beklenmedik değişiklikler veya operasyonel aksaklıklar sonucu oluşan verinin güncellememesi gibi durumlar.

Sistemimiz aktif olarak bu anomalleri tespit ediyor ve ilgili ekipleri uyarıyor.

Biz de stick modeller ve time series forecasting modelleri kullanıyoruz burada.

Ayrıca Custom SQL Rule ismini verdiğimiz kullanıcıların kendi kurallarını tanımlayabildikleri ve alert almak istedikleri durumlarda haberdar olabildikleri bir yapımız da var.

Source olarak bir query kullanıyoruz şu anda biz ama başka source'lar üzerinde de çalışıyoruz.

Önceliğimiz Postgre ve Elasticsearch olmak üzere.

Yine kendi datasında anomali bakmak isterse MLP ekibimizin...

Saladığı source desteğiyle 3 farklı ML model desteği var.

Kendi anomal detection, POC ortamı salıyoruz.

Null rates, zero rate, min-max metrikleri gibi çokla metriklerinde bakıyoruz ayrıca.

Süper. Burada şeyi merak ediyorum ya.

Aslında Helix tarafıyla da sizin kendi yaptığınız işle de şimdi artık birçok sürece AI süreçleri işte AI tool'ları falan filan çok fazla girmeye başladı.

Sizin taraf çok aslında hassas bir taraf olduğu için data ile alakalı bir taraf olduğu için siz AI Tool'larını burada ne kadar işin içerisine kattınız merak ediyorum.

Mesela Helix tarafında böyle altta kullanılan bir AI model vs.

tarzında bir şey var mı?

Ya da buna ihtiyaç duydunuz mu?

Ya da yaptığınız işlerde kullandığınız böyle modeller oluyor mu?

Ben gireyim o zaman burada.

Aslında şöyle oluyor.

Burada kullandığımız bazı istatistiki modeller mevcut.

Ama bunları kendi bünyemizde eğitip yine kendi bünyemizde saklıyoruz.

Hani herhangi bir şekilde dışarıyla paylaşmıyoruz.

Dediğim gibi veriler hassas olduğu için.

Onun dışında aslında hani şu an daha çok günümüzde AI dediğimiz bir elelem mantığında bir şey kullanmıyoruz.

Daha çok istatistiki modeller üzerinden kendi modellerimizi eğitip bunları yine kendi sistemlerimizde saklıyoruz.

Ki herhangi bir üçüncü parti veya dışarıda bir paylaşım olmasın dediğim gibi veriler hassas olduğu için.

Bunun dışında yine tool'umuzu...

Bir MCP'ye çevirmeye de çalışıyoruz, bir MCP desteği de sunmaya çalışıyoruz ki aslında kullanıcı sadece ön yüzden değil, herhangi bir ihtiyacı olduğunda bir chatbotla da konuşarak işlerini halledebilsin, tablolarını gözlemleyebilsin

diye. Emir'in ve Fikri'nin söylediklerine ek olarak benim eklemek istediğim bir şey var.

Aslında AI'yı da entegre etmek bizim gündemimizde olan bir şey.

Hatta çok yakın zamanda bunu nasıl kullanabiliriz diye de ufak...

Kendi aramızda yaptığımız konuşmalar yani brainstormingler de var.

Ben şöyle bir örnek vereyim.

Çok yakın zamanda konuştuğumuz için bunu örnek vermek istiyorum.

Emir'in mesela bahsettiği anomaliler.

Gün sonunda kullanıcının gidip bu anomallere bir aksiyon alması gerekiyor.

Bunlar nasıl aksiyonlar?

İşte bu incident veya anomali diyeyim kaynak sebepli mi bizden kaynaklı mı?

Pipeline'larda bir hata mı var?

Gibi bazı kontrollerin yapılması gerekiyor.

Biz de çok yakın zamanda bunu acaba entegre edebilir miyiz diye bir kendi içimizde şunu değerlendirdik.

Aslında bir flow'a kendi yaptığımız kontrolleri tanımlayıp gün sonunda da elelemin Bu flow'un çıktısını yorumlayıp ilgili alert'ün, incident alert'ünün altına eklediği

yani yorumlardan kastım da şöyle.

Atıyorum Kafka'dan kaynaklı bir incident yaşadığımızı düşünelim.

İşte Kafka'daki konektörleriniz şu an ayakta değil.

Bu alert'ü yüksek ihtimalle bundan dolayı almışsınızdır şeklinde bir yorum yaptırmak için kullanabiliriz diye konuştuk.

Hani burada tamamen süreci otomatize edip çıktıları da.

eleleme yorumlatabilmek gibi bir hedefimiz var diyeyim uzun vadede.

Süper. Çok teşekkür ederim arkadaşlar.

Bence çok güzel bir plan.

Uzun vade için gayet ulaşılabilir.

Birçok ekip de zaten süreçlerini EA'ya da entegre ediyor.

Dilmesi de lazım yani artık dünya o yöne doğru gidiyor.

Biz de teknolojide zaten Türkiye'de özellikle hani teknoloji alanında birçok konuda öncü olarak gittiğimiz için bu tarz konularda da zaten uzun süredir neredeyse ilk çıktığı zamandan beri çeşitli çalışmalarımız

oluyor diyebiliriz.

Okey sıradaki sorum arkadaşlar birazcık daha böyle aslında bizim klasik sorularımızdan biri.

Teknoloji tarafınızı merak ediyorum.

Burada teknoloji olarak neler kullanıyorsunuz?

Hangi teknolojileri kullanıyorsunuz? Tekstiliniz tam olarak nedir?

Burada aslında ekibimiz genel data temelli olduğu için kendimizi en rahat hissettiğimiz dil tabii ki de Python.

O yüzden çoğu modelimiz, çoğu projemiz Python temelli kuruluyor.

Örnek veriyorum backendimizde Python'ın bir framework'ı olan FastAPI'yi kullanıyoruz.

Onun dışında yine farklı şekilde model eğitimi, mesela Metric Collector veya Animal Detection projelerimiz var.

Onlar da yine Python temelde gidiyor.

Frontend tarafında TypeScript ve React kullanıyoruz.

Bunun dışında da yine database olarak da Postgre veya InfluxDB kullanıyoruz diyebilirim duruma göre.

Okey süper. Güzel teknolojiler.

Yani şimdi data tarafını çok bilmediğim için açıkçası.

Ekstra yorum yapamadım muhtemelen Fırat olsa o daha ekstra yorum yapardı ama yani çok farklı şeyler kullanmak teknolojiler kullanmak işte zaten genel trend yolda birçok teknolojiyi

kullandığımız için Python'da çok sık kullandığımız teknolojilerden biri.

Data tarafında daha önce ben üniversitedeyken bir şeyler yapmıştım orada Python kullanmıştım.

Kolaylığı da tabii ki yani şey olarak sinteks açısından kolaylığı da gayet iyi olmuş diyebiliriz.

Peki burada data tarafı olduğunuz için birçok ekiple birçok domenle aslında alakanız olduğunu düşünüyorum.

Çünkü data yani bize kadar işte client tarafıyız biz bize kadar belirli şekillerde akıyor.

Dolayısıyla burada yakın çalıştığınız ekiplerde domenlerde vardır.

Siz burada hangi domenlerde veya takımlarla yakın çalışıyorsunuz?

Burada aslında veri ekosistemine değen, yani veri ekosistemindeki herkeste çalışıyoruz diyebiliriz.

Yani veriyle işi olan, veriye dayalı karar alan özellikle ekipler bizim en çok yardımcı olduğumuz ekipler diyebiliriz burada.

Amacımız da burada bize gelen ekiplerin verisinde bir beklenmedik bir durum, yani onlara da anomali diyoruz.

Beklenmedik bir durum var mı veya bir antipatern...

Yakalamak istiyorlar mı?

Bunlar onları çok etkiliyorsa özellikle o ekipler bize gelip bu platformu yani çıkarma çalışması platformu aslında kullanmak istiyorlar.

Ekip olarak da analitik ekipler olabilir.

Data Science ekibi var, DVH ekibimiz var, Data Engineer ekibi var.

Bunun gibi aslında geniş bir alpazede çalışıyoruz.

Burada da mesela business ekiplerimizi etkileyebilen bazı data quality issue'larını önleyebilmek adına analitik enjinyörlerle yakın olarak çalışıyoruz.

Onlar da kendileri create ettikleri custom SQL DQ rule'ları üzerinden aslında takip edebiliyorlar.

Yine en önemli diyebileceğimiz verilerimizden klik verisindeki antipaterleri yakalamak buna bir örnek olabilir.

Farklı ekiplerden örnek vereceğim.

Az önce sen de değmiştin abi.

Container Platform ekibiyle yeni bir POC başlattık.

Burada Beholder'daki CPU, memori ve missing DNS'leri takip ettiğimiz bir yapı üzerine çalışıyoruz.

Onun dışında yine zaman zaman false alarmlar üretebilen Kafka Lake alertleri üzerine de çalışmaya devam ediyoruz.

Demek istediğim burada data deyince aklınıza sadece tablolar ve tabloların anomalisine bakılan bir yapı gelmesin.

Beholder'da var, burada Kafka Lake'leri de var ve biz aslında buradaki aslında data quality ölçüm mantığını tablo ötesine de taşımaya çalışıyoruz.

Yani herhangi bir datanın anomalisine bakacak bir platform üzerine çalışıyoruz diyebilirim.

Dolayısıyla bize gelen her ekip aslında kendi ihtiyacına göre LX'i customize edebiliyor.

Bu sayede de Trendyol için de hem teknik anlamda hem de business anlamında değer yaratmaya çalışıyoruz diyeyim.

Peki burada şeyi sormak istiyorum.

Şimdi aslında siz...

birçok şeye, birçok ekibe provider oluyorsunuz yani bir nevi yani sizin taraftan yani data hani geliyor ve işte reliability'sini siz oluşturup ve data paslıyor gibi bir durum

benim anladığım.

Burada size data gelirken nasıl ilerliyor süreç?

Yani siz bu datayı bir noktadan mı alıyorsunuz?

Yani size mesela size data geliyor, siz işliyorsunuz ve veriyorsunuz diyelim.

Bu data size gelirken birçok yerden mi geliyor yoksa tek bir noktada birleşip oradan gelip sonra sizden mi dağılıyor?

Burada aslında strikt bir şekilde tek bir kategorili takip etmiyoruz abi.

Örnek veriyorum BigQuery'deki bir kaynak datayı anomalisine bakmak istediğimiz zaman oraya yöneliyoruz veya az önce bahsettiğimiz işte Kafka Lake veya Beholder çok bambaşka bir evren ve doğası

gereği aslında bazı datayı bizim pre-proses'e tabi tutup bir yerde collect edip daha sonra o collect edilen data üzerinden bakmamız gerekebiliyor veya zaman zaman bazı data bize direkt ekstra bir çok işlem maliyeti gerektirmeden

gelebiliyor veya biz onu ekstra bir yerde tekrar tutmamıza gerek kalmıyor.

Bu gibi durumlarda direkt aynen kendisinden aldığımız datayı çok ufak preproseslere tabi tutarak işleyebiliyoruz.

Yani burada aslında katı bir şekilde tüm veriyi şu şekilde kolekt ediyoruz gibi bir yapımız yok.

İhtiyacı yönelik şekillendirebiliyoruz ama bizim için çok da zor olmuyor diyebilirim burası.

Anladım, anladım süper.

Valla yani biraz Zor bir şey.

Yani açıkçası şeyi daha zor.

Orkestrasyon etmesi oldukça zor bir durum.

Burada şeyi de konuştuk işte çalıştığınız domenler vesaireyi de konuştuk.

Ama şey...

daha önemli bence. Yani burada sağlıklı bir şekilde, huzurlu bir şekilde çalışmak, süreci yönetmek.

Şimdi bu kadar çok ekiple birlikte çalışmak sizin için ortak çalışma, iletişim falan konuları nasıl oluyor?

Yani zorlanıyor musunuz burada? Zor oluyor mu?

Bir de şeyi sormak istiyorum. Buradaki mesela bir ekiple ortak teknik bir şey geliştireceğiniz zaman süreç tam olarak nasıl ilerliyor?

Helix Projesi kapsamında gerçekten birçok yeni ekiple tanıştık, iletişime geçtik.

Bu tanışmaları Genelde yani bu toplantı ve bu tanışmaları genelde PM'imiz Gizem ve ekip liderimiz Aylin organize ediyor.

Bu ekiplerle bir araya gelip anormal detekşin ihtiyaçları doğrultusunda POC'ler yaparak ve aynı zamanda payer çalışarak çıktıları yine birlikte değerlendirerek ilerliyoruz.

Ekiplerden gelen feedbackler doğrultusunda da mevcut DQ çözümlerimizden ihtiyacı yönelik özelleşmiş yeni çözümler üretiyoruz.

Güzel yani ben hep şeyi savunurum işte.

Özellikle birçok farklı ekiple çalışacağımız bir şey geliştireceğimiz zaman.

Ya böyle akıl sağlığımızı koruyalım da gerisi çok da önemli değil gibi.

Yani çünkü gerçekten birçok insanla beraber çalışmak.

Hele ki ortak projelerde çalışmak.

Çok şey bir iş yani.

Zor bir iş. Bunun yönetmesi de çok zor bir iş.

O yüzden güzel de handle ediyorsunuz gibi gördüm.

Tebrik ediyorum. Peki burada şimdi sprint koşuluyor.

İşlerden bahsettik.

Süreçlerden bahsettik.

Bizim... İçeride tabii metriklerimiz var ölçülerimiz bildiğiniz üzere.

Bunlardan daha önceki bölümlerde de bahsetmiştik.

İşi yapmanın yanında ship etmek de çok önemli.

Yani bir işi yapıp çıkmak, hızlı çıkmak ve düzenli çıkmak sürekli bir rölantide bu işi ilerletmek oldukça önemli.

Burada deployment süreçleriniz nasıl ilerliyor?

Sıklık konusunda nasıl bir sıklık izliyorsunuz?

Şöyle abi, aslında zaten haftalık sprint koştuğumuz için sık sık deployment çıkıyoruz diyebilirim.

Orada da şöyle işliyor sistem.

Aldığımız kartı bitirdiğimizde stage ortamı alıyoruz.

Stage ortamda bazen PM'lerimizle bazen kendi aramızda UAT testlerimizi hallediyoruz.

UAT testleri de başarılı bir geçtikten sonra proda alma süreci gerçekleşiyor.

Yine TBP kullandığımız için burada bizi elimizi baya kolaylaştırıyor diyebilirim.

CICD pipeline ile birlikte tek tıkla aslında halledebiliyoruz diplomi süreçlerini.

Yaklaşık da yine ortalama 3 günde bir diplomi çıkıyoruz diyebiliriz.

Çok iyi yani tabii her takımı kendine belirlediği idealler var ama gelen işler ve işte iş yapma sıklığı falan 3 gün bence ideal bir durum haftada yani koşulan spektrum durumunda.

Çok iyi. Şey tarafını konuşalım biraz.

Şimdi bizim artık her ekiple klasik şeyimiz, konuştuğumuz konu.

Incident konuları, monitoring konuları vs.

Incident konusuna geliriz daha sonrasında.

Daha doğrusu bu soru içerisinde soracağım onu da.

Böyle siz monitoring süreçlerinizi nasıl ilerletiyorsunuz?

Çünkü hele ki data ile alakalı bir ekip olduğu zaman ben çok açıkçası merak ettim.

Burada monitoringi nasıl yapıyorsunuz?

Bu durumda nasıl hani oluşmadan önce ya da sonrasındaki planınız neler oluyor?

Bir de tabii hani her ekibe sorduğumuz güzel böyle bir incident örneğiniz varsa onu da dinlemek isterim.

Toparlayayım. Buradaki monitoring süreçleriniz, alert mekanizmanız, incident süreçleriniz nasıl ilerliyor?

Şöyle ki abi burada her servisimizde bizim hata yakalama yapılarımız var.

Stage Pro'da olmak üzere iki tane Slack error kanalımız var.

sistemlerimizde herhangi bir hata olması durumunda da bu kanallardan bilgilendiriliyoruz.

Aslında bu şekilde fark ediyoruz bir sorun olduğunda.

Bir örnek olarak vermem gerekirse mesela gönderdiğimiz alertlerde ilgili konu ile ilgili bir Jira taskı açılmasını sağlayan bir butonumuz var bizim attığımız Slack mesajlarında.

DVH içerisinde Jira yapısı değişti.

birisinde ve bizim mevcut jira yapımız bu yenisine uygun değil diyor.

Bu direkt hata almaya başladı mesela ve burada az önce söylediğim gibi slay kanallarına düşen erörler sayesinde keşfettik.

Bir başka örnek daha vermek istiyorum.

Orada da yaptığımız bir geliştirme sonucunda bu bizim anomalileri gönderdiğimiz slay kanallarına yanlışlıkla böyle mesaj bombardımanı tuttuk bir anda.

Full false alert atmaya başladık.

Bunu zaten hızlıca gördük yani herkesi gibi biz de görmüş olduk.

Sonrasında hızlıca gönderilen mesajları tekrardan silip hatayı da fixledik.

Ya buna tam olarak bir incident diyebilir miyiz ama?

Hani ben biraz onu düşündüm.

Gerçi şimdi tabii ki şey olarak bakmamak lazım hani sizin tarafta belki bu hani bir incident olarak kabul ediliyor olabilir.

Bana yani şu zamana kadar dinlediğim insınıtlar arasında böyle çok pembe bir insınıt gibi geldi ama sizin için belki çok büyük bir insınıttır.

Bilmiyorum onu. Abi ne mutlu bize ki en büyük insınıtımız buydu diyebilirim.

Çok iyiymiş. Çok iyi.

İnşallah bundan daha büyük bir insınıt yaşamazsınız.

İnşallah. Harika süper.

Şimdi tabii incident aslında eğer burada her bölümde konuştuğumuz konu incidentlar yaşanabiliyor.

Yani her gün yaşayabiliyoruz.

Buradaki tabii ki amacımız incidentları azaltmak, yaşamamak üzerine ama asıl ondan da önemlisi bu incidentlardan ders çıkarmak ve tecrübe edinmek sonrasındaki süreci aslında oluşturmak.

Şimdi sonrasında aslında buradaki ders çıkarma konusunda da toplantılar işte retro toplantıları üzerine yapılan retrolar çok büyük bir önem.

arz ediyor. Süreçleri tabii şeyleri konuştuk işte yaptığınız süreçleri, sprint durumlarını falan filan ama retrodan da biraz konuşalım istiyorum.

Data Reliability 2.1 retrolarını nasıl yapıyor?

Tabii abi ben bahsedeyim kısaca.

Fikri zaten haftalık sprint koştuğumuzu söylemişti.

İki haftada bir de bizim retro toplantılarımız oluyor.

Yani bu retro toplantılarında da genelde bu sprint boyunca yaşanan sorunlar veya çözdüğümüz bug'lar varsa genelde bunları konuşuyoruz.

Neden olduğunu, nasıl tekrarlanmaması için nasıl aksiyonlar alabileceğimize dair şeffaf ve açık iletişim kurmaya çalışıyoruz.

Buna yönelik maddeler giriyoruz.

O yüzden çok kanlı geçtiğini söyleyemem.

Genelde ekip çalışmasını ve ekip içi iletişime...

daha iyi bir seviyeye çıkartabilmek için maddeler giriliyor.

Arada ben böyle bazen ortalığı karıştırmak isteyen maddeler girsem de çok karışmıyor diyeyim ortalık.

Mesela birkaç örnek vereyim.

Refinement'la alakalı bir maddemiz olmuştu daha öncesinde bir retro toplantısında.

Refinement'ta aslında bizim sprint'e alacağımız kartları en ince ayıncısına kadar analizini yapıp ve bu kart kapsamında neler yapılmasını kararlaştırdığımız bir toplantı.

Ve bu toplantıların Sprintlerde çok da bu toplantının çıktılarını sprintlere çok da yansımadığını fark ettik.

Ve bu refinement toplantısını nasıl iyileştirebiliriz'e dair bir madde vardı ve bunun üstüne tartıştık.

Bunun dışında bir de bir toplantı maddesi vardı.

Çok toplantımız var diye ben buna çok güldüm.

Çok gülmemin sebebi de şuydu aslında biraz.

Bunu ayrı bir reddla toplantısında konuşalım dendi.

Toplantı maddesinin girildiği bir yerde ayrı bir toplantı daha yapalım bunun için diye bir çözüm bulmuştuk.

Buna gülmüştüm yani baya komik gelmişti bana.

Çok iyi çözülmüş. Yani toplantı fazla diye bir toplantıda konuşalım.

Gerçekten çok iyi çözülmüş.

Valla süper yani aslında Çağdaş şöyle bir şey var.

Ben mesela konuştum yani şu ana kadar çok ekiple bölüm yaptık ve ofislerde de çeşitli etkinlikler yapıyoruz.

Ankara ofiste yaptığımız etkinliklerden birinde mesela bir arkadaştan şey duymuştum.

Biz retroları çok böyle gerçekten sıkıntı konuları özellikle konuşacağımız şekilde yapıyoruz ve elimizden geldiği kadar kanlı olabilecek şekilde düzenliyoruz demişti.

Ve bu ekip mesela aşırı mutlu bir ekipti falan.

Açıkçası genellikle baktığım zaman bekant ekiplerinde böyle bir şey var nedir o gerçekten ciddi retrolar yapalım gerçekten hani olan sorunları üzerine basa basa böyle ve belki de

hani böyle yani tabii ki kavgaya dönüşmeyecek şekilde bir tartışma ortamına çevirecek şekilde yapalım algısı var.

Client ekiplerinde, burada da ben 3-4 ekipte çalıştım.

Aynı sizinki gibiydi aslında.

Biz de biraz böyle hafif soft yapıyorduk.

Ama şeyi fark ettik son zamanlarda böyle.

Daha üzerine basılacak konular getirdiğimiz zaman retroya gerçekten verimli bize geri dönüşü daha iyi olan bir durum olduğunu mesela fark ettik.

Belki hani siz de bunu deneyebilirsiniz.

Sen zaten ufak ufak alttan vermeye çalışıyormuşsun.

Belki de hani 2000...

Belirli noktalarda ihtiyacı bu olabilir yani.

Evet abi ben deneme taraftarıyım açıkçası.

Arkadaşlarım da okey olursa.

Dozunda tutmak çok önemli.

Dozunda tutmak çok önemli yani.

Haklısın. Dozunda tutulduktan sonra evet.

Süper. Peki yavaş yavaş da sona geliyoruz.

Son iki sorumuz kaldı.

Şeyi merak ediyorum. Buradaki...

Çalışma ortamınız şimdi, hepiniz çok güzel insanlarsınız.

Burada çok güzel bir ekip oluşmuş, çok güzel bir proje yürütüyorsunuz.

Buradaki çalışma ortamı nasıl ilerliyor?

Yani sizin ekibinizde hangi değerler önemli?

Nasıl bir çalışma ortamı yürütüyorsunuz?

Abi şöyle aslında az önce senin de konuştuğun şeyler hani tabii ki trend yolunun tamamında önemli olan konular, bizde de uygulanan konular.

Zaten bu ekibin bir şansı da şey, bu platform öncesi de biz bir şekilde asla kadar çok yakın çalışan kişilerdik burada.

Zaten şirket kültürü gereği uzakta da olsa bir şekilde kaynaşıyorsun ve hızlıca adapte olabiliyorsun birbirine ama bizim zaten bir geçmişimiz vardı diyebilirim.

O açıdan gerçekten şanslı bir şekilde bir araya gelen bir ekip olduk.

Onun dışında mesela Çağdaş'ın söylediği konu çok önemli.

Yani burada işte Retro'da gerçekten her şeyin çok şeffaf olması bize çok şey katıyor diyebilirim.

Herhangi bir konuda bir bayrak kaldırılacaksa o konuda herkes üzerine düşen inisiyatifi alıp hızlıca bunu ortaya koyuyor.

Ve oradaki problem neyse aslında hızlıca tespit ediyoruz.

Yani bu bizim için artık takım özelinde bir mikrokültür diyebilirim buna.

Onun dışında işte knowledge sharing bizim için çok önemli.

Her sprint sonunda mesela biri büyük bir geliştirme çıktıysa özellikle onu önceliklendirip konuları aktarımlı birbirimize yapıyoruz.

Yani platformda zaten genelde komponentlerin çoğu birbirine etkiler durumunda.

Herkes bu geliştirmeyle alakalı birbirinden haberdar olsun gibi.

Tabii bu sadece teknik detaylarla da kısıtlı değil.

Örneğin bir geliştirme yapılacağı zaman veya bir yeni tasarım yapılacağı zaman.

Burada hangi zorluklarla karşılaşıldı development süresince veya bunlara nasıl çözümler bulundu ki?

Bunlar aslında ufak brainstorm stasyonları gibi diyebiliriz.

Burada herkes birbirine aktarım yaparken aslında yeni yeni fikirler de ortaya çıkarmış oluyoruz.

Bu bizim için çok kıymetli oluyor.

Zaten gerçekten ciddi manada faydalarında gördük bunu.

Veya işte bir konu tek kişi üzerinde çok spesifik bir şekilde kaldığı durumda da zaten hemen hızlıca bir aktarım stasyonuyla bunu herkese anlatmış oluyor.

Bütün bu anlattıklarımın da bize en büyük katkısı şey diyebilirim.

Bir bilgi hani tek bir kişi üzerinde kaldı ve tüm know-how tek bir kişi de yığıldı gibi bir şey olmuyor.

Biz biraz bundan aslında kaçmaya çalışıyoruz ve zaten sprintlerde de genelde şey oluyor hani.

sahipsiz iş çok kalmıyor diyebilirim yani.

Herkes bir şekilde böyle sahiplenme içgüdüsüyle direkt kartların arası üstüne atlıyoruz ve hani açıkta hiçbir şey kalmıyor.

Bu da dediğim gibi aslında bu ikisi karşılıklı olarak birbirini besleyen iki tane süreç ve sebep diyebilirim.

Onun dışında şey zaten düzenli birebirlerimiz var.

Eğer hani o birebir için belli bir konu yoksa böyle hani bazen olmayabiliyor çünkü işte böyle net feedback maddedir.

Biz yine o birebirleri yapmaya çalışıyoruz yani.

Başka bir şey çıkıyor veya aslında zaman zaman uzakta kaldığımızda tekrar birbirimize yaklaşmamızı sağlıyor diyebilirim.

Özetle de takımda aslında herkesin sesini duyurabildiği, fikirlerini rahatça birbirlerle paylaşabildiği bir ortam yaratmak için çalışıyoruz.

İşte tabii burada şirket kültüründe bize çok büyük artlar oldu.

Taban olarak onun üzerine yeni bir takım kültürümüz oldu diyebilirim.

Güzel, keyifli bir ortam var.

Böyle bol bol...

Beyinlerin yakıldığı yani yeni bir geliştirme olacağı zaman herkesin çılgın fikirleriyle geldiği.

Sonra o çılgın fikirlerden de yeni yeni güzel geliştirmenin tasarlandığı bir ortam var.

Çok iyi ya. Valla ağzına sağlık Cihangir.

Yani burada aslında bizim genel olarak Trendyol'da da istediğimiz ve genel olarak yaptığımız bir ekip kültür yapısı var.

Burada aslında güzel bir yapı oluşturmuş, güzel bir ekip kültürü oluşturmuşsunuz.

Biz de kendi ekibim de öyle, birçok ekip de öyle.

Zaten bu değerler neticesinde ilerlemeye çalışıyoruz.

Birbirine yardım eden, birbirine arka çıkan, destek olan ekip üyeleri olması oldukça önemli kesinlikle.

Evet, son sorumuza geldik arkadaşlar.

Çok keyifli bir podcast bu arada.

Şimdi bitirmeyeceğim ama son sorumu da sorayım.

Bizim zaten klasik sorumlusu her ekibe sorduğumuz.

Ekibinizin iletişimini işte iş dışındaki şeyleri nasıl ilerletiyorsunuz?

Hani bu işte şeyler var.

Bazı ekiplerimiz bildiğiniz üzere araba sevdalısı, nargile seven ekibimiz var.

Genel olarak zaten Trendyol genelinde yemek çok seviliyor biliyorsunuz.

İşte yemek de bizim bir kültürümüze oturmuş vaziyette.

Siz burada ekip iletişimini geliştirmek için neler yapıyorsunuz?

Yani yaz döneminden çıktığımız için şeyden örnek vereyim abi.

Şimdi yaz döneminde evdeyiz ama birbirimizi özlüyoruz falan böyle çıkıp kafede çalıştığımız zamanlar olmuştu.

Hala da bazen yapıyoruz yani çıkıp evde çalışmaktan sıkılıp birlikte vakit geçirmek için kafede buluşup o günü kafede çalışarak geçiriyoruz.

Yakın zamanda bir Çin buluşması yaptık.

Umarım devamı gelir.

Bunu yapmak bayağı keyifliydi çünkü.

Akşam çıkıp çimlerde oturduk sohbet muhabbet.

Çay getirenler oldu. Abur cubur getirenler oldu.

Oturup sohbet muhabbet ettik.

Bunun dışında şehir dışında yaşayan arkadaşlarımız var.

Şehir dışından kalsın da İstanbul dışında.

Mesela Emir. Emir İstanbul'a geldiği zamanlar birlikte vakit geçirmek için yemek eventleri ayarlıyoruz.

Ofisteysek ve herkes için uygunsa ofis çıkışı bir şeyler yapmaya çalışıyoruz.

Ofisteyken de... Hani bir kahve molası veriyoruz birlikte.

Ufak bir kaçamak yapıyoruz.

Sohbet muhabbet yine aynı şekilde.

Hatta Eylül sonunda bir tane heliks yemeğimiz olacak.

Onu iple çekiyorum ben.

Çünkü bayağıdır beklediğim bir eventti.

Yani bu tarz bir araya gelmeler bence çok keyifli oluyor.

Hani birbirimiz hakkında daha fazla şeyler öğrenebiliyoruz.

Hani hem ekibin iletişimini arttıracak hem de bağını.

Daha da güçlendirecek şeyler paylaşılabiliyor.

Sadece birlikte iş yapmak değil de birlikte vakit geçirdiğimiz aileden bir parça gibi bir şey oluyor diyebilirim ekip.

Çünkü günün çoğunu birlikte geçiriyorsun.

Ve bu insanları da içten bir şekilde tanımak bence çok keyifli oluyor.

Bir de şeyi ekleyebilirim.

Ekip toplantılarımız oluyor.

Bu ekip toplantılarımızda genelde boşsak online oyun oynuyoruz.

Baya rekabetli ve güzel oluyor.

O da keyifli oluyor. Hatta bugün bir ekip toplantımız var.

Büyük ihtimalle buradan sonra bir oyun oynarız diye düşünüyorum.

Süper, süper.

Valla güzelmiş yani yeni şeyleriniz.

Özellikle bu çimlerde buluşma konusunu bayağı beğendim.

Benim aklımda öyle kalacak yani.

Oyun konusu da zaten tüm ekiplerde neredeyse klasik olmuş bir durumda.

Yemekten sonra direkt oyun geliyor.

Süper arkadaşlar. Valla çok teşekkür ederim.

Ben çok memnun oldum sizlerle bu bölümü kaydettiğimiz için.

Ki geldiniz. Data Reliability'i tanımak...

Çok güzel oldu.

Tekrar çok teşekkür ederim.

Biz teşekkür ederiz abi.

Bizim için de çok keyifliydi.

Süper. Çok sevindim. Bu bölümde 84.

bölümümüzde Data Reliability ekibiyle beraberdik.

Sonraki bölümlerde başka ekiplerle yine beraber olmaya devam edeceğiz.

Bunun yanında Trendyol Talks adında başka bir podcast serimiz var.

Trendyol Talks'ta 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ı da takip etmeyi unutmayın lütfen.

Teşekkürler dinlediğiniz için. Bir sonraki bölümde başka bir videoda tekrar görüşmek üzere.

Bay bay.