
Transkript
Selam ekip. Yine programımıza hoş geldiniz.
Bu acaba kaçıncı program?
13, 14, 12 arasında gidip geliyorum.
Burada pandemi yasakları beni çok etkiledi.
O yüzden tam cevabı bilmiyorum ama topu Onur'a atabilirim.
Onur kaçıncı programınız? Bugün 14.
programımız olsun Fırat.
Merhaba bu arada. Barış senin bir tercihin var mı?
Sormadım ama. Yok ben de 14 iyidir diye düşünüyorum.
O zaman. Bugün 14.
programımızda. Merve Canar ve Semih Köker bizimle Sales Store ekibine temsilen bugün katıldılar.
Hoş geldiniz arkadaşlar. Öncelikle biraz kendinizden bahsedebilir misiniz?
Merhabalar herkese.
Merve ben. 5 yıldır teknoloji ekibinde çalışıyorum Trendyol'da.
Bayağı eski sayılırım burada.
Son bir senedir de Sales Store domeninde Product Manager olarak çalışıyorum.
Benden bu kadar.
Semih'e batayım sözü. Selamlar.
Ben de Semih. 1,5 yıldır Trendyol'da çalışıyorum.
Bundan önce bir yaklaşık 10 yıla yakında bir sektör tecrübem var.
Burada takım yöneticisi olarak devam ediyorum.
Tekrar hoş geldiniz.
Biz geçenlerde benimle birlikte çalıştığım kupon ekibiyle geliştirilen bir geliştirmede bir araya gelmiştik Seller Store'la.
Daha çok orada API'lerimizle birbirimize tanışmıştık ve konuşmuştuk.
Ama dinleyicilerimiz için de böyle domen nedir, neleri kapsar, sayfalar işte.
Back-end'de, front-end'de neler yapıyorsunuz?
Biraz bunlardan bahsedebilir misiniz bize?
Burada lafı ben alayım aslında.
Biz Seller Store için satıcıların trend yoldaki vitrinin tanımını uygun görüyoruz.
Satıcıların panelleri var.
Panelleri üzerinde oluşturdukları ekranlar bunlar.
Ekip olarak satıcıların sayfalarını oluşturmalarından, bu sayfaların ön yüz platformlarında görüntülenmesinden sorumluyuz.
Neden böyle bir domain var?
Amacımız ne dersek de...
Hem müşterilerimize hem satıcılarımıza olan etkisini anlatabilirim.
Burada bu sayfaların satıcı tarafından amacı satıcıların kendi o platformu içinde kendilerini daha fazla örgütlerine çıkarabilmelerini sağlamak.
Satıcıların kendi takipçilerini kazanarak daha sadık müşterilik kitleleri oluşturmalarını sağlamak aslında.
Müşteri tarafından da şöyle bir şey var.
Sevdiğim bir satıcının ürünlerine daha hızlı ulaşabiliyorum, daha kolay bulabiliyorum diyebiliriz.
Peki sedatör domeyini hangi takımlarla daha yakın çalışıyor?
Burada hem ekip satıcı ekranlarından sorumlu hem ön yüz ekranlarından sorumlu dikey bir ekibimiz var.
Dolayısıyla bir sürü ekiple beraber çalışıyoruz.
Bunları böyle sıralayayım biraz.
Web ve mobil web ekipleriyle çok yakınız.
Bu platformlardaki sayfaları direkt Seller Store ekibi geliştiriyor.
Yine iOS Android platformlarındaki geliştirmeler bizim tarafımızdan yapılmıyor ama mobil ve onun gatewayi olan Zeus ekibiyle çok yakın çalışıyoruz.
Satıcı ekranlarını geliştirirken Marketplace Core ekibiyle çok yakın çalışıyoruz.
Satıcı ekranlarında satıcıların ürünlerini çekebilmek için Search ekibinden bayağı destek alıyoruz.
Yine satıcı bilgiler için de Indexing ekibiyle çalışıyoruz.
Google tarafında mağaza aramalarını ön plana çıkarmak için SEO ekibiyle yaptığımız çalışmalar var.
Burada yine mail linkler, müşterilere atılan kuşlar için...
CRM ekipleriyle de çalışıyoruz.
Son olarak da son zamanlarda böyle mağaza takipçileriyle ilgili böyle fake followerlar falan yapan servisler çıktı türede.
Bunları da böyle sistemden silebilmek için data science ekipleriyle yakın çalışıyoruz fake followerları track edebilmek için.
Böyle özetleyebilirim.
Fake follower konusu çok enteresanmış ya.
Yani hani Instagram'da falan böyle satın alınan fake followerlar oluyordu ama trend yolda da olması gerçekten ne kadar...
Herhalde büyüdüğünün göstergesidir.
Peki çok fazla sorumluluktan bahsettiniz.
Burada ekip yaparız nasıl? Yani öyle backend developerlarla mı çalışıyorsunuz?
Yoksa frontend tarafı da var mı?
QA ne durumda? Burada sözü ben alayım.
Aslında burada bizim backend developer, frontend developer diye bir ayrımımız yok.
Ekipteki bütün geliştiriciler full stack developer olarak çalışıyor.
Bunun dışında iki tane QA arkadaşımız var.
Developer'in test rolünde.
Bütün developerlar aslında hem backend hem frontend nereye dokunulması gerekiyorsa yazıyor kodunu.
Biz deep backend de sağlıyoruz.
Satıcı panelinin ön yüz ekranlarını da biz geliştiriyoruz.
Mobil web gatewayleri de biz sağlıyoruz.
Sadece Zeus bizim deep backendimizden gelip mobil clientlarda kendi satıcı sayfalarını yaratıyorlar, gösteriyorlar.
Bundan dolayı biz aslında böyle dikey bir ekibiz.
Herkese her işe giriyor gibi düşünebilirsiniz.
Aslında satıcıların kendi sitelerini yapıyorlarmış gibi kullandıkları ve buradan ürün sattıkları bir portal gibi düşünebiliriz değil mi?
Satıcılar kendi sayfalarını dizayn ediyorlar.
User'larda aslında bu satıcıların kendi satıcı sayfalarını görüyorlar.
Bu sayede sellerler user'larla engagement kurabiliyor bu köprü üzerinden.
Kaç yıldır var bu domain?
İlk ne zaman başlamışsınız?
Aralık'ta başlamış. Aralık 2019'da.
Yani bir buçuk yıl kadar falan bir domain.
Aslında sonrasında hızlıca remote'a geçtiniz pandemi nedeniyle bir ekip yapılanması değil mi?
Evet. Ekibi kurarken hem pandemi döneminde hem ondan öncesinde nasıl bir onboarding stratejiniz vardı?
Neler yaptınız? Değişen neler oldu burada?
Remote zamanı biraz daha dikkat etmeye başladık onboarding süreçlerine.
Şimdiki onboarding planından biraz bahsedeyim.
Biz aslında iki haftalık bir onboarding planı yapıyoruz.
İlk hafta genel olarak body ile böyle pair olarak domeni...
tanıyarak geçiyor. İkinci hafta ise çok küçük de olsa bir task atayıp payroll'lu kişilerle geliştirip kodun canlıya çıkmasını sağlıyoruz.
Uçtan uca aslında iki hafta içinde bir kod oluyor canlıda.
Hem bu süreçte de ortamları, pipeline'ları daha iyi anlıyorlar.
Bu süreci iyileştirmek için ise yeni gelen arkadaşlarla her onboarding sonrası onların feedbacklerini alıyoruz.
Onlara önem veriyoruz. İşte önceki çizdiğimiz diagramlar Süreçler anlaşılır mı?
Şu anki yaptığımız wiki sayfaları yeterli mi?
Bunların feedbacklerini toplayıp eksik yerleri ekliyoruz ki yeni gelen arkadaşlar daha iyi bir onboarding deneyimi yaşayabilsin.
Ben bir daha şeyi soracağım.
Şimdiye dek sormadınız bir soruyu ama kaç uygulamanız var?
Kaç mikro servisiniz var?
10 tane mikro servisimiz var.
Bunlar aslında çok küçük küçük gerçekten mikro servis kıvamında olan da var.
Ana domenleri yönettiğimiz mikro servislerimiz de var.
İki tanesi Deep Backend.
Biri satıcı takip mekanizmasının olduğu domeni ve asıl olan da satıcı sayfalarının tuttuğumuz dataları sağlayan domeni var.
İki Deep Backend. Diğerleri BFF tadında ya da bizim ön yüz satıcı sayfasının ön yüz kısmı için kullanan backend servislerimiz var.
Onun için arada yazdığımız BFF'ler oluyor.
Peki bir trend içerisinde çok fazla ekip var ve her ekibinde kullandığı teknolojiler birbirinden farklılaşabiliyor.
Siz burada hangi teknolojileri daha çok kullanıyorsunuz ve bu teknolojileri seçme nedenleriniz ne olmuştu?
Ağırlıklı olarak Node.js TypeScript kullanıyoruz.
TypeScript TypeSafe olarak geliştirme yapmanızı sağlıyor.
Node.js de hem hızlı performanslı bir uygulama geliştirmek için imkan sağlıyor.
Hem de bu ekip kurulurken rotasyonla gelen arkadaşların Node.js tecrübeleri olduğunu düşünerek böyle başlanmış.
Node.js projelerinde genelde NET diye bir framework var.
Bunu kullanıyoruz. Bu geliştirme hızımızı arttırıyor.
Bunun dışında Java ve Kotlin'de yazdığımız apilerimiz de var.
Burada da Spring Boot'un nimetlerinden yararlanıyoruz.
Java ve Kotlin kullanma sebebimiz aslında mikro servisin domen ihtiyaçlarını karşılaması oldu.
Bunu örneklendirirsem mesela satışı takiplerini handle ettiğimiz servisler Go ve Node.js'e göre Postgre tarafındaki...
Tüphaneler daha gelişmiş, daha hızlı geliştirme yapılabiliyor.
Hem de bu tarafta write yükü çok fazla olduğu için high throughput çalışabiliyordu.
Bundan dolayı seçtik.
Bunun dışında Go'da yazdığımız bir consumer var.
Go deneyebilelim ekipte diye.
Bu satıcı takiplerinin fraudunu önleyen, data science'dan akan trafiği karşılayan consumer'da Go kullanalım.
Hem de öğrenmiş oluruz dedik.
Ön yüz içinde aslında mobil web web tarafında server site rendering ile sayfaları server ediyoruz.
Bundan dolayı ön yüz tarafında React kullanıyoruz.
Kolayca server site rendering işlemleri yapabilmek için.
Partner etrafında da verdiğimiz ön yüzde ise gene React kullanıyoruz.
Burada Recoil diye bir ekstradan state management kütüphanesi var kullandığımız.
Database olarak da Postgre ve Couchbase kullanıyoruz.
Benim çok küçük bir sorum var.
Trendyol'da 3 farklı satış tipi var.
Bizim aşina olduğumuz ya da e-ticaretten aşina olunan SDFT ve MP diye.
Marketplace'de çoğunlukla bilinen pazar yeri ismiyle bilinen.
Burada pazar yeri ile satışa çıkan herhangi bir satıcının direkt sayfası oluyor mu?
Yoksa bir arayüzden girip sayfasını aktif mi hale getirmesi gerekiyor mağazasına?
Burada ben gireyim devreye.
Şöyle satıcıların panelleri var aslında, satıcı panelleri.
Burada bizim de ayrı bir sayfamız var mağaza oluşturulması için.
Bu sayfa üzerinden değişik komponentler kullanarak aslında örnek verecek olursam işte ürünlerini bir yerde...
toparlayabilirler. İşte oluşturdukları kampanyaları burada sergileyebilirler.
Değişik bannerlar yaratabilirler.
Bunları böyle düzenleyerek aslında kendilerine bir sayfa oluşturabiliyorlar.
Bunu yayınladıklarında tüm platformlara biz bunu serve ediyoruz aslında.
Aslında ön yüz tarafında da çok fazla işiniz var ve olası bir hata çok katastrofik olabilir sizin için.
Siz ne kadar zamanda bir cipto yapıyorsunuz?
Genelde haftada splinter koşuluyor ama sprintin sonunu mu bekliyorsunuz yoksa nasıl ilerliyorsunuz?
Şöyle işliyor aslında.
Trunk-based development yapıyoruz biz.
Ondan dolayı bu trunk-based development'ın da scale trunk-based development stratejisiyle ilerliyoruz.
Bundan dolayı kodumuz merge olduğunda aslında master'daki pipeline devreye giriyor.
Bundan dolayı...
Orada kontinüsel veriye ne kadar yakın olabilirsek o kadar daha iyi olur diye biz o pipeline'larımızı geliştirdik.
Merge olduktan sonra master'a bizim pipeline'ımız başlıyor.
İşte testleri geçiyor.
Unit testleri geçtikten sonra acceptance testleri yapıyor.
Ve dev stage'i otomatik deploy oluyor.
Burada pipeline duruyor. Manuel kontrolden sonra genelde manuel kontrollerimiz de UI tarafındaki kısımlarda işliyor.
Backend tarafında... Bu kontrollerden kaçmak için otomasyon testlerimizi arttırıyoruz.
Bunlar geçtikten sonra köye arkadaşımız okey verirse canlıya kodumuzu çıkıyoruz.
Bayağı da sık diploömit yapıyoruz aslında.
Ayda 50-60 arası diploömit yapıyoruz.
Yani bir sprint'in bitmesini beklemek gibi bir durum yok bizim tarafta.
Diploömit sürecinden bahsederken gerçi biraz değindin ama kod review süreçleriniz nasıl işliyor?
Ya da işte test yazıyorsunuz, onu değindiniz.
İşte TD'de uyguluyor musunuz?
İlerliyor musunuz? Oraları biraz anlatabilir misin?
O süreci nasıl yönetiyorsunuz?
Olur. Daha demin TrumpBase geliştirme yaptığımızdan bahsetmiştim.
Future branch'e geliştirme yapıp pushluyoruz.
Bunun için de küçük bir pipeline dosyası geliştirdik.
O otomatik merge request açıyor.
Merge request açıldığında bütün ekibe düşüyor zaten bunun Slack alerti.
Orada herkes uygun olduğu olan kişi kodu review edip işte commentini girip ya da bir sıkıntısı yoksa Merge edebiliyor.
Test tarafı da şöyle, test sürecini.
Backend kodlarımızı yapar yapmaz en kısa sürede aslında acceptance ve contract testlerini eklemeye çalışıyoruz.
Ki backend tarafını böyle daha otomatize edebilelim.
Hiç manuel test olmadan canlıya otomatik çıkabilsin.
Amanıyoruz bu. Ama ön yüz tarafında her zaman bir köye arkadaşımızın kontrol etmesi gerekiyor.
Web tarafında yaptığımız otomasyonlarda da zaten genelde BFF gibi davrandığımız yerlerin otomasyonlarını böyle...
Ya da sayfa düzgün render oluyor mu?
Ama muhakkak o tasarım hatalarını görmesi için QA arkadaşın bir son göz olarak bakması lazım.
Bu tarafta manuel süreçleri kısaltmak için de araştırdık visual testing diye bir konu var.
Bunu implement edeceğiz ve buradaki amaç da aslında QA hiç manuel test yapmadan otomatik canlıya çıkabilsin.
Geliştirme yaparken de TDD uygulamaya özen gösteriyoruz açıkçası.
Pay'lerimizde şöyle böyle 1-2 puanlık falan Küçük işler olmadığı sürece muhakkak peer ilerliyoruz.
Yani %90 neredeyse peer olarak çalışıyor herkes.
Peki canlıya çıktıktan sonra olası bir problemde bunu nereden nasıl fark ediyorsunuz?
Hangi kanallardan monitör ediyorsunuz?
Şöyle monitoring ve alert mekanizmamızı açıklayayım biraz size.
Bizde 3 tip alert mekanizması var.
Birincisi log seviyesindeki alertler.
Loglamamızı düzgün yapmaya çalışıyoruz.
Buna göre Kibana ve Greylock'ta lock severity'ler var.
İşte gerekli error'ların gerçekten error olduğunu, gerekli warn'ların gerçekten warn olduğunu iyice ayıkladıktan sonra Greylock ve Kibana'da bence bunların alertleri takip edilebilir.
En azından business exception'ları böyle yakalıyoruz.
Burada da şöyle yapıyoruz.
İşte error için threshold'umuz son bir dakikada 10.
İşte warn için 50 diyelim.
Bu threshold değerlerini aşınca bizim...
Alert kanalımız var. Oraya slay'e hemen alert düşüyor.
Biz de alerti görünce bakıyoruz, müdahale ediyoruz.
İkincisi, nivriyelik tarafında alertlerimiz var.
Burada da apt-x, response time, error yüzdelerine göre belli thresholdlar var.
Bu thresholdlara göre gene alert düşüyor kanalımıza.
Üçüncüsü de grafana alertleri.
Burada da mesela Kubernetes'in üstünde podların metriklerini topluyoruz.
Podların restart count'u arttı.
Demek ki bir sıkıntı olabilir.
Potken kendine restart olduysa.
Bunun için de gene sile kanalımıza alert düşüyor.
Bu mekanizmalar sayesinde aslında ilk bir haberimiz oluyor.
Böyle hızlıca müdahale edebiliyoruz.
Sadece böyle özetleyebilirim.
Diyelim gece 1'de bir sorun oldu.
Hani müşteriler de sipariş vermeye devam ediyordu ama sayfa render etmiyor.
Bu tarz durumlarda nasıl alert oluyorsunuz?
Aslında buradaki amaç şey.
Bundan haberimiz oluyor senin söylediğin kezde.
Ama haberimiz olmayacak bir kez içinde...
Haberimiz olduğunda muhakkak bunu track edebildiğimiz bir alert sistem yapıyoruz.
Mesela bu dediğin case'de backend'e spesifik bir exception fırlatıyorsa bu exception'ın yakalayıp istediğimiz leveye göre logonu basıp buna spesifik alertler tanımlayabiliyoruz.
Mesela bir sıkıntıdan bahsedeyim yaşadığımız.
Bir ara backend tarafında bir validasyon eklemeyi unutmuşuz, canlıya çıkmışız.
Bundan bir incident yaşadık.
Tamamen stage'deki çalıştığımız server'ı hem developer hem de testçi arkadaşımız kullandığı için bu hatayı yakalayamamışız ve canlıya çıkmışız.
Validasyonsuz şu oldu.
Bu da yeni satıcı sayfası oluşturacak user'ları aslında etkiliyor.
Bundan dolayı yaklaşık bir 16 saat falan haberimiz olmadan bazı satıcılar girememiş satıcı paneline.
Bundan sonra şey yaptık.
Bundan haberimiz olduğunda hemen bunun specific business'ını yakalayıp Log'unu bastık ki bana da bu log'a özel alert tanımladık.
Bir tane bile olsa artık şimdi böyle durumlar olduğunda haberimiz olacak, müdahale edebileceğiz.
Yaşadığımız incident'lardan ders çıkartıp aslında böyle şeylere yöneliyoruz.
İlk bir şeylerden haberimiz olsun diye.
Peki, Selim Spor ekibinin en büyük challenge'ı nedir diye sorsam nedir?
Şöyle aslında, böyle tren yolu içerisinde binlerce satıcı var biliyorsunuz.
Bunların hepsi de çok...
donanımlı deneyimli olamayabiliyorlar böyle teknoloji kullanma konusunda.
Aslında köşedeki kırtasiye de herhangi bir satıcı olabilir.
Böyle tüm kitleler tarafından anlaşılabilir bir sayfa yaratmamız lazım.
Satıcıların çok kolay bir şekilde mağaza oluşturabilmesi lazım.
Bu yüzden böyle sayfalarımızı sadeleştirip biraz kompleks bir sayfamız var.
Bunları böyle biraz daha sadeleştirebilmek üzerine çalışıyoruz.
Bunu da aslında şöyle yapıyoruz.
Satıcıların aldıkları hataları logluyoruz.
Özel eğitimler yapıyoruz.
Her hafta yapılan eğitimler var.
Eğitim ekibi tarafından yapılan.
İşte fokus gruplar yapıyoruz.
Bazen satıcıları çağırıyoruz.
Siz ekranı kullanın biz sizi izleyelim.
Nerede takılıyorsunuz görelim istiyoruz.
Burada da aslında ileride de...
Satıcı datamız şu anda küçük aslında.
İleride de satıcı datası biraz daha büyük olduğunda AV testler yapıp aslında nerelerde zorlanılıyor, bunu daha iyi nasıl hale, ekranları daha iyi nasıl hale getirebiliriz diye görmek istiyoruz.
Bir de şimdi yine dediğim gibi Trendyol'da bir sürü satıcı segmenti var.
İyileri olanlar da var böyle fazla satışlı, koton gibi ya da işte dediğim gibi köşelik kırtasiye de başka bir segmentte.
Bu segmentlere hitap eden geliştirmeler de yapmayı hedefliyoruz.
En büyük challenge'ımız bu şu anda.
Semih incident'larda aldığınız işte oradaki yaptığınız iyileştirmelerden bahsetti.
Belli ki ekip olarak da sürekli iyileştirme mentalitesiyle.
var olan problemleri sürekli ders çıkararak devam ettiriyorsunuz.
Böyle retrolarda direkt bir örneğiniz var mı?
İşte en sonra çıkan retroda çıkan konu şuydu, şunun üzerine durduk.
Ekip olarak şunun üzerinde çalışmamız gerekiyor dediğimiz nedir?
Ekran bazlı değil de bizim retrolar gerçekten çok sakin geçiyor.
Bayağı uyumlu bir ekip aslında kendi içerisinde.
Sadece remote çalışma kaynaklı bir maddemiz vardı, onu söyleyebilirim.
Toplantılarda böyle konuşurken kameralar kapalıysa karşımızdakilerin tepkisini asla göremiyoruz, anlayamıyoruz.
Bazen böyle kafa sallıyorlar kendi içlerinde ama görmediğin için sanki boşluğa anlatıyormuşsun gibi geliyor.
Bunu engellemek için böyle groominglerimizde, planlamalarımızda kamera açmayı zorunlu hale getirdik kendi içimizde.
Bayağı iyi geldi bize ondan sonra.
Teknik olarak da şöyle bir şey var aslında.
Bazen Semin dediği bir sürü alert mekanizmalarımız var aslında.
Ama böyle false alertler falan oluyordu.
Takımın dikkati dağılıyor böyle çalışma esnasında böyle false alert gelince.
Bunun için de böyle logları sınıflandırdık.
Her birine ayrı alert mekanizmaları tanımladık falan.
Şimdi artık gerçekten bir sorun olduğunda herkes doğru yere odaklanıyor.
Zaman kaybını böyle dikkatlanıklığını falan engellemiş olduk.
Ya şey bizde de var bu arada.
Remote'da çalışıp kamera açma o bizde de var.
Hatta ben şu an anlaşmak istemiyorum.
Çünkü burunda kocaman bir sivilce var.
Ve kamerayı açtığımda görünen ilk şey bu.
Bunun da böyle ters sıkıntılı durumları var.
İnsanlık hali ya olabilecek bir şey.
Ama sorun hiç bununla alakalı değil.
Bunu paylaşmak istedim sadece.
Siz takım olarak sizin için en önemli metikler hangileri?
Yani işte o an server store'da bulunan satıcı sayısı mı, burada bulunan ürün sayısı mı?
Siz neleri takip ediyorsunuz?
Şöyle biznes olarak baktığımız bir sürü metrik var.
Sisteme her gün yeni satıcılar katılıyor.
Bizim amacımız aslında her gelen satıcının kendi mağazasını oluşturabilmesi.
Bu yüzden de şeye bakıyoruz.
Sistemde ne kadar satıcı var, ne kadar mağaza oluşturmuş.
Bunun oranını takip ediyoruz.
Ondan sonra siteye gelen müşterilerin ne kadar bu mağazaları ziyaret ediyor.
Toplam trend yola girenler ama bunların içerisinde ne kadarı mağazaları görebiliyor?
Buna bakıyoruz. Yine mağazaların efektivliğini ölçmemek için de mağazaya giren müşterilerin ne kadarı alışveriş edip çıkıyor?
Buna da bakıyoruz. Bir de ayrıca bizim ortalama follower sayısı diye bir metrimiz var.
Bu ortalamada ne kadar yüksek olursa aslında satıcılar için o kadar iyi.
Çünkü bir mağazayı takip eden bir müşterinin satın alma oranı diğerlerinden daha yüksek.
Takip ediyorsam gerçekten onun ürünlerini merak ediyorumdur.
Biziz metrikler genel olarak böyle aslında.
Ben teknik metrikler için sözü semiye bırakabilirim.
Olur. Teknik tarafta aslında çok fazla metrik takip ediyoruz.
Hepsinin detayına girsem mi çok emin olamadım.
İlk başta 4K Matrix değerlerine bakıyoruz aslında.
Bunlar bizim için önemli.
Bunun dışında projelerin unit test coverage'ları, sonar kod kalite değerleri, işte aylık yaşadığımız incident'lar, bunların analizini ve üstünde konuşalım bir daha nasıl yapmayız diye konuştuğumuz
session'larımız oluyor. Acceptance test adetlerimiz, performans test senaryolarımız, işte...
Nivrelik'ten aylık ne kadar throughput almışız, ne kadar error rate'imiz var, average response time'larımız ne seviyede, database index büyüklüğümüz ne durumda, CDN'deki büyüklüğümüz ne kadar,
pipeline sürelerimiz artmış mı, azalmış mı?
Bu metrikleri takip ediyoruz.
Aylık bir kere yaptığımız KPI toplantımız var.
O ayın sorumlusu ilgili Excel'i dolduruyor.
Sonra bir saatlik toplantıda bu metrikleri konuşuyoruz.
Bir anomali varsa...
Buna göre aksiyonlarımız çıkıyor.
Sallıyorum işte pipeline sürelerimiz 10 dakikadan 15 dakikaya çıkmış.
Pipelinde nasıl bir geliştirme yaptık böyle böyle.
Hani canlıya en hızlı 10 dakikada kod atmam zorunda kalacağız böyle bir durumda.
Pipeline sürelerini kısalım diye bir aksiyon maddesi çıkabiliyor.
Ya da işte yaşadığımız incidentları konuşuyoruz.
Incidentların üzerine tekrar işte aksiyon piyanları yapıyoruz.
Ne olursa bir daha yapmazdık.
gibi. Unit test coverage'larımız işte bakıyoruz %90'ın altına düşmüş projeler varsa bununla ilgili task'lar atıyoruz birbirimize unit test coverage'larını arttıralım diye.
İşte database'deki index size'ımız çok mu büyümüş?
Bunların üzerinden bakıp anomaller varsa bunları detect edip ilgili task'ları yaratıp bir sonraki ayda yapacağımız KPI toplantısına kadar bu maddeleri tamamlamaya çalışıyoruz.
Peki can sistemde yaşadığınız bir problem ve o problemde öğrendiğiniz ve bizim dinleyicilerle paylaşabileceğiniz bir deneyim var mı?
En son yaşadığımız incident aslında 2 ay önceydi.
Bu size daha demin bahsettiğim durum.
İşte back-end'de bir validasyon eklemeyi unutmuşuz.
İşte bunu stage'de de görememişiz.
Canlıya çıkmış. İşte yaklaşık bir 16 saat falan satıcılar ilgili şeye giremedi.
Kendi sayfalarını oluşturamadılar.
Böyle bir durumda işte konuştuk.
Dedik bir daha böyle olmaması için ne yapmamız lazım?
İşte QA tarafındaki arkadaş işte belli durumlarda kritik geliştirmelerde sıfırdan satıcıyı da deniyor.
Yeni satıcıyı da deniyor.
Öyle çıkıyor. Mesela böyle bir aksiyon maddesi çıktı.
Biz de böyle bir şey sıkıntı olmasın.
Canlıya çıktığında en azından haberimiz olabilsin diye spesifik bu exception'ı yakalayıp ilgili logonu basıp bunun alertini tanımladık.
Genelde öyle ilerliyor.
İlk başta Incident'ı yapıyoruz.
Bunun üzerine bir daha ne yaparsak bir daha yaşamayız diye ilerliyoruz genelde.
Yani galiba programın sonuna geldiğimiz şu anlarda.
Çok teşekkür ediyoruz öncelikle programımıza katıldığınız için Merve ve Semih.
Biz teşekkür ederiz.
Teşekkür ederiz. Tabii ama programı kapamadan önce bildiğiniz gibi burada bir geleneğimiz var.
Bir göreneğimiz var. Buna uymak zorundayız.
Merve'nin de daha önce söz verdiği gibi önce hangi şarkıyı söyleyeceğini bizle paylaşabilirsen ve sonra da şarkıya giriş yaparsan çok teşekkür ederiz.
Evet, yayından önce hatta böyle bazı şey yapmıştım, biraz söylemiştim.
Bir kubbe söylemiştin hatta.
Ay yapmayın böyle şeyler.
Söz vermemişimdir ben.
Söz değilse bir de bir anlaşma.
Bir de sana söz verelim o zaman.
Milyonlarca kişi bizi dinliyor şu an.
Ya ama şu an aklımda hiçbir şey yok ya.
Kıpkırmızı oldum sizin yüzünüzde.
Kıpkırmızı, kıpkırmızı.
Neyi değiştirdim burada?
Ya bunu Semih'e de öğrendiniz bu arada.
Semih'in de sesi güzele benziyor çünkü.
Yok abi benim sesim kalın baksana ya.
O zaman Burak abi için bir şeyler.
Black Metal'den.
Aynen. Söylerseniz yancı oluruz ama.
Fırat o zaman ben söyle bari söz vermiştim.
Kimse söylemezse ben söylerim demiştim.
Biz zamanı çok söyledik.
Artık konukları bırakıyoruz.
O yüzden kusura bakmayın.
Gidiyorum. Ya ayrıldı.
Denedik ama olmadı.
En azından denedik Fırat.
Üzülme. Üzüldüm ya.
Fırat özellikle şey yazdı da ben bırakacağım galiba programı yazdı Merve ama neyse.
Bir sonraki programı olsun.
Bende şu product çok.
Başka bir şey. Başka domine içinde.
Sonraki program sadece şarkı söylemeye.
Aynen şarkı söylemeye.
Merve'ye özel bir bölüm sadece şarkı yayını yapamadık.
Aynen. Nasıl hiç dinlenmedi.
Orkestre kurarız gerçekten.
Piyano var, gitar var.
Bir davul eksik yani. Bayağı bir trend ol şeyinde.
Teknolojide müzikle uğraşan insan var.
Evet en uğraşmayan iki kişiyi konu kaldınız.
Bu da sizin şanssızlığınız.
Yok be ben eskiden bas gitar çalıyordum Merve.
Hadi be. Aynı zamanda solistsin değil mi?
Yok abi o değil. Neyse o zaman kapatalım programı.
Kapatalım. Tekrar teşekkürler geldiğiniz için.
Teşekkürler. Teşekkür ederiz.
Teşekkür ederiz sizi ağırladığınız için.
Bu transkript otomatik olarak çıkarıldı; kayıtla küçük farklar olabilir.
