CTO olarak Üç Yılda Öğrendiklerim
Yaklaşık üç yıldan beri HeadBall2 (ios,and) ve Basketball Arena (ios,and) oyunlarını geliştiren Masomo oyun şirketinde CTO görevindeyim. Global çapta günde 3.5 milyon kullanıcıya hizmet veren sistemlerin kararlılığından, optimizasyonundan ve takımlarından sorumlu oldum. Benim için eşsiz bir deneyimdi. Çok şey öğrendim, artık misyonumun sonuna geldim ve yeni maceralar için görevimi benden daha iyi bir yönetim sergileyeceğine inandığım Mustafa Köse kardeşime devrettim.
Daha önceleri oguzhan.info blog’u üzerinden kendi çapımda bir şeyler yazıyordum ve bana iyi geliyordu. CTO görevi ile beraber yazmak için zaman ayıramaz olmuştum bu yazı ile de tekrar yazmaya başlayacağım sanırım.
CTO görevindeyken Masomo’da ilk işim büyük bir migration oldu 15 bölgede birbirinden izole ve yerel ISP’lerde Dedicated sunucular üzerinde koşan sistemi AWS’de birleştirip cloud dönüşümümüzü tamamladık. (migration’da emek veren, birlikte çalıştığım en sağlam ekibe selam olsun 🙋♂)
Soldan sağa kadro: Ateş Derviş, Arda Örer, Taylan Doğan, Yiğit Yıldırım, Mehmet Karcı, Oğuzhan Yılmaz, Burak Varlı
Migration’dan sonraları geliştirilen yazılımlarda etraflıca refactor’e giriştik, kaynak kullanımını optimuma getirdik, onlarca şeyi otomatize ettik, çok güzel internal tool’lar geliştirdik ve bunlar şirketin vazgeçilmez parçaları oldular. Takımların performansları ve çalışma şekilleri ile ilgili çok düşündük, Agile olacağız diye türlü türlü framework’ler denedik. Sistemleri eğdik, büktük kendi iş yapış şeklimize uydurduk verimliliği arttırdık (hala sürüyor). Çok güzel monitoring sistemleri kurduk sistemin neresinde ne oluyor görebildik, buna göre iyileştirmeler yaptık. Latency konusuna özel eğildik, gerçek zamalı bir oyunda, oyun deneyimini maksimuma çıkartmaya gayret ettik…
Çok uzatmayayım yazılım geliştirme kültürünün oluşturulmasından tutun da parola paylaşım politikalarına kadar dantel gibi işledik her şeyi… Gözüm arkada kalmayacak yani.
Şimdi gelelim bu geçen zamanda öğrendiklerime; Aşağıda dağınık başlıklar halinde öğrendiklerimi yazmaya çalıştım, umarım birilerine faydalı olur…
Davranış Değişikliği
Öğrendim ki; şirketlere yeni davranış kazandırmak veya bir davranışı değiştirmek zor fakat imkansız değildir.
Zamanında evrim üzerine çalışan insanlar güzel demiş;
Hayatta kalacak olanlar, en güçlü ya da en zeki değildir; daha ziyade, değişimi en iyi yönetebilenlerdir.
Şirketlerin de serbest piyasada hayatta kalabilmeleri için değişimi başlatmaları veya buna ayak uydurmaları gerekir. (Nokia ve Blackberry en sevdiğim örneklerden. Ha birde IBM’in PC’ler için takındığı tavır da çok ibretlik.) Bu demek oluyor ki şirketlerinde davranışlarını, reflekslerini içerideki veya dışarıdaki etkilere göre değiştirmesi gerekir, değtirmelidir.
Açıkcası en çok zorlandığım konulardan biri de davranışların değiştirilmesi oldu, şirketin verimsiz olan davranışlarını verimli olanlarla değiştirmek veya yeni bir davranış alışkanlığı kazandırmak zor iş.
Bir çok davranış değiştirmemiz gerekti fakat burada yazılabilecek nahif bir örnek olmasından dolayı “commit mesaj” vakasını seçtim. 👇
Gitlab üzerinde yazılım geliştiriyorduk. Takımdaki developer sayısı arttıkça kimin ne yaptığını, neden yaptığını anlayamadığımız commit mesajları dikkat çekmeye başladı. Bu durum basit gibi görünse de gerçekten önemli problemlere neden oluyordu;
Şöyle ki;
- Incident anında rollback’i geciktiriyordu,
- Hangi commit’in neleri içerdiği, amacını anlaması zorlaşıyordu,
- Changelog için bir otomasyon kuramıyorduk,
- Versiyonlama yapmayı zorlaştırıyordu, otomatik bump edemiyorduk
- Bazı önemli metrikleri yakalayamıyorduk (defect rate vs.)
- Breaking Change’ler dikkatten kaçıyor bu da kararlılık sorunlarına neden oluyordu.
Çözüm için hemen hemen endüstri standardı olan Semantic Commit Message ‘ı denemeye karar verdik. Gel gelelim küçük ama hızlı ekiplerle yazılım geliştirmeye alışmış Ninja Developer’lar için bu “davranış değişikliği” demekti.
Davranışı değiştirmek için öncelikle kendi commit’lerimi semantic hale getirmeye başladım, her bir değişikliğe bir commit gelecek şekilde anlamlandırıp birlikte kod yazdığımız developer’lara göstermeye başladım, tabii bir süre sonra yayılmaya başladı (aklın yolu bir, developer’lar akıllı insanlar) ama işin garibi şu ki yeni developer’lar hemen benimserken daha eski developer’lar davranışı daha sonra benimsedi. Tabii bu ufak, ufak adımlar etkili oldu ve herkes aynı hassasiyeti göstermeye başladı.
Tepeden indirgemeci bir şekilde empoze edişin çalışmayacağını en baştan biliyordum ama iyi veya kötü davranışların bulaşıcı olduğunun farkında değildim. Davranışları değiştirmek istiyorsan bunları insanlara anlatmak yerine uygulayıp etkilerini göstermek gerektiğini öğrendim.
Yeni davranışlar oluştuktan sonra sürdürülebilir olması açısından yararlarını göstermek de çok önemli.
Örneğin: Semantic Commit Message sayesinde projede kapatılan kusurların metriklerini izleyip, kaliteyi ölçmek davranışı pekiştirmek adına güzel bir değer yarattı.
E.Q. > I.Q.
Öğrendim ki; iletişim yeteneği, teknik bilgiden daha önemli.
Genelde hep söylenir “iyi ürünleri iyi developer’lar yapar”. Bu geçen süreçte iyi ürünlerin, uyumlu developer’lar ile gerçekleştirildiğini tecrübe ettim. (EQ tüm alanlarda önemli!)
Çok yetenekli bilgili ve zeki developer’lardan tam bir black-ops takımı kurduk tıpkı PSG’nin hücum hattı gibiydi Neymar, Mbappe, Messi. Sonra şampiyonlar liginden elendik, nedeni ise çok basit. Takım içinde iletişimden kaynaklanan uyum sorunları oldu. Bu arada tüm takım uyumsuz değildi sadece bir kişinin egosu diğerlerine göre daha az mütevaziydi.
Keşke tüm iyi developer’lar aynı zamanda mütevazi olsa ama olmuyor. Bilgiyi taşımak kolay değil. Bu aşamada Dijkstra’nın meşhur The Humble Programmer makalesini de hatırlatırım.
Takım aslında görev üzerinde ilerleme kaydetmişti ama bizim arkadaş sürecin ilerlemesini zorlaştırıyordu. Takım için basit kararlar gereksiz tartışmalardan dolayı yorucu hale gelmişti. Review’lere sürekli premature-optimization için tartışmayla geçiyordu doğru yoldaydık ama keyifli bir ortam yoktu, çamurda koşuyorduk. Birisi yeni bir fikir atınca gireceği tartışmayı düşünüp vazgeçiyordu.
Benim burada aksiyonum, o arkadaşı takım ile daha uyumlu çalışabileceğine inandığım başka bir yetenek ile değiştirmem oldu, küçük hareket ama büyük etkisi oldu tahmin edileceği üzere.
Bizim “Genius Jerk” (hakaret olarak kabul etmeyin lütfen, bir iltifat olarak kullandım) ile bire bir görüşüp uzun vadede birlikte çalışamayacağımıza beraber kanaat getirip yollarımızı ayırdık. (Bu süreci yönetmek de ayrı bir konu, çok pragmatist olmak gerekiyor. Kişisel husumet’e yer verecek kelimeler bile kurulmaması gerekiyor.)
Masomo gibi firmalarda yazılım geliştirme işi bir takım sporu olarak yapılır, bir kahraman olmasına gerek yoktur, her takım üyesi proje hedefine katkı sağlamalıdır, birlikte kod yazdığı insana projede sonsuz güvenmeli, onunla beraber gelişmelidir. Görevim boyunca bu ortamı sağlamak önceliğim oldu.
Hype Train (Hype Cycle)
Öğrendim ki; Hype Train bir fırsattır, her anlamda üzerinde objektif şekilde durulması gerekir.
Yeni bir teknoloji, tool, platform veya tekniği uygulamanın bir kaç faydası var.
- Birincisi, teknik insanın motivasyonunu ve mutluluğunu arttırıyor olması.
- İkincisi, çıkan sonucun şirket hedeflerine uygun olup olmadığının herkesce net görülmesi,
- Hype hakkında sağlam bir fikrin oluşması.
Böylece değerlendirmeler Hype hakkında ön yargılardan kurtulup, direkt çıktılar üzerinden sağlıklı bir şekilde yapılabiliyor.
Diğer bir faydası da “ya şu teknolojiyi kullansak iyi olacak ama şirket izin vermiyor” gibi argümanların toksikleşmesine izin vermiyor…
Game Server’larımızı daha iyi yönetebilmek için bir Kubernetes cluster kurulmasının daha iyi olacağı fikri vardı. AWS üzerinden kurup Paris’de prod’a aldık. Gel gelelim diğer Game Server’lara göre latency %60 daha kötüydü. Biraz network katmanını optimize ettik, Container, Pod, Kernel hardening derken baya uğraştık. Gel gelelim %20 daha kötü bir değer elde ettik ve uygun olmayacağına karar verdik.
Böylece Game Server’ları Kubernetes üzerinde koşturmanın oyuncu deneyime kötü etkisi olduğunu öğrendik, Kubernetes’in network katmanı konusunda etraflıca bir fikrimiz oldu ve konu kapandı.
Bonus: Bu aralar AWS-CNI ile direkt ENI üzerinden trafiği Pod üzerine alma fikri var. Böylece Latency çok daha iyi olabilir. Deneyip göreceğiz işe yaramaz ise çöpe atacağız. (Bunlar hep çalışıyorsa elleme değil! 😃)
Bu yaklaşımdan dolayı Masomo’da çok çeşitli teknoloji’ler tool’lar var. Tech. Stack sürekli değişim içerisinde. Örneğin PHP’leri koşturmak için Nginx’den LiteSpeed’e daha sonra da RoadRunner’a geçtik, çok çok stabil olması gereken bazı public bileşenlerimizi Go’dan Rust’a çektik. Bu kası hep güçlü tutmak faydalı ve teknik anlamda güzel sinerji yaratıyor…
Güven Ortamı
Öğrendim ki; insanlara korkusuzca fikirlerini söyleyeceği bir ortam sağlarsan sorunların tespiti, çözüm önerileri ve takımların uyumu üst düzeye çıkıyor.
Ben bunu fakında olmadan doğal yoldan yapıyormuşum ama sonra öğrendim ki literatürde yeri varmış. Amy C. Edmondson’ın çalışmalarından ortaya çıkmış. The Fearless Organization: Creating Psychological Safety in the Workplace for Learning, Innovation, and Growth kitabı konuyu etraflıca ele alıyor.
Ben bunu doğal yoldan yapıyormuşum dedim ama bazı hatalarımda olmadı değil 👇
Yine bir gün feature toplantısındayız 👴 , her zamanki gibi kısıtlı süreler içerisinde, büyük hedefleri nasıl gerçekleştireceğimizi konuşuyoruz. Product Manager’lar, Developer’lardan süre tahmini istiyor (bitmeyen senfoni 🚬 ). Yetenekli bir arkadaş işi hızlıca tamamlayacağımız bir fikir belirtti. Tam bir “dirty hack” ama zaten yarısını anladım, anlamadım gereksiz bir hışım ile arkadaşa “duyduğum en saçma fikir bu” deme gafletinde bulundum 💩 (Bunun gibi çok gaflette bulunduğumu da söylemeden geçmemeyim). Tabi arkadaş herkesin içinde çeşitli sosyal bagajlarla fikrini çok savunamadı.
Bir sonraki toplantıda ve diğerlerinde bu arkadaş bir daha hiç fikir belirtmedi, sadece işini yaptı. Sonradan ben toparlayıp bire bir görüşmelerle ve açık yüreklilikle özür diledim ama yine de onun o kıvrak zekasından bir daha yararlanamadık.
Bu “Güven Ortamı” farkındalılığı çok önemli. Şirketin DNA’larında olması, tüm yöneticilerin içselleştirmesi gereken bir konu. Bu sağlandığında şirketteki bütün problemler suyun üzerine çıkmaktan korkmaz.
Bonus: Korkusuz organizasyonlar için Google’ın Aristoteles projesi de güzel bir başlangıç olabilir. İyi takımları inceleyip hepsinin ortak noktasını Psikolojik Güven Ortamı olarak nasıl bulduklarını anlatıyor.
İzleme ve Ölçümleme
Öğrendim ki; ölçümlemek, tüm sistemi düzeltiyor.
Bir metrik belirleyip ölçümlemeye çalıştığınızda aslında orayı iyileştirmiş oluyorsunuz, çünkü bilgiyi yaratan “yer” sistematik değilse ölçümlemeniz de mümkün olmuyor. O nedenle önemli gördüğünüz her şeyi ölçümlemeye çalışırsanız, elinizde tıkır tıkır çalışan bir sistem buluyorsunuz. (Bu şirketi daha iyiye götürmek için bir manevra olarak kabul edilebilir 🤔)
Öğrendim ki; insana dokunan ölçümleme büyük verimsizliklere yol açıyor.
Ölçümleme ile ilgili kıyısından döndüğüm hatalardan birisi de insanı rakamlara indirgemek oldu. Eğer insan ile ilgili bir ölçüm olacaksa minimum takım seviyesinde ölçümlemek ve herhangi bir performans değerlendirilmesine tabi olmaması çok önemli 👇
Gitlab üzerinden zaman zaman kendi dandik script’lerimden kimin en çok commit attığını, kimin en çok satır eklediğini veya sildiğini takip ediyor, bunu da bir Leader Board ile takımlarla paylaşıyordum. Zaman içerisinde bu paylaşımlar performans metriği olarak algılanmaya başladı. Paylaşımlara bir süre devam ettikten sonra ise developer’lar üzerinde olumsuz etlikerini fark ettik. Sıralamaları etkileyecek yeni davranışlar ortaya çıkmaya başladı. Örneğin yazılan kodda fazladan satır eklenebiliyordu, fonksiyonların boyutları gereksiz uzatılıyordu, gereksiz refactoring’ler görebiliyorduk. Bu benim yüzümdendi çünkü farkında olmadan bir rekabet tetiklemiştim.
Her ölçümleme de önemli değildir, herkesin görmesine gerek de yoktur. [spoiler] Tıpkı İlkkan’ın Anne ve Babasının İlkkan’a yazdığı mektup gibi bunu İlkkan’ın bilmemesi daha iyi olabilir. (Gibi, S1B7 )[/spoiler]
Öğrendim ki; önemli olan ölçümlemeler önemini yitirebildiği gibi, önemsiz gibi görünen ölçümler en önemli hale gelebilir.
Her şirketin kendi “North Star” metrikleri vardır. Teknik taraf için CCU (Concurrent User) ve DAU (Daily Active User) ana metriklerimizdendi. Sonra bunların önemi ikinci plana düştü çünkü oyuncu deneyimi için daha öncelik vermemiz gereken metrikler olduğunu farkettik ve hiç düşünmeden rotamızı değiştirdik. Bazı hassasiyetlerden dolayı bu değişikliğin örneğini Youtube üzerinden verdim. 👇
Youtube ilk zamanlar video’nun izlenme sayısına göre strateji belirliyordu. Verilen tüm kararlar ise normal olarak videoların izlenme sayısını arttıracak doğrultudaydı! Sonra fark edildi ki video izlenme süreleri yüksek olan videolardan insanlar daha mutlu ayrılıyor, reklam geliri daha yüksek seyrediyor. Hemen arkasından temel ölçümlemelerini izlenme sayısından, izlenme süresine çekiyorlar ve tüm hedefler buna göre evriliyor. Sonraki yıl günlük 1 milyar saat izlenme süresi hedefliyorlar ve 4 yıl içinde buna ulaşıyorlar.
Bonus: Masomo’da yazılım geliştirme yaşam döngüsünü izleyebilmek için SWE-Dashboard projesini geliştirdik ve open source paylaştık. Bizim için önemli ve önemini yitirmiş metrikleri de içerir. Günahlarımızı ve sevaplarımızı içeren bir proje oldu :)
İmkansız Hedefler
Öğrendim ki; hedefler ne kadar büyük olursa, insanların kendi kendini harekete geçirmesi daha kolay oluyor. O nedenle büyük hedefler, hatta hayallerin ötesinde hedefler konulması elzemdir.
Hedeflerin şeffaf bir şekilde paylaşılması, aylık veya üç aylık döngülerle üzerinden geçilmesi, gerekirse güncellenmesi yani sürekli bakımının yapılması gerekiyor. Burada hedefi tüm paydaşların anlaması, içselleştirmesi çok önemli. Alınan her kararın hedefe hizmet edip etmediği herkes tarafından sorgulanacağı bir yapı ile tüm hedeflere ulaşmak mümkün. Yeter ki hedefler saf bir şekilde herkes ile paylaşılsın.
Basketball Arena oyunumuz ilk çıktığında dünya çapında Latency ortalamamız 90ms (milisaniye) civarındandı. İyi bir oyun deneyimi için 80ms’i geçmemesi gerekiyordu. Çünkü Retention ve LTV (Life Time Value) oranlarımız olumsuz etkileniyordu.
Hedefimiz şu oldu:
“Tüm dünyadaki maçlar 50ms altında oynanacak”
Pek gerçekçi olmayan bu hedefi Infra&SRE ve Development takımlarımıza duyurduktan sonra çalışmalara başladık. Game Server’da 150 kadar mikro iyileştirme yaptık, Game Server konumlarını Internet Routing mekanizmalarına göre tekrar konumlandırdık, sunucuları ARM tabanlı CPU’ya geçirdik, Linux son sürüm kernel’in daha iyi performans verdiğini keşfettik, client tarafta prediction algoritmalarımızı optimize ettik ve sonuç olarak 35ms ortalama yakaladık.
Imperatif olma Deklaratif ol
Öğrendim ki; işin nasıl yapılacağını söylemek yerine sadece işin amacını ve hedeflerini belirtmek çok daha verimli.
Görev takibi yapan biri olmaktan ziyade akıl hocalığı yapan biri olmayı tercih ederim o nedenle; genelde bir görev delege ettikten sonra “İşini daha iyi yapman için ne yapabilirim?” veya “İşini yapmana engel bir durum var mı?” diye soruyorum.
Görevi delege ettiğim insana sonsuz güvenirim, eğer konu ile ilgili bir talebi olursa işte o zaman elimden geldiğince yönlendirmede bulunmayı tercih ediyorum.
Burada “Kalite Sponsoru” kavramını seviyorum. Açıkcası beni güvende tutuyor. Çünkü görevin kalitesinden ben sorumluyum, çıktılar benim beklentilerimden düşük ise o zaman somut olarak işin nasıl yapılacağı ile ilgili fikir vermem daha pozitif karşılanıyor.
Bunun kötü bir yan etkisi var. İşin hedefine giden yol çok verimsiz uygulanmış olabiliyor ve bu durum iş bitiminde fark edilebiliyor. Bu büyük israf, ama yaşanmıyor da değil. Bu gibi durumların postmortem’ini, retrospektif’ini kesinlikle yapmak lazım ki bir daha ki task’da aynı israf olmasın.
Yıllık Performans Değerlendirmeleri
Öğrendim ki; Yıllık Performans Değerlendirmeleri başarısızlığa mahkum, yorucu ve maliyetlidir.
1927 ile 1932 yılları arasında, Western Elektrik Şirketi’nde aydınlatma düzeyi ile verimlilik ilişkisini araştırmak için fabrika çalışanları ile bir deney yapıyorlar. Deneyler sırasında karanlıkta kalan işçilerle aydınlıkta kalanlar arasındaki verimliliğin eşit arttığı gözlemleniyor, daha sonra aydınlanma düzeyinin azaltılmasına karşın hem aydınlanmanın azaltıldığı grupta hem de kontrol grubunda verimliliğin gene arttığını gözlemliyorlar. Tüm deney gruplarında hem de kontrol grubunda verimliliği artmasının nedenini bulmak isteyen psikologlar, işçilerle görüşüyorlar ve işçilere durumun nedenini soruyorlar, işçiler de araştırmacılara, bilim insanlarının kendileriyle ilgilenmesinden memnuniyet duyduklarını anlatıyorlar. Oha! Bknz 👉 Hawthorne Effect
Yukarıdaki Hawthorne etkisi bize açıkca gösteriyor ki birlikte çalıştığınız insanlarla sürekli geri bildirim halinde olmanız, bunu da sürdürülebilir kılmanız verimliliği arttırıyor.
O zaman neden senede bir kere görüşüp, sığ değerlendirmeler yapıp adaletsiz bir sistem kullanıyoruz? Düşünsenize, size geri bildirim verme fırsatı çalışanın eline yılda bir kere geçiyor 💩
Peki, bu modası geçmiş yaklaşım yerine nasıl bir çatı koymalıyız?
Intel’in efsanevi yöneticisi Andy Grove’un uyguladığı C.F.R. (Conversations, Feedback, Recognition) sistemi Hawthorne Etkisi ile uyumlu bir sistematik.
CFR’de puanlama yoktur, herhangi bir yazılı değerlendirme yoktur, belge yoktur, kimseyi yormaz. Sürekli geri besleme ve diyalog süreci performansı değerlendirmenize olanak verir.
CFR’leri deneyimleme fırsatım henüz olmadı o nedenle bir tecrübe aktaramıyorum ama ne yapılmaması gerektiği ile ilgili derdimi söyledim. O nedenle mesajım verip konuyu kapatayım. Yıllık değerlendirmeleri hemen bırakın ve çalışanlarınız ile sürekli diyalog halinde kalıp iki taraflı geri bildirimde bulunan bir sistematikler kurgulayın. Bunu da CFR’leri referans alarak yapabilirsiniz.
Not: John Doer’in Önemli Olanı Ölç kitabında CFR sistemi Adobe hikayesi ile çok güzel anlatılıyor.
Müzakerecilik
Öğrendim ki; kültürel bir handikap ile doğruyu bulma arayışından kopup tartışmaları çok kolay kişiselleştirebiliyoruz.
Fikri yanlışlanan kimse sanki kariyeri tehlikedeymiş gibi geriliyor ve çeşitli safsatalarla tartışma yararsız hale geliyor.
Bu aşamada tartışmayı şirket için yaptığımızı, hedeflerimize katkı sağlayacak adımların doğruluğundan emin olmak için tartıştığımızı hatırlatırım hep. Yani burada konu kimin doğru söylediği değil, neyin hedefler için iyi bir adım olacağıdır. Tartışmada hep materyalist olmakta fayda var.
Ne kadar uzlaşma olmasa da, tartışmanın ekseni ne kadar amacından sapmışsa ve Ad Hominem’e abanılmışsa da masadan bir sonuç ile kalkmayı hedeflemek gerekiyor. Tabii kolay değil, çelik gibi sinirlere, İsmet İnönü gibi inada sahip olmanız gerekiyor.
Vaka Değerlendirme Raporu (a.k.a Postmortem)
Öğrendim ki; Postmortem’ler, bizim tabirimizle Vaka Değerlendirme Raporları bir firmanın ilerlemesi için en büyük geri bildirimlerdir.
CTO görevim süresince 30 civarı VDR (Vaka Değerlendirme Raporu) yazmışız. Bunlardan bazılarını hatırlamak bile istemiyorum fakat işleri her batırdığımızda problemi bir uçak kazası ciddiyetinde irdeleyerek, daha iyi hale evrilmeyi öğrendik. Sonuçta bizi öldürmeyen şey güçlendirir!
Gelin size en berbatı olan Türkiye bölgesinde 24 saat kapalı kaldığımız en uzun outgage’imizden ve aldığımız aksiyonlardan bahsedeyim 👇
VDR #5, 13 Mayıs 2020 SummitDB Crash!
Türkiye’de Raft Consensus ile çalışan ve RESP destekli key-value store kullanıyorduk. Üç makine birbirinin failover destekliyor, Önemli kullanıcı dataları orada, yani main component. Aha işte o uçtu!!
Her gün 06:00 da yedek alınıyor fakat o zamanlar yoğun bir trafik var. VDR’den alıntı yapıyorum;
06:33 - TR için alınan rutin yedeklemede sırasında veri tabanlarından SummitDB servisinin process’ı durdu. İşletim Sistemi seviyesinde bir hata tespit edildi.
Hata: Out of memory: Kill process 10976 (summitdb-server) score 447 or sacrifice child
Her şey böyle başlıyor… Önce Opsgenie herkesi arıyor (ben dahil) kimse aksiyona geçmiyor. (Action #1:SRE takımına on-call sistemine geçmeye karar veriyoruz)
06:35'de Türkiye’de oyun duruyor. Bizim haberimiz taa 09:00 da oluyor. 💩 🤦♂
09:15 Sistemi maintanence moda alıyoruz. Bu arada crash olan DB’den “null” response için error handling başka bir probleme neden oluyor (Action #2: Error handling mekanizmasını refactor ediyoruz)
10:40 Error handling’in başka bir store’daki datayı bozduğunu fark ediyoruz. O kullanıcıları yedeklerden restore ediyoruz. (Action #3: Bunun bir daha olaması için refactor ediyoruz, Action 4# Kullanıcı restore’u otomatize ediyoruz)
11:20 27GB olan yedekleri restore ediyoruz fakar Raft Consesus’da bir senkronizasyon sorunu var. SummitDB’ye yaptığımız bir patch edge case yaratıyor. Onu fix’liyoruz ve ayağa kaldırmaya çalışıyoruz. Sistem Kapalı.
12:20 Makine içindeki son Raft snapshot’unu SRE takımından bir arkadaş gereksiz diye siliyor WTF! (Action #5: Buna bir aksiyon alamadım)
13:48 SummitDB’yi ayaklandırmak için Raft’ı single node’da açıp arkasından diğer node’ları açıyoruz ki sıfırdan sync olsun ama o kadar çok cascading failure var ki tüm yangınlara yetişemiyoruz…
…Baya bir mücadeleden sonra…
02:42 Sonunda sistemi ayaklandırabiliyoruz. Stabil. (Action #6: SummitDB’yi DynamoDB ile değiştirme kararı aldık, Action #7 TR region’unu AWS’ye migrate’e karar verdik)
04:11 Sistemi açtık ve trafik akmaya başladı ama ISP’nin IDS’ı UDP trafiğini bloke etti. Aniden gelen bir saldırı gibi algıladı. (Action #8: ISP ile görüşüp bizim network’ün policy’sini değiştirttik. Tüm ISP’ler ve AWS dahil bu policy’i zorunlu kıldık)
05:27 Tüm sistemler devrede, sinirler gergin! 😫
Bu hengamenin dakika dakika süreci, nedenleri, kapsamı hepsi yazılı. Ne zaman konusu geçse geri dönüp raporu okuyup aynı heyecanı yaşıyoruz. Şimdilerde sistem yedekli, felaket senaryolarına daha dayanıklı. Tabi geriye dönüp baktığımızda “ne kadar amatörmüşüz” diye içimden geçirmiyor değilim.
Ne diyelim, Tanrı Masomo’ya bir daha VDR yazdırmasın.
Bonus: Başkasının hatalarından ders çıkarmak çok karlı bir davranış. O nedenle bulabildiğim tüm postmortemleri okurum. Aşağıda güzel bir repo var. İyi bir başlangıç noktası olabilir.
👉 https://github.com/danluu/post-mortems
Bilge adamın dediği gibi:
Başkalarının hatalarını yapmadık ama kendi hatalarımızı yaptık.
Derine, Daha Derinlemesine
Öğrendim ki; yönettiğin sistemlerde nelerin olup bittiğini derinlemesine bilmeli, neden sonuç ilişkilerini açığa çıkartmalısın.
User Error grafiğimizde sürekli dikkatimi çeken ufak bir desen görüyordum. Her ayın ikinci haftasının başında özellik Türkiye bölgesinde 0,1 ila 0,2 arasında bir yükseliş gözlemliyorduk. Gündeme getirdiğimde bir çok hipotez söyleniyordu, konu “olur öyle” diye kaynayıp gidiyordu gel gelelim örümcek hislerim yeni bir case yakaladığımızı söylüyordu. Önce back-end logları içerisinde ne aradığımı bilmeden dolaştım, daha sonra client tarafındaki loglarda dolaştım bir şey bulamadım veya doğru aralığı yakalayamadım fakat bir sonraki ay. Doğru zamanda doğru yerde olacaktım.
Bu sefer yeni log girdileri eklediğim bir game server kaldırdım neredeyse her paketi kaydediyordu. Diğer yandan client tarafında gelen response’ları error anında daha detaylı izlemeye başladık.
Aha! Bir de ne görelim, Türk Telekom TCP’den araya girip bizim response yerine kendi response’unu borçlu olan abonelere gönderiyormuş! 🤦♂
Bizdeki client’da JSON beklediği yerde HTML gelince oyun crash oluyormuş 💩
Her şey %0,1'i kovalamak ile başladı ve çok değişik bir edge case yakaladık. JSON marshalling tarafını güçlendirdik, Crash-Free oranımızda bir nebze arttı, ufkumuz genişledi! 😄
Diğer bir ilginç olayı da Kore’de yaşadık;
Kore’de retention’ımız düşüktü ve CCU seviyemiz yerlerde geziyordu. Teknik olarak gözle görülür hiç bir alamet yoktu. Günlerce baktık baktık bir şey bulamadık, Kore’den birilerini bulup video atmasını istedik. Hiç bir sıkıntı yoktu oyun beklendiği gibi açılıyor ve çalışıyordu fakat gözden kaçırdığımız bir şeyler olduğu kesindi. Açıkca söylemek gerekirse peşini bıraktım fakat bir kaç ay sonra tekrar döndüm. Tesadüfen discord kanalında Japon bir oyuncunun feedback’ini gördük, Level Üçde isim seçerken sadece Latin klavye desteği vardı ve yüklü olmayan telefonlar bir şey yazamıyorlardı. Peh! 😝
İşin içine biraz daha daldıktan sonra aslında konu daha da derinmiş. Korece ve Japonca fontları çektiğimiz CDN’in Asyada node’u yokmuş o nedenle gidip Frankfurt veya California üzerindeki node’lardan çekiyormuş ve tahmin edeceğiniz gibi asset çok yavaş geldiğinden retention kaybına neden oluyormuş.
Hemen fontları embed ettik ve CDN Node’larının Asia tarafında açılmasını sağladık. Oyunun açılış hızı dramatik şekilde yükseldi yalnız retentin’lara etkisi sandığımız kadar olmadı… Hala var bir şeyler orada :)
Başka ilginç case ise şöyle;
Türkiye bölgesinde bir kaç günden beri online kullanıcı grafiğimizde 30 dakikada bir yükselmeler olmaya başladı. İlk zamanlar pek önemsemedik ama bu desenin süresi haftayı geçince şüphelenmeye başladık. Sanki kullanıcılar düşüyor ama göremiyoruz , sonradan bir yanlış hesaplama ile çok görünüyor gibi bir durum diyerek bir çok hipotez üretiyoruz. Teknik olarak tüm sistemi tarıyoruz, sistemi verbose mod çekiyoruz, oyunu oynuyoruz, o saatlerde her şey çok normal!
Sonradan anlıyoruz ki. Pandemi dolayısıyla online eğitim başlamış ve öğrenciler her 30 dakikada bir 10 dakika teneffüs’e çıktıklarından oyunu açıp oynuyorlar ve ders başlayınca kapatıyorlar.
Nasıl mı anladık, bir arkadaşın eşi öğretmen olduğundan o farkettirdi.
HTO: @Oğuzhan Yılmaz ders arası olabilir
11:55 eşimin molaya çıktığı zamanlara denk geliyor
11:55 9da başlayıp evden online ders veriyorlar ya
11:55 30 dk bir 10 dk teneffüse çıkıyorlar.
Art Design Pipeline Ama Nasıl?
Öğrendim ki; Endüstri’de Art Design’ın bir ölçümlemesi veya sistematiği yok. Hala optimumu arıyorum…
Şirketteki tüm takımların bir şekilde ölçümlemesi hakkında fikrim var ama Game Artist takımı tarafında hala bir fikrim yok. Amacım performans kaygısı ile bir şeyi ölçmek değil sadece bir Game Artist takımının ürettiği Asset’lerin (png, animasyon, vs..) süresini ve trendini görmek, karar süreçlerine dahil etmek.
Örneğin Game Artis’lerde bir Merge Request kavramı yok o nedenle bir Cycle Time bulamıyorsun. Jira üzerinden bir Cycle Time üretebilirsin ama bu çok yüzeysel kalıyor ve gerçekçi değil. Benim istediğim Asset’in üretime başladıktan ve kabul edilip prod’a çıktıktan sonraki stepleri ölçmek bunun için git-annex üzerinden bir şeyler kurguladım ama derme çatma oldu.
Hala araştırıyorum. Burada bir öğrenimi olanlar fikir verirse sevinirim ✋
Kapanış
Gerçekten hunharca yazmışım, sanırım uzun zamandan beri yazmayışımın da etkisi yok değil. Aslında daha değinmek istediğim Agile, İş Görüşmeleri, Maaşlar vb. başlıklar vardı fakat sıkıcı konular olduğundan bir sonraki yazılara bıraktım.
Bundan sonraki planım belli, oyun sektöründeki çılgın problemleri çözmek. Her şey yolunda giderse Mayıs ayında bir girişimimizi duyuracağız.
Bu arada yeni girişim için, yeni bir ekip kuruyoruz önceliğimiz Unity Game Engine’e aşina Game Developer’lar olacak ilgilenenler aspsrc@gmail.com adresine CV’sini gönderebilir 🧙
—
Oğuzhan
