Konuklar: İsmail Hakkı Tekin, Mesut Özbaş
74. bölümümüzde konuğumuz SRE 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 Browsing ekibinden Cengiz.
Teknoloji ekiplerini tanıdığımız ve süreçler, teknolojiler gibi konuları konuştuğumuz Selam Ekip Podcast serisinin 74.
bölümündeyiz. Ve 74.
bölümde SRE ekibiyle beraberiz.
SRE ekibini tanıyıp kullanılan teknolojiler, ekip yapısı, pratikler gibi konuları konuşacağız.
Heyecanlıyız SRE ekibini konuka aldığımız için.
Arkadaşlar hoş geldiniz. Hoş bulduk.
Selamlar Cengiz. Hoş bulduk.
Valla şahsen ben bayağı mutlu oldum sizle birlikte bölüm yaptığımızda.
Çünkü şu an açıkçası Trendyol'un en kilit ekiplerinden biriyle bölüm kaydediyoruz.
Çünkü her hafta artık bizim incidentlarımızda ya da işte sistemle alakalı diğer durumlarımızda yani reliability ile alakalı her şey sizinle alakalı.
Hele ki bu sene bizim için de ana hedefimiz bu olduğu için kilit bir rolde oynadığınızı düşünüyorum.
Birçok konudan konuşacağız zaten ama öncelikle kendinizi tanıtabilir misiniz?
Ben başlayayım. Selamlar tekrardan.
Ben İsmail Hakkı Tekin.
Yaklaşık 6,5 senedir Trendyol'a çalışıyorum.
Belirli bir kısmını Cengiz'in de daha önce çalışmış olduğu Storefront ekiplerinde çalıştım.
Büyük bir kısmı. Daha sonra yine Storefront için de SFX ekibindeydim.
Yaklaşık 3 sene kadar orada devam ettim.
Son 1-1,5 senedir de Mesut'la beraber SR ekibindeyiz.
Tüm bu süreçleri anlayıp ilerletmeye çalışıyoruz diyebilirim.
Ben Yüreğim. Selamlar.
Ben de Mesut. Benim 5 sene olmak üzere neredeyse Traniyol'da.
Girdiğim zamandan beri ismi deyse de işte SRE, DevOps, platform, benzer işlerde belli bir seviyede transition vardı.
Çalışıyorum. Öncesinde farklı fintech firmaları, edtech firmaları ve e-commerce firmalarında görev aldım.
Ne benzer konularda. Sadece farklı önceliklerdi.
Ben de böyle. Selamlar herkese tekrardan.
Süper. Tekrar hoş geldiniz.
Aslında şeyi söylemek lazım, SRE 2000'deki arkadaşlar genellikle deneyimli, background'ı yüksek arkadaşlar.
Çünkü bizim için SRE tarafı kilit bir rol oynuyor daha önce de söylediğim gibi.
Dolayısıyla içerideki arkadaşlar tüm süreçlere hakim olan oldukça donanımlı arkadaşlar.
Tekrar hoş geldiniz diyeyim.
Şimdi SRE tarafıyla önce başlayalım.
Aslında SRE işte...
Bir kısaltma ve işte uzun hali side reliability engineering, side reliability engineer ya da yapan kişiye.
Peki SRE kimdir, ne yapar diye başlayalım isterseniz.
Şöyle aslında SRE dediğimiz kavram 2003 yılında Google tarafından foundedilen bir alan.
Mantığı da tamamen yaşanılan problemleri ortadan kaldırabilecek bir ekip bulabilmek ve aynı zamanda Development ekipleriyle sistem ekipleri arasında bir köprü görevi kurabilmek.
Aslında biz DevOps dediğimiz şeyden daha önce bulunan, DevOps dediğimiz bir kültür, SRE dediğimiz bir title, foundedilen bir ekip gibi.
Fakat sektördeki tüm şirketlerin neredeyse SRE'yi algılamış şekli farklılık gösterebiliyor.
İhtiyaçlarından ve büyüklüğüne göre diyebilirim.
Onun dışında biz...
Ne yapıyoruz? Bizim çalışma düzenimiz nasıl?
Biz şu anda SRE'de yaklaşık 6 kişiyiz.
7 diyebiliriz hatta.
7 kişiyiz. Ve Trendyol'un reliability konseptlerine destek olmaya çalışıyoruz.
Aslında baktığımız zaman eski de bir pratik ama birçok şirkette daha yeni yeni oturan bir süreç.
Peki... Sizin tarafta, Eseri tarafında biraz ekipten bahsedecek olursak ve çalıştığınız işlerden bahsedecek olursak yani neler üzerine çalışıyorsunuz ve ekip çalışma düzeni nasıl ilerliyor
sizin tarafta? Çalışma düzenimizden bahsedecek olursak bir, bizde ciddi bir nöbet on-call düzeni var.
Bu on-call düzeni aslında gün içerisinde veya mesai saatleri dışarısında tren yolda yaşanılan herhangi bir...
müşteri related incident'ı yani müşteriyi etkileyen herhangi bir incident'ta incident kanalında hazır ve nazır bulunan.
Diğeri geldiğinde incident commander dediğimiz birazdan İsmail'le üzerinde bahseder.
Incident commander dediğimiz rolle beraber incident'ı yöneten kişilerden oluşuyor ağırlıklı olarak.
Çalışma düzenimiz biraz proaktif, biraz reaktif.
Neden proaktif ve reaktif?
Üzerinde çalıştığımız projeler var.
Projeleri birazcık daha defans diye nitelendiriyoruz.
daha çok bir problemi bulan, observability kapsamında bulunan veya problemin çözüm sürecini hızlandırabilecek bize data sağlayan ürünlerden oluşuyor.
Reactive dediğimiz noktada da incident gerçekleştikten sonra incident'ın hızlı bir şekilde sonuca ulaştırılması, müthiye edilmesi ve daha sonrasında bu incident sonrası yaklaşımları
da ilerlettiğimiz post-mortem ve reliable preview session'lar ve warm-up'lar denetelendireceğimiz.
bazı süreçleri yürütüyor diyebilirim.
Ben de biraz aslında neler üstünde çalışıyoruz, ondan bahsedeyim.
Aslında Mesut'un bahsettiği gibi burada temelde 3 farklı noktayı ele alıyoruz gibi düşünebiliriz.
Bir incident öncesi, bir incident süreci ve incident sonrası kısımlar.
Burada incident öncesi kısım için bizim için en önemli olan kısım aslında observability.
Bir problemi hızlıca görebilmek, anlayabilmek, gerekli metriklere ulaşabilmek.
Bunun üstünde çalıştığımız...
Takip edebilirsiniz Pandora üzerine bir dashboard projemiz var.
Çoğunlukla bütün aslında ortak paydayı orada toplamaya çalışıyoruz.
Nedir bunlar? Kritik business metrikleri olabilir bizim için işte bir sipariş sayısında düşüş var mı?
Belirli key sayfalarda, trafikte hata var mı, sorun var mı gibisinden.
Bir diğer kısmı bizim için önemlisi KBT dediğimiz Key Business Transaction'lar.
Bu Key Business Transaction'lar da aslında bizim temeldeki amacımız bu zamana kadar zaten az çok deneyimlemişsinizdir.
Instant'lar böyle daha çok. Birinin fark etmesi, birinin bir bayrak kaldırmasıyla ortaya çıkan süreçler.
Bunu biraz daha nasıl hem otomatize edebiliriz hem de trend yolu olarak kendi business'ımıza nasıl bir hedef koyabiliriz?
Aslında KBT'nin temel amacı biraz daha o.
Burada SLO dediğimiz Service Level Objective konusu devreye giriyor.
Biz aslında business ekiplere diyoruz ki biz bu bu bu kritik feature'lar için size bu kadar uptime'da bulunma, bu kadar reliable çalışma sözü veriyoruz gibisinden.
Buradaki k-beta da aslında bunun ölçümünü sağlıyor ve buradaki düşüşlere vs.
göre bize tepki verebiliyoruz.
Genel olarak bunları takip ediyoruz pre-incident diyebileceğim kısımlarda.
Onun dışında ekstra böyle dediğim gibi işte farklı metrik dashboardları olabilir.
Farklı alert tanımlamaları, anomali tanımlamaları vesaire gibi.
Bunlar üzerine daha çok yoğunlaşıyoruz.
Bunun bir de instant süreci kısmı var.
Burada aslında şu an için genelde herkesin hakim olduğu işte bir alert kanalı düştükten sonra hızlıca bir toparlanma süreci başlıyor.
Burada da bizim için en değerli kısımlardan bir tanesi instant commanderlar.
Instant commanderların aslında...
Tüm temel amacı, tek amacı hatta diyebiliriz.
Bir instant sürecindeki koordinasyonu sağlamak.
Burada bazen kafa karışıklığı olabiliyor.
İşte bir instant commander geliyor, bazı şeyler sorabiliyor, bazı şeyler isteyebiliyor veya yönlendirebiliyor.
Ama instant commander burada daha çok aslında biz doğru soruna nasıl odaklanabiliriz, çözüme en hızlı nasıl ulaşabiliriz ve doğru kişileri nasıl aslında dahil edebiliriz.
Çünkü bir instantta şu da çok mümkün.
Alakalı alakasız 100 kişi, 200 kişi bir anda odaya doluşuyor.
Çok yaşanan bir durum daha öncesinde.
Ve her kafadan bir ses çıkıyor aslında.
Temelde bunun önüne geçmek, o instant sürecini tamamen fokus olarak ilerletebilmek.
Instant Commander bazen burada sanki sorun çözmeli gibi şeyler de anlaşılabiliyor ama aslında tek amacı oradaki koordinasyonu sağlamak.
Instant Commander'dan beklentimiz doğru kişileri buraya getirebilmesi.
Bu süreçte de ekstra çalıştığımız bir proje daha var.
Henüz live olmadı ama daha çok bu koordinasyon daha da fokus olabilecek.
Belki deneyimlemişsinizdir, bir instantta bizim böyle bir excel sheetimiz oluyor.
Kim ne yaptı abi, burada ne yaptı?
Nereye müdahale ettin? Sen ne yazdın, ne konuştun?
Bu odada ne dönüyor? Birçok oda oluşabiliyor büyük instantlarda.
Bunu daha ortak bir paydaya toplanmak için uğraştığımız bir proje var.
Bir de bunun sonrasında işte instant bitti, her şey okey.
Bunun sonrasında ne yapabiliriz?
Burada da daha çok aslında bizim post-mortem review'lar devreye giriyor, root cause analizler devreye giriyor.
Daha sonrasında yaptığımız aylık instant meetingleri, ekiplerin tribe level'ına kendi yaptıkları warm meetingleri gibi konular.
Burada da temel amaç aslında bir...
Incident'tan aslında bir sorumlu vesaire bulmak gibi değil ama bir incident'ı neden yaşadık, nasıl yaşamayabiliriz, daha iyi nasıl hale getirebiliriz bu aksiyonları konuşmak üzerine.
Aslında üç fokusumuz böyle diyebiliriz çalıştığımız kısımlarda.
Burada da farklı farklı yardımcı tool'lar kullanabiliyoruz.
İşte intelligent alerting var bize destek veriyor bir anda burada sıkıntı var diyor.
Metric dashboard'u konuyu daha işte troubleshooting uygulaması yeni yayına çıktı.
Hani biz o... kısımdaki sorun yaşadığımız yerler bu VM olabilir, uygulama olabilir.
Hızlıca nasıl toparlayabiliriz?
Bunun üstüne çalışıyoruz.
Valla süper. Yani aslında baktığımız zaman eseri tarafı öncelikli olarak incident olmak üzere incidentten öncesi ve sonrasında süreç içerisinde bulunabilecek ve sonrasında hızlı bir şekilde
müdahale edip İşte related takım kimse onunla iletişime geçme ve bu problemin hızlıca çözülmesini sağlamak koordinasyonu gibi birçok aslında sorumluluğu var.
Daha önce de bahsettiğimiz gibi oldukça kilit bir rol ve artık bütün şirketlerde bu reliable süreçlerde çeşitli incidentlar yaşanabiliyor.
Aslında şey de çok değerli, onu da sormak istiyorum.
Bir şey yaşanıyor fakat bizim aslında yaşanmasından ziyade biz bunu bir daha nasıl yaşamayız diye.
düşündüğümüz genellikle oluyor.
Genellikle biz bunu düşünüyoruz.
Eseri tarafında, onu da sormak istiyorum.
Eseri tarafında bunu bir daha nasıl yaşamayız diye yaptığınız POC'ler ya da herhangi bir projeler oluyor mu?
Burada şöyle söyleyebilirim.
Dediğim gibi bu arada bir incident'ın problem olmasından bir fırsata geçiş tamamen bu soruyu sormakla başlıyor.
Çünkü her yaşadığımız problem bizim için teknik anlamda kendimizi geliştirebilmemiz için bir yol sunuyor.
Bunu kullanabildiğimiz senaryoda gerçekten işte daha reliable ve daha resilient servisler geliştirme ve platformlar geliştirme yoluna adımlar atabiliyoruz.
Bunlar için POC'lerimiz oluyor mu?
Kesinlikle oluyor. Birazdan hani instant hikayelerinden vesaire de bahsettiğimizde yaşadığımız instantların sonucunda nasıl büyük kararlar alındığı ve bu kararların ilerletildiği konusunda da
birazcık değineceğiz.
Ama günün sonunda şu yaklaşım gerçekten çok önemli.
Incident utanılacak veya üzülecek bir şey değil.
Tamamen bu incident'ın sonucunda bir ders çıkardığımızda bizi teknik ve kültürel anlamda daha da ileri götürebilecek fırsatlar taşıyor.
Şundan da biraz bahsetmek gerekebilir.
Mesela ne aksiyon alıyoruz aslında?
Mesela Haziran ayında bir Equinix incident olmuştu belki hatırlarsınız.
Data Center'da elektrik kesintisi yaşandı ve bir anda birçok servise, birçok...
uygulamaya erişemez olduk.
Onun sonrasında mesela bu kaos test uygulaması aslında aksiyona başladı.
Biz aslında multi AZ dediğimiz kavrama tam anlamıyla yapamamışız.
Onu fark ettik. Hani yıllardır konuştuğumuz bir konu.
Bunu daha nasıl mitig edebiliriz?
Bunun için mesela kaos test süreci başladı.
Geçen Ocak ayının Şubat ayında.
Bunun ilkini yaptık mesela. Birçok ekip katıldı.
Yaklaşık 150 kişilik bir toplantıydı.
Ve herkes çok memnun kaldı mesela.
Aslında burada biraz o açıdan da bakmak lazım.
Çok büyük bir incident oldu ama kimse bir Şey arayışına girmedik aslında böyle ne bileyim.
Günah keçisi arama gibi bir duruma değil ama nasıl sorunları anlayıp çözebiliriz.
Kaos Test mesela bunun çok güzel bir örneği oldu.
Ve o kadar güzel yönetildik. Gerçekten buradan Serkan ve Gökhan'a da tekrar teşekkür etmek istiyorum.
Yani herkes, benim hayatımda ilk defa gerçekten iyi ki katıldık.
Gecenin bir yarısı bu toplantıya dediği bir sonuç çıktı ortaya.
Kesinlikle katılıyorum. Yani Kaos Test bizim de takım olarak, trap olarak çok...
Hoşumuza giden dikkat ettiğimiz bir şey oldu, test oldu.
İkincisini hatta dört gözle bekliyoruz.
Kesinlikle çok değerli.
Hani burada yaptığımız işler, herkesin en ufak bir şeyi bile yani en ufak bir eforu bile burada aslında çok büyük etki yaratıyor, fayda yaratıyor reliability konusunda
diyebiliriz bence. Süper.
İnsanın tarafına geçmeden önce bir de şeyi sormak istiyorum ben.
Ekipler genel anlamda SRE ile nasıl iletişime geçebilir?
Şöyle bir problem varsa instant niteliğinde siz iletişime geçmeden biz sizi buluruz diyebilirim.
Çünkü observable tool'larımız mümkün olduğunca gelişmiş bir seviyede.
Anomali detection'lar olsun.
yaşanan işte problemler olsun, business'a etkileyen vs.
Bu tarz konularda gerçekten işte biz birazcık proaktif yaklaşmaya çalışıyoruz.
İşte sizin tarafınızda herhangi bir problem yaşandığından haberiniz daha iyi olmasa, haberiniz olmasa daha iyi.
Observability tool'larımızla bunu yakalıyorsak çok iyi biz şey yapıyoruz.
Yakalayamıyorsak her zaman için bizim internal QA platformumuz olan bir Stack Overflow vari bir uygulama olan Pandora QA'dan her zaman eseri space altından
bize istediğiniz zaman istediğiniz soruyu sorabilir.
İstediğiniz konuda danışabilirsiniz.
Yani şey mi diyoruz Mesut?
Siz daha bir problem olduğunu fark etmeden biz sizi görmüş oluruz.
Çok yaşanıyor bu arada.
Çalıştığımız sistemler ne kadar iyi de kurgulasan aslında.
Hataya çok açık yerler. Her zaman öyle olacak.
Çoğu zaman işte container ekibi de bu konuda proaktif.
Bir cluster sorun oluyor.
Hemen hızlıca nodları taşıma, nodu arttırma vesaire gibi.
İşte bizim resource yetersiz konusunda mesela alertlerimiz var.
Baktık ki bu cluster, bu database gidiyor abi.
Gitmek üzere yani. Ramak kaldı.
Hemen hızlıca müdahale edip aslında bir insanta yol açmadan müdahaletimiz çok oluyor.
Ama asıl eklemek istediğim hani QA platformı zaten herkes çok iyi kullanıyor.
Çok yaygınlaşmış bu konu.
Ama genel deneyimlediğimiz sıkıntılardan bir tanesi bu iletişim konusunda.
Mesai saatleri dışında on-call SRI'ye ulaşmakta bazen zorluk yaşanabiliyor.
Bunun da temel sebebi aslında benim çok yaşadığım mesela.
Slack'ta biliyorsunuz saat 8'den sonra notifikasyonlar kapanıyor otomatik.
Rahatsız etme moduna geçiyor.
Ve kanaldan veya özelden çok fazla mesaj gelebiliyor ani bir sıkıntıyla alakalı.
Biz de bunu göremeyebiliyoruz.
Çünkü Slack'ı sürekli kontrol etmediğimiz için.
Burada hani... Eğer çok kritikse mesela içi de olsa dışı da olsa fark etmez.
Direkt aramalarını tavsiye ediyorum herkese.
Oncall platformundan o günkü nöbetçi kimse.
Veya zaten Slack'te herkesin numarası var.
Bazen insanlar spesifik kişilerle konuşmaya da çekinebiliyorlar.
Mesela beni iyi tanıyorsan direkt beni arayabilirsin.
Doğrudan arama burada çok daha iyi bir yöntem.
Gerçekten kritik bir noktada olduğumuzu düşünüyorsak.
Çok kritik değilse de yine orada zaten QA platformu vesaire günlük sıkı takip ettiğimiz bir yer.
Gün içinde veya gün dışında denk geldikçe oradan da devam edebiliriz.
Süper. Buradan yeri gelmişken İsmail Hakkı'nın telefon numarasını da paylaşalım.
0507 Paylaş abi.
Yani aslında evet kritik anlarda iletişim çok büyük bir problem olabiliyor.
Yani bizim de yaşadığımız böyle.
Bu konuda size, trafik ekibine, konteyner ekibine vesaire de ayrı teşekkür etmek lazım.
Kişisel olarak da teşekkür ederim.
Çünkü ne zaman bir problem yaşasak, ne zaman bir acil bir problem, acil bir durum olduğu zaman çok hızlı bir biçimde ulaşabiliyoruz.
Ve hemen... Problemi çözebiliyoruz.
Ayrıca TBP ekibine de teşekkür etmiş olayım buradan.
Çünkü bu oldukça kritik yani biz hani gerek client tarafta gerek işte servis taraflarına vesaire belki fark edemiyor olabiliriz ama hani işte bu değirmenin büyük dişlilerinden birisi de aslında
işte SRE, Trafik, TBP vesaire tarafı.
Dolayısıyla buradaki iletişim de oldukça önemli dediğiniz gibi.
Süper. Şimdi ufaktan artık incident taraflarına geçelim.
Her zaten ekiple konuştuğumuz bir konu ama sizinle konuşması ayrı keyifli olacak şu an.
Çünkü direkt olarak aslında main topiclerden biri uğraştığımız incident tarafı.
Şeyle başlayalım. Incident süreçleri sizin tarafta nasıl ilerliyor?
Yani siz ekiplerin bu süreci bakışlarını nasıl değerlendiriyorsunuz?
Şöyle bahsedebilirim.
Incident süreçleri aslında bizim için yine...
Çok gün içinde devam eden bir süreç sürekli her an.
Bir instant olmasa dahi sürekli devam eden bir süreç.
Buradaki temel giriş noktamız zaten bir instant kaydı öncelikle.
Bakıyoruz bir instant var.
Öncelikle burada ne olduğunu anlamaya çalışıyoruz.
Burada da şu devreye giriyor.
Ekiplerden ricalarından bir tanesi.
Bazen bir instant olduğu noktada doğrudan bir instant kaydı açılmayabiliyor.
Biz dışarıdan konuya dahil olduğumuz için çoğu zaman, otomatik instantlarda bu çok problem değil ama bir ekibin yaşadığı spesifik bir konuda dışarıdan dahil olduğumuz için o aradaki communication, sen abi buraya
gel, ben geldim, Zoom'da bana bir özet geçin falan filan.
Bunlar hem konuyu dağıtabiliyor hem de o sırada erişemedin, ulaşamadın, o geldi, bu gelmedi vs.
konuları biraz süreci yavaşlatabiliyor.
Aslında bizim için buradaki kritik nokta bir incident'ın olduğu an itibaren kaydı olması.
Ne yaşıyoruz? Kısa bir özet.
Çok burada detaya gerek yok. Ekipler bazen buna çekinebiliyor.
İşte çok büyük bir sorun var abi ben bununla mı uğraşacağım gibisinden.
Bir nevi haklı olsa bile aslında uzun vadede o prosesin daha sağlıklı akabilmesi için bu çok önemli bir anlam taşıyor.
En önemli şey bizim için bu. Biz aslında gün içinde de bir incident yoksa bile geçmiş incident kayıtlarını işte hem bir aylık yaptığımız bütün ekiplerle bir süreç var hem de bizim kendi içimizde yaptığımız ayrı bir süreç daha var.
Buradan instant kayıtlarını inceleyip aslında düzenli aralıklarla işte son bir ayda ne kadar instant yaşamışız, bu instantlar neden yaşanmış, nelerle çözebilirdik.
Aslında bu kaos test konusu işte multi-AZ konusu, kaneri konusu mesela herkesin takvimine göre aslında hep bu analizlerden ortaya çıkıyor.
Tek tek bakıyoruz orada biraz daha önce bunu Gökhan Karadaş ile Emre yapmıştı mesela hani tek tek gerçekten bu instant neyle çözülebilir abi biz burada ne yapabiliriz.
kalıcı bir aksiyon olarak. Bazen bu şekilde ilerliyoruz.
Bazen AI yardımı aldığımız oluyor.
Daha çok ve uzun bir liste varsa.
Ama genelde en nihayetinde herkesin tek tek bu konuyu bakıp tartıştığı, bu insansız neden olabilir, neden olmuş, nasıl çözülebilir konuları devreye giriyor.
Onun sonrasında da biz ekiplerle İşte bu baktık bir incident var.
Bu incident'ın çıktısı da bu.
Bu çıktıyı nasıl takip edebiliriz aslında?
En kritik nokta aslında demin bahsettiğimiz bir incident aslında bizim için kötü bir olay gibi bakmaktan ziyade.
Buradan nasıl iyi bir yola gidebiliriz?
Nasıl bir aksiyon çıkarabiliriz?
Bu aksiyonları aslında dokümente etmeye çalışıyoruz.
Bu kısım için de hem otomatikleştirmek için çalışmalar var zaten hem de şu an için biraz daha inisiyatifle ilerliyor.
Bizim ekibin almış olduğu bir inisiyatifle daha çok farklı bir board üzerine takip ediyoruz.
Bunu ekiplerin kendi boardlarına nasıl yerleştirebiliriz?
Oradan da beraber sync olabiliriz.
Üzerine uğraştığımız bir konu.
Ekiplerin bakış açısına gelirsek burada aslında.
Trendyol'da bu kültürel bir shift haline geldi aslında instant konuları.
2024'ün başına kadar çok gündem alan bir konu değildi.
Genelde bir sorun varsa hemen ilgili ilgilisiz herkes merak eden toplanıyordu.
Sorunu bir şekilde çözmeye çalışıyordu.
2024'den itibaren biraz daha bunu nasıl daha düzenli böyle daha kayıt altına alabiliriz süreci başladı.
Ekiplerin bu süreci adaptasyonunda zorluklar olabiliyor.
Bizim de oldu aynı şekilde. Her şeyi doğru değerlendiremeyebiliyoruz.
Ekipler de bunu yapabiliyor. Buradaki en kritik nokta yine instant commanderların buradaki rolünü kullanabilmek.
Instant commanderlar yine orada zaten instant sürecinde size destek için var.
Bu instantın temel sebebi veya responder ekibi bu instantın gerçekten prioritisi olabilir.
Çok sık yaşanan konulardan bir tanesi.
Bir instantın prioritisi ne olmalı?
Ekipler bazı konularda bu benim için çok önemli deyip pay bir instant açabiliyor.
Ama overall picture'da daha farklı bir priorityye sahip olabilir.
Bu konular biraz daha kritik.
Burada bizim bazı yanlış aldığımız aksiyonlar da var gelişme konusunda.
Geçenlerde Zach Bitanoğlu'da instant countlardan vs.
bahsedince bir anda herkesin roadmap'ine girdi ama çok aslında yanlış bir bakış açısı durumuna düşmüş oldu.
Çünkü dediğimiz gibi instant sayısı veya kimin ne instant yaptığı çok bizim için kritik anlam ifade etmiyor.
Bu instantların sebepleri ve nasıl daha iyi çözülebilir?
Oradan tekrar hatırlatmış olayım.
İnstant sayısını lütfen bir hedef olarak almayın.
Oradaki temel amaç bir hedef olacaksa biz instant aksiyonlarını ne düzeyde ilerletebiliyoruz?
Daha değerli bir hedef çünkü instant yaşamamaktansa bu şeye de sebebiyet verebiliyor.
Ekipler mesela çok sık instant yaşadı.
Biraz çekinip bu sefer kayıt açmaktan çekinebilirler.
İnsan psikolojisi olabilir. Hani bu tip durumlara düşmemek için, gerçekten şeffaf ilerleyebilmesi için sürecin.
Hani instant sayısına odaklanmaktan ziyade aldığımız aksiyonlara, çözümlere, sistemi nasıl daha iyi hale getirebiliriz buna odaklanmak gerekiyor.
Ekiplerin bence şu an yaşadığı bu geçiş sürecinde kültürel şifredeki en kritik konuların bir tanesi bu.
Benim gözlemlediğim. Belki Mesut senin eklemek istediğin bir şey var mı?
Farklı benim bahsetmediğim. Ağzına sağlık.
Şöyle en kritik noktalardan bir tanesi gerçekten eseri ekibi bir gatekeeper değil.
Incident hesap sorulan bir şey değil.
Bazı ekipler defansif yaklaşabiliyor bizim ilerlettiğimiz süreçlere.
Ama günün sonunda aslında herkesin ortak kabul etmesi gereken bir gerçek var.
Problem hepimizin problemi üzerinde hepimiz çalışıyoruz.
Aslında amacımız, hedefimiz benzer doğrultuda ilerliyor.
O sebeple daha...
Defansif yaklaşmak yerine aslında collaboration'a açık olduğumuz zaman bu süreçleri daha smooth bir şekilde ilerletebiliriz.
Kesinlikle katılıyorum.
Şey konusunda da özellikle ayrıyeten katılıyorum.
Bu ekiplerin işte incident açarken, incident kaydı açarken vesaire işte incident'ın önemini belirtme konusunda.
Çünkü mesela bizim ekipte de şey olabiliyor mesela bir incident yaşandı ve işte RCA kaydı açılacak.
Bazen şeyin pazarlığına girebiliyoruz.
Ya bunun skopu çok yüksek değil.
İşte bunu P3 yapabiliriz, P4 yapabiliriz falan pazarlığına girilebiliyor.
Ve birçok ekipte incident count'u zaten düşürmek artık bir KPI hedefi.
Fakat sen de dediğin gibi bu aslında bir hedeften ziyade bir kültür haline gelmesi de gerekiyor bir yandan.
Herkesin zaten bu bakış açısıyla işlerini yapı ilerletiyor olması lazım.
Valla birçok konuda açık.
bir şekilde. Benim de böyle farklı düşündüğüm noktalar vardı.
Onları aydınlattınız gerçekten.
Çok iyi oldu bu soru. Teşekkür ediyorum öncelikle.
Aslında incident sayısı dediğim gibi hedef değil ama bizim için farklı diğer metrikler var.
Biraz daha aslında onlar önem arz etmeye başladı.
Bir incident'a ne kadar hızlı tepki verebiliyoruz?
Bu incident'ı ne kadar hızlı anlayabiliyoruz ve çözüme ulaştırabiliyoruz?
Buradaki aslında kritik nokta biraz daha bunlar.
Biz çok fazla incident yaşayıp bu incident'lara çok hızlı çözüme ulaştırıyoruzdur.
Etkisini çok Anlamlı bir şekilde düşürebiliyoruzdur.
Kullanıcı hiç fark etmiyordur veya çok minimalca da fark ediyordur.
Bu seviyeye geldiğimiz zaman instant sayısı 1000 olmuş, 1 milyon olmuş çok aslında önemli değil.
Burada da aslında yine şeye denk geleceğim.
Ekipler bazen scope dışına çıkabiliyor instant sürecinde işte.
Sorunu bulduk hadi bir de çözelim.
Çözümünü nasıl daha iyi yapabiliriz vesaire konularına.
Aslında instant'taki temel amaç her zaman instant'ı anladın.
Ne kadar hızlı etkisini...
Hani orada mükemmel bir şekilde bir çözümü ulaştırmak kritik değil.
Aslında bir yangın var. Yangını nasıl hızlı söndürebiliriz?
Yangını söndürdükten sonra alacağımız aksiyonlara daha rahat odaklanabilelim.
Çünkü o çözülmediği her an ekstra bir stres.
Hem bizim üstümüzde hem oradaki bizimle beraber Zoom'da çalışan arkadaşlarla aynı şekilde.
Hani ne kadar hızlı etkiyi azaltırsak ondan sonra rahat rahat istersek bir gün, üç gün, beş gün.
Duruma göre bir hafta, iki ay böyle şeyler de çıkabilir.
Gerçekten aksiyonlar uzun süreli.
Bunlara odaklanmak daha rahat olur.
Kesinlikle katılıyorum. Süper.
Okey. Diğer soruya geçerim isterseniz.
Ben incident tarafından devam etmek istiyorum.
Şimdi birçok ekibe de zaten sorduğumuz soru var.
Burada da aslında sizden direkt konusu incidentlarla alakalı olan ekip olduğumuz için.
şekilde bunu sormak istiyorum.
Genellikle biz ekiplere yaşadığınız en komik incident anısı nedir?
İşte böyle komik bir anınız var mı diye soruyoruz.
Sizden bir komik bir de sizi besleyen öğretici bir anınız var mı diye sormak istiyorum.
Hani böyle iki örnek var mıdır verebileceğiniz?
Komik incident konusu yani tren yolu uzun süre çalışan herkesin bir şekilde başına gelip hani üzücü ama böyle gerçekten gülmeden de edemediğin durumlar olabiliyor.
Benim için bu SFX'e çalışırken başıma gelen bir olay var.
Çok teknik detay vermeyeceğim ama konsül üzerinde bir tane bir instant yaşandı.
SFX ekibinin sebebiyet verdiği.
Biz normalde şöyle bakıyoruz bu olaya.
Konsül çok temel bir yer ama biz bozduğumuz yerde sıkıntı yapabiliriz.
Sen bir sisteme bir şey entegre ediyorsun.
Senin entegre ettiğin yer bozulur.
Oralardan en fazla biraz çevresinden sıkıntı yaşarsın.
Bir gün şöyle bir instant yaşandı.
Beni bir war room'a çağırdılar.
Konsülde bir sıkıntı var. İşte böyle böyle bir şey bir gelebilir misin diye.
Ben de girdim. Orada bir tane depo tarafında çalışan bir arkadaş vardı.
Şöyle bir çıkış yaptı. Arkadaşlar dedi.
Bu insansı çok büyük. Depoda şu an bütün operasyonlar durdu.
Oradaki çalışan kişiler kutu taşıyamıyorlar.
Hepsi araya çıktı ve geri getirmekte zorlanıyoruz.
Bunu bir an önce çözmemiz lazım diye.
Ben o sıra buna çok fazla güldüm.
Yani çünkü hani dedim ki depo tarafıyla ben ne alaka yani.
Hani konsülün depo tarafıyla ne alakası var vesaire gibi.
Ama çok küçük bir entegrasyon aslında oradaki.
Bizim konsülde sebebiyet verdiğimiz durumdan ötürü tren yolu paketlerin arabalara yüklenememesine sebebiyet verdi.
Aslında baktığı zaman çok büyük bir operasyonel sıkıntı.
Çok fazla geri dönüş olabilecek bir konu.
Ama o anki o şeyde ciddiyetle öyle bir geldi ki bu konu yani.
İnsanlar bu kutuları arabaya taşıyamıyor.
Ben dahil bir sürü kişi bu konuyu biraz böyle şey yapmıştı.
Şaşırma gülme arası sonra soruna odaklanmıştık.
Böyle bir anım var. Çok farklı bir tane bir şeyden daha bahsettim.
Aslında bahsetmeyecektim ama. Biraz da o da komik bulduğum bir konu.
Bu çok eskiden olan bir incident.
Ben o zaman web tarafında çalışıyordum.
Web tarafında bu şu anki dynamic config'den önce kendi çapında yaptığı bir dynamic config mekanizması vardı.
Orada bizim böyle trendi olabiliyorsunuz.
Bir tane navbar var işte. Kadın erkek altında bir sürü kategoriler vesaire açılıyor.
Bunu datasını tuttuğumuz o zaman bunun bir servisi yoktu.
Datasını tuttuğumuz çok büyük bir JSON dosyası vardı ama.
Çok büyük yani. İçinde binlerce satır.
Bunu işte business ekip, marketing ekibi kurguluyor.
Diyorlar ki bunları göstermek istiyoruz.
Biz de o JSON'ı güncelliyoruz ve yolumuza devam ediyoruz.
Burada da yine bir güncelleme sonrası orada bir formatting hatası olmuş.
İşte JSON'ı non-JSON bir formata çevirmiş.
Bir tane farklı bir editörde güncellenmiş vs.
Tırnaklar bozulmuş. Biz de bunu yapıştırırken fark etmemişiz.
O zaman bu JSON'dır vs.
değildir gibi bir şey. Her şey string yani.
Bir sıkıntı görmüyorsun. Bu navigation tarafı için de aslında bizim için kritik bir konu ama çok da değişmediği için bizim her yerde cache'imiz var.
Storefront'umuz bunu cache'lıyor.
Bunu dönen gateway cache'lıyor.
Ama cache mekanizmamız çok iyi değilmiş.
Cache gittikten sonra cache'i siliyor ve sürekli arkadan yenisini almaya çalışıyor cache'i doldurana kadar.
Bu data hatalı olduğu için bunu dönen gateway cache'i güncelleyemiyor kendi içinde.
10 dakika sonra cache'e expire oluyor.
Storefront tarafı da 30 dakika sonra diyelim cache'e expire oluyor.
Bu servisten tekrar bu datayı almaya çalışıyor.
Ama alamıyor. Alamadığı için cache'i güncelleyemiyor.
Ve bu cache'ler birbirinden farklı zamanlarda bozulduğu için storefront tarafı yavaş yavaş down olmaya başlıyor.
Biz güncellemeyi yapıyoruz.
5 dakika sonra işte birisi çıktı dedi ki ben beyaz ekran görüyorum.
Site gelmiyor. Herkes giriyor bakıyor.
Yo çalışıyor sıkıntı yok. Herkes yoluna devam ediyor.
10 dakika sonra başka birisi diyor ya bende de gelmedi.
Bu sefer 1-2 kişi daha yaşıyor ama sonra tekrar düzeliyor falan.
Bir yarım saatlik süreçte site böyle gözlerimizin önünde hani bataklığa batarsın gibi çökmüştü.
O da böyle çok... Üzülerek ama gülerek andığım bir anıdır yani.
İşte böyle ellerimde resmen gitti yani.
Yavaş yavaş. Değişik bir anda o da benim için.
Şey konusu çok acayipmiş ya böyle.
Yani düşüyor, bir şekilde gidiyor ama sen hiçbir şey yapamıyorsun.
Hani sen de çalışıyorsun.
Ya şey de mesela instant yaşadığın zaman ya da bir problem yaşadığın zaman mesela QA yazıyor.
Ya arkadaşlar şurası problemli.
Sen de çalışıyorsun bakıyorsun yol çalışıyor falan.
Ama sonra bir deneme daha yaptığın zaman oranın patladığını görünce yaşadığın mutsuzluk çok...
Şey mesela yani kötü bir şey.
Çok garipmiş gerçekten yani.
Oradan da bir pointer vermiş olayım.
Cache yaparken lütfen cache'inizi expire etmeyin.
Üstüne güncelleyin.
Buradan çıkardığım en büyük ders de budur bu arada.
Aynı zamanda öğretici de bir incident olmuş diyebilirim.
Aynen. Süper.
Mesut sende var mı abi? Komik incident olarak...
bahsedeceğim çok fazla yok ama ben şirkete girdiğimde Trendyol'a başladığımın birinci haftasında bir instant yaşatmıştım.
Birazcık hani major sayılabilecek bir instanttı.
Pim ekibini bilirsin.
Pim ekibinin Elasticsearch'larının tamamını uçurmuştum yanlış playbook kullanarak.
Ansible kullananlar varsa Ansible'ın ne kadar hataya açık olduğunu bilirler.
O zaman bir Source kontrolü de yapmıyorduk çok fazla o playbooklar tarafında.
Girdiğim birinci haftası da Pim'in tüm elastik sorçlarını uçurmuştum.
Ve daha sonrasında şey düşünmüştüm.
Bu kadar büyük bir şirkette bu kadar büyük bir ürünü daha birinci hafta patlattıysam ben bir LinkedIn'e gireyim.
Ufaktan iş bakmaya başlayayım diye düşünmüştüm.
Ama orada da tren yol kültürü gerçekten beni çok şaşırtmıştı demeyeceğim mutlu etmişti.
Evet hata yapabiliriz ama yaptığımız hatanın sonucunda ders çıkarıyor muyuz kası çok daha önemli.
Hep beraber takım olarak bu problemi çözmüştük.
Üstesinden gelmiştik.
Daha sonrasında da aynı hatada tekrarlanmayacak bir şekilde yapıyı değiştirmiştik.
Bu da tren yol kültürünün aslında yeni yeni oluşan bir şey değil de yıllardır nasıl olduğunu da gösteriyor.
Biz de şu anda bu kültürün hep beraber tüm teknoloji olarak bayrak taşıyıcıları izleyebilirim.
Çok komik değil ama bu örneği verebilirim.
Girer gülmez. Abi çok geçmiş olsun yani 5 sene geçmiş üzerinden ama yani daha dün...
Hala anlatabiliyorum. Evet ben de hissettim tekrar çok geçmiş olsun.
Eyvallah. Peki öğretici incident üzerine biraz da konuşalım.
Yani yaşadığınız böyle ve bize gerçekten Smiling Cash anısı hariç, Cash incident hariç böyle gerçekten bize iyi bir ders verdi, iyi bir öğreti verdi dediğiniz bir olay
yaşadınız mı? Burada aslında...
Eskiden beri burada olanları çok iyi hatırlayacağı çok büyük bir incident vardı zamanında.
Yanlış hatırlamıyorsam 2019 senesinin başlarındaydı.
Storage tarafında bir tane incident yaşandı.
Bu incident sonucunda VM'lerin birçoğu corrupt oldu aslında.
Geri döndürülemedi. Burada ne oldu?
Yanlış hatırlamıyorsam 12-18 saat aralığında bir süre hiçbir şey çalışmadı.
Cloudflare'den sadece böyle bir çalışıyoruz yazısı dönülmüştü yani.
Çünkü hiçbir şey çalışmıyordu. Burada da aslında sıkıntı şuradan devreye giriyor.
Hani o zamanlar bu multi-DC konusu, multi-AZ konusu hiç kimsenin aklında bile yok yani.
Herkes abi tamam data center'ım var, kendim maintain ediyorum çok iyi, süper ilerliyoruz vesaire.
Bir anda bu instant olunca bütün tren yolu gitti her şeyle beraber.
Hani hiçbir şey çalışmıyor. Hani en küçük böyle bir yanlış hatırlamıyorsam Ahmetcan'ın mobil web'e koyduğu bir cache vardı.
O zamanlar puzzle tarafında sadece mobil web çalışıyor bir şekilde yani.
Ama o da client-side çalışıyor.
Öyle bir konu. Buradan aslında çıkardığımız en büyük konu hani bu büyüklükte bir şirkette hani senin backup'ın nasıl olmaz yani gerçekten.
Biz farklı farklı tek bir data center'a yüklenmişiz ama o gidince hiçbir şey yapamıyoruz.
Buradaki en büyük çıktı aslında multi-DC konusu.
2019'da başlayan bir konu. Şu an bile hala hayatımızdaki en kritik konu.
Yine bu tarafta işte nasıl bu sisteme geçebiliriz?
Farklı farklı bu ekipler, bu dipendislerle nasıl kurtulabilir?
Her zaman konuşulan bir konu oldu ve hala da konuşulacak yani.
Şu an bile son kaos testinin temel konusu aslında buydu.
Onun dışında farklı bir öğretici nokta olarak o zamanlar VM kurulumları işte giden VM'leri tekrar kurmak için o zamanki DevOps ekibimiz bütün makineleri tek tek böyle uğraşmıştı.
İşte bu makine gitmiş hemen burada bir VM kaldırmamız gerekiyor ama bunu elle yapıyorlar ve...
Tek tek yapmak zorundalar. Bu da aslında bizim infraize kod dediğimiz yapının girmesini sağladı bir nevi.
Hani şu an nasıl biz gidiyoruz bir önce Nargo CD kullanan ekipler mesela işte bunun bir de VM tarafı var.
Terraformlarla yapılıyor. Gerçekten OpenStack'te işte ne bileyim VMware'de bir tane VM nasıl kaldırırsın?
Bir tane kodu var çalıştırıyorsun ve kalkıyor.
Eskiden bunu tek tek bir...
Hyper-VR yüzünden işte bu IP'ye bunu kuracağız, bu özellikler olacak, şu olacak, bu olacak mesela tek tek giden bir süreçti.
Bu bahsettiğim 18 saatlik sürecin işte çok büyük bir kısmı sadece bu elle VM'leri kurmak yani.
Trendyol'un yanlış hatırlamıyorsam o anki arkadaşlarımın duyduğum %60-70'lik bir kısmını sıfırdan tekrar kurmaya çalıştılar.
Burada da aslında iki temel çıktığımız işte multi-disc'li bizim için vazgeçilmez hayata önem taşıyan bir şey ve yaptığımız her şeyin bir EZ kodu olarak karşılığı olması gerekiyor ki biz bu tip durumlara tekrardan düşmeyelim aslında.
Trendyol'un temelden etkilendiği, en temel korunda bulunan mantaliteleri oluşturan insınt büyük ihtimalle budur.
Birçok ekibi en ucundan işte çok alakasız, farklı yerde çalışan bir ekipten en temeldeki eseri ekipler işte ne bileyim, search ekipleri vesaire herkesi temelden etkileyen bir insınt oldu aslında.
Çok acayip ya gerçekten yani bunu duymuştum bu insıntı.
Hatta bununla alakalı işte fotoğraflar falan da görmüştüm.
İnsanların o yüzlerindeki çaresizliği direkt olarak anlatıyordu yani her şeyi.
Gerçekten çok büyük bir incident ama yani tabii büyük şeyler, büyük felaketler aslında büyük öğretileri de doğuruyor.
Büyük işte fikirleri de doğuruyor.
Bugün bu tarz şeyleri yaşamamamızın ana nedenlerinden biri de bu incident tabii ki.
Bir de şeyi merak ediyorum ben.
Böyle öğretici incident farklı bir şey ama böyle şey dediğimiz incident hiç oldu mu?
Abi resmen direktten döndük.
patlamak üzereydik, son dakika kurtulduk falan dediğimiz bir incident oldu mu hiç yaşadığınız?
Tabii tabii. Çok güzel bir örneği var aslında bunun.
Tamamen şans eseri.
Gerçekten bir katastrofinin önüne geçilen bir incident yaşandı.
Yine benzer zamanlar. Bu arada 2018-2019 tren yolunun incident namına gerçekten prime zamanları diyebilirim.
Hatta eskiler belki bilir.
Sistem tarafının üstünde işte bir televizyon var.
Televizyonda şey muhabbeti var.
Bu şirkette x gündür incident yaşanmamıştır.
O count hiçbir zaman sıfırdan bile çıkmamıştır.
Hani o dönemler. Şöyle, yeni marketplace uygulaması var Trendyol'da o dönemlerde.
Ve marketplace aslında product datasının %80'ini barındıran bir yer gibi düşünebilirsiniz.
Trendyol'un kendi depolarından çıkan kendi ürünleri hariç tüm her şey bu marketplace'in karşı bezlerinde tutuluyor.
O kadar büyük, geniş bir ortam.
Gitti mi geçmiş olsun gibi bir durum.
Ve gerçekten gidiyor. Failover olurken ayağa kalkamıyor.
Backup'ı yok. Instance Couchbase tamamen erişilemez hale geliyor.
Bu sebepten dolayı da data tamamen uçuyor o dönemde.
Tam aynı dönemde yine o ekipten şimdi ismini tam olarak hatırlamıyorum.
Jibes'i deniyor. Jibes de bu arada Couchbase Connector gibi düşünebilirsiniz.
Jibes'i test ederken test ediyor ve bu amaçla bir backup alıyor lokaline bu Couchbase cluster'ını.
Couchbase'e işlem hızı hale gelince arkadaş çıkıyor diyor ki tamam bende backup'ı var bu backup'ı import edebilir miyiz?
deyip aslında çok büyük bir incident'ın çok büyük sonuçlarının olabileceği bir incident'ı şans eseri tamamen daha ufak bir radius'la, impact'le çözüyor.
Eğer ki o arkadaşı olmasa o dönem muhtemelen tüm satıcılardan tekrar product data'larının alınması gibi bir şey olurdu.
Yine muhtemel bir hafta ve belki iki hafta boyunca kullanılamaz bir tren yol platformu olabilirdi müşteriler tarafından.
Hatta şeyi de söyleyeyim, bunun kazanımından da bahsedeyim çok hızlı.
Bu olaydan sonra Couchbase Cluster'ların database ekibi devralıyor.
Ve bu Couchbase Cluster'ları verilirken şey olarak söyleniyor.
Bu Cluster source of truth değil, backup'ı yok.
Ona göre datanızı burada konumlandırın.
O yüzden Couchbase'e tamamen güvenmeyin şeklinde iletiliyor.
Ama bu iletişim ekipler arasında çok net bir şekilde ilerlemediği için bu problem yaşanıyor.
Daha sonrasında database ekibi bu süreci devraldığında...
Daha sonrasında backup'lar işte database'lerin backup'ları periyodik olarak alınmaya başlanıyor.
Yedekli keza yine aynı şekilde yapıya geçiliyor.
Ve işte her bir data kullanan yapının database engine'in yedekli backup'ı alınan bir yapıya geçirilmesi sağlanıyor diyebilirim.
Ondan sonra benzer bir problem yaşanmıyor zaten.
Bu inanılmaz bir şey gerçekten ya.
Yani ilk defa duydum bunu ve şok edici gerçekten.
Kurtulmaz mı? Mucize olmuş bir incident oluşmuş açıkçası.
Hani bunu bence böyle bizim kullandığımız sistemlerin girişine falan çiviyle çakmamız gerekir yani.
Bakın arkadaşlar biz böyle bir şey de yaşadık ve hayatta kaldık gibi.
Gerçekten tekrar herkese çok geçmiş olsun.
İnanılmaz büyük bir şeymiş yani.
Ama güzel kazanımlar olmuş bize.
Evet kesinlikle. Okey süper.
Şimdi yavaş yavaş sona doğru geliyoruz.
2-3 sorum daha var.
Onları da sorayım sonra ufaktan kapatalım isterseniz.
Şimdi biraz eseri yaklaşımı tarafından bir şeyler sormak istiyorum.
Şimdi bizim sektörümüz, teknoloji sektörü, yazılım sektörü, e-commerce vs.
sürekli değişen bir sektör aslında baktığımız zaman.
Bu noktada eseri tarafında bakış açısında değişimler oluyor mu?
Kesinlikle. Şöyle konuşmanın başında da bahsetmiştim.
SRE dediğimiz şeyin aslında bir handbooku, bir başucu kitabı var Google tarafından yazılan.
2003 senede ortaya çıkarıldı.
Daha sonra işte handbookları, workbookları yayınlandı ve şirketler bunu kendilerine adapte etmeye başladı.
Ama bu adaptasyon sıfırdan yüze anlık bir şekilde gerçekleşmiyor.
Çünkü her şirketin, her döneminin farklı farklı ihtiyaçları ve öncelikleri olabiliyor.
Tamamen ekip de bu önceliklere...
ve işte o anki teknoloji alt tepside bağlı olarak değişimler gösterebiliyor.
Trendyol'da da benzer bir dönem olmuştu.
Ben girdiğim dönemden itibaren olan kısımdan birazcık daha bahsedeyim.
İlk dönemlerde SRE diye bir yaklaşımı çok fazla yoktu.
DevOps tarafı vardı. Yine Instant'larla ilgileniyordu ama Embedded çalışıyordu.
Yine eskiler hatırlar.
Her tribe'ın bir DevOps'u var.
Bu DevOps kurulumlardan sorumlu.
Kurulan servislerin ayakta kalmasından sorumlu, otomasyonundan sorumlu vs.
Ama teknoloji siteyimiz genişledikçe konteks çok genişlemeye başladı.
Bu ekip yetersiz değil.
Tribe'deki bir kişi bir anda kendini, örnek veriyorum 50 tane tool'da update tutmaya çalışırken buldu.
Tribe'lar arasında farklı standartlar ortaya çıkmaya başladı.
Bu da genele yayılması gereken konuların...
yayılmasını zorlaştırdığı bir konu oldu.
Ondan sonra bizim problemimiz bu oldu.
Daha sonra merkezi bir yapıya geçelim ama merkezi bir yapıda ekiplerin sorumluluklarını kısıtlayalım.
Tribe bazlı değil, teknoloji bazlı kısıtlamaya çalışalım gibi bir modele geçmeye çalıştık.
Bu modelde de aslında birazcık daha teknoloji kırılımlarına göre daha dar skoplarda daha derin uzmanlıklar yaratabileceğimiz bir yapıya geçmeye çalıştık.
Ne yaptık? İşte cloud ürünleri kullanıyoruz.
Cloud ürünleri için bir cloud ekibi olsun.
Geliştirilmesi gereken platformlar var.
İşte platform tarafı container ve common olarak ikiye ayrılsın.
Platform tarafı kurulsun.
Eseriye hizmet edecek, ürünleri geliştirecek bir ekip olması gerekiyor.
Ve aynı zamanda işte atıyorum GitLab gibi, Argo CD gibi birazcık daha software development, lifecycle içerisinde bulunan konuları ilerleten bir ekip olsun dedik.
İşte tools ekibi foundedildi.
Service Level Management'ı konuşalım, Instant Management'ı konuşalım dedik.
Core ekibi ortaya çıktı. Ve support isteklerini karşılayacak bir ekibe de ihtiyaç var.
Enablement ekibini ortaya çıkaralım.
Bu ekibin sorumluluğu da ekiplerinin know-how'ını artırsın.
App kiplerinin operasyonlarını kendilerinin yürütebileceği bir yapıya evritelim.
Gerekirse otomasyonu iyileştirelim gibi.
Bir de Enablement ekibi ortaya çıkmıştı.
Bu bir ara dönem. Bu çok uzun süre sürmedi.
Bunun da belli başlı problemleri vardı.
Neydi? İşte bu sefer headcount artırmak da çok zorlanmaya başladı.
Çünkü çok spesifik alanlarda uzmanlaşma gerekiyordu.
Oradan da evrildiğimiz nokta birazcık daha core enablement ekibinin birleşmesi ve cloud ekibi işte hala valide cloud ekibinin kalması.
Bu ekip de bir yere kadar az önce bahsettiğim core ekibinin ve enablement ekibinin sorumluluklarını taşıyordu.
Ama O ekip içerisinde ne eksik olan bir tecrübemiz, alanımız vardı.
Ekip tamamen eski sistemcilerden, birazcık daha sistem tarafına yakın kişilerden oluşuyordu.
Burada da ekibin multidisipliner bir yapıya geçmesi ve problemlerin birden fazla pratikte daha doğru bir şekilde yorumlanabilmesi için de aslında birazcık
daha %50, %50 hatta %60...
birazcık daha development alanına kayacak şekilde developer kökenli insanları ekibe katmaya başladık.
İsmail keza bu arkadaşların başında geliyor.
İlk katılan arkadaşlardan biri olarak söyleyebilirim.
Hem tecrübe olarak bu arkadaşlar hem de bakış açısı olarak ekibe kattıklarıyla ekibin bu sefer konteksti birazcık daha değişmeye başladı.
Nedir? Platform ilk yapısı oldu.
SRE platformları ortaya çıktı.
Üzerinde bahsettiğimiz ürünleri geliştirebilmeye başladık.
observability site'imizi genişletmeye başladık.
Daha derin olarak işte operation excellence'imizi daha iyi bir noktaya getirdik.
İşte operasyonel işlerimizi azalttık.
Geliştirdiğimiz ürünlerle.
Daha sonrasında ortada sadece operasyonel iş olarak şeyler kaldı.
Performance troubleshooting ve aynı zamanda bir uygulamada yaşanan problemleri troubleshoot etme konuları kaldı.
Daha sonrasında da işte kendi platformlarımızı geliştiriyoruz.
Kalan olarak da gerçekten servis level management'ı nasıl yürütürüz, kültürel olarak bu shift'i nasıl sağlarız, nasıl defansif becerilerimizi daha iyi bir kapasiteye taşıyıp, bu defansiften
aldığımız datayı da offense diyoruz diye adlandırıyoruz.
Offense tarafında ekiplerin kendi servislerinde nelerde, nerelerde gelişim noktasına açık olduğunu visible hale getirebileceğimiz bir yapıya doğru ilerleyebildik.
Bakınca gerçekten %100 operasyon ekibinden, Daha proaktif bir development ekibine geçiş bu 5 sene içerisinde gerçekleşti diyebilirim.
Arada da bahsettiğim gibi 3-4 tane farklı model denedik.
Şu anda birazcık daha bu modelde ilerliyoruz.
Ve şu an için bakınca bu modeli değiştirmemiz için de şu an için en azından bir sebep veya ihtiyaç görünmüyor.
Süper valla. Çok iyi bir değişim yaşamış.
Çok iyi bir dönüşüm yaşamış.
Ve şu an geldiği nokta gerçekten verimli ve güzel işleyen bir.
Ben araya bir şey sıkıştırmak istiyorum.
Merak ettiğim bir konu var.
Şimdi Google tarafında genellikle bu SRE konularında on-call yaklaşımında mesela SRE tarafını bahsediyorlar orada.
Baktığımız zaman bizim şirketimizde işte Trendyol'da uyguladığımız her ekibin kendi onkolu var.
Her haftalık değişen ya da günlük değişen falan ve böyle bir modelle ilerliyoruz.
Bu model oluşturulurken biliyor musunuz hani böyle şey yapılan örnek alınan bir nokta oldu mu ya da zaten büyük şirketler de böyle mi ilerliyor bu süreç?
Hani onkol daha minimalize edilmiş daha takım bazına indirilmiş bir...
süreç midir? Google'daki model Google'da uygulanabiliyor.
Aslında o modeli devralırken ya da işte kendi şirketimize entegre etmeye çalışırken birazcık şeyi düşünmek lazım.
Google'daki engineering sayısını karşılayabiliyor muyuz?
Hayır. Oradaki kültürü birebir alıp uygulayabiliyor muyuz?
Umarım zamanla evet.
Ama onlar da şöyle bir yapı söz konusu.
Google'daki SRE'ler aslında ürünlerin SRE'leri ve birbirlerinden çok bağımsız çalışıyorlar.
Benim az önce ilk bahsettiğim bir embedded DevOps süreci vardı, zamanı vardı hatırlarsın.
Ama sadece o tribe'ın ya da o ürünün operasyonel işleriyle ilgileniyordu.
Aslında Google buna benzer çalışıyor.
Gerçekten Google'daki SRE'lerin amacı o ürün içerisinde, girdiği ürün içerisindeki operasyonel süreçleri.
iyileştirmek ve aynı zamanda instant management'la uğraşmak.
Bunun yanı sıra ekibin ihtiyaç duyacağı ürünleri geliştirmek.
Ama bu bahsettiğimiz ürünler gerçekten şey gibi ürünler.
Google bir konuda problem yaşıyor.
Diplomatlarla Borg'u geliştiriyor.
Borg dediğimiz şey de Kubernetes'in atasıdır.
Böyle ürünler geliştiriyor Google'daki eseriler.
Scala bu seviyede olduğu için ve birazcık headcount artı seviye bu seviyede olduğu için.
Onlardaki on-call yapısı bulundukları servislerdeki life cycle'a göre ilerliyor.
Bizdeki mantık birazcık daha bizim SRE sayımız çok fazla yeterli değil ve aynı zamanda product'ların %100 içerisine giremiyoruz ad count dolayısıyla.
Bu sebeple birazcık daha şey felsefesini benimsemeye çalışıyoruz şirket olarak.
You build it, you run it, you own it.
Yani nedir? Sen geliştiriyorsun, sen diplo ediyorsun, sürecinden sen sorumlusun ve ürünün sağlığından da sen sorumlusun.
gibi bir yaklaşım var.
Ama buradaki sen ürünü geliştiren değil sadece ortak bir sorumluluk ilerletmeye çalışıyoruz.
Burada da Booking.com'un ortaya çıkardığı bir Shared Responsibility modeli var.
Birazcık hani Google'ın SRE Workbook'uyla Booking'in Shared Responsibility modelini harmanlayıp ilerletmeye çalışıyoruz.
On call'daki farklılık da birazcık bundan dolayı geliyor.
SRE her zaman bir servis level management seviyesinde bir problem yaşandığında olaya hem incident commander olarak hem de subject matter export dediğimiz bir yaklaşımda
dahil oluyor. Ama yanı sıra o servis hakkında, o ürün hakkında bilgili birinin de kendi on-call rotasyonunda olması ürünün sağlıklı bir state'e geçirilirken ihtiyaç
duyduğumuz bilgiyi de sağlamasını sağladığı bir ortam yaratıyor diyebilirim.
O yüzden birazcık...
İki taraflı on-call yapısı var Google'dakine farklı olarak.
Anladım, anladım.
Pardon baştan alıyorum.
Anladım, anladım. Yani aslında bizim case'lerimizi çözecek bir yapı durumu şu an söz konusu.
Bence de mantıklı gayet.
Bence akan bir süreç ilerliyor şu an.
Son bir sorumuz var.
Ondan sonra bir soru daha soracağım.
Ama ondan önce bu eseri yaklaşımıyla alakalı son soruyu sorayım.
Trendyol'daki bu reliability süreçlerini iyileştirmek adına Ne gibi aksiyonlar alıyorsunuz?
Burada şöyle bahsedebilirim.
Zaten demin bahsettiğim aslında defansif anlamdaki ürünleri geliştirmeye devam ediyoruz.
İşte burada daha iyi nasıl görebiliriz, daha iyi nasıl alert duruma geçebiliriz vs.
Bu aslında biz bir sorun olduğuna yakalayalım kısmı için daha çok.
Bir problem var nasıl hızlı mitig edebiliriz.
Ama aslında reliability doğrudan development sürecinde başlıyor.
Bunun da aslında iki tarafı var.
Bir domain ekiplerinde yaşadığımız işte business geliştiren ekiplerde.
development kısmı bir de sistemsel taraftaki.
Sistemsel taraftaki kısım daha çok böyle çok net kuralları olabilen konular işte.
Hani Windows'u nasıl kurarsın mesela bir yolu belli zaten.
İşte database'in backup'larını nasıl oluşturursun yolu belli.
Business taraf biraz daha dinamik ilerliyor.
Dolayısıyla biz de aslında temel fokusumuzu biraz daha buraya yaymaya çalışıyoruz.
Buradaki girişimlerden bir tanesi de aslında bizim reliability review dediğimiz bir konu.
Biz aslında burada ne yapıyoruz?
Ekiplerle Belirli sırada işte farklı kriterlere göre bu ekiplerin daha önce yaşadığı problemlere bağlı olabilir.
Daha kritik gördüğümüz ekipler olabilir.
İşte KBIT yakışındaki önem arz eden ekipler olabilir.
Bu ekiplerin gerçekten production ortamları sağlıklı mı?
Bir development yaparken doğru reliability süreçlerinden önlemlerden geçiyorlar mı?
Bunları hem ekiple beraber çalışıp doğru key noktaları bulabilmek adına yaptığımız bir süreç.
Burada da aslında dediğim gibi hani biz daha...
Herhangi bir sorun olmadan bir sorun var mı veya bir sorun olma meyilli mi bunu anlamaya çalışıyoruz.
Bu çok yeni başlattığımız bir süreç.
İlkini Storefront TR PDP ekibiyle yaptık.
Parça parça aslında buradan kazandığımız deneyimlerle bunu olabildiğince çok ekibe yaymaya çalışacağız.
Buradaki en değerli noktada aslında bizim tren yolu her ekipten hemen hemen bir tane staff engineer'ımız var.
Aslında staff engineer'larımız da bu konuda kendi öğrendiklerimizle de birleştirip onları da bu konuda...
maillendirerek. Hani her ekibin aslında bu süreci bir kültürel nokta haline getirmesi.
Hani ben bir feature çıkıyorum.
Gerçekten bu kriterleri karşıladım mı?
Gibisinden. Aslında bir basitçe bir checklist gibi düşünebilirsiniz.
Bunun bir karşılığı PRR olarak geçiyor.
Production Readiness Review. Biz bunu biraz daha direkt production'a çıkmaktan ziyade hani ekibin geçmiş deneyimlerinde baz alarak işte yaşadığı instantlar olabilir.
Süre gelen farklı blokerlar olabilir.
Bunları da ele alabilmek adına biraz daha genişlettik aslında.
En temelde aldığımız şu an kritik aksiyonlar bir tanesi bu.
Onun dışında demin bahsettiğim işte bir incident oluyor.
Olup olmaması çok önemli değil ama nasıl aksiyon alabiliyoruz?
Bu konuda da yakın zamanda yine post mortem review'lara başladık.
Burada aslında daha çok P1 incident'lara ve müşteri etkisi olan incident'lara odaklanıyoruz.
Buradaki temel amaç da aslında dediğim gibi tekrar hatırlatmış olayım.
Hani bir günah keçisi bulmak veya bir ekibe sorumluluk yüklemek değil aslında bir süreci iyileştirmek amacıyla.
Burada da ne yapıyoruz aslında? Instant neden oluştu?
Biz nasıl müdahale ettik?
Neleri daha yapabiliriz? Şu an RCA analizi dediğimiz kısım, root cause analizi yaparken insanların doldurduğu belirli başlı alanlar var.
Bu alanlar aslında tam olarak root cause diye daha çok postmortem dediğimiz kavrama yakın kısımlar.
Biz bunu daha çok asenkron ilerletiyorduk bu zamana kadar.
Ekipler bu alanları dolduruyor, kendi çıktılarını.
Daha sonra instant review toplantısında konuşuluyor gibi.
Biz burada biraz daha süreci dahil olmak istedik aslında.
Instant Commander'ın o an instant'ı değerlendirirken işte müşteri etkisine, business etkisine veya systems etkisine bakarak burada bir postmortem review yapalım arkadaşlar dediği noktada başlıyor.
Şu an için her instant'a yaptığımız bir süreç değil.
Burada da daha iyi aksiyonlar alabilmek, takip edebilmek, ekiplerle daha yakın çalışabilmek yine aynı amaçla aldığımız bir aksiyon.
Onun dışında biraz daha böyle tool olarak aldığımız aksiyonlar var.
Trend olarak çok uzun süredir service maturity diye bir kavram var biliyorsunuz.
Ve ekipler bunu geldiğinde çok güzel benimsedi.
Bu genel olarak baktığınız zaman farklı sektörlerde de çok ortaya çıkan bir durum.
Hani bir konu üzerinde bir gamification varsa insanlar bunu böyle seviyor, hoşuna gidiyor.
Hani kendini geliştirmek için böyle şey gibi görüyor.
İşaret gibi görüyor mesela. İşte orada senin servis skorun silver.
Hadi bakalım bunu gold yapalım gibisinden.
İnsanlar bu yaklaşımı benimseyebiliyor.
Reliability tarafında bu biraz eksikti açıkçası.
O yüzden bu sene aldığımız en büyük aksiyonlar bir tanesi de bu aslında.
Service maturity ve yakın zamanda çıkan team maturity taraflarında reliability konularını nasıl target edebiliriz?
Burada da biraz seçici davranmaya çalışıyoruz.
Çünkü baktığınız zaman hani birçok ekibin yaşadığı belki yüzlerce farklı sorun var.
Ama herkesi eşit payda da ileriye götürebilecek konuları belirlemeye çalışıyoruz gibi.
Burası hala devam eden bir süreç.
Birkaç kural entegre olmaya başladı.
İşte resource management ile alakalı, farklı süreçlerle alakalı.
Burası da bu sene içerisinde gelişmeye devam edecek.
Bunun dışında yine warm meetinglere şu an herhangi bir warm meetinge bir SRE arkadaşımız da katılıyor.
Bütün tribe'ların yaşadığı durumlara.
Orada da yine aslında instant analiz yapılırken doğru noktalara parmak basabilmek adına işte doğru aksiyonların alınına emin olmak adına yürüttüğümüz bir süreç.
Buradan gelen çıkıları da yine team maturity veya işte demin bahsettiğim instant board'u konuları var.
İşte reliable preview'dan çıkan aksiyonlar olabilir.
Buralara yaymaya çalışıyoruz.
Süper. Süper.
Valla elinize sağlık. Gerçekten bence Trendyol içerisinde reliability artık bu sene içerisinde farklı bir noktaya gidecek gibi görüyorum.
Çok da umutluyuz genel olarak bu konuda.
Daha güzel sonuçlar alacağımızı kesinlikle düşünüyorum.
Kapatmadan tüm ekiplere sorduğumuz klasik bir soru var.
Onu da sormak isterim size. Eseri ekibi eğlenmek için ne yapıyor?
Böyle boş vakitlerinde, işte kahve molalarında vs.
Neler yapıyorsunuz ya da etkinliklerinizde?
Valla biz ekip etkinliklerinde genelde beraber vakit geçiriyoruz ama geçtiğimiz seneden itibaren artık bir rutin haline getirdiğimiz, getirmek istediğimiz bir laser tag etkinliği var.
Açık alan laser tagi. Havaların düzenlesini bekliyoruz tekrar yapmak için.
Tavsiye ederiz tüm ekiplere.
Onun dışında yemek yemeyi çok seven bir ekip.
Tren yol kültüründe de yemek yemek vardır zaten.
Pembe masa. Lahmacunlar, baklavalar vs.
aslında kültürün içerisinde bulunan bir şey.
Herhangi bir yerde bir yiyecek varsa, etraf üzerinde biri almıştır, baklava ısmarlamıştır ya da başka bir şey vardır vs.
O masa daha yerine gitmeden o baklavanın, o lahmacunun yanında bizim ekipten birilerini görebilirsin.
En ön sırada bekler. Yemek yemeyi seven bir ekip olarak aslında sık sık böyle yemek çevresinde toplanıyoruz.
Onun dışında kendi aramızda oynadığımız oyunlar var.
Belli boş bulduğumuz alanlarda ara ara kafa dağıtmak için.
Bunlar için de mesela Cold Names'de Hexball'da gibi herkesin bildiği oyunlar.
Vakit geçiriyoruz diyebilirim.
Süper. Harika.
Aslında yemek cevabını bekliyordum.
Laser Tech cevabı sürpriz oldu benim için ama güzel etkinlik.
Bunu da bir kenara yazalım.
Diğer ekiplere örnek olarak veririz diyelim.
Süper. Arkadaşlar çok teşekkür ediyorum geldiğiniz için.
Ben çok mutlu oldum açıkçası.
Bence çok güzel bir bölüm oldu.
Eseri'yi daha derinden daha iyi bir şekilde tanımış olduk.
Tekrar çok teşekkür ediyorum.
Biz de çok teşekkür ederiz.
74. bölümde Eseri ekibiyle beraberdik.
Bunun yanında Selam Ekip Podcast'imizin yanında Trendyol Talks adında başka bir podcast serimiz de var.
Orada da Trendyol kültürümüzden beslenen iş yapış biçimlerimizden ve ürkerlerimizden konuşuyoruz.
O podcastı da Trendo Talks yazarak bulabilirsiniz diyeyim.
Sonraki bölümlerde farklı ekiplerle görüşmek üzere.
Bu transkript otomatik olarak çıkarıldı; kayıtla küçük farklar olabilir.