#Experience
Sizga bir sir ochaman. Yaxshi va yomon dasturchi o'rtasidagi farq quyidagicha deb bilaman:
Yomon dasturchi:
1. Kod yozadi
2. Bug fix qiladi
3. Va yaxshilashni o'ylab ko'radi
Yaxshi dasturchi:
1. Loyihani dizaynini tuzadi va boshqalar bilan discuss qiladi
2. Kod yozib ishga tushiradi
3. Muhtojlik sezilganda yaxshilaydi
Kod yozish hech qachon 1-qadam bo'la olmaydi. Bo'ldimi, demak dastur emas muammo yaratibsiz degani!
@otabekswe
Sizga bir sir ochaman. Yaxshi va yomon dasturchi o'rtasidagi farq quyidagicha deb bilaman:
Yomon dasturchi:
1. Kod yozadi
2. Bug fix qiladi
3. Va yaxshilashni o'ylab ko'radi
Yaxshi dasturchi:
1. Loyihani dizaynini tuzadi va boshqalar bilan discuss qiladi
2. Kod yozib ishga tushiradi
3. Muhtojlik sezilganda yaxshilaydi
Kod yozish hech qachon 1-qadam bo'la olmaydi. Bo'ldimi, demak dastur emas muammo yaratibsiz degani!
@otabekswe
#experience
Kecha qiziq ishlar bo'ldi. Jamoada ansible bilan file transferda muammo bo'layotgani, bandwith oshib ketgani haqida aytishdi. Ya'ni muammo juda ko'p fayllar tarmoqda transfer bo'lsa bandwith oshib ketayotgan ekan. Bu muammoni o'z zimmamga oldim. Ozgina research qilib, bergan yechimim jamoani qiziqtirdi. Muammoga yechimni juda oddiy tilda yozdim:compress (archive all files) before sending
Yechimni discuss qildik va ba'zi pointlarga to'xtalib o'tdim. Bir nechta fayllarni yuborish o'rniga barchasini (compress) archive qilib yuborish yaxshi idea bo'ldi. Jarayonni to'liq test qilib ko'rdik, natija 1 minutdan -> 20 sekundga tushdi. Boshida HTTPS beradigan TLS xavfsizligi yaxshi deb turgandim. Ammo bu faqat file transfer vaqtidagina xavfsiz, fayl manzilga tushgandan keyin u ochiq bo'lishini aytishdi. Ba'zi fayllarni hech kim ocholmasligi kerakligi uchun uni Private (va Public) keydan tashqari encrypt/decrypt qilish uchun imkoniyat qo'shdim.
Kattaroq va ko'proq fayllar bilan sinab ko'rdik (log, va juda ko'p config fayllar bilan), natija juda zo'r. Eski holatdagi o'tkazish uslubi 3 minut oldi. Yangi xolatdagi o'tkazish esa 43.12 sekund. Compression algoritmlari haqida yana ham ko'proq narsa o'rganib chiqdim, qiziq tajriba bo'ldi.
Qiziq narsa eshitdim: Lucerne shahridan Zurich shahrigacha har kuni poyezd orqali 1TB ma'lumot berib yuborilar ekan. (Esimda qolmadi nomi) Qanaqadir labaratoriya va uni tahlil qiladigan korpuslar boshqa-boshqa joyda joylashgani uchun, tarmoq orqali ma'lumotni yuborgandan, uni poyezda yuborish tezroq bo'lar ekan. Chunki uni hali process ham qilish kerak, unga ham vaqt oladida.
Updated:
Katta Data Center levelda ham test qilib ko'rdik, natija 1000x bo'ldi. Ya'ni bu yerda time complexity O(days) -> O(minutes) o'zgardi.
Kecha qiziq ishlar bo'ldi. Jamoada ansible bilan file transferda muammo bo'layotgani, bandwith oshib ketgani haqida aytishdi. Ya'ni muammo juda ko'p fayllar tarmoqda transfer bo'lsa bandwith oshib ketayotgan ekan. Bu muammoni o'z zimmamga oldim. Ozgina research qilib, bergan yechimim jamoani qiziqtirdi. Muammoga yechimni juda oddiy tilda yozdim:
Yechimni discuss qildik va ba'zi pointlarga to'xtalib o'tdim. Bir nechta fayllarni yuborish o'rniga barchasini (compress) archive qilib yuborish yaxshi idea bo'ldi. Jarayonni to'liq test qilib ko'rdik, natija 1 minutdan -> 20 sekundga tushdi. Boshida HTTPS beradigan TLS xavfsizligi yaxshi deb turgandim. Ammo bu faqat file transfer vaqtidagina xavfsiz, fayl manzilga tushgandan keyin u ochiq bo'lishini aytishdi. Ba'zi fayllarni hech kim ocholmasligi kerakligi uchun uni Private (va Public) keydan tashqari encrypt/decrypt qilish uchun imkoniyat qo'shdim.
Kattaroq va ko'proq fayllar bilan sinab ko'rdik (log, va juda ko'p config fayllar bilan), natija juda zo'r. Eski holatdagi o'tkazish uslubi 3 minut oldi. Yangi xolatdagi o'tkazish esa 43.12 sekund. Compression algoritmlari haqida yana ham ko'proq narsa o'rganib chiqdim, qiziq tajriba bo'ldi.
Qiziq narsa eshitdim: Lucerne shahridan Zurich shahrigacha har kuni poyezd orqali 1TB ma'lumot berib yuborilar ekan. (Esimda qolmadi nomi) Qanaqadir labaratoriya va uni tahlil qiladigan korpuslar boshqa-boshqa joyda joylashgani uchun, tarmoq orqali ma'lumotni yuborgandan, uni poyezda yuborish tezroq bo'lar ekan. Chunki uni hali process ham qilish kerak, unga ham vaqt oladida.
Updated:
Katta Data Center levelda ham test qilib ko'rdik, natija 1000x bo'ldi. Ya'ni bu yerda time complexity O(days) -> O(minutes) o'zgardi.
#experience
Twitterda, boshqa kichik chatlarda va savollar ichida eng mashxurlaridan biri bu dasturlash tili tanlash haqida bo'ladi. Men o'z tajribamdan kelib chiqib sizga bir maslahat bermoqchiman.
Agar siz kamroq xato qilishni va kod yozishni, ko'proq va tezroq natija olishni istasangiz JavaScript va Python eng zo'r tillar xisoblanadi.
Dasturlaringizda kamroq bug'lar chiqishini va yaxshiroq ishlashini istasangiz sizga qattiqo'l va ma'lumotlar turiga juda qattiq e'tibor beradigan til kerak bo'ladi, misol uchun Java. Java ham interpreted ham compiled til xisoblangani uchun interpreted tillarga nisbatan tezroq va xavfsizroq.
Agar sizga xotira bilan ishlay oladigan (pointers) ammo GC (Garbage collector) til kerak bo'lsa demak siz Go ni tanlashingiz kerak. Go juda tez va juda ko'p boshqaruvni o'zingizga olishingiz uchun imkoniyat beradigan tillardan. Shuning uchun siz Java ni emas balkim Go ni ko'plab infrastruktura leveldagi dasturlarni ishlab chiqishda ishlatilayotganini ko'rasiz.
Agar sizga real-time ishlaydigan va juda tezkor dastur qurish kerak bo'lsa GC'dan voz kechgan tillarni tanlashigniz kerak misol uchun Rust va C++. GC mavjud bo'lgan tillarda dasturingiz orada pauza qiladi, chunki xotirani scan qilib undagi keraksiz ma'lumotlarni tozalash ham katta resurs xarajat qiladi. Shuning uchun ham Telegram C++ ni tanlgan (boshqa sabablar ham bor albatta).
Meta programming yoqtiradiganlar bor bo'lishi mumkin. Qoidalar yozish, xotira boshqaruvi, system call'lar, embedded system bularni barchasi uchun C va Zig ideal til. Ammo bu tillar bilan o'zingizga pichoq tiqib olishingiz ham mumkin, juda ehtiyotkorlik talab qiladi, chunki bularda hech qanday chegara yo'q.
Perfeksionistlar uchun Haskell tavsiya qilinadi, bu til haqida boshqa gap yo'q menimcha ; )
O'ta performance shaydosi va sabrli bo'lsangiz, COBOL yoki Assembly da kod yozing.
Bu fikrlar 100% to'g'ri bo'lmasligi mumkin, ammo shaxsiy tajribamdan ko'rganlarimni bo'lishdim, siz nima fikrdasiz?
Twitterda, boshqa kichik chatlarda va savollar ichida eng mashxurlaridan biri bu dasturlash tili tanlash haqida bo'ladi. Men o'z tajribamdan kelib chiqib sizga bir maslahat bermoqchiman.
Agar siz kamroq xato qilishni va kod yozishni, ko'proq va tezroq natija olishni istasangiz JavaScript va Python eng zo'r tillar xisoblanadi.
Dasturlaringizda kamroq bug'lar chiqishini va yaxshiroq ishlashini istasangiz sizga qattiqo'l va ma'lumotlar turiga juda qattiq e'tibor beradigan til kerak bo'ladi, misol uchun Java. Java ham interpreted ham compiled til xisoblangani uchun interpreted tillarga nisbatan tezroq va xavfsizroq.
Agar sizga xotira bilan ishlay oladigan (pointers) ammo GC (Garbage collector) til kerak bo'lsa demak siz Go ni tanlashingiz kerak. Go juda tez va juda ko'p boshqaruvni o'zingizga olishingiz uchun imkoniyat beradigan tillardan. Shuning uchun siz Java ni emas balkim Go ni ko'plab infrastruktura leveldagi dasturlarni ishlab chiqishda ishlatilayotganini ko'rasiz.
Agar sizga real-time ishlaydigan va juda tezkor dastur qurish kerak bo'lsa GC'dan voz kechgan tillarni tanlashigniz kerak misol uchun Rust va C++. GC mavjud bo'lgan tillarda dasturingiz orada pauza qiladi, chunki xotirani scan qilib undagi keraksiz ma'lumotlarni tozalash ham katta resurs xarajat qiladi. Shuning uchun ham Telegram C++ ni tanlgan (boshqa sabablar ham bor albatta).
GC ni ko'p kamchiliklari bor aynan gap performance va resource usage haqida ketganda
Meta programming yoqtiradiganlar bor bo'lishi mumkin. Qoidalar yozish, xotira boshqaruvi, system call'lar, embedded system bularni barchasi uchun C va Zig ideal til. Ammo bu tillar bilan o'zingizga pichoq tiqib olishingiz ham mumkin, juda ehtiyotkorlik talab qiladi, chunki bularda hech qanday chegara yo'q.
Perfeksionistlar uchun Haskell tavsiya qilinadi, bu til haqida boshqa gap yo'q menimcha ; )
O'ta performance shaydosi va sabrli bo'lsangiz, COBOL yoki Assembly da kod yozing.
Bu fikrlar 100% to'g'ri bo'lmasligi mumkin, ammo shaxsiy tajribamdan ko'rganlarimni bo'lishdim, siz nima fikrdasiz?
#experience
Bizning jamoa infrastrukturadagi dasturlarni maintain (qo'llab quvatlab turadi) qiladi. Ish boshlaganimdan 3 oy o'tib menga ham networking'da bir qiziq loyiha berildi va loyiha kodi asosan Rust'da yozilgan ekan (undan oldin asosan C++ da bo'lgan ekan yechim). Loyihani tushunib olishga va Rustga ko'nikishga biroz vaqt ketdi.
Loyiha maqsadi asosan kuniga bir necha ming terabaytlab ma'lumot almashadigan serverlar o'rtasida reliable (ishonchli) yechim qilish bo'lgan. Bu juda katta masshtabli loyiha. Loyihada socket connection, encoding/decoding, async support, va juda ko'p boshqa omillar ro'l o'ynashini juda qiziq dokumentatsiya qilib yozib chiqishgan ekan.
Ushbu loyiha uchun, Go GC (Garbage collector) bor tillardan xisoblangani uchun unda latency (kechikish) tez-tez uchragan ekan (GC spikes), ayniqsa uni grafana bilan monitoring qilganda juda bilindi. Xotiradan ishlatilmayotgan ma'lumotlar darhol o'chishini o'rniga GC ni uyg'onib xotirani scan qilishini kutadi va natijada latency baydo bo'ladi.
Rust meni lol qoldirgan tomoni bu CC (Concurrency Control) bo'ldi. Race condition dan Compile-time da qutilish imkoniyatini berar ekan. Yana bir tomoni Go'da Goroutine'lar runtime-managed, Rust esa sizga threading model tanlash va boshqarishni manually imkon beradi (o'z tabingizga qarab ishlatasiz degani). Data sharing bo'yicha ham Send va Sync yechimlari o'ta go'zal ishlagan, sizga resourslar aro ma'lumotni bo'lishishni ham o'zingiz tanlaysiz (o'zingiz boshqarasiz).
Rust'ni maqtash emas shunchaki undagi xotira bilan ishlash (Memory control) tizimi shunchalik yaxshi ishlaganini va nima uchun ayan Rust memory safe ekanligini qisman, aniqroq tushunib oldim deb o'ylayman.
Misol uchun Go dasturlash tilida mana bunday ish qilsangiz nimalar bo'ladi:
Hozir siz:
- gorutine'lar (map, slices, counters, ...) o'rtasida state share qildingiz
- Agar to'g'ri lock qila olmasangiz, data race yuzaga keladi.
- Channel buffer juda kichik bo'lsa, deadlock'ga sabab bo'ladi
- Goroutine leak bo'lsa, silent memory bloat (dastur siz o'ylagandan ko'ra ko'proq resurs yeyishni boshlaydi) sodir bo'ladi
Bunday ishlarni to'liq o'z nazoratingizga olishingiz uchun sizga low-level til kerak bo'ladi, misol uchun Rust yoki C++. O'sha loyihani 25-30% hali ham C++ da turadi, Rust'ni tanlashganini yana bir tomoni aynan o'sha modellarni extend (kengaytirib) qilib ishlatish bo'lgan bo'lsa kerak.
Post ancha uzunroq va sizga tushunarsizroq bo'lgan bo'lishi mumkin. Ammo xavotir olmang, otabek.io da bunday postlarni tushunishingiz uchun ko'proq soddaroq postlar yozishga harakat qilaman. Rust'ni doim ishlatmasakda ammo o'rganayabmiz sekin-asta. Shuning uchun xatolar bo'lsa tushunasiz deb o'ylayman.
Bizning jamoa infrastrukturadagi dasturlarni maintain (qo'llab quvatlab turadi) qiladi. Ish boshlaganimdan 3 oy o'tib menga ham networking'da bir qiziq loyiha berildi va loyiha kodi asosan Rust'da yozilgan ekan (undan oldin asosan C++ da bo'lgan ekan yechim). Loyihani tushunib olishga va Rustga ko'nikishga biroz vaqt ketdi.
Loyiha maqsadi asosan kuniga bir necha ming terabaytlab ma'lumot almashadigan serverlar o'rtasida reliable (ishonchli) yechim qilish bo'lgan. Bu juda katta masshtabli loyiha. Loyihada socket connection, encoding/decoding, async support, va juda ko'p boshqa omillar ro'l o'ynashini juda qiziq dokumentatsiya qilib yozib chiqishgan ekan.
Ushbu loyiha uchun, Go GC (Garbage collector) bor tillardan xisoblangani uchun unda latency (kechikish) tez-tez uchragan ekan (GC spikes), ayniqsa uni grafana bilan monitoring qilganda juda bilindi. Xotiradan ishlatilmayotgan ma'lumotlar darhol o'chishini o'rniga GC ni uyg'onib xotirani scan qilishini kutadi va natijada latency baydo bo'ladi.
Rust meni lol qoldirgan tomoni bu CC (Concurrency Control) bo'ldi. Race condition dan Compile-time da qutilish imkoniyatini berar ekan. Yana bir tomoni Go'da Goroutine'lar runtime-managed, Rust esa sizga threading model tanlash va boshqarishni manually imkon beradi (o'z tabingizga qarab ishlatasiz degani). Data sharing bo'yicha ham Send va Sync yechimlari o'ta go'zal ishlagan, sizga resourslar aro ma'lumotni bo'lishishni ham o'zingiz tanlaysiz (o'zingiz boshqarasiz).
Rust'ni maqtash emas shunchaki undagi xotira bilan ishlash (Memory control) tizimi shunchalik yaxshi ishlaganini va nima uchun ayan Rust memory safe ekanligini qisman, aniqroq tushunib oldim deb o'ylayman.
Misol uchun Go dasturlash tilida mana bunday ish qilsangiz nimalar bo'ladi:
go handleConnection(conn)
Hozir siz:
- gorutine'lar (map, slices, counters, ...) o'rtasida state share qildingiz
- Agar to'g'ri lock qila olmasangiz, data race yuzaga keladi.
- Channel buffer juda kichik bo'lsa, deadlock'ga sabab bo'ladi
- Goroutine leak bo'lsa, silent memory bloat (dastur siz o'ylagandan ko'ra ko'proq resurs yeyishni boshlaydi) sodir bo'ladi
Bunday ishlarni to'liq o'z nazoratingizga olishingiz uchun sizga low-level til kerak bo'ladi, misol uchun Rust yoki C++. O'sha loyihani 25-30% hali ham C++ da turadi, Rust'ni tanlashganini yana bir tomoni aynan o'sha modellarni extend (kengaytirib) qilib ishlatish bo'lgan bo'lsa kerak.
Post ancha uzunroq va sizga tushunarsizroq bo'lgan bo'lishi mumkin. Ammo xavotir olmang, otabek.io da bunday postlarni tushunishingiz uchun ko'proq soddaroq postlar yozishga harakat qilaman. Rust'ni doim ishlatmasakda ammo o'rganayabmiz sekin-asta. Shuning uchun xatolar bo'lsa tushunasiz deb o'ylayman.
#experience
Ikki hafta oldin kompaniyada TechTalk’da "Memory leak" mavzusida ma’ruza berdim. 51 ta turli xil jamoalardan muhandislar kirib eshitishdi, to‘g‘risi ancha qo‘rquv bosdi. Memory leak juda nozik mavzu, agar siz ishlatayotgan tilni mohiyatini yaxshi bilmasangiz xotira bilan ishlashda juda chiroyli muammolarga duch kelishingiz mumkin. Biz asosan Python va Go tillaridan misollar ko‘rib ketdik.
Online meeting orqali qatnasha olganlar juda ajoyib feedback yozishdi. Ularni har hafta o‘qib maza qilyapman. Ma’ruzamning videosi chiqqanidan so‘ng tomosha qilganlar ham yaxshi xabarlar yozishdi, ammo bir yigitni xabari e’tiborimni tortdi. U bu ma’ruzadan keyin tizimdagi memory leak’ni topishga muvaffaq bo‘lgan.
Ular ishlaydigan tizim kodi Java’da yozilgan ekan. Bilamizki Java ham Garbage collected til hisoblanadi. GC xotirani tozalash uchun reference counting dan foydalanadi. Agar obyekt ishlatiladigan bo‘lsa uni reference count odatda +1 ga teng bo‘ladi. GC juda aqlli bo‘lgani bilan, benuqson emas.
U yozgan xabarda inner class yozish va uni xotiraga ta’siri haqida gap ketgan. Men uning ma’ruzamda memory leak’ga sabab bo‘lishi mumkinligi haqida misollar bilan yoritib o‘tgan edim.
Muamo outer class obyekti o‘chib ketganiga qaramay inner class obyekti ishlatilishda davom etishida. Qanday qilib inner class obyekti o‘chib ketmadi deyishingiz mumkin. Sabab, unga reference saqlanib qolgan (ref count +1). Dastur to‘laoqnli to‘g‘ri ishlashini ta’minlash uchun uni o‘chib ketishini ham o‘zingiz dasturlashingizga to‘g‘ri keladi.
Yana bir bola o‘zining frontend loyhasidan memory leak topganini yozibdi. Closures - outer scope’dagi o‘zgaruvchilarni eslab qola oladi. Agar obyektni saqlab qolsangiz, u reference qilgan qiymatlar ham o‘chmay saqlanib turaveradi degani. Agar ehtiyot bo‘lmasangiz Javascript kodingiz, browser’da leak’ga sababchi ishlar qilishi juda osonligini ko‘rdim. U yuborgan koddan parcha:
Bunday muammolar ko‘p. Ma’ruza berish orqali faqat o‘rgatmadim, balkim ko‘p o‘rgandim ham. Videoni ommaviy ulashish imkoni bo‘lsa, ulashishni reja qilib turibman. Sizga ham bir parcha tajriba ilindim : )
Ikki hafta oldin kompaniyada TechTalk’da "Memory leak" mavzusida ma’ruza berdim. 51 ta turli xil jamoalardan muhandislar kirib eshitishdi, to‘g‘risi ancha qo‘rquv bosdi. Memory leak juda nozik mavzu, agar siz ishlatayotgan tilni mohiyatini yaxshi bilmasangiz xotira bilan ishlashda juda chiroyli muammolarga duch kelishingiz mumkin. Biz asosan Python va Go tillaridan misollar ko‘rib ketdik.
Online meeting orqali qatnasha olganlar juda ajoyib feedback yozishdi. Ularni har hafta o‘qib maza qilyapman. Ma’ruzamning videosi chiqqanidan so‘ng tomosha qilganlar ham yaxshi xabarlar yozishdi, ammo bir yigitni xabari e’tiborimni tortdi. U bu ma’ruzadan keyin tizimdagi memory leak’ni topishga muvaffaq bo‘lgan.
Ular ishlaydigan tizim kodi Java’da yozilgan ekan. Bilamizki Java ham Garbage collected til hisoblanadi. GC xotirani tozalash uchun reference counting dan foydalanadi. Agar obyekt ishlatiladigan bo‘lsa uni reference count odatda +1 ga teng bo‘ladi. GC juda aqlli bo‘lgani bilan, benuqson emas.
U yozgan xabarda inner class yozish va uni xotiraga ta’siri haqida gap ketgan. Men uning ma’ruzamda memory leak’ga sabab bo‘lishi mumkinligi haqida misollar bilan yoritib o‘tgan edim.
Muamo outer class obyekti o‘chib ketganiga qaramay inner class obyekti ishlatilishda davom etishida. Qanday qilib inner class obyekti o‘chib ketmadi deyishingiz mumkin. Sabab, unga reference saqlanib qolgan (ref count +1). Dastur to‘laoqnli to‘g‘ri ishlashini ta’minlash uchun uni o‘chib ketishini ham o‘zingiz dasturlashingizga to‘g‘ri keladi.
Yana bir bola o‘zining frontend loyhasidan memory leak topganini yozibdi. Closures - outer scope’dagi o‘zgaruvchilarni eslab qola oladi. Agar obyektni saqlab qolsangiz, u reference qilgan qiymatlar ham o‘chmay saqlanib turaveradi degani. Agar ehtiyot bo‘lmasangiz Javascript kodingiz, browser’da leak’ga sababchi ishlar qilishi juda osonligini ko‘rdim. U yuborgan koddan parcha:
function setup() {
const bigData = new Array(1e6).fill(’leak’);
document.getElementById(’btn’).addEventListener(’click’, function () {
console.log(bigData[0]);
});
}
Bunday muammolar ko‘p. Ma’ruza berish orqali faqat o‘rgatmadim, balkim ko‘p o‘rgandim ham. Videoni ommaviy ulashish imkoni bo‘lsa, ulashishni reja qilib turibman. Sizga ham bir parcha tajriba ilindim : )
#experience
degan gapni eshitgan bo'lsangiz kerak. Eshitmagan bo'lsangiz, keling men birinchilardan sizga buni isbotlab beray.
AWS, GCP kabi cloud servislar 99.95% SLA taklif qilishadi. Ya'ni service yil davomida qancha vaqt up & running bo'lishini xisoblaydi. Qanchalik 9 lar soni ko'p bo'lsa, bu yil davomida servisda kamroq down time bo'ladi (yumalab qoladi) degani. Misol uchun:
☹️ 99.9% (uchta to'qqiz) yiliga 8.77 soat yumalab yotadi,
🙂 99.99% (to'rtta to'qqiz) 52.6 minut yumalab yotadi,
😇 99.999% (beshta to'qqiz) 5.26 minut yumalab yotadi,
... va bu ko'rsatkich to'qqizlar soniga qarab pasayib boraveradi. Ammo to'qqizlarni qanday oshiradi u servislar? Well, vertical va horizontally scale qilish kerak bo'ladi. Bu ko'proq pul (serverlar, tarmoqlar, elektr ta'minotlari, ...), fault-tolerant design, failover systems, va ko'plab ishlar qilinishi kerak degani. Bular tekinga bitmaydi. Va siz high availability'ni taminlash uchun ko'proq pul sarflashingiz kerak bo'ladi. Yo tizimni boricha qabul qilishlarini so'rab pul ishlaysiz, yoki pul ishlatib tizimni yaxshilab keyinchalik pul ishlashni tanlaysiz.
Tasavvur qiling, siz database, table yaratdingiz va ichiga ma'lumotlar yozdingiz. Ketidan ushbu query'ni yuritsangiz nima bo'ladi?
Butun table'ni scan qilib sizga to'g'ri, siz so'ragan row'ni qaytaradi. Agar ma'lumotlaringiz juda ko'p bo'lsa (100 million row), qidiruv ko'proq vaqt olishi mumkin. Agar name column'ni indekslasangizchi? Xuddi o'sha query endi tezroq yurishni boshlaydi (query o'zgarmadi, ammo o'qish tezlashdi). O'qish tezlashgani bilan yozish, o'chirish va yangilash (indekslash xisobiga) sekinlashadi. Chunki endi bir emas ikki joyda o'zgarish sodir bo'ladi (index va table o'zida ham). Biriga erishish uchun ikkinchisiga ko'z yumayabsiz.
K8S orqali servis deploy qilayabsiz. Rolling Update strategiyasini tanladingiz. Yangi deployment incremental (birma-bir) yangilanadi va config yozish ham juda oson. Eng asosiysi bu sizga Zero downtime (odatda) xissini beradi. Ko'rinishidan juda oson va xavfsizdek. Agar tassavvur qiling, servisingiz noto'g'ri ishlashni boshlasa pod'larni rollback qilish ham incremental sodir bo'ladi. Va ba'zilarda bu nostabil ishlashga sabab bo'lishi mumkin (chunki rollback qilish vaqt oladi va ba'zilarda yangi, ba'zilarda eski versiya ishlagani sabab vaqtinchalik inconsistency sodir bo'ladi).
Dasturlashda til, texnologiya, strategiya, tizim, servis, operatsion tizim va har qanday narsani tanlash bu nimagadir ko'z yumish degani (mindey o'ylab qarasam hayotda ham shunaqa ekan). Qaysi biriga ko'z yumishni bilish uchun esa, sizga tajriba kerak. Tajriba qiling!
Software engineering is all about choosing the right trade-off
degan gapni eshitgan bo'lsangiz kerak. Eshitmagan bo'lsangiz, keling men birinchilardan sizga buni isbotlab beray.
AWS, GCP kabi cloud servislar 99.95% SLA taklif qilishadi. Ya'ni service yil davomida qancha vaqt up & running bo'lishini xisoblaydi. Qanchalik 9 lar soni ko'p bo'lsa, bu yil davomida servisda kamroq down time bo'ladi (yumalab qoladi) degani. Misol uchun:
... va bu ko'rsatkich to'qqizlar soniga qarab pasayib boraveradi. Ammo to'qqizlarni qanday oshiradi u servislar? Well, vertical va horizontally scale qilish kerak bo'ladi. Bu ko'proq pul (serverlar, tarmoqlar, elektr ta'minotlari, ...), fault-tolerant design, failover systems, va ko'plab ishlar qilinishi kerak degani. Bular tekinga bitmaydi. Va siz high availability'ni taminlash uchun ko'proq pul sarflashingiz kerak bo'ladi. Yo tizimni boricha qabul qilishlarini so'rab pul ishlaysiz, yoki pul ishlatib tizimni yaxshilab keyinchalik pul ishlashni tanlaysiz.
Tasavvur qiling, siz database, table yaratdingiz va ichiga ma'lumotlar yozdingiz. Ketidan ushbu query'ni yuritsangiz nima bo'ladi?
SELECT * FROM students WHERE name = "Otabek"
Butun table'ni scan qilib sizga to'g'ri, siz so'ragan row'ni qaytaradi. Agar ma'lumotlaringiz juda ko'p bo'lsa (100 million row), qidiruv ko'proq vaqt olishi mumkin. Agar name column'ni indekslasangizchi? Xuddi o'sha query endi tezroq yurishni boshlaydi (query o'zgarmadi, ammo o'qish tezlashdi). O'qish tezlashgani bilan yozish, o'chirish va yangilash (indekslash xisobiga) sekinlashadi. Chunki endi bir emas ikki joyda o'zgarish sodir bo'ladi (index va table o'zida ham). Biriga erishish uchun ikkinchisiga ko'z yumayabsiz.
K8S orqali servis deploy qilayabsiz. Rolling Update strategiyasini tanladingiz. Yangi deployment incremental (birma-bir) yangilanadi va config yozish ham juda oson. Eng asosiysi bu sizga Zero downtime (odatda) xissini beradi. Ko'rinishidan juda oson va xavfsizdek. Agar tassavvur qiling, servisingiz noto'g'ri ishlashni boshlasa pod'larni rollback qilish ham incremental sodir bo'ladi. Va ba'zilarda bu nostabil ishlashga sabab bo'lishi mumkin (chunki rollback qilish vaqt oladi va ba'zilarda yangi, ba'zilarda eski versiya ishlagani sabab vaqtinchalik inconsistency sodir bo'ladi).
Dasturlashda til, texnologiya, strategiya, tizim, servis, operatsion tizim va har qanday narsani tanlash bu nimagadir ko'z yumish degani (mindey o'ylab qarasam hayotda ham shunaqa ekan). Qaysi biriga ko'z yumishni bilish uchun esa, sizga tajriba kerak. Tajriba qiling!
Please open Telegram to view this post
VIEW IN TELEGRAM
#experience
Let's talk about distributed systems.
Siz distributed system backend qismini qurayabsiz. Client serverga request (so'rov) yuboradi - API, message queue yoki event bus orqali. Ammo bir muammo bor, qanday qilib request'ni serveringiz aniq bir marta process qilishini ta'minlaysiz?
Eng qiziq muammolar bu yerda faqat u emas balkim:
- Network paketlarni drop qilishi mumkin (tashlavoradi)
- Client retry qilishi (qayta so'rov yuborishi) mumkin
- Server process qilish jarayonida crash bo'lishi (buzilishi) mumkin
- Message ketma-ketligi buzilishi, kech kelishi, yoki 2 marta kelishi mumkin
Agar yuqoridagi muammolarni oldini olmasangiz:
- Client'dan 2 marta to'lov yechishingiz mumkin
- Duplikat ma'lumot yaratib qo'yishingiz mumkin
- Mahsulotni 2 marta yuborishingiz mumkin
- 50 marta notification yuborishingiz mumkin (Twitter bir yili shunday qilgandi, foydalanuvchilar retry sababli chatiga bir xil xabarlar bilan to'ldirilgandi)
Distributed tizimlarda "At-most-once", "At-least-once" va "Exactly-once" degan tushunchalar mavjud. "At-most-once" holatida xabarlar/so'rovlar 0 yoki 1 marta yetkaziladi. Duplikatlarsiz, ammo siz uni yo'qotishingiz (drop) mumkin. "At-least-once" holatida xabarlar 1+ marta yetkaziladi. Yo'qotish yo'q, lekin takrorlanish mumkin. "Exactly-once" holatida xabar bir marta yuboriladi (bu ko'rsatkichga erishish qiyin).
Exactly-once holati deyarli mavjud emas. Siz user'ni idempotent qilib fake qilib turasiz. Ya'ni HTTP headerga doim idempotency token qo'shasiz. Process qilingan ID'lar tarixini saqlab borasiz. Outbox patter ya'ni event (xodisa)lar ma'lumotlar omborida saqlaysiz va ularni o'sha yerdan olib process qilasiz.
Misol uchun, S3, Google drive, Dropbox kabi tizimlarga ko'pchilik fayllarni yuklashadi. API'lari doim ham barqaror ishlamaydi. Xuddi o'sha PUT yoki POST request bir necha marta yuborilishi mumkin. Har bir obyekt uchun maxsus key va ETag (content caching) bilan yuborishadi. Bu esa content-based idempotency deyiladi. Yanada chqur kirsak, kontentlarni bitta qilib yubormaydi, TCP ni chegarasi (65KB) tufayli kontentlar bir nechta iteratsiya qilib yuboriladi va buni MTU deyishadi. Endi tasavvur qiling, brinchi yuklashda 20% yuklandi va crash bo'ldi, 2chisida esa 40% bo'lib crash bo'lsa nima qilasiz. Bu holatlarda ham content-based idempotency key ishlatish ko'p muammoni yechadi. Keyingi marta qayta urinishda siz kelgan joyidan davom eta olasiz degani.
System Design intervyularda ko'p yordam bergan shu mavzular menga. Sizga ham foydali bo'lishi mumkin. Bugunchalik kallangizni achitish uchun shu yetadi : )
Let's talk about distributed systems.
Siz distributed system backend qismini qurayabsiz. Client serverga request (so'rov) yuboradi - API, message queue yoki event bus orqali. Ammo bir muammo bor, qanday qilib request'ni serveringiz aniq bir marta process qilishini ta'minlaysiz?
Eng qiziq muammolar bu yerda faqat u emas balkim:
- Network paketlarni drop qilishi mumkin (tashlavoradi)
- Client retry qilishi (qayta so'rov yuborishi) mumkin
- Server process qilish jarayonida crash bo'lishi (buzilishi) mumkin
- Message ketma-ketligi buzilishi, kech kelishi, yoki 2 marta kelishi mumkin
Agar yuqoridagi muammolarni oldini olmasangiz:
- Client'dan 2 marta to'lov yechishingiz mumkin
- Duplikat ma'lumot yaratib qo'yishingiz mumkin
- Mahsulotni 2 marta yuborishingiz mumkin
- 50 marta notification yuborishingiz mumkin (Twitter bir yili shunday qilgandi, foydalanuvchilar retry sababli chatiga bir xil xabarlar bilan to'ldirilgandi)
Distributed tizimlarda "At-most-once", "At-least-once" va "Exactly-once" degan tushunchalar mavjud. "At-most-once" holatida xabarlar/so'rovlar 0 yoki 1 marta yetkaziladi. Duplikatlarsiz, ammo siz uni yo'qotishingiz (drop) mumkin. "At-least-once" holatida xabarlar 1+ marta yetkaziladi. Yo'qotish yo'q, lekin takrorlanish mumkin. "Exactly-once" holatida xabar bir marta yuboriladi (bu ko'rsatkichga erishish qiyin).
Exactly-once holati deyarli mavjud emas. Siz user'ni idempotent qilib fake qilib turasiz. Ya'ni HTTP headerga doim idempotency token qo'shasiz. Process qilingan ID'lar tarixini saqlab borasiz. Outbox patter ya'ni event (xodisa)lar ma'lumotlar omborida saqlaysiz va ularni o'sha yerdan olib process qilasiz.
Misol uchun, S3, Google drive, Dropbox kabi tizimlarga ko'pchilik fayllarni yuklashadi. API'lari doim ham barqaror ishlamaydi. Xuddi o'sha PUT yoki POST request bir necha marta yuborilishi mumkin. Har bir obyekt uchun maxsus key va ETag (content caching) bilan yuborishadi. Bu esa content-based idempotency deyiladi. Yanada chqur kirsak, kontentlarni bitta qilib yubormaydi, TCP ni chegarasi (65KB) tufayli kontentlar bir nechta iteratsiya qilib yuboriladi va buni MTU deyishadi. Endi tasavvur qiling, brinchi yuklashda 20% yuklandi va crash bo'ldi, 2chisida esa 40% bo'lib crash bo'lsa nima qilasiz. Bu holatlarda ham content-based idempotency key ishlatish ko'p muammoni yechadi. Keyingi marta qayta urinishda siz kelgan joyidan davom eta olasiz degani.
System Design intervyularda ko'p yordam bergan shu mavzular menga. Sizga ham foydali bo'lishi mumkin. Bugunchalik kallangizni achitish uchun shu yetadi : )
#experience
Yaqinda jamoamiz Dropbox va OpenAI bilan integratsiya qilish ustida ishladik. Bizni vazifamiz ML muhit (environment) yaratish kerak edi. Aniqroq qilsak OpenAI ChatGPT'ni Dropbox serverlarida ishga tushirish haqida gap ketayabdi. Nimalarni o'rgandim:
ML environment deganda hayolingizga istalgan katta LLMni deploy qilish, train qilish, kerakli ma'lumotlarni olib o'tish va kerakli dasturlarni run qila olish imkonini beruvchi tayyor infrastruktura kelishi kerak. Buning uchun biz juda ko'p resurs ajrtadik. GPU haqida eshitgandim ammo TPU (Tensor Processing Unit) haqida eshitmagandim, buni ham o'rganib oldim. Btw, OpenAI ni Python ko'tarib turibdi ekan. Pythonchilar bir yayrasin : )
Secuirty for AI haqida ajoyib hikoyalar eshitdim. Adversarial attacks, Data poisoning, model stealing va privacy attack haqida ko'p gap ketdi. Maqolalar o'qib ularni tahlil qilib chiqdik. AI'ga user qo'pol so'zlar aytsa yoki so'kinsa AI sizni qaytarib so'kmasligi ham security ekan, qiziq. Prompt hacking ham ozgina ko'rib chiqdik.
Yana bir qiziq o'rgangan narsam AI for security bo'ldi. Ya'ni AI'ni kiber xujumlarni qaytarishda ishlatish, misol uchun tarmoqdan kelayotgan nomalum so'rovlar, phishing email'larni topish va h.k.z. Bunday business modellar juda kam, hozir boshlasangiz yaxshilardan biriga aylanishingiz mumkin ekan.
AI deploy qilayotganda uni izolyatsaladik, firewall bilan in va out trafiklarni chekladik. To'g'ri OS tanlash ham muhim ekan bu yerda. AI faqat API bilan ishlaydi, firewall kirayotgan va chiqayotgan trafikni to'liq nazorat qiladi. Modelni og'irligi (weight) bu uni bilimi degani. Uni ham encrypted storage'da saqlash kerakligini o'rgandik. Ancha praktikaga boy bo'ldi. Katta modeldan kichik model yasashni ko'rib chiqdik. Bu orqali ancha cost va performance optimization qilsa bo'lar ekan.
Xulosa:
Eng katta xulosam AI yaxshi yordamchiligicha qoladi. Eng yaxshi injenerlar yaxshi debuger'lar ekan. AI debugging da juda oqsaydi. Debug qilishni o'rganing. Agar hali ham AI'dan kodingizni debug qilishini so'rayotgan bo'lsangiz, juniorlik zindoniga bir umr ravona bo'lasiz.
Yaqinda jamoamiz Dropbox va OpenAI bilan integratsiya qilish ustida ishladik. Bizni vazifamiz ML muhit (environment) yaratish kerak edi. Aniqroq qilsak OpenAI ChatGPT'ni Dropbox serverlarida ishga tushirish haqida gap ketayabdi. Nimalarni o'rgandim:
ML environment deganda hayolingizga istalgan katta LLMni deploy qilish, train qilish, kerakli ma'lumotlarni olib o'tish va kerakli dasturlarni run qila olish imkonini beruvchi tayyor infrastruktura kelishi kerak. Buning uchun biz juda ko'p resurs ajrtadik. GPU haqida eshitgandim ammo TPU (Tensor Processing Unit) haqida eshitmagandim, buni ham o'rganib oldim. Btw, OpenAI ni Python ko'tarib turibdi ekan. Pythonchilar bir yayrasin : )
Secuirty for AI haqida ajoyib hikoyalar eshitdim. Adversarial attacks, Data poisoning, model stealing va privacy attack haqida ko'p gap ketdi. Maqolalar o'qib ularni tahlil qilib chiqdik. AI'ga user qo'pol so'zlar aytsa yoki so'kinsa AI sizni qaytarib so'kmasligi ham security ekan, qiziq. Prompt hacking ham ozgina ko'rib chiqdik.
Yana bir qiziq o'rgangan narsam AI for security bo'ldi. Ya'ni AI'ni kiber xujumlarni qaytarishda ishlatish, misol uchun tarmoqdan kelayotgan nomalum so'rovlar, phishing email'larni topish va h.k.z. Bunday business modellar juda kam, hozir boshlasangiz yaxshilardan biriga aylanishingiz mumkin ekan.
AI deploy qilayotganda uni izolyatsaladik, firewall bilan in va out trafiklarni chekladik. To'g'ri OS tanlash ham muhim ekan bu yerda. AI faqat API bilan ishlaydi, firewall kirayotgan va chiqayotgan trafikni to'liq nazorat qiladi. Modelni og'irligi (weight) bu uni bilimi degani. Uni ham encrypted storage'da saqlash kerakligini o'rgandik. Ancha praktikaga boy bo'ldi. Katta modeldan kichik model yasashni ko'rib chiqdik. Bu orqali ancha cost va performance optimization qilsa bo'lar ekan.
Xulosa:
Eng katta xulosam AI yaxshi yordamchiligicha qoladi. Eng yaxshi injenerlar yaxshi debuger'lar ekan. AI debugging da juda oqsaydi. Debug qilishni o'rganing. Agar hali ham AI'dan kodingizni debug qilishini so'rayotgan bo'lsangiz, juniorlik zindoniga bir umr ravona bo'lasiz.
#experience (1-qism)
Senior darajadan keyin sizda odatda 2ta yo'l bo'ladi (kompaniyaga qarab). Biri Management (odamlar bilan ishlash), boshqasi Staff (texnik liderlik). Ikkisida ham o'ziga yarasha qiyinchiliklari bor. Biz ushbu postda Staff Engineer yo'li haqida gaplashamiz.
Staff Engineer bizni kompaniyada 3ta eng asosiy narsaga qarab tanlanadi.
- U bog'liq tizimlarni yaxshi tushunadi (Ownership scope)
- U kompaniyaga nima foyda olib kelishini ko'ra oladi (Impact)
- U bir necha komandalar bilan ishlay oladi (Collabration)
Ishga ilk bor kirganimda onboarding jarayoni uchun 3 oy vaqt berilgandi. Shu 3 oyni men 2 qismga bo'lib chiqdim. 1-oy asosan onboarding bosqichini tugatish. 2 va 3-oy jamoamiz ishlaydigan tizimlarni arxitekturasini ko'rib, undagi komponentlarni o'rganib chiqish. Asosan bergan savolim "why" bo'lgan, "how" emas.
Nega "why"?
Tizmlar va undagi komponentlar nega mavjudligini bilish boshqa ishlardan ancha muhimroq. Nega aynan bu komponent yaratilgan? Nega u bunday algoritm asosida ishlaydi? Nega u error'larni bunday handle qiladi? Bu savollar ancha ko'proq qamrovda savollarga javob bera oladi. Agar shuni "how ...?" ga o'zgaritganimda men tizim qanday ishlashi va qanday handle qilishini bila olardim xolos. Bu faqat texnik savollarga javob beradi xolos, ammo qarorlarni kelib chiqish sababiga hech qachon javob topa olmaysiz. To'g'risini aytaman, tizimlarni qanday ishlashini bilish sizni qimmatbaho dasturchi qilmaydi, chunki bu yodlanadigan bilm, qayta ishlatiladigan bilm emas.
What makes you best engineer?
Men bilgan eng zo'r injinerlarni hammasida 2ta odatni ko'raman. Debugging va yozish. Debugging shunchaki koddagi xatolikni topish emas, balkim tizimni qanday ishlayotganini ko'ra olish degani. Katta tizmlarni yaratish oson bo'lishi mumkin, ammo ularni tuzatish ancha murakkabroq. Tizimni qayerida xatolik bo'layotganini topish va uni ertaroq oldini olish juda katta tajriba talab qiladi. Yaratishdan ko'ra debug qilishga ko'proq vaqtingiz ketadi odatda.
Debug qildingiz endichi? Endi ularni log qilib qo'ying. Ha biror daftaringizni oching va shu xatolik nimaga, qanday sodir bo'lgani va uni tuzatganingiz haqida to'liq yozib qo'ying. Bu juda muhim. Bilmlar xiralashadi. Bugun aniq detallarini ayta olasiz. Ammo kunlar o'tgan sari siz kam-kamdan mayda detallarni unutib boraverasiz. Yozganingizni ertaga o'qib oson yodga solasiz. Yozishni foydalari ko'p. Yozayotganda yaxshiroq yechimlar ham kelishi mumkin (shaxsan o'zimda shunday bo'lib turadi). Yozganingizni ulashish ham osonroq bo'ladi. Yozing.
Senior darajadan keyin sizda odatda 2ta yo'l bo'ladi (kompaniyaga qarab). Biri Management (odamlar bilan ishlash), boshqasi Staff (texnik liderlik). Ikkisida ham o'ziga yarasha qiyinchiliklari bor. Biz ushbu postda Staff Engineer yo'li haqida gaplashamiz.
Staff Engineer bizni kompaniyada 3ta eng asosiy narsaga qarab tanlanadi.
- U bog'liq tizimlarni yaxshi tushunadi (Ownership scope)
- U kompaniyaga nima foyda olib kelishini ko'ra oladi (Impact)
- U bir necha komandalar bilan ishlay oladi (Collabration)
Ishga ilk bor kirganimda onboarding jarayoni uchun 3 oy vaqt berilgandi. Shu 3 oyni men 2 qismga bo'lib chiqdim. 1-oy asosan onboarding bosqichini tugatish. 2 va 3-oy jamoamiz ishlaydigan tizimlarni arxitekturasini ko'rib, undagi komponentlarni o'rganib chiqish. Asosan bergan savolim "why" bo'lgan, "how" emas.
Nega "why"?
Tizmlar va undagi komponentlar nega mavjudligini bilish boshqa ishlardan ancha muhimroq. Nega aynan bu komponent yaratilgan? Nega u bunday algoritm asosida ishlaydi? Nega u error'larni bunday handle qiladi? Bu savollar ancha ko'proq qamrovda savollarga javob bera oladi. Agar shuni "how ...?" ga o'zgaritganimda men tizim qanday ishlashi va qanday handle qilishini bila olardim xolos. Bu faqat texnik savollarga javob beradi xolos, ammo qarorlarni kelib chiqish sababiga hech qachon javob topa olmaysiz. To'g'risini aytaman, tizimlarni qanday ishlashini bilish sizni qimmatbaho dasturchi qilmaydi, chunki bu yodlanadigan bilm, qayta ishlatiladigan bilm emas.
What makes you best engineer?
Men bilgan eng zo'r injinerlarni hammasida 2ta odatni ko'raman. Debugging va yozish. Debugging shunchaki koddagi xatolikni topish emas, balkim tizimni qanday ishlayotganini ko'ra olish degani. Katta tizmlarni yaratish oson bo'lishi mumkin, ammo ularni tuzatish ancha murakkabroq. Tizimni qayerida xatolik bo'layotganini topish va uni ertaroq oldini olish juda katta tajriba talab qiladi. Yaratishdan ko'ra debug qilishga ko'proq vaqtingiz ketadi odatda.
Debug qildingiz endichi? Endi ularni log qilib qo'ying. Ha biror daftaringizni oching va shu xatolik nimaga, qanday sodir bo'lgani va uni tuzatganingiz haqida to'liq yozib qo'ying. Bu juda muhim. Bilmlar xiralashadi. Bugun aniq detallarini ayta olasiz. Ammo kunlar o'tgan sari siz kam-kamdan mayda detallarni unutib boraverasiz. Yozganingizni ertaga o'qib oson yodga solasiz. Yozishni foydalari ko'p. Yozayotganda yaxshiroq yechimlar ham kelishi mumkin (shaxsan o'zimda shunday bo'lib turadi). Yozganingizni ulashish ham osonroq bo'ladi. Yozing.
#experience
Bir qiziq bug'ni tuzadim. Bizda code base monorepo holida saqlanadi. Ya'ni hamma kodlar bitta repo'da saqlanadi. Bu holda kodlarni test qilish, build qilish, va hokazo operatsiyalarni qo'lda bajarish yoki ularga pipeline yozib ularni boshqarish qiyinlashib boradi. Bunga yechim incremental build systems ishlatish.
Incremental build system ham oddiy dasutr, faqat u kodlaringizni o'zgarishini, dependency control, qaysi qismda o'zgarish bo'lsa faqat o'sha qismni build, test qilishni belgilay oladi. Tasavvur qiling Google, Meta, Dropbox kabi tizmlarda hamma dasturlarni kodlari bitta joyda (monorepo holida) saqlanadi.
Build System alohida Linux machine'larda ishlab turadi. O'zgarishlar bo'lsa kodlar o'sha mashinaga boradi, test, build qilinadi va keyin shunga qarab natijalar bizga ko'rinadi. Bir kun build system service OOM (out of memory) bo'lib qoldi. Memory swap qilishni boshladi. Lekin biz u servislar uchun ajratgan resurslarimiz yetishi kerak edi. Borib tahlil qilishni boshladim. 64GM RAM umumiy xisobda. Hammasi yaxshi. 48GB ram qaysidir process tomonidan ishlatilayotganini ko'rdim. Va yana 16GB OS filesystem cache ham bor edi. OS filesystem cache ni doim tozalay oladi. Lekin bu holatda nimaga swap qilayotganini tushuna olmadim.
Esingizda bo'lsa docker minimal versiyasini yasab ko'rganim haqida aytgandim. Ha o'sha tajriba qo'l keldi. Hamma gap
Ba'zan qilgan eksperimentlarim ko'p azq otadi. Peace!
Updated: Bu voqeaga ancha bo'lgan lekin hozir yozgim kelib qoldi. Balkim shu ham promoga yordam bo'lgandir, who knows
Bir qiziq bug'ni tuzadim. Bizda code base monorepo holida saqlanadi. Ya'ni hamma kodlar bitta repo'da saqlanadi. Bu holda kodlarni test qilish, build qilish, va hokazo operatsiyalarni qo'lda bajarish yoki ularga pipeline yozib ularni boshqarish qiyinlashib boradi. Bunga yechim incremental build systems ishlatish.
Incremental build system ham oddiy dasutr, faqat u kodlaringizni o'zgarishini, dependency control, qaysi qismda o'zgarish bo'lsa faqat o'sha qismni build, test qilishni belgilay oladi. Tasavvur qiling Google, Meta, Dropbox kabi tizmlarda hamma dasturlarni kodlari bitta joyda (monorepo holida) saqlanadi.
Build System alohida Linux machine'larda ishlab turadi. O'zgarishlar bo'lsa kodlar o'sha mashinaga boradi, test, build qilinadi va keyin shunga qarab natijalar bizga ko'rinadi. Bir kun build system service OOM (out of memory) bo'lib qoldi. Memory swap qilishni boshladi. Lekin biz u servislar uchun ajratgan resurslarimiz yetishi kerak edi. Borib tahlil qilishni boshladim. 64GM RAM umumiy xisobda. Hammasi yaxshi. 48GB ram qaysidir process tomonidan ishlatilayotganini ko'rdim. Va yana 16GB OS filesystem cache ham bor edi. OS filesystem cache ni doim tozalay oladi. Lekin bu holatda nimaga swap qilayotganini tushuna olmadim.
swappiness degan narsa haqida google qilib o'rgandim. Agar swappiness qiymati baland bo'lsa swap qilishni boshlar ekan. Bizdagi config 2 ko'rsatayotgan edi va men uni sysctl vm.swappiness=1 ga set qildim. Lekin shunda ham swap qilishda davom etaverdi. Swapni o'chirib qo'ydik, ancha ahvol yomonlashdi. Process'lar OOM berishni boshladi. OOM berganda Linux uni kill qiladi (to'xtatadi). O'zimga "why? why?" deb bir idea kelib qoldi.Esingizda bo'lsa docker minimal versiyasini yasab ko'rganim haqida aytgandim. Ha o'sha tajriba qo'l keldi. Hamma gap
cgroup da edi. Buni rostligini tekshirish uchun dmesg ni tekshirdim, voila javob topildi. Bug topildi. Aynan bizga kerakli ishlab turgan process'lar limiti past bo'lgan cgroup ga tushib qolganini ko'rib ich-ichimdan xursand bo'lib ketdim. I wanted to scream like "Technologia, I found the bug".Ba'zan qilgan eksperimentlarim ko'p azq otadi. Peace!
#experience
Kodingiz 1 millisecond'da 23 000 qator record (ma'lumot)larni ustida operatsiyani bajarish qanchalik zo'r? Kecha bir kodni ko'rdim va hamksablar bilan gaplashganimdan beri bu ko'rsatkich sekinga aylanib qoldi. I love Distributed Systems😢 .
Kecha java'dagi Math.pow() funksiyasini optimizatsiya qilishganini ko'rib qoldim. Bu unchalik muhim bo'lmasa kerak deb o'ylagandim, adashibman. Hozir kod 100x tezroq ishlayabdi ekan. Ishonmay benchmark ham qilib ko'rdim (eski va yangi change'larni farqini bilishga). Awesome!!!
Okay bu haqda blog yozishga arziydi lekin kanalda 2k reader (follower) bo'lsak bu haqida albatta yozaman. Hozircha bu sizga challange sifatida qolaqolsin. Btw, bu muammoni men yechmaganman, lekin men ham shunday yechgan bo'lardim.
Kodingiz 1 millisecond'da 23 000 qator record (ma'lumot)larni ustida operatsiyani bajarish qanchalik zo'r? Kecha bir kodni ko'rdim va hamksablar bilan gaplashganimdan beri bu ko'rsatkich sekinga aylanib qoldi. I love Distributed Systems
Kecha java'dagi Math.pow() funksiyasini optimizatsiya qilishganini ko'rib qoldim. Bu unchalik muhim bo'lmasa kerak deb o'ylagandim, adashibman. Hozir kod 100x tezroq ishlayabdi ekan. Ishonmay benchmark ham qilib ko'rdim (eski va yangi change'larni farqini bilishga). Awesome!!!
Okay bu haqda blog yozishga arziydi lekin kanalda 2k reader (follower) bo'lsak bu haqida albatta yozaman. Hozircha bu sizga challange sifatida qolaqolsin. Btw, bu muammoni men yechmaganman, lekin men ham shunday yechgan bo'lardim.
Please open Telegram to view this post
VIEW IN TELEGRAM
#experience
Yillar davomida o’rgangan ba’zi bilmlarimdan:
- Abstraksiya funksiya yoki servis qanday ishlashiga emas, nima bersangiz nima olishingiz mumkinligiga diqqatingizni qaratadi. Bu ba’zan sizga tizimni murakkabligini soddaroq tushinb qurishga yordam qilsa, ba’zan sizga qimmatga tushishi mumkin. On-call, o’zbek tilida navbatchilik deymiz. Infra, cloud jamoalarda ishlaydiganlar odatda buni yaxshi bilishadi. Aynan navbatchilik paytida bizga yoqmaydigan fundamental “algoritmlar”, “data structure”, “low-level”, “matematika”, “networking”, “database”, “operating systems” va h.k.z bilmlar juda kerak bo’lishini ko’p guvohi bo’lasiz. Insonlar mukammallikdan uzoq bo’lgani kabi, ular yozgan dasturlar, kodlar, kitoblar va asarlar ham huddi shunday ekan.
- Kod yozishdan ko’ra ko’proq kodni o’chirish qiyinroq va ko’proq xavfsizlik keltirar ekan. Shu paytgacha 20 238 qator kod o’chirdim. Jamoa bu ishimdan juda hursand bo’ldi. Pul, asab va energiya tejadik. Qanday? Endi bu servis hech qachon buzilmaydi, biz uni soatlab “nima bo’ldi ekan?” deb kuzatmaymiz/tuzatmaymiz. Ota-bobolarimiz aytganidek “eng yaxshi kod bu yozilmagan kod”.
- Yiqilishdan qo’rqmaydiganlar ko’p yutar ekan. Qiziqishlarim menga juda qimmatga tushgan. Dadam olib bergan o’sha $500 lik kompyuterni chuqalab $50 ga sotganimiz, startup quraman deb cloudga to’lagan oxirgi $4000 pulim, system dizayni amaliyot qilib o’rganaman deb ketkazilgan vaqt (20ta kitob o’qib yodlash mumkin edi bu vaqtga), production’da qilingan xatolik va eksperimentlar, ehh gapirsa tugamaydigandek. Lekin barchasi Otabekni shu yergacha kelishiga o’z xissasini qo’shgan. Dastur muammosiz ishlasa o’smaysiz. Istalgan kompaniya ham shuncha odamni bekorga ishlatmaydi. Xatolar va muammolar bizni bor qilib turibdi, buzishdan qo’rqmang. Ammo buzg’unchi bo’lmang.
- Yaxshi do’stlar ortdiring va qiymat bering. Blog yozib ham do’st orttirish mumkin ekan. Hozirda minglab do’slarim (sizlar) shu blogimni foydasi bor deb o’qishadi. Ba’zilar “qiziqshim oshadi sizni blogizni o’qisam” desa, yana ba’zilar “senior bo’lishda/ishga kirishimda yordam qildi blogingiz” deydi. Ha “nima deyabsan o’zing tushunayabsanmi?” deydiganlar ham topiladi. Ammo foydasi tegayabdi, shunisidan xursandman.
Xullas qisqacha shular.
Yillar davomida o’rgangan ba’zi bilmlarimdan:
- Abstraksiya funksiya yoki servis qanday ishlashiga emas, nima bersangiz nima olishingiz mumkinligiga diqqatingizni qaratadi. Bu ba’zan sizga tizimni murakkabligini soddaroq tushinb qurishga yordam qilsa, ba’zan sizga qimmatga tushishi mumkin. On-call, o’zbek tilida navbatchilik deymiz. Infra, cloud jamoalarda ishlaydiganlar odatda buni yaxshi bilishadi. Aynan navbatchilik paytida bizga yoqmaydigan fundamental “algoritmlar”, “data structure”, “low-level”, “matematika”, “networking”, “database”, “operating systems” va h.k.z bilmlar juda kerak bo’lishini ko’p guvohi bo’lasiz. Insonlar mukammallikdan uzoq bo’lgani kabi, ular yozgan dasturlar, kodlar, kitoblar va asarlar ham huddi shunday ekan.
- Kod yozishdan ko’ra ko’proq kodni o’chirish qiyinroq va ko’proq xavfsizlik keltirar ekan. Shu paytgacha 20 238 qator kod o’chirdim. Jamoa bu ishimdan juda hursand bo’ldi. Pul, asab va energiya tejadik. Qanday? Endi bu servis hech qachon buzilmaydi, biz uni soatlab “nima bo’ldi ekan?” deb kuzatmaymiz/tuzatmaymiz. Ota-bobolarimiz aytganidek “eng yaxshi kod bu yozilmagan kod”.
- Yiqilishdan qo’rqmaydiganlar ko’p yutar ekan. Qiziqishlarim menga juda qimmatga tushgan. Dadam olib bergan o’sha $500 lik kompyuterni chuqalab $50 ga sotganimiz, startup quraman deb cloudga to’lagan oxirgi $4000 pulim, system dizayni amaliyot qilib o’rganaman deb ketkazilgan vaqt (20ta kitob o’qib yodlash mumkin edi bu vaqtga), production’da qilingan xatolik va eksperimentlar, ehh gapirsa tugamaydigandek. Lekin barchasi Otabekni shu yergacha kelishiga o’z xissasini qo’shgan. Dastur muammosiz ishlasa o’smaysiz. Istalgan kompaniya ham shuncha odamni bekorga ishlatmaydi. Xatolar va muammolar bizni bor qilib turibdi, buzishdan qo’rqmang. Ammo buzg’unchi bo’lmang.
- Yaxshi do’stlar ortdiring va qiymat bering. Blog yozib ham do’st orttirish mumkin ekan. Hozirda minglab do’slarim (sizlar) shu blogimni foydasi bor deb o’qishadi. Ba’zilar “qiziqshim oshadi sizni blogizni o’qisam” desa, yana ba’zilar “senior bo’lishda/ishga kirishimda yordam qildi blogingiz” deydi. Ha “nima deyabsan o’zing tushunayabsanmi?” deydiganlar ham topiladi. Ammo foydasi tegayabdi, shunisidan xursandman.
Xullas qisqacha shular.
#experience
Dropbox Dash jamoasi bilan 4 oy ishladim (Tour of Duty). Va RAG haqida va uni katta masshtabda yuritish (running at scale) haqida juda ko'p o'rgandim.
Agar RAG qurayotgan bo'lsangiz va write/read amallari soni juda ko'p bo'lsa siz qurayotgan RAG katta ehtimollik bilan kengaya olmaydi va juda ko'p alaqsiraydi (hallucination). Vector database kichik bo'lsa kNN qidiruvi ishlashi mumkin. Agar ma'lumot bo'laklar hajmi 80k-100k dan oshsa juda katta kechikish (latency) sodir bo'ladi. Sababi so'rov (query) va har bir vector o'rtasidagi masofani xisoblash qimmatlashib va og'irlashib ketadi.
Buni qanday yechish mumkin? kNN o'rniga ANN algoritmlaridan foydalanish kerak, misol uchun HNSW (Hierarchical navigable small world) indekslari. Eng katta trade off, 100% to'g'ri ma'lumot emas, balkim 99.5% - 99.9% foiz aniqlikda ma'lumotlarni topa olasiz. Xisoblash (Computing) hali ham qimmat xisoblanadi garchi ba'zilar buni hozir amal qilmaydigan ta'rif deyishsada. Agar ana katta kompaniyalar aytishayabdi desangiz, Cloud narxi nega tushmayabdi? Xullas tushundingiz menimcha.
PDF kabi xujjatlarni qanday qilib saqlaydi va ulardan qanday ma'lumot qidiradi deysizmi? Bu yerda ham shunday trade off qilinadi. Vector Quantization ya'ni rasmlarni sifatini tushurish degani, compression. High-precision floating point raqamlar saqlashdan ko'ra, ularni round qilib saqlaysiz simple cluster'larga.
Ba'zan alaqsirashga (hallucination) sabab "The Context Window Paradox" bo'ladi va uni "Lost in the Middle" muammosi deb ataymiz. Ya'ni "promptda ko'proq ma'lumot bersang, yaxshiroq natija olasan" degan gaplar noto'g'ri. Buni ko'pincha Attention modellar qanday ishlashini bilmaydiganlar aytadi. Chunki bu model diqqatini (attention) buzadi. Ya'ni prompt o'rtasiga borib model ma'lumotni yo'qotadi. Buning uchun "Re-ranking layer" yechimlari mavjud. Xullas LLMga berishdan oldin, vector db dan olingan ma'lumot bo'laklarni (chunk) cross-encoder'ga berasiz va re-rank qilingan top 3-5 tasini yuborasiz LLMga.
Bizda ham RAG qurayotganlar ko'payabdi, balkim foydasi tegar : )
Dropbox Dash jamoasi bilan 4 oy ishladim (Tour of Duty). Va RAG haqida va uni katta masshtabda yuritish (running at scale) haqida juda ko'p o'rgandim.
Agar RAG qurayotgan bo'lsangiz va write/read amallari soni juda ko'p bo'lsa siz qurayotgan RAG katta ehtimollik bilan kengaya olmaydi va juda ko'p alaqsiraydi (hallucination). Vector database kichik bo'lsa kNN qidiruvi ishlashi mumkin. Agar ma'lumot bo'laklar hajmi 80k-100k dan oshsa juda katta kechikish (latency) sodir bo'ladi. Sababi so'rov (query) va har bir vector o'rtasidagi masofani xisoblash qimmatlashib va og'irlashib ketadi.
Buni qanday yechish mumkin? kNN o'rniga ANN algoritmlaridan foydalanish kerak, misol uchun HNSW (Hierarchical navigable small world) indekslari. Eng katta trade off, 100% to'g'ri ma'lumot emas, balkim 99.5% - 99.9% foiz aniqlikda ma'lumotlarni topa olasiz. Xisoblash (Computing) hali ham qimmat xisoblanadi garchi ba'zilar buni hozir amal qilmaydigan ta'rif deyishsada. Agar ana katta kompaniyalar aytishayabdi desangiz, Cloud narxi nega tushmayabdi? Xullas tushundingiz menimcha.
PDF kabi xujjatlarni qanday qilib saqlaydi va ulardan qanday ma'lumot qidiradi deysizmi? Bu yerda ham shunday trade off qilinadi. Vector Quantization ya'ni rasmlarni sifatini tushurish degani, compression. High-precision floating point raqamlar saqlashdan ko'ra, ularni round qilib saqlaysiz simple cluster'larga.
Ba'zan alaqsirashga (hallucination) sabab "The Context Window Paradox" bo'ladi va uni "Lost in the Middle" muammosi deb ataymiz. Ya'ni "promptda ko'proq ma'lumot bersang, yaxshiroq natija olasan" degan gaplar noto'g'ri. Buni ko'pincha Attention modellar qanday ishlashini bilmaydiganlar aytadi. Chunki bu model diqqatini (attention) buzadi. Ya'ni prompt o'rtasiga borib model ma'lumotni yo'qotadi. Buning uchun "Re-ranking layer" yechimlari mavjud. Xullas LLMga berishdan oldin, vector db dan olingan ma'lumot bo'laklarni (chunk) cross-encoder'ga berasiz va re-rank qilingan top 3-5 tasini yuborasiz LLMga.
Bizda ham RAG qurayotganlar ko'payabdi, balkim foydasi tegar : )
#experience
Dropbox'da ishlab ko'p ajoyib narsalarga guvoh bo'lganman. Dunyo bo'ylab ko'p davlatlarda ish faoliyati yuritishiga qaramay, ishchilar soni unchalik ham ko'p bo'lmagan (muhandislar soni men kirganimda > 10k, va layoff'lardan keyin 4.9k qolgandi) kompaniya. Boshqa katta kompaniyalardan farqi bottom-up (basdan-yuqoriga) kulturasida ish yuritilardi, ya'ni muhandislar investorlarga nima ustida ishlashni aytishadi, tepadan "shuni qilasan" degan buyruq kelmaydi (81% holatda).
Meni eng ko'p lol qoldirgan narsalardan biri uni oqimga erta ba'zan vaqtida tez moslashishi bo'lgan. "Ask Max" degan servisni ko'rganimda ilk bor hayron qolgandim, men ko'rgan agentic AI. Siz undan savol so'raysiz, yoki prompt yuborasiz. U sizni promptingizni klassifikatsiya qilib, buyruqimi, savolmi yoki shu kabi ishlarni aniqlab shu asosida ish bajarardi. Eng qiziq tomoni, bu servis 2022 yilda May (yoki Mart) oyida ishga tushgan ekan test rejimda, bu degani servis undan oldinroq qurila boshlangan. Birinchi aytgan gapim "Wow, that's how it looks agentic AI systems". Aytgancha, hamma uni "Max" deb chaqirardi, bitta men uni "itvachcha" derdim. Keyin menejerimga o'rgatdim, va butun jamoa uni shunday chaqira boshlagandi :)
Staff Engineer bo'lib ishlab OpenAI jamoasi bilan ishlaganim haqida yozgandim ilgariroq. ChatGPT 5.1 chiqqan paytlari edi. Bizga ular "GPT-5.1-Codex, Mini va Max modellarimiz bor koding uchun maxsus" deyishganda juda ko'p so'raganim esimda. Keyin uni ham olib kirgandik. Birinchi bor eshitib o'ylanib qolgan gapim "Skill based development" bo'lgan. 2025 yil, Dekabr oylari edi adashmasam. "Biz skill yozib chiqamiz, u yerda to'liq instruksiya, yaxshi va yomon misollar va nimalarni qanday hohlashimizni to'liq yoritib o'tamiz. Keyin AI u asosida kod yozadi" degani esimda. Yana bir "WOW moment" bo'lgandi. Ulardan tutorial qilib berishini so'ragandim. Butun organizatsiya uchun qilgan eng yaxshi ishlarimdan biri bo'lgan deb o'ylayman, har holda ismimni unutishmaydi shu sabab.
Kompaniyadan ketishimdan 2 oy oldin, faqat dokumentatsiya yozishga o'tdim. Loyihalar bo'yicha bilgan bilimlarimni yozib, bor ammo eski bo'lgan dokumentatsiyalarni yangilab chiqish vazifasi berilgandi. Shu paytlar qandaydir coding uchun topshiriq kelsa, SKILL.md yozib, men ham "Skill based development" qilishni boshlagandim (ha to'liq AI bilan kod yozganman). Xattoki review'ni ham to'liq AI ga topshirganman, jamoadan boshqa muhandislar AI o'tkazib yuborgan xatolarni yozishardi, AI uni olib yana ustida ishlab qayta PR ochardi.
Yaqinda shu haqda o'ylab qoldim, o'zimni uslubimga mos SKILL yozib ko'rdim. Hozircha 5/10 ishlayabdi. Yaxshilash kerak joylari ko'p. Ammo coding qismdagi deyarli ko'p ishni AIga topshirishga qaror qildim. Ammo code review uchun har bir qatorni o'qib chiqishni ham odat qildim.
AI kod generatsiya qilishi mumkin, ammo code review jarayonini hali ham yaxshi bajara olmaydi, ha industriya hali ham eng muhim muammoni yechmagan. Lekin biz o'rganishimiz, va doim bir xil formada turish uchun endi ko'proq review qilishni boshlashimiz kerak. AI generates code, humans review it. Kod yozish ishimizni bir qismi, uni to'g'ri yoki noto'g'ri ishlashi bizni mas'uliyatimiz. Mas'uliyatli bo'ling!
Dropbox'da ishlab ko'p ajoyib narsalarga guvoh bo'lganman. Dunyo bo'ylab ko'p davlatlarda ish faoliyati yuritishiga qaramay, ishchilar soni unchalik ham ko'p bo'lmagan (muhandislar soni men kirganimda > 10k, va layoff'lardan keyin 4.9k qolgandi) kompaniya. Boshqa katta kompaniyalardan farqi bottom-up (basdan-yuqoriga) kulturasida ish yuritilardi, ya'ni muhandislar investorlarga nima ustida ishlashni aytishadi, tepadan "shuni qilasan" degan buyruq kelmaydi (81% holatda).
Meni eng ko'p lol qoldirgan narsalardan biri uni oqimga erta ba'zan vaqtida tez moslashishi bo'lgan. "Ask Max" degan servisni ko'rganimda ilk bor hayron qolgandim, men ko'rgan agentic AI. Siz undan savol so'raysiz, yoki prompt yuborasiz. U sizni promptingizni klassifikatsiya qilib, buyruqimi, savolmi yoki shu kabi ishlarni aniqlab shu asosida ish bajarardi. Eng qiziq tomoni, bu servis 2022 yilda May (yoki Mart) oyida ishga tushgan ekan test rejimda, bu degani servis undan oldinroq qurila boshlangan. Birinchi aytgan gapim "Wow, that's how it looks agentic AI systems". Aytgancha, hamma uni "Max" deb chaqirardi, bitta men uni "itvachcha" derdim. Keyin menejerimga o'rgatdim, va butun jamoa uni shunday chaqira boshlagandi :)
Staff Engineer bo'lib ishlab OpenAI jamoasi bilan ishlaganim haqida yozgandim ilgariroq. ChatGPT 5.1 chiqqan paytlari edi. Bizga ular "GPT-5.1-Codex, Mini va Max modellarimiz bor koding uchun maxsus" deyishganda juda ko'p so'raganim esimda. Keyin uni ham olib kirgandik. Birinchi bor eshitib o'ylanib qolgan gapim "Skill based development" bo'lgan. 2025 yil, Dekabr oylari edi adashmasam. "Biz skill yozib chiqamiz, u yerda to'liq instruksiya, yaxshi va yomon misollar va nimalarni qanday hohlashimizni to'liq yoritib o'tamiz. Keyin AI u asosida kod yozadi" degani esimda. Yana bir "WOW moment" bo'lgandi. Ulardan tutorial qilib berishini so'ragandim. Butun organizatsiya uchun qilgan eng yaxshi ishlarimdan biri bo'lgan deb o'ylayman, har holda ismimni unutishmaydi shu sabab.
Kompaniyadan ketishimdan 2 oy oldin, faqat dokumentatsiya yozishga o'tdim. Loyihalar bo'yicha bilgan bilimlarimni yozib, bor ammo eski bo'lgan dokumentatsiyalarni yangilab chiqish vazifasi berilgandi. Shu paytlar qandaydir coding uchun topshiriq kelsa, SKILL.md yozib, men ham "Skill based development" qilishni boshlagandim (ha to'liq AI bilan kod yozganman). Xattoki review'ni ham to'liq AI ga topshirganman, jamoadan boshqa muhandislar AI o'tkazib yuborgan xatolarni yozishardi, AI uni olib yana ustida ishlab qayta PR ochardi.
Yaqinda shu haqda o'ylab qoldim, o'zimni uslubimga mos SKILL yozib ko'rdim. Hozircha 5/10 ishlayabdi. Yaxshilash kerak joylari ko'p. Ammo coding qismdagi deyarli ko'p ishni AIga topshirishga qaror qildim. Ammo code review uchun har bir qatorni o'qib chiqishni ham odat qildim.
AI kod generatsiya qilishi mumkin, ammo code review jarayonini hali ham yaxshi bajara olmaydi, ha industriya hali ham eng muhim muammoni yechmagan. Lekin biz o'rganishimiz, va doim bir xil formada turish uchun endi ko'proq review qilishni boshlashimiz kerak. AI generates code, humans review it. Kod yozish ishimizni bir qismi, uni to'g'ri yoki noto'g'ri ishlashi bizni mas'uliyatimiz. Mas'uliyatli bo'ling!
#experience
Dropbox'da highly distributed systems qurganmiz deb ko'p aytganman. "O'zi tizimlarni nega distribute (tarqatish) qilish kerak?" degan savolga ham javob bermoqchiman.
Ilgariroq agar dasturlar ko'proq foydalanuvchilarga xizmat ko'rsatishi kerak bo'lgan bo'lsa, insoniyat shunchaki serverlarga ko'proq va kuchliroq RAM, Disk va CPU qo'shib kuchaytirgan. Buni Vertical Scaling (chunki moshina eniga emas, bo'yiga o'sadi faqat) deb ataymiz.
Qayisidir nuqataga borib dunyodagi eng kuchli kompyuterni yasab qo'ydik ammo shu ham yetmayabdi degan muammo paydo bo'ladi. CPU cheksiz tezlasha olmaydi, chunki elektr toki bilan gaplashgani uchun juda ko'p qizib ketadi va eriy boshlaydi. Tok o'chib qolsa butun biznesingiz o'chadi degani, chunki bizda faqat bitta kompyuter bor. Serveringiz boshqa regionda bo'lsa RTT (Round Trip Time) va Latency muammolar kelib chiqadi. Xullas siz o'ylagandek ideal emas. Endi bizga lokalizatsiya va tezlik kerak.
Bitta super kompyuter o'rniga 100ta kichik kompyuterlarni tarmoq orqali bog'laymizda, ularni bitta tizim sifatida ishlashga o'rgatish fikri keladi, ya'ni Horizontal Scaling. Ammo bu yerda eng katta muammo bor, untrustworthy network (ishonchsiz tarmoq).
Networking (reklamada aylanay) yaxshi o'qiganlar buni juda yaxshi bilishadi. Tarmoqda nimadir sodir bo'lsa ikkinchi tomon bilmay qolishi yoki tarmoqda yo'qolishlar bo'lishi mumkin (Network Partition Illusion). Yokida "Split-Brain Catastrophe" muammosi yoki The Gray Network ya'ni servis healthy (sog'lom) mi deb so'rasangiz "ha" deyaveradi lekin u juda sekin bo'lgani uchun nechadir foiz trafikni tashlab yuboradi. Boshqa serverlar unga ishlayabdi deb so'rov yuboraveradi va natijada butun region cloud servisi qulashiga olib boradi.
Odatda tizimlarni kengaytirishda (scale), doim ishlab turishini ta'minlashda (Availability) va latency kamaytirish uchun lokalizatsiyalashtirishda distribute qilinadi. Chunki katta traffikga bitta eng kuchli bo'lsa ham qurilma javob bera olmaydi, biri o'chib qolsa ikkinchisi javob berishi uchun va ma'lumot foydalanuvchi regionida saqlansa unga tezroq yetib borishi uchun.
Arxitektura qilishda esa "Stateless", "Stateful" va "Consensus Protocols" degan tomonlari bor. Stateless bo'lsa oson, ma'lumot DBga saqlanadi va load balancer orqali istalgan servis o'sha yagona DB'dan ma'lumot o'qib foydalanuvchiga javob bera oladi. Stateful bo'lsa DB da muammolar paydo bo'ladi. Ma'lumotlarni maxsus key'lar orqali sharding qilasiz, va doim replica olib borasiz. "Split-Brain" muammosini yechish uchun serverlar Raft yoki Paxos algoritmlari orqali ovoz berish yo'lga qo'yishadi. Nega? Chunki tizimlar distributed, ular endi bitta emas ko'p. Va ko'pchilik rozi bo'lganda operatsiya bajarilishi kerak, chunki ma'lumotlar bir joyda emas. Va bu tushunchani "Quorum" deb atashadi.
U yerda yana vaqt muammosi ham bor ayalanay. Butun dunyo bir xil vaqtda operate qila olmaydi. CAP theorem dagi kimni qurbon qilish masalasi ham bor. Xullas juda murakkab jarayon.
Ko'pchilik yozmagan jarayon, menga buni Staff Engineer o'rgatgandi va bu "Formal Verification" deyiladi. Tizimni matematik yo'l bilan to'g'riligini topish mumkin ekan. Test qilishda biz har xil input berib, outputini to'g'ri javob bilan solishtirib olamiz. Lekin distributed systems bunday testlash doim ham ishlayvermaydi.
Formal Verification 3ta bosqichdan iborat. Specification bosqichida tizim nima qilishi kerakligini ifodalaysiz. Implementation qismida kodini yozasiz. Engine qismida implementatsiya qilgan kodiz spesifikatsiya qismida tasvirlagandek ishlashini tekshirasiz. Bu jarayon haqida juda kam bilimga egaman, shunga ko'p yoza olmayman.
Hozircha shular
Dropbox'da highly distributed systems qurganmiz deb ko'p aytganman. "O'zi tizimlarni nega distribute (tarqatish) qilish kerak?" degan savolga ham javob bermoqchiman.
Ilgariroq agar dasturlar ko'proq foydalanuvchilarga xizmat ko'rsatishi kerak bo'lgan bo'lsa, insoniyat shunchaki serverlarga ko'proq va kuchliroq RAM, Disk va CPU qo'shib kuchaytirgan. Buni Vertical Scaling (chunki moshina eniga emas, bo'yiga o'sadi faqat) deb ataymiz.
Qayisidir nuqataga borib dunyodagi eng kuchli kompyuterni yasab qo'ydik ammo shu ham yetmayabdi degan muammo paydo bo'ladi. CPU cheksiz tezlasha olmaydi, chunki elektr toki bilan gaplashgani uchun juda ko'p qizib ketadi va eriy boshlaydi. Tok o'chib qolsa butun biznesingiz o'chadi degani, chunki bizda faqat bitta kompyuter bor. Serveringiz boshqa regionda bo'lsa RTT (Round Trip Time) va Latency muammolar kelib chiqadi. Xullas siz o'ylagandek ideal emas. Endi bizga lokalizatsiya va tezlik kerak.
Bitta super kompyuter o'rniga 100ta kichik kompyuterlarni tarmoq orqali bog'laymizda, ularni bitta tizim sifatida ishlashga o'rgatish fikri keladi, ya'ni Horizontal Scaling. Ammo bu yerda eng katta muammo bor, untrustworthy network (ishonchsiz tarmoq).
Networking (reklamada aylanay) yaxshi o'qiganlar buni juda yaxshi bilishadi. Tarmoqda nimadir sodir bo'lsa ikkinchi tomon bilmay qolishi yoki tarmoqda yo'qolishlar bo'lishi mumkin (Network Partition Illusion). Yokida "Split-Brain Catastrophe" muammosi yoki The Gray Network ya'ni servis healthy (sog'lom) mi deb so'rasangiz "ha" deyaveradi lekin u juda sekin bo'lgani uchun nechadir foiz trafikni tashlab yuboradi. Boshqa serverlar unga ishlayabdi deb so'rov yuboraveradi va natijada butun region cloud servisi qulashiga olib boradi.
Odatda tizimlarni kengaytirishda (scale), doim ishlab turishini ta'minlashda (Availability) va latency kamaytirish uchun lokalizatsiyalashtirishda distribute qilinadi. Chunki katta traffikga bitta eng kuchli bo'lsa ham qurilma javob bera olmaydi, biri o'chib qolsa ikkinchisi javob berishi uchun va ma'lumot foydalanuvchi regionida saqlansa unga tezroq yetib borishi uchun.
Arxitektura qilishda esa "Stateless", "Stateful" va "Consensus Protocols" degan tomonlari bor. Stateless bo'lsa oson, ma'lumot DBga saqlanadi va load balancer orqali istalgan servis o'sha yagona DB'dan ma'lumot o'qib foydalanuvchiga javob bera oladi. Stateful bo'lsa DB da muammolar paydo bo'ladi. Ma'lumotlarni maxsus key'lar orqali sharding qilasiz, va doim replica olib borasiz. "Split-Brain" muammosini yechish uchun serverlar Raft yoki Paxos algoritmlari orqali ovoz berish yo'lga qo'yishadi. Nega? Chunki tizimlar distributed, ular endi bitta emas ko'p. Va ko'pchilik rozi bo'lganda operatsiya bajarilishi kerak, chunki ma'lumotlar bir joyda emas. Va bu tushunchani "Quorum" deb atashadi.
U yerda yana vaqt muammosi ham bor ayalanay. Butun dunyo bir xil vaqtda operate qila olmaydi. CAP theorem dagi kimni qurbon qilish masalasi ham bor. Xullas juda murakkab jarayon.
Ko'pchilik yozmagan jarayon, menga buni Staff Engineer o'rgatgandi va bu "Formal Verification" deyiladi. Tizimni matematik yo'l bilan to'g'riligini topish mumkin ekan. Test qilishda biz har xil input berib, outputini to'g'ri javob bilan solishtirib olamiz. Lekin distributed systems bunday testlash doim ham ishlayvermaydi.
Formal Verification 3ta bosqichdan iborat. Specification bosqichida tizim nima qilishi kerakligini ifodalaysiz. Implementation qismida kodini yozasiz. Engine qismida implementatsiya qilgan kodiz spesifikatsiya qismida tasvirlagandek ishlashini tekshirasiz. Bu jarayon haqida juda kam bilimga egaman, shunga ko'p yoza olmayman.
Hozircha shular
#experience
Hamma vibe coding qilayabdi. Bilasizmi, korxona ko'p maxsulot ishlab chiqarsa nimalar sodir bo'ladi? Ularni test qilish, ko'rikdan o'tkazish qiyinlashadi. Ko’p moshina chiqarish ko’p sotishga emas, ishlab chiqarishni butunlay to’xtashiga olib boradi.
Qayta aytmoqchi bo'lgan so'zim, AI bilan kod yozish ishni tezlashtiradi, sifatni pasaytiradi. Kod yozish oldin ham muammo emas edi. Haqiqiy muammo kodni "review" va "test" qilishda edi. Biz hali ham noto'g'ri muammoni yechayabmiz.
"AI bilan kod yozavering, qolganlarni eshitmang" deydigan yomon injenerlikka targ'ib ko'payib qolgan. Haqiqiy injenering o'rganishdan va muammo yechishdan iborat. Muammo yechayabsizmi? Unda nima muammoni qanday yechayabsiz? Shu savolni so'rab ko'ring, agar nimadir o'rganayotgan bo'lsangiz demak to'g'ri yo'ldasiz.
Avvalroq kod yozishni AI ga topshirganim haqida aytgandim. Juda ko'p ishimni yengillashtirdi, ammo juda ko'p muammo keltirib chiqa boshladi ham. Bugundan kamroq vibe coding qilishga o'tayabman. Katta va murakkab ishlar, loyihalar uchun yaramas ekan.
Hamma vibe coding qilayabdi. Bilasizmi, korxona ko'p maxsulot ishlab chiqarsa nimalar sodir bo'ladi? Ularni test qilish, ko'rikdan o'tkazish qiyinlashadi. Ko’p moshina chiqarish ko’p sotishga emas, ishlab chiqarishni butunlay to’xtashiga olib boradi.
Qayta aytmoqchi bo'lgan so'zim, AI bilan kod yozish ishni tezlashtiradi, sifatni pasaytiradi. Kod yozish oldin ham muammo emas edi. Haqiqiy muammo kodni "review" va "test" qilishda edi. Biz hali ham noto'g'ri muammoni yechayabmiz.
"AI bilan kod yozavering, qolganlarni eshitmang" deydigan yomon injenerlikka targ'ib ko'payib qolgan. Haqiqiy injenering o'rganishdan va muammo yechishdan iborat. Muammo yechayabsizmi? Unda nima muammoni qanday yechayabsiz? Shu savolni so'rab ko'ring, agar nimadir o'rganayotgan bo'lsangiz demak to'g'ri yo'ldasiz.
Avvalroq kod yozishni AI ga topshirganim haqida aytgandim. Juda ko'p ishimni yengillashtirdi, ammo juda ko'p muammo keltirib chiqa boshladi ham. Bugundan kamroq vibe coding qilishga o'tayabman. Katta va murakkab ishlar, loyihalar uchun yaramas ekan.
#experience
Ko'pchilik bir xil savol beradi:
"Model o'zilarnikimi yoki open-source modelmi?"
O'zimizniki ham bor, open source modellarimiz ham bor. Nimaga "pre-train" (ma'lumot yig'ib, PyTorch va JAX code bilan neural networkni tuzish, necha qavatli qilish, attention, yashirin dimension lar va hardware ga mos optimizatsiya qilish, keyin katta model uchun distributed system qilish chunki katta modellar bitta GPU ga sig'maydi, Hyperparameter configuration va h.k.z larni hammasini qilish deganida ) qilmaysizlar to'liq ham deyishadi. Odatda javobim bunday.
Pre-training juda og'ir jarayon, ayniqsa low-resource (resursi kam bo'lgan) tillar uchun model qilish undanda og'ir. Ma'lumot yig'ish, tozalash jarayonini o'zi sizni butun umrlik qiynoqqa soladi. Biz bunday holatlarda osonroq yo'ldan ketamiz. Bor modelni olamiz, uni shunchaki post-train (fine-tuning) qilamiz. Bu jarayonda model'dagi og'irlik (weight) qayta balans qilinadi. Bu orqali model yaxshiroq o'rganadi eski ma'lumotlarini. Ya'ni ona tili ustozingiz diktantni faqat bir marta qaytarishi aniqlikni oshiradimi, yoki 2-3 marotabami?
Ikkinchi masala bu "compute". Hozirgi paytda bizga Azure, AWS va GCP zo'rga GPU'lar uchun imtiyoz berishgan. Ba'zilarida H100, H200 yoki B200 kabi kuchli videokartalar topishimiz qiyin bo'lsa, ba'zilarida bor ammo juda qimmat. Startup uchun bu og'ir.
Ammo imkon topayabmiz, modellarimizni yaxshilab borayabmiz. Undan tashqari CPU da ham ishlay oladigan modellarni ustida ishlayabmiz. Jarayondan o'rgangan 2 xulosam bor. Biri pre-train jarayoniga. Ikkinchisi post-training jarayoniga tegishli.
Barcha ma'lumotlarni chalkashtirib (shuffle qilib) keyin ularni boshidan oxirgacha teng distrbute qilish juda xato ekan. Model o'rganish darajasini (Learning rate) train jaryoni oxirida pasaytirish, va yuqori sifatli ma'lumotlarni berish kerak. Chunki aynan shu qismi modelni tugashi va post-training boshlanishi bo'ladi. Model ma'lumotni o'rgandi, endi unga bu ma'lumotni to'g'ri tushunish va ishlatishni o'rgatish (post-training) qismida ham sifatini saqlab qolishi uchun oxirgi ko'rgan ma'lumotlari juda sifatli bo'lishi kerak.
Model aldashni o'rganadi. Agar label qilingan ma'lumot faqat yaxshi tondagi javobga mukofot (reward) olsa, demak u cheat code qilishni boshlaydi. U doim muloyim va ishonchli aldashni boshlaydi. Buni natijasida u hallucinate qiladi, asosiy sabab bitta reward tonga (yoki stilga) nisbatan, haqiqatga (mazmun) emas.
RL muhitda bu tarafga qarash uchun modelni objective test qilish kerak, ya'ni natijani tekshirish oson bo'lishi kerak. Misol uchun "kod compile bo'ldi va to'g'ri ishladimi?", "javob haqiqatdan 42 chiqdimi?", "bergan javobi yaroqli JSONmi yoki nimadir qo'shvordimi?" degan savollarga javob topish. Chunki bularni tekshirsa bo'ladi.
Ovozli modellarda ham huddi shu jarayonni avtomatlashtirsa bo'ladi. Faqat ozgina sabr kerak ekan. Biz buni o'rgandik, bir kun yozish ham nasib qilsin. Uxlanglar endi : )
Ko'pchilik bir xil savol beradi:
"Model o'zilarnikimi yoki open-source modelmi?"
O'zimizniki ham bor, open source modellarimiz ham bor. Nimaga "pre-train" (
Pre-training juda og'ir jarayon, ayniqsa low-resource (resursi kam bo'lgan) tillar uchun model qilish undanda og'ir. Ma'lumot yig'ish, tozalash jarayonini o'zi sizni butun umrlik qiynoqqa soladi. Biz bunday holatlarda osonroq yo'ldan ketamiz. Bor modelni olamiz, uni shunchaki post-train (fine-tuning) qilamiz. Bu jarayonda model'dagi og'irlik (weight) qayta balans qilinadi. Bu orqali model yaxshiroq o'rganadi eski ma'lumotlarini. Ya'ni ona tili ustozingiz diktantni faqat bir marta qaytarishi aniqlikni oshiradimi, yoki 2-3 marotabami?
Ikkinchi masala bu "compute". Hozirgi paytda bizga Azure, AWS va GCP zo'rga GPU'lar uchun imtiyoz berishgan. Ba'zilarida H100, H200 yoki B200 kabi kuchli videokartalar topishimiz qiyin bo'lsa, ba'zilarida bor ammo juda qimmat. Startup uchun bu og'ir.
Ammo imkon topayabmiz, modellarimizni yaxshilab borayabmiz. Undan tashqari CPU da ham ishlay oladigan modellarni ustida ishlayabmiz. Jarayondan o'rgangan 2 xulosam bor. Biri pre-train jarayoniga. Ikkinchisi post-training jarayoniga tegishli.
Barcha ma'lumotlarni chalkashtirib (shuffle qilib) keyin ularni boshidan oxirgacha teng distrbute qilish juda xato ekan. Model o'rganish darajasini (Learning rate) train jaryoni oxirida pasaytirish, va yuqori sifatli ma'lumotlarni berish kerak. Chunki aynan shu qismi modelni tugashi va post-training boshlanishi bo'ladi. Model ma'lumotni o'rgandi, endi unga bu ma'lumotni to'g'ri tushunish va ishlatishni o'rgatish (post-training) qismida ham sifatini saqlab qolishi uchun oxirgi ko'rgan ma'lumotlari juda sifatli bo'lishi kerak.
Model aldashni o'rganadi. Agar label qilingan ma'lumot faqat yaxshi tondagi javobga mukofot (reward) olsa, demak u cheat code qilishni boshlaydi. U doim muloyim va ishonchli aldashni boshlaydi. Buni natijasida u hallucinate qiladi, asosiy sabab bitta reward tonga (yoki stilga) nisbatan, haqiqatga (mazmun) emas.
RL muhitda bu tarafga qarash uchun modelni objective test qilish kerak, ya'ni natijani tekshirish oson bo'lishi kerak. Misol uchun "kod compile bo'ldi va to'g'ri ishladimi?", "javob haqiqatdan 42 chiqdimi?", "bergan javobi yaroqli JSONmi yoki nimadir qo'shvordimi?" degan savollarga javob topish. Chunki bularni tekshirsa bo'ladi.
Ovozli modellarda ham huddi shu jarayonni avtomatlashtirsa bo'ladi. Faqat ozgina sabr kerak ekan. Biz buni o'rgandik, bir kun yozish ham nasib qilsin. Uxlanglar endi : )
#experience
Deyarli bir yarim yildan buyon intervyular jarayonida bitta savol doim so'rayman "Eng qiyin yechgan muammoyingiz nima?".
Bu savol nega muhim? Chunki bu savolni ichida juda ko'plab yaxshi savollarga javob olish mumkin, kandidat haqida. Masalan, uni izlanuvchan ekanligini "Muammoga qanday duch keldingiz va uni qanday yechdingiz?", muammo yechuvchanligini esa "Aynan qanday limitlar bu muammoni qiyin qilib turgandi?", yaxshi muhandsiligini "Nimalar qildingiz? Qanday qildingiz?" va qanchalik chuqur kira olganini esa har bir qismiga ko'proq to'xtalib savol bilan aniqlash mumkin.
Men ko'rgan yaxshi muhandislar javob bermaydi, ular o'rgatadi, bo'lishadi. Dasturchi muhandislik juda qiziq soha, biz har kuni har xil muammolarga duch kelamiz. Muammoni yechish hozir osonroq, AI Agentlar xisobiga. Lekin muammoni o'rganish va uni keyingi safar oldini olib qo'yish xislati kamayib bormoqda.
Eng zo'r muhandislar muammoni yaxshi o'rganadi, tahlil qiladi, yechim beradi va keyingi safarga tayyor turadi.
Deyarli bir yarim yildan buyon intervyular jarayonida bitta savol doim so'rayman "Eng qiyin yechgan muammoyingiz nima?".
Bu savol nega muhim? Chunki bu savolni ichida juda ko'plab yaxshi savollarga javob olish mumkin, kandidat haqida. Masalan, uni izlanuvchan ekanligini "Muammoga qanday duch keldingiz va uni qanday yechdingiz?", muammo yechuvchanligini esa "Aynan qanday limitlar bu muammoni qiyin qilib turgandi?", yaxshi muhandsiligini "Nimalar qildingiz? Qanday qildingiz?" va qanchalik chuqur kira olganini esa har bir qismiga ko'proq to'xtalib savol bilan aniqlash mumkin.
Men ko'rgan yaxshi muhandislar javob bermaydi, ular o'rgatadi, bo'lishadi. Dasturchi muhandislik juda qiziq soha, biz har kuni har xil muammolarga duch kelamiz. Muammoni yechish hozir osonroq, AI Agentlar xisobiga. Lekin muammoni o'rganish va uni keyingi safar oldini olib qo'yish xislati kamayib bormoqda.
Eng zo'r muhandislar muammoni yaxshi o'rganadi, tahlil qiladi, yechim beradi va keyingi safarga tayyor turadi.