Turknet Transformers Mühendislik Ekibinde bir mikro hizmet dönüşümünün hikayesi
Architect Perspektif — hard parts
Transformers takımı başlarda core engineering takımı olarak kurulmuş ve 14 squad ekibinin 13. sü olarak yer almıştı.
Başlarda ki görevi şirketin cloud hedeflerine uyulması gereken ekiplere kaldıraç görevi görmekti. Bu baglamda bir domain’i yoktu. Ad-hoc adını verdiğimiz architecture pattern’ler de de yeri olan cross-cutting gorevi gören servisler design etmek bu ekibin ilk göreviydi.
- anket gönderimleri
- notification (sms,push,email) gonderimleri
- authentication yapıları
- edevlet integration sistemleri
- product,basket ,kampanya servisleri
gibi süreçleri design eden ve ilgili squad takımları ile dirsek temasında bulunan bir takımdı. Hal böyle iken okr hederleri de buna göre şekilleniyor ve ne kadar fazla mikroservis dönüşümü gerçekleştirirse takım kendini o kadar çok cloud ve mikroservis dönüşüm hedeflerine uygun görüyordu.
Tabi başlarda bu servisler mikro değil zaman zaman mini servisler olarak da kendini gösteriyor ve iyiden iyiye yeni kurulmuş bir takımda hiç görmek istemediğimiz bir complexity’e dogru süreç evriliyordu. Çünkü bounded contexlerin olmadıgı bir dünyada servislerin zombi servisler olabileceği aşikardı.
Gelinen noktada 72 tane servisi olan ve bir domain’i olmayan , üstelik kurulusundan 1 sene gecmemiş olan bir takımın 12 tane kadim ve oldukca derinliği olan,bir telekom şirketinin olmaz ise olmazlarını olusturan satıs,aktivasyon,faturalama gibi ekiplerin 3 katı servise sahip olması, bir şeylerin yanlıs gittiği izlenimini bana vermişti.
Faturalama ekibinden sonra ki bu ekip şirketin kuruluşundan beri var. 148 repo ile transformers onun önüne geçmişti.
Billing : 132
Transfomers : 148
Diğer squadlardan max repo count ise : 60 idi.
Niyet dogruydu,ekip dogruydu,hedef dogruydu ama yol yanlıştı.
Building evoulation architure’da neal ford’un izah ettiği quantum tam olarak görülememişti. Yani evrilmesi gereken hedef önceden bir iskelet olarak design edilmeli,ortaya konmalı ,yol haritası çıkarılmalı idi. Backlog ona göre zenginleştirildikten sonra işlere sınır getirilmeliydi. Her sprint bir servislerin etrafı fikirler ile örülmeli ve ekip bu anlamlı hedefe sprint olarak koşmalıydı. Her sprint sonunda live edilip , servise bir client kazandırılmalı ,elde edilen business metricleri ile kullanım oranları arasında ki denge gözetilip yapılan işin outcome mı yoksa output mu olduğu anlaşılmalıydı.
Geldiğimiz noktada elde edilen toplam 72 servis ve hangilerinin kullanıldıgını hiç bir zaman anlamadıgımız bir örümcek ağına dönüşen bir domain’imiz vardı.
Halbuki bir mikroservisin karakteristiği aslında şöyleydi,
- Componentization via Services
- Organized around Business Capabilities
- Products not Projects
- Smart endpoints and dumb pipes
- Decentralized Governance
- Decentralized Data Management
- Infrastructure Automation
- Design for failure
- Evolutionary Design
Teknik olarak,infra automation,design for failure ,decentralized governance ve data management kuralına gore design edilmişti ama en önemli olan konu atlanılmıştı. Organized around business capabilities.
Bunun sonucu olarak herkes yazdıgı servisi biliyordu ama kimin alt parcası veya hangi büyük parçaya hizmet ettiğini kimse bilmiyordu.
- bu neyin parçası ?
- bu neyin örneği ?
- bunun arkasında ki niyet nedir ?
Bu 3 sorunun cevabını hiç bir zaman alamıyorduk. Bence mikroservisleri design ederken kaçırılan en büyük nokta burası. Ben ne istiyorum değil müşteri ne istiyor diye sorsak aslında daha anlamlı bir fikri altyapıya kavuşacağız.
Dogru soruna yanlış çözüm bulduğumuz için değil, yanlış sorunu çözdüğümüz için daha sık başarısız oluyoruz. Russell L. Ackof
Russell Ackof, karmasık problemler için en ilgi cekici olarak kulllandığı metafor “karmaşa” dır. Ackof buna karmaşa adını vermiş. Bu karmaşaların nedeni ne kadar bahaneler ile kendimizi avutsak da sorunu anlayamamamızdır.
Tüm bu karışıklar ile başa çıkmanın yolu , varsayım ve içgüdülerimizi bir kenara bırakarak nedenlerini bulmaktır.
Benim de çözüm aramaya çalıştığım sorun buydu. Aslında bu mikroservislerin karakteristiğinde yatıyordu. Cross functional team oluşturmadan böyle bir topa girilmeyeceğiydi.
Tabi burada büyüteci biraz daha yakınlaştırdığımızda cross functional ‘ın takımın kendisinin olduğu anlasılır. Uzaklaştırdığımızda ise chapter’ların ve stakeholder’ın bunu temsil ettiği gözükür.
Yani quantum’u doğru tespit ettiğinizde üzerine domain’i inşa etmeye başlayabilirsiniz demektir. Eger domain’i mini servisler yazarak keşfetmeye kalkışırsanız kıyamet saatine kadar bu geliştirmeler bitmez. Ölüm kapınızı çaldıgında daha işim bitmedi diyemezsiniz :)
Gelinen noktada baktığımız manzara şu şekildeydi,
Yanlış OKR bağdattan döner !
Hal böyle iken şirketin başlattıgı ama bir türlü randıman alamadıgı bir crm projesi de fail edince , onun sıfırdan prototipinin yazılması transformers ekibine verildi. Bu tip manevra kabiliyetine sahip en elverişli takım telekom şirketin içinde bulunduğu konjukture hizmet eden diger domain takımlarının olamayacagı aşikardı . Çunku satış,aktivasyon,faturalama gibi takımlar zaten bir telekom şirketi süreclerinin ana umdelerini temsil ediyor ve halihazırda her quarterda bu okr’ler koşan takımlardı.
Bu yeni bir domain’in veya bir projenin create edilmesinde ki başlangıç yani aslan payının transfomers’a verilmesi bir tesadüf değildi . Bu bir crm projesiydi. Yeni design edilmesi gerekiyordu. Cloud ve mikroservis okr’lerine hizmet etmesi gerekiyordu. Organizasyonel olarak chapter ve stakeholder’lar ile yakın teması gerektiren ve bir setup kurulduktan sonra hemen müşteri önüne konulup feedback alınması ve ona gore yol haritası belirlenmesi gerekiyordu.
Peki yukarıda anlattıgım ve kurulusunda 1 yıl geçmemiş ,elinde bir spider web architecture olan ekip ne yapmalı ve nasıl karar vermeliydi ? Nasıl bir roadmap çizmeliydi ?
Doğru bir politika izlemediği takdirde akıbeti önce ki fail eden projeden farksız olacak ve organizasyonun bütçesinde ciddi bir sarsıntıya daha sebep olacaktı.
Bu projenin adı onehub idi. Yani telekomun kadim ekiplerini bünyesinde barındıracak,her birine ait ayrı bir roadmap ve backlog oluşturacak , bu hedeflerine hizmet ederken kimsenin kuyruğu birbirine değmeden esnek bir şekilde ilerlemesini sağlayacaktı.
Ekip kollarını sıvamıstı. TMForum adı verilen globalde bir telekom organizasyonunun nasıl bir bounded contexlere sahip olduğunu araştırmak ile işe başlamıştı. Deyimi yerinde ise yukarı da anlattığım örümcek ağına dönmesin diye her servisin tm forum modellerinde nasıl tasarlandığına ilişkin dökümanları ekip hatmetmişti.
Bu zamana kadar platform hizmeti veren takım ilk defa bir domaine sahip olacak ve sürece liderlik edecekti. Okunan tmforum dokumanları,mevcut crm’in nasıl calıstıgı ilgili bilgiler bir elde toplanarak pm eliyle ekibe geliyor, ekip bir süzgeçten gecirerek daha anlamlı business altyapısı olan servislere dönüştürüyordu. Bu şekilde 30 adet mikroservis elde edilmiş ve sadece mikroservis değil aynı zamanda da cloud okr’sine koşan takım her servise ait mikro db de oluşturmuştu.
Aslında yine engineer’ın kronikleşen hastalıgı burada da devrede. Db ayrılması cok zor bir iştir. En son yapılması gereken iş ilk basta yapılarak yine nasıl bir faciaya gidildiği öngörülememişti.
Ölçeklenme db den değil loadbalancer arkasında instancelarını artırdıgınız servislerden baslar. Yani Z ekseninde yer alan data partitioning sürecin son halkasıdır.
Öncelikle sistem yukarıdan aşağıya doğru bölünür ve tümden gelime gidilirdi. Aslında TDD de 2 yaklasım vardır.
- bottom up
- top down
Bottom up, domain’i avucunuzun içi gibi bildiğinizde mümkündür. Hiçbirimiz telekom domain’i ile haşır neşir olmadığımıza göre yine facia geliyorum demişti.
El-Cezeri, bir işin bilimi ogrenilene kadar önce uygulamaları yapılır ve her uygulama aşağı yukarı ele yüze bulaştırılır der. Yani bu gayet normal. Batı da fake it till you make it dedikleri konu da aslında budur.
Ama distributed sistemler sevmediğinizde masadan kalkacağınız öğle yemeği molası olmadığına göre bu konuya biraz hassas davranmak gerekir.
Software architecture hard parts, aslında sistematik bir şekilde bu bölünmeyi anlatır. Ve ufuk acıcı fikirler verir. Elbette harfi harfine uymak gerekmez ama nasıl bir yol izlenilmesi gerektiği ile ilgili ipuclarını bilmek daha ihtiyatlı ve stressiz adımlar atmanıza yarar.
Yukarıda anlattığım spider web architecture’dan oldukça dersini almıs olan takım bu sefer daha anlamlı ve ihtiyatlı hareket ediyordu. Bu kez takımı daha farklı bir challange bekliyordu. Genel olarak baktığımızda yeni kurulmus bir takım oldugundan,
- fail eden projeye nazaran beklenti yüksekti
- yönetim barut gibiydi :)
- takımın birikmiş problemleri vardı
- takım içinde agile & engineering practices adına hiç bir rituel yoktu
- hiç bir servis monitor edilmiyor cunku trafiği yoktu.
- Bir de 72 servis üzerine bu 30 servisin olması infra chapter’larına ciddi workload yaratmıstı. Ekip istediği kadar okr’sine hizmet etsin, turknet evreninde yalnız değildi. Beraber calıstıgı tüm stakeholder ile paralel hareket edip ,işlere sınır getirmesi yani kanban tarzı ilerlemesi gerekiyordu. Sizce 1 ve 2. maddenin yarattığı stres buna izin verir miydi ?
Ekibimizin içinde oldugu durum tam da buydu. Onehub ‘ın ilk adımı yukarı da ki görselde ki gibi atılmıstı. Yine en zor yol seçilmişti :)
Aslında nacizane ben , tam da burada ekibe dahil oldum. Ve makale buradan başlıyor.
26 subat 2024 deadline’ı — MVP 1.3
Core team 5 kişi,1 qa,1 devops,1 fe,1 ux ise chapter arkadaşlarımız.
Product manager’ımız ve ben backlog’u süzdük. 5 aylık borcumuz var ve ilk mvp için 2 ay süremiz var.
Can Kurucu ile türk yıldızları filo komutanlığı gibi çalısmaya başladık. Bu ekip göçmen kuşlar gibidir. Mutlaka önünde bir lider kuş vardır. Yeri gelir en arkada ki en öne geçer. Biri düşünce diğeri onun yanına iniş yapar ve gerekirse kalkana kadar refakatlık eder.
Takımı arkamıza alıp , oncelikle topologiyi cıkardık. Her takıldıgımız yerde filomuzda ki ilgili servise hit eden arkadasımızı/arkadaslarımızı dahil edip sorunu çözüp deploy ettik. Her business akışını bağlantısı olan diger servisler ile birleştirip bir kurgu çıkarmaya basladık . Ve bu kurgunun aslının ne oldugunu pm’imizden oğrenerek test edip ,hatalarını fix ettik.
Atılan commitlerden,dev ve prod arasında ki gaplerden,deploy edilmiş image’ın versiyonunun codebase’de karsılıgının olmamasından tutunda her servis arası ortak modellerin bir nexus reposundan verildiği bagımlılıklara kadar bir çok sorunumuz vardı. Üstelik bu versiyonlar birbirleri ile de uyuşmuyordu. Üstüne azure’dan bitbucket’a ,bir k8s ortamından farklı bir k8s cluster’e gecişinde okr oldugu bir dünyada hepden uçurumun kıyısındaydık :)
Dere geçerken at değiştirmek bu olsa gerek !
Aslında bu süreclerin sorunları ve bunlara hit eden çözümleri literaturde onceden yer alıyordu. 12 factor app.
Bir cloud native app geliştirmenin kabaca 12 adıma hit ettiğini biliyoruz. Ve her adım için birden fazla sorun yasadık.
Özetle,
I. Codebase : version control system azure’dan bitbucket’a taşınmıştı. Tahmin edileceği üzere bir sürü sorun beraberinde gelmişti.
II. Dependencies : her servisinin barındırdıgı common model veya paketler için ortak bir artifact vardı. Mikroservislerde code duplication işin doğası gereği olduğundan buna aykırı olarak modellerinde paketleştirilmesi ve version control sisteminin de taşınması ile kaotik bir hal almıstı.
III. Config : devops chapter’ımız yeni bir k8s stratejisine geçiş yapmak istiyordu. Asis bakımı pahalıydı,buna hakları vardı ve bir playgrounda ihtiyac vardı. Bundan doğal hiç bir şey olamaz. Ama bu kadar sorun ile uğrasırken bir de bu geçişe denk geliyor oluşumuz bize saç baş yoldurttu diyebilirim. Çünkü her servisin deployment scriptlerini teker teker düzeltmek,eksiklerini gidermek ,her hata çıktığında tekrar tekrar düzenlemek zorunda kaldık.
X. Dev/prod parity : dev ve prod ortamlarını setup aynı ama deployment ortamları farklı olmalıydı. Yani dev’in locali produn aynısı olmalı sadece configler değişmeliydi. Aynı şekilde deployment ortamlarının pipeline’larını bu şekilde olmalıydı. Servislerin yaml file’larında yer alan configler ve bunları tutarsızlıkları azure ve bitbucket pipeline’ları arasında bir t anında geçiş süreci olarak değerlendirdiğimizde bir dev’in aklını yitirmemesi mucizeydi. Config azure,pipeline bitbucket’a gore ayarlanmıs , sonra en son dokunusumuzdan beri temsil edilen image version aslında codebase’e uymuyor gibi sahneler ile başbaşa kaldığımız en küçük anılarımızdan biriydi :)
XI. Logs : Tabi k8s ortamı değişince log strategysini de değiştirmek mevzu bahis oldu ve elbette alıstıgımız ortamın log sistemi ile geçiş yaptığımız ortamın log sistemi tutarlılık kazanana kadar bir süre körleşmemize sebep oldu.
Tüm bunlar yapılmaması gereken geliştirmeler değil ve her firmada bu devops ve cloud sürecler oturana kadar bu sorunlar olur. Söz konusu problem mikroservis dünyasına ekibin ve infra ekiplerinin fikri alt yapılarının gelişmesini ,playgroundlar oluşturarak öğrenmeleri için zaman yaratılması gibi gereklilikler gözetilmeden girildiğinden tepeden tırnağa her adımda sorun yaşamış olmamızdı.
Yani bu durum değişim kelimesinin cazibesine kapılmış ve alt metin olarak getirdiği dezanformasyonların hesap edilmeden dalınan dünyanın bir yansımasıydı. Elbette tabii kanunlara karşı çıkamadığımız gibi organizasyonun okrlerine hit eden işlerin ekipler tarafından uygalandıgında birbirleri arasında conflictler çıkması tesadüf değildi.
Yukarı da yanlış okr bağdattan döner demiştim. Eger poc olarak bir servis seçip , organizasyonun tüm chapterları ile bu servisin 12 factor app rule’larına uyum saglanması okr’si konulsaydı elbette bu kadar kaotik sorun olmadan tüm sorunlar bir servis ozelinde birikeceğinden hem kaos olmaz hem de farklı okr veya sürecler için ekiplerin değişime gösterdiği manevra kabileyeti için zaman ve enerjileri olurdu.
Şirket içi çıkarlar her zaman olur ki bu normaldir. Bir de üstüne bu manzara yonetime izah edilir cinsten değildi. Bunu izah edemezdik.
Dediğim gibi önce ekiplerin fikri altapısı ve zihin modelleri inşa edilir. Sonra ufak ufak başlanılır. Bir sorun olduğunda explosion zone doğal olarak kendi cürmü kadar olur.
Sistemi design etmeye görselde ki gibi başlarsanız elbette olacağı aşağıda ki görsel gibidir.
26 subat deadline’ı görselde de görebileceğiniz üzere akrepler ile yolun engellendiği yere bizi getirmişti :)
Bölüm sonu canavarı gibi basta can ve ben olmak üzere ekip ile nereye geldik lan biz ,bu yolun sonu nereye cıkıyor der gibi birbimizin yüzüne bakıyorduk :)
İlk defa modumun bu kadar düştüğünü hatırlıyorum Hatta can’ın aldıgı bir call’a irem de gelmişti. Ve abi daha ilk günden neden bu kadar sesin içine kaçtı demişti. Cevap veremedim. Gördüğüm manzarayı nasıl izah edebilirdim ki ?
K8s ortamları nispeten geçmiş,configler düzenlenmiş,db ayarları yapılmıs,artifacler ile ilgili sorunlar elimizden geldiğince calısır hale getirilmiş,business eksikler fixlenmiş,data migrationları yapılıp yeni crm , belli bir süreyi cover eden canlı müşteri dataları ile beslenmişti. Bu migrationlar için bir kac defa planlı calısmalar ile gece çalışılmış ,ilk mvp için çok basit bir kurgu olan ama mvp’in de kalbi olan auto ticket atama kurgusu müşteri önüne çıkacak hale gelmişti.
Bir auto ticket atama için Ya Rab, ne sistem design edilmişti !
Başta Can ile beraber , ekibi arkamıza alarak buz kıran gibi ilerlemiş ,her engeli oyle ya da boyle çözüp ,mutfagın içine etmiş ama ilk pastayı da masaya koymustuk.
Ekibin itibarı düzelmiş,yonetimin gazı alınmıs,chapter’ların kaynak ayırmada şüpheye düştüğü proje tekrar hayata dönmüştü. Business geri kalan hayallerini tekrar zihinlerinde rafa kaldırdıgı yerden indirip tekrar gündem etmek için motive olmustu.
İlk demo sonrası şirketin tebrikleri ekibin motivasyonunu ciddi şekilde artırmıs artık devam etmek için bize bir amaç vermişlerdi.
Müşterilerin önüne sunduğumuz ürün test edilirken ve feedbackler toplanıyorken oluşan boşlukta merceği tekrar odaklama fırsatımız olmuştu. Nereleri optimize etmeliydik ?
Topology de bizi en cok yoran ne ise oraya odaklandık.
Elde ettiğimiz topology buydu. Tabi farklı 3rd party kurumlar için geliştirilen servislerinde oldugunu da katarsak 30 adet olması normal ama gereksiz olanları silmemiz,daha clean haline getirdiklerimiz vs derken 20 küsür adet servisimiz olmus oldu.
Aslında daha da basit çözülebileceğini ve totalde 10 mikroservise düşürebileceğimiz bir hedefimizde var. Çünkü transformers turknet evreninin tek gezegeni değil. İlgili servisleri devir teslim ettiğimizde aslında gittiğimiz nokta asagıda ki gibiydi;
Hayalimiz tam buydu.
27 mayıs 2024 deadline’ı — MVP 2
Architecture’ın hard part olan kısımlarını anlamıs, 26 subata kadar optimize etmiş ve en hayati dokunusumuzu sonraya bırakmıstık. Bu 27 mayıs deadline ‘ı aslında bu sürecin evrildiği zamandı.
Yukarıda ki gorselde de gorebileceğiz üzere beraber calıstıgımız squadlar vardı. Bizler yalnız değildik. Ama ne hikmet ise sanki bizden başka takım yokmus gibi her işe el atıp servisleştiriyorduk. Büyük resme baktıgımızda devretmemiz gereken servisler vardı ama biz o ekiplerin servislerinden değil doğrudan doğruya CDC ile dbden data çekiyorduk.
Migrating to microservice database kitabında , son bölümlerinde aslında integration strategies bölümü altında anlatılan birden fazla yontem bulunur.
- Shared Tables
- Database View
- Database Materialized View
- Database Trigger
- Transactional Code
- ETL Tools
- Data Virtualization
- Event Sourcing
- Change Data Capture
CDC görüldüğü gibi en son çaredir. Her yöntemin pros ve cons’u vardır . Burada izlenilen yöntem squadlar ile align olmak yerine ve o ekiplerin varsa apileri ya da topiclerine subscribe olmak gibi yollar izlemek yerine stratejilerin en zoru olan db,devops ve cloud ekiplerine de oldukca fazla efor çıkaran bir yol izlenmiş ve CDC kullanılmıstı.
Zannediyorum her adımda en zor yolu secmek bir güc gosterisiydi. Ya da şirketten intikam almak mıydı bilmiyorum ama üzüldüğüm tek şey transformers ekibinin bu kararlar altında savrulmuş olmasıydı :(
Ekip ile bu deadline zamanı içinde olan quarter da ilk yaptıgımız konu bu integration strategisini nispeten daha kolay olan event sourcing seviyesine cekmekti. Daha once event sourcing dark side adında bir makaleyi noctools ekibini dönüştürdüğümüzü anlattıgım makale de paylasmıstım .
Hiç de kolay değildi. Ama CDC daha zordu :) Çünkü sürekli geri akım yaratıyordu, db load’a sebep oluyordu. Devops’un kafka strimzi gibi aletler ile sürekli bakım yapmasına sebebiyet veriyordu. Hala cdc yapılarımız var ama en can alıcı noktayı fix etsek cok rahat edecektik.
CRM aracının ilk teması bize en yakın olan experience makers ekibi idi. Ve şaşırtıcı bir şekilde şirket içinde tüm platformlardan gelen ticket eventlerini kendi bünyelerinde toplamış ve bir event olarak kafka topiclerine bırakmışlardı. Sanırım bundan daha cok sevindiğim bir şey olamazdı . Hemen migration servislerinin dbden baglantısını kopardık, ilgili topiclere bağladık ve gelen her event için polling publisher yaparak db call ile event’i migrate edip tobe sistemi besledik.
- Hem anti corruption olarak denge bozulmadı
- Geri akım yaratan eventlerden kurtulduk
- %100 asis ile uyum göstermesi istenen sistemin zorluklarından bir tanesini çözmüş olduk
- DB rahatladı
- Tek bir squad’a sıkışmıs iş yükü diğer squad ile paylasıldı
Böylece artık imparatorluk refleksi gosteren ülkeler gibi içeride biriken enerjiyi dışarı yönlendirmeyi başardık ve onehub’ın hedeflerinden biri olan birden fazla takımı ve operasyon ekibini ürüne çekerek kendi quarter hedeflerini artık onehub’da düşünerek belirlemesini sagladık. Hem motivasyon,hem quarter hedefleri için backlog olusturulması hem de transformers ekibi ile yakından calısması gerektiklerini herkes anlamış oldu ama bunu hiç hissettirmeden yapmıs olduk. Dış işleri diplomasisi bu olsa gerek :) Önce sevdir, sonra bağlı kıl, turan devleti gibi g8 zirvesini kur :)
Çünkü onehub sadece bir ekibin support vereceği bir sistem değil, crm olması hasebiyle her takımın funnel’ından geçen business, müşteri sorunlarını çözmek için operator’e hit ettiğinden aslında bir üst akıl niteliğindeydi.
Yani bir operator , bir müşterinin bilgileri ile donatılmıs bir ekrana baktıgında, elinin altında herşeyi bulacak ve onun sorununu en hızlı bir şekilde çözebilecekti. E bu da zaten OKR hedefi değil miydi ?
- 30 günde açılan ticket sayısında düşme
- Müşteriye nitelikli cevap verme süresinde kısalma
- Online işlemlerden açılan ticket’ın ilk karşılama süresinde kısalma
- Modem bilgileri,aktivasyon ticketlar ve geçmişini görüntüleme gibi sayısız feature
müşterilerimize verdiğimiz hizmetin bir funnel’a yayılmıs hali değil miydi ? Funnel’a hizmet eden tüm squadlar bir crm aracında toplanınca onehub oluşmus oluyordu.
Yukarıda ki görselin aslında teknik olarak vücut bulmus hali bu olmalıydı. Bu şekilde mvp 2 de müşterilerimizin önüne konmustu.
Mimarinin davranış patternini tek bir gorsel ile anlatacak olursak,
Ürün her haliyle distributed. Yani cok iyi monitor edilmeliydi. Async sürecler,message broker’da biriken lagler,bunları anlamak için konulması gereken alertlar,hatayı trace etmemiz gereken kibana dashboardları vs gibi süreçler ilerleyen bölümlerde anlatılacaktır.
Crm’e düşen bir ticket , operatore atanıyor,işlemler görülüyor,arıza anında hemen yanımızda ki squad ile genel arıza bildirimi çıkılıyor. Bir alert olduğunda sysops ekibinin mailine düşüyordu.
Bu görselde olduğu gibi transformers’ın onehub öncesi verdiği platform hizmetleri ile onehub sonrası hizmetleri ete kemiğe bürünmüş ve ekibin genel domain sorumluluklarını belirgin hale gelmişti.
Artık “transformers “ , tam manasıyla bir squaddı ve adaptasyonu tam bir yıl sürmüştü. Demek ki agile dönüşüm şirketlerinde mevcut ekipleri squad olarak ayırmak onların kadim domain bilgilerine isim verip, daha anlamlı yönetilmelerini sağlarken yeni açılan squadlarda işler çok kolay ilerlemiyordu. Kareye yuvarlağı oturtmak gibi bazı doku uyuşmazlıkları olabiliyordu .
- dogru backlog
- dogru lead
- dogru pm
- dogru team
- dogru head of engineer manager
ilk düşünülmesi ve sorgulanması gereken konulardı. En azından benim deneyimlediğim kadarıyla bu sürecten çıkarttığım ders buydu.
Leadership perspektif
24 haziran 2024 deadline’ı — MVP 3
MVP 3’e gelindiğinde ekip ve ben çok yorulmustuk. Vaktimizi daha verimli ve efektif geçirmek istemiştik.
Sonuçta kansere dönen ürünün sorunları çözülmüş ve 26 şubattan beri canlıdaydı ve kullanıma açıktı. Tabi müşterilerimizin önüne konulmadan önce şirket içine açılmıştı ve pilot olarak dahil ettiğimiz tüm user’lar kullanabiliyordu.
Q1 ‘nin sonları ve Q2’nin başlarıydı, hatta ortalarıydı diyebilirim. Cross functional team olabilmek için erkendi. Bu konuda cok risk alma şansımız yoktu. Silolaşma vardı ve en hızlı çözüm olarak herkesin bildiği konular üzerine iş bölümleri yaparak Q2’yi yönetme kararı aldık. Kendi verdiğimiz isim ile “Epic Based Sprint Management”.
Epic based sprint management
- epic sorumluları ile konuştuğumuz kanallar olacak
- epic dışındakileri ilgilendiren konular ortak kanalda konuşulup körlük yaratılmayacak
- refinementta align olduktan sonra tech involvement için bir konusu olan öncesinde ilgili epic kanalından yazacak ve tech involvementta herkes blocked olmamış olacak
- boylece her epic sahipleri ve team lead arasında ki alignement epic dışındakileri blocklamayacak
- her quarter epic ve memberler değişecek
- epic based tasklarda iş paylaşımı yaparken direkt ana taska puan veriyoruz. Burda da kişi bazlı done rate ölçerken sadece ana taskı alan kişinin done rate’ni ölçmüş oluyor. Mw frontend ve backend tasklarını epic altında ayrı ayrı açıp puan verebiliriz. Bu da işi yapma zamanımızı daha iyi ölçer ve burdown grafiğindeki hızlı düşüşü görmüş oluruz.
Bu yöntemin feedbackleri çok güzel oldu. Head of engineering manager’ımız Hakan Çelebi’nin halihazırda üst yonetim ile squadlar arasında haritayı gösterdiği bir dashboard’u vardı. Neden bunu ekip seviyesinde de uygulamayalım dedik .
Aslında yönetim ekibi OKR için Enterprise Backlog adında bir user story açıyor. Ve bunun altına kaç takım girdiğini product’ların eline bırakıyordu. Çünkü burada ki silolaşma product manager’lardır. Aynı şekilde bizim ekibe düşen epiclerinde alt kırılımlarını pm ve ben karar vereceksem neden silolaşma olan iş sahiplerine bölmeyelim ki diye düşündük. Başta elbette cross functional team yapısına aykırı ama içinde bulundugumuz durumda zaman kaybına tahammülümüz yoktu. Bir quarter’lık bu yöntemi kullanmalıydık.
Bunun takıma faydası ise,
- her üyenin sahip oldugu bir epic oldu
- her üye quarter’ın sonuna kadar kendisi için anlam ifade ettiği epic’in altında ki taskları done etmek ile mükellefti
- bu taskları neye hit ediyorsa o alanda keşif yapmak zorunda oldugu için onboarding daha anlamlı ve kısıtlı bir alana inmiş oldu. Sonu olmayan bir domain’i keşfetmek bir quarter’a sıgmazdı çünkü :)
Bu şekilde hızımız 2 kat arttı ve çok da yorulmamış olduk. Bir üyenin okr’lerini ölçmek için bu yol işe yaramazdı. Onun için farklı toolumuz var ve dora metriclerini ona göre ölçüyoruz.
Bu yöntem sadece takımın bir squad seviyesinde ki
- her üyenin epic dağımları
- done rate yüzdeleri
- Acık olan pr’larını
- Jira boardda ki task statuslerini tek bir ekrandan takip etmemizi saglıyordu.
Ayrıca,
- her refinementta ne kadar team workload ve chapter workload yarattığımızı bize gösteriyor
- sprint içinde anlık durum
- her dailyde status update için sorulması gereken bir soru ve sorun var ise onu farketmemizi saglıyordu.
Özetle daha anlamlı ve odaklı bir sprint koşmamızı sağlıyor. Bunu sprint kitabından ilham alarak yapmaya calıstık.
Bir kaç gorsel ile örnek vermek gerekirse,
Takımın iş yükü ve bu yükün hangi epiclerden oluştuğunu görebiliyoruz. Tam tersi şekilde sag taraftaki enterprise backlogdan squadlara süzülen epiclerin takım içinde dağımlarını kontrol edebiliyoruz.
Refinement yaparken hangi üyemizin üzerinde ne kadar yük yarattık görebiliyoruz. Rush donemlerinde bu kadar hassas davranacak ve bu detayları düşünecek zamanımız yoktu. Eger unbalance bir durum varsa ekip bunu görüp hemen bayrak kaldırabiliyor. Örnek olarak Burcunun üzerinde yaratılan yüke direkt İrem dikkat cekmişti ve bir sonra ki sprinte assign edilmesi için üzerinde bir taskı drop etmiştik.
Bu şekilde takım için kaynaşma,adalet ve pair kültürünün de oluşmasını hayal etmiştik.Yakında kadın dayanışması yapıp beni kovdurmazlar inş. :)
Takım içinde ki taskların status bazlı dağılım oranlarını ve done rate’lerine olan uzaklığını görebiliyoruz.
Acık olan PR’lar , blocked taskları vs görünce her sabah benim ve ekibimin dailyde veya gün içinde ki çözmemiz gerekenler daha belirginleşmiş oluyor.
Buna socio-techno diyorlar.
- dora metric
- four key metrics
- efective engineering
- productivity
gibi bir çok konu başlıkları var endüstride ama biz kendi el yordamımızla ve basitçe çıkardıgımız metricler ile başta söylediğim dinginliğe kavuşmayı istemiştik. Yoksa bu koşunun sonu uçurumdu :)
Software Systems as Cities
Artan zamanda bu zamana kadar aklıma gelmeyen bir şeyi ögrenmek istemiştim. Biz bu süreçleri işletiyorduk ama bizim as-is olarak adlandırdıgımız ve replatforming’ini gercekleştirdiğimiz customer care , namı deger cc projesi nasıl bir projeydi ? Business ve tasklar ,product ekiplerinden süzülüp geliyordu ama kaynağı yerinde görmek için emektar sistemin nasıl bir mimari ve dependency’lere sahip oldugunu merak etmiştim.
Bir makale karşıma cıktı. Bir doktara teziymiş. Software systems as cities . Yani yazılım sistemlerine bir şehir metaforu ile daha anlaşılır kılıyor. Nasıl bir codebase de yaşadığımızı bir şehir metaforu ile görselleştiriyordu.
Yukarıda da anlattığım üzere, Russell Ackof ; asıl sorunun problemi anlayamamak oldugunu söylemişti. Yani bunca sürec ve serüven aslında sorunun sebebi tam anlasılmadıgı için yaşanmıştı.
Bu site aslında tezi yazan engineer’ın yıllar once publish ettiği blog post’u içeriyor. Tool’u ve onu anlatan makaleyide yayınlamıs. CodeCity aracını indirdiğimde çalışmadı . Çünkü o kadar eskiydi ki , işletim sistemi versiyonuna takılmıştı.
Tabi codebase’in ham hali elimizde olmadığından tekrar derlenebilecek imkanı yoktu. Benim için önemli olan konu ise literatürde böyle bir alan bulmamdı ve bunu yapan başka tool’lar var mı diye araştırdım.
böyle bir makale ve makaleye konu olan tool’un bir github reposu var.
Tabi ilk çalıştırdıgım da çalışmadı. Bir sürü python paket sorunu çıkardı. VPN dışında güvenli bir ağ olmadığında çalışmayan scripleri vs derken yine elimde kaldı tool.
Aracı tamir ettim. Eksiklerini fix ettim. Dockerize edip developer’ın dogru işletim sistemini seçmek ve onun paket versiyonları ile ugraşmamasını sağladım. Bir ad bile koydum . Eagle :)
bu repoyu publish ettim.
CC böyle bir projeydi. Şehir hatları metro istasyonları haritası gibiydi :)
Logical ve semantic bağlamları merge edip python pandas kütüphesi bu şekilde bir görsel olusturuyordu.
Yer altı haritasına aşağıdan bakalım ,
Domain driven design da gecen Big Ball of Mud sanırım buydu :)
Hakan Çelebinin oturttugu bir bigroom kültürü vardı. Sistem squadların önceden hazırlanarak şirkete gidip bir gün içinde hem sosyal etkinlik gibi kaynaşıp aynı zamanda birbirlerine hit eden işleri planlayıp align olması üzerine kuruluydu.
Kafamda şöyle bir sorun vardı,
- takımlar kendi işlerini planlıyorlar
- şirkete gidiyorlar
- diger takımlar ile align oluyorlar
- sonra quarter içinde conflictler olabiliyor ve anlık rush olabiliyorlar
Belki sadece bizim takımda vardır diye düşündüm. Diger lider arkadaslara da başlarda böyle gelmiş. Aşağı yukarı başlarda alignement elbette sancılı olur ama zamanla oturmustu.
Ben yine bunun sebebini merak ettim . Replatforming’i diger şirket deneyimlerime gore burada bize zor kılan konunun sebebini araştırmak istedim. Ackof’un dediği problemi anlayamamak deyimi aslında ipin ucunu bu tool ile yakalamısken bırakmamama sebep oldu.
Bu görselde anlaşılacağı üzere aslında zannımca sorun şu,
- yönetim okr koyuyor
- epicler squadlara iniyor
- squadlar hazırlanıp bigroomda align oluyorlar
- ama quarter içinde ara ara rush yasıyolar .
Yani evdeki hesap neden çarsıya uymuyor ?
Sebebi ise her takım kendi içinde bir şirket gibi , teoride de öyle ama aynı codebase üzerinden birbirlerine göbekten bağlı. Görselde ki farklı kümeleşmeler de şunu gösteriyor,semantic bağlam commitlerin hit ettiği class ve paketleri cover ediyor ve commitlerin change’e uğrattığı file set’i ölçüyor. Böylece herkes codebase’den bir parsel seçmiş ve tüm dünyasını orada yasıyor . Ama aslında hemen yanında ki squad’ın alanına girdiğini bilmiyor. Kümelenmelerin aralarının cok ayrı olması kuyrukların birbirlerine değmediği anlamına geliyor ama aslında bir epic’in squadlara hit eden ihtiyacları ortaya cıktıgında quarter içinde ekipler halay havasına geçiyorlar :)
Ortak file’lara hit eden commitler farklı takımlardan geliyor ve aralarında ciddi bağ oluşturuyor. Class ve paketler şehir metaforunda binaları oluşturuyor ama sokaklar ise bu commitlerin hit ettiği ortak file’lara olan bağlantılar ile ortaya çıkıyor.
Örnek ticket mikroservisine baktığımda ise görsel şu şekildeydi,
CC’nin ticket management süreci , vali kebabı ise
Onehub’ın ticket management süreci , bunun sosu gibi bişeydi :)
Sanırım mikroservisleri çekici yapanda bu idi .
Tabi ben bunları görüp ,düşünürken bir yaş daha atladım. 33 iken 34 felan oldum ama bir bakmışım lansman tarihi gelmiş :)
8 temmuz 2024 — lansman
MVP 3 bitmişti.
Ürün kademeli bir şekilde netuzman adını verdiğimiz operatorlerimizin önüne açılıyordu. Yukarıda beni renkten renge sokan görselleri olusturan emektar CC projesinden yavas yavas Onehub’a göç baslamıştı.
Turknet’in müşteri destek üniteleri türkiye genelinde verdiği hizmetlere göre bölünen takımlar ile yönetiliyordu.
Örnek vermek gerekirse ürünümüz aşağıdaki timeline’a göre parça parça ekiplerin önüne açılmaya başladı.
CTO’muz Doğan Aydın’ın deyimiyle , white boardda prototipini çizdiğimiz ürün artık ete kemiğe bürünmüş ve kullanıcılarını bekliyordu.
Lansman sürecinde en çok ticket atama kurgusuyla alakalı sorunlar yaşadık ve feedbackler aldık. En çok oradan feedback alınca da acaba auto ticket atama mvp için erken miydi diye düşünmedik desek yalan olur.
Ama olan olmuştu ,artık geri dönüş yoktu. Var gücümüzle ne kadar bug ,kurguda ne kadar eksiklikler varsa çözdük. Atama senaryolarını tekrar tekrar okuduk,kodu hatim ettik. Operatorlerimiz ile ayrı geçirdiğimiz bir gün bile olmadı. Yediğimiz içtiğimiz artık aynıydı :)
Hepimiz olası bir eleman ihtiyacında görev alacak kadar çağrı nasıl çözülür,dönüş nasıl yapılır,nasıl hizmet verilir vs ögrenmiştik :)
Kendimizde paralelde,
- ne kadar user’ımız var
- toplam ne kadar ticket atadık
- operator dagılımları
- operator status’leri gibi metricleri çıkarttık.
Elimizden geldiğince yaptıgımız her feature ‘ı ve attıgımız her adımı ölçmeye başladık. Yukarıda ki görsel buna bir örnek teşkil etmektedir.
Management perspektif
Ekip ilk sınavı vermişti. Onehub’dan önce irili ufaklı bir çok servisi platform hizmeti olarak veriyordu. Artık onehub’da 3. ürünü olmuştu. Böylece 3 ürünü olan bir takım haline dönüşmüştü.
- oim ekranlarına verilen authentication hizmeti
- central notificaton system olarak isimlendirelen notification hizmeti
- ve son olarak emektar cc’nin şimdilik ticket süreclerinin bir kısmını üstüne alan onehub’a hizmet verecekti.
Tabi bu süreç ekip içinde artık canlı müşterilerimiz oldugu için günlük support verme ihtiyacı doğurmustu. Squad takımının sprintleri planlanırken aslında engineer’ların support için de zaman ayırması gerekiyordu.
Hakan Çelebi’nin şu postunu belki hatırlarsınız ,
Sağdaki piramidin en üstünde aslında takımın ilk iki ürününe bu zamana kadar cok da fazla support ihtiyacı yaratmayan müşteriler yerine onehub müşterileri oturmuştu. Ekibin bir sprintte çalışma düzeni artık değişecekti. Ve her engineer hizmetkar engineer’a dönüşecekti.
Bunu sistematik hale getirmek için oncall management system adını verdiğimiz bir rituel kullanmayı seçtik.
2 tane open source tool araştırdık ve önümüzde ki günlerde bunlardan birini kullanmayı planlıyoruz ama bu süre zarfında turknet’in hali hazırda içeride kullandıgı atlassian ürününe entegre çalışan nöbetçi çizelgesi sistemine dahil olduk.
Geçici bir süre bunu kullanmayı düşünüyoruz. Ekipten herkes bu support sürecinin her güne bir ekip üyesi bakacak şekilde dönüyor ve sprint süresi boyunca müşterilerimizden gelen sorun,feedback,anlık operasyonel işlemlere destek oluyorlar.
Başlıca avantajları,
- domain learning ile cross functional team özelliği kazanma
- customer feedbacklerden product minded bir anlayış kazanma
- büyük resmi görme ihtiyacı
- evdeki hesap çarsıya uydu mu diye muhakeme yeteneği kazanmak
- sıkıcı süreçleri otomasyona bağlama ve bunun ile ilgili gerekirse refinementta task alma esnekliği
Dezavantajları,
- başlarda motive edici ,sonra sıkıcı olabiliyor
- overdose yaratabiliyor
- eğer zamanını yönetmez isen sprint işlerine odaklanamıyorsun
gibi pros,consları var . Ama bunların hepsinin çözümü de efective engineer kitabında var. Bunu da ekip olarak birbirlerimize gelişim planları hazırlayarak paylaşıyoruz.
Product minded software engineering kitabında yeri olan cygnus method tam da bu idi.
Artık bir developer’ın habitatları ve günlük rutinlerinin zihninde ,görselde ki gibi şekillenmesini istiyoruz.
Quarter based plan
Bu support süreçlerinden yola çıkarak aslında bir backlog olusuyor.
- Neye ne kadar zaman harcıyoruz ?
- Hangi süreçler bizim domain’imize girmiş ve devredilebilir ?
- DBA,Devops ,QA chapter isterlerinin toplanması ve beklentlerin quarterlara girmesi
gibi bir çok sürecin aslında gelecek quarterın backlogunu oluşturması sağlanabiliyor. İlk bigroom’da sıfır bilgi ile şirkete gidip sudan çıkmış balığa döndüğüm durum aslında 6 ay sonra daha bilincli bir şekilde bigroom’a gitmemi sağladı.
Makalenin başlarında bahsettiğim onehub’dan istenenlerin içinde diger telekom squadlarınında bu crm aracına dahil olması bekleniyordu. Şimdi geldiğimiz noktada aslında her ekibin onehub’a öyle ya da böyle dahil olması ,bundan sonra da o ekiplerin backloglarına giren tasklara sebep olduğundan bigroom alignement daha bir anlam kazandı.
Artık biz çok fazla squadlara gitmemiz yerine, squadlar bize gelmeye başladılar. Onehub mimarisinin tek darbogazı kalmıştı . O da middleware idi . Bu durumda onu da forklayarak çözdük. Bu yöntem de software architecture hard parts kitabında anlatılıyor.
Bunun ilk örneği satış ekibinin middleware’ini forklayıp aynı ürüne bağımsız olarak hizmet etmesini sağlamamızdı.
Artık satış ekibi de onehub’da yerini almaya başladı. Ve Onehub 2 ayrı tema ile açılıyor.
Sektörde muadilleri çok olan crm araçlarından ilham alınarak eklendi. Tabi burada Sevgili Frontend Developer arkadasımız Nurullah Ünlü’ye frontend mimarisine böyle bir esneklik kazandırdıgı için minnettarız.
Crm aracı kullanıldıkca daha cok adaptasyonun gerceklesmesi, zamanla aktivasyon,saha vb ekiplerinde dahil olunması mümkün hale gelecektir. Her ekip kendi context’ine uygun bir kutucugun arkasında kendi domain serüvenini taşıyacaktır. Onehub ismi gibi her squad’ı tek bir çatı altında toplayacak ama hiç birinin kuyrugunu birbirine değdirmeyecektir. Yani en azından umdugumuz bu :)
- Her squad’ın kendi middleware’ini kendi geliştirmesi
- Kendine ait mikroservisleri dönüştürmesi ve ekranlara bağlaması
- Kendine ait mikroservislerin db’lerini yonetmesi
- Kendi tech stack’ini seçebilme özgürlüğü
- Kendi ci/cd pipeline’larını design edip deployment cıkma esnekliği gibi bir yetenek kazandırmıs olduk
İlk adımının transformers ekibi tarafından atılan bu adımın diger squad takımlarına bir yol açtıgını düşünüyoruz. Tabi yine ortak kullanım dataları,servisleri vs olacaktır ama bu dependecy’lerin loosely couple olması hedeflenmektedir.
Asansörün en üstüne çıkmak hiç kolay olmadı ama şuan geldiğimiz nokta ise artık business ve it ‘yi connect edeceğimiz bir noktaydı. İnşAllah bundan sonra da tasarımsal,kurgusal bir sorun çıkmaz ve roadmap’e uygun bir şekilde ilerleriz.
Aşagıdaki görsel aslında, business’ın dilini konusmaya başladıgımızı gösteren bir asanör metaforu . Her ürün hayaller ,fikirler ile başlar ama en aşağıda ki makine dairesi ile en yukarıda ki yonetim odası arasında ki bağ doğru kurulmaz ise asansör faciası olabilir. Ürünü live edene kadar ki hissettiğim duygu acaba hangi katta tıkanacak veya hangi katta çakılacağız olmustu :)
Sonra ki adımlarımız ise artık business ve tech ekibi olarak roadmap’e devam edip , diğer turk telekom fiber ve vae hizmetleri verdiğimiz müşterilerimizi karsılayan operator takımlarının önüne bu ürünü açmak olacaktır.
Onunda deadline ‘ı cok da uzak değil :)
Son olarak;
Core Team
- bilal islam — lead
- atilla kızıltan — pm
- irem simsar — developer
- burcu öztaş — developer
- mehmet başeğmez — developer
- can kurucu — developer
- muhammet yetiş — ex-developer
Chapters
- aysenur ulusu — QA
- nurullah unlu — Frontend
- emrah aybastı — UX
- ensar bozdoğan — Devops
Stake holders
- hakan çelebi — engineering manager
- umut tek — experience makers team lead
- behire tapınç — product lead
- murat özbek — head of product
Arkadaşlarıma bu sancılı süreç bizi psikolojik olarak çok yıpratsa da 8 ay boyunca motivasyonlarından hiç bir şey kaybetmeden hedefe kitlendikleri için sonsuz teşekkür ederim.
Bu sürecin tamamen teknik , data ve infrastructure özelinde ki olan yazımızı da serinin 2. post’u olarak paylaşmayı düşünüyoruz.
Görselden de anlaşılacağı üzere doğru ürün dogru yetkinlikte ki ekip ile geliştirilir. Ve bu dengeyi sağlamak kolay olmadı ve hala kolay değil 🙂
Mühendislik ve aynı zamanda yönetim becerilerimizi geliştirmemiz konusunda bize ilham kaynagı olan bazı kitaplar;
software architecture : hard parts
software architecture fundamentals
the sprint
yönetim ve organizasyon
migrating to microservice databases
software system as cities
the efective engineer
product minded software engineer
A Lessons in Learned
PS : The art of system design is the Picking the right architecture = Picking the right battles + Managing trade-offs
Onehub be with you 🙂
