Konuklar: Gizem Uzar, Levent Anıl Özen, Mert Can Bilgiç, Yusuf Mert Yıldırım
83. bölümümüzde konuğumuz Observability 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 Web Search ekibinden Cengiz.
Teknoloji ekiplerini tanıdığımız ve süreçler, teknolojiler gibi konuları konuştuğumuz Selam Ekip Podcast serisinin 83.
bölümündeyiz. 83.
bölümde Obsorability ekibiyle birlikteyiz.
Obsorability ekibini tanıyıp, ekip yapısı, kullanılan teknolojiler, pratikler gibi konuları konuşacağız.
Arkadaşlar hepiniz hoş geldiniz.
Hoş bulduk. Hoş bulduk.
Selamlar, hoş bulduk.
Süper. Bugün yine harika bir ekiple beraberiz.
Özellikle benim dört gözle beklediğim bir bölümdü.
Obsorability çünkü bizim Trendyol içerisinde bildiğiniz üzere aslında en sık kullandığımız tool'ları içeren ekiplerden biri.
Daha öncesinde Beholder bölümünde de bahsetmiştik.
Orada da aslında benzerler diye düşünebiliriz.
Obsorability tarafıyla alakalı da bugün birçok şey öğreneceğiz.
Öncelikle arkadaşlar kısaca kendinizden bahsedebilir misiniz?
Selamlar. Ben Levent Anılözen, 31 yaşındayım.
Bir buçuk yıl kadarı platform absorpti tarafında olmak üzere beş küsur yıldır Trendyol'da çalışıyorum.
Daha önce çeşitli domain takımlarında ve platform projelerinde çalışma deneyimim oldu.
Baklava da onlardan biri mesela.
Ya da internal bazı tool'lar.
Burada çalışıyorum bir buçuk yıldır.
Topu bırakayım. Selamlar, ben de Mert Bilgiç.
Yaklaşık 4,5 yıldır Trendyol'dayım ve bu 4,5 yılın tamamı Developer Productivity Engineering ekipleri altında geçti.
Trendyol içerisinde Developer'lar tarafından aktif kullanılan birçok projeyi benim elimden geçti diyebilirim.
Yaklaşık 1 yıldır da Observability ekibindeyim ve ekip arkadaşlığımla beraber Mergen'i geliştiriyoruz.
İlerleyen dakikalarda da zaten Mergen projesinden bahsedeceğiz.
Ben de Evralıyım.
Selamlar herkese. Ben de Yusuf Mert.
Yaklaşık 2 yıldır Trendyol'da çalışıyorum.
Bu 2 yılın tamamı Mert'in de söylediği gibi bende de aynı şekilde Developer Productivity Engineering ekipleri içinde geçti.
Bundan önce Extensibility ekibindeydim.
Yaklaşık 6 aydır da Beholder ekibinin altında mergen projesiyle uğraşıyorum.
Daha çok backend ve infra tarafıyla uğraştığımı söyleyebilirim.
Çok heyecanlı bir ürün var size anlatmak istediğim.
Birazcık heyecanlıyız o yüzden.
Ben de topu gizeme atayım.
Selamlar. Arkadaşlarıma kıyasla ben de şunu belirteyim.
Ben sadece iki aydır Trendyol'dayım.
Observability Platform ve Observability Experience ekiplerinin Product Manager'ı olarak görev alıyorum.
Daha önce şudan başlayayım aslında.
Yıldız Teknik Üniversitesi Elektronik ve Haberleşme Mühendisliği mezunuyum.
On yıl önce kariyerime Network Mühendisi olarak başladım.
Beş sene kadar Network Mühendisi olarak çalıştıktan sonra pandemiyle beraber bir kariyer değişikliğine giderek hem iş analisti hem de infra tarafından Product Manager olarak farklı şirketlerde görev aldım.
İki aydır da Trendyol'dayım.
Ama iki aydan çok daha uzun süredir buradaymışım gibi geliyor olumlu anlamda.
Ben de teşekkür ediyorum arkadaşlarıma da bu sebeple.
Süper. Vallahi harika.
Gizem sen de hoş geldin ekibe.
İki ay yani şeydeki gibi Interstellar'daki gibi aslında Trendyol'da geçen iki ay.
Herhangi bir yerde geçen bir sene gibi aslında düşünebiliriz.
Tekrar hoş geldiniz.
Tekrar hoş geldiniz arkadaşlar.
Süper. Aslında baktığımız zaman ekipteki diversity'yi, ekipteki işte çeşitliliği de buradan görebiliyoruz.
Biraz şeyden bahsedelim isterseniz.
Bu ekibin başlangıcından.
Observability Experience diyoruz.
Observability yine zor söylenen ekip isimlerinden biri.
Observability Experience takımının kurulma hikayesi nedir arkadaşlar?
Ekim'in tren yoldaki sorumluluğu nelerdir?
Ben de Observability takımında değilken bir iş arkadaşımız tarafından şirketken yapılmış bir ihtiyaç anketi vardı.
İşte liderlere, teknik liderlere falan sorular.
Overall ne ihtiyaçlar var gibi.
Daha çok platform odaklı.
Bu anketin sonucunda da in-house bir monitoring tool'u en yüksek önceliğe sahip proje olmuştu.
Yani biliyorsunuz bizimki gibi büyük ve kompleks sistemlerde var olan third party platform ve tool'lar, işte bunlar Nivrelik olur, Sentry olur, Datadock olur.
Tam anlamıyla çözüm sunmuyorlar, sunamıyorlar.
Çünkü onlar zaten global müşteriye hizmet ediyorlar.
Bizim gibi büyük ve işte kompleks sistemlerde de senin böyle çok küçük, böyle kendine özel yapılmış çözümlere ihtiyacın oluyor.
Bunlar ne kadar çok fazla jenerik olabiliyorlar.
O zaman bazı özelleşmen gereken yerlerde özelleşemiyorsun gibi.
Hem de bizim scale'de maliyet aşırı yüksek oluyor.
Bunun gibi bir sürü sebep üzerine bir RFC çalışması başlattık.
İlk aşamasını ben yazmıştım işte.
Sonra RFC'yi sınırladık.
Bu RFC süreçlerinden falan bahsetmişlerdir.
Belki böyle bir soru gelirse ileride ondan da bahsedebiliriz.
Ondan sonra bu RFC'nin üzerine proje monitörlükten obzaveti evrildi.
Önümüzde de kullandığımız third party tool'ların yeni anlaşmaları için sadece aylar vardı.
Bu anlaşmadan önce de biz end-to-end, ZG Client tarafından başladık ve mobil olmak üzere.
Observatory platformumuza geliştirmek için yola koyulduk diyebiliriz.
Hem takımların migration'ı, hem platform, SDK'ler, insanların on-board olması, mobile SDK, yani bütün bu süreci geçtirmeye aslında start verdik.
Çok zorlu bir süreçti. Mobil taraftan, mobil platform ekibinden destek aldık.
Orayı bizim yönlendirmemizde orada da epey sofistike bir SDK geliştirildi.
Ve bu işin sonunda aslında biz 200-210 farklı projenin kullandığı bir platform yapmayı başardık diyebiliriz.
Ve işte bunun üzerine de böyle bir takım kurulma ihtiyacı duyuldu.
Yani Trendyol'da önce iş ondan sonra takım onun üzerine kuruluyor gibi belki düşünülebilir.
Ekibin sorumluluğu da hem bu projenin hem içeride RG sürecinde olduğu için hani şu an burada bahsedemeyeceğimiz birkaç tane daha proje var.
Onların kullandığımız infrastrukturun, veri tabanlarının onlardan da bahsedeceğiz birazdan.
Ve OZOBIT SDK'lerinin hem servis hem de client application'larını tamamı için düşünülebilir.
Maintain edilmesi ve geliştirilmesi diyebiliriz.
Burada aslında doğru hatırladığım kadarıyla yani doğru hatırlıyorsam Böyle biraz daha client tarafındaki monitoring şey yapılarak yani kullandığımız işte nevrelik tarafından çıkalım ve işte
client monitoring için bir tool yapalım falan diye bir fikir ortaya koyulmuştu değil mi?
Doğru hatırlıyorum. Evet evet orada birazcık low hanging fruit muhabbeti var ya oydu.
Yani client ile özel olarak birazcık daha kördük ilk olarak.
İşte kullandığımız third party tool'lar burada bahsetmekte bilmiyorum base var mı hem sentry kullanıyorduk nevrelik kullanıyorduk tren yolu geneli için konuşuyorum.
Neuralink browser'da ve mobilde aslında adam akıllı insightler sunmuyordu.
Bunun örnekleri de Sentry falan vardı.
Oradaki RFC çalışmaların içerisinde şey de vardı.
Overall biz client'ı içeri alsak ne kadar para ödeyeceğiz gibi.
O da bayağı yüksek rakamlardı.
Sonra biz dedik ki o zaman biz önce bir client'ı aradan çıkaralım ve bakalım ne kadar cost şey yapıyoruz aslında save ediyoruz.
gibi böyle bir süreçte. Onun matematiğini de önden bir yapmıştık.
Sonra full focus client'a giriştik.
Yani doğru hatırlıyorsun. Süper.
Süper abi. Yani aslında bence bir ayısı yok.
Yani burada bu tool'lardan bahsedebiliriz.
Birçok bence şirketin benzer dertleri var burada.
Çünkü bu tarz tool'lar evet belli oranda bir şey sağlıyor.
Belli oranda bir fayda sağlıyor ama doğal olarak ucuz şeyler değil, enstrümanlar değil.
Yani böyle gerçekten ciddi ücretler hele ki işte bizim bu şeyimizde, scale'ımızda şirketler için ciddi büyük meblalar karşılığında aslında biz bu şeyleri kullanabiliyoruz, uygulamaları.
Hele ki yani Nivreli'nin ve Sentry'nin namını bilenler bilir özellikle Sentry'nin.
Dolayısıyla yani içeride inbound bir şekilde, internal bir şekilde bu tarz bir tool yapma fikri bence de çok iyi ortaya çıktı.
Ve çok iyi de başarılı zaten tool ile alakalı.
Fazlaca da konuşacağız süreçte.
Şimdiden ellerinize sağlık diyeyim.
Süper. Peki ekiple alakalı birazcık bahsedelim.
Ekip dağılımı nasıl sizde?
Observability Experience ekibinde kaç developer var?
Bu ben devralayım burada.
Ekipte şu an dedike çalışan 5 developerız.
Bir tane tek leadimiz var.
Beholder tarafına ve bizim Beholder Experience tarafına ortak bakan.
Şimdi buradaki ekiplerin ayrımından da tabii bence birazcık bahsetmek lazım.
Biz aslında Beholder çatısı altında çalışan iki ayrı ekibiz.
Bir tanesi Observability Platform, öbürü de Observability Experience.
Biz şu an Observability Experience ekibiyle beraber buradayız.
Observability Platform aslında bütün Observability Platform'unun işte data collectorları olsun, arka tarafındaki infrası olsun, ingestion tarafı olsun ve benzeri servisleri sunan aslında platform ekibi.
Observability Experience da burada bu...
toplanan arka taraftaki metriklerin ve verilerin biraz daha ürünleştirilip kullanıcı tarafından daha kolay bir şekilde gözlemlenebilir hale gelmesini hedefliyor.
Observability Experience tarafında dediğim gibi 5 developerız.
Bir tane tek leadimiz var platform tarafına ve bize aynı zamanda ilgilenen.
Bir de gizem var. Aslında 6 kişilik bir ekibiz diyebilirim o yüzden.
Çok iyi. Çok iyi.
Aslında yani baktığımız zaman genel olarak baktığımız ekiplere göre bir tık küçük bir ekip gibi duruyor ama yani Yeni olan bir ekip ve yeni büyüyen bir domenik.
Dolayısıyla bence gayet yeterli sayıda olduğunu düşünebiliriz.
Süper. Peki ekip yapısından bahsettik.
Biraz da çalışma prensipleriniz üzerine konuşalım isterseniz.
Nasıl çalışıyorsunuz?
Sprint mi koşuyorsunuz?
Sprint koşuyorsanız daily sprintlerinizi nasıl ilerletiyorsunuz?
Burada nasıl bir süreciniz var?
Buna ben cevap verebilirim ekibin product manager olarak diyeyim.
Aslında şöyle ilerliyoruz biraz.
Hepimizden gelen spor taleplerinden, kullanıcı geri bildirimlerinden aldığımız yönlendirmelerimiz oluyor.
Ve bunların doğrultusunda konularımız özelinde önceliklendirmelerimizi yaparak haftalık sprintlerde çalışıyoruz.
Bir haftalık sprint koşmuş oluyoruz ekipçe.
Yeni sprintimiz her çarşamba başlıyor.
Öncesinde ise salı günleri ekipçe grooming toplantısı yapıyoruz.
Eğer elimizde yeni ve büyük bir konu varsa buradaki hislerleri netleştirmek için ayrıca toplandığımız farklı grooming toplantılarımız da oluyor proje ya da konu özelinde.
Beraber karar verebilmek için nasıl ilerleyeceğimizi belirlemek ve UI dizaynının nasıl olacağını beraber konuşmak, backend tarafının nasıl olacağını beraber konuşmak için bir araya gelip kararlar verdiğimiz toplantılar.
Ama her salı muhakkak düzenli bir grooming toplantımız oluyor.
Grooming toplantılarımızda da o hafta özelinde neye odaklanacağız, buna birlikte karar veriyoruz.
Bazen yeni tasklar çıkarıyoruz, bazen de backlogdaki mevcut tasklarımızdan ilerleyip puanlamalarımızı yapıyoruz tasklar bazında.
Tüm süresince de daily'lerde işlerimiz nasıl gidiyor, karşılaştığımız bir engel var mı, birbirimizin yardımcı olabileceği bir konu var mı, destek olabileceğimiz bir yer var mı?
Her sabah değillerimizde bunlar üzerinden gidip sprintimizi çarşamba günü kapatmaya çalışıyoruz.
Sprint sonunda da yeni sprinte başlamadan önce ekip içinde mini bir review yapıyoruz.
İşte bu sprint neler yaptık, hangilerini tamamlayabildik, taahhüt ettiğimiz tasklar tamamlandı mı, bir sonraki sprintin konusu olarak devam edecek, devam task açmamız gereken bir konu var mı?
Bunları bir konuşuyoruz beraber.
Sonrasında da zaten...
Her ay aynı şekilde Tribe bazında da bir sprint review toplantımız oluyor.
Burada da bu sprintlerde ekiple beraber neleri yaptık, hangi işlerimizi tamamladık bunları paylaşmış oluyoruz.
Bir de önemli olan, kritik olan konularımızdan biri aslında roadmap oluşturmak, OKR'larımızı belirlemek.
Burada da ben iki aydır buradayım ama Haziran'da bu Q3 planlamasına yetişmiş oldum.
Burada da işte üç ayda bir yaptığımız OKR review ve planlama toplantımız var.
demiştim. Q3 planlamayı da kısa süre önce yaptık.
Eylül gibi de Q4 hazırlıklarına başlayacağız.
Burada quarter bazlı planlamalar bence çok değerli.
Hem daha kısa vadeli neler yaparız, planımız değişmişse ya da önceliklendireceğimiz farklı bir konu varsa aslında onları beraber yine değerlendirmiş oluyoruz.
Bir de zaten ben de hala paralelde bir yandan da öğrenme aşamasında olduğum için de bu bir araya gelmeler benim için de çok faydalı oluyor.
Burada zaten ekiple beraber her şeyi yaptığımız için Gerçek bir takım çalışması çıkarıyoruz ortaya diyebilirim.
İki aylık gözlemlerime göre.
Vallahi ağzını salgılayacağım gerçekten.
Baya tek nefeste tüm süreci anlatmış oldu yani.
Ben şeyi merak ettim ya.
Hiç bir ekipten çarşamba başlayan ve biten sprint duymamıştım açıkçası.
Yani klasik şeydir ya pazartesi başlanır.
İşte pazartesi cuma biter.
İşte pazartesi tekrar başlanır falan.
Yani burada çarşambayı seçmenizdeki neden nedir tam olarak onu merak ettim.
Yine zaten aynı sprint düzenini ilerletiyorsun ama neden çarşamba?
Aslında burada hafta ortası başlamak bize yani benim düşünceme göre biraz o hani pazartesi sendromu konusunda bizi de biraz hafifletiyor diye düşünüyorum.
Salı gününe kadar bir vaktimiz var çarşambadan salı gününe kadar.
Bütün haftanın her günü sanki bizim için aynı seviyedeymiş gibi hissettiriyor.
O yüzden haftanın ortasında bu planı yapıp başlayınca pazartesi salı gelen farklı bir durum var mı?
işte ekiplerin başlattığı diğer süreçlerden bize dokunacak bir kısım var mı?
Aslında groomingde de bunu da ele alma şansımız oluyor diye düşünüyorum.
Ben gelmeden önce de bu şekildeymiş, bu şekilde ilerlemiş.
Bir hani aksayan bir kısım yok ya da farklı bir görüş olmadığı için şu an için böyle devam ettiriyoruz.
Ama ileride hani daha iyi olur diye farklı bir gün özelinde yine sprint başlatmayı düşünürsek yine bu da da ekiple beraber retrolarımızla karar veririz diye düşünüyorum.
Anladım. Yine ilginç diye düşünüyorum çünkü Pazartesi sendromu biraz daha pazartesiye yönelik bir şey değil gibime geliyor.
Yani bu durumda sizin çarşamba sendromu...
Çarşamba sendromu benim için bu arada.
Haftalık sprint ben de ilk kez bu düzende çalışıyorum.
Daha önce böyle iki haftalık en az periyotlarla sprint koştuğum olmuştu.
Bunun iyi yanı var.
Kötü yanı da yani şu an kötü demek doğru mudur bilmiyorum ama sürekli bir gerçekten hani takip, task çıkarma, taskları yetiştirme.
planlama yapma konusu var.
Bir de kendi özelimde hem platform ekibi hem de experience ekibi observability olarak her iki ekibin de hem sprint, işte groomingleri planlamaları derken benim için çarşamba sendromu olmuş oluyor.
Ama pazartesi, salı günü işte önümüzü görebilmek açısından iyi olduğunu düşünüyorum ben yine.
Hafta başından gelen bir konu var mı ya da işte groomingde bizim daha çok dikkat etmemiz gereken bir konu var mı?
Pazartesi günü aslında böyle bir insight elde etmiş oluyoruz.
Peki Gizem sana Senin için kritik bir soru sormak istiyorum.
Observability platform ekibini mi daha çok seviyorsun yoksa observability experience ekibini mi?
Hadi bakalım. Bir anne baba sorusuymuş gibi yaklaşık.
İkisini de çok seviyorum demek isterim.
Çünkü benim için aslında ayrımı yok.
Sadece toplantılarımız farklı gibi.
Slack kanalında da bir şey olduğunda hep beraber oturup konuşuyoruz.
Herhangi bir konuyu...
platform tarafına netleştirip işte client tarafına aktarmak için yine bir araya gelip beraber halletmiş oluyoruz.
Bu mimaride her ikisi de çok değerli ekibim.
Her iki ekibime de selamlarımı iletiyorum.
Peki. Platform ekibine buradan şey doğdu, cevap doğdu.
Onları da bir sonraki selam ekip bölümünde bekliyoruz diyelim ve bağlayalım.
Okey süper. Şimdi sizin ekipte aslında bu şey ekiplerinde, ürün ekiplerinde çok fazla bizim bu tarz soruları soruyoruz.
Özellikle servis ekiplerinde ve ürün ekiplerinde şöyle bir aslında durum var.
Çok fazla ekiple çalışma gibi bir durum var.
Çünkü sizin yaptığınız ürünü Levent de bahsetti.
Çok fazla ekip kullanıyor.
Neredeyse ben işte şeye girdiğim zaman, Mergen'in sayfasına girdiğim zaman, Mergen'in sayfasına girdiğim zaman çok fazla proje görüyorum ve bir o kadar da göremediğim şey vardır muhtemelen.
Dolayısıyla Birçok ekiple birlikte çalışıyorsunuz.
Bu ekiplerle böyle iletişim ve ortak çalışma zor olmuyor mu?
Bu süreci nasıl yürütüyorsunuz?
Nasıl sağlıklı bir şekilde akıyor bu süreç?
Ben cevap vereyim buna.
Açıkçası çok zor bir iş.
Hem de deadline'lar bu kadar sıkıyken, teknik challenge'lar bu kadar sağlamken çok zor bir iş.
İhtiyaçlar takımdan takıma epey değişebiliyor.
Bütün bu sebeplerden ötürü de etkiye bir iletişim kurmak gerekiyor aslında.
Ve buradaki en büyük avantaj da bu ihtiyaçları.
Hani bu takımlardaki işte bizim çünkü müşterimiz developer ya burada.
Sonuçta biz de işte projeler yaptık.
Bunların takip edilmesi, observable olabilmesi gibi işte dertlerimiz vardı.
Observable denilmiyorsa bile o zaman.
App proje hakkında, sağlığı hakkında, reliability hakkında falan fikir elde etmeye ihtiyacımız falan oluyordu yani.
Bunları da daha önce hissetmiş olduğumuz için aslında orada birazcık daha avantajlıyız.
En büyük hata da işte burada aslında şey oluyor.
Müşteri de developer olduğu için yine aynı sebepten.
Müşteri bir problem gördüğü zaman ona çözüm önerisiyle birlikte geliyor.
Hatta bazen problemden bahsetmiyor da.
Mesela işte biz şu an history falan tutuyoruz.
E işte seni bir hataya lead eden akış tamam mı?
E bu akışa baktığı zaman aslında amacımız hani Sentry kullananlar bilir breadcrumb gibi düşünebilirsiniz.
Şöyle bir talep gelebiliyor.
Ya breadcrumb isteseyiniz 50 örnek veriyorum.
Bunu 100'e çıkarsanız ya history gibi.
Şimdi bunu direkt alıp yüze çıkarıp hayatınıza devam edebilirsiniz.
Yani bu çok böyle basit bir örnek ama projenin bütün detayında böyle şeyler düşünebilirsiniz.
Böyle yaparsanız zamanla işte mevzu birazcık daha işin içinden çıkılamaz hale geliyor.
Çünkü müşteri de developer ve zaten bir çözüm önerisi sunuyor.
Burada aslında biz şunu yapıyoruz.
Biz soru soruyoruz. Bunun sebebi nedir?
İşte bunun sebebi örnek veriyorum.
X, Y, Z asetlerimin işte şeylerini de burada görmek istiyorum.
Benim için kritik. Bu durumda siz diyorsunuz ki tamam, istorya aynı kalsın ama burada işte smart bir yola gidebilir miyiz?
Çünkü şöyle düşünelim, 200 küsur tane proje, yani Trendyol'daki neredeyse bütün mobil ve web clientlerinden bahsediyoruz.
Bunların her birinin attığı logdan bahsediyoruz, yani exceptionlardan bahsediyoruz.
Onların her birinin gönderdiği metriklerden bahsediyoruz.
Sadece 50'yi 100 yapmak bile aslında bizim için daha fazla scaling problemi falan demek olabiliyor.
Böyle şeyler yaparak aslında hem iletişimi iyi tutarak hem problemi anlayarak ve ona olabilecek en smart çözümü bulmaya çalışarak bunu yürütmeye çalışıyoruz diyebilirim.
Gizem sen ne düşünüyorsun?
Ben buraya geldiğimde Slack ilk kez kullandığım bir tool oldu.
Bu anlamda bence Slack gerçekten çok iletişimi nasıl desem...
Teşvik eden mail yerine Slack ile iletişim kurmak benim çalışmam açısından ya da insanlarla tanışmak ve iletişim kurmam açısından çok işime yaradı.
Mail kullanmıyor olmak burada gerçekten çok güzel çünkü hızlı ilerlettiğimiz süreçler var, projelerimiz var.
Burada sürekli Slack üzerinden haberleşmek bence çok güzel.
Sağlıklı bir durum, sağlıklı bir araç Slack.
Burada ortak kanallarımız var zaten Slack üzerinden yine bütün ekiplerle ya da proje üzerinde açtığımız channel'larımız var.
Oradan toplantı notlarımızın aksiyonları olsun, hangi aşamada ya da hangi taskımızda, hangi durumda kaldık, asing haberleşmek gibi ihtiyaçlarımız olsun.
Hepsini bu kanallar üzerinden yürütüyoruz.
Bir de... Bazı projeler, yani büyük yürüttüğümüz projeler üzerinde sync toplantılarımız oluyor yine aynı şekilde ekiplerle.
Burada da hani hem teknik ihtiyaçları alıp tekrardan dinleyip kullanıcı beklentilerini de yakından takip edebiliyoruz.
Zaten hani işimiz gereği kullanıcılardan aldığımız geri bildirimler doğrultusunda da planımızı revize etme gibi durumlarımız olabiliyor.
önceliğimiz yine kullanıcılarımız olduğu için.
Burada da bu sync toplantılarında da yine kullanıcılarla birebir iletişimde kalmış oluyoruz.
Aynı zamanda Slack üzerinde yine hem public channelımız hem QA kanalımız, channelımız var.
Aynı zamanda Pandora üzerinden de yine QA kanalımız bulunmakta.
Orada zaten haftalık on-call kişimiz oradan gelen support requestlerini hızlı bir şekilde karşılıyor.
Aynı zamanda daha geniş kapsamlarıyla alınacak bir konu olursa da yine ekiple o grup toplantılarımızda ya da warm toplantılarında bunları karşılıyoruz.
Bir de aslında şeyden bahsetmek istiyorum.
Şu an kişi listemizi tekrardan oluşturuyoruz.
Platform ve Experience ekiplerinin...
hitap ettiği kullanıcılar farklı olduğu için son zamanlarda incubating toplantılarımızın katılımcıları azaldı.
Hatta bazen katılım yetersizliğinden dolayı toplantıyı yapamıyoruz.
Burada da incubating listemizi bir başta oluşturma sürecimiz var.
Sonrasında yine aylık olarak incubating toplantılarımızı yapıp kullanıcılara orada da erişmek, yaptıklarımızdan bahsetmek, geri bildirimlerini almak istiyoruz.
Proje bazında yaptığımız user interview'lar var.
Onlardan da bahsedebilirim kısaca ama Mert senin eklemek istediğin farklı bir şey varsa ben kendi notlarımdan hızlıca bir şeyler söylemek istemiştim.
Benim şu an eklemek istediğim bir şey yok.
Sen tam QA'dan bahsedecektin.
Sen R'ye girdin. Güzel oldu.
Benim ekleyeceğim başka bir şey yok.
Sonraki soruya geçebiliriz bence. Belki şey konuşabiliriz.
Neden bu kadar zor isimler seçiyorsunuz ya?
Neyse anladı. O toplantıdan bahsedelim isterseniz.
Bilmeyenler olabilir. Incubating toplantısında neler konuşuluyor?
Ne amaçlanarak bu toplantı ortaya çıktı?
Aslında bu biraz Sprint Review'a benzer ama Sprint Review'dan farklı olarak daha henüz canlıya almadığımız işleri yaptığımız, işte biz bu işleri bu uygulama üzerinde planlıyoruz.
Şu featureleri konumlandırmayı düşünüyoruz.
Sizin fikriniz nedir gibi. Kullanıcılarımızdan bunu yapsak iyi olur mu gibi geri dönüş almak istediğimiz toplantılar oluyor bu.
Ben henüz yapamadım. Dediğim gibi katılımcı sayısı sebebiyle toplantılarımız hep iptal oldu.
Ama hani orada bir araya gelip ekiplerle...
Yapacaklarımızdan bahsetmek ve henüz daha bu iş için efor harcamamışken onların yorumları doğrultusunda şekillendirebiliyorsak önümüzü görebilmek açısından yolun başındayken durumu şekillendirmek için
aslında onlarla paylaşım yapmak istediğimiz bir toplantı.
Levent'in belki eklemek istediği bir şey vardır.
Sözü ona da vereyim. Sağ ol Gizem.
Evet bu ilk dediğimiz konuda da yani normalde bir ürün geliştirirken bizim üstümüz developer ya bu...
Aslında normal developer olmasa da önemli oluyor.
Bir ürünü geliştirirken biz müşteriden aslında o ürünün özellikleri hakkında önden bir fikir alıyoruz.
Neye ihtiyaç var?
Ne yapılmak isteniyor?
Siz ne düşünüyorsunuz?
Sizin neye ihtiyacınız var?
Tekrar revalide etmek gibi oluyor.
Orada da aslında şunu biliyorsunuz.
Bir şey yapıyorum. Bunu yaptığım zaman o incubation takımının seçilmesi falan da önemli.
Nasıl seçildiği de önemli. Diyorsunuz ki bu takımların yaptığımız şey bir ihtiyacı oluyor.
Bunu sürekli valide etmek gerekiyor.
Zaten bir ürünün başarılı olması için direkt müşteriden bildirim alman gerekiyor ya.
Ne yaparsan yap. Bunda da aslında platform projelerinde de başarılı olmak için direkt müşteriyle konuşup dediğim gibi o hatalara düşmeden müşterinin söylediği şeyi direkt yapmadan
aslında. Hani oradaki...
orada daha akıllı olup daha akıllı çözümler bulmaya çalışarak arkadaki asıl sebebi bulmaya çalışarak ilerlemek diyebilirim.
Süper. Valla burada yaklaşımınız bence gayet güzel.
Özellikle bir ürün teknoloji üzerine çalıştığınız için bu konu daha da önem kazanıyor diyebilirim.
Burada peki bu ürünleri geliştirirken, ürünü geliştirirken hangi teknolojileri kullanıyorsunuz?
Tekstiliniz nasıl burada? Bu soruyu ben devralayım.
Şimdi aslında Observability domeninde çok fazla tool var.
Open source olsun, closed source olsun, commercial olsun.
Biz bu noktada Trendyoski elinde bir şirkette hem high available olabileceğimiz, down olmayacağımız bir yapı kurmaya çalıştık.
Çünkü eğer siz observability tarafında down olursanız aslında bir noktada kör oluyorsunuz.
Çünkü uygulamalarınızın nasıl hizmet verdiğini ya da verip vermediğini takip edemiyorsunuz.
Ve bu da direkt olarak aslında business impact'e yol açıyor negatif şekilde.
O yüzden biz burada Observatory Domain'de en böyle aktif geliştirmesi olan ve bazı şeylerde standartları getirmiş olan OpenTelemetry tarafında çok sırtımızı dayamış durumdayız.
Hem log collection olsun, metric collection olsun, span collection olsun.
Bütün aslında clientlardan topladığımız bilgilerin tamamı OpenTelemetry kolektörleri üzerinden bize akıyor.
Bizim tabi bu noktada arka tarafta dataları store ettiğimiz kısım var oradan da bahsedeceğim.
Ama oraya geçmeden önce Mergen tarafında...
İlk başta client taraflarına yani client domenilerine geliştirdiğimiz SDK'lar var.
Bu SDK'lar hem mobile application'lar için olabilir ya da web client'lar için olabilir.
Farklı farklı framework'lar için böyle çok sofistike şekilde geliştirilmiş SDK'lar.
Çünkü siz bir SDK yayınladığınız zaman eğer çalışan ipin içinde bir şeyleri bloklarsanız hem geliştiren ekibin bunu görmesi çok zor hem de aslında yine business impact'e ulaşmış oluyorsunuz.
içeride ne olduğunu görelim derken bir anda ipi patlatabilirsiniz.
O yüzden orada böyle bayağı sofistike yazdığımız SDK'lar var.
Bu SDK'lar üzerinden fırlatılan bütün imantlar bizim OpenTelemetry Collector'larımıza düşüyor.
OpenTelemetry Collector'ları üzerinden de aslında arka tarafta bir Kafka queue'umuz var.
Bu Kafka queue'su üzerinden bizim bu verileri topladığımız veri tabanı diyebileceğimiz servisleri akıyor.
Bu veri tabanı servisleri de aslında şu an iki tane Sık kullandığımız, yani sırtımızı yasladığımız iki tane veri tabanı teknolojisi var.
Bir tanesi Prometheus.
Yani direkt olarak Prometheus kullanmıyoruz aslında.
Victorometrics kullanıyoruz. Bu bir time series database.
Aslında genel olarak metrikleri tutup bunları hızlı bir şekilde kölebilmek için kullandığımız bir servis.
Bunun haricindeki her şey için de Clickhouse kullanıyoruz şu an.
Clickhouse da aslında takribi yeni bir teknoloji.
Analitik database olarak çıkmış open source bir proje.
Clickhouse'un performansından bayağı memnunuz aslında.
Ama tabi bunu ben size rakam vermeden anlatamam çünkü teknoloji dünyasında biliyorsunuz rakam vermediğiniz zaman aslında sadece bu fantezisine tool'ları alıp kullanmışsınız gibi oluyor.
Birazcık rakam vermeye çalışayım ben size o yüzden.
Şimdi öncelikle Mergen'i aktif olarak kullanan 144 tane client projesi var.
İşte bunların içinde web projeleri var, mobil projeler var, farklı farklı framework'lar var.
Bu 144 projenin Clickhouse tarafına akan işte loglar, issue'lar ve error'lar olarak...
Bir saniye. Dashboard geride kalmış.
210 tane projemiz var şu an içeride aktif olarak Mergen'i kullanan.
Bizim Clickhouse tarafında 7 günlük bir data retention'ımız var.
Bu data retention'ın total olarak...
Bize çevirdiği veri aslında 1.8 TB gibi bir şeye denk geliyor.
Ki buradan şunu yorumlayabilirsiniz.
İşte aslında buradaki veriler konsola basılmış böyle minik minik loglar.
Ve hani bunun üzerinden biz 1.8 TB'lik bir veriyle çalışıyoruz.
Click House tarafı böyle.
Open Telemetry Collector'larına ne kadar yük geliyor ondan bahsetmeye çalışayım birazcık.
Şimdi burada 3 ana konu var.
Bir konu loglar, bir konu metrikler, öbür konu da spanler.
Spanler aslında... Tracer olarak düşünebilirsiniz.
Spenlerde anlık şu an 400 milyon civarı bir throughput alıyoruz.
Metric tarafında 250 milyon gibi.
Log tarafında da 6 milyon.
Bunlar dakikalık.
İşte bunların oluşturduğu roll sayısını da 3 aşağı 5 yukarı tahmin edebilirsiniz diye düşünüyorum.
Scale'imiz bu şekilde.
Burası aslında bizim platformu oluşturduğumuz kısım.
Hani bunun Victoria Matrix...
tarafı platform ekibinde, observability platform ekibinde.
Kalan bütün yapıyı biz observability experience olarak kendimiz götürüyoruz aslında.
Bir de bunun tabii application tarafı var.
Application tarafında da şöyle bir yapı kullanıyoruz.
Bir tane client'ımız var, React'la yazılmış.
Mergen Web diye bahsettiğimiz.
İşte girip aslında ürünün product kısmı.
Bunun arka tarafında bir tane go back end'imiz var.
Aslında işte filtreleme ve data okuma işleri için kullandığımız.
Bu arkadaki datasorçları entegre bir şekilde çalışıp aslında kullanıcının deneyimini iyileştirmeye çalışıyor.
Tek isteğimiz bu şekilde.
Eğer cevaplamamı istediğin bir soru varsa cevaplamaya çalışalım.
Bir de şeyden de bahsedebiliriz belki.
Bizim client SDK'inden.
Hem web hem mobil için geçtirdiğimiz bu iki SDK aslında.
Biz ilk projeye başladığımız zaman dünyada pek bir örneği yoktu.
Honeycomb tarafında vardı. Biraz önce Yusuf Mert de söyledi.
Hotel Collector tarafından.
Yani OpenTelemetry Native. veri üretmek burada aslında ana amaç.
Hem trace için hem metric için hem de log için.
Pek bir örneği yoktu.
Grafana'nın geliştirdiği bir tool vardı.
Sanırım Grafana'nın Faro olması lazım.
O SDK'yi birazcık incelemiştik.
O da aslında sırtını işte tamamen trace'e ve log'a dayamış.
Bütün işi şeye yükleyen direkt servis tarafına yükleyen bir yapısı vardı.
Ben orada herhalde şu an dünyada olan en sofistike SDK'leri geliştirdiğimizi düşünüyorum.
Özellikle web tarafı için.
Burada da çok fazla challenge'lar var.
Biraz önce Yusuf Mert'in bahsettiği işte external OTP üzerinden, external pipeline'lar üzerinden akan verilerin miktarına bakınca bu verilerin aslında hem kendimizi scale etmeye çalışıyoruz backend
tarafında, infrastructure tarafında hem de client tarafında scale edilebilir veri göndermeye çalışıyoruz gibi bayağı orada learning'lerimiz var.
İnşallah önümüzdeki süreçte bununla alakalı makaleler yazmayı da planlıyoruz.
Teşekkür ederim. Süper.
Süper. Burada aslında bayağı sofistike ilerliyor yapı gibi görüyorum.
Zaten tahmin ediyordum bu arada OpenTelemetry, Prometheus falan gibi konular kullanıldığını.
Çünkü sonuçta günün sonunda metriklerden, trace'lerden, log'lardan falan bahsediyoruz.
Dolayısıyla aslında open source vesaire kullanılan da bu tarz teknolojiler var.
SDK olayını da bilmiyordum açıkçası.
Gayet iyiymiş, ellerinize sağlık.
Yani çok sağlam, güzel bir yapı kurulmuş burada diyebiliriz.
Süper. Şimdi biraz daha şeyden konuşalım istiyorum.
Gizem daha yeni katıldığını, iki ay olduğunu falan söylemişti.
Sizin ekipte yeni biri katıldığında onboarding süreci nasıl oluyor, nasıl ilerliyor?
Buna çok taze bir yerden cevap verebilirim diye ben başlayayım isterseniz.
Daha sonrasında developer onboarding'i nasıl oluyor diye arkadaşlarım devam eder.
Ben hayatımda ilk kez açıkçası bu kadar net bir plana sahip bir şekilde onboard edildim.
Daha önce yaklaşık on küsur senedir çalışıyorum.
Her zaman böyle denize at, yüzmeyi öğren şeklinde bir süreçle karşılaşmıştım.
O şekilde bir onboarding'im olmuştu ya da onboarding midir bilmiyorum.
O şekilde başlamıştım her seferinde işe.
Ama Trento'da ilk başladığımda beni en çok etkileyen şey gerçekten onboarding süreci oldu.
Burada da süreç gerçekten planlı ve sahiplenilmişti.
Buradan tekrardan Hakan'a, Body My Cell'e ve Observability Platform Experience ekibine de tekrardan teşekkür ediyorum.
Çünkü iki aydır burada olmama rağmen daha uzun süredir buradaymışım gibi hissetme sebebim bence gayet iyi planlanmış bir onboarding sürecim.
olması ve bu şekilde işe başlamamdı.
Herkes gerçekten ilk günden beri ne zaman ne sorsam çok hızlı şekilde dönüşler alabileceğim şekilde yardımcı olma amacıyla yaklaştı bana.
İlk iki hafta boyunca planımızın üzerinden gittik.
Vadim Aysel'le beraber ekip toplantılarına katıldım.
Birebir seçimlerimizde ekibin stratejisi, roadmap ve OKR dokümanları üzerinde beraber çalıştık.
Burada zaten ekip yapısını, projeleri, diğer ekiplerle iletişimimizi, hedefleri anlamam için bu süreç benim için gayet iyi oldu.
Üçüncü haftam itibariyle de rutin sprint toplantılarını artık ben lider etmeye başlamıştım.
Burada da artık tamamdır bu işten de denildiği zamanda onboarding sürecimizi tamamladık.
Ama şu anda hala ne zaman ihtiyacım olursa hem bodyme yazabiliyorum, hem takım liderimiz, hem staffımız, hem arkadaşlarımız gerçekten her konuda destek oluyorlar.
Burada... Beraber yaptığımız o ürünleri tanıma anlamında birebir toplantılarımız da oldu.
Bunlar da benim için çok faydalı oldu.
Açıkçası gerçekten 10.
yılımın sonunda diyeyim iş hayatında ilk kez gerçek anlamda onboarding edilerek bir işe başlamış oldum.
Çok fark ediyormuş. Bunu da tekrardan belirtebilirim.
Şimdi topu ben devralayım o zaman.
Çünkü gizemden sonra son onboard olan bendim ekibe.
Birazcık da bu işin developer perspektifini anlatmaya çalışayım.
Yaklaşık bir yıl, iki aylıkken falan Beholder ekibine geçtim.
Öncesinde ama yine Developer Productivity Engineering ekiblerinden birinde çalışıyordum aslında.
O yüzden çalışma stilini ve geliştiren ürünlere hakimdi.
Domain'i birazcık biliyordum ama Observability benim için yepyeni bir domain'di.
Çünkü networking ya da Kubernetes üzerinde bir tool ya da bir ürün geliştirmekle Observability tarafında bir ürün geliştirmek çok farklı tecrübeler.
Ekibe ilk geldiğimde aslında benim...
Tecrübem gizeme göre birazcık daha farklı ve ben bunu birazcık şey veriyorum aslında rollerden alakalı, rollerimizle alakalı olduğunu düşünüyorum.
Bendeki tecrübe biraz daha şeydi işte anne kuş, küçük kuşu böyle şeyden atar, ağaçtan atar ve o kuşun uçmayı öğrenebilmesi için o havadayken kendine öğrenmesi gerekir.
Benim de tecrübem ona benziyordu birazcık.
İlk geldiğimde backend projesinde bir refactoring yapılması gerekiyordu.
İşte onu tek başıma devraldım.
Onu birazcık yürüttüm. Oradaki süreçte de aslında şey öğrenmiş oldum işte ekip ne yapıyor aslında, bizim ana görevlerimiz neler, bu product'ın içindeki yapmaya çalıştığım şeyler neler gibi konuları öğrenmeye çalışmıştım.
Yani aslında birazcık tecrübe şeye benziyor işte sizin developer olarak böyle çok alışılmadık bir domene giriş yaptığınız zaman hem pratikleri öğrenmeniz lazım.
Best pratikleri öğrenmeniz lazım.
Çünkü hata yapma ihtimaliniz çok yüksek eğer bir şeylerin nasıl yapıldığını okuyup öğrenmiyorsanız.
Hem de bizim burada çözmeye çalıştığımız problem ne?
Onu çok iyi öğrenmek gerekiyor.
Çünkü bir domain ekibinde aslında kullanıcının yaşadığı tecrübeyi iyileştirmek olabilir çözdüğünüz problem.
Ya da ona yeni bir tecrübe katmak olabilir.
Onun yapabileceği yeni bir şeyi çözmek olabilir.
Ama bizim taraftaki requirementlar biraz daha şey aslında.
Observability tarafında kullandığınız platformların down olmaması lazım.
Reliable olmanız lazım.
Servis verdiğiniz, hizmet verdiğiniz servislerden daha reliable olmanız lazım.
Çünkü onların down olduğu senaryoda siz ayakta olacaksınız ki down olduklarının farkına varsınlar.
Bu tarz konularda aslında birazcık tabii kendi kendime böyle birazcık kazarak öğrenmem gerekiyordu.
Ama bu bizim mesleğin getirdiği bir şey tabii.
Hani dinleyiciler de bence bunu birazcık takdir ederler.
Benim de onboarding tecrübem bu şekildeydi aslında.
Ama ekip hani şey böyle...
Direkt kucak açıp beni aralarına aldılar.
Hani o konuda kesinlikle bir şikayetim yok.
Sadece teknik tarafta böyle birazcık şeydi.
Stresli geçti diyebilirim birkaç hafta.
Evet, evet Yusuf. Son yaklaşık iki dakikadır şikayetin olmadığını hepimiz anladık abi.
Ne çok onboarding sığdırmışsın içine diyerek yorum yapmak istiyorum.
Levent abi atlıyor şu an bakalım.
Birazcık bir konuya yakalım.
Hak veriyorum bu arada.
Bizde çok yoğun süreçlerimiz olduğu için şey gibi oldu da biliyorsun zaten.
Hepimiz böyle çok yoğun bir şekilde bir şeyler yapmaya çalışıyoruz.
Katılıyorum yani. Trendyol'da genelde bu developer, benim onboardinglerimle çok benzer oluşuyor.
Geriye dönüp baktığım zaman şey oluyoruz.
Böyle tamam abi böyle bir şey yapacağız falan.
Yusuf Mert'e de bayağı kallavi bir iş vermiştik.
Ondan sonra da onun orada onu yapmasını izleyerek.
Kenarda biz de normal işimize devam etmiştik falan.
Biz de o şekilde ilerliyor.
Komple bir ekibiz.
İnsan geldiği zaman ilk günden itibaren tamam artık bu ekibin parçasıyız.
Birlikte şunu yapıyoruz şeklinde ilerlediğimiz süreçler oluyor diyebiliriz.
Gayet de güzel aktı Yusuf Mert.
Teşekkür ediyoruz. Mert senin var mı yorumun?
Benim de bir yorumum var.
Burada aslında Merton'un öğrenme isteğiyle bizi...
Elimizi bayağı rahatlattı.
Bir tık böyle şikayet etmiş gibi oldu ama yani o kadar hızlı öğrendik her şeyi.
Direkt olarak bir projeyi emanet edebileceğimizin hissiyatını bize çok net bir şekilde verdiğine inanıyorum Mert'in.
Hani o konuda da bizim elimizi bayağı rahatlattı.
Hızlı bir onboarding süreciyle güzel bir başlangıç yaptık Mert'le de.
Yani developer tarafındaki onboardingimiz yani şöyle diyebilirim.
Mert aslında bizim developer tarafında onboard ettiğimiz ilk kişiydi ve ilk ve tek kişi diyebilirim.
Ve bu işi de çok hızlı bir şekilde yaptık.
O şekilde diyebilirim.
Dostlar çok teşekkür ediyorum.
Şimdi burada şöyle bir konu da var zaten.
Codebase iyi olunca, doküman iyi olunca istekliysen zaten oluyor bazı şeyler.
O yüzden ekibin hakkını yemeyeyim yani o konuda.
Teşekkür ediyorum. İyi ki varsınız.
Çok sağ olun. Evet.
Yani buraya yorum yapmak istemiyorum.
Direkt olarak diğer soruya geçeceğim.
Çok teşekkür ederim cevaplarınız için.
Okey şimdi peki. Sizin tarafa yeni projeler geldiği zaman, yeni bir iş geldiği zaman ya da böyle herhangi bir durumda refaktör ihtiyacı da olduğu zaman nasıl ilerliyorsunuz?
Ben burada ufak bir araya girmek istiyorum.
Yeni adam onboard ediyoruz abi replatforming ihtiyacımız olduğunda.
Aslında az önceki onboarding sorusuna paralel olaraktan...
Gerçekten hem işi tanımak hem ekibi hem de konuları tanımak için direkt bir projeyle başlamak ya da projeleri faktör etmek bence çok değerli ve önemli.
Şu an benim de burada bir şansım var.
Şu an Q3-Q4'te hedeflediğimiz bir Nivrelik ürününden tamamen çıkmak ve ürünümüz olan Mergen'i tüm şirket...
bazında observability açısından kullanılan tek ürün yapma hedefimiz var.
Mevcutta client uygulamaları, web ve mobil uygulamalarını Mergen üzerinde zaten konumlandırdık.
Bu kişiler, kullanıcılarımız ihtiyaçlarını Mergen üzerinden karşılayabilir durumdalar.
Yine tabii geliştirmelere devam ediyoruz.
Eksikleri gördükçe devam ediyoruz bir şeyler yapmak için.
Şu an amacımız APM kısmında, backend uygulamaları kısmında yine mergene taşıyarak Nivreleak'tan tamamen tüm ekiplerin çıkmasını sağlamak.
Bu da bizim için aslında hem yeni bir proje diyeyim, çok kritik önümüzde olan konulardan biri.
Burada da şu an yaptığımız şey aslında benchmark.
Hem nivrelikte neler var, biz mergene neleri konumlandırabiliriz.
Bu şekilde nivrelik ve benzeri ürünlerden yaptığımız benchmarklar var.
Bu benchmarklar sonucu aldığımız, gördüğümüz eksiklikleri mergende uyumlandırabilir miyiz, konumlandırabilir miyiz diye.
Yine az önce aslında neredeyse her soruda bahsettiğim o, ekiple birleşip yaptığımız büyük toplantılarımız var, kurumlarımız var.
Burada kendimize ve kendi ürünümüze uygun şekilde neyi koyabiliriz, neyi katabiliriz, bunları üzerine.
daha çok konuşuyoruz. Burada diğer yaptığımız şey nivreliği şu an için nivrelik üzerine örnek veriyorum bu kritik bir proje diye.
Burada amacımız aslında diğer bu ürünü en çok kullanan kişilerle de görüşüp konuşup onların ihtiyaçlarını anlamak ve mergende onların ihtiyaçlarına uygun neler ekleyebiliriz ilk aşamada bunları tespit
etmek. Burada da gerçekten demek istediğim şey aslında kullanıcıdan ilgili feedback'i ve bilgiyi alıp gerekli benchmark'ı da yapıp ürüne üründe konumlandırmaya çalışmak.
Bunu yaparken de yine ekiple beraber çalışıp uygun şekilde kendi teknolojilerimize de UI UX dizaynımıza da uygun şekilde bu featureleri konumlandırmaya çalışmak.
Önemli olan tekrar uygulamak istediğim kısım ihtiyacı anlamak.
Daha sonra da gerisi halloluyor diye düşünüyorum.
Burada eklemek istediğim farklı bir kısım yok.
Ama mevcut çalışma düzenimize de zaten uyan bütün projelerde ya da işte bütün konularda aslında ilerlediğimiz şekilde bu proje için de bu şekilde ilerletiyoruz diyebilirim.
Sözü Levent'e verebilirim.
Topu Levent'e atabilirim.
Ben de biraz teknik tarafından belki bahsedebilirim.
Aslında burada süreç şu oluyor.
Bizim işte hem onboarding süreçlerimiz hem işte var olan durum statüsümüzü takip edebilmek için çok iyi bir dokumentasyon aslında yazmamız gerekiyor.
Biz de onu yapıyoruz. Böyle süreçlerde, replatformik süreçlerinde aslında bunlar zaten bu sürecin bir başı var.
Evet böyle bir şey veya yeni bir proje geldi.
Bunun sebeplerinden aslında bizim zaten önceden haberimiz olmuş oluyor.
Bu iş birazcık aslında kolektif ilerleyen bir iş oluyor.
O yönden çok iyi. Ürün tamamen bize ait, bütün takım olarak.
Business requirementları da olsun, her şey olsun.
Bu bir platform projesi olduğu için aslında overall karar verebiliyoruz neler olacağına dair.
Ondan sonra da genelde ADR'lar yazıyoruz veya işte bununla alakalı teknik toplantılar yapıyoruz.
Yapacağımız işi nasıl yaparız?
Bu işi yaptığımız zaman nasıl sonuçlar ummalıyız?
İşte bu sonuçlara gidebiliyor muyuz böyle yaparak gibi.
Bütün süreci end-to-end aslında ele alıyoruz.
Ondan sonra da aslında nasıl yapacağımıza dair bir karar vermiş oluyoruz.
Bu kararı da kaydediyoruz. O ADR dediğimiz akışlar öyle oluyor.
Sonradan gelen bir kişi de gelip okuduğu zaman aslında...
Fikir sahibi olabiliyor direkt diyebiliriz.
Ben böyle söyleyebilirim.
Ekip olarak kendimize de epey güveniyoruz.
Şu son zamanlarda yaptığımız başarılara bakarak özgüveni bayağı yüksek bir ekibiz.
Ondan ötürü de bunu bayağı büyük bir özgüvenle, bayağı büyük bir zevkle yapıyoruz.
Yeni projeler geldiği zaman hatta keyfimiz yerine geliyor diyebilirim.
Çok güzel, çok güzel.
Gerçekten buradaki yaklaşımınız harika.
Ağzınıza sağlık, çok teşekkür ederim.
Bir sonraki soruya... Geçeyim.
Hafiften de vaktimizin sonuna doğru geliyoruz.
Son iki sorumuz var. Şimdi tabii birazcık bu soru aslında şeye hit ediyor.
Watch the watcher muhabbeti.
Yani işte gözleyenleri kim gözlüyor?
Bir observability ekibine monitoringle alakalı bir soru sormamız gerekiyor.
Ama tabii yani sonuçta bir ürün var ortada.
Yani diğer ekiplerin monitoringini...
Yönetseniz de sizin de aslında sizin tarafta bir monitoring sistemleriniz de olması gerekiyor ürününüzü gözleyebilmek için.
Burada monitoring ve alert mekanizmanız nasıl bir incident olduğu durumda nasıl önceden haberdar oluyorsunuz?
Bir de sonunda böyle güzel bir incident örneğiniz varsa onu da rica edebilirim.
Bu soruya ben cevap verebilirim.
Aslında yani dediğim gibi who watches the watcher?
Kısmında terzi kendi söküğünü dikiyor.
Biz de aslında kendi ürünlerimiz için kendi yaptığımız ozoril titullarını kullanıyoruz.
Bunların hepsinin tabii ki de aletleri kurulu.
Onun dışında biz mergen olarak da yani mergen projesinde client-side takip ettiğimiz için client-side uygulamaları takip ettiğimiz için mergenin client-side tarafını da mergen ile takip ediyoruz aslında.
Burada bir incident örneği olarak da yani aklıma çok bir şey gelmedi.
Yani bizim tarafta Allah'a şükür Büyük bir incident yaşamadık.
Hani o konuda çok bir şey diyemeyeceğim ama dediğim gibi bütün tool'larımızı yine kendi yaptığımız monitoring infrasıyla takip ediyoruz.
Ve bütün hepsinden yani bütün aletlerden nasıl desem on-call sistemleriyle vesaire her şeyi takip ediyoruz.
Kullandığımız işte database'lerde aletler tanımlı.
Open telemetry instance'larının aletleri tanımlı.
Burada herhangi bir veri yakışı.
azaldığı anda biz direkt zaten on call sistemimiz bizi arıyor yani o an on call olan kişiyi arıyor ve durumdan haberdar oluyoruz diyebilirim.
Ben de burada topu Levent abiye bırakayım.
Genel olarak artı bir diyorum Merdo ile.
Bu arada alerting de bizim yine uzay ödül platform takımının altyapısını sunduğu bir şey.
Ya şöyle globalde overall bütün data centerlerde elektrik falan kesilmediği sürece bizim kendimizden haberdar oluyoruz aslında.
Multi platform yapılarımız var diyebiliriz.
Orada da daha aslında nasıl ileriye gidebiliriz falan onları düşünüyorum.
Burada da aslında sürekli şeylerimizi takip ediyoruz.
Bunlar KPI'lerimizden arasında.
Uptime'larımız hem functional hem non-functional requirement'larımızı takip ediyoruz.
Bu non-functional requirement'lar arasında da bunlar da var.
Ve bunlar aslında bizim KPI'miz yani.
İşte biz ürünü böyle geliştiriyoruz, öyle yapıyoruz'un dışında böyle aslında hedeflerimiz de var.
Orada da 4.9'a falan 3.9'a ulaştık diye hatırlıyorum.
4-9'a doğru gidiyoruz diye söyleyebilirim.
Onun dışında da incident örneğini Cengiz sen hatırlarsın bir tane vardı.
Ondan da acaba bahsetsek mi bilmiyorum teknik bir şeyler ama yani Mergen'in web SDK'nin dıdısının dıdısıyla işte GTM'in çakışmasına sebep
olan Adblocker'ın X versiyonunun falan filan.
Biliyorsun orada çok büyük bir müşteriye aslında zarar vermediğimizi hatırlıyorum.
P4 mark edilmişti.
Ama bu böyle bir incidentımız var.
Onun dışında var mı bir incident?
Hatırladığım kadarıyla bir incidentımız yok yani.
Maşallah nazar boncuğu.
Evet burada nazar boncuğu önemli.
Süper valla yani. Daha gerçi inşallah ileriki zamanlarda da olmaz.
Daha yeni bir takım sonuçta.
Hani şu ana kadar olmamış şimdiden sonra da olmaz muhtemelen.
O incident da evet gerçekten yani Merge'nin içerisinde overwrite edilen bir şeyin GTM'de çakışması ve adblocker içerisinden de çakışıp işte aslında yani senin de dediğin gibi çok
fazla kullanıcıya hit etmedi ama ben de çok net hatırlıyorum çünkü ben nöbetçiydim o gün.
Akşam yaklaşık biz iki buçuk saat.
Mehmet Can'la birlikte eski takımdan arkadaşım.
Böyle acaba nedir problem falan diye.
Hiç de bu arada şey yapmadık yani.
Mergene hani ya bu konu mergenle alakalıdır falan demedik.
Acaba nerede hata yaptık falan diye böyle düşünürken.
Ya acaba başka bir şeyden olabilir mi falan diye.
Lokal ortamda mergeni bir devre dışı bıraktık.
Mergenden dolayıymış.
Ama tabii ki her bölümde söylüyoruz yani.
Bu tarz şeyler herkesin başına gelebilir.
Önemli olan bundan ne?
şey yaptığımız, ne çıkardığımız durumu.
Bu arada efsane bir nokta yapar bakmazsın.
Biz Mergen'de aslında bütün süreçlerimiz var.
Kaos testlerine kadar yapıyoruz yani.
Antoin testlerimiz var.
Smoke testlerimiz var.
Yani unit testlerimiz var.
Zaten onu saymaya gerek yok.
Bütün bu testleri yapıyoruz.
Hatta browser bazlı bir support egzerlerimiz falan da var ama bazı problemler hakikaten şey olabiliyor.
Bu ilk başta dediğim konu gibi.
Bir ürün geliştiriliyor ama burada çok sofistike işler yapılıyor.
Yani Trendyol web sayfasına girip evet bir web sayfası girdin ve işte orada bannerlar var tıkladın, ürün gördün falan gibi düşünülüyor olabilir dışarıdan.
Belki hani çok deneyimli olmayan arkadaşlar böyle düşünüyordur.
Öyle dinleyenler falan da olacaktır.
Ama aslında orada gördüğünüz her bir parça için aslında epey sofistike işler yapılıyor.
Böyle olunca da ki mergen gibi bir web estikeyi yazabilmeniz için bütün browser, native akışları peslemeniz lazım.
Böyle de olunca bir yandan...
Hani yapılan geliştirme gidip işte x1 işte extension olabilir adblocker bunlardan biri.
Onunla çakışıp işte gtm etkiliyor falan filan gibi böyle takip etmesi zor problemlere sebebiyet verebiliyor.
Burada işte mergenin avantajı da internal bir tool.
Bir şekilde evet abi böyle bir şey varmış deyip birlikte geliştirip.
Hani bir sorun varsa hemen o sorunu çözüp yeni versiyonu çıkabiliyoruz.
Ya da işte bazı fallback mekanizmaları var.
Hatta yine sizin ekiplerle Cengiz görüşeceğimiz öyle şeylerle baya trend yola işte bize faydalı olabilecek şekilde ürünler geliştiriyoruz diyebilirim.
Aynen aynen.
Ellerinize sağlık şimdiden.
Çok güzel bir yaklaşım.
Vaktimizin de sonuna geldik.
Son bir soru ile ufaktan kapatalım.
Her aksına ekibe sorduğumuz klasik soru.
Ekip iletişimi geliştirmek için neler yapıyorsunuz?
Burada tabii işte önceki ekiplerimizden nargileci ekiplerimiz var.
Araba sevdası olan ekiplerimiz var.
İşte paintball'a giden ekiplerimiz var.
Yeme konusunu zaten söylemiyoruz.
Tüm trend yolu genelinde oldukça sevilen bir durum.
Sizin ekipte ekip iletişimi geliştirmek için neler yapıyorsunuz?
Burada ben cevaplayayım bu soruyu.
Aslında ben bu soruyu cevaplarken hem Observer Elite platform hem de Observer Elite Experience ekibi için ortak cevap vereceğim.
Biz aslında çok sportif bir ekibiz.
Geçen yazdan itibaren her hafta salı ya da perşembe günleri o gün hangi gün müsaitsek İdealtepe sahilinde basketbol oynuyoruz müsait
oldukça. Daha sonra ofise döndükten sonra da genel olarak...
Sarıyer Demet'in Oktay Spor testlerinde kapalı salonda basketbol oynamaya devam ediyoruz.
En büyük eğlencemiz aslında basketbol diyebilirim.
Gerçekten sportif bir ekibiz ama bunun dışında her cuma günü yaptığımız da bir event var oyun saati.
Ondan da bahsetmesi için ben topumu erte bırakayım.
Şimdi platform tarafıyla beraber bizim de her cuma akşam yani mesai sonunda bir saatlik takvimlerde şey var.
Beholder oyun saati diye bir blogumuz var.
Orada bazen Secret Hitler oynuyoruz, bazen Mario Kart oynuyoruz.
Böyle bir ekip içinde insanların birbirini nasıl kandırmaya çalıştığını görmek falan çok keyifli oluyor.
Özellikle Secret Hitler oynarken.
Bu şekilde aslında böyle team bonding olarak uzaktan çalıştığımız için tabii bir noktada zor oluyor ama tabii şeyler de var.
İşte Slack'ta kullandığımız GoGoi kanalları da var.
Hani hem teknoloji tarafında fikirle alakalı olsun hem de böyle genel gündem olur, başka konular olur.
İşte Opney'in yeni modeli çıkıyor.
Mesela onunla alakalı bile böyle bir tane thread açılıp böyle tıkır tıkır konuşuluyor hani arka tarafta.
Developer olunca tabii böyle birazcık inek denilebilecek konularla ilgileniyor insanlar ister istemez.
Bu şekilde aslında. Ben de sözü geri bırakayım.
Güzel, güzel valla yani basketbol konusu çok iyiymiş.
Ankara'da da bir şey var, bir ekip var.
Her hafta voleybola giden bir ekip var.
Valla darısı tüm ekiplerimizin başına diyelim.
Çünkü meslek dolayısıyla çok da hareket etmeyen şeyiz, insanlarız.
Dolayısıyla basketbol çok olmuş.
iyi olmuş yani daha doğrusu çok olmuş derken tebrik ediyorum burada.
Süper. Arkadaşlar çok teşekkür ederim.
Vallahi dolu dolu bir bölümdü.
Bayağı da bir şey konuştuk zaten.
İyi ki geldiniz. Tekrar teşekkür ederim.
Biz teşekkür ederiz.
Biz çok teşekkür ederiz.
Teşekkür ederiz. Çok güzel bir bölüm.
Çok keyifliyiz. Süper.
Çok teşekkürler arkadaşlar.
Selam ekibin 83. bölümünde Obsorbility ekibiyle, Obsorbility Experience ekibiyle beraberdik.
Bir sonraki bölümde farklı bir ekiple tekrar görüşmek üzere.
Bay bay.
Bu transkript otomatik olarak çıkarıldı; kayıtla küçük farklar olabilir.