Transkript
Merhaba herkese.
Bugün Selam Akip Podcast'ın yeni bölümünde konuğumuz Developer Experience ekibinden Gamze ve Emre.
Gamze ve Emre hoş geldiniz.
Hoş bulduk. Hoş bulduk.
Öncelikle geldiğiniz için teşekkürler.
Biraz kısaca hem Gamze hem Emre kendinizden bahsedebilir misiniz bize?
Tabii. Ben kısaca kendimden bahsedeyim.
Gamze Şentürk. Beş yıldır Trendyol'da çalışıyorum.
Bundan önce iki farklı domain ekibinde bulunduk.
Bir buçuk yıldır da Developer Experience Pandora ekibindeyim.
Kısaca kendimden bu şekilde bahsedebilirim.
Ben de Emre Savcı. Gamze ile aynı dönemde işe başlamışız.
Yani beş yıl oluyor benim de.
Dördüncü domain ekibim.
Sanırım Trendyol'daki. Daha önce istedim.
Delivery, Trendle Express, Marketplace gibi ekiplerle çalıştım.
Şimdi Developer Experience'siyim.
Kısaca böyle. Teşekkürler.
Hoş geldiniz diyeyim ben de tekrardan.
Biraz böyle çalıştığınız domayından bahsedebilir misiniz?
Şu anki çalıştığınız domayın nedir?
Hangi problemi çözmeye odaklanıyor?
Bu konuları biraz değinebilirseniz süper olur.
Tamamdır. Ben Pandora ekibi ne yapıyor ondan bahsedeyim.
Biz Spotify'ın open source projesi olan Backstage'i kullanarak internal bir teknoloji portalı geliştiriyoruz aslında.
Bu portalın ortaya çıkış hikayesini anlatayım.
Bir yolda teknoloji ekibi olarak sayımız artmaya başladığında özellikle remote dönemde belli baş sorunlar ortaya çıktı.
Mesela ekiple arası iletişim, servislerin bağımlılıkları neler, bu projeyi geliştiren developerlar kimler, servisin, projenin ya da takımın dökümanları nerede gibi.
Bunlarla birlikte yeni gelen arkadaşların oryantasyonu, Devex ekibinin geliştirdiği toolların tanıtılması ve doküment edilmesi gibi sorunlarımız vardı.
Bu sorunları çözüm ararken Spotify'ın da aynı sorunları çözüm olarak geliştirdiği backstage'i görmüş olduk.
Belli bir komünitesi, güzel bir dokumentasyonu ve open source olması sebebiyle biz de Trendyol'da kullanmaya karar verdik.
Bu şekilde domeninden bahsedebilirim.
Bizim amacımız günün sonunda içerideki teknolojide çalışan arkadaşlarımızın deneyimini geliştirmek, güzel bir deneyim sunmak diyebilirim.
Biz de Tevekskor olarak...
Aslında genel vizyonumuz şu, bir sürü ekip var Trendyol'da.
Yaklaşık 1600 teknoloji çalışanı var.
60-70 tane ekip var ayrı ayrı.
Tüm bu ekiplerin geliştirdiği microservicelerin runtime ihtiyaçlarını karşılayan uygulamalar lazım.
Şimdi böyle söyleyince çok anlaşılmıyor genelde.
E yani ne yapıyorsunuz gibi bir soru geliyor peşimde.
O da şu aslında, bir microservicenin runtime ihtiyaçları nelerdir?
Mesela önceden crosscutting layer diye bir şey vardı kod seviyesinde proje.
İçerisinde böyle genel ihtiyaçları projenin cross-cutting diye geçerdi.
Nedir bunlar? Caching mesela, authorization, config management, logging vs.
Biz bu tarz gereksinimleri uygulama kodu olarak değil de proses olarak ele almaya başladık.
Ve Kubernetes'de çalıştığımız için her bir prosesi bir sidecar olarak ele alıp ekiplere sidecarlar vermeye başladık.
Mesela X ekibinin 50 farklı ekip var dedik.
Diyelim ki her 10 tane de farklı programlama değil olsun.
Bu ekiplerden herhangi birisinin bir checking ihtiyacı olduğunda, ya gidip biz bunlara şey demeyelim, ya siz 10 farklı program modeliyle aynı sorunu çözen kodu baştan yazın demeyelim de, biz bunu tek elden çözelim, bir proje haline getirelim,
bu projeyi sidecar haline getirelim, ekiplerin Kubernetes'de çalışan proseslerinin yanına bir proje olarak koyalım dedik.
Genel olarak bunu yapıyoruz, bu tarz ihtiyaçları çözüyoruz.
Peki bu developer experience ekiplerinde sadece development'a yönelik işler mi oluyor?
Aslında ekip içinde developer, test mühendisi, bir PM'iniz mesela oluyor mu?
Tam olarak konumlanmanız nasıl?
Ekip yapımızdan bahsedeyim ben Pandora ekibinin.
Bir product manager'ımız, bir developer in-test, bir UX designer ve 10 developer'dan olmak üzere 13 kişiden oluşuyor.
Bizim front-end developer ve back-end developer gibi bir ayrımız yok.
Hepimiz full stack çalışıyoruz aslında.
Cross-functional bir takımız bunun sonu.
hepimiz iki tarafta da geliştirme yapıyoruz.
Kendi gelişimimiz için ve Noha'nın sadece bizim de olmaması adına da çoğunlukla peer olarak ilerliyoruz.
Bu şekilde bahsedebilirim. Aynı şekilde bizim ekipte de bir cross functionality söz konusu.
Ama tabii biz Pandora gibi UI yazan bir ekip değiliz.
UI tarafımız tamamen Pandora aslında.
Ama bizim de bir adet product manager bulunuyor.
Hatta aynı product manager'a sahibiz Pandora'yla.
Deveks'in product manager'ı.
Tester dedin bize.
Test nasıl ya? Testi delikanlı bir development ekibi product'ında yapmıyor.
Ayrı bir testçimiz yok açıkçası.
Biz doğrudan testleri de kendimiz geliştiriyoruz.
Cross-functionalist de şöyle bir şey.
DevOps süreçlerimizle kendimiz idame ettiriyoruz.
İşte development'ı da backend'i de işte Gamze'nin dediği gibi frontend tarafından.
Ekipteki herhangi biri hayatta kalacak kadar yapabilir seviyede.
Gerekirse birisi CI pipeline'larını yazar, birisi işte otomasyon testini yazar, birisi integration testini yazar.
Yani herkes bunları yapabilecek kabiliyette.
Genel olarak ekip yapısı bu şekilde.
Güzelmiş ya aslında. Baktığın zaman her ekipte ben her zaman bir test mühendisinin işte bu konuda uzman birinin olması.
olması gerektiğini savunan biriyim.
Ama aynı zamanda da aslında ekipteki her üyenin her bir uzmanlık altında belli başlı şeyleri yapabilir halde olmasını aslında savunuyorum bir yanda.
Bu yüzden bence anlattığın şekil benim hoşuma gitti açıkçası.
Yani bir işte developer olarak CRCD pipeline'lerini kuruyor olmanız, işte gerekli testleri yazıyor olmanız bence gayet güzel bir şeymiş.
Tebrik ederim. Teşekkürler.
Ben mesela Trendyol'a yeni başladım ve işte Developer Experience'deki ...tribünde çalışmaya başlayacağım.
Beni neler bekliyor bu ekipte?
Ben nasıl onboard olacağım?
Biraz bu konulara değinir misiniz?
Seni neler bekliyor? Aslında bizim bir onboarding...
...prosesimiz var. Çıkarttığımız belirli maddeler var.
Yeni başlayan bir arkadaşı onboard etme sürecinde neler uyguluyoruz?
Yeni başlayan bir arkadaşa bir tane body atıyoruz ekipten.
Belirli bir süre boyunca o arkadaşın bütün ihtiyaçlarını, mesela x bir sorusu var, o soruyu kime göndermeli, muhatabı kim olacak?
Belirli trend yolun internal tool'ları var kullanmak.
Ticket aç mıdır, şudur, budur, talepleri vs.
Ekipleri tanıtması gerekiyor.
Sonuçta şu ekiple çalışıyoruz, sistem ekipleri, DevOps ekipleri, domain ekipleri vs.
Bir de bunun dışında içerideki DevEx ekibinin tool'larının tanıtılması.
gerekiyor. Yani bizim hizmetlerimiz neler?
Neleri kullanıyoruz? Trendle geneline neleri yaydık?
Hangi ekiplerle entegreyiz?
Hangi teknolojileri nasıl kullanıyoruz?
Bütün bunları anlattığımız süreçlerimiz var.
Genelde ekipte belirli projelerde işte en başından beri olan farklı farklı kişiler bulunuyor.
Bu onboarding sürecinde yeni başlayan bir arkadaşım.
Bu projelerde uzun süredir bir arada olan veya projeye hakim olan başka bir arkadaşla toplantılarla bir araya getiriyoruz.
Belirli atıyorum bir aylık bir sürece yayıyoruz bunu.
Ekiple sürekli toplantılar yapıp proje aktarımlarını yapıyoruz.
Bir yandan da bizde tabii peer kültürü var, birlikte çalışma kültürü.
Bütün yaptığımız işlere, girdiğimiz toplantılara bu arkadaşı gözlemci olarak, peer olarak yanımıza alıyoruz.
Genel olarak bu şekilde bir süreç işliyor zaten.
Hızlıca şey, coding süreçlerine dahil ediyoruz yeni başlayan bir arkadaşım.
Biz de direkt kastlara girmeye başlıyoruz.
İK tarafındaki vesaire oryantasyonları da bittikten sonra.
Öyle bir süreç diyebilirim.
Bu işleri geliştirirken kullandığınız teknolojilerden biraz bahseder misiniz?
Pandora'nın front-end tarafını React, back-end tarafını ise Node.js ve Go ile geliştiriyoruz.
Database olarak PostgreSQL ve Elasticsearch, Monitoring Tool olarak New Relic, Loglarımızı takip etmek için Kibana Tool'unu, CLCD süreçlerimiz için ise GitLab ve ArgoCD'yi kullanıyoruz.
Projelerimizi de kırayt edip Kubernetes üzerinde host ediyoruz.
Bu teknolojileri seçerken dikkat ettiğimiz konular oluyor.
DevEx Core tarafında da ana teknolojimiz Golang diyebiliriz.
Gol diliyle yapıyoruz hemen hemen tüm geliştirmelerimizi.
Peki neden gol diliyle yapıyoruz?
Şimdi biz DevEx ekibi olarak çeşitli extensibility...
kabiliyetlerimiz var. Örneğin Trendle'da Kubernetes kullanılıyor, Istio kullanılıyor, ContainerD arka planda kullanılıyor vs.
Bu tool'ların yazıldığı dil Go dili.
Doğrudan bu tool'ların Go diline native client'ları var, SDK'leri var.
Projenin kendisi o dille geliştirildiği için Go'nun package yapısı olsun, projenin kendi geliştirdiği client olsun, biz doğrudan Go dilini kullanarak çok rahat bir şekilde bu tool'lara extensibility katabiliyoruz kendi tarafımızda.
Veya işte client paketlerini kullanarak kendi ihtiyaçlarımıza göre...
özel projeler çıkartabiliyoruz.
Bu birinci sebebi. Bir ikili sebeplik Go'nun çok düşük resource kullanımı Sidecar geliştirmek için mükemmel oturuyor.
Yani Sidecar dediğimiz şeyin çok yüksek memori kullanmaması gerekiyor.
Hızlıca ayağa kalkabiliyor olması gerekiyor.
Startup time'ın hızlı olması gerekiyor vesaire.
Go müthiş bir şekilde bu ihtiyaçlara fitreden bir dil oluyor bizim için.
Genel olarak Go'yu kullanıyoruz o yüzden biz de.
Onun dışında ama teknoloji olarak neler var?
Dil olarak Go var. Fakat işte mesela biz Distributed Tracing altyapısı geliştiriyoruz.
Java'ya, .NET'e, Node.js'e SDK sağlamamız gerekiyor.
bunlarla da ufak paketlerimizi yazıp veriyoruz dışarıya veya bir authorization library'si yazıyoruz.
Bunu JavaScript teknolojileriyle geliştirip sağlıyoruz.
Diğer teknolojilerde dediğim gibi infrastructure, container, orchestration olarak Kubernetes kullanıyoruz.
Trendyol'da Service Mesh kullanılıyor.
Istio Service Mesh kullanılıyor.
DevEx ekibi de bunun yaygınlaştırmasını yapıp işte çeşitli extensibility feature'larını kullanan, çeşitli kendi istiyonun verdiği özellikleri kullanıp bazı şeyleri abstract edip domain ekiplerine hizmet olarak verdiğimiz yerler oluyor.
Başka burada şeyleri kullanıyoruz.
Mesela Distributed Tracing'de Trace Storage olarak Jaeger gibi bir tracing tool'unu kullanıyoruz.
Genel olarak aslında CNCF ürünlerinin çoğunu kullanıyoruz diyebilirim.
Mesela RGCD'yi kullanıyoruz.
deploymentlarımızı yönetebilmek.
Veya çeşitli popüler CLI araçları var.
Atıyorum Customize. Kubernetes'de deployment yaparken bazı fonksiyonel şeyler sağlayan bir tool.
Bunları kullanıyoruz. CLCF'de görebileceğiniz birçok ürünü bir şekilde bizim POC'lerimizden veya kullanım senaryolarımızdan geçiyorum.
Kapatarsak bu minimalle ürünlerle çalışıyoruz.
Şimdi genel olarak aslında baktığımız zaman sizin müşteriniz içerideki domain ekipleri oluyor.
Dolayısıyla bir iş yapacağınız zaman nasıl karar veriyorsunuz?
Yani direkt olarak sizi drive eden böyle bir business ekibi de yok.
Burada neyi yapacağınıza ya da işte atıyorum bir yıl sonra işte...
Pandora nereye gidecek ya da şimdi DevX tarafında neler yapacaksınız?
Bunlara nasıl karar veriyorsunuz?
Şöyle bahsedeyim ben Pandora tarafından.
Genelde önümüzde bir roadmap var.
Yani product manager'ımız olduğu için önümüzde neler yapacağımıza dair feature'lar var.
Özellikle Developer Experience Tool'larını tanıtmak adına.
Onun dışında düzenli olarak feedback alıyoruz.
Hangi geliştirmeyi görmek isteyeceklerizle ilgili.
Ve ona göre de priority belirliyoruz bu işlerde.
Ve çok acil çıkması gerekiyorsa ve çok gerekliyse ekipler için kullanımı daha fazla olacaksa ilk başta onu alıp onu geliştirip o iş çıkıyor aslında.
Akış bu şekilde. Ama belli bir roadmap var.
Nereye gitmek istediğimiz belli günün sonunda.
Ama arada priority yüksek bir iş geldiğinde ekiplerin daha çok kullanacağı işler.
Geldiğinde değiştiriyoruz tabii ki.
DevEx tarafında ise bir tık daha şöyle ilerliyor işler.
Uzun bir süre boyunca Developer Experience ekibindekiler ne yapması gerektiğini kendisi analiz etti.
Yani domenik tiplerimizin ne ihtiyacı var?
Bu ihtiyacı analiz etme sürecinde tetikleyen gelişmeler oldu.
Mesela işte bundan bir iki yıl önce Trendle'un multi-DC mimarisine geçiş.
kararı. İşte orada ne çıkıyor devreye?
Multi-cluster çalışabilme kabiliyeti çıkıyor.
İşte orada cross-cluster servis discovery gibi gereksinimler çıkıyor.
Mesela bu cross-cluster servis discovery'de performans kaygıları devreye giriyor.
Örneğin işte araya load balansı olmasında servisler doğrudan birbiriyle haberleşebilsin gibi bir düşünce atılıyor ortaya.
Ve biz bu noktada bunu nasıl yaparız diye düşünüp geliştirme yapmaya başlıyoruz.
Burada işte cross-cluster servis discovery yapmayı sağlayan gene güvenliğin fonksiyoneliteleriyle ve bizim üzerine yazdığımız kast.
Şimdi bu da başka bir şeyi tetikledi.
Aradan load balansırları çıkarttık.
Load balansırları çıkartınca load balansırın...
fonksiyonalitesini kullanan ekipler bu fonksiyonalitetten mahrum kaldı.
E bundan mahrum kaldı ne dedik?
E biz böyle bir servis sağladık, böyle bir hizmet sağladık ama başka bir feature'ı yok ettik.
O zaman bunu yerin dolduracak bir şey sağlamalıyız dedik ve caching problemi çıktı devreye.
Bu probleme bir çözüm ürettik.
İşte orada site cache diye makalesi vesaire de var.
Hatta GitHub'da eski bir versiyonu, GitHub'da da duruyor projenin.
SiteCache diye SiteGar üzerinde caching kabiliyeti sağlayan bir proje yaptık.
İyileştirme noktalarını, gördüğümüz herhangi bir iyileştirme noktası, Trendur'da çalışan bir yazılımcının hayat kalitesini arttırabilecek, development kalitesini arttırabilecek herhangi bir şeyi not ediyoruz, değerlendiriyoruz.
Değerlendirme sonucuna göre de roadmap'imizi ekliyoruz diyebilirim.
Bayıldım mı uzun cevabımdan?
Teşekkürler. Bayağı güzel bilgiler verdin.
Dinleyenler için özellikle bayağı faydalı olduğunu düşünüyorum.
Hazır bu konuya girmişken bir de bu kararları aldınız.
Neler yapacağınıza karar verdiniz.
Peki deployment süreçleriniz nasıl oluyor?
Özellikle birçok ekibi direkt olarak etkileyen tool'lar yazdığınız için burada ne tür önlemler alıyorsunuz ya da ne tür yöntemler uyguluyorsunuz?
Önlem olarak bir kere mutlaka yaradana sığınıp deploy basma durumu biraz oluyor.
Çünkü şöyle düşün abi, site cache mesela, trend yolun milyonlarca cache verisini o yazdığımız kod partisi üzerinden akıtıyoruz kullanıcılara.
Şimdi buradaki en ufak bir yanlış deployment, yüzlerce clusterdaki binlerce kodunu uygulamanın yanlış veri dönmesine kadar gidebilecek bir şey.
Yani çalışmaması gerek toleri edilebilir bir şey.
Hiç çalışmaz, bütün yük arka plana biner.
Bu okey. Ama yanlış çalışma ihtimali de var ya sonuçta, bütün datanın karışabilmesi gibi.
Bir tık böyle şeyler tedirgin edici olabiliyor veya sinks.
Bütün network oradan dönüyor.
Yani tek bir kesinti trend olun net öykünü kesmeye kadar gidebilir.
Biraz tabii bu noktada kaygılarımız yüksek oluyor diplomat yaparken ve çok kademeli bir diplomat yapmaya çalışıyoruz.
Örneğin bizim işte DevOps ekibiyle de paylaya çalışıyoruz.
Daha önceden büyük bir platform ekibi vardı.
Orada implement edilmiş bir diplomat süreci var.
Common release'leri, böyle bütün altyapıya çıkacak release'leri çıktığımız tek bir yer var.
Bir kere entegrasyon testlerimiz, unit testlerimiz, işte gerekli...
Bütün harici bağımlılıkları test edildiği senaryolarımızı yapıyoruz.
Bunları otomatize halde yapıyoruz.
Bu süreçlerden geçtikten sonra DevOps ekibiyle anlaşmalı bir şekilde, eseri ekipleriyle anlaşmalı bir şekilde şunu söylüyoruz.
Şu geliştirmemizin şu şu şu klastırlara çıkması lazım.
Öncelikle stage ortamlarına tüm trend yolun genelinde yaygınlaştırma yapılıyor.
Burada bir süre izleniyor.
Herhangi bir hata olmadığı durumda bir sonraki hafta production klastırlarına aynı yaygınlaştırma yapılıyor.
Bazen de... Tamamına değil de production clusterlarında ekip ekip kademeli bir şekilde çıkış yapıyoruz.
Öncelikle mesela daha az kritik bir servisin olduğu ekibe çıkıyoruz.
Orada da hata yoksa tüm geneli yaygınlaştırıyoruz.
Tabi burada şey kaygıları var.
Yani yazdığım tool ile versiyon geliyor.
Bu tool'u bütün ekipler kullanıyor.
Yeni bir versiyon çıktığında backyard compatibility'i bozmuyor olman gerekiyor.
Buna bir örnek şeyi verebilirim.
Hatta iki örnek verebilirim.
Birincisi site cache, cache verisi.
Biz bir noktada cache verisinin arka planda tutulduğu structure'ı değiştirme yoluna gitmemiz gerekti.
Belirli bir istekten ötürü.
Öyle bir kod çıkmalısınız ki hali hazırda cache'de gigabyte'larca veri var.
Onu da doğru şekilde okuyabilmeli.
Yeni gelen structure'ı da doğru bir şekilde işleyebilmeli.
Mesela bu bir backwards compatibility örneğidir.
Veya service authorization'da yöntemimizi değiştirip daha güvenli bir yönteme geçiş yaptık.
Gene aynı şekilde de işte kullandığın tokenları.
kullandığım otorizasyon yöntemine iki versiyonda doğru bir şekilde birbiriyle entegre çalışabilecek şekilde çıkmamız gerekiyor.
Hatta şöyle bir yerde versiyon 1'e bir yerde versiyon 2'yi kullananlar olabilir.
Hala hazırda haberdeşen. Bunların da backward compatible çalışması gerekiyor ki şunu yaptıramayız.
Yüzlerce ekip yani yüzlerce servise hadi aynı anda t eşittir sıfır anında deployment yapın.
Böyle bir dünya yok. Mümkün değil.
Bu yönetilemez. O yüzden bütün uygulamamız backward compatible çalışıyor.
Bir noktada da artık ihtiyaçlar doğrultusunda deployment süreçlerimizi, CI'yi ve CD'yi birbirinden ayırıyoruz.
Biliyorsunuz, continuous integration vardır.
Bir de continuous deployment, delivery vardır.
Biz deployment'ı bir tık ayırıyoruz.
Argo CD'ye geçiyoruz orada.
Bazı konularda daha hızlı aksiyon alabilmek adına.
Bu da yeni implement ettiğimiz, kendi içimizde yeni denettiğimiz bir yöntem.
Kısaca böyle anlatabilirim.
Bizim böyle DDD, Dua Dream'in development'la ilerlemiyor.
Bizim daha simple süreçlerimiz var aslında bu kısımda.
İşimizi kodu yüzünü yaptıktan sonra ilk olarak feature-based pipeline yapımızla ilgili işin olduğu bir polu ayağa kaldırıp, köy arkadaşımızın orada feature test etmesini sağlıyoruz.
Herhangi bir sorun yoksa master branchine merge deyip, stage ortamında end-to-end testlerimizi koşup, UAT'mizi yaptıktan sonra production'a döndüğümüzü gerçekleştiriyoruz aslında bizim deployment süreci.
İzlediğinizde bu şekilde. CRCD yapımızda GitHub üzerinden de uygulamamızı gerçekleştiriyoruz.
Bazı kolaylıkları sağladığı için ArgoCD ile de örnek veriyorum.
Rollback daha basit.
ArgoCD üzerinden yapıyoruz.
Herhangi bir sorun olduğunda Rollback ile geri çevirebiliyoruz uygulamamızı.
Bu şekilde bahsedebilirim GitHub'ın sürecimizden.
Anladım ya. Teşekkürler.
Gerçekten ben açıkçası Devreks ekibinin böyle işler geliştirdiğine çok fazla hakim değildim.
O yüzden şu an birazcık etkilendim.
Ne yalan söyleyeyim.
Şu anda benim kalbim kırıldı. Şaka bir yana gerçekten ellerinize sağlık.
Peki şunu merak ediyorum.
gerçekten hem işte dediğiniz gibi bir developer'ın gününü de aslında kolaylaştırmaya çalışıyorsunuz.
Bir yandan da gerçekten anlattıklarınıza göre bu işler hem büyük hem de riskli işler.
Bunun yanı sıra bir aslında Devex ekibi olarak sizin bu takımdaki en büyük challenge'ınız nedir sizce?
Zor bir soru. En büyük challenge'ımız.
Düşünelim. Bana kalırsa teknik konular bir noktada çözülüyor.
Tekniğe uğraşırsın, denersin.
Olmaz. Farklı bir şey denersin.
Hata yaparsın, düzeltirsin.
Bu bir noktada çözülebiliyor.
Sorunun kapsamını tam bilmiyorum ama ben kendimce yorumlayıp çabuk bulmaya çalışıyorum.
Bence en önemli, en kritik şey iletişimi doğru sağlayabilmek.
Yaptığımız bir şeyi doğru bir şekilde aktarabiliyor olmamız lazım.
En cetrefilli süreç bence insanlarla iletişim sağlamak.
Çünkü şunu düşünün, siz bir ekipsiniz, geri kalan 50-60 tane ekibe hizmet sağlıyorsunuz.
Sonuçta herkesin bilgi veya teknik seviyesi aynı değil, herkesin kavrayışı aynı değil.
Öyle bir anlatabiliyor olmanız gerekiyor ki, konuyu bilmeyen birisi de basic kavramları kavrayabilmeli.
Kafasında bir soru işareti kalmamalı.
Çünkü bir noktada siz bunu özellikle sözel değil, yazısal olarak da yapmanız gerekiyor.
Peki bu neden? Burada ne demek istiyorum?
Ekip sayımız belirli, ekipte kaç kişi olduğumuz limitli.
Bu kadar kişiyi ayrı ayrı, her birine ayrı domenilere hizmet verecek halde bile ayırsak yine yetersiziz.
Çok fazla kişi olmamız gerekiyor.
Ve hep şey denir ya işte, DevOps'ta vesaire, Market'e de.
Her şeyi otomatize et. Otomatize edebildiğin her şeyi otomatize et.
Dokümentasyon da bunlardan biri aslında.
Birilerine gidip bir kişinin bir şey anlatmasındansa o şeyi dokümante et ve öyle bir et ki okuduğunda anlaşılabilir olsun.
Bu gerçekten zor bir şey. Yazısal olarak bir şeyi...
ifade etmek, teknik bir şeyi ve 100 kezlerle harmanlayıp ifade etmek çok zor bir şey.
Bence en büyük challengelarımızdan birisi bu.
Bu birazcık da şey, soft challenge diyebilirim.
Yani teknik değil, teknik çok.
Farklı challenge'larımız var. Ama aklıma gelen yani benim için önemi çok yüksek olan şeylerden bir tanesi bu.
Emre'nin söylediklerine katılıyorum.
Ben ek olarak bizim takımın teknik challenge'ından bahsetmek istiyorum.
İlk başta söylediğim gibi biz open source proje kullanıyoruz.
Bu aşamaya kadar bizim ihtiyacımızı düzgün bir şekilde karşıladı ama datamızın artmasıyla birlikte performans sorunları yaşamaya başladık.
Ve UI tarafında da istediğimiz şekilde değişikliğe gidemediğimiz için backstage'den çıkma kararı aldık.
Bu sıralar yeni yapımımız için analizler ve piyosilerle...
Hem yeni yapımızı geliştirmeye başlayacağız hem de eskisine de çok büyük featureler olmasa da yeni yapı hazır olana kadar geliştirme yapmaya devam edeceğiz.
Genel olarak böyle yaptığınız işlere baktığım zaman zaten böyle çok rutin işler yapmıyorsunuz.
Yani işte böyle business implemente etmiyorsunuz aslında.
Biraz daha işte bir şeyleri araştırmanız gereken, yeni şeyler öğrenmeniz gereken işler yapıyorsunuz.
Yine de kendinize böyle kişisel olarak, bireysel olarak bir vakit ayırabiliyor musunuz sprint içerisinde?
Yoksa yaptığınız işler zaten...
Kendimizi bir şekilde geliştirmemiz için yeterli oluyor mu diyorsunuz?
Evet oluyor. Bunun için çarşamba günleri lunch and lunch sesyonlarımız oluyor.
Bu lunch and lunch sesyonlarında ilgilenip merak ettiğimiz teknolojileri konuşuyoruz.
Bu topiklere not aldığımız bir egzer var.
Ona göre bir plan yapıyoruz.
Her hafta bir teknoloji ya da tool üzerine konuşmaya çalışıyoruz.
O hafta konuşulacak bir konu yoksa ekipçe o hafta yaptığımız işlerimizi review ediyoruz.
Bu da bize çok büyük katkı sağlıyor kişisel gelişimimiz için.
Bunlara ek olarak da yaptığımız işlerde farklı...
farklı teknoloji ve tool'larla ilgili yeni şeyler öğrenme fırsatımız oluyordu.
Aslında böyle soruyu sorarken de bir şey dedi ya, yoksa yaptığınız işler bir noktada bunu kapsıyor mu?
Bazen öyle oluyor. Yani yaptığımız öyle bir iş oluyor ki, teknik anlamda çok...
Fazla şey öğrenmiş oluyoruz.
Sürekli bir öğrenme süreci içerisinde bulabiliyorum kendimi.
Özellikle mesela son zamanlarda global jenerik bir end user otorizasyon sistemi yaptık Trendle'ın internal için.
Bu süreçte o kadar farklı şey öğrendik ki birden fazla tool, birden fazla yaklaşım, birden fazla süreç bunlar nasıl kullanılır, nasıl implement edilir.
İşte avantajları, dezavantajları, ne neyi nasıl yapıyor vesaire.
Bambaşka teknik tool set anlamında şeyler görebiliyoruz.
Ama onun dışında şeyi de yapmaya çalışıyoruz.
Kendimize teknik gelişim için süreç ayırmaya çalışıyoruz.
Atıyorum x bir günün işte bir günü, yarım günü komple open source bir projeye contribution veya onu öğrenmek.
Zaten düzenli lunch and learn'larımız var.
Her hafta onu lunch and learn'da bir konuyu ele alıyoruz.
Bu ya internum geliştirdiğimiz bir şey oluyor ya da birisi çıkıyor diyor ki ya ben şu konuyu araştırıyordum.
Bunu anlatmak istiyorum, sizinle paylaşmak istiyorum.
Bu konuya hep beraber bakalım. Böyle şeyler yapıyoruz.
Bunu sağlamaya çalışıyoruz. Bir yandan da zaten yaptığımız iş de bunu destekleyen bir süreci sahip.
Peki farklı sorunları çözen, farklı ekiplere hizmet veren birçok projeniz var.
Ben şunu merak ediyorum. Bu projeleri dipo ettikten sonra hangi metriklerini takip ediyorsunuz?
Ve aslında daha çok merak ettiğim konu, bu kadar farklı konteksteki projeleri takip etmek sizin için zor olmuyor mu?
Şöyle. Takip ettiğimiz çeşitli metrikler var.
Bu proje burası değişiyor.
Ama genel birkaç metrik var ki onlar da şey.
Yani aslında her projede standart olan throughput ve response time.
Özellikle bazı uygulamalarda bunun response time'ı ne?
Ne kadar throughput alıyor? İşte P99'da ne kadar latency ile hizmet veriyor?
Bunları kesinlikle takip ediyoruz.
Çünkü bizim yaptığımız uygulamaları domain ekiplere hizmet olarak sağlıyoruz.
Biz ne kadar available'ız? Bunu görmemiz gerekiyor.
Bir servisimiz yavaş olduğunda şöyle düşünün mesela.
Servis otorizasyonu. Yavaş çalışıyor diyelim ki.
Çünkü bu tek bir uygulamayı etkilemeyecek ki.
Sonuçta dışarıdan giren bir istek zincirlemen bir sürü domeyine gidiyor.
O bir sürü domeyin aynı uygulamayı tekrar tekrar kullanıyor belki.
Oradaki yavaşlık kümünatif olarak artacak dışarıdan bir isteği.
Toplamda belki işte bir iki saniye yavaşlatacak.
Bu hiç istediğimiz bir şey olmaz bizim.
O yüzden bu en fazla takip ettiğimiz metriklerden birisi bu throughput ve...
Onun dışında distributed tracing metriklerimiz var.
Kim neyi nereden çağırmış, bir request başlamış, nereden girmiş, nereden çıkmış bunları takip etmeye çalışıyoruz.
Bunlar üzerinde çeşitli alerjik mekanizmalarımız var.
Kullandığımız APM tool'u ile olsun, login site'imiz de olsun.
Bunları takip etmeye çalışıyoruz genel olarak.
Ben bahsedeyim bizim taraftan.
Emre'nin bahsettiği gibi New Relic'ten throughput ve response time'larımıza bakıyoruz.
Sonar küple projelerimizin code quality.
Bununla birlikte instantlarımızı not aldığımız Excel'imiz var.
Oradan da takip edip aksiyon alıyoruz instantlarımızla ilgili.
Google Analytics'e uygulamada hangi sayfalar daha çok kullanılıyor, kullanıcıların ne kadar sürekli oluyorlar bu metrikleri takip ediyoruz.
Teşekkürler. Peki böyle bir canlı ortamda aldığınız bir hata ya da işte bir instant var mı bize anlatabileceğiniz?
Özellikle de böyle bir... Çok fazla ekibi etkilediğiniz için yani Devics'in yaptığı bir sidecar birçok şey tarafından, ekip tarafından kullanılıyor.
Burada işte sizin yaşadığınız instantlar bu ekipleri de etkiliyor mu mesela?
Ya da işte etkiliyorsa örnek bir instant var mı?
Hataları kabullenmek çok zor bir şey değil mi?
İnsanların genel olarak. Ama şey bizde öyle bir kültür yok.
Yani kimseyi hatasından ötürü suçlayan bir kültür yok.
Bazen soruluyor mesela. İşte bu soru dışarıdan da soruluyor.
İnsanlar şunu merak ediyor. Ya bir hata yaptınız işte şirkete zarar verdi belki bu mahalleyi açıdan.
İşte kovmuyorlar mı sizi?
Ben de şöyle diyorum. Tamam belirli bir kaybı oluyor yapılan hataların.
Belirli bir sonuçları oluyor. Ama şöyle düşünüyorum.
Sen hatayı yaptın ve artık ne yapmamanın gerektiğini öğren.
Sen bu konuda tecrübelisin artık.
Yaptığın bir şeyin sonuçlarını gördün.
Neler ortaya çıkarabileceğini, vereceği etkiyi gördün.
Seni çıkartsa, yerini yeni birisi alsa.
Sende artık deklare edilmiş bir tecrübe var.
Sen artık bunu biliyorsun. Bir daha yapmaman gerektiğini de biliyorsun.
Bilerek yapmadığın müddetçe.
Ama yeni birisini aldığında yerine aynı şeyleri baştan yaşayacak.
Yaşamayacağının bir garantisi yok.
O yüzden şirket için tecrübe kattığı birisini çıkartıp da yeni birisi tekrar almak çok mantıklı değil.
O yüzden bu gibi durumlarda işten çıkarılma, kovulma veya yaptırım falan durumu...
Çok mantıklı gelmiyor bana genel olarak bahsediyor.
Dünya'da böyle daha evrensel.
Ama bizim mesela en son bir instant yaşadığımız şey, konuyu şey yapmaya çalışıyorum böyle instant yaşadığımız anlar burada.
Kesinlikle bir şey düşünüyorum. Şöyle bir insanımız oldu abi.
End User Authorization projemiz var ve storage olarak bazı end user verilerini tutan, hesaplayan open source bir tool kullanıyoruz orada.
Bu tool düşük skeldeyken, bayağı çok düşük skeldeyken ihtiyaçlarımızı karşılıyordu.
Ama zaman içinde o tool'a entegre olan ekip sayısı, o tool'a gelen yük vesaire artmaya başladı.
Ve bir noktada birazcık da legacy teknolojiler vardı tool'un arkasında.
Biz böyle derinlemesini kullanmaya başlayınca fark ettik.
Bir noktada yükü kaldıramaz olduk.
tabanına attığı sorunlar çok saçma sapandı vesaire.
Özet geçiyorum tool çöktü production'dan.
çöktü ve kendini toparlayamadı.
Yani çökmesi mesele değil. İşte veri tabanı yatıyor mesela hiçbir hata yok.
İşte VM'ler yatıyor.
Ama tool'un kendisi bir şekilde kendisini toparlayamıyor.
Yani trend management'ı, pool management'ı, connection management'ı düzgün sağlayamıyor ve çöküyordu.
Bayağı böyle birkaç saat bir instrument'ımız oldu.
İndi o ürün ve belirli bir süre domain ekiplere, internal user'larına hizmet veremez oldu.
Öyle bir... Tatsız bir an yaşandı yani.
En güncel hatırladığım bu.
Aynen bu ekiplerden biri de biziz.
Bizim de uygulamamız etkilendi.
Ne diyeceğimi bilemedim.
Mahkumuz galiba. Sağ olun.
Biz öyle bir ekibiz ki batarsak kendimizi de batırıyoruz.
Peki aynı gemideyiz, batarsak birlikte batıyoruz, çıkarsak birlikte çıkıyoruz dediniz.
Harika bir soruya böyle pas atmış oldunuz.
Aynı gemideyiz tabii ki ve işte teknik olarak...
Birbirimizi sürekli besliyoruz.
Lunch and Learn yaptığınızdan, bilgi aktarımına önem verdiğinizden bahsettiniz zaten.
Peki bunun dışında hepimiz insanız çünkü.
Hepimizin kötü anları olabiliyor.
Bir anda ekibinizden bir arkadaşınızın motivasyonunun düştüğünü gördünüz.
Mutsuz olduğunu gördünüz.
Böyle zamanlar oldu mu?
Olduysa nasıl bir çözüm uyguladınız?
Veya bu konularda birbirinizi yükseltmek için neler yapıyorsunuz?
Şöyle oluyor aslında. Hissettiğimiz bir motivasyonun düşük bir olduğunu...
Biz genelde kendimiz görüyoruz.
Arkadaş direkt hani motivasyon düştü ya da modum düşük diye gelmiyor.
Öyle bir şey olduğunda fiil ilerlemeye çalışıyoruz yani.
Onun önceden yaptığı...
Eğer bu iş kaynaklı bir şeyse, motivasyonu teknik anlamda düşmüşse, onun önceden yaptığı güzel işleri de motive edecek şekilde hatırlatıp, onun lead ettiği bir iş alıp pair oluyoruz aslında.
Motivasyonunu yerine getirmek için.
Onun dışında eğer gerçekten özel hayatta ilgili bir şeyse, konuşup kendini iyi hissetmesi adına küçük böyle çay saatleri yapıp, derdini dinleyip motivasyonun yükselmesini sağlıyoruz.
Şöyle de bir durum var bizde.
Şunu sürekli ekip olarak destekliyoruz.
Bu desteği ben de... Ekip arkadaşlarımdan yer yer görüyorum.
Bir derdiniz olduğunda bunu bayrak kaldırmaktan çekinmeyin diyor.
Şu tabir bizde vardır. Bayrak kaldırmaktan çekinmeyin.
Ve bunu yeni gelen veya uzun süredir ekibimizde olan herkesin sürekli söylüyoruz.
Bir sorun mu oldu? Bir yerle ilgili bir şey mi var?
Bir derdin mi var? Bunu anlat.
Çekinme. Biz genel olarak zaten siz de biliyorsunuz.
Ekip trend olun. teknoloji ekibi kültürü olarak şöyle bir şey var.
Aynı iletişimi açık ve doğru bir şekilde yapalım net bir şekilde.
Mesela bizim domenimizde kontekst switch olabiliyor projeler arasında.
Çok fazla kontekst switch yakmış olabilir insan.
Ben de mesela bazen hissediyorum.
Çok fazla bölünüyoruz bazen.
Bu CPU bile yoran bir şeyken insan beyni kolay değil bunu kaldırarak bölünüyor.
Bazen motivasyon düşebiliyor.
Veya uzun süre aynı proje üzerinde çalışmak da demotive edebiliyor.
Bazen şimdi yazılımcılar olduğumuz için hep şey istiyoruz.
Teknik, böyle bir değişiklik, yenilik vs.
Bu da yansıtıcı olabiliyor.
Burada şeyi sağlamak lazım.
Bir tık bizim de herkesin yani bireysel sorumluluk olarak gözlem yeteneğimizin biraz yüksek olması lazım.
Farkındalığımızın fazla olması lazım ki...
Şunu anlayabilirim. Birlikte çalıştığımız kişi düşüyor mu?
Düşüyorsa hemen ona ya sen düştün böyle yapma falan demek yerine fark ettin o.
Bir sohbete çek kafasını daha belki o gün çalışma ya o gün iş süreçlerini birazcık daha yavaş ilerle tamam.
O kişinin motivasyonunu yükseltebilecek şeyler yap.
Motivasyonun yüksekken gerçekten üretkenliğin fazla oluyor ya.
Belki iki saatte bitiriyorum her şeyi.
Şimdi o kişiyi sekiz saat düşük modda çalıştırmaktansa bir saat kafasını dağıtıp geri kalan süreçte çok daha hızlı bir şekilde adapte edebilirsin.
Bu öyle bir şeydir ki bir kişinin modunun düşmesi.
Günlerce sürebilir o düzelmediği zaman.
Kendi kendine düzelmesini beklemek bir şeylerin her şeyi yoluna koymayabilir.
O kişiyi bir şekilde toplamamız lazım.
Belki teknik bir sorun canını sıktı.
Belki bir süreç canını sıktı.
Belki iletişimde sonuçta çoğu zaman artık yazışmayla iletişim sürdürüyoruz ya.
Mimikler gözükmüyor, ses tonu gözükmüyor.
Ne dediğim belki yanlış anlaşılıyor.
Herhangi bir sebepten düşmüş olabilir ve bunun giderilmesi gerekebiliyor.
harici bir kaynak tarafından.
O da bizler oluyormuş. Bunu yapmak o düşük süreci toparlayabilir azıcık.
Olan cevap olmuştur ya.
Oldu oldu. Güzel cevap bu.
Teşekkürler. Bu arada katıldığınız için de teşekkürler ayrıca.
Programın sonuna da gelmiş olduk sanırım.
Biz teşekkür ederiz. Bir geleneğimiz var tabii.
Onu da bırakmayalım. Bir şarkı da rica ediyoruz tabii ki de kapatmadan önce.
Şarkının adını mı söylüyoruz sadece?
Çünkü şarkının kendisini söylüyor olmak eziyet olabilir.
Varsa kendisi bir repertuarda ne varsa artık.
İbrahim tatlı sesle yabancı bir kadının remixi var diyor.
Doğalipo mu? Aynen aynen doğalipo.
Cehennemde bile bir araya gelmeyecek insanlar diyor.
Şey de olabilir yani bu bölümü kaydedip insanların motivasyonunu yükseltmek için.
Çünkü daha kötü bir şey varsa o da bizim şu an şarkı söylememiz olabilir.
Belki kaydedip. Onların motivasyonunu ve modunu yükseltebiliriz bu sayede.
Değil, tabii ki de şaka yapıyorum.
Arkadaşlar böyle bir şey yapmayalım.
O zaman hayalet sevgilimi olsun ya.
Son zamanlarda tekrar popülerleşti zaten.
O zaman şöyle yapalım.
Ben arkadaşlara, dinleyenlere G-Minor, Beh'ten G-Minor, Lua Nu Arrangement'ı dinlemeliyim.
Klasik müzik yazan developer'ın üretkenlerimizde 26'ymış.
O zaman teşekkürler.
Biz teşekkür ederiz. Geleneğinizi bozmuş mu olduk?
Ne olduk? Bir ilk mi?
Yok kimse söylemiyordu zaten.
Nasıl ya? Söylüyorlardı.
Ya atlıyormuşum ben.
Çünkü bende öyle bir vibe var yani.
Böyle bir atlarım. Böyle şeylere söylüyormuş.
Arada söyleyen oluyordu ya.
Korkma. Yok ya benim söylemişliğim var bu arada arkadaşlar.
Yani çok kötü olmasa da.
Söylesene o zaman aşk olsun.
Ben şurada bayılıveririm.
Oraya nasıl çıktığına dair en ufak bir fikrim bile yok gerçekten.
O gün böyle çok özgüvenliğim için çıktık.
Bu arada gezimizden olan bir anı.
Trendi olan işte bol abartılı olan gezimizden.
Bir türkü söylemiştim var tabii.
Hangi türküydü ya? Kocakonak.
Nasıldı ya? Çıkıp da...
İnmediğim o anı hatırlıyor musun?
Böyle işte eklemedir koca konakla giriş yapıp sonra beyaz giyme toz olur, siyah giyme toz olur.
O türküyle devam eden bir serüver.
Bu arada bol türküstür arkadaşlar.
Beyaz giyme toz olur, siyah giyme toz olur.
Çok özür diliyorum. Öyle.
Bu bilgilendirme için de teşekkürler.
Bu bilgiyle... Kendi türkünü de ters ters...
Evet ya.
Biraz öyle oldu. Bir bilgi verdik.
Bir şey var. İnfo var burada.
Artık çıkmaz aklımızdan.
Teşekkürler. Teşekkür ederiz.
Teşekkürler. O zaman kendinize iyi bakın.
Görüşmek üzere. Hoşçakalın.
Görüşmek üzere. Hoşçakalın.
Bu transkript otomatik olarak çıkarıldı; kayıtla küçük farklar olabilir.