Konuklar: Aysel Zengin, Oğuzhan Demir, Enes Canca, Onur Yılmaz
63. bölümümüzde konuğumuz Observability Platform ekibi oldu. Ekip yapısını, projelerini, teknoloji stack seçimlerini ve çok daha fazlasını konuştuk!
Trendyol Talks'da Trendyol'daki kültürümüzü, kültürümüzden beslenen iş yapış biçimlerimizi ve ritüellerimizi konuşuyoruz. Trendyol Talks podcast kanalımızı takip etmeyi unutmayın!
Transkript
Selam ekip, ben Storefront TRPDP ekibinden Cengiz.
Teknoloji ekiplerini tanıdığımız ve süreçler, teknolojiler gibi konuları konuştuğumuz Selam Ekip Podcast serisinin 63.
bölümünde Observability Platform ekibiyle birlikteyiz.
Bu ekibi tanıyıp, ekip yapısı, kullanılan teknolojiler, pratikler gibi konuları konuşacağız.
Arkadaşlar hepiniz hoş geldiniz.
Hoş bulduk, selam.
Hoş bulduk, selamlar.
Selamlar. Şimdi isminiz oldukça zor söylenmesi.
Yani bugüne kadar çok...
Zor isimler olan ekiplerle podcast kaydettik.
Observability yani şu an tekte söyleyebildim ama demin bir iki defa tıkandım.
Hatta burada benim notlarım arasında isiminizi direkt Beholder olarak yazmışım.
Ama bugün beraberiz.
Bugün beraber olduğumuz için de çok mutluyuz.
Tekrar hoş geldiniz. Kendinizden kısaca bahsedebilir misiniz?
Merhabalar ben başlayayım.
Aysel Zengin ben.
Yaklaşık iki yıldır Trendyol'dayım.
Otel Endüstri Mühendisliği mezunuyum.
Trendyol'da da observability platformunda direkt ürün yöneticisi olarak başladım.
Öncesinde de bir PM tecrübem var.
Etiya'da 4,5 yıl kadar.
Ondan önce de farklı sektörlerde iş tecrübelerim oldu.
Teşekkürler. Selamlar.
Ben de Onur. Ben de yaklaşık 7 yıldır Trendyol'dayım.
Aslen makine mühendisiyim.
Biraz alaylı yazılımcıyım.
Yazılıma ve iş hayatına Trendyol'da başladım.
Çok çeşitli domenlerde çalıştım Trendyol'da.
Checkout tarafında, farklı platform ekiplerinde de çalıştım.
Yaklaşık bir yıldır da observability ekibinde...
Çalışmaya devam ediyorum. Selamlar, ben Enes.
3 yılı aşkın süredir Trendyol'dayım.
Trendyol'a DevOps Bootcamp'iyle katıldım.
Bu benim ilk iş tecrübem oldu.
İlk deneyimim aynı zamanda. İlk 4 ayımı Platform Core ekibinde geçirdim ve ardından bu ekipten bölünerek bir holder kuran ekip üyelerinden biri oldum.
DevOps ile başlayıp Platform Engineer olarak kariyerime devam ediyorum.
Selamlar, Oğuzhan ben.
Ben 11. yılındayım Trendyol serüvenimdeki.
Bu 11 yıllık sürede çok farklı ekiplerde çalıştım.
İşte Discovery için altında Search ekibi, Browsing ekipleri, Web Checkout ekipleri.
O zaman biraz daha küçük bir ekip yapımız.
Sonrasında Marketplace'i yine yapan ekiplerde bulundum.
Son 5 yıldır da Builder platformla beraber çalışıyoruz.
Observability ekibiyle de son 1 senedir yakın çalışıyoruz diyebilirim.
Tekrar hoş geldiniz.
Valla bu bölüm... Daha keyifli olacak.
Yani diğer bölümlerimiz de çok keyifli tabii ki.
Fakat bu bölümde yıl dengesi açıkçası her taraftan var.
Yani işte çok uzun zamandır Trendyol'da olan da var.
İki yıldır Trendyol'da olan da var.
Yani gerçekten keyifli bir bölüm olacağına eminim.
Tekrar hoş geldiniz. Şimdi öncelikle biraz şeyden bahsedelim istiyorum.
Observe bakın yine.
Sizin takımınız diyeyim.
Bir tek ben mi bu arada böyle tekliyorum yoksa...
Başka tekleyen insanlar da oldu mu?
İlk başta oluyor birazcık.
Biz zaten Trendyol'a biliyorsun içeride takımlara, projelere böyle daha kolay, akılla kalır isimler vermeye çalışıyoruz.
Beholder daha kolay geliyor.
İçeride öyle bir isimlendirme tercih ettik.
Ama genel olarak yaptığımız işin daha net anlaşılması için de observability diyoruz.
Biraz daha oraya hızlı söylersen akabilir sanki.
Observability diye böyle. Okey süper.
Şimdi observability platform nedir?
Tam olarak ne yapar? Amacı nedir?
İçeriği nedir?
Bunlardan birazcık bahsedebilir misiniz?
Buradan ben başlayayım.
Trendyol'da observatif platform iç kullanıcıların kullandığı ve in-house geliştirdiğimiz platformuz aslında.
Tabii alternatif platformlar da var, nivrelik gibi ama biz Trendyol içinde geliştirilen bir platformuz.
Neyin observabilitesi?
Uygulama olabilir, altyapı olabilir bu tarz öğelerin observabilitesi.
Ne yapıyoruz peki biz?
Aslında ilgili telemetri verilerini toplanmasına olanak sağlayacak yapıları geliştiriyoruz.
Nedir bunlar? Logmetrik ve trace verileri örneğin.
Bunların kaydedilip saklanması, verim yönetiminin yapılması, görselleştirilip raporlanması aynı zamanda ve belli durumlarda mesela uygulamanın sağlığında bir problem olduğunda alarm...
oluşturulması ve raporlanmasını sağlayan yapıları aslında geliştiriyoruz kendimiz ve amacımız burada bütünleşik bir monitoring deneyimi sağlamak amacımız.
Selam ekip sesyonlarında da bu arada hep monitoring geçiyor.
Bu nedenle biz diyebiliriz ki bu altyapıyı sağlayan ekibiz aslında inhaz olarak.
Alternatif ürünlerin yanında tabii ki.
Ve Beholder Grafana en çok bilinen kısmı çünkü kullanıcıya dokunan kısmı bu.
Burada görselleştirme yapıyoruz.
Ama aynı zamanda bu sene başında Pandora'da da observability kullanıcı arayüzümüz çıktı.
Burada da alarmların oluşturulması ve raporlanmasına yönelik bazı ekranlarımız oldu.
Ayrıca da Key Business Transaction ve bunlar için servis seviyesi tanımlama girişimlerimiz var biliyorsunuz.
Bunlarla ilgili de raporlama arayüzleri var bu tarafta.
Ayrıca yine bu sene ortası gibi launch ettiğimiz SDK'sı ve kullanıcı arayüzüyle beraber yine yeni bir ürünümüz var Mergen.
Bu da Client Observability yani web ve mobil uygulamaların aslında monitoring için kullanılan bir uygulama.
Buraya da tabii ki aynı zamanda backend tarafını da entegre etmeyi planlıyoruz end-to-end observant deneyimi sağlayabilmek açısından.
Bu şekilde diyebiliriz.
Aysel'in dediklerine ek olarak observability konusunun önemini şöyle anlatayım.
Yani biz bu ekibin kurulma yerlerine kadar gider aslında.
Biz 2019 senesinde çok büyük bir incident yaşadığımızda aslında Builder Platform Tribe'un ilk temellerini atmıştık.
Bunları atma sebebimiz aslında şöyle.
Bunu bir ilerleyen zamanlara daha detaylı da anlatacağım da.
Observability'nin önemi şu arkadaşlar. Bizim 7000 civarı mikroservisimiz var.
Ve mikroservis üniversitedeki en büyük sorunlardan birisi de observability konusudur.
Yani bizim o yüzden burada...
inanılmaz şekilde standartize bir şekilde ilerlememiz ve belli pattern ile ilerlememiz gerekiyor.
İçinde biz şu an endüstride en güncel yaklaşım olan Open Telemetry standartlarını benimsedik ve bunu baz alarak ilerliyoruz.
Log, Metric ve Trace konularını standart bir şekilde tüm Trendyol Tech ekosistemine yayma amacımız var.
Bunu yaparken de aslında iki tane fazı var benim gözümde.
Birinci faz biz yaşanan herhangi bir hatayı yakalayabiliyor muyuz?
Bu bizim için birinci yoldu.
Bunu şu ana kadar yapabiliyoruz.
Çeşitli akıllı yeni ürünlerle de bunu çok rahat yakalayabiliyoruz.
Burayı hallettik ama bunun ikinci adımı olan da şurasıdır aslında.
Incident'ları veya sorunları olmadan önce yakalayabilmek.
Ya bir yerde bir anomali var.
Ya bak burası normalin üzerinde.
gibi gibi çıkarımları yaptırmamızı sağlayacak metriklere, telemetri datalarına ihtiyacımız var.
Bizim aslında ki nihai hedeflerimizden birisi de bu.
Trend yolu tek de bizim gözlemleyemeyeceğimiz yer kalana kadar biz devam edeceğiz.
Hedefimiz bu diyebilirim kısaca.
Valla harika ya. Yani her, Aysel'in de söylediği gibi biz her bölümde, her ekiple monitoring tarafını kesin konuşuyoruz.
Yani konuştuğumuz net konulardan biri zaten monitoring devreye girdiği zaman işte incidentlar da devreye giriyor, log takibi de devreye giriyor vs.
Yani günlük hayatımda da böyle sıkça kullandığım ve böyle olmadığı zamanlarda ya da düzgün implement edilmediği zamanlarda eksikliğini çok hissettiğimiz uygulamalar olduğu için
ekstra da ilgimi çekti açıkçası.
Oldukça fazla... izin olduğuna eminim burada.
Özellikle teşekkür edeyim bu güzel uygulamalar için tüm Trendyol ekibi adına.
Peki birazcık daha aslında tribe'dan bahsedelim istiyorum.
Builder Platform olsam biraz bahsettim hani işte temellerini attığınızdan.
Builder Platform tribe'ından birazcık bahsedebilir misiniz burada?
Tabii. Bahsedeyim.
Biraz önce dediğimin devamını getireyim aslında.
Biz 2019 senesinde çok büyük bir incident yaşadık.
O incident'ı Biraz anlatmak istiyorum.
O zamanlar tek data center çalışıyorduk.
Tek data center çalıştığımız zaman da bizim scale'de şirketler için bunlar tabii ki availability ile ilgili soru işareti oluşturuyor.
Ve biz de o zaman çok büyük bir incident yaşadık.
O gün dedik ki artık biz tek data center değil birden fazla data center veya zonda çalışalım ki availability'imiz artsın gibi bir düşüncemiz oldu.
Bu sebeple ve buna ek olarak da şu vardı.
Bizim eskiden trend yol tek yani...
200 kişiydi, 300 kişiydi.
O civarda falandık biz yaklaşık o zamanlar.
Hadi 400 olsun, 500 olsun.
Şu an mesela teknoloji 2000 kişi.
civarı hatta plus diyebiliriz.
Böyle olduğu zaman ne oluyor?
2000 kişi demek bizim için 200'den fazla domain ekibi demek.
Bu ekibinde bir sürü uygulaması olduğunu düşünürsek biraz önce de dediğim gibi 7000'den fazla mikro servisimiz var.
Böyle olduğu zaman da bazı ortak sorunlar olabiliyor.
Çok basit development cycle sorunları.
İşte config management nasıl olacak?
İşte secretlar nasıl olacak?
İşte servis registriler. 7000 servis kimlere gidecek?
Nereden öğrenecek? Gibi gibi sorunları dedik ki biz bunları çözmesi için bir ekip oluşturalım.
Domain ekiplerini bu Gereksiz efordan kurtaralım dedik.
Ve ekibin temellerini hem MultiDC hem de bu dediğim gibi ortak sorunları çözmeye yönelik bir fokus ekip kurarak başlattık diyebiliriz.
Builder platformu tohumları burada atıldı diyebiliriz yani.
Bunu yaptıktan sonra da tabii ki zamanla aslında bizim bu developer productivity konularının ne kadar önemli olduğunu, bizim gibi büyük skeldeki ekipler için ne kadar...
Kritik değerlere sahip olun daha net gördük ve burada yapılanmaları start verdik diyebiliriz Builder platformda.
Şu an için Builder platformda 3 tane fokus grup var gibi düşünebilirsiniz.
Bunları da şöyle anlatayım. Bir Developer Productivity Engine'in kısmı var.
Bir RS var bir de SRE var.
SRE ekibi reliability konularına ilgileniyor genelde.
Hem on-premise hem de cloud kullanımında görev alıyor bu ekip arkadaşlarımız.
RS ekibimiz de aslında içeride in-house geliştirilen bir performans test platformu.
Tüm test süreçleriyle ilgili...
İçeriye platform olarak servis sunuyor ve ekip arkadaşlarımız buradan faydalanıyor.
DP'yi açacak olursam da DP'nin içerisinde 5 farklı ekip var gibi düşünebiliriz.
Bunlar neler? Extensibility, Application Delivery Platform, Pandora, Developer Portal diye açayım.
Observability ekibi ve Engineering Insight ekibi.
Bu ekiplerinde hepsinin kendine ait misyonları var.
Extensibility ekibi biraz daha runtime'daki sorunlara ilgileniyor.
Nasıl diyeyim? Caching optimizasyonları, cache solution, rate limit mevzuları, config secret yönetimi gibi gibi biraz daha runtime konularına destek veriyor diyebiliriz.
Kubernetes üzerinde zaten çoğunlukla.
ADP'de Application Delivery Platform.
Yine bu da tüm ekibimizde Trendyol Tech'e self-service kullanabilecekleri bir delivery platform sunuyor.
Pandora ekibi, Developer Portal aslında bizim builder platformun...
Trendyol teknolojiye açılan kapısı gibi düşünebiliriz.
Ürünlerimizi sunduğumuz, gösterdiğimiz bir portalımız.
Observative ekibi zaten konuşuyoruz artık.
Hani onun detaylarına gireceğiz zaten.
Bir de Angelic Insight ekibimiz var.
Bu da aslında bizim Trendyol teknolojideki metrikleri, dataları toplamayla ilgili.
4K metriktir, service maturity'dir vs.
vs. Bir sürü productivity ile ilgili kavramları ölçen ekip gibi düşünebiliriz.
Vallahi ben dinlerken bir noktada yoruldum.
Kolay olmadı işte dediğim gibi.
Beş senelik bir süreç olduğu için hani buralara gelmemiz bayağı bir zaman aldı.
İşte hatalar yaptık, dersimizi aldık, tekrar ayağa kalktık, devam ettik.
Ama sonunda iyi bir noktaya geldiğimizi düşünüyorum.
Evet, evet ben de katılıyorum.
7000 mikro servis konusu özellikle çok olduğunu biliyordum ama...
Bu civarda olduğunu bilmiyordum.
Bunu yönetmesi gerçekten oldukça zordur diye düşünüyorum yani.
Bunlardan da bahsederiz zaten.
Özellikle şey tarafında da biz mesela TBP ile birlikte ADP tarafında sunulan TBP'yi de mesela çok sık kullanıyoruz.
İşte deploymentlarımızla vesaire.
O yüzden böyle hayatımızın aslında şu an Trendyol içerisindeki her noktasına değiniyor diyebiliriz Builder platformun.
Biraz daha ekip yapısından bahsedelim istiyorum.
Çünkü aslında yani tribe...
genelinde çok çok geniş bir ekipler serisi var.
Fakat Observability Platform ekibi kaç kişidir, kimlerden oluşur, kaç backend, kaç frontend var falan.
Biraz da bunlardan konuşalım istiyorum.
Ekip yapısından biraz bahsedebilir misiniz?
Tabii ben bahsedeyim burada isterseniz.
Ekipte toplam 10 kişiyiz.
6 backend, 3 full stack engineer ve bir product managerımız var diyebilirim.
Aslına baktığınız zaman cross-functional bir takımız.
Yeri geldiğinde herkes her işe giriyor.
Ama biraz büyük bir domeniz.
karmaşık işlerle ve çok çeşitli işlerle uğraşıyoruz.
Bunun getirdiği bir şey oluyor. Ekipteki aslında bazı insanlar spesifik konularda daha uzmanlaşması gerekiyor.
Öyle bir farklılık var diyebilirim.
Bu kadar. Süper.
Yani aslında bu ekipte işte herkesin yeri geldiği noktada bir şeylere ulaşması, uzanması genel olarak aslında gördüğümüz bir şey Trendyol genelinde ama tabii bu ekip genelinde.
çok daha önem kazanıyor diyebiliriz.
Ekipte bu arada şeyi merak ediyorum.
Sizin şimdi frontend tarafınız da var.
Anladığım kadarıyla bir size de bakan bir dizayner arkadaş da var değil mi?
Evet yani dedike değil.
Farklı platformlara da bakıyor, farklı ürünlere de.
Ama evet dizayn da var UX.
Süper. Peki şeyi soracağım.
Sizin ekip için bir product ekibi diyebilir miyiz aslında?
Bir ürün ekibi diyebilir miyiz?
Evet gayet diyebiliriz diye düşünüyorum.
Çünkü bizim amacımız gerçekten bütünsel bir ürün ve biraz benchmarklara da bakarak böyle bir ürün, profesyonel bir ürün hedefimiz var.
Bu yönde çalışıyoruz. Dolayısıyla evet ürün olarak bakabiliriz.
Bayağı da geniş kapsamlı farklı komponentleri olan bir ürün diyebiliriz.
Harika, süper. Şimdi üründen konuşmuşken aslında bizim temel noktalarımızdan biri data ve sizin ekibin de...
Aslında en dikkat çeken özelliği bu kadar büyük datanın olması ve bu kadar büyük datayı bu kadar verimli şekilde işleyebilmek, bu kadar verimli şekilde yönetebilmek.
Şimdi Trendyol genelinde data yönetimi nasıl gerçekleşiyor?
Yönettiğimiz data sıkıca kontrol ettiğimiz bir resource aslında.
Sürekli olarak analiz edip anlık değişimleri gözlemliyoruz.
Biraz data ile konuşalım dersek, anlık 1.5 milyon log, 450 terabyte size.
Bize sahip bir log sistemimiz var.
Bir quadrillion data point'in olduğu ve bir petabyte boyutunda yine bir metrik altyapısı ve 2 milyon tracing geldiği bir trace altyapısı var.
Bu kadar büyük bir data yönetmek tabii ki kolay değil.
Hele ki bir cloud provider gibi faturalandıramıyorsanız.
Burada en büyük etkenlerden biri verinin ingestion sürecini tamamen user'lara bırakmamak ve belli başlı standartlara oturtmak oluyor.
Aynı zamanda bizim ekip içi kullandığımız bir tabir var.
Gelen verinin polisliğini yapmak diyoruz buna.
Aslında bunu yapmakta zorundayız.
Standartlara uymayan durumları yakalayıp standartlara uydurmalı veya işte sistem akışını bir noktada kesmek zorundayız stabiliteyi sağlamak için.
Gelen verinin polisliğini yapmak çok güzel tabirmiş.
Çok güzel tabirmiş gerçekten.
Ya valla açıkçası bahsettiğin değerler gerçekten akılda.
Hayal edilenin ötesinde bence yani en azından benim tabii ki daha büyük datalar vardır daha büyük datalarla çalışılabilir fakat hani gerçekten bence çok çok büyük datalar ve bunları yönetmesi
de zor yani öncelikle.
Tekrar kolay gelsin diyorum.
Buradaki standartize etmek konusu da bence oldukça önemli.
Çünkü data nasıl geliyorsa o şekilde alalım ve bunu işleyelim, yönetelim falan demeyip burada datayı öncelikle sorgulamak ve bunu bir standartize hale getirmek bence çok önemli.
Çünkü sonrasında yaşanabilecek problemleri direkt olarak önlemiş oluyorsunuz.
Güzel bir pratik bu. Gerçekten çok beğendim.
Tabii şimdi böyle büyük...
Datalarla uğraşırken ya da böyle büyük sistemleri kurmak da işte maintain etmek falan da zordur muhtemelen.
Ben burada şeyi biraz merak ediyorum.
Teknoloji tarafından neler yapıyorsunuz?
Hangi teknolojileri kullanıyorsunuz?
Buradaki tekstiliniz nedir tam olarak?
Tabii ben bahsedeyim biraz tekstilimizden.
Yani kendi projelerimizi in-house geliştirdiğimiz uygulamaları genelde Golang kullanıyoruz.
Bir tane Java ile yazdığımız bir uygulamamız var.
O da biraz kompleks bir...
Logik içeren bir uygulama olduğu için bir arkadaşımız Java ile yazmayı tercih ettiği için Java ile yazdık.
Onun dışında her şey Go. OpenTelemetry'nin kütüphanelerinin üzerine geliştirdiğimiz kendi kütüphanelerimiz ve agentlarımız var.
Aslında bunlar datanın ilk toplandığı noktalar.
Uygulamalar entegre oluyor. Bunları kullanıyorlar ve bize data gönderiyorlar.
Bunları tabii Trendyol'da kullanılan tüm diller için geliştirmek ve maintain etmemiz gerekiyor.
Nedir bunlar? Golang, Java, Node.js ve .NET.
Burada da şeyden bahsetmiş olalım.
Bizim çok mesela ekipte .NET tecrübesi olan hiç insan yok.
Orada da mesela farklı ekiplerden destek aldığımız noktalar oluyor.
Sağolsunlar bize de yardımcı oluyorlar.
Buradan da teşekkür etmiş olalım.
Onun dışında metrik altyapımızda datanın toplanması, iletilmesi, sorgulanması gibi kısımlar da Victoria Matrix.
Ürünün komponentlerini kullanıyoruz.
Görselleştirme kısmında ise Grafana var.
Zaten endüstri standartı.
Log tarafında ise verileri Fluentbit'te topluyoruz.
Yine iletiminde OpenTelemetry ve Kafka kullanılıyor.
Saklama kısmında Elasticsearch kullanıyoruz.
Görselleştirmede de Kibana var.
Distributed Tracing tarafında ise yine OpenTelemetry Kafka ikilisiyle datalar akıyor sistemimize.
Yine Elasticsearch'ta saklıyoruz.
Görselleştirme tarafında da bu sefer Jaeger kullanıyoruz.
O da bir CNCF ürünü.
Tüm bu verilerin üzerine geliştirdiğimiz tabii alerting sistemlerimiz var.
Zaten asıl olay orada bitiyor.
Burada da ağırlıklı olarak yine kendi geliştirdiğimiz sistemler var.
Intelligent Alerting gibi bazı sistemlerimiz var.
Bunların dışında bir de yine Victoria Metrics'in bazı tool'larından da yararlanıyoruz alerting kısmında.
Bir de şeyden bahsedebilirim.
TraceBlock kısmında biraz veri saklama kısmında daha doğrusu.
Elasticsearch yerine ClickHouse.
denemeye başlayacağız yakın zamanda.
Bunu da araştırdık. Bayağı bir bize optimizasyon sağlayacağını düşünüyoruz.
Yakın zamanda POC'lere başlayacağız.
Bu kadar bahsedebilirim teknoloji siteyimizden.
Vallahi harika. Yani burada bahsettiğin teknolojilerin ayrı ayrı mesela client tarafında biz hepsini aslında ayrı ayrı kullanıyoruz.
Fakat kullandığımız noktalar çok aslında sizin tarafa...
göre basit diyebiliriz.
Yani temel diyelim.
Biz de mesela Yager tarafını da yeni yeni kullanmaya başladık.
Onun dışında işte Kibana, Grafana falan zaten kullanıyorduk.
Fakat yine tabii sizin aslında geliştirdiğiniz tarafları kullanıyoruz gibi düşünüyorum.
Bir de ek olarak şeyi Söyleyebilirim.
Biz standart yapmaya çalışıyoruz.
Her şeyin belli standartta orada olmasını istiyoruz demiştik.
Bunu Onur'un dediklerine ek olarak şunu da diyelim.
Alertle ilgili önceden yani her Log, Trace ve Metric için ayrı ayrı alert sistemleri vardı.
Bu da çok sürdürülebilir olmuyordu.
Biz dedik ki bir standart belirliyorsak her şeyde standart olmalı.
O yüzden tek bir alerting sistemi geliştirdik.
Bu alerting sistemi hem Log'a, Metric'e ve Trace'e üçüne birden de bakıp alert oluşturulabiliyor, takip edilebiliyor ve AHA bir şekilde çalışıyor.
Bunu da eklemiş olalım. Süper, harika.
Benim şimdi bir şey geldi aklıma, bir soru geldi.
Burada mesela yeni bir teknolojiyle işte Clickhouse'dan bahsettiniz işte orayı deneyeceğiz dediniz.
Yeni bir teknoloji deneyeceğiniz zaman standartlarınız neler oluyor, nelere bakıyorsunuz, nasıl başlıyorsunuz?
Yani diyelim bir şey değiştireceksiniz mesela örnek veriyorum Kibana yerine başka bir şey entegre edeceksiniz.
Buradaki analiz ve POC süreci nasıl ilerliyor?
Bu sizin tarafınızda aslında büyük bir değişiklik.
En küçükten itibaren analize POC'ye nasıl başlıyorsunuz?
Nereden başlıyorsunuz? Burada belki ben bir gireyim.
Belki arkadaşlar da yine destekler beni.
Eksiklerim olursa da onlar tamamlayabilir.
Burada bu dediğin aslında bizim sektörde çok olağan şeyler.
Çünkü her gün yeni bir teknoloji çıkıyor.
Hani her konuyla ilgili yeni bir gelişme, yeni bir ürün geliyor.
Buradaki aslında bizim izlediğimiz yol şu.
Biz her zaman bir tek radarımız var içeride kendi takip ettiğimiz.
Bu tek radar içerisindeki herhangi bir tool ile biz destek alabiliyor muyuz?
Yani bizim o anki senaryodaki ihtiyacımızı çözebilmek için ne kullanabiliriz diye kendi meçhurtimizin yüksek olduğu ürünleri öncelikle yöneliyor.
O çözmüyor mu bizim işimizi?
O zaman diyoruz ki biz ne kullanabiliriz?
Ne yapabiliriz? Buradaki soruna en iyi cevap verecek teknoloji nedir?
Diye bakıyoruz. Bu arada bir parantez açayım.
Biz hiçbir zaman tool'u amaç olarak görmüyoruz.
Tool her zaman bizim için adı üzerinde bir tool'dur, bir araçtır.
Hedefimize gitme de bize destek olacaktır.
Daha az eforludur, daha efektiftir.
Onlara göre bakarız. Nasıl oluyor dersek örnek veriyorum.
Observatory ekibini düşünelim. Dediğim gibi çok büyük bir sistem.
Burada yapılacak bir değişiklik çok fazla etkileri olabilir gibi.
Biz o yüzden sistemi buna göre tasarladık.
Örnek veriyorum. Biz datayı ne dedi onur?
İşte Elasticsearch'te saklıyoruz.
Ama biz bu sakladığımız yapıyı öyle bir ayarladık ki biz bunu birden fazla yeri destekleyecek şekilde zaten konfigüre ettik.
Hani örnek veriyorum biz şimdi Clickhouse'u denemek istediğimiz zaman yapacağımız şu.
Bir Clickhouse kurulumu yapacağız.
İşte best practice'leri takip ederek.
Ondan sonra biz iki tarafı da bestleyeceğiz.
Ondan sonra bunları bir benchmark yapacağız.
Hani bizim kullandığımız senaryolar, şu an eziz yapıda sorun olan yerler yeni yapıda nasıl, bütün senaryolarımızı cover ediyor mu gibi gibi aslında çok kısa olmayan bir süreçle.
karşı karşıya olacağız. Ama burada şöyle bir durum da var.
Tabii ki çok kritik durumlarda daha hızlı aksiyonlar almamız gerekebilir.
Ama şu anki sistemi göz önünde bulundurduğumuz zaman bizim şu an aslında eziz teksteğimizle kanayan bir yerimiz yok.
Tabii ki gelişim yerlerimiz var.
Daha efektif olması gereken yerler var.
O yüzden daha böyle kendine emin sakin bir şekilde iki tarafı da sürekli işte test ederek benchmarkları dediği gibi arkadaşlarımın dataları kıyaslayarak en doğru çözüme gitmeye çalışıyoruz diyebiliriz.
Aslında bu Tüm teknoloji stack için geçerli bu arada.
Hani database'den ben örnek verdim ama yazılım dili de olabilir bu.
Başka bir şey de olabilir. Dediğim gibi çok fazla bir yelpazemiz olduğu zaman bizim buralara support vermemiz veya production'da olan bir incident'a hızlı aksiyon almemiz zor oluyor.
O yüzden de belli standart takip etmemiz gerekiyor.
Yani örnek veriyorum bir dil çıktı.
Örnek veriyorum Rust mesela şu an çok günceldir.
Hani herkes de çok över sever.
İyidir, efektif bir dildir zaten.
Hani ona kimsenin diyeceği bir şey yok. Fakat bu dili bilen kaç kişi var?
Bir sorun olduğunda biz nasıl bu sorunu hızlıca çözebiliriz?
Bizim bunlar önemli noktalar aslında.
Yani bizim üzerinde durduğumuz noktalar bunlar.
Öncelikle bir maturity'miz yükselsin.
Bunun için şu tarz yaklaşımlar da yapabiliriz bu arada.
Daha böyle önemi düşük servislerden başlayarak yani core commerce kritik servisler değil de daha böyle helper işte hani sıkıntı olduğunda bizi çok böyle başımızı ağrıtmayacak servislerde denemeler yaparak da maturity
kasabiliriz aslında. Kısaca bu şekilde.
Anlatmış olayım. Trend yolu genelindeki teknoloji seçimi de aslında bu tarz ilerliyor diyebiliriz.
Aynen, aynen katılıyorum.
Birçok aslında teknoloji yelpazesi bu kadar geniş olan ekibe bu soruyu özellikle soruyoruz.
Çünkü her ekibin...
yönelmesi her ekibin uyguladığı pratikler farklı.
Özellikle sizin gibi böyle standartlar belirlemeyi zaten seven ve bunları pratik eden ekiplerde bu çok görülüyor.
Şeyi de çok beğendim yani siz aslında buradaki hizmet akışında buradaki işte data akışında ya da işte ne derseniz bir kesinti olmaması için aslında her şeyi standartize ettiniz ve bu standartize ettiğiniz
şeyde X elementini de koyduğunuz zaman, Y elementini de koyduğunuz zaman sistem zaten tıkır tıkır akıyor, çalışıyor durumda.
Çok güzel bir pratik.
Harika yani ben çok beğendim.
Onu da araya sıkıştırmak istedim, sormak istedim.
Şimdi mesela benim bir tane uygulamam var, onu da sorayım.
Bir tane uygulamam var ve sizin platformunuza Observability...
Platformuna entegre olmak istiyorum.
Artık işte monitoringimi ve işte ne bileyim uygulamalarımın sağlığını vesaire her şeyi observability platformunun geliştirdiği tool'lar ile yapmak istiyorum.
Buraya entegre olmak istiyorum.
Ne yapmam lazım tam olarak? Şimdi son zamanlarda en çok aldığım ve en sevdiğim sorulardan biri bu.
Yakın zamanda log alt yapımımızdaki değişikliği buyurduk ve bu soruyu oldukça sık alıyoruz bununla beraber.
Cevabı da oldukça basit şu an bizim için.
It's magic diyoruz. Şaka bir yanına tek yapılması gereken TBP entegre olmak.
Yani başka hiçbir şey düşünmek zorunda değilsiniz.
Hatta bir entegrasyon da değil aslında bu kimse için.
Zaten hala hazırda TBP herkes geçiş yapıyor.
Ve bununla beraber sihirli bir şekilde logları da...
Available bir sisteme akıyor. Yeri kalan süreci zaten tamamen Beholder otomatize ediyor.
Burada herhangi bir manuel aksiyon ve operasyon alınmıyor.
İstiyoruz ki tüm servislerimiz de bundan sonra TBP integral olsun.
Ve bunun için çalışıyoruz aslında.
Diğer servislerimizden de kısaca bahsetmek isterim burada.
Trick için Prometheus'a uygun formatlı metiklerinizi expose ediyorsunuz.
Ve bir servis monitörü tanımlıyorsunuz.
Yine gerisi Beholder tarafından otomatize ediliyor.
Yine alert için de benzer bir yapı var.
Zaten metrik için querylerinizi atıyorsunuz, dashboardlarda kullanıyorsunuz, explore'da atıyorsunuz.
Tek fark bu Aysel'in de bahsettiği gibi yeni UI aracılığıyla gelip bize register ediyorsunuz.
Bu benim için ben bir alert tanımlamak istiyorum diye.
Trace için de şöyle bir opsiyonumuz var.
Viewholder olarak sunduğumuz SDK'yi uygulamanıza import ediyorsunuz.
Bu kadar basit aslında. Geri kalan süreç uçtanınca bir yoldur tarafından otomatize ediliyor.
Bir de Mergen Client Observability için yazdığımız SDK'leri hem CDN hem de NPM üzerinden kolaylıkla çalıştırabiliyorsunuz.
Her bundler için gereken bütün pluginler de bizde mevcut.
Herhangi bir performansa etkisi olmadan tüm...
Telemetri için, log trace metri için enstrümente ediyoruz.
Tabii ki bunlar hakkında son derece ayrıntılı dokümanlarımız da wiki sayfamızda bulunuyor.
Bizim buradaki asıl amacımız müşterilerimize, çalışma arkadaşlarımıza minimum eforla hatta herhangi bir efor sarf etmeden bize entegre olmaları diyebiliriz.
Ben özellikle dokümanlarınızı çok beğendiğimi söylemek isterim.
Çünkü biz de client tarafında gerek TPP gerek Prometheus'taki metrikleri vesaire işte Grafana'daki dashboardlarımız hepsine geçiş yaptık ve çok sık da kullanıyoruz.
Ben de yakın zamanda Prometheus tarafındaki metriklerle biraz uğraştığım için sizin taraftaki dokümanları çok beğendiğimi de söylemem lazım.
Çok böyle yani kullanıcı girdiği zaman hiç ekstra bir şeyle ilgilenmeden Nerede konfigüre etmesi gerektiğini falan bakıp direkt olarak görebiliyor.
Bence çok güzel bir şey.
Bunu duyduğumuzda çok sevindik ekip olarak.
Biz de dokümentasyonlara büyük bir önem veriyoruz.
Ve herkesin Beholder'ın dokümentasyonlarından mutlu bir şekilde ayrılmasını istiyoruz.
Bunun için NPS'e kadar her türlü hizmeti sunuyoruz.
Bu konuda feedback almaktan da oldukça mutluyuz.
Hem olumlu hem de geliştirici feedbackler için.
Tüm ekip arkadaşlarımıza da teşekkür etmek isterim bir kere daha.
Süper. Tam feedback ile alakalı soracaktım.
Size feedback bu konuda alakalı feedback vermek isteyenler sanırım Public Kanal ya da Pandora üzerinden vesaire ulaşabilir diye düşünüyorum.
Tabii ki orada zaten görünür bir şekilde hem MPS için hem de bize iletecekleri feedback için belirli alanlarımız mevcut.
Gerekirse bize DM'den dahi ulaşabilirler.
QA'miz de var aynı şekilde.
Public Kanallarımız var. Ulaşılabilir olmayı çok seviyoruz.
Lütfen bize ulaşın. Süper.
Harika. Açıkçası bu kadar kullanıcı dostu bir platform geliştirmek de...
Kolay bir şey değil. Benim merak ettiğim konulardan biri de o.
Siz bir platformu kullanıcı dostu hale nasıl getiriyorsunuz?
Yani bunu yapmak da çok güç bir şey diye düşünüyorum.
Bu konuda biraz meraklarım var açıkçası.
Bir platform kullanıcı dostu hale nasıl getiriliyor?
Evet burada amacımız self-service bir platform sunmak.
Dediğimiz gibi aslında entegre olacak tool'ları ve raporlama ve aksiyon alma için kullanıcı arayüzleri sağlamayı hedefliyoruz.
Mümkün olduğunca da kognitiv love vermeyen kullanıcıya ve akışları da böyle basitçe aksiyonlar alabileceği bir yapıyla sunmayı tasarlıyoruz ve hedefliyoruz.
UX dizaynı var bildiğiniz gibi ama tabii ki ne yapıyoruz?
Birden fazla ürünün benchmark'ını yapıp aynı zamanda kendi akışımızla...
bunları güzel bir şekilde öncelikle tasarlamaya çalışıyoruz.
Burada yine... Kullanıcılarla bazı seanslar yapıp bakın böyle bir tasarım hedefledik size nasıl görünüyor diyoruz ve buradan da bir feedback almaya çalışıyoruz.
Aynı zamanda tabii ki hani ürün analitikleri var.
Ürün analitiklerinde de belli konulara bakıyoruz.
Burada daha gelişim alanımız var.
Hotjar'da bir takım analitiklere bakıyoruz.
Clarity'de aynı şekilde.
Örneğin bazı kendi oluşturduğumuz adaption gibi şeyler de var.
Bunlara da bakıyoruz. Dolayısıyla burada iteratif bir şekilde bunu yapıyoruz.
Önce tabii ki baştan feedback alıp güzel bir şekilde tasarlamaya çalışmak üstüne de belli analitiklere bakarak.
burada geliştirmeler yapmak.
Amacımız bu. Aynı zamanda platformu da kullanıcı dostu derken bence evet platform öz bir şekilde monitoringi yapabileceği ve drill down edebileceği yani detaylara bakabileceği araçları sunuyor.
Ama aynı zamanda zeka katmayı da hedefliyoruz.
Bazı projelerimizde başladık.
Örneğin akıllı alarmlar, anomaliye göre alarmlar ya da kök sebebi bulmaya çalışmak gibi.
Çünkü diyoruz ki biz end-to-end observancy sağlıyoruz.
Aslında bir sürü veri var platformumuzda.
Dolayısıyla bu tarz yapılar kurmak veya bunların kurulmasına katkıda bulunmak bir hedefimiz.
Ayrıca tabii dokümanlardan biraz önce bahsettim.
Güncel ve öz tutmaya gayret gösteriyoruz.
Burada elbette kullanıcılar hala gelip bize sorular sorabilir, destek isteyebilir.
QA platformuna yönlendiriyoruz genelde kullanıcıları.
Direkt feedback de alabiliyoruz elbette ama direkt support aldığımız veya soruları cevapladığımız kısım Pandora QA tarafı.
Burada da yine bazı akışlarımıza kullanıcıların da kolay yönlendiren veya cevaplayan akışları entegre etmeyi planlıyoruz yapay zeka ile.
Bu tarz araçları var geliştirdiği Trendyol'un.
Yine bizim tribe'ımıza da geliştirilen.
Bu şekilde hedefimiz bu diyebilirim.
Süper. Aslında son söylediğine ek bir soru daha sormak istiyorum.
İşte Trendyol'da bu şekilde geliştirilen tool'lar var.
Onları da kullanmaya çalışıyoruz dedin Aysel.
Burada aslında sorun biraz daha şey.
Hani işte sizin çalıştığınız domenlerle, takımlarla alakalı.
Baktığımız zaman çok geniş kapsamlı bir tool.
Çok geniş kapsamlı aslında yapılan işler.
Ve çok fazla da şeyiniz var.
Consumer'unuz var aslında yani.
baktığınız zaman. Fakat sizin tarafınızda da yani sizin de işte konsum ettiğiniz servisler olabilir, işte beraber yakın çalıştığınız ekipler olabilir.
Burada hangi domenlerle ve veya takımlarla yakın çalışıyorsunuz?
Bir yoldurun sunduğu hizmetler doğrultusunu Trendyol'daki hemen hemen tüm ekiplerle çalıştık ve çalışmaya devam ediyoruz.
Zaman zaman daha yoğun çalıştığımız ekipler de oluyor tabii ki.
Özellikle de infra ekipleriyle sıkı bir iş birliği içerisindeyiz.
Trafik ekibiyle tüm ortamlardan datayı bir holdere yönlendirebilmek amacıyla sık sık çalışıyoruz.
Provider ekipleriyle custom flavor ihtiyaçları üzerinde uzun süre çalıştık.
Bu konuda bize çok büyük destekler oldu.
Yakın zamanda TBP konsol için Builder platform ekipleriyle yakından çalıştık.
Yine keza Pandora ekibiyle çalışıyoruz.
Böyle bu şekilde birbirimize destek olduğumuz uzun bir birlikteliğimiz oldu bu ekiplerle beraber.
Ve umuyoruz ki devam edecek.
Aslında ben burada bir yoldur tarafını, observability tarafını birazcık daha tam olarak ortada bir yerde görmeye başladım.
Yani siz hem gerektiği yerde consumer oluyorsunuz, gerektiği yerde provider oluyorsunuz.
Yani bir dal, ağaç olarak bakacaksak olaya tam aslında ortada, kalbe yakın yerde duruyorsunuz diyebilirim.
Kritik bir nokta aslında.
Kritik bir yer baktığımız zaman.
Beholder'ın kullanılabilirliği neden bu kadar kritik?
Buna gerçek örneklerle anlatmayı ben çok seviyorum.
Yine yakın zamandaki bir örnekten bahsedeyim.
Bir servisimizde bir sorun çıktı.
NS Change olarak yaptığım ilk iş Beholder Trendyol.com'u ziyaret etmek oluyor.
Burada çeşitli dashboardları özellikle Application Performance Monitoring gibi bizim önceden hazırladığımız dashboardları inceliyoruz.
Servisimizin durumunu gözledikten sonra troubleshoot ihtiyacı için ise yine Beholder'ın altyapısına gidiyoruz.
Diyelim ki bir senaryo oldu ve Beholder'a ulaşamadınız.
QA'den, DM'den, public kanallardan aldığımız ilk tepki kör olduk oluyor.
Bu nedenle Beholder'ı trend yolun gözü olarak konumlandırabiliriz sanırım.
Bu durumun yaşanmaması için high availability sisteme sahibiz.
Multi DC çalışarak datayı cross DC'ye de yazıyoruz aynı şekilde.
Bu sayede herhangi bir data kaybı olmuyor.
Availability'den herhangi bir ödüm vermiyoruz.
Trend yolun gözü...
olarak söylemem biraz bir tık manidar çünkü Beholder aslında bilenler bilirler şey tarafında bu işte fantastik tarafta aslında tek gözlü bir mistik bir
karakter olarak geçiyor.
Bu da bence güzel bir örnek oldu yani ama kör olduk konusu çok çok nokta atışı bir tabir oldu bence yani.
Bu arada gerçekten de isim Beholder'ın kurulduğunda oradan geliyor diyebiliriz.
Aynen D&D oynayanlara buradan selam.
Süper. Valla yani gerçekten dinlemesi bile böyle stresli bir şey.
Yani aslında bir noktada çok keyifli olduğunuz yer bir noktada da oldukça stresli çünkü baktığınız zaman...
Biz sonuçta bir noktada müşteriniziz aslında sizin ve biz kullanıcılar olarak da tarafta kullandığımız noktada çeşitli işte taleplerimiz olabiliyor, feedbacklerimiz olabiliyor ve bunları da yönetmek oldukça
zor. Siz burada kullanıcılardan gelen talepleri nasıl yönetiyorsunuz?
Evet, talep geliyor tabii ki bize.
Feedbackler alıyoruz ya da birebir DM'den vesaire her yerden aslında her kanaldan feedback gelebiliyor veya feature request gibi talepler gelebiliyor.
Değerlendirirken neye bakıyoruz?
Öncelikle bizim bir ürün, strateji, misyon, vizyonumuz var.
Bununla örtüşüyor mu diye bakıyoruz.
Bu önemli bir kriter. Onun dışında etki ve efor var tabii ki.
Bir puanlama da yapmamız gerekiyor burada.
Kullanıcıya faydasını anlamaya çalışıyoruz.
Bir de benchmark mesela önemli.
Hani yaptığınız ürünlerde olan temel bir özellik mi olması gereken yoksa çok spesifik, nice to have bir şey mi talep edilen şey onu anlamaya çalışıyoruz.
Kullanıcı etkisini anlamak için de mesela bazı surveylerimiz var.
Anketlerimizde direkt belli özellikleri, planladığımız özellikleri ilgilenir misiniz ya da size fayda sağlar mı gibi sorup cevap almaya çalışıyoruz.
Ayrıca incubating team inisiyatifimiz var.
Bu da bizim observability platform için farklı domenilerden oluşturduğumuz farklı...
domenleri kapsayan geniş bir kullanıcı gruplu, focus user grup diye bildiğimiz bir yapı.
İki haftada bir toplanıyoruz ve burada mesela planlarımızı anlatıyoruz, gelen talepleri değerlendiriyoruz, bazen release'lerimizi demo ediyoruz.
Burada da gerçekten talep edilen konuların kullanıcı belli kullanıcılara mı sadece özel olduğunu, herkese hitap edip etmediğini sağladığı faydayı anlamaya çalışıyoruz.
Yani birebir karşılıklı etkileşerek bence çok kıymetli bu gruplar açıkçası.
Çok faydasını gördüğünüzü söyleyebilirim.
Önceliklendirmede de buradaki input'u göz önüne alıyoruz diyebiliriz.
Ayrıca tabii ki aynı zamanda bazı analitiklere de bakıyoruz.
İşte adaption'dır, ne kadar kullanıyorlar, kaç ekip kullanıyor, hangi özellikleri kullanıyorlar gibi.
Tabii ki bir de NPS skorumuz var.
Bunu da toplamaya çalışıyoruz farklı yollarda ve onu da ölçmeye çalışıyoruz.
Valla her ne kadar çok fazla anket çözmeyi sevmeyen.
Anket doldurmayı sevmeyen bir insan olsam da her fırsat bulduğum zaman Trendyol içerisindeki böyle güzel işler yapan ekiplerin anketlerini doldurmaya çalışıyorum.
Şeyden de haberim yoktu açıkçası işte update'lerin verildiği bir meeting olduğundan da haberim yoktu açıkçası.
Kişisel olarak bundan sonra katılım sağlayacağımı söyleyebilirim.
Çünkü her ne kadar aslında şey gibi görünse de işte bizim tarafla bir alakası yok gibi görünse de aslında çok...
Yakın bir şekilde çalışıyor gibiyiz yani.
Her ne kadar bizim sizin tarafa mesela bir katkımız gözle görünür şekilde olmasa da sonuçta biz bir...
Konsümer olduğumuz için sizin tool'unuzda bir deneyimimiz oluyor.
Bu tabii ki Trendyol geneli için söylüyorum.
Yani her ekipte var bu. Ve bunu da toplamak, yönetmek falan oldukça güzel.
Bunu yönetebilmek oldukça güzel diyebilirim.
Burada birazcık şeyden bahsedelim istiyorum.
Şimdi tool ile alakalı, observability ile alakalı çok konuştuk.
Çok şey paylaştık. Fakat birazcık da aslında her günümüz tabii ki güneşli olmuyor.
Zorluklar böyle işte sık...
sıkıntılar falan başımıza gelebiliyor.
Observability platformunda yaşadığınız en büyük zorluklar nelerdir burada?
Ben burada şey diyebilirim yani ben bir senedir bu ekipteyim yaklaşık ve hala birçok yani her gün böyle aydınlanıyorum yani yeni şeyler öğreniyorum.
Çok kompleks ve büyük bir domain.
Bence en büyük zorluğu bu kesinlikle.
Onun dışında zaten Aysel ile Enes de bahsetti.
Doküment etmemiz çok kritik.
Güzel dokumentasyon yapmamız ve kolay kullanılabilir ürünler yapmamız çok kritik.
Bunu yapmadığımız durumda gelen destek talepleri, kullanıcılarımızdan bize açılan destek şeyleri, istekleri çok fazla vaktimizi almaya başlıyor ve bu da doğrudan üretkenliğimiz ve motivasyonumuzu düşürüyor.
Tabii Trendyol ölçeğinde ve mikroservis mimarisine kullanıldığı bir sistem de...
Observability biraz kritik bir hale geliyor ve observable sistemler tasarlamak gerçekten zorlaşıyor.
Aslında mikro servisin getirdiği bir problem.
Bunun sonucunda da yine Enes'in bahsettiği gibi saniyede 2 milyonun üzerinde Logspan datasının yazıldığı bir sistemi ölçeklenebilir ve yüksek erişilebilir şekilde tasarlamak ve ayakta tutmamız gerekiyor.
Bu da çok zorlu bir şey diyebilirim açıkçası.
Tam burada şöyle bir...
Soru sormak istiyorum.
Şimdi zorluklardan bahsettik.
Onur sen de dedin ki işte yüklerle alakalı bir bazen zorlanmalar olabiliyor.
Burada operasyon yüklerini siz nasıl dengeliyorsunuz?
Nasıl bir denge durumunuz var orada?
Yani sadece V-Holder gibi değil.
Muhtemelen tüm tren yola hizmet veren diğer...
platformlar, projeler için de aynı şey söylenebilir ama operasyonel yükleri dengelemek mümkün olmayabilir.
Bu yüzden en başta izin vermemek gerekiyor bence.
Biz de bu yüzden Weekly Operational Review Meeting adında bazı toplantılar düzenliyoruz.
Bu meetinglerde geçtiğimiz süreci işte haftalık, aylık olabilir.
Analiz ediyor ve bu hatta aldığımız support requestlere kadar indirgiyoruz bazen.
Her sürecimizi otomize etmeye odaklanıyoruz.
Eğer ki manuel yürütülen bir operasyon var ise ekip üyelerinden biri burada bayrak kaldırıyor ki bu genellikle haftanın nöbetçisi oluyor.
Ekipte manuel operasyonlara izin vermiyoruz demek yanlış olmaz az önce de söylediğim gibi.
Tabii ki bunun trade-off'unu hesaplıyoruz.
Her zaman manuel süreçleri otomatize etmek mi yoksa buradaki yapını refaktör edip yeniden başlanması mı?
Süper. Yani burada dengeli bir ilerleyiş sağlamak çok güzel.
Çok önemli. Şimdi birazcık daha aslında şey tarafından da sormak istiyorum.
Ekiple alakalı zaten konuştuk ama şey tarafını konuşmadık.
Şimdi observability tarafına...
Rotasyonlar ileriki oluyordur ya da işte yeni alımlar ileriki oluyordur.
Ekibe yeni biri geldiği zaman süreç nasıl ilerliyor?
Ekibe yeni biri geldiği zaman aslında süreç çok aşırı farklı ilerlemiyor.
Şöyle düşünelim hani biz nasıl observanti ekibinin ürünlerini kullanmak isteyenlere dökümanlarımızı gösteririz veya eğitimlerimizi videolarımızı yolluyoruz.
Aslında ekibe yeni gelen de ilk önce öyle bir giriş yapıyor.
Biz önce bir dökümanlarımızdan bahsediyoruz.
Yani bir onboarding sürecimiz var tabii ki.
Oradaki mevzu biraz şöyle ilerliyor.
Dökümanlardan başlıyoruz bir göz gezdiriyor.
sesyonlarımız varsa kritik olduğunu düşündüğümüz kendi domainimizle alakalı.
Onları işte arkadaşa, katan arkadaşa yolluyoruz.
Onun dışında zaten trend yolu genelinde de yaygın olan bir yaklaşım var ya.
Payr. Yani elini sokmadan öğrenemezsin.
O yüzden biz yeni gelen arkadaşlar çoğunlukla yani ilk birkaç ayında böyle sürekli payr olması payrinden, ekipte eski olan arkadaşlardan işler nasıl ilerliyor, projeler nasıl geliştiriliyor, nerede ne gibi sıkıntılar var işte.
Hatta şunu da yapıyoruz. İlk birkaç ay zaten saporta direkt girmiyor arkadaş.
Ki hani birinin yanında giriyor, bakıyor nasıl, nereye bakmalı, neyi nasıl yapmalı.
Aslında burada en önemli şey bence onboarding sürecini iyi atlatabilmek için ekip ruhunun güzel olması.
Trend yoldaki en büyük öncelik budur her zaman.
Her zaman takım ruhuna vurgu yapılır.
Her zaman takım en öndedir.
Teamwork bizim hani bir şeyimizde var ya sözümüz.
Teamwork makes the dream work. Aslında biz direkt buna uygun ilerliyoruz.
Takımımızdaki iletişimi had safhaya çıkarıp bu şekilde yeni gelen arkadaşlarında kolayca ekibi ısınabilmesi, hızlıca gerekli bilgilere sahip olması için yardımcı oluyoruz diyebiliriz aslında.
Bir tane de dedike badisi oluyor tabii ki.
Örnek veriyorum. Onur geldi.
DNS Onur'un badisidir.
İşte 2-3 ay onudur. Onun sorunlarına direkt cevap vereceğim.
Süper. O zaman son sorumu sorup ufaktan kapatalım diyorum.
Bizim her ekibe sorduğumuz klasik bir sorumuz var.
Ekip kaynaşması konusu.
Ekip kaynaşması için beraber yaptığınız etkinlikler, aktiviteler var mı?
Nasıl kaynaşıyor sizde ekip?
Yani ekip günlerimiz oluyor.
Ekip günlerimizde çeşitli aktiviteler deniyoruz.
Son ekip günümüzde mesela go kart yaptık.
Çok eğlendik. Baya eğlenceliydi.
Bir daha tekrarlamak istiyoruz hatta.
Onun dışında cuma günleri oyun saatimiz var.
Mesai sonuna doğru bir saat böyle beraber Zoom'da buluşup genelde Secret Hitler oynayıp birbirimize düşüyoruz.
Ama çok keyifli oluyor. Seviyoruz yani.
Onun dışında İstanbul'daki arkadaşlarımızla bir süredir her hafta perşembe günleri, ay sonrası basketbol oynuyoruz.
O da güzel. Hem sağlık açısından hem gerçekten kaynaşma açısından keyifli oluyor.
Hatta bunu biraz böyle tribe'a doğru yaymaya da başladık.
Tribe'dan diğer arkadaşlarımız da geliyor.
Sadece bizim takım değil. Özetle beraber eğlenceli, kaliteli vakit geçirdiğimiz bayağı aktivite yapıyoruz diyebilirim rahatlıkla.
Süper. Aslında son olarak yani demin son demiştim ama şimdi son olarak bir ekstra soru daha sormak istiyorum.
Aklıma geldi merak ettim.
Obsorability tarafında gelecek planlarınız nelerdir?
Neler yapmayı düşünüyorsunuz?
Buradaki gelecek planlarımız aslında çok şeyler değil yani bilinmezler değil.
Güncel endüstriyi takip ettiğimiz zaman genelde herkes işte productivity, optimizasyon, işte cost.
azaltma gibi operasyonlara yöneldiği için aslında bizim amaçlarımızın birincisi tabii ki kostu azaltıp o şekilde ilerlemek ve bizim bu yeni kurduğumuz standartize yapının Öncesinde de eski yapı var.
Hala daha kullanımda olan.
Aslında o eski yapıları da tamamen ortadan kaldırıp yeni kurduğumuz yapıyı %100 bir şekilde Trendyol teknolojiye yaygınlaştırmak ve kullandırmak istiyoruz.
Aslında hedefimiz bu. Bunun yanında dediğim gibi on-premise de olsa, cloud da olsa, çok düşük miktar cloud kullanımımız da var.
Bu kullanımları azaltmak, bazı lisanslı ürünleri in-house geliştirip oradan da yıllık lisans maliyetlerinden kurtulma gibi hedeflerimiz var diyebilirim.
Harika. Süper. Çok teşekkür ederim.
Valla arkadaşlar iyi ki geldiniz.
Çok teşekkürler. Dolu dolu bir bölüm oldu.
Ben çok keyif aldım. Ağzınıza sağlık.
Çok teşekkür ederim. Biz teşekkür ederiz.
Umarım bir insight verebilmişizdir.
Observability takımı ne yapar, nedir, ne değildir diye.
Şahsi olarak çok daha fazla şey bildiğimi söyleyebilirim.
Çok daha fazla şey öğrendiğimi söyleyebilirim.
Umarım arkadaşlarımız da böyle düşünüyordur.
Tekrar çok teşekkür ederiz.
Bir sonraki bölümde görüşmek üzere başka bir ekiple.
Kendinize iyi bakın. İyi günler.
Bu transkript otomatik olarak çıkarıldı; kayıtla küçük farklar olabilir.