Please open Telegram to view this post
VIEW IN TELEGRAM
Media is too big
VIEW IN TELEGRAM
Serverlarga xakkerlar xujum qiladi.
Menga esamushugim Mimi 🐈
Express Networking 3 modul, "Serverga xujum qilamiz" darsini yozish jarayonidan lavha
Menga esa
Please open Telegram to view this post
VIEW IN TELEGRAM
#5MinuteTopic
Platform vs DevOps Engineer
O‘tgan galgi streamda Platform Engineer vs DevOps Engineer nima farqi bor deb so‘rashgandi. Keyinroq shuni o‘zimga yozishni va ko‘rishganda so‘rashni boshlashdi. Bu yerda bu ikkisini farqi haqida gaplashamiz. Infrastruktura tomonda ishlaganim uchun bu haqda o‘rganishga va amaliy sinab ko‘rishga muvaffaq bo‘la oldim.
DevOps Engineer bu to‘liq texnik emas balkim qaysidir darajada madaniyatni ham tatbiq etuvchi rol hisoblanadi. Siz developer’lar va operations team’ni bog‘lovchi inson bo‘lishingiz kerak. Texnik tomondan to‘g‘ri siz CI/CD (continuous delivery / continuous deployment), Kubernetes, Jenkins, Git, Networking, Security va Cloud yechimlar haqida bilishingiz kerak bo‘ladi. Bu sizda mijozlarga dasturchilar qurgan dasturni to‘g‘ri yetkazib berishdek mas’uliyatni shakllantiradi. Ammo, tasavvur qiling qaysidir dasturchi yoki jamoa biror yangi loyiha qilsa va DevOps jamoasi band bo‘lsa butun process to‘xtab qoladi degani. Bu muammoni yechish uchun esa Platform Engineer sohasi shakllangan.
Platform Engineer bu IDP (Internal Developer Platform) quruvchi injener hisoblanadi. Endi siz DevOps engineer bo‘shashini kutmaysiz, chunki siz uchun platforma qurilgan. Siz bir nechta tugmalarni bosish va dokumentatsiyada ko‘rsatilgandek qoida yozishni o‘rganish orqali o‘zingiz bemalol operate (harakat) qila olasiz degani. Ya’ni dasturchilar uchun o‘ziga-o‘zi xizmat ko‘rsatuvchi platforma degani bu, ajoyib-a? Endi jamoada hamma Terraform, AWS, K8S ni bilishi shart emas. Ular platformaga kiradi va qoida yozishni o‘rganib shunchaki o‘zlariga-o‘zlari xizmat ko‘rsata olishadi.
DevOps uchun mijozlar bu haqiqiy mijozlardir. Platform Engineer uchun mijozlar bu dasturchilardir. Siz "I will write a Jenkins pipeline for the team" dan "I will build a template in the IDP so any team can spin up a secure pipeline in 3 clicks without asking me" ga o‘tasiz.
Biz SRE haqida gaplashmadik, bu umumman alohida mavzu.
Platform vs DevOps Engineer
O‘tgan galgi streamda Platform Engineer vs DevOps Engineer nima farqi bor deb so‘rashgandi. Keyinroq shuni o‘zimga yozishni va ko‘rishganda so‘rashni boshlashdi. Bu yerda bu ikkisini farqi haqida gaplashamiz. Infrastruktura tomonda ishlaganim uchun bu haqda o‘rganishga va amaliy sinab ko‘rishga muvaffaq bo‘la oldim.
DevOps Engineer bu to‘liq texnik emas balkim qaysidir darajada madaniyatni ham tatbiq etuvchi rol hisoblanadi. Siz developer’lar va operations team’ni bog‘lovchi inson bo‘lishingiz kerak. Texnik tomondan to‘g‘ri siz CI/CD (continuous delivery / continuous deployment), Kubernetes, Jenkins, Git, Networking, Security va Cloud yechimlar haqida bilishingiz kerak bo‘ladi. Bu sizda mijozlarga dasturchilar qurgan dasturni to‘g‘ri yetkazib berishdek mas’uliyatni shakllantiradi. Ammo, tasavvur qiling qaysidir dasturchi yoki jamoa biror yangi loyiha qilsa va DevOps jamoasi band bo‘lsa butun process to‘xtab qoladi degani. Bu muammoni yechish uchun esa Platform Engineer sohasi shakllangan.
Platform Engineer bu IDP (Internal Developer Platform) quruvchi injener hisoblanadi. Endi siz DevOps engineer bo‘shashini kutmaysiz, chunki siz uchun platforma qurilgan. Siz bir nechta tugmalarni bosish va dokumentatsiyada ko‘rsatilgandek qoida yozishni o‘rganish orqali o‘zingiz bemalol operate (harakat) qila olasiz degani. Ya’ni dasturchilar uchun o‘ziga-o‘zi xizmat ko‘rsatuvchi platforma degani bu, ajoyib-a? Endi jamoada hamma Terraform, AWS, K8S ni bilishi shart emas. Ular platformaga kiradi va qoida yozishni o‘rganib shunchaki o‘zlariga-o‘zlari xizmat ko‘rsata olishadi.
DevOps uchun mijozlar bu haqiqiy mijozlardir. Platform Engineer uchun mijozlar bu dasturchilardir. Siz "I will write a Jenkins pipeline for the team" dan "I will build a template in the IDP so any team can spin up a secure pipeline in 3 clicks without asking me" ga o‘tasiz.
Biz SRE haqida gaplashmadik, bu umumman alohida mavzu.
50ta tizim dizayn intervyularidan o'rganganlarim shu bo'ldi
Tizim dizayni intervyularidan o'rganganlarim, xatolarim va ularni yaxshilash haqida yozdim. Big Tech'ni crack qilishni istaganlar uchun maxsus.
Batafsil
Tizim dizayni intervyularidan o'rganganlarim, xatolarim va ularni yaxshilash haqida yozdim. Big Tech'ni crack qilishni istaganlar uchun maxsus.
Batafsil
#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 : )
LLM vs RLM
LLM qurish biz o‘ylaganchalik qiyin ish emas ekan. Uni mashq qildirish, unga sifatli ma’lumotlar topish, deploy qilish, monitoring qilish va h.k.z.lar qilish qiyin. Yaqinda Attention mexanizmi haqida yozgandim. Aynan o‘sha mexanizm kontekstni (context) boshqaradi. Kontekstni tushunish uchun u doim ortga qarab yuradi. Ya’ni model chapdan-o‘ngga qarab shunchaki o‘qib ketmaydi, balki ushbu gapdagi qaysi so‘z menga bu so‘zni yaxshiroq tushunishimga yordam beradi degan savol bilan yurish qiladi va so'zlar bilan aloqa xaritasi yasaydi, uni GPU'dagi VRAM (Video RAM)da KV Cache ga saqlaydi .
Nima uchun modellarda 128k - 256k ba’zan 1M context limit bor? Sababi oddiy matematika, Quadratic Complexity. Huddi tepada aytganimdek, agar ba’zimda 5 ta odam bo‘lsa, ular bir-birlari bilan oson gaplasha olishadi. Agar 100 ta odam bo‘lsa 100 000 ta kombinatsiya, 1 000 000 odam bo‘lsa ehheeeee. Undan tashqari VRAM buncha katta ma’lumotlar saqlashi qiyinlashib boradi.
LLM lar uchun har bir token (so‘z) boshqa token’larga qarashi kerak context da qolishi uchun. Matn hajmi ikki baravar oshsa, hisoblash (computational work) ishi ikki baravar emas, to‘rt baravar oshadi, insane.
Bu muammoni yechish uchun kodlarni indekslash kabi yechimlar chiqgan. Ammo ularni biznesi uzoqqa bormaydi deb o‘ylayman. Shaxsan o‘zim ishda RLM ya’ni Recursive Language Model qurish jarayonida qatnashib ko‘rdim. Large Language Modellardan farqi shundaki, u rekursiv o‘zini-o‘zi chaqira oladi, ammo nega? Context muammosini yechish uchun. Decomposer mexanizmi ya'ni LLM ortidagi "Divide-and-conquer" algoritmi.
LLM:
• katta prompt bersangiz, prompt o‘rtasiga yetganda boshini unutib qo‘yishi mumkin
• prompt dagi barcha narsaga diqqat (attention) qilmoqchi bo‘ladi
• Internal weight ga asoslanib ishlaydi (trainingdagi ma’lumotlar bilan)
RLM:
• Faqat kichik va kerakli parchaga (snippet) diqqat qiladi. Keyingi bo‘lakga o‘tish uchun recursion ishlatadi.
• Controller mexanizmi orqali katta topshiriqni kichik bo‘laklarga bo‘lib kerak paytda o‘zini-o‘zi chaqira oladi kerakli parcha bilan.
• 1M matn uchun "filter" yozib kerakli qismini o‘qiy oladi.
RLM bilan 10M context gacha bemalol chiqsa bo‘lar ekan. To‘liq test qilib production da yuritib ko‘rilmagan, ammo eksperiment sifatida qilingan ishni bo‘lishdim. Bu kompaniya siri emas, ochiq manba. Sirli tomonlar hozircha "miyada" 😅
LLM qurish biz o‘ylaganchalik qiyin ish emas ekan. Uni mashq qildirish, unga sifatli ma’lumotlar topish, deploy qilish, monitoring qilish va h.k.z.lar qilish qiyin. Yaqinda Attention mexanizmi haqida yozgandim. Aynan o‘sha mexanizm kontekstni (context) boshqaradi. Kontekstni tushunish uchun u doim ortga qarab yuradi. Ya’ni model chapdan-o‘ngga qarab shunchaki o‘qib ketmaydi, balki ushbu gapdagi qaysi so‘z menga bu so‘zni yaxshiroq tushunishimga yordam beradi degan savol bilan yurish qiladi va so'zlar bilan aloqa xaritasi yasaydi, uni GPU'dagi VRAM (Video RAM)da KV Cache ga saqlaydi .
Nima uchun modellarda 128k - 256k ba’zan 1M context limit bor? Sababi oddiy matematika, Quadratic Complexity. Huddi tepada aytganimdek, agar ba’zimda 5 ta odam bo‘lsa, ular bir-birlari bilan oson gaplasha olishadi. Agar 100 ta odam bo‘lsa 100 000 ta kombinatsiya, 1 000 000 odam bo‘lsa ehheeeee. Undan tashqari VRAM buncha katta ma’lumotlar saqlashi qiyinlashib boradi.
LLM lar uchun har bir token (so‘z) boshqa token’larga qarashi kerak context da qolishi uchun. Matn hajmi ikki baravar oshsa, hisoblash (computational work) ishi ikki baravar emas, to‘rt baravar oshadi, insane.
Bu muammoni yechish uchun kodlarni indekslash kabi yechimlar chiqgan. Ammo ularni biznesi uzoqqa bormaydi deb o‘ylayman. Shaxsan o‘zim ishda RLM ya’ni Recursive Language Model qurish jarayonida qatnashib ko‘rdim. Large Language Modellardan farqi shundaki, u rekursiv o‘zini-o‘zi chaqira oladi, ammo nega? Context muammosini yechish uchun. Decomposer mexanizmi ya'ni LLM ortidagi "Divide-and-conquer" algoritmi.
LLM:
• katta prompt bersangiz, prompt o‘rtasiga yetganda boshini unutib qo‘yishi mumkin
• prompt dagi barcha narsaga diqqat (attention) qilmoqchi bo‘ladi
• Internal weight ga asoslanib ishlaydi (trainingdagi ma’lumotlar bilan)
RLM:
• Faqat kichik va kerakli parchaga (snippet) diqqat qiladi. Keyingi bo‘lakga o‘tish uchun recursion ishlatadi.
• Controller mexanizmi orqali katta topshiriqni kichik bo‘laklarga bo‘lib kerak paytda o‘zini-o‘zi chaqira oladi kerakli parcha bilan.
• 1M matn uchun "filter" yozib kerakli qismini o‘qiy oladi.
RLM bilan 10M context gacha bemalol chiqsa bo‘lar ekan. To‘liq test qilib production da yuritib ko‘rilmagan, ammo eksperiment sifatida qilingan ishni bo‘lishdim. Bu kompaniya siri emas, ochiq manba. Sirli tomonlar hozircha "miyada" 😅
Sizga hech kim aytmagan sirni aytaman
Gigant kompaniyalarda sizga birinchi o’t yoqib, keyin o’chirishga ruxsat bor. Ammo hamma ishga kirganlar buni qilib bo’lmaydi deb, qandaydir yozilmagan qoidalarga amal qilishga harakat qilishadi )
Dropbox dan o'rgangan eng muhim 2ta narsam haqida
Computer Networking
Istalgan kompaniya katta trafik bilan ishlashni boshlaganda bu mavzu haqida ko'proq o'rganadi. Bir hamkasbim boomerang-hire bo'ldi, kecha gaplashib qoldik. U borgan startup kompaniya AI uchun infrastruktura qilar ekan va ko'p AI coding qilishar ekan. Eng yomon tomoni hech kim efficiency haqida o'ylamaydi, duch kelgan narsani yozib yuboraveradi deydi. Tushuntirishga harakat qildim nega buncha ko'p tizimda kamchiliklar va outage bo'lishini, lekin quloq solmadi deydi. AI tez kod yozib beradi, jarayonni tushunadigan dasturchilar endi ko'proq qadirlanishini isboti. Networking'ga keladigan bo'lsa, AI uchun klusterlarni va GPU larni bir-biri bilan samarali gaplashishi uchun tarmoqni tizim dizayn qilishadi va barcha keyslarga solib test qilib ko'rishadi (simulyatsiya). Keyin eng yaxshisini olib ishlatishadi. Internet networking siz mavjud bo'lmasdi, bundan buyog'iga ham Network injenerlarga talab kuchayib boraveradi (hardware va software da ham).
Communication
Senior bo'lib ishlab yurgan paytlarimda menejerim menga ko'proq Staff engineer bilan ishlashni, unga yaqinroq bo'lishni maslahat bergandi. Shu maslahatiga quloq solib Staff bo'ldim. Chunki undan ko'p bilmlar o'rgandim. 1:1 meeting qilsak ham hech qachon berilgan mavzudamas, boshqa mavzular to'g'risida ko'proq gaplashardik. Shundan keyin har bir system design qilinishi, research qilinishi kerak bo'lgan joylarda birga ishlashni boshladik. Uni kompaniyadagi 7 yillik tajribasini bir qismi menda bo'lgani uchun ham meni promote qilishdi. Ha undan hamma ko'proq ma'lumot olib qolishga harakat qilishdi, ammo ketishiga oz qolganda. Menda bu narsa ancha erta boshlangandi. Staff bo'lganimdan keyin kod yozishdan ko'ra ko'proq boshqa jamoalar bilan ishlash, o'z jamoamga ko'proq o'rgatish va ulardan ham fikrlar olib ular bilan birga o'sishni o'rgandim. Qisqasi yaxshiroq va ko'proq komunikatsiya qilishni o'rgandim.
Eng kattalari shular bo'ldi, qolganlari IaC, Distributed Systems, Platform Engineering, AI/ML va Data Center lar haqida bo'lgan.
Computer Networking
Istalgan kompaniya katta trafik bilan ishlashni boshlaganda bu mavzu haqida ko'proq o'rganadi. Bir hamkasbim boomerang-hire bo'ldi, kecha gaplashib qoldik. U borgan startup kompaniya AI uchun infrastruktura qilar ekan va ko'p AI coding qilishar ekan. Eng yomon tomoni hech kim efficiency haqida o'ylamaydi, duch kelgan narsani yozib yuboraveradi deydi. Tushuntirishga harakat qildim nega buncha ko'p tizimda kamchiliklar va outage bo'lishini, lekin quloq solmadi deydi. AI tez kod yozib beradi, jarayonni tushunadigan dasturchilar endi ko'proq qadirlanishini isboti. Networking'ga keladigan bo'lsa, AI uchun klusterlarni va GPU larni bir-biri bilan samarali gaplashishi uchun tarmoqni tizim dizayn qilishadi va barcha keyslarga solib test qilib ko'rishadi (simulyatsiya). Keyin eng yaxshisini olib ishlatishadi. Internet networking siz mavjud bo'lmasdi, bundan buyog'iga ham Network injenerlarga talab kuchayib boraveradi (hardware va software da ham).
Communication
Senior bo'lib ishlab yurgan paytlarimda menejerim menga ko'proq Staff engineer bilan ishlashni, unga yaqinroq bo'lishni maslahat bergandi. Shu maslahatiga quloq solib Staff bo'ldim. Chunki undan ko'p bilmlar o'rgandim. 1:1 meeting qilsak ham hech qachon berilgan mavzudamas, boshqa mavzular to'g'risida ko'proq gaplashardik. Shundan keyin har bir system design qilinishi, research qilinishi kerak bo'lgan joylarda birga ishlashni boshladik. Uni kompaniyadagi 7 yillik tajribasini bir qismi menda bo'lgani uchun ham meni promote qilishdi. Ha undan hamma ko'proq ma'lumot olib qolishga harakat qilishdi, ammo ketishiga oz qolganda. Menda bu narsa ancha erta boshlangandi. Staff bo'lganimdan keyin kod yozishdan ko'ra ko'proq boshqa jamoalar bilan ishlash, o'z jamoamga ko'proq o'rgatish va ulardan ham fikrlar olib ular bilan birga o'sishni o'rgandim. Qisqasi yaxshiroq va ko'proq komunikatsiya qilishni o'rgandim.
Eng kattalari shular bo'ldi, qolganlari IaC, Distributed Systems, Platform Engineering, AI/ML va Data Center lar haqida bo'lgan.
Dropbye!
Bugun mana salgina kam bo'lib qolgan sarguzashtga yakun yasayadik. Corporate job bilan hayrlashib, startup olamiga to'liq qadam qo'yayabman.
Oldinda nima kutib turibdi aniq bilmayman, lekin limitlarimni sinab ko'rmoqchiman. Ha aytgancha, Big Tech offer'lar 9-oy valid, B plan ham bor, lekin bunga muhtoj bo'lmaymiz deb umid qilamiz. Let's build something great together!!!
Goodbye Dropbox. It's been a pleasure journey with you.
Bugun mana salgina kam bo'lib qolgan sarguzashtga yakun yasayadik. Corporate job bilan hayrlashib, startup olamiga to'liq qadam qo'yayabman.
Oldinda nima kutib turibdi aniq bilmayman, lekin limitlarimni sinab ko'rmoqchiman. Ha aytgancha, Big Tech offer'lar 9-oy valid, B plan ham bor, lekin bunga muhtoj bo'lmaymiz deb umid qilamiz. Let's build something great together!!!
Goodbye Dropbox. It's been a pleasure journey with you.
Sizga sovg'am bor.
Bugun yakshanba, dam olish kuni. Algoritmlar bo'yicha bir paytlar o'tgan jonli darslarimni sizga o'rganishga bermoqchiman. Yana bunday darslarni o'tish uchun vaqt va sharoit topilishi bilan bularni yanada yaxshiroq qilishga harakat qilamiz.
1. Algoritmlarga kirish
2. Diskret Matematika
3. Array & Strings
4. Recursion
5. Stack & Queue
6. Graph
7. Tree
8. Deque
9. Linked List
10. Sorting
11. Hash Table
12. Searching
12. Sorting 2-qism
13. Dynamic Programming
14. Greedy Algorithms
Darslar yoqgan bo'lsa va fikringiz bo'lsa bemalol donat qilishingiz va fikringizni qoldirishingiz mumkin.
Bugun yakshanba, dam olish kuni. Algoritmlar bo'yicha bir paytlar o'tgan jonli darslarimni sizga o'rganishga bermoqchiman. Yana bunday darslarni o'tish uchun vaqt va sharoit topilishi bilan bularni yanada yaxshiroq qilishga harakat qilamiz.
1. Algoritmlarga kirish
2. Diskret Matematika
3. Array & Strings
4. Recursion
5. Stack & Queue
6. Graph
7. Tree
8. Deque
9. Linked List
10. Sorting
11. Hash Table
12. Searching
12. Sorting 2-qism
13. Dynamic Programming
14. Greedy Algorithms
Darslar yoqgan bo'lsa va fikringiz bo'lsa bemalol donat qilishingiz va fikringizni qoldirishingiz mumkin.
#startup
"Hozir startupda nimalar qilayabman?" eng ko'p so'ralgan savollardan.
Dropbox'da ishlab yurgan paytlarim kichik experiment qilgandik. Mendagi savol quyidagicha:
GPU va CPU o'rtasida ba'zi katta farqlar bor, ammo bu degani modellarni CPU da yaxshi va effektiv yurita olmaymiz degani emas. CPU dagi eng katta ustunlik bu xotirada. Ya'ni siz 256GB RAM istasangiz undan kattaroq qilib ishlatsangiz bo'ladi ammo bu GPUda bu limit 80GB (H100).
CPU va RAM o'rtasida gaplashish tezligi ~60-100 GB/s, GPU esa ~1000-2200 GB/s ga teng. Modellar ma'lumotlar va juda ko'p compute (xisob-kitob) dan iborat. Shuning uchun ham hozircha buni yaxshiroq algoritmlari topilmagan. Ammo bu degan bunday algoritmlar topilmaydi degani emas.
Qiyin muammo ustida ishlayabman, ammo har kuni nimadir o'rgatadigan muammo ustida ishlayabman.
"Hozir startupda nimalar qilayabman?" eng ko'p so'ralgan savollardan.
Dropbox'da ishlab yurgan paytlarim kichik experiment qilgandik. Mendagi savol quyidagicha:
Nimaga biz kichik, efficient va biror tor yo'nalishdagi modellarni ko'paytirib, ularni CPU da yuritishni o'rniga, general modellarni bilimini (weight) kengaytirib ularni ko'p train qilib, hozirda qimmat bo'layotgan GPU larda yuritishimiz kerak?
GPU va CPU o'rtasida ba'zi katta farqlar bor, ammo bu degani modellarni CPU da yaxshi va effektiv yurita olmaymiz degani emas. CPU dagi eng katta ustunlik bu xotirada. Ya'ni siz 256GB RAM istasangiz undan kattaroq qilib ishlatsangiz bo'ladi ammo bu GPUda bu limit 80GB (H100).
CPU va RAM o'rtasida gaplashish tezligi ~60-100 GB/s, GPU esa ~1000-2200 GB/s ga teng. Modellar ma'lumotlar va juda ko'p compute (xisob-kitob) dan iborat. Shuning uchun ham hozircha buni yaxshiroq algoritmlari topilmagan. Ammo bu degan bunday algoritmlar topilmaydi degani emas.
Qiyin muammo ustida ishlayabman, ammo har kuni nimadir o'rgatadigan muammo ustida ishlayabman.
Bunday research talab qiladigan g'oyaga pul tikadigan investorlar juda kam, deyarli yo'q ayniqsa O'zbekistonda. Shuning uchun to'liq vaqtim va diqqatimni bu yerga qarata olmayabman. Ba'zi narsalar uchun pul kerak, pul topish uchun short-term ba'zi narsalarga rozi bo'lish kerak. Moshina yoqilg'isiz uzoqga borolmagani kabi, biz ham resurssiz (pul, vaqt va diqqatsiz) uzoqga borolmaymiz.
Ammo umid qilamanki kelajakda biror loyiham kattalashib ketsa shunday murakkab jarayon uchun o'zini baxshida qilgan yoshlarga o'zim birinchilardan bo'lib investitsiya qilaman. Hozircha jarayondan bahraman bo'layabmiz.
Ammo umid qilamanki kelajakda biror loyiham kattalashib ketsa shunday murakkab jarayon uchun o'zini baxshida qilgan yoshlarga o'zim birinchilardan bo'lib investitsiya qilaman. Hozircha jarayondan bahraman bo'layabmiz.
#startup
Juda kuchli founder va oddiy founder lar o'rtasidagi eng katta farq matematikada ekan. Google TPU, Nvidia GPU, Intel CPU yaratayotgan jamolar bilan suhbat qildim. Xulosa bitta, ular matematikada kuchli.
Misol uchun Dario Amodei (Anthropic), Ilya Sutskever (OpenAI), Sergey Brin (Google), Elon Musk (SpaceX, Tesla), Pavel Durov (Telegram), Jeff Bezos (Amazon), Mark Zuckerber (Meta), Vitalik Buterin (Ethereum), Nikolai Durov (Telegram), Piotr Dąbkowski (ElevenLabs) va h.k.z
Matematika tezkor va aniq fikrlashni o'stiradi. Istalgan eng zo'r ishlar ortida matematika bor. Bizda hali ham "matematika o'rganaymi?" degan savollar bo'lib turadi. G'ayrioddiy ishlarni qilish uchun sizga matematika kerak.
Hozirgi startup'im ham juda ko'p matematika talab qiladi. Deyarli nima o'rgansam ham hammasi borib matematikaga taqaladi. Chip levelda ish qilish, OS bilan chip gaplasha olishi uchun compiler qilish, compiler chipga yuborilgan instruksiyani qay tartibda bajarishiyu, bajarish algoritmlari. Bularni barchasiga matematika kerak va juda low-level bilmlar. Hech nima bilmayman, ammo juda ko'p o'rganayabman.
Matematika o'rganing!!!
Juda kuchli founder va oddiy founder lar o'rtasidagi eng katta farq matematikada ekan. Google TPU, Nvidia GPU, Intel CPU yaratayotgan jamolar bilan suhbat qildim. Xulosa bitta, ular matematikada kuchli.
Misol uchun Dario Amodei (Anthropic), Ilya Sutskever (OpenAI), Sergey Brin (Google), Elon Musk (SpaceX, Tesla), Pavel Durov (Telegram), Jeff Bezos (Amazon), Mark Zuckerber (Meta), Vitalik Buterin (Ethereum), Nikolai Durov (Telegram), Piotr Dąbkowski (ElevenLabs) va h.k.z
Matematika tezkor va aniq fikrlashni o'stiradi. Istalgan eng zo'r ishlar ortida matematika bor. Bizda hali ham "matematika o'rganaymi?" degan savollar bo'lib turadi. G'ayrioddiy ishlarni qilish uchun sizga matematika kerak.
Hozirgi startup'im ham juda ko'p matematika talab qiladi. Deyarli nima o'rgansam ham hammasi borib matematikaga taqaladi. Chip levelda ish qilish, OS bilan chip gaplasha olishi uchun compiler qilish, compiler chipga yuborilgan instruksiyani qay tartibda bajarishiyu, bajarish algoritmlari. Bularni barchasiga matematika kerak va juda low-level bilmlar. Hech nima bilmayman, ammo juda ko'p o'rganayabman.
Matematika o'rganing!!!
#startup
Dropbox'da ML team kichik model train qilishgandi. Biz uni olib Reinforcement Learning muhitga tashlab uni qilayotgan ishlarini kuzatgandik. Bu joyiga to'liq to'xtala olmayman, ammo qiziq bir narsani aytmoqchiman.
Agent muhitga tushganda turli xil yo'llarni sinab ko'radi. Agentga policy beriladi va u shundan chiqib ketmaslikga harakat qiladi. U har xil oldin ko'rmagan (pre-training jarayonida) ishlarni qilib ko'rishga va model mavjud parametrlarini yangilab, muhitda foydali bo‘lgan yangi xatti-harakat strategiyalarini o'rganishga harakat qiladi. Bu yerda odam emas, muhitni o'zi baho qo'yadi, reward (mukofot) yoki penalty (jazo).
Reward funksiyasi yozib chiqiladi (MDP - Markov Decision Process), u orqali agent harakatini baholash uchun formula yozasiz. Bu avtomatlashgan protsess. Qiziq tomoni unga berilgan topshiriq bo'yicha u xato qildi. Yomon baxo olib qayta urinib ko'rib yana xato qildi, umumiy 2ta xato. Yana urinish jarayonida endi bitta xatosini tuzatdi, ammo birinchi qilgan xatosi hali ham turibdi lekin yaxshi baho oldi. Eng qiziq tomoni u qilayotgan ishini unutib qo'ydi. Bu jarayonni qayta-qayta takrorlaganimizda u ba'zan bir nechta xato qilib ko'pini tuzatganda yaxshi baxo olishi bilan eski xatolarni tuzatmadi yoki eski xatosini borligini aytaveradi ammo hech tuzatmasdan boshqa ishlar qiladi.
Bu jarayonni AI agent'lar uchun tuzatish mumkin deb o'ylayman. Ba'zi qilib ko'rgan eksperimentlarim natijasi shuni aytayabdi. Ammo LLM modellar uchun bu jarayonga ko'proq RLHF (Reinforcement Learning from Human Feedback) kerak deb o'ylayman. Ammo u yerdagi odamlar ham professional bo'lishlari kerak. Bitta kamchilik bu jarayonda professional odamlarni rozi bo'lib o'tirishi qiyin, va bu ko'p vaqt oladi. Ammo shunday qilinsa hozirgi LLM (GPT) modellar ancha aqilliroq bo'lgan bo'larmidi deb o'ylaman.
Dropbox'da ML team kichik model train qilishgandi. Biz uni olib Reinforcement Learning muhitga tashlab uni qilayotgan ishlarini kuzatgandik. Bu joyiga to'liq to'xtala olmayman, ammo qiziq bir narsani aytmoqchiman.
Agent muhitga tushganda turli xil yo'llarni sinab ko'radi. Agentga policy beriladi va u shundan chiqib ketmaslikga harakat qiladi. U har xil oldin ko'rmagan (pre-training jarayonida) ishlarni qilib ko'rishga va model mavjud parametrlarini yangilab, muhitda foydali bo‘lgan yangi xatti-harakat strategiyalarini o'rganishga harakat qiladi. Bu yerda odam emas, muhitni o'zi baho qo'yadi, reward (mukofot) yoki penalty (jazo).
Reward funksiyasi yozib chiqiladi (MDP - Markov Decision Process), u orqali agent harakatini baholash uchun formula yozasiz. Bu avtomatlashgan protsess. Qiziq tomoni unga berilgan topshiriq bo'yicha u xato qildi. Yomon baxo olib qayta urinib ko'rib yana xato qildi, umumiy 2ta xato. Yana urinish jarayonida endi bitta xatosini tuzatdi, ammo birinchi qilgan xatosi hali ham turibdi lekin yaxshi baho oldi. Eng qiziq tomoni u qilayotgan ishini unutib qo'ydi. Bu jarayonni qayta-qayta takrorlaganimizda u ba'zan bir nechta xato qilib ko'pini tuzatganda yaxshi baxo olishi bilan eski xatolarni tuzatmadi yoki eski xatosini borligini aytaveradi ammo hech tuzatmasdan boshqa ishlar qiladi.
Bu jarayonni AI agent'lar uchun tuzatish mumkin deb o'ylayman. Ba'zi qilib ko'rgan eksperimentlarim natijasi shuni aytayabdi. Ammo LLM modellar uchun bu jarayonga ko'proq RLHF (Reinforcement Learning from Human Feedback) kerak deb o'ylayman. Ammo u yerdagi odamlar ham professional bo'lishlari kerak. Bitta kamchilik bu jarayonda professional odamlarni rozi bo'lib o'tirishi qiyin, va bu ko'p vaqt oladi. Ammo shunday qilinsa hozirgi LLM (GPT) modellar ancha aqilliroq bo'lgan bo'larmidi deb o'ylaman.
GridWall RL Environment
Reinforcment Learning nimaligiga qiziqadiganlar uchun. Buni vizual ko'rish uchun ilgariroq bir o'yin yasagandim. Uni UI qismini AI dan yaxshilashini so'rab, sal to'g'irlab chiqardim. Kod imkon qadar oson yozilgan, iltimos qattiq kritika qilmang (yosh bo'lganmanda).
GridWall o'yinini RL muhitda o'rganish jarayoni uchun o'yin. Siz uni o'rganish jarayonini kuzatib turolasiz. Juda oddiy va qiziq proyekt
GridWall - bu qutichalardan iborat bo'lgan o'yin. Unda Start nuqtasi, Trap (tuzoq), Wall (devorlar) va Goal (So'ngi finish) bor. Agent maqsadi bu o'yinda o'ynab, Goal ga borish uchun optimal yo'lni topishga urinish. Xaritani kod orqali istalgancha o'zgartira olasiz.
Q-Learning algoritmi modellarsiz o'rganish uchun moslashtirilgan algoritm. Bu yerda hech qanday AI model yo'q, va u o'yin haqida hech narsa bilishi shart emas. Ammo u qilib ko'rib o'rganadi. Ya'ni
try action -> receive reward -> update belief
Q-Value degan joyi bor Q(state, action). U orqali qaysi state (holatda) qaysi harakat (action) yaxshi bo'lishini shunchaki so'raydi, ya'ni oddiy hashmap deb tasavvur qilsangiz bo'ladi.
Ko'proq research qilib ko'ring yana
Reinforcment Learning nimaligiga qiziqadiganlar uchun. Buni vizual ko'rish uchun ilgariroq bir o'yin yasagandim. Uni UI qismini AI dan yaxshilashini so'rab, sal to'g'irlab chiqardim. Kod imkon qadar oson yozilgan, iltimos qattiq kritika qilmang (yosh bo'lganmanda).
GridWall o'yinini RL muhitda o'rganish jarayoni uchun o'yin. Siz uni o'rganish jarayonini kuzatib turolasiz. Juda oddiy va qiziq proyekt
GridWall - bu qutichalardan iborat bo'lgan o'yin. Unda Start nuqtasi, Trap (tuzoq), Wall (devorlar) va Goal (So'ngi finish) bor. Agent maqsadi bu o'yinda o'ynab, Goal ga borish uchun optimal yo'lni topishga urinish. Xaritani kod orqali istalgancha o'zgartira olasiz.
Q-Learning algoritmi modellarsiz o'rganish uchun moslashtirilgan algoritm. Bu yerda hech qanday AI model yo'q, va u o'yin haqida hech narsa bilishi shart emas. Ammo u qilib ko'rib o'rganadi. Ya'ni
try action -> receive reward -> update belief
Q-Value degan joyi bor Q(state, action). U orqali qaysi state (holatda) qaysi harakat (action) yaxshi bo'lishini shunchaki so'raydi, ya'ni oddiy hashmap deb tasavvur qilsangiz bo'ladi.
Ko'proq research qilib ko'ring yana
#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