'Greedy' Karyera Yo‘li
1-qism
🇺🇿

Greedy — bu algoritmlar bir turi bo'lib, unda har bir qadamda mahalliy eng yaxshi tanlov qilinadi, va bu tanlov oxir-oqibat global eng yaxshi yechimga olib borishiga umid qilinadi.

Matematika va kompyuterlarga bo‘lgan qiziqish bilan ulg‘ayganim sababli, 2018 yil boshida menda bir savol paydo bo‘lgan edi: keyingi qadam nima? Javob oddiydek tuyulardi — men dasturiy ta’minot muhandisi bo‘laman. Ammo aniqrog‘i, matematika bilan chambarchas bog‘liq bo‘lgan yo‘nalishni tanlashni xohlardim. Menimcha, fan qanchalik matematikaga yaqin bo‘lsa, shunchalik hayotga ham yaqin bo‘ladi. O‘sha paytda juda ommabop bo‘lgan Web Development esa bu qarashimga unchalik mos kelmasdi.

Sun'iy intellekt sohasi (AI) atrofida allaqachon katta shov-shuv bor edi, shuning uchun muhandislik va matematikani birlashtirgan aynan shu soha men uchun to‘g‘ri yo‘l bo‘lsa kerak, degan xulosaga keldim. Muammo shundaki, o‘sha vaqtda, ayniqsa yangi boshlovchilar uchun, deyarli hech qanday ish imkoniyatlari yo‘q edi.
2018 yil oxirida esa biroz “omadli” tarzda, bir kompaniya universitetimizda mehmon ma’ruza o‘tkazdi. Ular O‘zbekistonda sun’iy intellekt bo‘limini ochayotganini, unga shveysariyalik AI mutaxassisi rahbarlik qilishini va tez orada amaliyot (internship) dasturiga qabul boshlanishini aytishdi. Bu men uchun ideal imkoniyatdek tuyuldi.
Suhbatlardan muvaffaqiyatli o‘tdim va ularning 6 oy davom etadigan “internshipga tayyorlov” dasturiga qabul qilindim. Asosan bizga Coursera’dagi AI/ML kurslarini mustaqil o‘rganish topshirildi. Dastur oxirida matematika va mashinaviy o‘rganish asoslariga oid yakuniy imtihon bo‘ldi. Bir oy kutdim va natijam yuqori ekanligi aytildi. 10 kishidan atigi 3 nafari muvaffaqiyatli o‘tgan edi — men ham ular orasida edim. Bu orzularim ushalayotgandek tuyuldi. Keyingi qadamlarni intiqlik bilan kutdim… ammo sukut. Yana bir oy o‘tdi…

Va kutilganidek (yoki kutilmaganda), email keldi: ular endi AI amaliyotchilariga ehtiyoj yo‘qligini, loyiha doirasida “yetarlicha AI ishi yo‘qligi”ni aytishdi. Shu bilan, 9 oyim sarflandi va bu xat mening AI sohasidagi karyera orzularim uchun berk ko‘cha bo‘lib tuyuldi.

Davomi bor…

#career #growth #ai

'Greedy' Career Path
Part 2
🇺🇸

That closed door was a good learning to open the right next door for my career. I had 2 paths that I had considered next:

Path 1: continue with AI, thinking long term with the hope that AI will take off one day, where I could be part of the ship, with the caveat of having 0 real opportunities at that moment.

Path 2: pivot to Web Development, hundreds of immediate opportunities, with peers (as students) already earning 2-3x more than country's average salaries, with the caveat that this work seemed automatable in the quite near future and eventually a saturated market.

I applied what we call in Computer Science a greedy algorithm, optimizing for the immediate best option at that moment: Web Development. Fortunately, a close friend from university, who had already been successful as a Web Developer, referred me for my first Web Development job at the company he was working at. From there, things started moving fast.

Looking back, that locally optimal choice opened doors and a career path I couldn't have imagined, that eventually brought me to Amazon as a Software Engineer. You can read more about my path to Amazon here.

But did the greedy algorithm actually work? Or did I just get lucky?

I will answer that in Part 3.

#career #growth #ai

'Greedy' Karyera Yo'li
2-qism
🇺🇿

O'sha yopilgan eshik karyeramda keyingi to'g'ri eshikni ochish uchun yaxshi saboq bo'ldi. Buyog'iga oldimda 2 ta yo'l bor edi:

1-yo'l: Uzoqni ko'zlagan holda AI bilan davom etish: "bir kun kelib AI rivojlanib ketganda, men uning bir qismi bo'lishim mumkin" degan fikr bilan. Lekin, o'sha paytlarda ish bozorida hech qanday real imkoniyatlar yo'q edi.

2-yo'l: Web Development ga o'tish: ish bozorida talab katta, yuzlab vakansiyalar mavjud, tengdoshlarim (talabalik davrida) allaqachon o'rtacha oyliklardan 2-3 baravar ko'proq topishayotgan edi. Lekin bu ish yaqin kelajakda avtomatlashtirilib, oxir-oqibat to'yingan bozorda talab yo'qolib ketish xavfi bor edi.

Men informatika (Computer Science) da greedy algoritm deb ataluvchi algoritmni qo'lladim, ya'ni o'sha paytdagi eng yaxshi variantni tanladim: Web Development. Yaxshiyamki, universitetdagi yaqin do'stim, allaqachon Web Developer sifatida muvaffaqiyatli ishlab kelayotgan edi va u meni o'zi ishlayotgan kompaniyaga ishga tavsiya qildi. Bu mening birinchi Web Development'dagi ishim edi. O'sha ondan boshlab, ish faoliyatim tez sur'atlarda rivojlana boshladi...

Orqaga qarasam, o'sha lokal optimal tanlov men tasavvur qila olmagan eshiklar va karyera yo'lini ochdi, natijada meni Amazon'ga dasturchi (Software Engineer) sifatida olib kelgandi. Amazon'ga yo'limni bu yerda batafsil o'qishingiz mumkin.

Lekin greedy algoritm haqiqatan ham ish berdimi? Yoki shunchaki omadim keldimi?

Bunga 3-qismda javob beraman.

#career #growth #ai

Friday deployments

Today is Friday and engineers finish their day hoping to have incident-less weekend ahead.

Engineers all know it is not a good idea to deploy software on Fridays (for obvious reasons). In most places, it is a good intention: "hey, we don't deploy on Fridays, please", and someone still does.

At Amazon, we don't rely on good intentions, instead we rely on guardrails (more on that here). All CI/CD pipelines that deploy to production are automatically blocked across all teams on Fridays and outside business hours.

I'm the oncall for my team this week, and thanks to this guardrail, I know I won't get a weekend incident caused by a teammate deploying a bug without my awareness.

Have a nice weekend!

#amazon #aws #operations #oncall #monitoring #cicd

'Greedy' Career Path
Part 3
🇺🇸

Coming back to the question from Part 2: "Did the greedy algorithm actually work? Or did I just get lucky?"
Answer: it wasn't luck; the greedy algorithm worked, but in ways I never expected.

If you still remember, I was rejected from an AI internship in 2018, because "there was no AI work to do". Fast forward to 2026, I'm at AWS, and we are being told "if you are not using AI for your job, you literally don't belong here". If we are not using AI, we are under-performing. Not only that, over the last year me and my team built an agentic AI pipeline that collects data, generates artifacts, and evaluates their quality, completely automating a big piece of manual work. Basically, we built a team of agents working for us overnight, and lets us focus on novel problems.

The path I walked away from a few years ago suddenly became my daily work. I couldn't have gotten here by waiting for AI in 2018. In 2018, I optimized for what was visible: job opportunities, immediate growth, tangible skills. Web Development taught me to deliver business value. It taught me how systems work at scale. It brought me to Amazon. And Amazon put me right in the center of AI opportunities at scale. The 2018 version of me couldn't have planned this path. He could only take the best step available at that moment.

If you're facing a "passion vs. pragmatic" decision, just know that you are not abandoning your goals by applying a greedy algorithm, and it can eventually lead to the global optimum.

The algorithm worked once. Maybe it's time to run it again: switch to AI research?

#career #growth #ai

'Greedy' Karyera Yo'li
3-qism
🇺🇿

2-qismdagi savolga qaytamiz: "Greedy algoritm haqiqatan ham ishladimi? Yoki shunchaki omadim keldimi?"
Javob: bu omad emas edi; greedy algoritm ishladi, lekin men kutmagan yo'llar bilan.

Agar hali esingizda bo'lsa, 2018-yilda AI internship'dan rad etishgan edi, chunki "AI da qilishga ish yo'q edi". 2026-yilga kelib, men AWS'daman va bizga "agar siz ishingizda AI'dan foydalanmayotgan bo'lsangiz, bu yerga tegishli emassiz" deyishmoqda. Agar biz AI'dan foydalanmasak, past natija ko'rsatyapmiz demakdir. Bundan tashqari, o'tgan yil davomida men va jamoam ma'lumot to'playdigan, artefaktlar yaratadigan va ularning sifatini baholaydigan agentic AI pipeline qurdik, bu katta hajmdagi qo'lda bajariladigan ishlarni to'liq avtomatlashtirdi. Oddiy qilib aytganda, o'zimiz uchun tun-u kun ishlaydigan agentlar jamoasini yaratdik va bu bizga yangi muammolarga e'tibor qaratish imkonini berdi.

Bir necha yil oldin tark etgan yo'lim to'satdan kundalik ishimga aylandi. 2018-yilda AI'ni kutib o'tirib bu yerga yetib kelolmasdim. 2018-yilda men ko'rinadigan narsalarni optimallashtirdim: ish imkoniyatlari, darhol o'sish, aniq ko'nikmalar. Web Development menga biznesga foydali bo'lishni o'rgatdi. U menga tizimlar qanday katta miqyosda ishlashini o'rgatdi. U meni Amazon'ga olib keldi. Va Amazon meni katta miqyosdagi AI imkoniyatlarining markaziga qo'ydi. 2018-yildagi "men" bu yo'lni rejalashtira olmas edim. "U" faqat o'sha paytdagi eng yaxshi qadamni qo'ya olardi.

Agar siz "ishtiyoq yoki pragmatik" qaror oldida turgan bo'lsangiz, shuni bilingki, greedy algoritmni qo'llash orqali maqsadlaringizdan voz kechayotganingiz yo'q, va u oxir-oqibat global optimumga olib kelishi mumkin.

Algoritm bir marta ishladi. Ehtimol uni yana ishga tushirish vaqti kelgandir: AI research'ga o'tishim kerakmi?

#career #growth #ai

States of Mind

"Bir aylanib kelsam yaxshiroq g'oyalar kela boshlaydi", - kabi gaplarni ko'pchilikdan eshitgansiz.

Aslida bu tasodif emas. Miyamizda Default Mode Network (DMN) deb ataluvchi neural tarmoq e'tiboringizni tor topshiriqqa qaratmay erkin qo'yganingizda miyangizdagi o'y-xayollarga mas'ul bo'ladi.

Faraz qiling miyangizda juda ko'p g'oyalar mavjud (states). Ammo, ikki g'oya orasidagi bog'lanish aniq emas. Berilgan masalani ishlash uchun esa o'sha state'lar ichidan yechimga olib boruvchi yo'l (path) topish kerak.

Ongli ravishda unday katta grafdan kerakli boshlang'ich nuqtani topish ham, keyingi to'g'ri state'ni tanlash ham mushkul (yechim qotib qoldi).

"Bir aylanib kelganda" esa DMN miya state'lari orasida tasodifiy yurish (random walk) amalga oshiradi. Bu esa o'z aqlingiz bilan tanlashingiz ehtimoli kam bo'lgan state'larning tanlanish ehtimolini orttiradi.

Natijada, tasodifan boshi berk ko'chadan chiqish yo'li ko'rina boshlaydi.

___

Large Reasoning Models (LRM) ham shunga tabiatan o'xshash usulda boshqarilishi mumkin. Bunda keyingi so'z bashorat qilinayotgan (next token prediction) taqsimot sun'iy ravishda o'tkir (peaky) taqsimotdan yoyiqroq (uniform) taqsimotga temperature annealing usulida o'tkaziladi. Bu esa tanlanishi mumkin bo'lgan keyingi so'zlar to'plamini ancha kengaytirishga xizmat qiladi.

@lazizabdullaev

Got a Google offer

...and I rejected it.

I interviewed with Google around a year ago, passed all their 4 interview rounds, and received an offer for their Munich office.

Total compensation was about 20% higher than what I was making in Berlin. But Munich is at least 20% more expensive.

Moving for essentially the same compensation didn't make sense. I'm happy with my work at Amazon, and the Google offer just wasn't compelling enough to justify the move.

Google'dan offer oldim

...va rad etdim.

Taxminan bir yil oldin Google bilan intervyu o'tkazdim, ularning 4 ta intervyu bosqichini muvaffaqiyatli o'tdim va Myunxen ofisi uchun ish taklifi (offer) oldim.

Umumiy taklif qilingan maosh Berlindagi maoshimdan taxminan 20% yuqori edi. Lekin Myunxen yashash xarajatlari Berlindan kamida 20% qimmat.

Deyarli bir xil maosh uchun Myunxenga ko'chish mantiqiy emas edi. Men Amazondagi ishimdan mamnunman va Google taklifi ko'chishni oqlaydigan darajada jozibador ko'rinmadi.

Designing systems for 'unknown unknowns'
Part 1
🇺🇸

In large scale distributed systems, anything can fail at some point. So as part of the system design, engineers are expected to list the anticipated failure modes and how their design mitigate and recover from them. So we cover the failure modes that we know with automated tests.

However, that is limited by only what is known. When the system is deployed to the wild, there will anyways be stuff that fails in unexpected ways, meaning failure is inevitable because of unknown unknowns.

What do we do with them?

We acknowledge we cannot prevent all failures with tests and now what matters for these failures is how fast we recover from them. There are standard metrics that measure this more formally:

- MTTD (mean time to detection): how quickly do we find out something failed?
- MTTA (mean time to acknowledgement): how quickly do we start responding?
- MTTR (mean time to recovery): how quickly we recover.

For example,

MTTD = sum(detection_time_i - incident_start_time_i) / number of incidents. 

The smaller these numbers are, the more resilient your system is to failures.

How do we make these numbers smaller?

I will answer that in Part 2.

#distributedsystems #operations #aws #operationalexcellence #testing

'Noma'lum noma'lumlar' uchun sistema qurish
1-qism
🇺🇿

Katta hajmdagi taqsimlangan (distributed) sistemalarda ixtiyoriy komponent qachondir ishdan chiqishi mumkin. Shuning uchun sistema arxitekturasini qurish jarayonida muhandislardan ehtimoliy nosozlik turlarini sanab o'tish va ularning arxitekturalari bu nosozliklarni qanday oldini olishi va tiklanishini ko'rsatishi kutiladi. Shunday qilib, biz ma'lum bo'lgan nosozlik turlarini avtomatlashtirilgan testlar bilan qamrab olamiz.

Biroq, bu bilan biz faqat ma'lum bo'lgan (biz bilgan, kutgan) nosozliklarni oldini olishimiz mumkin. Tizim real muhitga joylashtirilganda, kutilmagan joylardan ishdan chiqadi, ya'ni noma'lum noma'lumlar tufayli nosozlik hodisalari muqarrar.

Ularni nima qilamiz?

Biz barcha nosozliklarni testlar bilan oldini ololmasligimizni tan olamiz va endi bu nosozliklar uchun muhim narsa ulardan qanchalik tez tiklanishimizdir. Buni rasmiyroq o'lchaydigan standart ko'rsatkichlar (metrikalar) mavjud:

- MTTD (mean time to detection: aniqlashning o'rtacha vaqti): nimadir ishdan chiqqanini qanchalik tez bilamiz?
- MTTA (mean time to acknowledgement - tan olishning o'rtacha vaqti): javob berishni qanchalik tez boshlaymiz?
- MTTR (mean time to recovery - tiklanishning o'rtacha vaqti): qanchalik tez tiklanamiz.

Masalan,

MTTD = sum(aniqlanish_vaqti_i - hodisa_boshlanish_vaqti_i) / hodisalar soni.

Bu raqamlar qanchalik kichik bo'lsa, tizimingiz nosozliklarga shunchalik bardoshli bo'ladi.

Bu raqamlarni qanday kichiklashtirish mumkin?

Bunga 2-qismda javob beraman.

#distributedsystems #operations #aws #operationalexcellence #testing

Following today's trend 💫

Designing systems for 'unknown unknowns'
Part 2
🇺🇸

In Part 1, I talked about the fact that unknown unknowns are inevitable. We cannot forecast them upfront, so the resilience of a system to these failures comes from how fast we detect, acknowledge, and recover when the system fails.

One way to deal with unknown unknowns is fault injection, in which engineers intentionally introduce failures into a system and observe how it behaves.

Different companies use different approaches for injecting failures to their system. Netflix developed Chaos Monkey, a tool that randomly terminates production servers to force services to tolerate server failures.

At AWS, this idea is applied through a game day process. A game day is an exercise where failures are simulated and teams respond using the same tools and processes they would use during a real incident, exposing gaps in detection, response, and recovery.

This is directly related to the metrics discussion in Part 1. During a game day, you can measure how long it takes before someone notices something is wrong (MTTD), how long it takes before someone actively starts responding (MTTA), and how long it takes to mitigate or recover (MTTR).

For example, in one of the game days I led, I introduced an artificial delay in a database client, which caused messages to pile up in a message queue. Error rates did not change, and the system looked "healthy" from the dashboards. After a few hours, the issue was eventually noticed through a report from a dependent team whose data was no longer getting refreshed.

That game day identified that the team would lose most of the time in detection (poor MTTD) and acknowledgement (poor MTTA), resulting in poor MTTR. As a result, we took action items to improve the system based on our learnings: we added an alarm on the age of the oldest message in the queue, turning the unknown unknown into a known unknown. The next time there is high database latency in production, the system is now able to detect it early.

Each game day surfaces gaps, and fixing them improves how the system responds next time.

Voilà, you have just improved your MTTD, MTTA, and MTTR!

@abdullaevdev

#distributedsystems #operations #aws #operationalexcellence #testing

'Noma'lum noma'lumlar' uchun sistema qurish
2-qism
🇺🇿

1-qismda men noma'lum noma'lumlarning muqarrarligi haqida yozgan edim. Biz ularni oldindan bashorat qila olmaymiz, shuning uchun tizimning bu turdagi nosozliklarga bardoshliligi tizim ishdan chiqqanda buni qanchalik tez aniqlashimiz, tan olishimiz va tiklashimizga bog'liq.

Noma'lum noma'lumlar bilan kurashishning usullaridan biri nosozlik kiritish (fault injection) bo'lib, bunda muhandislar ataylab tizimga nosozliklar kiritadilar va buning natijasida sistemaning ishlashini kuzatadilar.

Turli kompaniyalar o'z tizimlariga nosozlik kiritish uchun turli yondashuvlardan foydalanadilar. Misol uchun, Netflix Chaos Monkey (betartib maymun) dasturini ishlab chiqqan. Bu vosita servislarning server nosozliklariga bardoshliliini tekshirish uchun, ishlab turgan serverlarni tasodifiy ravishda to'xtatadi.

AWS'da esa bu g'oya game day jarayoni (o'yin kuni) orqali amalga oshiriladi. Game day da nosozliklar simulyatsiya qilinadi va jamoalardan mavjud bo'lgan vositalar va jarayonlardan foydalangan holda nosozlikni bartaraf etish so'raladi. Ushbu jarayon jamoadagi nosozlikni aniqlash, unga javob berish va tiklanishdagi kamchiliklarni ochib beradi.

Bu 1-qismdagi ko'rsatkichlar muhokamasi bilan bevosita bog'liq. Game day davomida kimdir nimadir noto'g'ri ekanligini sezmagunicha qancha vaqt ketishini (MTTD), kimdir javob berishni boshlamagunicha qancha vaqt ketishini (MTTA) va nosozlikni bartaraf etish yoki tiklash uchun qancha vaqt ketishini (MTTR) o'lchashga yordam beradi.

Masalan, men boshqargan game day'lardan birida ma'lumotlar bazasi klientiga sun'iy kechikish (delay) kiritdim, bu esa xabarlar navbatida xabarlar to'planib qolishiga sabab bo'ldi. Xatolik darajasi o'zgarmadi va tizim dashboard'lardan "sog'lom" ko'rinardi. Bir necha soatdan so'ng, muammo bizning sistemani ishlatuvchi boshqa bir jamoadan kelgan xabar orqali sezildi: ularning ma'lumotlari yangilanmayotgan ekan.

O'sha game day jamoa vaqtning ko'p qismini aniqlash (yomon MTTD) va tan olishda (yomon MTTA) yo'qotishini aniqladi, natijada yomon MTTR hosil bo'ldi. Game day dan so'ng, biz o'rganilgan narsalarimizga asoslanib, tizimni yaxshilash uchun vazifalarni aniqladik: navbatdagi eng eski xabarning yoshiga signal (alarm) qo'shdik, ya'ni noma'lum noma'lumni ma'lum noma'lumga aylantirdik. Keyingi safar ishlab turgan muhitda (production'da) ma'lumotlar bazasi ga ulanishda kechikish ko'rsatkichlari yuqori bo'lgan holda, tizim endi uni erta aniqlashga qodir.

Har bir game day kamchiliklarni yuzaga chiqaradi va ularni tuzatish tizimning keyingi safar qanday javob berishini yaxshilaydi.

Mana, siz hozirgina MTTD, MTTA va MTTR'ingizni yaxshiladingiz!

@abdullaevdev

#distributedsystems #operations #aws #operationalexcellence #testing

Getting hired at Amazon is a statistical anomaly in many ways. It is similar to getting into Harvard, and the data actually backs that up. Depending on the year and the role, acceptance rates here hover between 0.5% and 2%.

Source

#amazon

Amazon’ga ishga qabul qilinish statistik jihatdan noodatiy holat hisoblanadi. Bu jarayon Garvardga o‘qishga kirishga o‘xshaydi va buni ma’lumotlar ham tasdiqlaydi. Yil va lavozimga qarab, bu yerda qabul qilinish darajasi odatda 0,5% dan 2% gacha bo‘ladi.

Manba

#amazon