#randomThoughts

Hamma havotir olayotgan, katta kompaniyalar tinimsiz bozorda raqobatlashayotgan narsa bu hozir AI. Sizu-biz ishlatayotgan LLM'lar ham aslini olganda bir til. Ularni linguistic, coding, communication, translation, explanation va e.t.c language yo'llarida ishlatishingiz mumkin. Dasturlash sohasini o'sish tarixi doim ajablantirib keladi.

Tarixda ilk yaratilgan dasturlash tillaridan biri bo'lmish FORTRAN (FORmula TRANslation) ham asosan matematik xisoblash va shu kabi yo'nalishlarda ishlatilgan. Assemblyda kod yozish juda katta intelektual kuch talab qilinishi xisobiga bunday tillar ishlab chiqilgan. Ha compiler dasturlash tillaridan oldin odamlar 0 va 1 larda kod yozishgan (adashmasam).

Tillar sekin-asta yaxshilanib inson tiliga yaqin tarzda kod yozish imkonini berishi o'sib boraverishini tillarni syntax'idan ko'rsangiz bo'ladi. C'da yozilgan kodni tushunish qiyin ammo Python kabi tillardagi kodlarni shunchaki o'qib tushunish osonroq. Hozir esa AI davridamiz. Siz to'laqonli inson tilida kod yozasiz (deyarli).

"Python bo'lmaydi, C++ o'rganish kerak", "Hech kim C da kod yozmay qo'yadi" kabi so'zlarni deyarli 20-30 yildan beri aytib kelishayabdi ammo ular akutalligini yo'qotishmadi. Xuddi shunday AI ham sizni ishingizni olish uchun emas, balkim siz uchun qulayroq ish muhiti yaratish uchun ishlab chiqarilayabdi deb o'ylayman.

AI ishni olib qo'yish xavfi bormi? Albatta, ammo yangi ish o'rinlari yaratish ehtimoli ham bor (balkim yo'qdir, aniq aytish qiyin). Aniqroq nimani ayta olish mumkin? AI shunchaki yordamchi bo'lib qoladi, to AGI yoki ASI yaratilmaguncha. Chunki AI o'zi, erkin harakat qila olmaydi, fikrlay olmaydi (hozircha).

AI qurish uchun eng zo'r til bu Python deyishadi. Menimcha unchalik ham emas. Shaxsan hozircha ko'rgan katta loyihalarim source kodi asosan Rust yoki C++ da (Dropbox'da ham). Adashmayotgan bo'lsam Anthropic (Claude) va Github (Copilot) ham asosan shu tillardan foydalanadi. Buni sabablari ko'p (qoidalar qattiqligi, xotira boshqaruv, xavfsizlik, resurslar, e.t.c.).

Bu post nimadir o'rgatish uchun emas, shunchaki fikrlarimni yozib qo'yish uchun yozildi. "Nimadir" yozgim kelmadi, o'rniga "random thought of mine" yoza qoldim 🙃

#computerNetworking

System Design intervyularda asosan katta tizimlarni qurish haqida gaplashiladi. Butun katta tizimni 45 daqiqada qurish qiyin, ammo uning qaysidir muhim qismiga diqqat qaratish va o'sha qismini yaxshiroq qilib berish nisbatan osonroq.

Siz har qanday servis qurishingizdan qat'iy nazar sizni servisingiz tashqi servislar bilan aloqa qila olishi kerak. Buning uchun sizdan Networking bilimi talab qilinadi. (Ha hozir hype bo'layotgan AI, cloud provider, cloud computing, frontend, backend, devops, ... larni barcha networking siz oddiy narsalar bo'lib qolishadi)

Interviewer: servisingiz low bandwidth xolatida ham yaxshi ishlay oladimi?
Siz, ichingizda: WTH, low bandwidth nima?

Bandwidth bu berilgan vaqt oralig'ida network connection orqali qancha ma'lumot yubora olishingiz xisoblanadi. Misol uchun siz wifi o'rnatish uchun kelishga ISP servis 100Mb/s degan bo'lsa, demak sizni tarmoqingiz ISP dan sekundiga 100 Megabits ma'lumot yuklab ololadi yoki yubora oladi.

Ammo menda bir muammo bo'layabdi. Kecha do'stim yuborgan linkga bosganimda sahifani ochishga 5 soniya vaqtim ketdi. Sahifada katta fayllar mavjud emas ekan. Bu holatda, meni internetim yomon ishlayabdimi?

Yo'q, high bandwidth degani har narsani tez yuklaydi/yuboradi degani emas. Bu yerda latency degan tushuncha kirib keladi. Network latency bu so'rov yuborish va qabul qilish jarayoni uchun ketkazilgan vaqtga nisbatan aytiladi.

High latency keltirib chiqaruvchi omillar turli xil bo'lishi mumkin: serever side dynamic content'ni compile qilinishi, server-client o'rtasidagi masofa, browser render qilish vaqti, va boshqa faktorlar ham bo'lishi mumkin. Agar software tomonda hammasi yaxshi bo'lsa, demak gap aniq masofada bo'ladi.

Misol uchun Google har qanday mamlakatda yaxshi ishlaydi. Buning sabablaridan biri bu masofa. Ya'ni sizni ISP servisingiz eng yaqin Google servislariga so'rov yuboradi. Shunda low latency bo'lgani xisobiga sizga garantiya berilgan internet o'z o'rnida ishlayotgandek ko'rinadi. Eng yaqin serverlarni joylashtirish jarayoni esa CDN ya'ni Content Delivery Network (Kontent yetkazuvchi tarmoq) deb ataladi.

Global servis qurayotganingizda masofaga albatta e'tibor bering. Chunki dasturingiz qanchalik yaxshi bo'lmasin, masofa uni sekinroq yoki yomonroq ishlar ekan degan tushunchaga sabab bo'lib qolishi mumkin.

#randomThoughts

Bozorda "sun'iy intelekt poygasi" boshlangan. Hamma AI haqida gapirayabdi. Meta eng yaxshi mutaxasislarni jalb qilishga qattiq bel bog'lagan.

Jensen Huang (CEO at Nvidia) Machine Learning va Computing uchun eng foydali yo'l bu CPU bilan emas, balkim GPU bilan ekanini qisman bo'lsa ham ko'ra olgan inson sifatida bilaman. Hozir Nvidia kompaniyasi bozor narxi $4 trillion dan oshibdi, bu Google + Meta va yana bir nechta kompaniyalarni bozor narxi degani.

Hamma AI uchun kurashayotgan bir vaqtda meni bir narsa ko'p e'tiborimni tortayabdi - "Quantum Computing". Agarda kelajakda AGI balkim, ASI ishlab chiqariladigan bo'lsa ular albatta ko'p quvvat va tezlik talab qilishni boshlashiga olib boradi. Bunda GPU lar qanchalik darajaga bora olishini bilmayman, ammo ular nazarimda Quantum chip'larchalik kuchli bo'la olishmaydi deb o'ylayman.

Agar kelajak uchun yaxshi investitsiya qilmoqchi bo'lsangiz, qanchadir vaqtingizni shu sohani o'rganishga ham investitsiya qiling.

Let me know if I am wrong.

Problem

Har qanday kompaniyada "onboarding" jarayoni bor ya'ni sizni kompaniya, jamoa, muhit, va ish qurollari bilan yaxshilab tanishtirishadi. Mobal.io kompaniyasidan oldingi barcha ishlagan joylarida o'zimga bir xil gapni takrorlar edim:
- Tezroq hamma narsani o'rganishim va code contribution qilishim kerak!

Biror yangi mavzuni o'rgansam "obsessed" bo'lib qolar edim. Kunlar emas, haftalarni sovurib yuborardim. Bunga asosiy sabab bu berayotgan xato savollarim bo'lardi:
- How it works (internally)?
- Why it works (that way)?


Experience

Bu qilgan qarorlarim xatoligini kech tushundim. Ba'zilari esa menga juda qimmatga tushgan. Texnologiyalarni ichini qanday ishlashini tushunish yoki yodlab olish sizni Senior qilib qo'ymaydi. Texnik bilimlarni kuchliligi sizni Senior qilib qo'ymaydi. Ishonavering, Senior bo'lish uchun ko'plab omillar kerak, yaxshi komunikatsiya, jamoa bilan ishlay olish, to'g'ri paytda to'g'ri yechim qilishni ko'ra olish va boshqa (Soft skill) tajribalar ham talab qiladi. Men buni kech angladim.


Solution

Onboarding vaqtida sizdan hech kim, hech qanday ortiqcha ishlar kutmaydi. Siz shunchaki o'zingizdan ko'p narsa kutishingiz mumkin. Jamoa sizni tezroq moslashishingizga yordam berish uchun doim tayyor bo'ladi. Ko'p vaqtingizni tejamoqchimisiz? Unda ushbu 2 savolni bering:
- What and Where?

- Bu servis o'zi nima?
- Nimaga mavjud?
- Qayerda ishlatishim kerak o'zi buni?
... degan savollar to'g'riroq bo'ladi. Har qanday kompaniyada ko'plab texnologiyalar va servislar ishlatiladi. Ularni nimaligi, qayerda ishlatishingizni bilish, sizga boshqa bilimlardan ustunroq xisoblanadi.

Muhtojlik xis qilmaguncha tegmang. Ha bu xuddi "kod ishlayabdimi, demak tegmang" degan gapdek eshitiladi va bu juda to'g'ri fikr. Siz servislarni optimizatsiya qilaman deb ishlab turgan narsani buzishingiz mumkin. Bu esa ishlab turgan biznesni buzishdek gap. Buni premature optimization deyishadi (kerakmas bo'lsa ham optimizatsiya qilish).

Ko'plab muvaffaqiyatli startup'lar o'zlari ishlatayotgan servis yoki texnologiyalarni to'liq yoki qisman bo'lsa ham tushunishmaydi. Ammo ular bu servis/texnologiyalarni qayerda ishlatishni, qanday ishlatishni bilishadi.

Dropbox'ga ilk bor qo'shilganimda Networking & Automation Team a'zosi edim. Asosiy loyihalarimiz ko'lami cheklangan edi. Ko'p jamoalar, tizimlar bilan ishlash uchun loyiha berishdi. Jamoani bu tizim/texnologiya bilan tajribasi yo'qligi va men ularni o'rganib, tadbiq qila olishim ham ko'p qo'l keldi. Bu tizmlarni qanday ishlashini aniq bilmayman, ammo ularni ishlatish bizdagi muammoni yecha olishini sezib turar edim. Bu ish ham promotion olishga katta xissa qo'shgan. Bilaman boshqa omillar ham bor, misol uchun ko'plab TechTalk'lar berish va jamoalarni bilmlarini oshirish ayniqsa juda katta role o'ynaydi. Kompaniyamiz CTO'si bilan tanish bo'lishim ham sababchi bo'lishi mumkin : )

Boshqalar: Hamma narsani zo'r eplayabdida shu yigit, malades.

Men: 🥲

#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 : )

Google'ga yo'q dedim.

Ha, noto'g'ri eshitmadingiz, Google bergan taklifni rad qildim. Qancha yoshlarni orzusi bo'lgan kompaniyaga men rad javobini berdim.

Google bilan pishirgan ilk oshimiz o'tgan yili bo'lgandi. Kompaniyadan ishga taklif kelgan ammo L4 (middle) lavozimiga, Dropbox taklif qilgan IC4 (Senior) lavozimi balandroq bo'lgani uchun Google bilan karyeramni davom etmadim.

Ammo Google bas kelmadi, men uchun Tizim Dizayni intervyusini tashkil qilib berdi. Undan yaxshi o'ta oldim, bu safar L5 (Senior) lavozimiga taklif oldim, ammo Dropbox IC5 (Staff) lavozimga taklif bilan Googleni ortda qoldirdi yana.

Google'dan keyingi qadamni kutib qolaman.

Google'dagi akalar, rekruiterlarga aytinglar, yaxshi oylik va sharoit qilib bersa boraman.

#announcement

cloud.42.uz bir vaqtni o'zida 500 ta odamga xizmat ko'rsata olardi. Nimaga ko'proq emas? Chunki cloud tekin emas, 500 ta odamni har biriga VM (virtual machine) bering. Va har bir VM narxi $5 xisoblaganizda ham jami $2500 har oy pul to'lashingizga to'g'ri keladi.

Biz jonajon talabalarimiz uchun, jamoamiz bilan yangicha yechim ishlab chiqdik. Endi u 500 ta emas, 5 million odamga ham xizmat ko'rsata oladi.

Bu yechim, bizga qanday qiymat olib keladi? Sizga biz yanada ko'proq Cloud, AI, Security, DevOps, Backend, Frontend va boshqa bilmlarni amaliy yetkazishimizdagi to'siqlarni olib tashlaydi.

Sinab ko'ring

#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.

#failure

Omadsizliklarim haqida qisqacha (hammasini yozsam sig'maydi ekan):

・Matematikadan yechgan ilk 10ta testimni natijasi tahmin qilib chiqsa ham, yaxshiroq natija olsa bo'ladigan darajada yomon bo'lgan. Buning uchun ustozimdan ko'p kaltak yer edim.

・SJTU Universitetida hamma yaxshi o'qib, imtixon topshirgan fandan yiqilganman. O'sha 1ta yomon o'quvchi men bo'lganman.

・Ilk loyihamni backend qismini juda yomon yozganman, bunga sabab shoshqaloqlik edi. Shuning uchun ham ko'p yiqilar edi va foydalanuvchilar arz qilardi.

・25ta open-source qilaman deb yozgan loyihalarimni 10% github'da private repo bo'lib turibdi, qolgalari github'ga ham yuklanmagan. Ularni kodini ko'rib yig'laydi kishi.

・Mobal.io ishlagan vaqtlarim katta change qilib uni production'ga yuborganimni eslayman. Shunda serverimiz 1 kunga meni deb ishdan chiqgan.

・Dropbox'da 50k config fayllarni o'chirib yuborib, data center (ma'lumotlar markazi ya'ni serverlar) qurish jarayonini 1 haftaga muzlatib qo'yganman.

・42.uz da ham ba'zi qismlarni tuzataman, yaxshilayman yoki tezlashtiraman deb ko'p buzganman.

Siz nimalar qilgansiz?

Kun meme'i

DNS qanday ishlashini bilasizmi?

Google Chrome dasturini ochdingiz. Search Bar'ga "otabek.io" deb yozib enter tugmasini bosganingizda nimalar sodir bo'ladi? Qanday sodir bo'ladi? Avvalroq yozgan dnsql dasturimni yaxshiladim va Open-Source qilib githubga yukladim.

U yerdagi kontentni o'qib siz ham DNS query resolver dastur yasab ko'rsangiz bo'ladi. Keyinroq bu haqda to'liqroq blog yozishga harakat qilaman.

Contribute uchun ochiqmiz:
Github: https://github.com/otabekswe/

#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.

#security

Yuqoridagi rasm bir ko'rishda Microsoft kompaniyasidan kelganga o'xshaydi. Logo, UI dizayn, hammasi deyarli bir xil.

Mobil telefonga email kelsa odatda kimdan, qanday domain'dan kelganini tekshirmaysiz. Ammo kompyuterdan email o'qisangiz bir qarab qo'yasiz domain'ga.

Bu yerda email microsoft.com dan emas, rnicrosoft.com dan kelgan (tushunmagan bo'lsangiz, yaxshilab o'qing). Mana shu kichik "rn" va "m" o'rtasidagi farq odamlarni oson aldanishiga sabab bo'ladi. Bu xujumni nomi "typosquatting attack" deyiladi.

Xujum qilaytogan odam shunaqa domain register qiladi. Qanchalik yaqinroq typo tanlay olsa unga yutish ehtimolini oshiradi.

Bunday xujumlar tarihda ko'proq HR, finans va shu kabi bo'limlarda ancha qo'l kelgan. Injinerlar jamoasida ham ba'zi muvaffaqiyatli hikoyalar bor ammo juda kam.

Yechim oddiy:
- Biror ish qilishdan oldin, doim domain'ni yaxshilab tekshiring
- Link ustiga bosishdan oldin, link qayerga jo'natayotganini o'qib ko'ring.
- Reply-to degan joyingizni ham tekshiring, ba'zan xabar va javob uchun alohida-alohida manzillar ishlatiladi
- So'ralmagan ishingiz uchun odatda sizga email kelmaydi.

Real hikoya:
2020-yil ilk o'qishga kirgan paytimda O'zbekistondagi va Xitoydagi kursdoshlarimni men ham shunday phishing qilganman. Faqat u yerda Facebook.com ga bo'lgan parollarni olgandim (45ta odamni bergan username va password'i ishlagan). Lekin, ularni sotmaganman shunchaki ularni ogohlikga chaqirganimni hali ham eslayman.

Ogoh bo'ling!

#networking

Nega UDP paketlar yo'qolib qoladi?

Networking bo'yicha bilmi borlar bilan gaplashsangiz TCP vs UDP haqida gapirishadi. Ular UDP haqida gapirishgan paytda uni "reliable" emas deyishadi. Ammo nega unday deyayotganini so'rasangiz javob yo'q. Bilganlar esa nega packet tushib qolishini aytib bera olishmaydi.

1. Tasavvur qiling siz juda ko'p UDP paketlarni bir manzildan ikkinchisiga yuborayabsiz. Har bir UDP socket'da socket sender buffer degan qismi mavjud. Ya'ni paketlar yuborilishdan oldin ayanan o'sha yerga jamlanadi (buffer bu bir vaqtinchalik xotira). Linux kernel bu paketlarni o'qish va yuborish bilan shug'ullanadi. Agar kompyuteringiz yoki serveringizdagi Network Card tezligi past bo'lsa, dasturni tezligiga tusha olmasligi va yuborish jarayonda paketlar yo'qolishi mumkin. Bu qanchalik odatiyligini bilmayman, ammo bunday holatlar bo'lgan.

2. UDP paketlarni internetga yubordingiz (kompyuteringizdan chiqib ketdi hammasi 100% muvaffaqiyatli), u yo'lda, bir router/switch'dan ikkinchisiga o'tish jarayonida yo'qolishi mumkin. Bu yerda router/switch queue limit tugab qolishi mumkin. TCP va UDP paket kelganda TCP paketlarni himoya qilish orqali UDP paketlarni tashlab yuborishi mumkin. Va yana ko'p boshqa sabablar ham bor.

3. Birinchi va ikkinchi bosqich muvaffaqiyatli bo'ldi ham deylik. Ya'ni yo'l yurib, barcha paketlar ohirgi nuqtaga yetib keldi. Endi sizni dasturingiz paketlarni kutib turibdi. Hammasi juda zo'r. Guess what, paketlar qayerga kelib tushadi? Yes, yana o'sha socket sender buffer ga kelishadi. U buffer hajmi qanchalik katta? U barcha paketlarni sig'dira oladimi? Bu savolga to'liqroq bu yerda o'qib ko'ring [link]. Meni kompyuterimda bunday ekan

# Macbook'da
# socket max buffer size
➜  ~ sysctl kern.ipc.maxsockbuf
kern.ipc.maxsockbuf: 8388608

# send/receive buffer size
➜  ~ sysctl net.inet.udp.recvspace
net.inet.udp.recvspace: 786896

Bu raqamlar byte emas, balkim page degani (bu haqda ko'proq keyinroq yozaman). Meni xolatimda har bir page 16KB degani ekan. Demak mendagi max buffer size 8388608 => 8MB ga to'g'ri kelar ekan (8 388 608 / 1024 / 1024 = 8). Standart receive buffer kengligi esa 0.75MB ekan. Demak agar menga katta miqdorda paketlar kirib kelsa va buffer to'lib qolsa 8MB dan buyog'ini tashlab yuborar ekan. Bu yerda application tezligiga ham bog'liq paketlarni saqlab qolish yoki tashlab yuborilishi. Shu paytgacha kompyuterim qancha paketlarni tashlab yuborgan ekan deb qizdim va natija shunday:

➜  ~ netstat -s -p udp
udp:
 141545183 datagrams received
  0 with incomplete header
  0 with bad data length field
  0 with bad checksum
  1048 with no checksum
  45648 checksummed in software
   31046 datagrams (20030730 bytes) over IPv4
   14602 datagrams (3553616 bytes) over IPv6
  159392 dropped due to no socket
  101590 broadcast/multicast datagrams undelivered
  0 IPv6 multicast datagram undelivered
  0 time multicast source filter matched
  9244 dropped due to full socket buffers
  0 not for hashed pcb
  141274957 delivered
 38752867 datagrams output
  415727 checksummed in software
   8977 datagrams (3238427 bytes) over IPv4
   406750 datagrams (117958647 bytes) over IPv6
 40 open UDP sockets

Facebook'da ishlaydigan do'stim bir hikoya aytib bergandi. Facebook’ning “Live” funksiyasi ham UDP'dan foydalanar ekan (RTCP/UDP). 2018-yilda ular serverda recv buffer limiti to‘lganida, Linux kernel UDP paketlarni tashlab yuborish muammosiga duch kelishgan ekan. Monitoringda bu drop’larni faqat server metrikalari orqali ko‘rishganda, foydalanuvchi tarafida video ‘pause’ bo'lishi kuzatilgan ekan. Muammoni sababi net.core.rmem_max juda past bo'lgan ekan. "Live session burst" ya'ni ko'p foydalanuvchilar live ga kirganida socket buffer to'lib ketgan. Yechim sifatida Facebook SRE jamoasi "dynamic UDP buffer autotuning" qo'shishganini aytgandi. Ya'ni kernel sysctl parametrlarini runtime’da trafikga qarab oshirish mumkinligini topishgan. Metrikalarni esa Prometheus bilan qattiq kuzatishgan ekan.

Katta tizmlarda ishlasangiz har bir qarich siz uchun muhimligini sezib borar ekansiz.

#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.

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!

Updated: Bu voqeaga ancha bo'lgan lekin hozir yozgim kelib qoldi. Balkim shu ham promoga yordam bo'lgandir, who knows